Patent Description:
The UMTS (Universal Mobile Telecommunication Service) system is a <NUM>rd generation asynchronous mobile communication system which is based on European mobile communication systems, that is, GSM (Global System for Mobile Communications) and GPRS (General Packet Radio Services), and employing a WCDMA (Wideband Code Division Multiple Access) scheme.

The 3GPP (<NUM>rd Generation Partnership Project) responsible for the UMTS standardization is currently developing LTE (Long Term Evolution) as a next generation UMTS system. LTE, with an aim of commercialization by around <NUM>, is technology for implementing high-speed packet-based communication at data rates of about 100Mbps. To this end, various plans are under discussion, including a plan to reduce the number of nodes located on a communication path by simplifying a network architecture, a plan to approximate wireless protocols to a radio channel as close as possible, and so forth.

<FIG> illustrates an example of the structure of a next generation mobile communication system. <FIG> illustrates a system structure based on the UMTS system.

Referring to <FIG>, evolved radio access networks (hereinafter referred to as "E-RAN") <NUM> and <NUM> have a simplified two node structure of evolved Node Bs (hereinafter referred to as "ENB" or "Node B") <NUM>, <NUM>, <NUM>, <NUM> and <NUM>, and anchor nodes <NUM> and <NUM>, as illustrated therein. User equipment (UE) <NUM> is connected to an internet protocol (IP) via the E-RANs <NUM> and <NUM>.

The ENBs <NUM> to <NUM> corresponds to an existing Node B of the UMTS system, and is connected to the UE <NUM> over a radio channel. Unlike an existing Node B, the ENBs <NUM> to <NUM> perform more complex functions. In LTE, all user traffic, including a real-time service through an IP, such as a VoIP (Voice over IP) service, is serviced via a shared channel, and the ENB performs scheduling after collecting situation information of UEs.

In order to enable a maximum transmission speed of 100Mbps, LTE is expected to employ an orthogonal frequency division multiplexing (OFDM) scheme as radio access technology with a bandwidth of <NUM>. The LTE is also expected to apply an adaptive modulation and coding (AMC) scheme in which a modulation scheme and a channel coding rate are adaptively determined to the channel state of a UE.

Similar to HSDPA (High Speed Downlink Packet Access) or E-DCH (Enhanced-uplink Dedicated Channel), LTE uses HARQ (Hybrid Automatic Retransmission Request) between the ENBs <NUM> to <NUM> and the UE <NUM>. However, since various levels of quality of service (QoS) requirements cannot be satisfied by the HARQ alone, an upper layer may perform a separate ARQ (outer-ARQ), which also takes place between the UE <NUM> and the ENBs <NUM> to <NUM>.

<FIG> illustrates the structure of an LTE protocol. As illustrated in <FIG>, RLC (Radio Link Control) entities <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM> are be established for each upper layer <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM>.

The RLC entity resizes upper layer data to an appropriate size, and performs an automatic retransmission request (ARQ) operation for the resized data. The data resized to an appropriate size by the RLC entity is referred to as an RLC protocol data unit (PDU).

In LTE, transmitting (Tx) RLC entities <NUM>, <NUM> and <NUM> construct RLC PDUs <NUM> in such a manner as to have a size transmittable in an MAC (Media Access Control) layer at a corresponding point in time. Thus, the size of an RLC PDU <NUM> may vary with a channel situation, a resource allocation situation, or the like.

If a lower layer notifies a Tx RLC entity <NUM>, <NUM> or <NUM> of the size of an RLC PDU to be transmitted in the next transmission time interval (TTI), the Tx RLC entity <NUM>, <NUM> or <NUM> generates an RLC PDU by splitting or joining upper layer data in conformity with the notified size and inserting an RLC PDU header. The RLC PDU header may include serial number information, etc..

A Tx MAC entity <NUM> multiplexes RLC PDUs submitted from the Tx RLC entities <NUM>, <NUM> and <NUM> to thereby generate an MAC PDU <NUM>. Since RLC PDUs generated by several RLC entities may be multiplexed into one MAC PDU, multiplexing information for the RLC PDUs is inserted into an MAC PDU header. Information included in the MAC PDU header will be described in detail below with reference to <FIG>.

The MAC PDU generated by the Tx MAC entity <NUM> passes through an HARQ process, and then is transmitted to a receiving side.

A packet actually transmitted over a radio channel is also referred to as a transport block <NUM>. However, one MAC PDU is mapped to one transport block, that is, these two are different only in name and actually denote the same object. In the following description, a transport block and an MAC PDU will be used interchangeably.

For an HARQ operation, information necessary for transport block decoding is transmitted together with a separate control signal when a transport block <NUM> is transmitted from a Tx HARQ entity <NUM>. This information includes information indicating the size a transport block (TB size) <NUM>, information on an MCS (Modulation and Coding Scheme) applied to the transport block (MCS Info) <NUM>, etc..

Since a transport block and an MAC PDU denote the same object, the information <NUM> indicating a TB size is not different from information indicating the size of an MAC PDU.

Upon successfully receiving a transport block <NUM>, a receiving (Rx) HARQ entity <NUM> forwards an MAC PDU to an Rx MAC entity <NUM>. The Rx MAC entity <NUM> separates an RLC PDU from the forwarded MAC PDU by using information included in an MAC PDU header, and forwards the separated RLC PDU to an appropriate Rx RLC entity <NUM>, <NUM> or <NUM>.

As discussed above, one of the important operations of an MAC layer is to multiplex RLC PDUs generated by several RLC entities into one MAC PDU and demultiplex RLC PDUs from an MAC PDU.

<FIG> illustrates the structure of an MAC PDU. Referring to <FIG>, upon receiving an RLC PDU from an RLC entity, a Tx MAC entity inserts a logical channel ID (LID) and a length (LEN) of the RLC PDU into an MAC PDU header.

Since one LID and one LEN per RLC PDU are inserted, as many LIDs and LENs as RLC PDUs are inserted when a plurality of RLC PDUs are multiplexed into one MAC PDU.

Information included in an MAC PDU header is usually located in the front of an MAC PDU, and thus LIDs and LENs match to RLC PDUs in their order within the header. In other words, the first LID <NUM> and the first LEN <NUM> within an MAC PDU header are information regarding the first RLC PDU <NUM>, and the second LID <NUM> and the second LEN <NUM> are information regarding the second RLC PDU <NUM>.

For a physical layer operation, the overall length of an MAC PDU is transferred to a receiving side through a separate control signal. Since the overall length of an MAC PDU is a value quantized according to given criteria, padding <NUM> may also be used in some cases. The padding refers to filling specific bits (usually <NUM>) in remaining parts within a packet so as to achieve the byte-aligned length of a data packet when the data packet is generated.

In some cases, an LEN value indicating the length of an RLC PDU is unnecessary information because the overall length of an MAC PDU is given. For example, if only one RLC PDU is accommodated in an MAC PDU, it is highly probable that the length of the RLC PDU is equal to the length of the MAC PDU, excluding that of an MAC PDU header.

A VoIP packet consists of an IPIUDPIRTP header and a VoIP frame, the IP/UDP/RTP header is compressed to about <NUM> to <NUM> bytes through a header compression protocol called ROHC (Robust Header Compression), and the length of the VoIP frame is always constant within a given codec rate. In other words, the length of the VoIP packet remains within a certain range, and thus it is more efficient to use a predetermined value rather than absolute information, such as LEN. Since the length of an RLC PDU in LTE can contain several thousand bytes, an LEN field indicating the length of an RLC PDU has a length of about <NUM> bits. In contrast with this, since the maximum length of an RLC PDU accommodating a VoIP packet is only several tens of bytes, and the length of a frequently occurring packet can be predicted, it is possible to express most lengths by even small-sized information with a length of about <NUM> or <NUM> bits. If a VoIP operates by means of a codec with a variable codec rate, such as AMR (Adaptive Multi-Rate), the number of possible packet lengths significantly increases. Thus, an SID (Size Index), which is collapsed information indicating the length of an RLC PDU, may require many more bits. However, when an MAC PDU header for a VoIP is designed in such a manner that the size of an SID coincides with the operation of the AMR codec, it is possible that the length of the MAC PDU header becomes too large. In a high-speed communication system, such as LTE, an MAC PDU header is byte-aligned, and thus it is grossly inefficient to determine the size of an SID by taking all circumstances into consideration because a one- or two-bit increase in the size of an SID may cause one-byte increase in the length of an MAC PDU header. The publication titled "Universal Mobile Telecommunications System (UMTS); Medium Access Control, MAC, protocol specification (3GPP TS <NUM> version <NUM>. <NUM> Release <NUM>) ETSI TS <NUM><NUM>" dated March <NUM>, <NUM> refers to interaction between the MAC layer and other layers in terms of primitives, wherein the primitives represent the logical exchange of information and control between the MAC layer and other layers. In the UE for the uplink, all MAC PDUs delivered to the physical layer within one TTI are defined as transport block sets, TBS. It consists of one or several transport blocks, each containing one MAC PDU. The transport blocks shall be transmitted in the order as delivered from RLC. When multiplexing of RLC PDUs from different logical channels is performed on MAC, the order of all transport blocks originating from the same logical channel shall be the same as the order of the sequence delivered from RLC. The order of the different logical channels in a TBS is set by the MAC protocol. <CIT> refers to a length indicator for a protocol data unit in a wireless communications protocol. A data structure for a layer protocol data unit in a wireless communications protocol has a sequence number region that holds a sequence number for indicating a sequential ordering of a first PDU in a stream of PDUs. A length indicator array follows the sequence number field, and has at least a final length indicator. The final length indicator is the last length indicator in the length indicator array and is n bits in length. An SDU array follows the length indicator array. The SDU array has at least a final SDU data block. The final SDU data block is the last SDU in the SDU array. The final length indicator indicates a position of the end of the final SDU block within the first PDU. Finally, a padding area is after the final SDU block. The padding area fills the remainder of the first PDU. The padding area is less than n bits in length and carries no layer SDU data.

Accordingly, the present invention has been made to solve the at least the above-mentioned problems occurring in the prior art.

The above and other aspects, features and advantages of the present invention will be more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which:.

Hereinafter, exemplary embodiments of the present invention will be described with reference to the accompanying drawings. It should be noted that the similar components are designated by similar reference numerals although they are illustrated in different drawings. Also, in the following description, a detailed description of known functions and configurations incorporated herein will be omitted when it may obscure the subject matter of the present invention. Further, it should be noted that only parts essential for understanding the operations according to the present invention will be described and a description of parts other than the essential parts will be omitted in order not to obscure the gist of the present invention.

In the specification, the terms "MAC PDU" and "RLC PDU" will appear frequently. As used herein, the term "MAC PDU" means a data unit into which data units of an upper layer are multiplexed by a layer responsible for multiplexing, and the term "RLC PDU" means a data unit provided by an upper unit of the layer responsible for multiplexing.

In LTE, since a receiving side knows the size of an MAC PDU through separate control information, size information of an RLC PDU accommodated in the MAC PDU does not need to be included in a header when the length of the RLC PDU can be deduced from the size of the MAC PDU.

This is obviously the case where only one RLC PDU is accommodated in an MAC PDU, and the length of the RLC PDU is equal to the size of the MAC PDU excluding a header thereof.

In a first non-claimed embodiment of the present invention, a Tx MAC entity does not include information indicating the size of an upper layer data unit (or RLC PDU) in an MAC PDU header if the following two conditions are satisfied:.

Since an RLC layer variably sets the length of an RLC PDU, the second condition is satisfied when data, the amount of which is greater than the size of an MAC PDU, is stored in an RLC buffer.

<FIG> illustrates the structure of an MAC PDU according to the first embodiment of the present invention.

Referring to <FIG>, an MAC PDU header <NUM> includes F fields <NUM> and <NUM>, LID fields <NUM>, <NUM> and <NUM>, and LEN fields <NUM> and <NUM>. Although not illustrated in the drawing, other fields may be included in the MAC PDU header, if necessary.

RLC PDUs <NUM>, <NUM> and <NUM> are located next to the MAC PDU header, and general padding <NUM> or byte aligning padding <NUM> and <NUM> for byte-aligning the MAC PDU is located next to the RLC PDUs.

In the present invention, the MAC PDU is divided into three parts, that is, an MAC PDU header part <NUM>, an MAC PDU data part <NUM>, and a padding part <NUM>.

The MAC PDU header part <NUM> is a space in which the F, LID and LEN fields are accommodated. The MAC PDU data part <NUM> is a space in which upper layer data units, such as RLC PDUs, are accommodated. The padding part <NUM> is a space in the rear of the MAC PDU, which is filled with dummy bits when the size of the MAC PDU does not correspond to the sum of the sizes of the MAC PDU header part, the MAC PDU data part and the padding part.

The respective elements of the MAC PDU header part <NUM>, the MAC PDU data part <NUM> and the padding part <NUM> will be described in detail.

The F fields <NUM> and <NUM> contain <NUM>-bit information.

If the F field has a value of <NUM> (F field <NUM>), only one RLC PDU <NUM> is accommodated in the MAC PDU data part <NUM>. Further, since the MAC PDU data part is filled with the RLC PDU as fully as possible, byte aligning padding <NUM> may exist in the padding part <NUM>, but general padding does not exist. In addition, an LEN field indicating the length of the RLC PDU does not exist in the MAC PDU header part <NUM>.

If the F field has a value of <NUM> (F field <NUM>), LEN fields <NUM> and <NUM> indicating the lengths of RLC PDUs exist in the MAC PDU header part <NUM>.

The LID fields <NUM>, <NUM> and <NUM> includes the identifier of a logical channel to which an RLC PDU belongs or the identifier of an RLC entity in which an RLC PDU occurs. An Rx MAC entity forwards a corresponding RLC PDU to an appropriate RLC entity by making reference to the LID field.

The LEN fields <NUM> and <NUM> are fields indicating the length of an RLC PDU. In the present invention, although it is assumed that the length of an RLC PDU is expressed in units of bytes, other units may be used.

The RLC PDUs <NUM>, <NUM> and <NUM> means upper layer data of an MAC layer. An RLC layer generates an RLC PDU framed in an appropriate size under instructions from an MAC layer, and then submits it to the MAC layer.

The byte aligning padding <NUM> and <NUM> are dummy data for correcting a difference between the size of an MAC PDU, signaled through a control channel, and the actual size of the MAC PDU, and has a size of <NUM> bit to <NUM> bits.

The size of an MAC PDU, signaled through a control channel, is in units of bits, and the size of an MAC PDU header is most likely to be in units of bits. However, since the length of an RLC PDU is in units of bytes, the sum of the sizes of an MAC PDU header (in bits) and RLC PDUs (in bytes) may not correspond to the size of an MAC PDU, signaled through a control channel. For example, when the size of an MAC PDU, signaled through a control channel, is <NUM> bits, the size of an MAC PDU header is <NUM> bits, and the length of an RLC PDU is <NUM> bytes, there is a difference of <NUM> bits between the actual size of the MAC PDU and the size of the MAC PDU, signaled through a control channel.

In this way, if a part constituting an MAC PDU has a size in units of bytes when the size of the MAC PDU is signaled in units of bits, padding between <NUM> bit and <NUM> bits unavoidably occurs. In the specification, such padding occurring within <NUM> byte is referred to as "byte aligning padding".

Since the byte aligning padding always has a value of <NUM> bit to <NUM> bits, and can be deduced by subtracting the sizes of an RLC PDU and an MAC PDU header from the overall size of an MAC PDU, it is not necessary to separately signal whether or not the byte aligning padding exists.

There is a case where general padding is used in addition to byte aligning padding. For example, when the size of a transmittable MAC PDU is greater than that of data stored in an RLC buffer, the size of an MAC PDU must be adjusted to the size of the transmittable MAC PDU by filling dummy data. As an example, if the size of an MAC PDU to be transmitted at any point in time is <NUM> bits, but the total sum of the sizes of data stored in an RLC buffer is only <NUM> bits, the remaining <NUM> bits of the MAC PDU must be filled with padding <NUM>. In the following description, the general padding will be referred to as "padding", and the byte aligning padding will be referred to as "byte aligning padding" in its entirety.

In the first embodiment of the present invention, the structure of an MAC PDU header varies with the value of an F field.

When the F field has a value of <NUM>, that is, when only one RLC PDU is accommodated in an MAC PDU, general padding does not exist, and only byte aligning padding exists, an LEN field is not inserted into an MAC PDU header.

When the F field has a value of <NUM>, that is, when a plurality of RLC PDUs are accommodated in an MAC PDU or when only one RLC PDU is accommodated in an MAC PDU, and yet general padding exists, LEN fields are inserted into an MAC PDU header.

<FIG> illustrates the operation of a Tx MAC entity according to the first embodiment of the present invention.

Referring to <FIG>, in step <NUM>, the Tx MAC entity begins to generate an MAC PDU. That is, if a base station scheduler allocates transmission resources to the Tx MAC entity, the Tx MAC entity determines RLC entities, which are to transmit data through the transmission resources, by considering the priorities of the RLC entities, etc. Further, the Tx MAC entity determines the amount of data to be transmitted by each of the RLC entities, and instructs each of the RLC entities to generate an RLC PDU having a size corresponding to the determined amount. If RLC PDUs arrive from the RLC entities, the Tx MAC entity multiplexes the RLC PDUs into an MAC PDU.

In step <NUM>, the Tx MAC entity determines the number of the RLC PDUs accommodated in the MAC PDU, the generation of which is in progress.

If it is determined that only one RLC PDU is accommodated in the MAC PDU, the Tx MAC entity proceeds to step <NUM>, and otherwise proceeds to step <NUM>. Only one RLC PDU is accommodated in the MAC PDU when there is only one RLC entity having data to be transmitted at a corresponding point in time, only data possessed by an RLC entity with the highest priority is transmitted because the amount of allocated transmission resources is insufficient, and so forth.

In step <NUM>, the Tx MAC entity determines if the MAC PDU, the generation of which is in progress, satisfies the following conditions: the Tx MAC entity determines (<NUM>) if there is no padding because the length of the RLC PDU is sufficiently large, (<NUM>) if the last byte of the RLC PDU corresponds to that of the MAC PDU, or (<NUM>) if the length of the RLC PDU is equal to a value obtained by subtracting the sizes of an MAC PDU header and byte aligning padding from the size of the MAC PDU.

The Tx MAC entity proceeds to step <NUM> if any one of the conditions is satisfied, and proceeds to step <NUM> if none of the conditions are satisfied.

In step <NUM>, the Tx MAC entity sets the value of an F field to <NUM>, and then proceeds to step <NUM>. In step <NUM>, the Tx MAC entity inserts LEN fields, each indicating the length of each of the RLC PDUs, into the MAC PDU header, and then proceeds to step <NUM>.

In step <NUM>, the Tx MAC entity sets the value of an F field to <NUM>, and then proceeds to step <NUM> via step <NUM> in which the Tx MAC entity does not insert an LEN field indicating the length of the RLC PDU into the MAC PDU header.

In step <NUM>, the Tx MAC entity inserts byte aligning padding into the rear portion of the MAC PDU to thereby complete the MAC PDU, and then proceeds to step <NUM>. In step <NUM>, the Tx MAC entity submits the completed MAC PDU to a lower layer.

<FIG> illustrates the operation of an Rx MAC entity according to the first embodiment of the present invention.

Referring to <FIG>, if the Rx MAC entity receives an MAC PDU from a lower layer in step <NUM>, the Rx MAC entity determines the value of an F field in step <NUM>. The Rx MAC entity proceeds to step <NUM> if it is determined that the F field has a value of <NUM>, and proceeds to step <NUM> if it is determined that the F field has a value of <NUM>.

In step <NUM>, the Rx MAC entity separates RLC PDUs from the MAC PDU by using the values of LEN fields accommodated in an MAC PDU header.

The following is a process of separating the RLC PDUs from the MAC PDU.

First, the Rx MAC entity identifies a point where a header part and a data part of the MAC PDU are separated from each other. That is, the Rx MAC entity sequentially analyzes LEN fields in the MAC PDU header part, and repeatedly subtracts the size corresponding to the LEN field from the overall size of the MAC PDU. If the remaining size of the MAC PDU after the repeated subtractions is less than the minimum size of RLC PDUs, the Rx MAC entity recognizes a corresponding LEN as the last LEN field.

The Rx MAC entity separates the MAC PDU header part from the MAC PDU data part on the basis of the last LEN field, separates the RLC PDUs from the MAC PDU data part by making reference to the LEN fields in the MAC PDU header part, and then proceeds to step <NUM>.

In step <NUM>, the Rx MAC entity forwards the RLC PDUs to appropriate RLC entities by making reference to the values of LID fields in the MAC PDU header part.

The fact that the F field has a value of <NUM> means that only one RLC PDU is accommodated in the MAC PDU, the RLC PDU fills the MAC PDU up to its last byte, and an LEN field indicating the length of the RLC PDU is not included in the MAC PDU header. Thus, in step <NUM>, the Rx MAC entity calculates the length of the RLC PDU by using Equation (<NUM>): <MAT>.

In Equation (<NUM>), the function Floor[x, y] is defined as an integer obtained by rounding down x by the nearest multiple ofy.

Further, the MAC PDU size denotes the overall size of a received MAC PDU, which is signaled through a separate control channel. In Equation (<NUM>), it is assumed that the overall size of the MAC PDU is signaled in units of bits.

Further, the MAC header size denotes the size of an MAC PDU header, expressed in bits. When only one RLC PDU is accommodated in an MAC PDU, and the RLC PDU fills the MAC PDU up to its last byte, the MAC PDU header does not include an LEN field, and consists of only an LID field and other fields. Thus, the size of the MAC PDU header corresponds to the sum of sizes of the LID field and other fields.

As with Equation (<NUM>), if the MAC header size is subtracted from the MAC PDU size, the size of a space in which the RLC PDU can be accommodated is calculated. However, since the length of the RLC PDU is in units of bytes, the value obtained by subtracting the MAC header size from the MAC PDU size must be divided by <NUM> and the quotient of the division must be taken in order to express the length of the RLC PDU in units of bytes.

If the overall size of the MAC PDU is signaled in units of bytes, the length of the RLC PDU can be derived from Equation (<NUM>): <MAT>.

Upon deriving the length of the RLC PDU in step <NUM>, in step <NUM>, the Rx MAC entity separates the RLC PDU from the MAC PDU by making reference to the derived length of the RLC PDU. That is, the Rx MAC entity takes a portion corresponding to the length of the RLC PDU from the point where the MAC PDU data part starts.

Subsequently, the Rx MAC entity proceeds to step <NUM>, and forwards the RLC PDU to an appropriate RLC entity by making reference to an LID field in the MAC PDU header part.

According to the first embodiment of the present invention, as stated above, a header field indicating the length of an RLC PDU can be omitted when only one RLC PDU is accommodated in an MAC PDU.

A second non-claimed embodiment of the present invention proposes a way to omit an LEN field indicating the size of the last RLC PDU when two or more RLC PDUs are accommodated in an MAC PDU.

The second embodiment of the present invention is based on the fact that when general padding, other than byte aligning padding, does not exist in a padding part of an MAC PDU, the size of the last RLC PDU is equal to a value obtained by subtracting the sizes of an MAC PDU header and other RLC PDUs from the overall size of the MAC PDU.

Unlike the first embodiment, since an MAC PDU header part and an MAC PDU data part cannot be identified from each other even when LEN values in the MAC PDU header part are analyzed, the MAC PDU header and data parts are identified using a separate flag in the second embodiment of the present invention.

The flag used for identifying the MAC PDU header and data parts from each other will be named an E field for the convenience of explanation.

In the second embodiment of the present invention, a Tx MAC entity does not include an LEN field indicating the size of the last upper layer data unit (or RLC PDU) in an MAC PDU header if the following two conditions are satisfied:.

<FIG> illustrates the structure of an MAC PDU according to the second embodiment of the present invention.

Referring to <FIG>, an MAC PDU header <NUM> includes F fields <NUM> and <NUM>, LID fields <NUM>, <NUM>, <NUM> and <NUM>, LEN fields <NUM>, <NUM> and <NUM>, and E fields <NUM>, <NUM>, <NUM> and <NUM>. Although not illustrated in the drawing, other fields may be included in the MAC PDU header part, if necessary.

RLC PDUs <NUM>, <NUM>, <NUM> and <NUM> are located next to the MAC PDU header, and padding <NUM> or byte aligning padding <NUM> and <NUM> is located next to the RLC PDUs.

If the F field has a value of <NUM> (F field <NUM>), padding other than the byte aligning padding <NUM> does not exist in a padding part <NUM> because the last RLC PDU accommodated in the MAC PDU fills the MAC PDU data part up to its last byte. Further, an LEN field indicating the length of the last RLC PDU does not exist in the MAC PDU header part <NUM>.

If the F field has a value of <NUM> (F field <NUM>), LEN fields <NUM>, <NUM> indicating the lengths of all RLC PDUs including the last RLC PDU exist in the MAC PDU header.

A repetitive description of the LID, LEN, RLC PDU, padding and byte aligning padding fields will be omitted because they have been already described in connection with the first embodiment.

The E fields <NUM>, <NUM>, <NUM> contain <NUM>-bit information.

If the E field has a value of <NUM>, a new set of LID, E and LEN fields does not exist any longer. Thus, in the case of an MAC PDU including an F field whose value is <NUM>, an MAC PDU data part starts directly after the E field. In the case of an MAC PDU including an F field whose value is <NUM>, an LEN field is located next to the E field, and an MAC PDU data part starts next to the LEN field.

If the E field has a value of <NUM>, another set of LID, E and LEN fields exists. That is, an LEN field is located next to the E field, and a new set of LID, E and LEN fields exist next to the LEN field.

In the second embodiment of the present invention, the structure of an MAC PDU header varies with the value of an F field.

When the F field has a value of <NUM>, that is, when padding does not exist in the padding part <NUM> of an MAC PDU, but only byte aligning padding exists, an LEN field for the last RLC PDU is not inserted into an MAC PDU header.

When the F field has a value of <NUM>, that is, when, in addition to byte aligning padding <NUM>, padding <NUM> also exists in a padding part <NUM> of an MAC PDU, an LEN field <NUM> for the last RLC PDU is also inserted into an MAC PDU header.

<FIG> illustrates the operation of a Tx MAC entity according to the second embodiment of the present invention.

Referring to <FIG>, in step <NUM>, the Tx MAC entity begins to generate an MAC PDU. That is, if a base station scheduler allocates transmission resources to the Tx MAC entity, the Tx MAC entity determines the RLC entities, which are to transmit data through the transmission resources, by considering the priorities of the RLC entities, etc. Further, the Tx MAC entity determines the amount of data to be transmitted by each of the RLC entities, and instructs each of the RLC entities to generate an RLC PDU having a size corresponding to the determined amount. If RLC PDUs arrive from the RLC entities, the Tx MAC entity multiplexes the RLC PDUs into an MAC PDU.

In step <NUM>, the Tx MAC entity determines if the MAC PDU, the generation of which is in progress, satisfies the following conditions: the Tx MAC entity determines (<NUM>) if there is no padding because the size of the last RLC PDU is sufficiently large, (<NUM>) if the last byte of the RLC PDU corresponds to that of the MAC PDU, or (<NUM>) if the length of the RLC PDU is equal to a value obtained by subtracting the sizes of an MAC PDU header, the RLC PDUs excluding the last RLC PDU, and byte aligning padding from the size of the MAC PDU.

The Tx MAC entity proceeds to step <NUM> if any one of the conditions is satisfied, and otherwise proceeds to step <NUM>.

In step <NUM>, the Tx MAC entity sets the value of an F field to <NUM>, and then proceeds to step <NUM>. In step <NUM>, the Tx MAC entity inserts a number of LEN fields equal to the number of the RLC PDUs, accommodated in the MAC PDU, into the MAC PDU header, and then proceeds to step <NUM>. Here, each of the inserted LEN fields indicates the length of each of the RLC PDUs.

In step <NUM>, the Tx MAC entity sets the value of an F field to <NUM>, and then proceeds to step <NUM> via step <NUM> in which the Tx MAC entity inserts LEN fields indicating the lengths of the RLC PDUs excluding the last RLC PDU into the MAC PDU header.

<FIG> illustrates the operation of an Rx MAC entity according to the second embodiment of the present invention.

First, the Rx MAC entity searches for an E field set to <NUM>, and recognizes the end portion of an LED field next to the searched E field as the starting point of an MAC PDU data part.

That is, if the Rx MAC entity identifies an MAC PDU header part and an MAC PDU data part, the Rx MAC entity sequentially analyzes LEN fields in the front of the MAC PDU to thereby separate RLC PDUs from the MAC PDU data part, and then proceeds to step <NUM>.

In step <NUM>, the Rx MAC entity forwards the RLC PDUs to appropriate RLC entities by making reference to LID fields in the MAC PDU header part.

If the F field has a value of <NUM>, the Rx MAC entity proceeds to step <NUM>. The fact that the F field has a value of <NUM> means that an LEN field indicating the size of the last RLC PDU is not included in the MAC PDU header part. Thus, in step <NUM>, the Rx MAC entity calculates the length of the last RLC PDU by using Equation (<NUM>): <MAT>.

In Equation (<NUM>), the MAC PDU size denotes the overall size of a received MAC PDU, which is signaled through a separate control channel. In Equation (<NUM>), it is assumed that the overall size of the MAC PDU is signaled in units of bits.

The MAC header size denotes the size of an MAC PDU header, expressed in bits.

If the MAC header size is subtracted from the MAC PDU size, the size of a space in which the RLC PDUs can be accommodated is calculated. In turn, if the sum of the known sizes of the RLC PDUs is subtracted from the calculated size, the length of the last RLC PDU is calculated. If the length of the last RLC PDU is divided by <NUM>, and the quotient of the division is taken, the quotient is the very value indicating the length of the last RLC PDU, expressed in bytes.

If the overall size of the MAC PDU is signaled in units of bytes, the lengths of any RLC PDU can be derived from Equation (<NUM>): <MAT>.

Upon deriving the length of the RLC PDU in step <NUM>, in step <NUM>, the Rx MAC entity separates the RLC PDU from the MAC PDU by referring to the derived length of the RLC PDU. That is, the Rx MAC entity takes a portion corresponding to the length of the RLC PDU from the point where the MAC PDU data part starts.

Subsequently, the Rx MAC entity proceeds to step <NUM>, and forwards the RLC PDU to an appropriate RLC entity by referring to an LID field in the MAC PDU header part.

A third non-claimed embodiment of the present invention proposes an MAC PDU format and the operation of a transmitting/receiving side in the case where a specific transmission resource is allocated only to a specific service.

In a specific service, such as a VoIP service, a packet with a relatively constant size occurs in a constant cycle. For example, if an AMR codec is used and a header compression technique is applied, a packet with a size of around 300bits occurs in a cycle of 20msec.

For such a service in which the occurrence pattern of traffic can be predicted in advance, a transmission resource capable of processing the traffic may be allocated only for a corresponding service, and this transmission resource is called a persistent resource.

Since data of other services is not transmitted through a persistent resource, a receiving side can process an MAC PDU for a corresponding service even if LID and LEN fields are not included in an MAC PDU header. First, if the receiving side receives an MAC PDU through a persistent resource, it can be aware that the MAC PDU includes RLC PDUs of a service which is supposed to use the persistent resource. Further, if only one RLC PDU is included in one MAC PDU, the length of the RLC PDU can be derived from the size of the MAC PDU, as described in the first and second embodiment of the present invention, and thus an LEN field need not be inserted.

In a VoIP service, since a packet occurs one by one every <NUM> msec, there is no case where a plurality of RLC PDUs connect with each other in one MAC PDU. Thus, when a persistent resource is allocated for the VoIP service, the format of an MAC PDU to be transmitted through the persistent resource is defined as illustrated in <FIG>.

<FIG> illustrates the structure of an MAC PDU according to the third embodiment of the present invention.

Referring to <FIG>, a transmitting side removes an LID field <NUM> and an LEN field <NUM> from an MAC PDU header, constructs an MAC PDU with only an Other hdr field <NUM> and an RLC PDU <NUM>, and then transmits the constructed MAC PDU. Upon receiving side receives any MAC PDU through a persistent resource, a receiving side determines that only one RLC PDU is included in the received MAC PDU, and separates the RLC PDU from the MAC PDU. With regard to this, the length of the RLC PDU is calculated by subtracting the size of the Other hdr field from the size of the MAC PDU, and the size of the Other hdr field has a fixed value.

<FIG> illustrates the operation of a transmitting side according to the third embodiment of the present invention.

Referring to <FIG>, in step <NUM>, if it is necessary to generate an MAC PDU, that is, if a transmission resource is available at the next transmission cycle, a Tx MAC entity begins to generate an MAC PDU.

In step <NUM>, the Tx MAC entity determines if the available resource is a persistent resource. If it is determined that the available transmission resource is not a persistent resource, the Tx MAC entity proceeds to step <NUM>. In step <NUM>, the Tx MAC entity constructs an MAC PDU according to the prior art, and then proceeds to step <NUM>. In step <NUM>, the Tx MAC entity transmits the MAC PDU by using the available transmission resource.

If it is determined that the available transmission resource is a persistent resource, in step <NUM>, the Tx MAC entity receives an RLC PDU from a relevant RLC entity. The relevant RLC entity refers to an RLC entity which is permitted to use the persistent resource. In step <NUM>, the Tx MAC entity attaches an MAC PDU header, which consists of only an Other hdr field without LID and LEN fields, to the RLC PDU to thereby construct an MAC PDU, and then proceeds to step <NUM>. In step <NUM>, the Tx MAC entity transmits the MAC PDU by using the persistent resource.

<FIG> illustrated the operation of a receiving side according to the third embodiment of the present invention.

Referring to <FIG>, in step <NUM>, an Rx MAC entity is notified of the LID of an RLC PDU to be received through a persistent resource. The LID is may be notified to transmitting and receiving sides when a persistent resource is allocated for a service which is to use the persistent resource, such as a VoIP service.

In step <NUM>, the Rx MAC entity receives an MAC PDU through the allocated persistent resource, and then proceeds to step <NUM>. In step <NUM>, the Rx MAC entity calculates the length of an RLC PDU according to Equation (<NUM>): <MAT>.

In Equation (<NUM>), the MAC PDU size denotes the size of an MAC PDU, which is notified through a separate control channel. For a service in which a packet with a constant size occurs, such as a VoIP service, the size of the MAC PDU may be determined in advance. The MAC header size denotes the size of an Other hdr field excluding LID and LEN fields, and has a fixed value.

In step <NUM>, the Rx MAC entity separates an RLC PDU from the MAC PDU. The RLC PDU to be separated is a portion corresponding to the RLD PDU length in Equation (<NUM>) after the Other hdr field is removed from the MAC PUD.

In step <NUM>, the Rx MAC entity forwards the RLC PDU to a relevant RLC entity. The relevant RLC entity refers to an RLC entity connected to a service which is permitted to use the persistent resource, and simultaneously is an RLC entity corresponding to the LID notified in step <NUM>.

According to the third embodiment of the present invention, as stated above, when a VoIP packet is not multiplexed with a packet of another flow, LID and LEN fields are not included in an MAC PDU header, so that the overhead of the MAC PDU header can be reduced.

<FIG> illustrates the structure of an MAC PDU according to a fourth embodiment, which is according to the claimed invention.

As illustrated in <FIG>, the fourth embodiment of the present invention proposes a way to reduce the overhead of an MAC PDU header for a service in which the size of a packet is substantially constant, such as a VoIP service, by inserting an SID field <NUM>, which includes collapsed information indicating the length of an RLC PDU, that is, an SID, into the MAC PDU header. With regard to this, a specific code point of the SID field <NUM> indicates that the length of an RLC PDU can be derived from the size of an MAC PDU, thereby efficiently meeting variableness in the size of a VoIP packet. That is, respective code points of the SID field <NUM> are previously mapped to packet sizes that are likely to occur frequently, and yet at least one of the code points includes information indicating that the length of an RLC PDU can be calculated from the size of an MAC PDU, so that even when a packet with a size undefined in the SID occurs, it can be dealt with well.

<FIG> illustrate the operation of a Tx MAC entity according to the fourth embodiment of the present invention.

Referring to <FIG>, in step <NUM>, the Tx MAC entity recognizes SID configuration information through a call setup process. An SID is configured according to RLC entities. In other words, a packet size meant by SID x for an RLC PDU occurring in a specific RLC entity may be different from that meant by the SID x for another RLC entity. Further, according to the characteristic of an RLC entity, the length of an RLC PDU may be represented using an SID or may be represented using an LEN field. Since the usefulness of an SID is limited to a service in which the length of an RLC PDU is limitative, an SID is configured only for RLC entities of some services, such as a VoIP service. Thus, for the other services, an SID is not configured, but a common LEN field is used. When n SIDs are configured for RLC entities, a given number of SIDs are defined by a given rule in such a manner as to indicate that the length of a corresponding RLC PDU can be derived from the size of an MAC PDU. In the following description, a given number of the SIDs are named a special SID for the convenience of explanation.

When the length of any RLC PDU is represented by a special SID, an example of a rule for calculating the length of the RLC PDU is defined by Equation (<NUM>): <MAT>.

In Equation (<NUM>), the MAC PDU size denotes the size of an MAC PDU into which a corresponding RLC PDU is multiplexed, the SUM of all MAC header sizes denotes the sum of the sizes of all MAC headers accommodated in the MAC PDU, and the SUM of all other RLC PDU sizes denotes the sum of the sizes of other RLC PDUs multiplexed together with the corresponding RLC PDU. The padding size denotes the size of corresponding padding in the case of using the padding in the MAC PDU. In general, whether or not padding exists and the size of padding is designated by information included in the MAC PDU header.

Each of SIDs other than a special SID indicates the size of a specific packet, a network defines a relation between each SID and a specific packet by considering a set-up call. In the following description, an SID indicating a predetermined packet size will be referred to as a "deterministic SID" for the convenience of explanation.

In step <NUM>, if it is necessary to generate an MAC PDU, that is, if a transmission resource is available at the next transmission cycle, the Tx MAC entity begins to construct an MAC PDU in conformity with the size of the available transmission resource. First, the Tx MAC entity determines the size of the MAC PDU by making reference to the available resource, determines the length of an RLC PDU to be transmitted, starting from RLC entities with higher priorities, and then proceeds to step <NUM>. In step <NUM>, the Tx MAC entity notifies each RLC entity of the determined length.

To be specific, in step <NUM>, the Tx MAC entity, which is aware of the amount of data stored in RLC entities and the priorities of the RLD entities, first notifies the length of an RLC PDU to an RLC entity with the highest priority from among the RLD entities in which data are stored. Here, the length of the RLC PDU is such that all data stored in the RLC entity with the highest priority can be accommodated. If space still remains in the MAC PDU even after the RLC PDU is accommodated therein, the Tx MAC entity notifies the length of an RLC PDU to an RLC entity with the next highest priority. The Tx MAC entity repeats this operation until there is no more space for accommodating an RLC PDU in the MAC PDU.

If the RLC entities submit RLC PDUs, the Tx MAC entity attaches an MAC PDU header to each RLC PDU. Here, an SID or LEN field indicating the length of the RLC PDU is accommodated in the MAC PDU header.

Indicating the length of an RLC PDU by using an LEN field is the same as that in the prior art, and thus a description thereof will be omitted. In the fourth embodiment of the present invention, a description will be given of only the case where the length of a specific RLC PDU is indicated using an SID field.

In step <NUM>, for an RLC PDU, the length of which is to be indicated using an SID field, the Tx MAC entity determines if it is possible to indicate the length of the RLC PDU by a deterministic SID. If possible, the Tx MAC entity proceeds to step <NUM>, and otherwise proceeds to step <NUM>.

In step <NUM>, the Tx MAC entity constructs an MAC PDU header by using an SID corresponding to the length of the RLC PDU, and then proceeds to step <NUM>. In step <NUM>, the Tx MAC entity connects the MAC PDU header and the RLC PDU to thereby complete the generation of the MAC PDU, and then transmits the generated MAC PDU.

If the length of an RLC PDU does not correspond to any one of deterministic SIDs, the Tx MAC entity proceeds to step <NUM>, and determines if the length of the RLC PDU can be indicated by a special SID. That is, the Tx MAC entity determines if the length of the RLC PDU corresponds to a value obtained by subtracting the size of the MAC PDU header and sizes of other RLC PDUs from the size of the MAC PDU. If so, the Tx MAC entity proceeds to step <NUM>. Otherwise, the Tx MAC entity proceeds to step <NUM>.

In step <NUM>, the Tx MAC entity constructs an MAC PDU header by using a special SID, and then proceeds to step <NUM>. In step <NUM>, the Tx MAC entity connects the MAC PDU header and the RLC PDU to thereby complete the generation of the MAC PDU, and then submits the generated MAC PDU to a lower layer.

In LTE, an RLC PDU has a variable length. In other words, if an amount of data sufficient for filling an MAC PDU are stored in RLC entities, the sum of the sizes of RLC PDUs and an MAC PDU header must always correspond to the size of the MAC PDU. In this sense, step <NUM> must be always true. The only exception is where the amount of data stored in RLC entities is not sufficient, and thus an MAC PDU cannot be fully filled with RLC PDUs. In this case, the length of any RLC PDU does not correspond to a value obtained by subtracting the sum of sizes of MAC PDU headers and other RLC PDUs from the size of the MAC PDU. Thus, the remaining space is filled with padding corresponding to such a difference.

In other words, proceeding to step <NUM> means that the remaining space of the MAC PDU must be filled with padding. In step <NUM>, the Tx MAC entity constructs an MAC PDU header by using a special SID, and then proceeds to step <NUM>. In step <NUM>, the Tx MAC entity connects the MAC PDU header and the RLC PDU and inserts dummy bits, that is, padding bits, into the remaining space to thereby complete the generation of the MAC PDU. Subsequently, the Tx MAC entity submits the generated MAC PDU to a lower layer.

<FIG> illustrate the operation of an Rx MAC entity according to the fourth embodiment of the present invention.

Referring to <FIG>, in step <NUM>, the Rx MAC entity recognizes SID configuration through a call setup process. To be specific, the Rx MAC entity recognizes packet size values corresponding to deterministic SIDs, which SID is a special SID, and a rule for calculating the length of an RLC PDU for which the special SID is used. The calculation rule follows Equation (<NUM>) as described above.

Padding usually does not exist, and even when padding exists, this is indicated in an MAC PDU header.

Upon receiving an MAC PDU in step <NUM>, the Rx MAC entity proceeds to step <NUM>, and analyzes the first header of the MAC PDU in order to demultiplex an RLC PDU from the MAC PDU. The Rx MAC entity examines if a special SID is used in the MAC PDU header. If a special SID is used, the Rx MAC entity proceeds to step <NUM>, and otherwise proceeds to step <NUM>.

Proceeding to step <NUM> means that a deterministic SID or an LEN field is used in the MAC PDU header, and the length of an RLC PDU can be discovered from the deterministic SID or the LEN field. In step <NUM>, after the Rx MAC entity discovers the length of a relevant RLC PDU from the deterministic SID or the LEN field, the RX MAC entity separates an RLC PDU corresponding to the length from the MAC PDU, and then proceeds to step <NUM>. In step <NUM>, the Rx MAC entity forwards the RLC PDU to an upper layer. Subsequently, the Rx MAC entity returns to step <NUM>, and repeats the same operation for the next MAC PDU header.

Further, proceeding to step <NUM> means that the length of a relevant RLC PDU is indicated by a special SID. Thus, in step <NUM>, the Rx MAC entity calculates the length of the relevant RLC PDU by Equation (<NUM>) as described above.

In step <NUM>, the Rx MAC entity separates an RLC PDU corresponding to the calculated length from the MAC PDU, and then proceeds to step <NUM>. In step <NUM>, the Rx MAC entity forwards the RLC PDU to an upper layer. Subsequently, the Rx MAC entity returns to step <NUM>, and repeats the same operation for the next MAC PDU header.

A fifth non-claimed embodiment of the present invention proposes a way to extend the meaning of a special SID.

In the fifth embodiment of the present invention, a plurality of special SIDs are configured, and the length of an RLC PDU, indicated by each special SID, corresponds to a value obtained by subtracting the size of an MAC PDU header, the sum of the sizes of other RLC PDUs, and n bytes from the size of an MAC PDU. Further, control information or padding with a size of n bytes is accommodated in the rear of an RLC PDU indicated by a special SID.

<FIG> illustrates the operation of a Tx MAC entity according to the fifth embodiment of the present invention.

Referring to <FIG>, in an MAC PDU header in which, for example, two RLC PDUs <NUM>, <NUM> are accommodated, the length of the second RLC PDU <NUM> is indicated by a special SID <NUM>. If the special SID has the meaning that the length of an RLC PDU corresponds to a value obtained by subtracting an MAC PDU header, other RLC PDUs and n bytes from the size of an MAC PDU, the length of the second RLC PDU <NUM> is derived from the overall size of an MAC PDU, the size of an MAC PDU header, the sizes of other RLC PDUs, and n bytes, and control information with a size of n bytes is accommodated behind the RLC PDU <NUM>.

When a small-sized RLC PDU, such as a VoIP packet, is transmitted together with separate control information, it is efficient to simultaneously indicate the length of the RLC PDU and the size of padding/control information by one SID in this way. The separate control information may include, for example, a buffer state report for reporting the amount of data to a scheduler. Further, padding is also considered a kind of control information.

The value of n may be set to a plurality of values, and as many special SIDs as the number of n values exist. In the fifth embodiment of the present invention, when an SID has, for example, <NUM> bits, the SID may be configured as given below in Table <NUM>.

In Table <NUM>, an SID with a value of <NUM>, <NUM>, <NUM> or <NUM> indicates the case where an RLC PDU with a frequently used size is inserted, and an SID with a value of <NUM> indicates the case where the length of a relevant RLC PDU can be deduced from the size of an MAC PDU, and control information is not included. An SID with a value of <NUM>, <NUM> or <NUM> indicates the case where the length of a relevant RLC PDU can be deduced from the size of an MAC PDU, and yet control information of given bytes is also included.

Referring to <FIG>, in step <NUM>, the Tx MAC entity recognizes SID configuration information through a call setup process. The SID configuration information and whether or not to use it are set up according to RLC entities. In other words, in stead of an SID field, an LEN field is used for an RLC PDU occurring in a specific RLC entity, and a special SID is used for an RLC PDU occurring in another specific RLC entity. A packet size meant by special SID x may be different from that meant by the special SID x for an RLC PDU occurring in another RLC entity. When n special SIDs are configured for any RLC entity, a given number of special SIDs are defined by a given rule in such a manner as to indicate that the length of a corresponding RLC PDU can be deduced from the size of an MAC PDU, and control information with a given size (n bytes) is included in the rear of the RLC PDU.

When the length of any RLC PDU is represented by a special SID x, an example of a rule for calculating the length of the RLC PDU is defined by Equation (<NUM>): <MAT>.

In Equation (<NUM>), different values of the MAC PDU size are used according to special SIDs, and padding is also considered a kind of control information. The MAC PDU size denotes the size of an MAC PDU into which a corresponding RLC PDU is multiplexed, the SUM of all MAC header sizes denotes the sum of the sizes of all MAC headers accommodated in the MAC PDU, and the SUM of all other RLC PDU sizes denotes the sum of the sizes of other RLC PDUs multiplexed together with the corresponding RLC PDU. Each of SIDs other than a special SID indicates the size of a specific packet, a network defines a relation between each SID and a specific packet by considering a set-up call. In the following description, an SID indicating a predetermined packet size will be referred to as a "deterministic SID" for the convenience of explanation.

In step <NUM>, if it is necessary to generate an MAC PDU, that is, if a transmission resource is available at the next transmission cycle, the Tx MAC entity begins to construct an MAC PDU in conformity with the size of the available transmission resource. First, the Tx MAC entity determines the size of the MAC PDU by making reference to the available resource, determines the length of an RLC PDU to be transmitted, for every RLC entity according to a given rule, and then proceeds to step <NUM>. In step <NUM>, the Tx MAC entity notifies each RLC entity of the determined length.

If the RLC entities construct RLC PDUs in conformity with the notified lengths and submit them, the Tx MAC entity attaches an MAC PDU header to each RLC PDU. Here, an SID or LEN field indicates the length of the RLC PDU.

Indicating the length of an RLC PDU by using an LEN field is the same as that in the prior art, and thus a description thereof will be omitted. In the fifth embodiment of the present invention, a description will be given of only the case where the length of a specific RLC PDU is indicated using an SID field.

In step <NUM>, for an RLC PDU, the length of which is to be indicated using an SID field, the Tx MAC entity checks if it is possible to indicate the length of the RLC PDU by a deterministic SID. If possible, the Tx MAC entity proceeds to step <NUM>, and otherwise proceeds to step <NUM>.

If the length of an RLC PDU does not correspond to any one of deterministic SIDs, the Tx MAC entity proceeds to step <NUM>. In step <NUM>, the Tx MAC entity determines a special SID to be used, and constructs an MAC PDU. If the length of an RLC PDU can be indicated by any one of special SIDs, the Tx MAC entity constructs an MAC PDU by using the special SID. However, if the length of an RLC PDU cannot be indicated by any special SID, the Tx MAC entity instructs a relevant RLC entity to discard the existing RLC PDU, newly generate an RLC PDU that can be indicated by any one of special SIDs, and then submit the generated RLC PDU thereto. Thus, the Tx MAC entity constructs an MAC PDU by using the newly forwarded RLC PDU.

In step <NUM>, the Tx MAC entity generates control information in conformity with the size of control information, indicated by the selected special SID, and then proceeds to step <NUM>. In step <NUM>, the Tx MAC entity connects an MAC PDU header, RLC PDUs and control information to thereby complete the generation of the MAC PDU, and then submits the generated MAC PDU to a lower layer.

<FIG> illustrate the operation of an Rx MAC entity according to the fifth embodiment of the present invention.

Referring to <FIG>, in step <NUM>, the Rx MAC entity recognizes SID configuration through a call setup process. The Rx MAC entity recognizes packet size values corresponding to deterministic SIDs, which SIDs are special SIDs, and what is meant by each special SID. The length of an RLC PDU meant by each special SID is calculated by Equation (<NUM>) as described above.

According to the fifth embodiment of the present invention, a plurality of control information sizes may be configured, and as many special SIDs as the number of the control information sizes are defined.

Upon receiving an MAC PDU in step <NUM>, the Rx MAC entity proceeds to step <NUM>, and demultiplexes an RLC PDU from the MAC PDU. The Rx MAC entity examines if a special SID is used in the first header of the received MAC PDU. If a special SID is used, the Rx MAC entity proceeds to step <NUM>, and otherwise proceeds to step <NUM>.

Proceeding to step <NUM> means that a deterministic SID or an LEN field is used in the MAC PDU header, and the length of an RLC PDU can be determined from the deterministic SID or the LEN field. In step <NUM>, after the Rx MAC entity determines the length of a relevant RLC PDU from the deterministic SID or the LEN field, the Rx MAC entity separates an RLC PDU corresponding to the length from the MAC PDU, and then proceeds to step <NUM>. In step <NUM>, the Rx MAC entity forwards the RLC PDU to an upper layer. Subsequently, the Rx MAC entity returns to step <NUM>, and repeats the same operation for the next MAC PDU header.

Further, proceeding from step <NUM> to step <NUM> means that the length of a relevant RLC PDU is indicated by a special SID. Thus, in step <NUM>, the Rx MAC entity calculates the length of the relevant RLC PDU and the size of control information behind the RLC PDU by Equation (<NUM>): <MAT>.

In step <NUM>, the Rx MAC entity separates an RLC PDU corresponding to the calculated length and control information corresponding to the control information size from the MAC PDU, and then proceeds to step <NUM>.

In step <NUM>, the Rx MAC entity forwards the demultiplexed control information an MAC layer, and proceeds to step <NUM>. In step <NUM>, the Rx MAC entity forwards the demultiplexed RLC PDU to an appropriate upper layer. In step <NUM>, the Rx MAC entity determines if the demultiplexed RLC PDU is a last RLC PDU. If it is determined that the demultiplexed RLC PDU is not a last RLC PDU, the Rx MAC entity returns to step <NUM>. If it is determined that the demultiplexed RLC PDU is a last RLC PDU, the Rx MAC entity ends the demultiplexing operation.

<FIG> illustrate the structure of a transmitting apparatus according to an exemplary embodiment of the present invention.

Referring to <FIG>, the transmitting apparatus according to this embodiment includes an RLC layer <NUM>, a data part construction unit <NUM>, a header insertion unit <NUM>, an HARQ processor <NUM>, a transceiver <NUM>, a control unit <NUM>, and a control channel processing unit <NUM>.

The RLC layer <NUM> consists of RLC entities, in each of which an RLC PDU is generated. The RLC entity generates an RLC PDU with a size instructed by the control unit <NUM>, and transfers it to the data part construction unit <NUM>.

The data part construction unit <NUM> connects RLC PDUs transferred by the RLC entities to thereby construct an MAC PDU data part, and then delivers the MAC PDU data part to the header insertion unit <NUM>.

The header insertion unit <NUM> inserts an MAC PDU header into the MAC PDU data part and inserts padding behind the MAC PDU data part, if necessary, to thereby construct an MAC PDU, and then delivers the MAC PDU to the HARQ processor <NUM>. Further, when the header insertion unit <NUM> generates an MAC PDU header, the header insertion unit <NUM> determines if an LEN field is inserted into the PDU header, under instructions from the control unit <NUM>.

The HARQ processor <NUM> transmits an MAC HARQ according to a prescribed HARQ operation.

The transceiver <NUM> performs an operation of converting an MAC PDU into a radio signal and transmitting the radio signal, and an operation of receiving a radio signal and forwarding it to an appropriate upper processor.

If a transmission resource is allocated to the transmitting apparatus, the control unit <NUM> determines RLC entities, which are to transmit RLC PDUs, by considering their priorities, etc., and determines the length of an RLC PDU. Further, the control unit <NUM> instructs each of the RLC entities to generate an RLC PDU with the determined length and transfer it to the data part construction unit <NUM>. Further, the control unit <NUM> determines the size of an MAC PDU to be transmitted, by using the allocated transmission resource, determines how it processes an LEN field in an MAC PDU header, by considering the lengths of RLC PDUs and the size of an MAC PDU, and notifies this to the header insertion unit <NUM>.

In the first embodiment of the present invention, the control unit <NUM> instructs the header insertion unit <NUM> to set an F field to <NUM> and not to insert an LEN field into an MAC PDU header if only one RLC PDU is accommodated in an MAC PDU, and the last byte of an RLC PDU corresponds to the last byte of the MAC PDU. Otherwise, the control unit <NUM> instructs the header unit <NUM> to set an F field to <NUM> and to insert an LEN field into an MAC PDU header.

In the second embodiment of the present invention, the control unit <NUM> instructs the header insertion unit <NUM> to set an F field to <NUM> and not to insert an LEN field for the last RLC PDU into an MAC PDU header if the last byte of the last RLC PDU corresponds to the last byte of the MAC PDU. Otherwise, the control unit <NUM> instructs the header unit <NUM> to set an F field to <NUM> and to insert LEN fields for all RLC PDUs into an MAC PDU header.

In the third embodiment of the present invention, the control unit <NUM> determines if a currently available resource is a persistent resource. If the available resource is a persistent resource, the control unit <NUM> instructs the header insertion unit <NUM> to construct an MAC PDU header without using LID and LEN fields.

In the fourth embodiment of the present invention, the control unit <NUM> controls the header insertion unit <NUM> to insert an appropriate SID field into an MAC PDU header for an RLC PDU occurring in an RLC entity where an SID is used.

In the fifth embodiment of the present invention, the control unit <NUM> controls the header insertion unit <NUM> to insert an appropriate SID field into an MAC PDU header for an RLC PDU occurring in an RLC entity where an SID is used. If it is necessary to connect control information with a given size behind the RLC PDU, the control unit <NUM> constructs control information with an appropriate size and delivers it to the data part construction unit <NUM>.

The control channel processing unit <NUM> transmits information necessary for processing an MAC PDU over a separate control channel. The information necessary for processing an MAC PDU may include the size of the MAC PDU, and a value notified by the control unit <NUM> is used as the size of the MAC PDU.

<FIG> illustrates the structure of a receiving apparatus according to an exemplary embodiment of the present invention.

Referring to <FIG>, the receiving apparatus according to this embodiment includes an RLC layer <NUM>, an RLC PDU separation unit <NUM>, a header analysis unit <NUM>, an HARQ processor <NUM>, a transceiver <NUM>, and a control channel processing unit <NUM>.

The transceiver <NUM> and the HARQ processor <NUM> demodulates a radio signal into an MAC PDU through a given procedure. Further, they deliver a successfully received MAC PDU to the header analysis unit <NUM>.

The transceiver <NUM> also receives control information necessary for processing an MAC PDU, which is transmitted over a control channel through a given procedure, and delivers the received control information to the control channel processing unit <NUM>.

The control channel processing unit <NUM> delivers the size of an MAC PDU, which is received over a control channel, to the header analysis unit <NUM>.

The header analysis unit <NUM> analyzes an MAC PDU header and separates an MAC PDU data part from an MAC PDU. Further, the header analysis unit <NUM> delivers the separated MAC PDU data part and MAC PDU header information to the RLC PDU separation unit <NUM>.

In the first embodiment of the present invention, for an MAC PDU whose F field has a value of <NUM>, the header analysis unit <NUM> calculates the length of an RLC PDU by using Equation (<NUM>) or (<NUM>). For an MAC PDU whose F field has a value of <NUM>, the header analysis unit <NUM> separates an MAC PDU header part and an MAC PDU data part from the MAC PDU by sequentially analyzing an MAC PDU header.

In the second embodiment of the present invention, for an MAC PDU whose F field has a value of <NUM>, the header analysis unit <NUM> calculates the length of an RLC PDU by using Equation (<NUM>) or (<NUM>). For an MAC PDU whose F field has a value of <NUM>, the header analysis unit <NUM> separates an MAC PDU header part and an MAC PDU data part from the MAC PDU by analyzing LEN fields in an MAC PDU header.

In the third embodiment of the present invention, the header analysis unit <NUM> identifies an MAC PDU transmitted through a persistent resource and an MAC PDU transmitted through a general transmission resource, and applies an MAC PDU header format appropriate to the identified MAC PDU. Further, the header analysis unit <NUM> analyzes an MAC PDU header by means of the appropriate MAC PDU header format, and demultiplexes an RLC PDU from the Mac PDU.

In the fourth embodiment of the present invention, the header analysis unit <NUM> analyzes an LID field of an MAC PDU header to thereby determine whether a field following the LID field is an SID field or an LEN field. If the field is an SID field, the header analysis unit <NUM> deduces the length of an RLC PDU from the SID field. Further, based on the contents of the MAC PDU header, the header analysis unit <NUM> demultiplexes an RLC PDU from an MAC PDU.

In the fifth embodiment of the present invention, the header analysis unit <NUM> analyzes an LID field of an MAC PDU header to thereby determine whether a field following the LID field is an SID field or an LEN field. If the field is an SID field, the header analysis unit <NUM> deduces the length of an RLC PDU and the length of control information from the SID field. Further, based on the contents of the MAC PDU header, the header analysis unit <NUM> demultiplexes an RLC PDU and control information from an MAC PDU.

If the header analysis unit <NUM> delivers an MAC PDU header part and an MAC PDU data part to the RLC PDU separation unit <NUM>, the RLC PDU separation unit <NUM> separates an RLC PDU from an MAC PDU by using information of the MAC PDU header part, and forwards the separated RLC PDU to an appropriate RLC entity.

According to the present invention as describe above, when upper layer packets are multiplexed into a packet whose overall size is informed via a separate path, the size of the upper layer packet is not signaled if it can be calculated from the overall size of the packet, so that the size a packet transmitted/received over a radio channel can be reduced.

Further, the size of an upper layer packet is not signaled for a service in which data is transmitted through a persistent resource, so that the size a packet transmitted/received over a radio channel can be reduced.

Further, collapsed information indicating the size of an upper layer packet is signaled for a service in which the size of a packet is substantially constant, so that the size a packet transmitted/received over a radio channel can be reduced.

Claim 1:
A method of transmitting a packet over a radio channel in a mobile communication system, the method performed by a transmitting apparatus and comprising:
receiving, by a data part construction unit (<NUM>), one or more radio link control packet data units, RLC PDUs (<NUM>, <NUM>), through one or more logical channels from an upper layer (<NUM>) comprising one or more RLC entities;
generating (<NUM>), by a header insertion unit (<NUM>), a media access control packet data unit, MAC PDU, that includes the RLC PDUs; and
transmitting, by a transceiver (<NUM>), the generated MAC PDU over the radio channel to a receiving apparatus,
wherein generating (<NUM>) the MAC PDU comprises:
inserting (<NUM>), into a header of the MAC PDU, a first information field (<NUM>) mapped to one among a predetermined set of sizes, to indicate a size of the RLC PDU if the RLC PDU is from a specific RLC entity related to a specific service.