Transmission system with flexible frame structure

Transmission system with flexible frame structure

The present invention relates to a transmission system including a transmitter coupled to at least one receiver via a transmission medium. The transmitter includes a frame assembly device for assembling a frame including a control portion and a payload portion, and the receiver includes a frame disassembly device , Used to extract the payload part from the frame.

The invention also relates to transmitters, receivers, transmission methods and signals.

The transmission system of the present invention can be known from DAVIC 1.1 Specification, part 8, Revision 3.0.

In the DAVIC (Digital Audio Video Council) specification, an attempt is made to standardize digitally enhanced broadcast channels. These standards cover the entire path from content providers to service providers to end users. The aspects covered by DAVIC are, for example, video coding, confidentiality, channel coding, modulation and frame structure.

In DAVIC, it is recommended to use MPEG-2 transport stream multiplex packets, in which the 187-byte payload part transmits the frame including the control part and the payload part. In DAVIC, the payload part is a sequence of ATM cells. The control part can carry several items, such as packet priority, error flag, and because the ATM cell is introduced as filling information to fill the transmission channel, the current ATM cell sequence carried in the frame is in the receiver Must be discarded in the instructions.

The problem with this known system is that it is not suitable for transmitting data in formats other than the current payload format. This format can be STM that requires fixed-length data words with a repetition rate of 125 μs, or such as "Ethernet" packets or P (network protocol) packets.

The purpose of the present invention is to provide a transmission system that allows transmission of various types of data formats.

Therefore, the transmission system according to the present invention is characterized in that: a frame assembling device is provided for inserting a packet having an identification part containing at least the length of the packet into the frame, and the frame assembling device also sets the frame at the beginning of a new packet in the frame. The position information is inserted into the control part; a frame removal device is provided to obtain the information of the start position of the new packet from the control part, and determine the start position of the subsequent packet from the start position and size of the current packet.

By indicating the start position of the packet in the control part of the frame, by determining the start of the back bread from the start position of the frame, and by determining the start of the back bread from the start position and length of the previous bread, it is possible to transmit all kinds of packets in the frame . It also allows the packet to be separated into two parts that are transmitted in different frames, resulting in high efficiency.

An embodiment of the present invention is characterized in that the frame assembly device is also used to introduce a package type indication in the identification part.

By specifying the types of packages, certain types of packages can be easily identified and processed accordingly.

Another embodiment of the present invention is characterized in that the control part of the frame includes the start position of the new packet in the next frame.

By indicating the start position of the new packet in the next frame, instead of indicating the start position of the new packet in the current frame, more time can be given to process the information about the position. As a result, the buffer for storing the frame part can be omitted.

Another embodiment of the present invention is characterized in that: the length of the packet is an integer multiple of a basic data unit larger than one byte.

By introducing these basic data units, the length of these packets can only have a limited number of values, reducing the number of bits that do not need to encode the length of the packets.

The present invention will now be described with reference to the accompanying drawings, in which: Fig. 1 is a transmission system according to the present invention; Fig. 2 is the structure of a basic frame composed of two MPEG transport stream frames; A packet of ATM cells that identifies bytes; Figure 4, a packet that includes variable-length cells; Figure 5, a packet that includes STM cells; Figure 6, a block diagram of the controller 18, used to be able to transmit according to Figures 3, 4 , And the frame structure of the data format of 5.

In the transmission system according to FIG. 1, the ATM signal is applied to the first input of the multiplexer 4 in the transmitter 2. The STM signal is applied to the second input of the multiplexer 4, and the sequence of variable length cells is applied to the third input of the multiplexer 4. Connect the first output of the controller 6 to the control input of the multiplexer 4. The output of the multiplexer 4 is connected to the input of a frame assembler (also called a frame assembler) 8.

The second output signal of the controller 6 carrying the output signal V-ATM is connected to the first input of the validity indication inserting device (also called validity indication inserter) 10. The third output of the controller 6 carrying the output signal V-STM is connected to the second input of the validity indicating inserter 10. The fourth output of the controller 6 transmitting the output signal V-VL is connected to the third input of the validity indicating inserter 10.

The output of the validity indicator inserter 10 is connected to the second input of the frame assembler 8. The output of the frame assembler 8 is coupled to the output of the transmitter 2.

The output of the transmitter 2 is coupled to the input of the receiver 14 via the transmission medium 12. The input of the receiver 14 is connected to the input of the controller 18 and the input of the frame detacher (here, the frame detacher) 16. The output of the controller 18 is connected to the second input of the frame splitter 16. At the first output of the frame splitter 16, an output signal in ATM format can be obtained. An output signal in the STM format can be obtained at the second output of the frame stripper 16, and an output signal including variable-length packets can be obtained at the third output of the frame stripper 16.

Configure the transmission system according to Figure 1 for data transmission in ATM and STM formats. It also supports the transmission of variable-length packets such as Ethernet packets or TCP/IP packets. The basic unit of different types of data is combined with the so-called protocol data unit (PDU'S).

The controller 6 provides a control signal to the multiplexer 4 to indicate which input signal is passed to the output of the multiplexer 4. The combination of the controller 6 and the multiplexer 4 is arranged to quickly change the source selection, introducing the possibility of generating an output stream in which ATM cells, STM data, and variable-length packets are interleaved.

The controller 6 provides information about the validity of the signal at the input of the multiplexer so that the validity indication inserter 10 introduces the validity indication in the frame constructed by the frame assembler 8. By using the validity indicator, the receiver can distinguish idle packets from packets carrying payload data. By adopting an identifier different from the one already described in the DAVIC specification, other types of data formats can be identified.

The frame assembler 8 constitutes a frame including the output data of the multiplexer 4 and the validity indication. The data frame is transmitted to the receiver 14 via the transmission medium 12.

In the receiver 14, the controller determines the start of the frame, and determines from the validity indication whether it is an input stream number carrying an ATM cell stream or an input signal carrying a different type of signal. This information is used to control the disassembler 16 so that it extracts different data formats from the frame and outputs them on the corresponding output terminal of the receiver 14. It can be seen that the receiver can be arranged to receive only one type of data. In this case, if the type of data appears in the frame at the input of the receiver 14, there is only one signal at the output of the receiver.

The signal according to Figure 2 includes a sequence of two standard MPEG transport multiplexed packets. 187 payload bytes of two consecutive MPEG transport stream packets are used to transmit the frame of the present invention. The first of these MPEG transport multiplex packets includes a one-byte synchronization signal 20, 187-byte payload 22 and a 16-byte error control section 24. The second of these MPEG transport multiplex packets includes a one-byte synchronization signal 24, a payload 26 of 187 bytes and an error control section 28 of 16 bytes. The synchronization signal is a fixed 8-bit segment with a binary value of "01000111", which is used for frame synchronization. The frame includes four control bytes 22-1 (CTRI0), 26-1 (CTRL1), 26-5 (CTRL2) and 22-6 (CTRL3). A group of basic data units (also called time slots) that carry user data 22-2...22-5, 26-2...26-5. These time slots include integer multiples of bytes. It is not necessary to start a new time slot after the CTRL0 byte, but can continue from the previous frame. This increases the efficiency of the frame, because there is no useless space in the frame. The CTRL0 byte indicates that this packet is the first in a sequence of two MPEG transport stream packets. The value of CTRL0 is EIPSSSSSb, where the E, P and S bits will be defined below. The CTRL1 byte indicates that this packet is the second of the two packet sequences. Its value is EOSSSSSb, and the E, P and S bits here will be defined below.

The E bit is a 1-bit error flag. When set to "1", it means that there is at least one uncorrectable bit error in the relevant 187-byte payload. This position can be set to "1" by an entity in the transport layer. When set to "1", this bit will not be reset to "0" before the bit value error is corrected.

The P bit is a 1-bit priority flag. When set to "1", it means that the relevant packet has a higher priority than its payload whose priority flag is set to "0".

The 5-digit SSSSS segment is a validity indicator. If its value is equal to binary "11110", the effective flow of ATM cells according to the DAVIC standard is within the effective load. In this case, no time slot is used. The first MPEG transport stream packet includes 3 ATM cells of 53 bytes and 27 bytes of the fourth ATM cell. The second MPEG transport stream packet includes the 26 remaining bytes of the fourth packet and 3 additional ATM cells. In this case, the CTRL3 byte does not appear.

If the character string SSSSS has another value, such as "01011", a signal different from the above-mentioned ATM stream appears in the payload 22 and 26. The character string SSSSS can be used to indicate which type of signal is in the payload, but the character string can also be used to indicate that the payload carries a format different from the DAVIC ATM stream. The latter opens up the possibility of interleaving different types of data in the payload. In this case, the data itself must carry identification information.

The CTRL2 byte is reserved, it will be specified for operation management, and the transmission of maintenance information (DAM).

The CTRL3 byte indicates the position of the first byte of the new protocol data unit (PDV) in the second MPEG transport packet. Each new PDU starts with a new time slot. By using this information, the disassembler 16 can easily extract PDUs from the frame.

Figure 3 shows that the first type of PDU is a sequence of ATM cells according to the draft (not yet published) of the IEEE 802.14 standard. This sequence is different from the standardized DAVIC sequence of ATM cells, where the identification part is a byte identifier 40 before each ATM cell. The identifier byte 40 has three sections defined according to the following table:

The format ID40-1 segment represents the PDU type. This section appears in all PDU's. For ATM PDU these positions become "00". The encryption key identifier bit 40-2 is used to indicate the conversion between two sets of encryption keys in order to increase confidentiality. The portion 40-3 including the last 5 bits of the identifier 40 is reserved for introducing additional format ID's.

Figure 4 shows that the second type of PDU is variable-length cell PDU. This type of cell has an identifier 44 with four segments. These have the meaning according to the table below

The format ID field 44-1 is 1 bit indicating the PDU type, and it is set to the value "1". The encryption key identifier 44-2 has the same meaning as discussed in conjunction with FIG. 3. A sequence identifier 44-3 is given for processing variable-length data units larger than 143 bytes. If the sequence identifier 44-3 has the binary value "10", the current segment is the first segment from the larger VL cell. If the sequence identifier 44-3 has the binary value "00", then the current segment is a segment in the VL cell and is followed by at least one segment. If the sequence identifier 44-2 has the binary value "01", the current segment is the last segment of the VL cell. If the sequence identifier 44-3 has the binary value "11", the current segment is the only segment of the VL cell. This sequence segment is used to extract the entire VL packet from a group of VL PDU's. The size identifier 44-4 consists of four bits and represents the number of 9-byte time slots following the same PDU.

Figure 5 shows that the third type of PDU is planned for the transmission of STM data. STM is used to support a fixed 64kbps bit rate connection, which is often used for telephone or ISDN purposes. The STM PDU includes a byte header 46, and 8 byte STM cells 48. Therefore, the STM PDU fills exactly one time slot. The header 46 includes three segments 46-1, 46-2, and 46-3 according to the following table.

The format ID46-1 with the value "01" indicates that an STM PDU is present. There are many options to implement STM downstream.

The first method of transmitting STM data is to use PDUs with the size of a single time slot. In addition, the header byte contains cell type information, which is a cell type identifier and an STM stream identifier. A single byte will be allocated for each time slot of every 64kbps connection. These time slots are expected to be 125Ts apart from each other. If only one 64kbps connection is active, an extra 7 bytes are generated for every 125Ts in approximately 1.5% of the 30Mbps stream. This method supports up to 256 simultaneous active cell accesses per downstream carrier.

Another method of transmitting STM used in the PDU according to FIG. 5 is to quote a 5-bit stream identifier, which is used to identify the actual STM stream specified by the data in the STM cell. Due to the size of the stream identifier, the number of simultaneous active cells is 32. The STM cell includes 8 consecutive bytes from an STM stream. Due to the 8 bytes of buffering from the ATM stream, this will result in an additional delay of 8 x 125 μs = 1 ms.

In the control unit 18 according to FIG. 6, the input is connected to the input of the frame synchronizer 51, to the control byte selector 52 and the PDU header selector 56. The output of the frame synchronizer 51 is connected to a reset input of the frame byte counter 50. The output of the frame byte counter 50, which carries the number of bytes present in the frame, is connected to the input of the logic unit 58 and the input of the control byte selector 52.

The first output of the control byte selector 52 carrying the ATM cell validity indication SSSSS is connected to the logic unit 58. The second output of the control byte selector 52 carrying the reset signal is connected to the PDU byte counter 54. The output of the PDU byte counter 54 carrying the number of existing bytes in the PDU is connected to the logic unit 58 and the PDU header selector 56. The first output of the PDU header selector, which carries the number of bytes in the PDU, is connected to the input of the PDU byte counter 54. The second output of the PDU header selector 56 carrying a signal representing the current PDU type is connected to the logic unit 58. The output of the logic unit 58 constitutes the output of the controller 18.

The frame byte counter 50 is a counter that can count from 0 to 186, and it outputs the current number of bytes in the frame. The frame synchronizer 51 determines the start of each 187-byte frame. The frame synchronizer 51 sends a reset pulse to the frame byte counter 50 at the beginning of each frame to reset it. This will synchronize the frame byte counter with the frame on the input of the control unit 18.

The control byte selector 52 is used to extract the control bytes CTRL0, CTRL1, CTRL2, and CTRL3 from the input stream. If the frame byte counter 50 has the value "0" or "156", use the control byte selector to select the byte on the input as the control byte. If the first bit in the control byte found at position 0 of the frame byte counter has the value "1", then the control byte is the CTRL0 byte. Its value is stored, and the value of the bit SSSSS is transmitted to the logic unit 58. If the sequence SSSSS is equal to "11110", the frame includes a sequence of ATM cells according to the DAVIC standard, and the logic unit 58 sends a command to the frame splitter 16 (FIG. 1) to transfer all the payload to the ATM output. If the sequence is different from "11110", the frame includes PDU basic data.

The control byte appearing at position 186 of the frame byte counter 50 can be CTRL2 or CTRL3. If the control byte in the same frame at position 0 of the frame byte counter 50 is the CTRL0 byte. Then the byte at position 186 is the CTRL3 byte. Otherwise the byte at position 186 is the CTRL2 byte.

In the case of the occurrence of CTRL3 bytes, its content, which represents the number of bytes at the beginning of the first new PDU in the next frame (or part of the frame), is stored for later use.

The PDU byte counter 54 is used to count PDU bytes. Set as a decrement counter, starting from the preset value and decrementing to 0. If it is the PDU byte in the payload, the PDU byte counter 54 simply decrements. It does not decrement when the CTRL0, CTRL1, CTRL2 or CTRL3 byte appears. If the value of the frame byte counter is the same as the value of the previous CTRL3 byte, the control byte selector used will reset the PDU byte counter to "0". This reset indicates the beginning of a new PDU. If the PDU byte counter 54 has the value "0", the PDU header selector 56 selects the current byte from the input signal. The PDU header selector determines the type of PDU and the length of the PDU from the information in the header.

The ATM cell PDU can be identified by the first two "00" values of the PDU header. The length of this ATM PDU is 54 bytes. The cell type is sent to the logic unit 58. Start sending the input signal to the ATM output via the detacher 16 (Figure 1). Only when the value of the PDU counter has changed and the value of the PDU byte counter is not equal to 0, the logic unit 58 only provides a read command to the disassembler 16. The purpose of this is to avoid sending the CTRL byte and PDU header to an output of the receiver. If a CTRL byte is at the input, the PDU byte counter is not advanced, so there is no CTRL byte passed to the output of the receiver. If the PDU header appears at the input, the PDU byte counter has a value of "0", so the PDU header is not transmitted to the output of the receiver. The number of PDU bytes after the first PDU byte (#PDU byte) is 53. This number is loaded into the programmable PDU byte counter 54. Each time one data byte is read from the input, the PDU byte counter is decremented. After 53 bytes are read from the input, the PDU byte counter will have the value "0". After that, the PDU header selector reads the header of the next PDU.

The VL PDU can be identified by the value "1" of the first bit in the PDU header. According to #PDU byte=8+L*9, from the length indicator L represented by the last four bits of the PDU header, determine the number of PDU bytes after the first PDU byte (#PDU), and determine the type of PDU Lost to the logic unit 58.

The STM PDU can be identified by the value "01" of the first two bytes of the PDU header. The length of this PDU (including the header) is 9 bytes, and the result is the value "8" for the #PDU byte. The PDU type and flow identifier are sent to the disassembler 16. The latter is used to identify that the STM stream belongs to the bytes in the current PDU, and this information is used to correctly send the STM signal to its final destination.