KR20000074179A - Apparatus and method for transmitting and receiving data with radio link protocol in wireless communication system - Google Patents

Abstract

PURPOSE: An apparatus and a method for transmitting and receiving data according to radio link protocol are provided for efficient transmission of data in radio environments. CONSTITUTION: A data transmitting apparatus of a mobile communication system includes a plurality of radio link protocol(RLP) processors each of which receives a data block with a size corresponding to a frame request to generate RLP frame and has an idendifier for indicating that the RLP frame is new or retransmitted, a multiplexing processor for receiving RLP frame from at least one RLP processor to generate multiplexed frame information having a variable length, and a physical layer processor for transmitting the multiplexed frame information through a physical channel. A data receiver of the mobile communication system includes a physical layer processor for receiving information through the physical channel, a demultiplexing processor for demultiplexing information into at least one data block to divide it into RLP frames, and RLP processors for processing RLP frames sent from the demultiplexing processor.

Description

Device and method for transmitting and receiving data according to radio link protocol in mobile communication system {APPARATUS AND METHOD FOR TRANSMITTING AND RECEIVING DATA WITH RADIO LINK PROTOCOL IN WIRELESS COMMUNICATION SYSTEM}

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a code division multiple access (CDMA) mobile communication system, and more particularly to a radio link protocol (RLP) used for efficient transmission of data in a wireless environment. The present invention relates to an apparatus and a method for transmitting and receiving data.

In general, the CDMA mobile communication system has evolved from the IS-95 standard, which mainly focuses on voice, to the CDMA2000 standard, which can transmit not only voice but also high-speed data. According to the CDMA2000 standard, services such as high quality voice, moving picture, and internet search are possible.

An example of a packet data service provided by the CDMA2000 standard is shown in FIG. 1. In FIG. 1, a terminal is composed of a terminal device (TE) and a terminal device (mobile termination). In FIG. 1, the base station includes a BS / MSC (Base

Station / Mobile Switching Center), and the interworking function that interworks with the data network (eg, the Internet) is represented by IWF. The IWF unit is a device that performs a function of converting protocols when using different protocols. In FIG. 1, the upper service (Web Service) processing units of the terminal and the IWF unit exchange data through a network protocol (IP) processing unit and a link protocol (PPP) processing unit. That is, the data created by the upper service processor are finally transmitted to the lower layer in the form of a link protocol packet, and the lower layer transmits the data using an appropriate protocol.

1 illustrates an example in which an EIA-232 controller is used between TE and MT. The link protocol packets transmitted to the MT through the EIA-232 controller are divided into RLP frames via the Radio Link Protocol (hereinafter referred to as RLP). The RLP frame generated by the above process is transmitted through a physical channel connected through the CDMA2000 standard IS-2000 standard. The RLP packet received to the base station through the connected physical channel is restored to link protocol packets and transmitted to the IWF unit through the relay layer. In general, the interface between the base station and the IWF unit follows the IS-658 standard. The IWF unit extracts the data from the link protocol packet and delivers the data to the network protocol processing unit. Finally, the data is transferred to the higher service processing unit.

While the above process shows the process of transmitting data from the terminal to the other side, the process of transmitting data to the terminal is similarly performed.

In the CDMA2000, various configurations different from those of FIG. 1 can be provided to provide various services. However, all of the link protocol packets containing the data of the upper service are common to the radio physical channel through the RLP.

On the other hand, the current RLP operates according to the RLP Type 3 specification described in Chapter 11 of IS-707-A-1. Since the RLP Type 3 specification currently supports a maximum of 153.6 kbps for the Rate Set 1 and 230.4 kbps for the Rate Set 2, the frame transmitted by the RLP is in the RLP Type 3 specification. As suggested, up to 3 pieces can be transmitted. However, if the physical channel supports a maximum data rate of 153.6 or 230.4 kbps or more supported by the RLP Type 3 standard, for example, 307.2 kbps. When supporting 614.4 kbps and 1228.8 kbps, a larger RLP frame is needed. Therefore, in order to transmit an RLP frame larger in size than the current RLP Type 3 frame at a low data rate, a new method different from the existing engraving method is required.

Accordingly, an object of the present invention is to provide an apparatus and method for transmitting and receiving RLP frames having various lengths when transmitting and receiving data according to RLP in a mobile communication system.

Another object of the present invention is to provide an apparatus and method for retransmitting only a necessary portion without having to send the entire RLP frame by attaching a serial number in bytes when transmitting and receiving data according to RLP in a mobile communication system.

Another object of the present invention is to provide an apparatus and method for indicating and transmitting a retransmission in an RLP frame transmitted from a transmitter in a mobile communication system.

A data transmission apparatus of a mobile communication system according to an embodiment of the present invention receives a data block of a size corresponding to a frame request, generates a RLP frame, and includes a plurality of identifiers including an identifier indicating that the RLP frame is new / retransmitted. A RLP processor and a multiplexing processor that receives the RLP frame from at least one RLP controller of the RLP processors and generates multiplexed frame information having a variable length, and a physical layer that transmits the multiplexed frame information through a physical channel It consists of a processor.

In addition, the data receiving apparatus of the mobile communication system according to an embodiment of the present invention, a physical layer processor for receiving information received through a physical channel, and demultiplexing the information into at least one data block to inversely separated into an RLP frame A multiplexing processor and an RLP processor for processing a corresponding unique RLP frame transmitted from the demultiplexing processor and requesting retransmission when an error occurs.

1 is a block diagram of a general code division multiple access communication system for performing a packet data service.

2 is a block diagram of a data transmission and reception apparatus according to an RLP to which the present invention is applied.

3 is a schematic diagram of a data transmitter in accordance with the present invention;

4 is a schematic diagram of a data receiver in accordance with the present invention;

5 shows the format of frames generated in accordance with the present invention.

6 illustrates the format of an LTU created in accordance with the present invention.

7 illustrates the format of an RLP frame generated in accordance with the present invention.

8 is a diagram illustrating a frame format when transmitting and receiving an RLP frame generated according to the present invention through a basic channel.

9 is a diagram illustrating a frame format when transmitting an RLP frame generated through an additional channel according to the present invention.

DETAILED DESCRIPTION A detailed description of preferred embodiments of the present invention will now be described with reference to the accompanying drawings. First of all, in adding reference numerals to the components of each drawing, it should be noted that the same reference numerals are used as much as possible even if displayed on different drawings.

2 is a diagram illustrating a configuration of a mobile communication system for transmitting and receiving data according to an RLP to which the present invention is applied.

In FIG. 2, the physical layer processor 150, 250 connects a physical channel between a terminal and a base station according to the IS-2000 standard, and transfers RLP frames transmitted from the RLP processor 130,230 to the opposite physical layer through the connected physical channel, The components that deliver the RLP frames received through the channel to the RLP processor 130, 230 are shown in one block.

The multiplexer / demultiplex controller 140,150 attaches information such as the destination and size to the RLP frames to the physical layer processor 150,250 to the physical layer processor 150,250 and transmits the information to the physical layer processor 150,250, and vice versa. After checking the size and size, it performs demultiplexing function to deliver to upper RLP processor 130,230. The multiplexing / demultiplexing controllers 140 and 240 basically perform operations according to the IS-2000 standard.

The transmit and receive data buffers 122, 124, 222, and 224 are memory devices that store data received by the EIA-232 controller or the IS-658 controller from the link protocol processor 110, 210 as in the example of FIG. The data buffers 122, 124, 222, and 224 cut the stored packets in order to the required size whenever the RLP processor 130, 230 requests them. In addition, the data buffers 122, 124, 222, and 224 are stored in order each time data is transmitted from the RLP processor 130, 230. The stored data is transmitted to the PPP processor or the IWF unit by the EIA-232 controller or the IS-658 controller. The EIA-232 controller or the IS-658 controller operates according to the EIA-232 standard and the IS-658 standard, and performs data transmission and reception between the data buffers 122, 124, 222, 224 and the link protocol processor 110, 210. It should be noted that the present CDMA2000 packet service may use other schemes besides the EIA-232 controller or the IS-658 controller, so that these controllers are not shown in FIG.

When the physical channel is connected according to the IS-2000 standard, the RLP processors 130 and 230 first perform a initialization / reset procedure to obtain a round-trip delay. The initialization operation is performed according to the RLP Type 3 standard. The RLP processors 130 and 230 having completed the initialization work generate frames according to the required number and size whenever the multiplexing / demultiplexing controllers 140 and 240 request the RLP frames, and deliver the frames to the corresponding multiplexing / demultiplexing controllers 140 and 240. FIG. The multiplexing / demultiplexing controller 140,240 may request an RLP frame from the RLP processor 130,230 at a predetermined time (for example, 20 ms), and after recording information necessary for demultiplexing the RLP frame transmitted from the RLP processor 130,230, the physical layer processor 150,250 To pass.

In addition, the physical layer processor 150, 250 delivers the received information to the multiplexing / demultiplexing controller 140,240 every set time (20 ms). The multiplexing / demultiplexing controller 140 separates the RLP frames from the received information and delivers the RLP frames to the RLP processor 130,230.

The RLP processors 130 and 230 basically interpret the received RLP frames according to the RLP Type 3 standard. According to the RLP Type 3 standard, the RLP processors 130 and 230 perform the generation and interpretation of fragment frames. That is, if the size of the retransmission frame to be sent is larger than the size allowed by the multiplexing / demultiplexing controller 140,240, the RLP processor 130,230 makes it a fragment frame and transmits it. In the RLP Type 3 standard, the segmentation procedure is performed as follows.

1. RLP Type 3 can make up to three pieces. Each piece is distinguished by FIRST, SECOND, and LAST. If more fragments are needed, the RLP processor 130,230 waits until it can send up to three fragments without sending fragment frames.

2. The assembly procedure for the engraving frame is only possible once all the pieces have been received. That is, if any one of FIRST, SECOND, and LAST is broken, the entire piece must be sent again.

As described above, the multiplexing / demultiplexing controller 140 and 240 and the RLP processor 130 and 230 basically perform operations according to the IS-2000 standard and the RLP Type 3, respectively. However, it should be noted that the multiplexing / demultiplexing controller 140 and 240 and the RLP processor 130 and 230 perform not only this basic operation but also an operation according to the present invention to be described later, that is, generating an RLP frame of variable length.

3 is a diagram illustrating a configuration of an RLP frame transmitter according to the present invention.

Referring to FIG. 3, an RLP processor 130 for transmitting and processing an RLP frame includes an RLP controller 131, an L_V (S) register 132 which is a serial number counter, and a retransmission buffer 133. The RLP controller 131 receives the data from the transmission data buffer 122 to generate an RLP frame, and then transmits the generated RLP frame to the multiplexing / demultiplexing controller 140. The forward resequencing buffer 133 is used as a memory device to store data for retransmission.

4 is a diagram illustrating a configuration of an RLP frame receiver according to the present invention.

Referring to FIG. 4, an RLP processor 130 for receiving and processing an RLP frame includes an RLP controller 131, two registers 135, 136, L_V (R) and L_V (N), a register E 134, a NAK list 137, and a rearrangement. Buffer 138 is included. The RLP controller 131 receives an RLP frame from the multiplexing / demultiplexing controller 140 and checks whether data in proper order has arrived. At this time, if the sequence is correct, the data is transmitted to the receive data buffer 124. If not, it is stored in the reorder buffer 138, and then the portion to be retransmitted is recorded in the NAK list 137, and the portion stored in the NAK list 137 is sent when the next control frame is transmitted. The register E 134 is for recording the number of broken data blocks. If the multiplexing / demultiplexing controller 140 notifies the broken data block, the RLP controller 131 writes this value to the register E 134 and can use it when a reset is needed.

According to the present invention, an operation of generating and transmitting an RLP frame having a variable length may be roughly described by operations of the multiplexing / demultiplexing controller 140 and 240 and the RLP processor 130 and 230. Since the operations of the multiplexing / demultiplexing controllers 140 and 240 are performed in the same manner, and the operations of the RLP processors 130 and 230 are performed to be the same, the operation according to the present invention will be described below. The description will be limited to the operation of 130.

Transmission operation of multiplexing / demultiplexing controller

Since not only packet data but also voice data or other various information can be transmitted simultaneously through the physical channel to which the current channel is connected, a service for providing data to be transmitted to a multiplexing / demultiplexing controller is called a service. An information frame output from the multiplexing / demultiplexing controller is called a multiplexing / demultiplexing frame. In addition, a transmission unit that the multiplexer / demultiplexer 140 and the physical layer processor 150 exchange with each other is called an information bit or a physical frame, and a higher service block including the RLP processor 130 and the multiplexer / demultiplexer 140 The transmission units that exchange each other will be referred to as data blocks or RLP frames.

The transmitter-side multiplexing / demultiplexing controller 140 generates and transmits information bits to be transmitted to the physical layer processor 150 at least every set time (eg, 20 ms). That is, the multiplexing / demultiplexing controller 140 generates and transmits information bits to fill the payload of a frame transmitted to the physical channel for all currently connected physical channels. When the multiplexing / demultiplexing controller 140 generates these information bits and delivers them to the physical layer, they pass the following values.

SDU: Contains information bits to be actually transmitted. If there are no information bits to transmit, the multiplexing / demultiplexing controller and the physical layer fill in null values previously promised.

FRAME_SIZE: Contains the size of a physical channel frame that will contain information bits. If a null value is assigned to the SDU, this value is ignored by the physical layer.

-FRAME_RATE: Specifies the transmission rate at which the physical channel frame containing the information bits is to be transmitted. If a null value is assigned to the SDU, this value is ignored by the physical layer.

When the transmitter-side multiplexing / demultiplexing controller 140 transmits the above contents to the physical layer processor 150, the physical layer processor 150 processes the transmitted contents using a designated encoding method and a modulation scheme and then transmits the contents to the receiving side.

When the physical channel is allocated, the transmitter-side multiplexing / demultiplexing controller 140 generates information bits that can be transmitted to the physical channel to all assigned physical channels. The transmitter-side multiplexing / demultiplexing controller 140 receives a data block to be transmitted for services corresponding to the physical channel to which the logical channel is currently connected in order to generate information bits to be transmitted to the physical channel. At this time, it can be informed that nothing can be transmitted for services that cannot send a data block in the information bit. The service corresponding to the physical channel to which the logical channel is connected refers to a service capable of transmitting a data block to the physical channel to which the logical channel is currently connected. The process of connecting such a service between the terminal and the base station and connecting the logical channel for the service on the physical channel is possible as a signaling message.

When the transmitting-side multiplexing / demultiplexing controller 140 decides to transmit a data block of services corresponding to the physical channel to which the current logical channel is connected, the receiving side receives a data block of the appropriate length from the service according to an appropriate priority. The multiplexing / demultiplexing controller 140 receives a service identifier and a length information so as to know a service for delivering the data block received at a receiving-side multiplexing / demultiplexing controller when the data block is received from the service. Create a MuxPDU appended to the data block. The MuxPDU may have several data blocks and signaling messages received from various services. The information bit includes one or several such MuxPDUs, and a Cyclic Redundancy Code (CRC) for detecting an error may be added to each one or several MuxPDUs. When a CRC that detects an error is added to each MuxPDU, one CRC and a part of the information bits protected by the CRC will be referred to as a logical transmission unit (LTU) in the present invention.

When there are no more data blocks to transmit, the multiplexing / demultiplexing controller 140 uses a MuxPDU attached to a receiving side multiplexing / demultiplexing controller and a predetermined service identifier in advance to fill the remaining portion of the information bits, or the receiving side multiplexing / The remaining bit of information bits are filled using a constant bit pattern previously agreed upon with the demultiplexing controller. In the present invention, the MuxPDU to which the specific service identifier is added will be referred to as a fill MuxPDU, and the constant bit sequence will be referred to as a fill bit pattern.

The multiplexing / demultiplexing controller 140 transmits a null value to an SDU on a physical channel when receiving no signaling message or data block to be transmitted, or a predetermined bit string previously promised with a receiving-side multiplexing / demultiplexing controller as an information bit. To the physical channel. In the present invention, the constant bit string will be referred to as null traffic.

Receiving Operation of Multiplexing / Demultiplexing Controller

The receiving physical layer processor 150 analyzes the received signal by using a specified decoding method and demodulation method, and then transmits a portion of the information bits included in the received physical layer frame to the receiving side multiplexing / demultiplexing controller 140. When the physical layer processor 150 interprets these information bits and delivers them to the multiplexing / demultiplexing controller 140, the following information may be included and transmitted.

SDU: Contains the actual received information bit. If no information bits are received or the frame is broken, the multiplexing / demultiplexing controller 140 and the physical layer processor 150 fill in null values previously promised.

FRAME_QUALITY: This indicates whether or not the received physical channel frame is a valid frame.

FRAME_SIZE: Contains the size of the received physical channel frame.

FRAME_RATE: Contains the transmission rate of the received physical channel frame.

If the receiving multiplexer / demultiplexing controller 140 determines that no physical channel frame has been received on the receiving physical channel and fills an SDU with a null value and informs that the correct frame is received in FRAME_QUALITY, the receiving channel multiplexer / demultiplexing controller 140 corresponds to the physical channel to which the logical channel is connected. Notify all services that no frame has been received.

When the receiving side multiplexing / demultiplexing controller 140 sends the information bits received in the allocated physical channel, the receiving side multiplexer / demultiplexing controller 140 determines whether the received information bits are broken by looking at FRAME_QUALITY transmitted together in the physical channel. If the received information bit is broken and the received information bit is divided into several LTUs, the receiving side multiplexing / demultiplexing controller 140 evaluates the CRC of each LTU again to see if there are no error-free LTUs.

The multiplexing / demultiplexing controller 140, if there is a faulty LTU, informs all services corresponding to the physical channel to which the logical channel is connected, for each faulty LTU, that a broken data block has been received. In this case, the multiplexing / demultiplexing controller 140 informs each service of the maximum length of a data block of a corresponding service that a broken LTU can include.

The receiving side multiplexing / demultiplexing controller 140 corresponds to the physical channel to which the logical channel is connected if the received information bit is broken and a CRC for detecting an error for every one or several MuxPDUs is not added to the received information bit. Inform all services that a broken data block has been received. In this case, the multiplexing / demultiplexing controller 140 informs the maximum length of the data block of the corresponding service that can be included in the received information bit for each service.

The receiving-side multiplexing / demultiplexing controller 140 separates error-free MuxPDUs from the information bits other than the fill bit string if an error-free LTU or information bit is received. If the separated MuxPDU is not null traffic or a filled MuxPDU, the multiplexing / demultiplexing controller 140 transmits the length of the data block and the data block included in the MuxPDU to a service designated by the service identifier of the MuxPDU.

The receiving side multiplexing / demultiplexing controller 140 may notify that an empty data block is received if an error-free LTU or information bit is received and there is a service not receiving a data block among services corresponding to a logical channel on a physical channel.

The transmission and reception operations of the multiplexing / demultiplexing controller 140 as described above may be more clearly understood through the description of the following embodiments. The IS-2000 standard defines several dedicated traffic channels such as a fundamental channel, a supplemental channel, and a dedicated control channel. Therefore, the transmission and reception operations of the multiplexing / demultiplexing controller 140 according to the present invention can be described by being divided into a case applied to the base channel and a case applied to the additional channel. In addition, it may be described separately from the case where the LTU is used, and the case where the LTU is not used. In this case, the LTU is used to encode data using a convolution code and then to transmit and receive data. The LTU is not used to encode data using a turbo code. This is the case when data is transmitted and received.

First, before describing the operation according to an embodiment of the present invention, the number of information bits of the basic channel and the number of information bits of the additional channel defined in the IS-2000 standard are summarized in the following <Table 1> and <Table 2>, respectively. Same as Table 1 below shows the number of information bits of the basic channel defined in the IS-2000 standard, and Table 2 shows the number of information bits of the additional channel.

Number of information bits of the base channel of the IS-2000 Transfer rate Number of information bits 9600 bps 172 bit 4800 bps 80 bit 2700 bps 40 bit 1500 bps 16 bit

Number of information bits of additional channel of IS-2000 Transfer rate Number of information bits 307 200 bps 6120 bit 614400 bps 12264 bit 1228800 bps 24552 bits

It should be noted that the above <Table 1> and <Table 2> does not represent all the transmission rate prescribed in IS-2000.

When the LTU is used corresponding to the number of information bits as shown in Table 2, the size and number of LTUs are obtained as shown in Table 3 below. The number of information bits is obtained by multiplying the size and the number of LTUs and adding the remaining bits.

LTU applied to additional channels Transfer rate Logical transfer unit size Number of logical transfer units Extra bits 307 200 bps 760 bit 8pcs 40 bit 614400 bps 1528 bits 8pcs 40 bit 1228800 bps 3064 bit 8pcs 40 bit

The MuxPDU format proposed by the present invention to fill the information bits is shown in Tables 4, 5, and 6 below. Table 4 below shows the MuxPDU format for the information bits of the base channel, Table 5 shows the MuxPDU format for the information bits of the additional channel when the LTU is used, and Table 6 shows that the LTU is not used. If not, indicates the MuxPDU format for the information bits of the additional channel.

MuxPDU format for basic channel information bits Transfer rate Primary service data block Signaling message Service data block Service recognizer MuxPDU Header 9600 bps 171 bits - - - '0' 9600 bps 80 bit 88 bit - - '0001' 9600 bps 40 bit 128 bit - - '0101' 9600 bps 16 bit 152 bit - - '1001' 9600 bps - 168 bit - - '1101' 9600 bps 80 bit - 85 bit 3 bit '0011' 9600 bps 40 bit - 125 bit 3 bit '0111' 9600 bps 16 bit - 149 bit 3 bit '1011' 9600 bps - - 165 bit 3 bit '1111' 4800 bps 80 bit - - - - 2700 bps 40 bit - - - - 1500 bps 16 bit - - - -

MuxPDU format for additional channel information bits (if LTU is used) Transfer rate Service identifier Length indicator Length field Reserved field Length of service data block 307 200 bps 3 bit '0' - '000' Up to 737 bits 307 200 bps 3 bit 'One' 11 bit - Up to 729 bits 614400 bps 3 bit '0' - '000' 1505 bits 614400 bps 3 bit 'One' 11 bit - 1497 bit 1228800 bps 3 bit '0' - '000' 3041 bits 1228800 bps 3 bit 'One' 11 bit - 3033 bit max

MuxPDU format for additional channel information bits (if LTU is not used) Transfer rate Service recognizer Length indicator Length field Reservation field Length of service data block 307 200 bps 3 bit '0' - '000' Up to 6113 bits 307 200 bps 3 bit 'One' 11 bit - Up to 6105 bits 614400 bps 3 bit '0' - '000' 12257 bits 614400 bps 3 bit 'One' 11 bit - Up to 12249 bits 1228800 bps 3 bit '0' - '000' Up to 24545 bits 1228800 bps 3 bit 'One' 19 bit - Up to 24529 bits

In Tables 4, 5, and 6, the service identifier may be determined as shown in Table 7 below.

Service identifier Service identifier service '000' reservation '001' First service '010' Second Service '011' Third Service '100' 4th service '101' 5th Service '110' 6th Service '111' Board service

In Table 7, a null service is a predetermined value of a predetermined service identifier used to inform a receiving side multiplexing / demultiplexing controller of a filling MuxPDU for filling. As shown in Table 7, the MuxPDU formats of Tables 4, 5, and 6 can distinguish data blocks sent from up to six services.

Transmission operation through the basic channel of the multiplexing / demultiplexing controller

Table 4 shows the MuxPDU format transmitted through the basic channel. In this case, the first service can distinguish the MuxPDU header only without the service identifier. This is because the case where the lower 2nd bit of the MuxPDU header is 0 corresponds to the first service. The data block corresponding to the sixth service in the second service may determine and determine the service recognizer of <Table 7>. Therefore, the service recognizer of Table 7 may have only values from '010' to '110'. In the basic channel using the MuxPDU format shown in Table 7, when the data blocks of the first service are all filled with '1', the receiving multiplexing / demultiplexing controller corresponds to any service in the transmitting multiplexing / demultiplexing controller. Promises null traffic that doesn't. Therefore, the receiving side multiplexing / demultiplexing controller determines that the MuxPDU received on the base channel is null traffic if only the data block of the first service is present and the data blocks are all filled with '1'.

Assuming that six services using RLP are connected, the transmitter-side multiplexing / demultiplexing controller operates as follows.

First, the multiplexing / demultiplexing controller determines the transmission order of each service and the size of the data block according to a prescribed quality of service guarantee rule (QoS). Next, the multiplexing / demultiplexing controller requests a data block from the RLP processor of each service according to the priority. For data blocks to be transmitted on the basic channel, the RLP process generates a data block of an appropriate size according to the size, number, and combination of data blocks allowed by the MuxPDU in Table 4.

Must be requested. When data blocks are received from the RLP processor, the multiplexing / demultiplexing controller collects them and creates a MuxPDU. At this time, the multiplexing / demultiplexing controller finds an appropriate bit string from Table 4 and adds it to the MuxPDU header according to the included data block. The multiplexing / demultiplexing controller transfers the generated MuxPDU as information bits to the physical channel.

In this process, the RLP processor that does not have the opportunity to generate a data block is requested by the multiplexing / demultiplexing controller to generate a blank data block so that the RLP processor knows that the opportunity has not been obtained. . In addition, if all RLPs provide no data block in the process, the multiplexing / demultiplexing controller generates the null traffic and delivers it as an information bit to the physical channel.

Receive operation through basic channel of multiplexing / demultiplexing controller

The receiving side multiplexing / demultiplexing controller operates as follows for the information bits transmitted on the base channel. First, each data block is distinguished by looking at the data rate and the MuxPDU header bit. The divided data block is transmitted to the corresponding service with reference to Table 4 above. If the received information bits are broken, the multiplexing / demultiplexing controller notifies all services corresponding to the logical channel to the base channel that a broken data block has been received and together with the length of the maximum data block that each service can send. In contrast, the receiving multiplexing / demultiplexing controller considers null traffic if the information bit is not broken, there is only one data block, the data block corresponding to the first service, and all are filled with '1'. The reception-side multiplexing / demultiplexing controller informs that when the information bits are not broken, an empty data block is received for services having no data block among services corresponding to a logical channel in the basic channel.

Transmission operation through additional channel of multiplexing / demultiplexing controller

When the multiplexing / demultiplexing controller generates additional channel information bits, it makes eight LTUs. The LTU has the same size as in Table 3. Since the LTU has a 16-bit CRC, the size of the maximum MuxPDU that can be carried in the actual LTU is 744 bits, 1512 bits, or 3048 bits depending on the transmission rate. In the present invention, since the additional channel 307.2 kbps is taken as an example, the maximum MuxPDU size is 744 bits.

The multiplexing / demultiplexing controller determines the transmission order of the respective services and the size of the data block in accordance with a prescribed quality of service guarantee rule (QoS). Next, the multiplexing / demultiplexing controller requests a data block from the RLP of each service according to the priority. For the data block to be transmitted on the additional channel, the multiplexing / demultiplexing controller generates an appropriately sized data block according to the size of the data block allowed by the MuxPDU and the remaining position of the LTU currently generated in Table 5 above. Should be requested.

As shown in Table 5, if the RLP processor generates a data block of 738 bits or a data block of a size that can fill the rest of the LTU, the multiplexing / demultiplexing controller identifies a service identifier to the corresponding service. Set the length indicator to '0'. In addition, if a 2-bit reserved field is added and a data block is inserted, a MuxPDU is generated. At this time, since the generated MuxPDU fits the payload of the LTU, one LTU is completed by generating and attaching a CRC to the MuxPDU.

In addition, as shown in Table 5 above, if the RLP generates a data block having a length of 729 bits or less, and the data block cannot fill all the remaining portions of the LTU, the multiplexing / demultiplexing controller provides a service. Set the identifier to the service and the length indicator to '1'. The multiplexing / demultiplexing controller sets the length of the entire MuxPDU, in which the service identifier, the length indicator, the 10-bit length field, and the data block are combined, in bytes. If the size of the entire MuxPDU is not indicated in bytes, the multiplexing / demultiplexing controller discards the data block.

The MuxPDUs generated as described above are sequentially inserted into the payload of the LTU, and the above process is repeated for the remaining portions. If no valid MuxPDU can be filled for the remaining part, the multiplexing / demultiplexing controller fills the remaining part with '0'. If there are more valid MuxPDUs but no appropriately sized data blocks, the multiplexing / demultiplexing controller creates a data block that can fill the remaining size and fills them all with '0' and then the service identifier '111' and the length indicator. Fills the payload after creating a MuxPDU with '0' and a 3-bit reserved field set. The LTU is completed by generating and attaching a CRC for the payload of the LTU generated by the above process.

When eight LTUs are generated through the above process, the multiplexing / demultiplexing controller puts all the generated eight LTUs into information bits in order. The multiplexing / demultiplexing controller fills all remaining 40 bit portions with '0' as shown in Table 3.

An example of information bits that can be obtained through the above process is shown in FIG. 6. 6 shows three LTUs. Referring to (a) of FIG. 6, the first LTU is a case where a 738-bit data block is received from the first service, and the service identifier is set to the first service 001 and the length indicator is set to '0'. Fill the LTU payload with bit 00. Referring to (b) of FIG. 6, the second LTU is a case in which a 330-bit data block is received from the second service, and the service identifier is set to the second service 010 and the length indicator is set to '1'. Set to 43 bytes (0000101011), which is the total length of the MuxPDU. The payload portion of the remaining 50 bytes of the LTU is a case where no service provides a data block. At this time, a fill MuxPDU is generated and inserted. Referring to (c) of FIG. 6, the third LTU is a case in which no service provides a data block when generating an LTU, and also generates and inserts a filling MuxPDU. In FIG. 6, when eight LTUs are collected to fill information bits and the remaining 40 bits are set to '0', generation of information bits is completed.

Receiving Operation through Additional Channel of Multiplexing / Demultiplexing Controller

The receiving side multiplexing / demultiplexing controller operates as follows for the information bits transmitted on the additional channel.

In the case of information bits using the LTU, as shown in Table 3, the LTU is classified in units of 760 bits at a transmission rate of 307.2 kbps. If there is no error in the information bits, the MuxPDU is identified for each LTU. Alternatively, if the information bit is in error, the CRC is checked for each LTU. At this time, MuxPDUs are distinguished for LTUs without errors in CRC checking. On the other hand, for each faulty LTU, inform all of the services corresponding to the logical channel to the additional channel that a broken data block has been received, together with the length of the maximum data block that each service can send to the LTU. Discard the information bit.

In the case of information bits for which LTU is not used, MuxPDUs are identified for all information bits. If there is an error in the information bit, the multiplexing / demultiplexing controller informs all services corresponding to the logical channel to the additional channel that a broken data block has been received, and the length of the maximum data block that each service can send in the logical transmission unit. Then together, then discard the information bits.

When the MuxPDU is distinguished with respect to the LTU or the information bit, the service identifier, the length indicator, and the data block of the MuxPDU must be delivered to a certain service through the length field, and the total length of the MuxPDU can be known. Therefore, the receiving side multiplexing / demultiplexing controller classifies the MuxPDU according to the length information of the MuxPDU from the front of the LTU or the information bit, and transfers the data block to the higher service according to the service identifier. If the service identifier is '111' or if the remaining portion of the LTU or information bits is large enough to not contain a valid MuxPDU, then the multiplexing / demultiplexing controller discards all remaining portions of the LTU or information bits.

According to the present invention performed by the RLP controller 131 as shown in FIG. 3 and FIG. 4 can be divided and described as follows.

Operation before data transmission of RLP controller

Before starting the operation, the RLP controller 131 sets the registers L_V (S) 132, L_V (N) 135, L_V (R) 136, and E 134 to 0 as shown in FIGS. 3 and 4. The RLP controller 131 also flushes the retransmission buffer 133, the NAK list 137, and the reorder buffer 138 before starting operation. RLP controller 131 finally turns off all timers related to retransmission.

The RLP controller 131 performs a reset process before transmitting data. The RLP controller 131 continues to forward the SYNC frame to the multiplex / demultiplex controller 140 as a data block. The RLP controller 131 receives a SYNC frame from the multiplexing / demultiplexing controller 140, receives a SYNC / ACK frame from the multiplexing / demultiplexing controller 140, and receives a SYNC / ACK frame from a physical channel frame. Continue to pass until not. When the RLP controller 131 receives the SYNC / ACK frame, the RLP controller 131 transmits an ACK frame to the multiplexing / demultiplexing controller 140. The RLP controller 131 continues to deliver an ACK frame until a physical channel frame is received at the multiplexing / demultiplexing controller 140 and is not an empty data block and is not a SYNC frame. The RLP controller 131 starts data transmission upon receiving an ACK frame. The RLP controller 131 may deliver the remaining frames other than SYNC, SYNC / ACK, and ACK frames to the multiplexing / demultiplexing controller 140.

Data transmission operation of the RLP controller

The RLP controller 131 uses a 20-bit serial number register L_V (S) 132 for data transmission. The RLP controller 131 determines a serial number to attach to a frame in the serial number register L_V (S) 132. The serial numbers all use an unsigned modulo operation of 2 ²⁰ . The serial number N in the (N + 1) modulo 2 ²⁰ when the - sequence number to the ^{(N +2 19 1) modulo 2} 20 are say greater than N, (N-2 ¹⁹⁾ from the modulo 2 ²⁰ (N - 1 Serial numbers up to modulo 2 ²⁰ are said to be less than N.

The RLP controller 131 may use a physical serial number to attach a value of a lower bit to an actual frame in the serial number register L_V (S) 132. In other words, in case of NAK frame, all 20 bits are used as serial number. In case of SYNC, SYNC / ACK, and ACK frame, only lower 8 bits are used as physical serial number. In the case of a data frame, the lower 17 bits are used as the physical serial number, and in the case of an idle frame or a busy frame, the lower 15 bits are used as the physical serial number.

The serial number register L_V (S) 132 increases by the number of data contained when a data frame containing data transmitted for the first time is created. That is, the L_V (S) 132 does not increase when data is already transmitted. In the following, the data frame containing the first transmitted data will be referred to as a new data frame, and the data frame containing the retransmitted data will be referred to as a retransmitted data frame, and when referring to both a new data frame and a retransmitted data frame, it will be called a data frame.

The new data frame transmitted in this way may have a unique 20 bit serial number for each byte. For example, if L_V (S) is S when transmitting N bytes of data, the first byte of data is S, the nth byte is (S + n-1) modulo 2 ²⁰ , and the last Nth byte is (S + N-1) modulo 2 has ²⁰ serial numbers. Upon sending the N bytes of new data, the RLP sets the L_V (S) to (S + N) modulo 2 ²⁰ .

The RLP controller 131 stores the newly transmitted data together with the serial number in the retransmission buffer 133 in preparation for the retransmission request from the receiver. When the RLP controller 131 requests retransmission from the receiving side, the RLP controller 131 should find and retransmit the data byte corresponding to the requested serial number in the retransmission buffer 133.

The RLP controller 131 makes a frame to be transmitted as follows. In the case of SYNC, SYNC / ACK, and ACK frames, as shown in (a) of FIG. 7, the lower 8 bits of L_V (S) are set as SEQ fields, the CTL field is set according to the frame type, and then the FCS field is set. 2-bit padding for byte alignment before pasting. The FCS field is a 16-bit frame check sequence made by a polynomial defined by RFC-1662. The FCS field is created for all preceding bits.

The RLP controller 131 uses a structure as shown in Table 8 in the case of a NAK frame.

NAK Frame field Length (bits) SEQ 8 CTL 6 NAK_TYPE 2 L_SEQ_HI 12 If NAK_TYPE is '00', the following fields are included: FIRST 20 LAST 20 If NAK_TYPE is '01', the following fields are included: NAK_UNIT 4 NAK_MAP_COUNT 2 The following fields are entered by NAK_MAP_COUNT + 1: NAK_MAP_SEQ 20 NAK_MAP 8 The following fields are included for any NAK_TYPE: PADDING_1 Variable length FCS 16 PADDING_2 Variable length

The RLP controller 131 makes a NAK frame as follows. The SEQ field of Table 8 is set to the lower 8 bits of N_V (S), and the L_SEQ_HI field is set to the upper 12 bits. In addition, the CTL field may be set to '110000' and the NAK_TYPE may be set to '00' or '01'.

When the NAK_TYPE is set to '00', the RLP controller 131 continuously inserts the first serial number requesting retransmission into the FIRST field and the last serial number into the LAST field. After the FIRST and LAST fields are filled, padding is performed to fill the FCS field with byte alignment, and the FCS field is filled. The FCS field is a 16-bit frame check sequence made by a polynomial defined by RFC-1662. The FCS field is created for all preceding bits. After entering the FCS field, the RLP controller 131 fills in '0' for the remainder of the data block.

When the NAK_TYPE is set to '01', the RLP controller 131 first sets a NAK_UNIT field. The NAK_UNIT field is a field indicating the extent of the serial number indicated by the NAK_MAP field. The NAK_UNIT field may be set as shown in Tables 8 and 9 below. Table 9 below shows a NAK_UNIT field set when an LTU is used, and Table 10 shows a NAK_UNIT field set when an LTU is not used.

NAK_UNIT field (if using LTU) Field value Serial number '0000' 19 '0001' 41 '0010' 90 '0011' 186 '0100' 378 '0101' 762 '0110'-'1111' reservation

NAK_UNIT field (if not using LTU) Field value Serial number '0000' 19 '0001' 42 '0010' 90 '0011' 186 '0100' 378 '0101' 762 '0110' 1530 '0111' 3066 '1000' 6138 '1001'-'1111' reservation

The RLP controller 131 fills the NAK MAP by the NAK_MAP_COUNT field value + 1. The NAK MAP inserts the first serial number into the NAK_MAP_SEQ field and indicates to NAK_MAP the serial numbers requesting retransmission in the NAK_UNIT unit. That is, if the NAK_UNIT unit determined by the NAK_UNIT field is U, and if the nth bit of the NAK_MAP bit is '1', (NAK_MAP_SEQ + (n-1) * U) modulo 2 ²⁰ at (NAK_MAP_SEQ + n * U-1) This means to retransmit the data corresponding to the serial number belonging to modulo 2 ²⁰ . The n value may have a value from 1 to 8.

The RLP controller 131 pads and fills the FCS field to fit the FCS field into byte alignment after inserting the NAK MAP. The FCS field is a 16-bit frame check sequence made by a polynomial defined by RFC-1662. The FCS field is created for all preceding bits. After entering the FCS field, the RLP fills in '0' for the remainder of the data block.

The RLP controller 131 may use a variable-length data frame as shown in FIG. 7B when transmitting data. If the data included in the variable length data frame is newly transmitted data, the RLP controller 131 sets the SEQ field to the lower 8 bits of L_V (S), and sets the S_SEQ_HI field to the lower 17 bits of L_V (S). Set to 9 bits. And set CTL field to 0 and REXMIT to 0. The LEN field of the variable length data frame indicates the length of the data portion in bytes. The RLP controller 131 fills in the remaining part of the remaining data block with '0' after inserting data.

If the data included in the variable length data frame is retransmitted data, the RLP controller 131 sets the SEQ field to the lower 8 bits of the serial number S of the first byte of the retransmitted data and sets the S_SEQ_HI field to the lower level of L_V (S). Set from 17 bits to 9 bits. And set CTL field to 0 and REXMIT to 1. The LEN field indicates the length of the data portion in bytes. The RLP fills the rest of the data block with '0'.

The RLP controller 131 sets the SEQ field of the variable-length data frame to the lower 8 bits of L_V (S) when there is no data to be sent or SYNC, SYNC / ACK, ACK, or NAK frames, and sets the S_SEQ_HI field to L_V (S). Set from the lower 17 bits to 9 bits. And set CTL field to 0 and REXMIT to 0. A data block filled with the LEN field as '0' and the rest with '0' can be transmitted.

The RLP controller 131 determines that the multiplexing / demultiplexing controller 140 does not have data or SYNC, SYNC / ACK, ACK, or NAK frames to request or send a data block having a length of 16 bits, 20 bits, or 32 bits. The idle frame as shown in (c) can be transmitted. To create the idle frame, the RLP controller 131 fills the SEQ field with the lower 15 bits of L_V (S). The RLP controller 131 sets the ISF field to 0 when there is no data to transmit and to 1 otherwise. The RLP controller 131 fills the remaining data block portion with '0'.

Data transmission operation through basic channel of RLP controller

The RLP controller 131 may send the frames described above even at a low data rate of the basic channel. However, when transmitting at 9.6 kbps of the basic channel, that is, when the size of the required data block is 171 bits, format A and format B frames as shown in FIGS. 8A and 8B, respectively, should be used.

The RLP controller 131 fills the TYPE field at the end with '01' when creating a format A frame. The RLP controller 131 should fill the INFORMATION field with the SYNC, SYNC / ACK, ACK, NAK, or variable length data frame. The RLP controller 131 fills the remaining INFORMATION field portion filled with the SYNC, SYNC / ACK, ACK, NAK, and variable length data frames with '0'.

The RLP controller 131 sets the SEQ field to the lower 8 bits of L_V (S) and sets the S_SEQ_HI field from the lower 17 bits to 9 bits of L_V (S) when the data included when creating the format B frame is newly transmitted data. Set it. The RLP controller 131 must be filled with 19 bytes of data. The RLP controller 131 sets a TYPE field to '10'.

If the data included when the format B frame is retransmitted, the RLP controller 131 sets the SEQ field to the lower 8 bits of the serial number S of the first byte of the retransmitted data, and sets the S_SEQ_HI field to the lower of L_V (S). Set from 17 bits to 9 bits. The RLP controller 131 must be filled with 19 bytes of retransmission data. The RLP controller 131 sets a TYPE field to '11'.

Data transmission operation through additional channel of RLP controller

The RLP controller 131 uses a supplemental channel data frame as shown in FIG. 9 when sending data on an additional channel or retransmitting data.

The RLP controller 131 sets the SEQ field to the lower 17 bits of L_V (S) and sets the REXMIT field to 0 when the data included when creating the additional channel data frame is newly transmitted data. The RLP controller 131 fills the data field with data to be sent.

If the data included when creating the additional channel data frame is data to be retransmitted, the RLP controller 131 sets the lower 17 bits of the serial number S of the first byte of the data to be retransmitted and sets the REXMIT field to '1'. do. The RLP controller 131 fills the DATA field with data to be retransmitted.

RLP controller data reception operation

The RLP controller 131 uses L_V (N) 135 and L_V (R) 136 which are 21-bit serial number registers when receiving data. Serial number register L_V (R) 136 indicates the serial number of the next new data byte to be received, and serial number register L_V (N) 135 indicates the serial number of the next data byte to be received next in the consecutively received data bytes. . That is, the RLP controller 131 may deliver data to the upper link protocol only when a data byte having a serial number stored in L_V (N) arrives.

The RLP controller 131 should have a NAK list 137 as shown in FIG. Each entry of the NAK list 137 has a 21-bit serial number and a data byte corresponding to the serial number, and has a retransmission timer and an abort timer. When the retransmission data arrives, the RLP controller 131 looks for an entry whose 17-bit serial number of the received data byte matches the lower 17 bits of the stored NAK entry.

When the RLP controller 131 receives a frame containing data, the RLP controller 131 obtains the serial number S of the received frame as follows. First, if the received frame contains the 17-bit SEQ field, the RLP controller 131 sets this value as the serial number S. If the second received frame contains an 8-bit SEQ field and a 9-bit S_SEQ_HI field, the 17-bit value prefixed with the value of L_SEQ_HI and the SEQ value after the sequence number S is used.

When the RLP controller 131 receives a frame containing data, the RLP controller 131 calculates the serial number L_SEQ of the first byte of the received data as follows.

If the first received frame contains the retransmitted data, the RLP controller 131 searches for an entry whose serial number matches the oldest entry of each entry of the NAK list 137. The RLP controller 131 finds whether the lower 17-bit portion of the 20-bit serial number in the NAK entry 137 is equal to the serial number S value of the received frame. If there is the same NAK entry, the RLP controller 131 sets the 20-bit serial number stored in the NAK entry as the serial number L_SEQ value of the first byte of data received. Alternatively, if there is no such NAK entry, the received frame is discarded.

If the second received frame contains newly transmitted data, the RLP controller 131 converts the serial number L_SEQ value of the first byte of the received data with the serial number S of the received frame as follows. Calculate through.

L_SEQ = {L_V (R) + [2 ¹⁷ + S-L_V (R)] modulo 2 ¹⁷ } modulo 2 ²⁰

The RLP controller 131 assigns a serial number of each data byte of the received data frame, starting from L_SEQ, in order from the front. That is, the n th data byte has a value of (L_SEQ + n-1) as the serial number L, and thus the first byte has a L_SEQ value as the serial number.

If the received data byte is a newly received data byte instead of the data byte of the received data frame, the RLP controller 131 performs the following operations in the order of the respective serial numbers.

If the serial number L of the first received data byte is equal to L_V (R), when L_V (R) is equal to L_V (N), the RLP controller 131 simultaneously increases the L_V (R) and L_V (N), Modulo operation for 2 ²⁰ . The RLP controller 131 transfers the data byte always received to the upper link protocol. However, the serial number L sets the VS_SEQ_HI field from the lower 17 bits of the L_V (S) to 9 bits. The CTL field is set to 0 and REXMIT is set to 0. If not equal to L_V (R), the RLP controller 131 increases L_V (R) and modulo operation for 2 ²⁰ . The RLP controller 131 stores the received data byte in the reordering buffer.

If the serial number L of the second received data byte is greater than L_V (R), the RLP controller 131 may request retransmission for the data byte having (L-1) modulo 2 ²⁰ in the L_V (R). Make an entry for each data byte in the NAK list. Each entry will have a 20-bit serial number for the corresponding data byte. The RLP controller 131 stores the received data byte in the reordering buffer and sets L_V (R) to (L + 1) modulo 2 ²⁰ .

The RLP controller 131 performs the following operations on the data bytes of the received data frame in the order of their respective serial numbers.

First, if the serial number L of the received data byte is less than L_V (N), the RLP controller 131 discards the received data byte.

Second, if the serial number L of the received data byte is greater than or equal to L_V (N) and less than L_V (R), the RLP controller 131 stores the received data byte in the reordering buffer. At this time, if the serial number L value is equal to L_V (N), the RLP controller 131 has a serial number capable of successively transferring data bytes stored in the reordering buffer 138 from the data byte having the L_V (N) value as the serial number. Passes up to data bytes to the upper link protocol. If the serial number of the last data byte transmitted in the process is LAST, the RLP controller 131 sets L_V (N) to (LAST + 1) modulo 2 ²⁰ .

Third, if the serial number L of the received data byte is larger than L_V (R), the RLP controller 131 requests retransmission for the data byte having (L-1) modulo 2 ²⁰ in the serial number L_V (R). Make an entry for each data byte in NAK list 137. Each entry will have a 21 bit serial number for the corresponding data byte. In addition, the RLP controller 131 stores the received data byte in the reordering buffer 138 and sets L_V (R) to (L + 1) modulo 2 ²⁰ .

On the other hand, when receiving the idle / busy frame, the RLP controller 131 sets the serial number S as a SEQ field value, and then calculates the serial number L_SEQ as shown in Equation 2 below.

L_SEQ = {L_V (R) + [2 ¹⁵ + S-L_V (R)] modulo 2 ¹⁵ } modulo 2 ²⁰

If the serial number L_SEQ of the received idle frame is greater than L_V (R), the RLP controller 131 requests NAK to request retransmission of the data byte having (L_SEQ-1) modulo 2 ²⁰ in the serial number L_V (R). Make an entry for each data byte in the list. Each entry will have a 20 bit serial number for the corresponding data byte. The RLP sets L_V (R) to (L + 1) modulo 2 ²⁰ .

When receiving the NAK frame, the RLP controller 131 sets the serial number L_SEQ to a 20-bit value prefixed with a 12-bit L_SEQ_HI field value and followed by an 8-bit SEQ field value.

The RLP controller 131 performs the following operation on the received NAK frame serial number L_SEQ.

If the serial number L_SEQ of the first received NAK frame is greater than L_V (R), the RLP controller 131 may request a retransmission for the data byte having (L_SEQ-1) modulo 2 ²⁰ in the serial number L_V (R). Make an entry for each data byte in the list. Each entry will have a 20 bit serial number for the corresponding data byte. The RLP controller 131 sets L_V (R) to (L + 1) modulo 2 ²⁰ .

Secondly, the RLP controller 131 retransmits data bytes requested in the NAK frame. If the retransmission request is made for a data byte having a serial number larger than L_V (S), the RLP controller 131 performs a reset process.

When the RLP controller 131 informs that the multiplexed / demultiplexed controller 140 receives a broken data block and informs the size of the data block, the RLP controller 131 estimates the maximum value M of data bytes that can be received as follows. If the broken data block was sent on the base channel, M is 19 bytes. On the contrary, if the broken data block is transmitted to the additional channel, M is obtained by subtracting 17 bits from the length L bits of the broken data block announced by the multiplexing / demultiplexing controller 140 and dividing by 8 again. For example, if you tell the length of a broken data block as 737 bits, think of 90 bytes as M minus 17 bits.

When the RLP controller 131 obtains the maximum number of data bytes M of the broken data block, the RLP controller 131 adds this value to the value stored in the register E 134 and stores the value again in the register E 134. If the added value is greater than or equal to 2 ₂₁ , the RLP controller 131 performs a reset process.

Operation after receiving data of RLP controller

The RLP controller 131 performs the following tasks after processing all received frames.

When the multiplexing / demultiplexing controller 140 says that no frame is received from the RLP controller 131, an idle / busy frame having an ISF field set to 0, or a newly transmitted data frame is received, the RLP controller 131 Starting with the oldest entry in NAK Listing 137, do the following:

First, if the NAK entry has not yet expired after the cancellation timer has been set and already contains three serial numbers included in the NAK entry, the RLP controller 131 reduces the value of the cancellation timer by one. If the cancellation timer value becomes 0, the RLP controller 131 performs the following operation. If the RLP controller 131 has already received the retransmission data byte corresponding to the serial number of the NAK entry, the RLP controller 131 deletes the NAK entry. In contrast, the RLP controller 131 has a serial number that the NAK entry already has.

If the retransmission data byte corresponding to the call has not been received, the RLP controller 131 assumes that the data byte corresponding to the serial number of the NAK entry has not been received and is larger than the serial number of the NAK entry stored in the reordering buffer 138. It forwards the received data bytes that can be sent to the upper link protocol to the upper link protocol. The RLP controller 131 sets L_V (N) as the serial number of the data byte waiting for the next reception.

Secondly, if the NAK entry has not yet expired after the retransmission timer is set and already contains two serial numbers included in the NAK entry in the NAK, the RLP controller 131 reduces the value of the cancellation timer by one. If the retransmission timer value is 0, the RLP controller 131 performs the following operation. If the RLP controller 131 has already received the retransmission data byte corresponding to the serial number of the NAK entry, the RLP controller 131 deletes the NAK entry. Alternatively, if the RLP controller 131 has not already received a retransmission data byte corresponding to the serial number of the NAK entry, the RLP controller 131 sets the cancellation timer of the NAK entry to an appropriate value. The RLP controller 131 includes a serial number of the NAK entry in three NAK frames to be transmitted next.

The RLP controller 131 sets the retransmission timer of the NAK entry to an appropriate value for the NAK entries to be added, and transmits the two NAK frames including the serial number of the NAK entry.

As described above, the present invention proposes a data byte-based serial numbering method, which enables the radio link protocol to generate a variable length frame.

As described above, the present invention proposes a data byte-based serial numbering method so that the radio link protocol can generate a variable length frame.

Claims (21)

A plurality of RLP processors each of which receives a data block of a size corresponding to a frame request, occurs as an RLP frame, and includes an identifier indicating that the RLP frame is new / retransmitted; A multiplex processor for receiving the RLP frame from at least one RLP controller of the RLP processors to generate multiplexed frame information having a variable length; And a physical layer processor configured to transmit the multiplexed frame information through a physical channel. The data transmission apparatus according to claim 1, wherein the RLP processor generates an RLP frame by setting the identifier upon request for retransmission at the receiving end, and generates a new RLP frame that resets the identifier. The multiplexing controller of claim 2, wherein the multiplexing controller selects RLP controllers according to a priority of a service among the plurality of RLP processors, requests transmission of an RLP frame to the selected RLP controller, and multiplexes the received RLP frames. A data transmission apparatus of a mobile communication system for generating a frame. 4. The apparatus of claim 3, wherein the multiplexed frame includes a service identifier, length information, and the RLP frames. The apparatus of claim 4, wherein the multiplexed frame is transmitted through a basic channel. The apparatus of claim 4, wherein the multiplexed frame is transmitted through an additional channel. 4. The apparatus of claim 3, wherein said RLP processor further comprises a register for storing a serial number for said RLP frame. 8. The apparatus of claim 7, further comprising a retransmission buffer for storing the RLP frame transmitted by the RLP processor in correspondence with the serial number. 8. The data transmission apparatus of claim 7, wherein the RLP processor reads and retransmits a data block corresponding to the serial number requested in the retransmission request from the retransmission buffer. A physical layer processor configured to receive information received through a physical channel; A demultiplexing processor for demultiplexing the information into at least one data block and separating the information into RLP frames; And a RLP processor for processing a corresponding unique RLP frame transmitted from the demultiplexing processor and requesting retransmission when an error occurs. The apparatus of claim 10, wherein the RLP processor generates and transmits a NAK frame requesting retransmission when an error occurs in the received RLP frame. The data receiving apparatus of claim 11, wherein the demultiplexing processor demultiplexes the at least one RLP frame using a data rate and header information included in the information bits transmitted through the basic channel. The apparatus of claim 12, wherein the demultiplexing processor is configured to demultiplex the RLP frame using a service identifier included in each logical transmission unit of the information when the information using a logical transmission unit is received in an additional channel. And a data receiving device of a mobile communication system for transferring to a corresponding RLP processor. The RLP processor of claim 13, wherein the demultiplexing processor is configured to demultiplex a data block using a service identifier included in the information when the information not used by a logical transmission unit is received through an additional channel. A data receiving device of a mobile communication system for transmitting to. Transmitter, A plurality of RLP processors each of which receives a data block of a size corresponding to a frame request, generates and transmits an RLP frame, and includes an identifier indicating that the RLP frame is new / retransmitted, and at least one of the RLP processors A transmitter configured to receive the RLP frame from an RLP controller and generate multiplexed frame information having a variable length, and a physical layer processor to transmit the multiplexed frame information through a physical channel; Receiver, A physical layer processor for receiving information received through the physical channel, a demultiplexing processor for demultiplexing the information into at least one data block, and separating the information into RLP frames, and a corresponding unique RLP delivered from the demultiplexing processor. A data communication apparatus of a mobile communication system, comprising a RLP processor for processing a frame and requesting retransmission when an error occurs. Generating a RLP frame including an identifier indicating that a plurality of RLP processors each receive a data block of a size corresponding to a frame request and indicate a new / retransmission; Receiving the RLP frame from at least one RLP controller of the RLP processors to generate multiplexed frame information having a variable length; And transmitting the multiplexed frame information through a physical channel. The method of claim 16, wherein generating the RLP frame comprises: And generating a RLP frame by setting the identifier at the reception side upon request of a retransmission, and generating a new RLP frame by resetting the identifier. The method of claim 17, wherein the generating of the multiplexed frame comprises: A method of transmitting data in a mobile communication system for selecting RLP controllers according to a priority of a service among the plurality of RLP processors, requesting transmission of an RLP frame to the selected RLP controller, and multiplexing the received RLP frames to generate the multiplexed frame. . Receiving information received through a physical channel; Demultiplexing the information into at least one data block and separating the information into an RLP frame; And processing a corresponding unique RLP frame among the demultiplexed RLP frames and requesting retransmission when an error occurs. The method of claim 19, wherein processing the RLP frame comprises: And generating and transmitting a NAK frame requesting retransmission when an error occurs in the received RLP frame. Generating and transmitting a plurality of RLP processors, each of which receives a data block of a size corresponding to a frame request, into an RLP frame including an identifier indicating that it is new / retransmitted, and from at least one RLP controller of the RLP processors; Receiving the RLP frame to generate multiplexed frame information having a variable length, and transmitting the multiplexed frame information through a physical channel; Receiving information received through the physical channel, demultiplexing the information into at least one data block, separating the information into RLP frames, and processing a corresponding unique RLP frame among the demultiplexed RLP frames. And a reception process including a process of requesting retransmission when an error occurs.