Data transmission system based upon orthogonal data stream mapping

[0002] The present invention relates to transmission networks of the type wherein a plurality of transmitters are transmitting streams of data frames over a broadband channel to a plurality of receivers, and relates particularly to a data transmission system using an orthogonal mapping of blocks and data streams into packets.

[0003] Today's communication systems are capable of providing digital communication over a broadband channel at data rates far exceeding 30 Mbits/s. The frames of data transmitted over such a channel are typically of fixed length. Interface devices provided at the receiving end of the channel collect the transmitted data frames, then forward these frames to a destination computer where they are then converted into logical blocks of data for use by the computer's software applications. An illustration of this method of transmission is the TCP/IP architecture used to transmit data over the Internet, in which the frames received by an interface device are encapsulated into IP packets which are then utilized by TCP/IP applications.

[0004] One disadvantage of this type of transmission system is the inability of today's interface devices to independently process frame data. Current interface devices must interrupt the destination computer each time a frame is received so that its software can convert these frames into useful logical blocks of data. Such direct handling of frame data by the computer's software has proven to be an inefficient use of CPU time. Thus, there is a need to translate frame data into useful data blocks directly within the network interface to improve the communication system described, in order to relieve the computer of this inefficient task of frame conversion.

[0005] Another shortcoming of present day network interfaces is their inefficient support of multicast data reception. This inefficiency results from a limited capability in the network interface to filter hardware addresses. For example, to support the reception of multicast IP datagrams in an Ethernet environment, a network interface must be able to receive packets with addresses that correspond to a particular host's set of IP group addresses. It is the function of the address filter to limit the multicast packets received by the network interface to only those packets having a valid destination address.

[0006] Unfortunately, the address filters of many current Ethernet network interfaces can only be configured to recognize a small number of hardware addresses, thus requiring the address filter to be disabled (or “opened up”) whenever the number of addresses within a particular group exceeds the limits of the filter. This disabling of the address filter can result in the computer having to inefficiently process data packets not intended for reception by its corresponding network interface. Thus, expanding the function of current address filter technology so as to improve the overall multicast transmission efficiency would be a desirable enhancement to the communication system described above.

[0007] A final unfavorable characteristic of the above described communication system relates to the unsecured method in which unicast transmissions are presently carried out over the network. Typically, broadcast of these unicast messages requires that the hardware address of a receiving station be accessible to the public in order to enable address resolution. For example, in TCP/IP, an Address Resolution Protocol (ARP) is used to share hardware addresses between host computers. Each host computer associates an IP address with a corresponding hardware address so that it can be determined to which interface device the frame data is to be forwarded. This public exchange of hardware address information makes it possible for information to be wrongfully intercepted through the use of counterfeit receiver hardware. Thus, devising a method of address resolution, whereby the hardware address of the receiving station need not be publicly disclosed, would be desirable to improve unicast transmission security.

[0008] Accordingly, the main object of the invention is to provide a data transmission system, wherein multiple computers can communicate to one another over a broadband channel using transmitters and receivers, each of which exchanges logical blocks of data that are carried over the channel in streams of frames.

[0009] Another object of the invention is to provide a data transmission system of the above type, wherein each host computer is attached to the broadband channel by using an intermediary receiving device, said device having the task of transforming frame data into logical data blocks that are then processed by the host computer upon receiving an interrupt signal from the receiving device indicating that the logical data blocks have been stored in the computer memory.

[0010] Another object of the invention is to provide a data transmission system of the above type, wherein multicast address filtering capability is expanded using a block identifier located within the received data packet itself that can be both masked and pattern matched against group address templates available to the receiving device.

[0011] Another object of the invention is to provide a data transmission system of the above type, wherein during unicast data transmission, unicast addresses are not publicly broadcast over the network, such that only authorized transmitters and the intended receiver itself possess the unicast address.

[0012] Therefore, the invention relates to a data transmission system, wherein a first plurality of transmitters transmits data packets over a broadband channel to a second plurality of receivers, in which each transmitter provides a stream of fixed-length packets constructed from a stream of variable length data blocks, each possibly originating from a different source, said packets being multiplexed amongst the various transmitters prior to being transmitted over the broadband channel.

[0013] In the preferred embodiment; transmitted data blocks are distributed over one or several fixed length packets, each packet comprising a packet header, having a source identifier that identifies the transmitting source, and the transmitted data itself. The first packet of any given transmitted data block also contains a block identifier that identifies the block being transmitted.

[0014] The preferred embodiment also permits multiple transmitters to transmit data concurrently over the broadband channel so long as each transmitter sends packets in the sequence that corresponds to their order within the data block. The packets may be interleaved and multiplexed on the broadband channel, however, each receiver is responsible for identifying packets belonging to each source or transmitter using the source identifier and reformatting the packets received into data blocks using the block identifier. Thus, the receiver must be capable of filtering through multiple packets originating from different transmitters and transforming them back into data blocks.

[0015] The objects and other features of the invention will be made clear in reading the following description of the preferred embodiment in reference to the accompanying drawings, wherein:

[0016] FIG. 1 is a block diagram depicting a data transmission system according to the invention.

[0017] FIG. 2 is a detailed representation of a fixed-length packet transmitted over the broadband channel in accordance with the preferred embodiment of the invention.

[0018] FIG. 3 is a flow diagram depicting the storage of logical block data into fixed length packets by the transmitter.

[0019] FIG. 4 is a flow diagram depicting the transmission of data streams, each possibly originating from various sources, over a single broadband channel.

[0020] FIGS. 5(a)-(b) are flow diagrams depicting the process for receiving data in accordance with the preferred embodiment of the invention.

[0021] FIG. 6 depicts the method of buffer management utilized by the receiver of the preferred embodiment.

[0022] A data transmission system 100 according to the present invention is illustrated in FIG. 1. The system comprises a plurality of transmitters 110 that transmit data over a broadband channel 130 to multiple receivers 140. The transmitters provide a flow of packets, preferrably a fixed length, constructed from streams of variable length data blocks, each data block possibly originating from a different source (such as from multiple host computers connected to the transmitter—not shown), that are first multiplexed by multiplexer 120 before being transmitted over the channel 130. The transmitted packets are then reassembled into logical data blocks by receivers 140 for use by various software applications running on one or more host computers (not shown) connected to each of the receivers. Although transmitter and receiver are referred to separately throughout this specification, one skilled in the art will recognize that the functions can operate simultaensously as a transceiver function.

[0023] Multiplexer 120 can be of any type in compliance with the broadband channel 130 employed. In the preferred embodiment, multiplexer 120 conforms with Digital Video Broadband (DVB) channels; furthermore, the multiplexing function can be integrated into the transmitters. Broadband channel 130 can be any high speed media that facilitates the transfer of data, voice and video at rates of 1,544 Mbps or higher.

[0024] In the event that frequency division multiplexing (FDM) is used to transfer data across the channel as in the case of cable TV transmissions, modems (not shown) are required at both the transmitting and receiving ends of the channel 130 in order to modulate the digital transmission and demodulate the received analog signal. In addition, data transmission system 100 depicted in FIG. 1 can be applied to DVB satellite transmission by implementing European Telecommunications Standard (ETS) 300-421 and ETS 300-429 as digital broadcasting systems for television sound and data services with modulation for 11/12 GHz satellite services.

[0025] Packet Structure

[0026] FIG. 2 depicts the packet structure used to transmit data over broadband channel 130. Recall that transmitter 110 constructs these fixed length packets from variable length data blocks originating from either a single source or from several sources connected to the transmitter, after which the packets from the various transmitters are multiplexed by multiplexer 120 prior to being transmitted over channel 130.

[0027] In the preferred embodiment, the packet length is fixed at 188 bytes (note that this size can be made arbitrarily different without affecting the invention). Although the packets are fixed in size, their structure varies as a result of both the need to demarcate the start of a new block of data and the need to accommodate varying data chunk sizes. Thus, packets are categorized into two main types, namely, a first type containing First Chunk 200 and a second type containing Middle/Last Chunk 250.

[0028] The packet corresponding to First Chunk 200 contains a 4 byte Packet Header 210 (as do all of the packets) that includes a 13 bit Source Identifier (SID) 211 used in identifying common logical sources from amongst the various host computers that may be connected to any given transmitter. This header structure is similar to that used in Moving Picture Experts Group (MPEG) packets. In addition to the packet header, First Chunk 200 also contains an 8 byte Block Header 220, the first 4 bytes of which includes a 12 bit Block Size field 221 containing the size, in bytes, of the data block being transmitted, with the remaining 4 bytes of Block Header 220 being reserved for Block Identifier (BID) 226, used by a receiver to identify given blocks of data. The remaining 176 bytes of First Chunk 200 is made up of Payload Data Field 230, used to store the transmitted data.

[0029] BID 226 is comprised of two components, one flag bit (bit 0) labeled Unicast Flag (UF) 227, and Address Field 228 made up of the remaining 31 bits of BID 226. Unicast Flag 227 is used by a receiver to determine whether the block being transmitted is a unicast or a multicast transmission block.

[0030] In the preferred embodiment, a BID having a UF equal to “1” is deemed to represent the transfer of a unicast transmission block, whereas a BID having a UF equal to “0” represents the transfer of a multicast transmission block. When UF 227 is equal to “1”, thus indicating the transfer of a unicast transmission block, the entire 31 bits of Address Field 228 contains the unique unicast address for the intended receiver hardware. This mode of operation is discussed in further detail below in the section entitled “Unicast Addressing Security”.

[0031] Again according to the preferred embodiment, when UF 227 is equal to “0”, the transmission of data is said to multicast, whereby transmitted data blocks are addressed to multiple receivers that are a subset of a larger group of receivers. In this mode of operation, Address Field 228 can be masked and pattern matched against address templates in order to filter out unwanted data packets. In addition, bits 1 through 3 of Address Field 228 can concurrently be used as a Service Type (ST) Field 229 allowing groups of receivers to be addressed based upon their service mode. The following section entitled “Multicast Group Address and Service Type Filtering” discusses these methods of multicast address filtering in further detail.

[0032] Like the packet representing First Chunk 200, the packet corresponding to Middle/Last Chunk 250, of FIG. 2, is comprised of both a Packet Header and a Payload Data Field. While the packet header structure is identical between the two packet types, both a variable length Payload Data Field 260 and the omission of a block header distinguishes Middle/Last Chunk 250 from First Chunk 200. Variable length Payload Data Field 260 is necessary when the remaining data to be transmitted is smaller than 184 bytes. In such situations, because the packet length must remain fixed at 188 bytes, any unused portion of the packet is necessarily padded with Stuffing Bits 270.

[0033] Note that if the size of the transmitted data block is smaller than 176 bytes, only one packet is needed for transmission of this data. In these situations, either the remainder of the packet can be padded with stuffing bits, or alternatively, a second data block intended for the same receiver (or group of receivers) can be transmitted by incorporating a second Block Header 220 into the packet. Thus, packets may contain a plurality of block header and payload data sections depending on the size of the data blocks that are to be transmitted.

[0034] Multicast Group Address and Service Type Filtering

[0035] Recall from the above discussion that when Unicast Flag 227 is equal to a “0”, the data block being transferred is a multicast transmission block intended for reception by a subset of the available receivers along the network. Because Address Field 228 is not needed to identify a uniquely designated receiver address while operating in this mode, its contents can be exploited to implement both multicast group address filtering as well as service type filtering. The first 3 bits of Address Field 228 are designated as Service Type (ST) Field 229 to facilitate the latter of these filtering modes.

[0036] Multicast group address filtering is accomplished in the receiver by comparing bits 1 though 31 in Address Field 228 of the BID with an internally stored bit map. This bit map is comprised of both a mask bit map and a pattern bit map. The mask bit map is first used to determine the relevant bits in Address Field 228 that represent the addresses of the group of interest, after which those relevant bits are compared against the pattern bit map. If all the relevant bits in Address Field 228 match those of the pattern bit map, the data block is received.

[0037] Note that this masking feature enables a receiver to ignore certain bits in Address Field 228 and thus focus only on those bits that form the portion of the address field that defines the group of interest. Masking on all of the bits of Address Field 228 allows a receiver to search for a particular multicast address, while masking off all of the bits in the address field would have the effect of the receiver accepting all multicast addresses.

[0038] In addition to the method of multicast group address filtering discussed above, the receiver hardware can further process addresses through the method of Service Type filtering. Service types (or service modes) are used in the transmission system to attach a particular organization or classification to the data that is being transmitted or received. Use of these service modes further expands the processing capabilities of multicast transmission systems by allowing transmitters or receivers, operating within a particular group addressing mode, to concurrently function in a separate service mode that is unique from the service mode of other transmitters or receivers operating within their address group. An example of a product capable of utilizing such service modes is the IBM Advance Cable Communication System (ACCS) which currently supports the services: ACCS Broadcast, IP Unicast and IP Multicast.

[0039] Service type filtering is accomplished in the receiver through the use of Service Type Field 229. In the preferred embodiment, this field is 3 bits in length and occupies bits 1, 2 and 3 immediately following Unicast Flag 227 in Block Identifier 226, thus providing eight service indices amongst which various service modes can be designated. The size of Service Type Field 229 can be varied depending on the number of service modes to be supported.

[0040] Note that the differentiation between Unicast and Multicast transmission can itself be thought of as producing two service types the latter of which can be divided into still more specific services through the use of Service Type Field 229.

[0041] Transmission Sequence

[0042] The transmission of logical data blocks over broadband channel 130 of FIG. 1 involves first transforming the logical data stream into packets, preferrably of fixed length, then multiplexing those packets amongst the various transmitters connected to the channel.

[0043] FIG. 3 depicts the first of these steps carried out by the transmitter, namely the transformation of a data stream into fixed length packets of the type depicted in FIG. 2. The transformation is initiated by an enduser system (hereinafter called “enduser”) sending a SET DATA START ADDRESS command to its corresponding transmitter. This command contains the start address of the first memory location in a linked list buffer chain. The transmitter then constructs fixed length packets from the Logical Data Stream sent by the enduser, storing each the packets in memory locations along the linked list buffer chain. After completion of the transformation, the transmitter sets an internal Data Ready flag indicating that the data stream is ready for transmission. Alternatively, the transmitter can send an interrupt signal to its corresponding enduser indicating that the transformation into packets is complete. A Data Under-Run flag is set in the transmitter if a second SET DATA START ADDRESS command is received by the transmitter prior to completing a previous transmission.

[0044] Once transformed into fixed length packets, the data stream is then transmitted over the broadband channel as depicted in FIG. 4. The transmitter first retrieves the packeted data by reading along the appropriate linked list buffer. The packets are then multiplexed amongst the various data streams being transmitted prior to being launched onto the broadband channel. The data can optionally be modulated prior to transmission.

[0045] Receive Data Sequence

[0046] The receiver performs three primary tasks in retrieving information from the broadband channel. The first task is to filter the received data for desired packets by examining both the source ID, contained in the packet header of all received packets, and the destination address contained in the block identifier of the first packet in the data stream. Next, the receiver assigns a buffer pool, which exists in the enduser memory, to each unique source identifier contained in the group of filtered packets. Lastly, the receiver processes the filtered packets by either translating them back into the original logical data block, or by storing the packeted information, as is, in the enduser memory for later translation. The method used to accomplish these tasks in the receiver of the preferred embodiment is depicted in FIG. 5.

[0047] Following receipt of a packet 502, the data is first demodulated in step 504, provided the information was optionally modulated prior to its transmission over the broaddband channel. Filtering of destination addresses begins with step 506, where it is determined whether the received packet contains a block identifier. Should the packet contain a block identifier, steps 508 through 520 carry out the tasks of unicast and multicast group and service type address filtering discussed above. The enduser uses the commands SET SERVICE INDEX and ENABLE SERVICE INDEX, as depicted in steps 528 and 530 respectively, to instruct the receiver how the destination addresses are to be filtered.

[0048] The SET SERVICE INDEX command is used to configure address filtering in the receiver to either unicast or multicast mode, and in the case of multicast filtering, to associate a corresponding multicast mask and group address pattern with the index. Should the desired addressing mode be multicast, the receiver uses the multicast mask and group address to pattern match against the address contained in the block identifier. The ENABLE SERVICE INDEX command is used to allow further filtering of multicast group addresses by service type as discussed earlier. If the SET SERVICE INDEX command configures the receiver to operate in unicast addressing mode, the BID is compared against the receiver's unique internal unicast address, and the multicast mask and address pattern are ignored.

[0049] The receiver uses the information in the SET SID INDEX command, issued by the enduser, to associate a start address of a linked list buffer pool with a particular source identifier of the received data packet 522. The receiver will later use this start address to store the data that is contained in the various packets received, and having the given source ID, in the buffer pool in order to facilitate re-assembly of the packeted data into a logical data block. Although this association is depicted at step 522 in the receive data path flow diagram, the step can occur at any point in the process prior to the filtering of the SID in step 524. The operation of storing the received data in the buffer pool is described in further detail in the following section entitled “Buffer Management”.

[0050] Whether the received packet contained a valid destination address and thus successfully traversed the various filtering mechanisms, or the packet contained no BID at all, the next step in the receive process is to filter the packet based upon its source identifier. Both the SET SID INDEX command 532, which identifies enduser-desired source ID's to the receiver, and the ENABLE SID INDEX command 534 which enables source ID filtering, are used by the receiver to facilitate SID filtering as depicted in step 524. If a packet contains a source ID equal to an SID identified by a previously received SET SID INDEX command, information from the packet will be processed and stored in the buffer pool that was associated with the source ID in step 522.

[0051] The enduser controls the processing and storage of the packeted data again through the use of the ENABLE SID INDEX command 534. In addition to enabling source ID filtering in the receiver, this command determines whether the packeted data is to be stored in the buffer pool in either block or packet format. In block mode, the receiver stores only the data portion of the packet, which is contained in its payload section, from which the complete transmission block can later be assembled. In packet mode, the receiver simply fills the buffer pool with the entire contents of the packet, leaving the assembly of the data block to the enduser. In either storage mode, the destination address contained in the BID of the first packet in the data stream is stored in the first 32 bits of the buffer pool. Note, that for security reasons (as will further be discussed in the section below entitled “Unicast Addressing Security”) any unicast addresses received are “zeroed out” in step 516 prior to storage.

[0052] The process of storing packets or payload data in the buffer pool continues for each valid source ID received until the block size, as depicted in field 221 of FIG. 2, for the logical data block is reached. At this time, the receiver generates a Data Ready interrupt which indicates to the enduser that the logical data block is ready to be read from the buffer pool, or, while operating in packet mode, that the stored packets are ready to be translated into a logical data stream. Alternatively, a Data Ready flag, that is possibly a portion of a status map having one bit allocated per valid SID, can be polled by the enduser using the QUERY DATA READY command to determine when a particular logical data block is ready for processing by enduser applications.

[0053] Buffer Management

[0054] As was described above, the enduser communicates an association of a buffer pool with a particular SID to the receiver through the use of the SET SID INDEX command. This buffer pool (allocated in the memory of the enduser, e.g. the PC storage) is formed from a linked list of nodes each having three fields as depicted in FIG. 6. In the preferred embodiment, Field 1 is used to provide information regarding the status of the buffer as well as some receiver exception status, the Data Ready flag, contained therein, being most relevant to the invention. Field 2 contains a pointer to a physical address, located in the enduser memory, in which the received data can be stored. Finally, field 3 contains a pointer to the physical address of the next node in the linked list buffer.

[0055] Thus, when the receiver stores data in the buffer pool in either packet mode or block mode form, it first stores the information in the address provided in Field 2 of the link node, then determines the physical address of the next node in link list from Field 3. This process, as now depicted in FIG. 5, is continued until the entire data block has been stored in the buffer pool, at which time the receiver resets the block count and service type index for the current SID in step 548, then updates the Data Ready flag in step 550, setting the flag equal to a “1” (such assignment being entirely arbitrary) to indicate that the buffer is ready to be read by the enduser. The enduser then reads the logical data block from its memory by traversing the chain of link nodes, simultaneously freeing the buffer by setting each Data Ready flag back to “0” (again polarity being arbitrary.)

[0056] Unicast Addressing Security

[0057] As mentioned above, another object of the invention is to support unicast data transmission while limiting access of the destination address to only authorized transmitters. Current unicast transmission methods require that the unicast address be made publicly available, thus allowing interception of information that is destined for a particular enduser by unauthorized endusers through the use of counterfeit receiver hardware.

[0058] The following features enable unicast address anonymity to be maintained in the system. First, the unicast address register is hardwired into the receiver hardware rendering the register non-programmable, and thus preventing unauthorized individuals from reading or altering the address. This unique address is assigned during manufacturing and cannot be subsequently read or altered by any individuals. Second, the unicast address is “zeroed out” in the enduser memory once matched against the receiver's internally hardwired register value. This prevents individuals from dumping or scanning the enduser memory when a valid unicast transmission is received in order to determine the receiver's unique unicast ID. Lastly, the unicast address is associated with the receiver hardware serial number but is not identical thereto. While the receiver serial number represents a visible ID which uniquely identifies the hardware component, the unicast address remains a non-visible ID that uniquely identifies the hardware component. This one-to-one correspondence between serial numbers and unicast ID's can be maintained by the manufacturer in a secured database, which can then be used by transmitters to send unicast transmissions to particular receiver hardware.

[0059] While the invention has been described in detail herein in accordance with certain preferred embodiments thereof, modifications and changes therein may be effected by those skilled in the art. Accordingly, it is intended by the appended claims to cover all such modifications and changes as fall within the true spirit and scope of the invention.