Methods of transmitting data blocks in wireless communication system

- LG Electronics

Disclosed is a method for generating a data block to be transmitted from a specific layer in a transmitting side to a receiving side in a wireless communication system. The method includes receiving an upper layer datei block from an upper layer and generating a lower layer data block including at least part of the upper layer data block and state indication information indicating a state of the upper layer data block, the state indication information being selected variably according to a logical channel through which the upper layer data block is received. This method optimizes overhead of a header of each upper layer data block according to contents of the upper layer data block and event situations associated with the upper layer data block, thereby increasing system efficiency.

Skip to: Description  ·  Claims  ·  References Cited  · Patent History  ·  Patent History
Description

This application claims priority to is a reissue of, and claims the benefit of, U.S. Pat. No. 8,081,662, issued on Dec. 20, 2011, which is a 35 U.S.C. §371 National Stage Entry of International Application No. PCT/KR2008/002468 filed on Apr. 30, 2008, which claims priority to U.S. Provisional Application No. 60/915,042 filed on Apr. 30, 2007, U.S. Provisional Application No. 60/915,417, filed May 1, 2007 and Korean Patent Application No. 10-2008-0040506, filed on Apr. 30, 2008, all of which are incorporated by reference for all purposes as if fully set forth herein.

TECHNICAL FIELD

The present invention relates to a wireless communication system, and more particularly, to a method for transmitting data blocks in a wireless communication system.

BACKGROUND ART

FIG. 1 illustrates the structure of a wireless access protocol responsible for data transmission in a radio link of a Universal Mobile Telecommunication System (UMTS) which is a third generation mobile communication system. Data link layers corresponding to the second layer (Layer 2: L2) of the Open System Interconnection (OSI) reference model include a Medium Access Control (MAC) layer, a Radio Link Control (RLC) layer, a Packet Data Convergence Protocol (PDCP) layer, and a Broadcast/Multicast Control (BMC) layer. The physical layer corresponds to the first layer (Layer 1: L1). Information exchange between protocol layers is performed through virtual access points that are referred to as “Service Access Points (SAPS)”, which are represented by ovals in FIG. 1. Data units communicated between layers are given different names. These data units are referred to as “Service Data Units (SDUs)” and basic units that protocols use for transmitting data are referred to as “Protocol Data Units (PDUs)”. In the following description of the invention, data delivered between layers in the wireless access protocol structure indicates data blocks in specific units such as SDUs or PDUs described above.

The MAC layer is a layer responsible for mapping between logical and transport channels. The MAC layer selects an appropriate transport channel for transmitting data received from the RLC layer and adds required control information to a header of a MAC PDU. Special functions performed by the MAC layer include a radio resource management function and a measurement function. The radio resource management function is not performed solely by the MAC layer. Instead, the radio resource management function serves to set operations of the MAC layer based on various MAC parameters received from a Radio Resource Control (RRC), which is located above the MAC layer, to control data transmission. Examples of the radio resource management function include a function to change mapping relations between logical and transport channels or to multiplex and transmit data through a scheduling function. The measurement function is to measure the amount of traffic of a terminal and to report the measurement to an upper layer. The upper layer can change the configuration (or setting) of the MAC layer based on the measurement information obtained by the MAC layer of the terminal, thereby efficiently managing radio (wireless) resources.

The RLC layer is located above the MAC layer and supports reliable data transmission. The RLC layer segments and concatenates RLC Service Data Units (SDUs) received from the above layer in order to construct data having a size suitable for a radio link. An RLC layer at the receiving side supports data recombination in order to restore original RLC SDUs from the received RLC PDUs. Each RLC entity can operate in a Transparent Mode (TM), an Unacknowledged Mode (UM), or an Acknowledged Mode (AM) according to processing and transmission methods of RLC SDUs. When the RLC entity operates in the TM, it transfers an RLC SDU received from an upper entity or layer to the MAC layer without adding any header information to the RLC SDU. When the RLC entity operates in the UM, it segments/concatenates RLC SDUs to construct RLC PDUs and adds header information including a sequence number to each RLC PDU. However, in the UM, the RLC entity does not support data retransmission. When the RLC entity operates in the AM, it can use the RLC SDU segmentation/concatenation function to construct RLC PDUs and can perform retransmission when packet transmission has failed. Various parameters and variables such as a transmission window, a reception window, a timer, and a counter are used for the retransmission function in the AM.

The PDCP layer is used only in packet exchange regions and can compress and transmit IP packet headers so as to increase the transmission efficiency of packet data in wireless channels. The PDCP layer also manages sequence numbers in order to prevent data loss during Serving RNC (SRNC) relocation.

The BMC layer broadcasts cell broadcast messages received from a core network to multiple users through a common channel.

The physical layer, which is the first layer, provides an information transfer service to an upper layer using a physical channel. The physical layer is connected to the Media Access Control (MAC) layer located above the physical layer through a transport channel. Data is transferred between the MAC layer and the physical layer through the transport channel. Data is transferred between different physical layers (specifically, physical layers of transmitting and receiving sides) through a physical channel.

A Radio Resource Control (RRC) layer, which is the third layer located at the bottom, is defined only in the control plane and is responsible for controlling logical, transport, and physical channels in association with configuration, re-configuration, and release of Radio Bearers (RBs). RBs are services that the second layer provides for data communication between terminals and a network including a base station. The control plane is a hierarchy in which control information is transferred in the vertical structure of the wireless access protocol of FIG. 1 and the user plane is a hierarchy in which user information such as data/information is transferred.

As shown in FIG. 1, an RLC PDU generated in the RLC layer is transferred to the MAC layer and is handled as a MAC SDU in the MAC layer. While a MAC SDU, which is an RLC PDU received from the RLC layer, undergoes various functions of the MAC layer, various header information required for data processing is added to the MAC SDU. The header information can be altered depending on mapping relations between logical and transport channels.

Logical channels provide transport passages required for data exchange between the MAC and the RLC layer. Each logical channel is classified into control and traffic channels according to the type of data transmitted therethrough. The control channel transmits data of the control plane and the traffic channel transmits user traffic data. A logical channel is a type of data stream carrying a specific type of information. Each logical channel is generally connected to one RLC entity. One or more logical channels of the same type can also be connected to an RLC entity. Transport channels provide passages for data communication between the physical and MAC layers. A data stream in a logical channel is embodied as a MAC PDU in the MAC layer. Reference will now be made to the MAC PDU.

FIG. 2 illustrates an example structure of a MAC PDU with a header added thereto in a mobile communication system. A MAC PDU includes one or more MAC SDUs corresponding to payload for data and a MAC header which is a set of MAC sub-headers indicating the size or type of each MAC SDU. In the example of FIG. 2, it is assumed that a total of N upper layer data blocks are provided. A MAC sub-header includes a Logical Channel ID (LCID) identifying each SDU, a length field (L) indicating the size of each SDU, and an extension field (E) indicating whether a subsequent field is a MAC header or an SDU to indicate whether or not additional headers are present.

The LCID indicates which logical channel corresponds to data of a MAC SDU which is an upper layer data block associated with a sub-header including the LCID. That is, one MAC PDU includes one or more upper layer data blocks and different logical channels can be allocated to the upper layer data blocks individually.

Generally, one or more logical channels can be established between a terminal and a base station. For example, in the case of a voice service, not only a logical channel carrying voice traffic but also a logical channel for a Signaling Radio Bearer (SRB) for control information communicated between the base station and the terminal can be established between the base station and the terminal. In this case, state changes of the SRB and state changes of the voice traffic channel may occur independently of each other. More specifically, change of an Adaptive Multi-Rate (AMR) codec mode in the voice traffic channel and generation of an urgent message in the SRB channel may occur independently of each other. Therefore, an upper layer data block for voice traffic and an upper layer data block for an SRB can both be allocated to one MAC PDU and the size or the like of each upper layer data block can be set to be different according to the type and usage of a logical channel associated with the upper layer data block. The size of each upper layer data block can be set through a size field in a MAC sub-field of a MAC SDU corresponding to the upper layer data block.

DISCLOSURE Technical Problem

Since MAC header values, which are part of a MAC PDU (i.e., a lower layer data block) excluding MAC SDUs (i.e., upper layer data blocks) containing payload, are not actual data values as described above, it is necessary to minimize the MAC header values to increase throughput. However, the sizes or types of the fields of the MAC header are fixed and used regardless of which logical channel is associated with each MAC SDU in the MAC PDU, regardless of what are actual contents of the MAC SDU, etc. This causes a reduction in system efficiency due to overhead of control signals.

It is also necessary to allocate radio resources to the upper layer data block suitable for characteristics of the upper layer data block and to perform an operation on the upper layer data block according to urgency and importance of the processing of upper layer data block.

The present invention has been suggested to overcome the above problems in the background art, and it is an object of the present invention to provide a method for generating a data block in a communication system.

Another object of the present invention is to provide a method for generating a data block using state indication information of one or more upper layer data blocks in a communication system.

Technical Solution

In an aspect of the invention, there is provided a method for generating a data block to be transmitted from a specific layer in a transmitting side to a receiving side in a wireless communication system. This method includes receiving an upper layer data block from an upper layer, and generating a lower layer data block including at least part of the upper layer data block and state indication information indicating a state of the upper layer data block, the state indication information being selected variably according to a logical channel through which the upper layer data block is received.

In another aspect of the invention, there is provided a data block structure transmitted from a specific layer in a transmitting side to a receiving side in a wireless communication system. The data block structure includes a first field including an identifier of a logical channel through which an upper layer data block is received, a second field including state indication information indicating a state of the upper layer data block received from an upper layer, the state indication information being selected variably according to the logical channel through which the upper layer data block is received, and at least part of the upper layer data block.

Advantageous Effects

The method for generating a data block in a wireless communication system according to the invention provides the following advantages.

First, the overhead of a header of each upper layer data block is optimized according to contents of the upper layer data block and event situations associated with the upper layer data block, thereby increasing system efficiency.

Second, the receiving side of the upper layer data block can efficiently manage radio resources using the state indication information.

DESCRIPTION OF DRAWINGS

FIG. 1 illustrates the structure of a wireless access protocol responsible for data transmission in a radio link of a Universal Mobile Telecommunication System (UMTS) which is a third generation mobile communication system.

FIG. 2 illustrates an example structure of a MAC PDU with a header added thereto in a mobile communication system.

FIG. 3 illustrates a structure of a network in an E-UMTS system in the related art.

FIG. 4 illustrates example transmission of a full header packet and a compressed header packet when a conventional header compression scheme is employed.

FIG. 5 illustrates a MAC PDU including at least one state indication information suggested in another embodiment of the invention.

FIG. 6 illustrates an example structure of a MAC PDU in an E-UMTS suggested in another embodiment of the invention.

 MODE FOR INVENTION

The above and other configurations, operations, and features of the present invention will be more easily understood from the embodiments of the invention described with reference to the accompanying drawings. The detailed description, which will be given below with reference to the accompanying drawings, is intended to explain exemplary embodiments of the present invention, rather than to show the only embodiments that can be implemented according to the invention. The embodiments described below are examples wherein the technical features of the invention are applied to an Evolved Universal Mobile Telecommunications System (E-UMTS) that is also called a “Long Term Evolution (LTE) system”. It is apparent that the technical features of the invention can also be applied to other similar mobile communication systems such as IEEE 802.16m or Wibro systems.

The E-UMTS system is an evolved version of the conventional WCDMA UMTS system and a basic standardization process thereof is in progress in the 3rd Generation Partnership Project (3GPP). For details of the technical specification of UMTS and E-UMTS, see Release 7, Release 8, and Release 9 of “3rd Generation Partnership Project; Technical Specification Group Radio Access Network”.

The technology described below can be used for various communication systems including a system using multiple antennas.

Communication systems are widely disposed to provide various communication services such as voice and packet data services. This technology can be used for downlink or uplink. The term “downlink” refers to communication from a base station to a terminal and “uplink” refers to communication from a terminal to a base station. The term “base station” generally refers to a fixed point that communicates with terminals and includes a network excluding terminals in a communication system including not only a physical transport end but also upper layers. Thus, in the invention, the network and base station are considered identical as they constitute the side opposite the terminals. Terminals may be fixed or mobile. The invention can be used in a single-carrier or multi-carrier communication system. The multi-carrier system can use Orthogonal Frequency Division Multiplexing (OFDM) or other multi-carrier modulation techniques.

FIG. 3 illustrates a structure of a network in the E-UMTS system.

The E-UMTS network can be mainly divided into an E-UTRAN and a CN. The E-UTRAN includes terminals (or User Equipments (UEs)), base stations (or eNode Bs (eNBs)), a Serving Gateway (S-GW) located at an end of the network and connected to an external network, and a Mobility Management Entity (MME) that manages mobility of UEs. One eNB may have one or more cells. eNBs are connected to each other through an X2 interface. Each eNB is connected to UEs through a radio interface and is connected to an Evolved Packet Core (EPC) through an S1 interface.

An embodiment of the invention suggests a method for generating data blocks to be transferred to a lower layer using state indication information indicating occurrence of a specific event associated with at least one upper layer data block to be transferred to a MAC layer and the type of a logical channel associated with the at least one upper layer data block.

The specific event suggested in the embodiment of the invention indicates occurrence, change, or removal of a specific situation associated with at least one of the type and contents of a logical channel carrying the upper layer data block.

The specific event may be set for each logical channel. The logical channel may be any type of logical channel such as a channel indicating system control information, a channel carrying paging (or call) information of a terminal, a channel for dedicated control information between a terminal and a base station, a channel for common control information, a channel for dedicated traffic for a specific terminal, and a channel for common traffic.

State indication information suggested in an embodiment of the invention indicates the occurrence or nonoccurrence of the specific event associated with a logical channel identified by an identifier of an upper layer data block included in a MAC header. More specifically, the MAC layer can receive an LCID that serves as an identifier of an upper layer data block for the same type of service from an upper layer and can determine which logical channel corresponds to the upper layer data block and can receive, from the upper layer, information indicating whether or not a specific situation associated with the logical channel has occurred or can determine the size or the like of radio resources required by the MAC layer to determine the value of the state indication information.

The state indication information may be one or more bits long. The number of bits of the state indication information is determined according to the number of specific events associated with the logical channel identified by the LCID. More specifically, 1 bit suffices for the state indication information if the number of specific events associated with the logical channel is 2 and 2 bits suffice if the number of specific events is 4. The number of bits of the state indication information can be changed according to the system operating mode.

A specific event for setting the state indication information suggested in an embodiment of the invention is an occasion where the upper layer data block is a voice data block. This informs the MAC layer or the receiving side of facts such as the fact that real-time processing is required and a relatively low amount of radio resources suffices compared to when the upper layer data block associated with the specific logical channel is a non-voice data block. This enables appropriate radio resource allocation.

A specific event for setting the state indication information suggested in another embodiment of the invention is an occasion where the upper layer data block is a silent data block. This increases the efficiency of resource management in a system that allocates radio resources in units of milliseconds or tens of milliseconds (possibly, in other units smaller than milliseconds or greater than tens of milliseconds) since the minimum amount of radio resources for maintaining call connection is required in the case where the upper layer data block is a silent data block.

A specific event for setting the state indication information suggested in another embodiment of the invention is an occasion where the upper layer data block is an RRC control message data block. Examples of the RRC control message include system information and RRC connection request, establishment, and release-related messages. The MAC layer or receiving side determines the priority of processing of the upper layer data block and the amount of radio resources required for the upper layer data block according to the type of the RRC control message.

A specific event for setting the state indication information suggested in another embodiment of the invention is an occasion where the upper layer data block is a Non Access Stratum (NAS) control message data block. The MAC layer or receiving side determines the priority of processing of the upper layer data block and the amount of radio resources required for the upper layer data block according to the system operating mode since the NAS control message includes protocols associated with signaling between UEs and a core network.

A specific event for setting the state indication information suggested in another embodiment of the invention is an occasion where the upper layer data block is associated with a full header data block or a compressed header data block. As described above, the PDCP layer located above the MAC layer compresses header information of an IP-based data stream such as Transmission Control Protocol (TCP)/Internet Protocol (IP) or Routing Table Protocol (RTP)/User Datagram Protocol (UDP)/IP to increase data transmission efficiency. More specifically, header compression is performed to increase transmission efficiency of IP packet data which is a data block in a wireless channel since the size of a header of an IP packet used in a wired network covers a significant proportion of the overall size of the IP packet. Header compression is based on the fact that each of the headers of packets belonging to the same packet stream has a large constant portion. Header compression is a method for reducing the overhead of headers by storing constant fields in context format in both a compressor of the transmitting side and a decompressor of the receiving side and then transmitting only changed fields after the context is created.

A PDCP entity of the transmitting side receives a PDCP SDU from an upper layer and compresses header information of the corresponding packet using a unique header compression scheme to construct a PDCP PDU and then transfers the PDCP PDU to the RLC layer.

FIG. 4 illustrates example transmission of a full header packet and a compressed header packet when a conventional header compression scheme is employed. In the following description, packets associated with header compression indicate IP-based data packets such as TCP/IP packets.

At an initial stage of header compression of a packet stream, header compression provides no benefit since the compressor transmits a full header packet to form context of the packet stream. However, after context is created, header compression provides significant benefits since the compressor transmits only compressed header packets. Which packet is to be transmitted with a full header and which packet is to be transmitted with a compressed header is determined solely by the compressor. Generally, a full header packet is transmitted when context of a packet stream is initially created and, thereafter, a full header packet is transmitted each time a predetermined time elapses while compressed header packets are transmitted so that context of the decompressor is synchronized with context of the compressor.

Upon receiving a packet from an upper layer, a PDCP compressor in a transmitting side transmits the packet together with a full or compressed header to a receiving side according to the pattern of the header of the packet. The compressor transmits the packet as a full header packet if it determines that it is necessary to create new context or update context and transmits the packet as a compressed header packet if it determines that context of the header pattern of the packet has already been created in the decompressor.

The PDCP decompressor in the receiving side needs to receive a full header packet of a packet stream to create corresponding context because the context is a basis for recovering compressed headers that will be received afterwards. If the decompressor receives a compressed header packet before context has been created, the compressor discards the received packet since it cannot reconstruct the original header of the packet.

More specifically, when a header compression scheme is used for a PS service in a radio link, the transmitting-side PDCP transmits each packet, received in a stream having the same Quality of Service (QoS) from an upper layer, as one of a packet that serves to create or update context or a packet that does not serve to create or update context. The packet that serves to create or update context can be considered much more important than the packet that does not serve to create or update context since all packets that are not to create or update context, subsequent to a packet that serves to create or update context, will be discarded without being decompressed at the receiving side if the packet that serves to create or update context has not been successfully received by the receiving side.

Therefore, the MAC layer or the receiving side is previously informed whether or not a header of an upper layer data block associated with a common or dedicated traffic channel has been compressed, thereby allowing the MAC layer or the receiving side to determine the priority of processing of the upper layer data block, the importance of the processing, the amount of radio resources that should be secured, and the like.

Table 1 illustrates an example where an LCID serving as an identifier of an upper layer data block indicates a logical channel associated with a dedicated or common traffic channel and a 2-bit state indication information indicates whether or not compression of a header has occurred as an event associated with the logical channel according to another embodiment of the invention.

TABLE 1 STATE INDICATION INFORMATION HEADER OF CURRENT OR NEXT (2 BITS) UPPER LAYER DATA BLOCK 0b00 currently transmitted upper layer data block has full header 0b01 currently transmitted upper layer data block has compressed header 0b10 next upper layer data block for transmission has full header 0b11 next upper layer data block for transmission has compressed header

A specific event for setting the state indication information suggested in another embodiment of the invention is an occasion where an AMR codec mode has been changed in an upper entity associated with the state indication information.

The AMR codec used in voice communication has one or more modes which are classified according to the size of voice information data. For example, a 136-bit upper layer data block (MAC SDU) is transferred to the MAC layer every 20 ms in a narrow-band AMR 4.75 kbps mode and a 288-bit upper layer data block (MAC SDU) is transferred to the MAC layer every 20 ms in a narrow-band AMR 12.65 kbps mode. That is, when the voice AMR code operates in one mode, the AMR codec entity generates voice information of a specific size at specific time intervals. Therefore, the size of a voice information packet transferred from the upper layer to the MAC layer is constant unless the AMR codec mode is changed. Generally, a base station or a terminal selects an AMR codec mode for use taking into consideration the amount of radio resources available in a corresponding cell, the amount of transmitted data agreed between the terminal and the base station, or the state of load in the cell. The selected AMR codec mode can be reset according to the state of the cell. Accordingly, both the base station and the terminal need to be able to cope with changes of the AMR code mode.

Voice information generated through the AMR codec (i.e., voice codec) used for voice communication has special characteristics. Voice data has two patterns, one being a talk spurt period during which somebody speaks and the other being a silent period during which nobody speaks. A voice data block containing voice information is generated every 20 ms in the talk spurt period and a silent data block containing voice information is generated every 160 ms in the silent period.

When the generated voice information corresponds to the talk spurt period, the base station will set radio resources according to the characteristics of the talk spurt period in order to efficiently use radio resources. More specifically, the base station will set radio resource information allocated to the terminal at intervals of 20 ms in consideration of the fact that a voice data block is generated every 20 ms.

In this case, if the state of the terminal is changed from the talk spurt period to the silent period, a large portion of the radio resources allocated at intervals of 20 ms will not be used since the silent data block is generated every 160 ms. Accordingly, the base station needs to immediately detect that the state of the terminal has been changed to the silent period and to immediately reset radio resources, thereby preventing waste of radio resources.

Similarly, one can consider that the base station sets scheduling resources to allow the terminal to use radio resources at intervals of 160 ms according to the silent period. In this case, if the state of the terminal is changed from the silent period to the talk spurt period, voice information transmission is delayed since the amount of resources allocated to the terminal is small although the amount of voice information to be transmitted from the terminal is large. In this case, the base station also needs to immediately reset radio resource allocation information.

Therefore, state indication information suggested in another embodiment of the invention indicates whether or not a change has been made in the voice AMR codec mode or whether or not a change has been made between the talk spurt period and the silent period.

Table 2 illustrates an example of 2-bit state indication information for an event indicating whether or not a change has been made in the AMR codec mode or whether or not a change has been made between the talk spurt period and the silent period during AMR-based voice communication using a dedicated or common traffic channel according to another embodiment of the invention.

TABLE 2 STATE INDICATION INFORMATION HEADER OF CURRENT OR NEXT (2 BITS) UPPER LAYER DATA BLOCK 0b00 no change 0b01 AMR codec mode is changed 0b10 Change is made from silent period to talk spurt period 0b11 Change is made from talk spurt period to silent period

In Table 2, an example change of the AMR codec mode is a change between a narrow-band AMR 4.75 kbps mode and a narrow-band AMR 12.65 kbps mode.

A specific event for setting the state indication information suggested in another embodiment of the invention is an occasion where an upper layer data block associated with the state indication information is an urgent control message or a non-urgent control message.

Control information communicated through a Signaling Radio Bearer (SRB) for control of configuration (or setup) between a base station and a terminal can be classified into relatively urgent control information and relatively non-urgent control information. An example of the urgent control information is control information associated with a handover command received from the base station when a terminal moves between cells, and an example of the relatively non-urgent control message is control information that the base station uses to notify one or more terminals of broadcast service channel information.

In this case, when a logical channel indicated by an identifier of an upper layer data block is a channel carrying system information such as a Broadcast Control CHannel (BCCH), 1-bit state indication information can be used to indicate whether the upper layer data block that is being currently processed or will be processed next is an urgent message.

Information regarding a specific event for setting the state indication information suggested in another embodiment of the invention can be provided to each terminal through system information or traffic information communicated between the base station and the terminal. More specifically, during RB configuration or re-configuration, the base station notifies, through an RRC configuration message, the terminal of specific events that the terminal needs to check for a specific logical channel and of relations between the events and respective state indication information values, thereby allowing the terminal to perform transmission according to the notification.

Although the upper layer data block is a MAC SDU and a data block transferred to a lower layer is a MAC PDU in the above embodiments of the invention, the invention is not necessarily applied to SDUs and PDUs of the MAC layer and may be applied to SDUs and PDUs of any other layer in which the above functions can be implemented or are needed.

FIG. 5 illustrates a structure of a MAC PDU including at least one state indication information suggested in another embodiment of the invention.

A sub-header of each upper layer data block includes a first field including an LCID as an identifier of a logical channel through which the upper layer data block is received, a second field including state indication information indicating the state of the upper layer data block, the state indication information being selected variably according to the logical channel through which the upper layer data block is received, and a third field including information indicating the size of the upper layer data block. The order of arrangement of the first to third fields shown in FIG. 5 can be changed according to system situations.

FIG. 5 illustrates example usage of state indication information having one bit indicating an event associated with each upper layer data block in a MAC PDU having three upper layer data blocks carrying 3 different logical channels.

The first upper layer data block is a TCP/IP packet and uses state indication information indicating whether or not header compression has been applied.

A logical channel capable of carrying a TCP/IP packet such as a Dedicated Traffic CHannel (DTCH) or a Common Traffic Channel (CTCH) can be indicated by an LCID of “A”. Here, “A” represents a specific binary value.

That is, when the LCID is “A”, the upper layer data block is a TCP/IP packet and an event associated with the upper layer data block includes an event regarding whether a header of the TCP/IP packet is a full header or a compressed header.

The state indication information in the first sub-head indicates a “full header” when the value of the state indication information is “1” and indicates a “compressed header” when the value of the state indication information is “0”. Alternatively, the state indication information in the first sub-head can be set to indicate a “full header” when the value of the state indication information is “0” and to indicate a “compressed header” when the value of the state indication information is “1”.

When a receiving side receives an upper layer data block whose LCID is “A”, the receiving side checks state indication information to determine whether the received upper layer data block is a full header or a compressed header and allocates radio resources according to the determination to the upper layer data block or requests that the transmitting side allocate radio resources according to the determination to the upper layer data block.

The second upper layer data block is a VoIP packet and uses state indication information for discriminating between a talk spurt period and a silent period.

The upper layer data block to which VoIP is applied uses an LCID of “B” which can indicate a logical channel capable of carrying a VoIP packet. Here, “B” represents a specific binary value.

More specifically, when the LCID in the second sub-head is “B”, the state indication information in the second sub-head indicates a “talk spurt period” if the value of the state indication information is “1” and indicates a “silent period” if the value of the state indication information is “0”. Alternatively, the state indication information in the second sub-head can be set to indicate a “talk spurt period” when the value of the state indication information is “0” and to indicate a “silent period” when the value of the state indication information is “1”.

When a receiving side receives an upper layer data block with an LCID of “B” and a state indication information value of “1”, the receiving side determines that the upper layer data block corresponds to a talk spurt period and allocates radio resources according to the talk spurt period to the upper layer data block or requests that the transmitting side allocate radio resources according to the talk spurt period.

When the state indication information value is “0”, the receiving side determines that the upper layer data block corresponds to a silent period and allocates radio resources according to the silent period or requests that the transmitting side allocate radio resources according to the silent period.

In the case of VoIP services, a talk spurt period and a silent period are defined as described above. Thus, if the current state indication information is different from state indication information of a previous transmission period, the receiving side may previously perform or request allocation of radio resources corresponding to the specific talk spurt period or the specific silent period.

The third upper layer data block relates to specific control information. Control information transmitted through a Signaling Radio Bearer (SRB) for control of configuration (or setup) between a base station and a terminal or the like can be classified into relatively urgent control information such as a handover command and relatively non-urgent control information such as broadcast service channel information as described above.

Thus, in the case of an upper layer data block using a logical channel such as a BCCH, a PCCH, a DCCH, or a CCCH, it is possible to determine, through state indication information, whether or not generation of urgent control information or non-urgent control information has occurred as an event associated with the upper layer data block. In this embodiment, the state indication information indicates an urgent message if the value of the state indication information is “1” and indicates a non-urgent message if the value of the state indication information is “0”. Alternatively, the state indication information can be set to indicate an urgent message if the value of the state indication information is “0” and to indicate a non-urgent message if the value of the state indication information is “1”.

When a receiving side receives an upper layer data block with an LCID of “C” and a state indication information value of “1”, the receiving side determines that the upper layer data block corresponds to an urgent message and allocates radio resources according to the urgent message to the upper layer data block or requests that the transmitting side allocate radio resources according to the urgent message. The receiving side may perform or request processing of the upper layer data block by priority since the upper layer data block is an urgent message and may perform or request processing of the upper layer data block stronger at a physical stage since the upper layer data block is important information.

Table 3 illustrates LCIDs and state indication information values of events associated with the LCIDs according to the above embodiment of FIG. 5 in the case where 1-bit state indication information is used as described above.

TABLE 3 state indication state indication LCID information = 1 information = 0 A full header compressed header B talk spurt period silent period C urgent non-urgent

Although the state indication information in this embodiment indicates state indication information associated with an event of an upper layer data block that is being currently processed, it may serve as control information in a specific transmission period, for example, control information after or corresponding to a specific number of Transmission Time Intervals (TTIs), each of which is a basic transmission interval of a specific transport channel in the MAC layer.

FIG. 6 illustrates a MAC header of an E-UMTS suggested in another embodiment of the invention.

A sub-head of a MAC PDU of the E-UMTS includes a 5-bit LCID field, a 1-bit E field, a 2-bit R field, a 1-bit F field, and a 7-bit (possibly, 15-bit) L field. In this embodiment, a MAC PDU includes a total of N upper layer data blocks. Therefore, a header of a MAC PDU also includes a total of N MAC PDU sub-heads. Details of the LCID field, the E field, the R field, and the L field are described above with reference to FIG. 2. In this embodiment of the invention shown in FIG. 6, one bit of the 2-bit R field is used as state indication information.

Unlike sub-heads of general MAC PDUs, the sub-header of this embodiment includes a format field F indicating the size of the length field. MAC control elements may include a Buffer Status Reporting (BSR) control element, a C-RNTI control element, a DRX command control element, and the like. The BSR provides information regarding the amount of data in an uplink buffer. The SSR control element provides information regarding the size of the buffer. The C-RNTI control element represents identification information of a new terminal which has entered a cell in a control RNC. The MAC control elements may also include other control elements as needed.

Each MAC PDU is generally processed in bytes. Therefore, when a total length of a combination of a MAC header, control elements, and MAC SDUs is not in bytes, a padding field is added to give a dummy value to the combination so that the total length is in bytes.

While the above embodiments of the present invention have been described focusing on the data communication relationship between transmitting and receiving sides for ease of explanation, the transmitting side may be a terminal or a base station in a network and the receiving side may be a base station in a network or a terminal. The terms used in the present disclosure can be replaced with other terms having the same meanings. For example, the term “terminal” may be replaced with another term such as “mobile station”, “mobile terminal”, “communication terminal”, “user equipment (UE)”, or “user device” and the term “base station” may be replaced with another term such as “fixed station”, “Node B (NB)”, or “eNode B (eNB)”.

Those skilled in the art will appreciate that the present invention may be carried out in other specific ways than those set forth herein without departing from the spirit and essential characteristics of the present invention. The above embodiments are therefore to be construed in all aspects as illustrative and not restrictive. The scope of the invention should be determined by the appended claims and their legal equivalents, not by the above description, and all changes coming within the meaning and equivalency range of the appended claims are intended to be embraced therein.

INDUSTRIAL APPLICABILITY

The present invention can be applied to a wireless communication system, and more particularly to a method for generating data blocks in a wireless communication system.

Claims

1. A method for generating a data block at a medium access control, MAC, layer of a transmitting side in a wireless communication system, the method comprising:

receiving an upper layer data block from an upper layer; and
generating the data block including a MAC header and a MAC payload, wherein the MAC payload comprises at least part of the upper layer data block and the MAC header comprises one or more sub-headers,
wherein each of the one or more sub-headers comprises: a LCID (logical channel identifier) field being used to indicate an identifier of a logical channel through which the upper layer data block is received, a 1-bit state indication information field being used to indicate a state of the upper layer data block, wherein the 1-bit value of the state indication information field is interpreted differently according to a value of the LCID field, and a L (length) field being used to indicate a size of the at least part of the upper layer data block,
wherein the state indication information field in one of the one or more sub-headers indicates whether the upper layer data block includes a full header or a compressed header when the LCID field in the same sub-header indicates the upper layer data block is received through a the logical channel related with an IP packet of the upper layer.

2. The method according to claim 1, wherein the state indication information field in one of the one or more sub-headers further indicates whether the upper layer data block has been generated in a talk spurt period or a silent period when the LCID field in the same sub-header indicates the upper layer data block is received through a logical channel related with a voice packet.

3. The method according to claim 1, wherein the state indication information field in one of the one or more sub-headers further indicates whether the upper layer data block is urgent information or non-urgent information when the LCID field in the same sub-header indicates the upper layer data block is received through a logical channel related with predetermined control information.

4. The method according to claim 1, wherein the state indication information field is included in a MAC sub-header corresponding to the upper layer data block.

Referenced Cited
U.S. Patent Documents
4205200 May 27, 1980 Parikh et al.
5588009 December 24, 1996 Will
5894595 April 13, 1999 Foladare et al.
6157833 December 5, 2000 Lawson-Jenkins et al.
6173057 January 9, 2001 Truong et al.
6233430 May 15, 2001 Helferich
6324171 November 27, 2001 Lee et al.
6353628 March 5, 2002 Wallace et al.
6526027 February 25, 2003 Yeom
6567409 May 20, 2003 Tozaki et al.
6725267 April 20, 2004 Hoang
6785256 August 31, 2004 O'Neill
6795419 September 21, 2004 Parantainen et al.
7039425 May 2, 2006 Mazawa et al.
7197317 March 27, 2007 Parkvall et al.
7245707 July 17, 2007 Chan
7373148 May 13, 2008 Kim et al.
7443813 October 28, 2008 Hwang et al.
7457588 November 25, 2008 Love et al.
7525908 April 28, 2009 Olsson et al.
7551643 June 23, 2009 Yeo et al.
7606370 October 20, 2009 Lillie et al.
7680058 March 16, 2010 Seurre et al.
7769351 August 3, 2010 Kwak et al.
7801527 September 21, 2010 Putcha
7864731 January 4, 2011 Forsberg
7899451 March 1, 2011 Hu et al.
7912471 March 22, 2011 Patabandi et al.
7916697 March 29, 2011 Eklund
7958542 June 7, 2011 Herrmann
8064676 November 22, 2011 Li et al.
8427997 April 23, 2013 Ren et al.
8582482 November 12, 2013 Hsu
8582487 November 12, 2013 Gou et al.
8588100 November 19, 2013 Wei
8614971 December 24, 2013 Kim et al.
20010012787 August 9, 2001 Wortham
20010017850 August 30, 2001 Kalliokulju et al.
20010034791 October 25, 2001 Clubb et al.
20010044322 November 22, 2001 Raaf
20020024972 February 28, 2002 Yi et al.
20020028690 March 7, 2002 McKenna et al.
20020057663 May 16, 2002 Lim
20020059464 May 16, 2002 Hata et al.
20020091860 July 11, 2002 Kalliokulju et al.
20020114294 August 22, 2002 Toskala et al.
20030007490 January 9, 2003 Yi et al.
20030007512 January 9, 2003 Tourunen et al.
20030016698 January 23, 2003 Chang et al.
20030050078 March 13, 2003 Motegi et al.
20030119488 June 26, 2003 Hans et al.
20030123485 July 3, 2003 Yi et al.
20030125056 July 3, 2003 Jiang
20030139170 July 24, 2003 Heo
20030147371 August 7, 2003 Choi et al.
20030165122 September 4, 2003 Westphal
20030165133 September 4, 2003 Garani
20030165166 September 4, 2003 Funakawa
20030189922 October 9, 2003 Howe
20030207696 November 6, 2003 Willenegger et al.
20030223452 December 4, 2003 Toskala et al.
20030227875 December 11, 2003 Wei et al.
20040014452 January 22, 2004 Lim et al.
20040028078 February 12, 2004 Beckmann et al.
20040039830 February 26, 2004 Zhang et al.
20040042507 March 4, 2004 Pelletier et al.
20040087320 May 6, 2004 Kim et al.
20040100940 May 27, 2004 Kuure et al.
20040117860 June 17, 2004 Yi et al.
20040121771 June 24, 2004 Song et al.
20040147269 July 29, 2004 Kim
20040148427 July 29, 2004 Nakhjiri et al.
20040176112 September 9, 2004 Beckmann et al.
20040180675 September 16, 2004 Choi et al.
20040185837 September 23, 2004 Kim et al.
20040202107 October 14, 2004 Bensimon et al.
20040229605 November 18, 2004 Hwang et al.
20040233870 November 25, 2004 Willenegger
20040242195 December 2, 2004 Chun et al.
20040253959 December 16, 2004 Hwang et al.
20050009527 January 13, 2005 Sharma
20050018624 January 27, 2005 Meier et al.
20050032555 February 10, 2005 Jami et al.
20050037767 February 17, 2005 Kim et al.
20050041610 February 24, 2005 Lee et al.
20050041681 February 24, 2005 Lee et al.
20050053029 March 10, 2005 Lee et al.
20050063347 March 24, 2005 Sarkkinen et al.
20050070253 March 31, 2005 Farnsworth et al.
20050085254 April 21, 2005 Chuah et al.
20050094670 May 5, 2005 Kim
20050100048 May 12, 2005 Chun et al.
20050141462 June 30, 2005 Aerrabotu et al.
20050141471 June 30, 2005 Virtanen et al.
20050141538 June 30, 2005 Beckmann et al.
20050151541 July 14, 2005 Brinz et al.
20050160184 July 21, 2005 Walsh et al.
20050164719 July 28, 2005 Waters
20050176430 August 11, 2005 Lee et al.
20050176474 August 11, 2005 Lee et al.
20050185620 August 25, 2005 Lee et al.
20050232271 October 20, 2005 Kettunen et al.
20050238051 October 27, 2005 Yi et al.
20050249188 November 10, 2005 Hayashi
20050265294 December 1, 2005 Hu et al.
20050286470 December 29, 2005 Asthana et al.
20050288022 December 29, 2005 Ryu et al.
20060013165 January 19, 2006 Choi et al.
20060034335 February 16, 2006 Karaoguz et al.
20060039309 February 23, 2006 Lee et al.
20060067324 March 30, 2006 Kim et al.
20060067364 March 30, 2006 Jung et al.
20060087994 April 27, 2006 Barth et al.
20060098567 May 11, 2006 Willenegger et al.
20060098688 May 11, 2006 Parkvall et al.
20060126554 June 15, 2006 Motegi et al.
20060126570 June 15, 2006 Kim et al.
20060142019 June 29, 2006 Kroth et al.
20060165045 July 27, 2006 Kim et al.
20060187846 August 24, 2006 Pelletier et al.
20060195540 August 31, 2006 Hamilton et al.
20060203760 September 14, 2006 Fukui et al.
20060209870 September 21, 2006 Lee et al.
20060218271 September 28, 2006 Kasslin et al.
20060245417 November 2, 2006 Conner et al.
20060251105 November 9, 2006 Kim et al.
20060262811 November 23, 2006 Jiang
20070041349 February 22, 2007 Kim et al.
20070041382 February 22, 2007 Vayanos et al.
20070047452 March 1, 2007 Lohr
20070047493 March 1, 2007 Park et al.
20070047582 March 1, 2007 Malkamaki
20070060139 March 15, 2007 Kim et al.
20070064631 March 22, 2007 Tseng et al.
20070064665 March 22, 2007 Zhang et al.
20070155389 July 5, 2007 Zhang
20070155390 July 5, 2007 Patabandi et al.
20070165567 July 19, 2007 Tan et al.
20070165635 July 19, 2007 Zhang et al.
20070177569 August 2, 2007 Lundby
20070178875 August 2, 2007 Rao et al.
20070206531 September 6, 2007 Pajukoski et al.
20070224993 September 27, 2007 Forsberg
20070248075 October 25, 2007 Liu et al.
20070254679 November 1, 2007 Montojo et al.
20070258591 November 8, 2007 Terry et al.
20070291634 December 20, 2007 Kwon et al.
20070291646 December 20, 2007 Ohishi et al.
20070291673 December 20, 2007 Demirhan et al.
20070291695 December 20, 2007 Sammour et al.
20070291719 December 20, 2007 Demirhan et al.
20070291728 December 20, 2007 Dalsgaard et al.
20070291729 December 20, 2007 Dalsgaard et al.
20070291788 December 20, 2007 Sammout et al.
20070293224 December 20, 2007 Wang et al.
20080004058 January 3, 2008 Jeong et al.
20080009289 January 10, 2008 Kashima et al.
20080043619 February 21, 2008 Sammour et al.
20080056198 March 6, 2008 Charpentier et al.
20080056273 March 6, 2008 Pelletier et al.
20080064390 March 13, 2008 Kim
20080076359 March 27, 2008 Charpentier et al.
20080089285 April 17, 2008 Pirskanen et al.
20080089292 April 17, 2008 Kitazoe et al.
20080095185 April 24, 2008 DiGirolamo et al.
20080101268 May 1, 2008 Sammour et al.
20080167089 July 10, 2008 Suzuki et al.
20080181127 July 31, 2008 Terry et al.
20080182594 July 31, 2008 Flore et al.
20080186946 August 7, 2008 Marinier et al.
20080188223 August 7, 2008 Vesterinen et al.
20080225744 September 18, 2008 DiGirolamo et al.
20080225765 September 18, 2008 Marinier et al.
20080240439 October 2, 2008 Mukherjee et al.
20080259912 October 23, 2008 Wang et al.
20080267126 October 30, 2008 Vujcic
20080267405 October 30, 2008 Vialen et al.
20080268850 October 30, 2008 Narasimha et al.
20080273610 November 6, 2008 Malladi et al.
20080280567 November 13, 2008 Sharma
20080285691 November 20, 2008 Onggosanusi et al.
20080287091 November 20, 2008 Suzuki et al.
20080287129 November 20, 2008 Somasundaram et al.
20080310452 December 18, 2008 Vedantham et al.
20080316959 December 25, 2008 Bachl et al.
20090005051 January 1, 2009 Voyer et al.
20090022107 January 22, 2009 Kapoor et al.
20090034466 February 5, 2009 Lindskog et al.
20090040982 February 12, 2009 Ho et al.
20090086659 April 2, 2009 Pani et al.
20090086710 April 2, 2009 Ho
20090092076 April 9, 2009 Zheng et al.
20090109912 April 30, 2009 DiGirolamo et al.
20090124259 May 14, 2009 Attar et al.
20090143074 June 4, 2009 Pelletier et al.
20090163199 June 25, 2009 Kazmi et al.
20090175183 July 9, 2009 Mochizuki et al.
20090181710 July 16, 2009 Pani et al.
20090207771 August 20, 2009 Lindskog
20090239538 September 24, 2009 Motegi et al.
20090264164 October 22, 2009 Chun et al.
20090318170 December 24, 2009 Lee et al.
20100027413 February 4, 2010 Park et al.
20100046384 February 25, 2010 Lee et al.
20100061285 March 11, 2010 Maeda et al.
20100061330 March 11, 2010 Hanov
20100067495 March 18, 2010 Lee et al.
20100075635 March 25, 2010 Lim et al.
20100128669 May 27, 2010 Chun et al.
20100137016 June 3, 2010 Voyer et al.
20100165901 July 1, 2010 Kim
20100195568 August 5, 2010 Imori
20100227614 September 9, 2010 Chun et al.
20100238799 September 23, 2010 Sebire
20100238903 September 23, 2010 Kitazoe
20100254340 October 7, 2010 Park et al.
20100265896 October 21, 2010 Park et al.
20100272004 October 28, 2010 Maeda et al.
20100309877 December 9, 2010 Damnjanovic et al.
20110039536 February 17, 2011 Lee et al.
20110090836 April 21, 2011 Mochizuki et al.
20110116436 May 19, 2011 Bachu et al.
20110182243 July 28, 2011 Gallagher et al.
20110207427 August 25, 2011 Kitani et al.
20110261743 October 27, 2011 Futaki et al.
20120002589 January 5, 2012 Saifullah et al.
Foreign Patent Documents
1549612 November 2004 CN
1719932 January 2006 CN
1751460 March 2006 CN
1731887 August 2006 CN
1835627 September 2006 CN
0 889 664 January 1999 EP
1 148 753 October 2001 EP
1 168 877 January 2002 EP
1 209 938 May 2002 EP
1 304 898 April 2003 EP
1315356 May 2003 EP
1315356 May 2003 EP
1 318 632 June 2003 EP
1337124 August 2003 EP
1 372 310 December 2003 EP
1 420 551 May 2004 EP
1 501 328 January 2005 EP
1499144 January 2005 EP
1511245 March 2005 EP
1 720 373 November 2006 EP
1720322 November 2006 EP
1720373 November 2006 EP
1932380 June 2008 EP
2087653 August 2009 EP
6-006294 January 1994 JP
2002-539686 November 2002 JP
2003-504935 February 2003 JP
2003-087180 March 2003 JP
2003-196775 July 2003 JP
2003-235064 August 2003 JP
2004-134904 April 2004 JP
2005-39726 February 2005 JP
2005-057787 March 2005 JP
2005-260906 September 2005 JP
2005-318131 November 2005 JP
2005-354488 December 2005 JP
2006-505979 February 2006 JP
2006-067115 March 2006 JP
2006-528456 December 2006 JP
2007-165635 June 2007 JP
2008-535370 August 2008 JP
2008-539678 November 2008 JP
2009-540721 November 2009 JP
2009-542100 November 2009 JP
10-2000-0039404 July 2000 KR
10-2001-0015234 February 2001 KR
10-2001-0105240 November 2001 KR
10-2002-0001173 January 2002 KR
10-2002-0014939 February 2002 KR
10-2003-0005537 January 2003 KR
10-2003-0026924 April 2003 KR
10-2003-0080165 October 2003 KR
10-2003-0093604 December 2003 KR
10-2004-0005834 January 2004 KR
10-2004-0039944 May 2004 KR
10-2004-0048675 June 2004 KR
10-2004-0072858 August 2004 KR
10-2004-0086950 October 2004 KR
10-2005-0008440 January 2005 KR
10-2005-0019560 March 2005 KR
10-2005-0027972 March 2005 KR
10-2005-0053376 June 2005 KR
10-2005-0063174 June 2005 KR
10-2005-0073244 July 2005 KR
10-0595646 July 2005 KR
10-2005-0096763 October 2005 KR
10-2005-0100552 October 2005 KR
10-2005-0100552 October 2005 KR
10-2005-0100861 October 2005 KR
10-2005-0106845 November 2005 KR
10-2006-0024756 March 2006 KR
10-2006-0024756 March 2006 KR
10-2006-0026722 March 2006 KR
10-2006-0048373 May 2006 KR
10-2006-0073472 June 2006 KR
10-2006-0091525 August 2006 KR
10-2007-0006850 January 2007 KR
10-2007-0047669 May 2007 KR
2249917 April 2005 RU
9904584 January 1999 WO
00/74416 December 2000 WO
01/78252 October 2001 WO
02/39622 May 2002 WO
02091659 November 2002 WO
03100988 December 2003 WO
2004017581 February 2004 WO
2004/028050 April 2004 WO
2004/043094 May 2004 WO
2004064272 July 2004 WO
2004091246 October 2004 WO
2004102833 November 2004 WO
2005/048613 May 2005 WO
2005067262 July 2005 WO
2005122616 December 2005 WO
2006/000876 January 2006 WO
2006/011763 February 2006 WO
2006/018670 February 2006 WO
2006049441 May 2006 WO
2006075820 July 2006 WO
2006/104344 October 2006 WO
2006/108703 October 2006 WO
2006/109851 October 2006 WO
2006/116620 November 2006 WO
2007025138 March 2007 WO
2007/052888 May 2007 WO
2007/078155 July 2007 WO
2007/078172 July 2007 WO
2007078929 July 2007 WO
2007/133034 November 2007 WO
2008/051466 May 2008 WO
2008096984 August 2008 WO
2008111684 September 2008 WO
2009084998 July 2009 WO
Other references
  • 3GPP TSG-RAN WG2 #57, R2-070778, Contention-based and Contention-free Access Procedures in LTE, NTT DoCoMo, Inc., Feb. 12-16, 2007.
  • 3GPP TSG-RAN WG2 #61, R2-080873, Timer handling for RACH procedures, Panasonic, Feb. 11-15, 2008.
  • 3GPP TSG-RAN WG2 #59, R2-073186, RACH access optimisation, IPWireless, NextWave Wireless, Jun. 20-24, 2007.
  • LG Electronics, Inc., “Scheduling Consideration on L2 Header”, 3GPP TSG-RAN WG2 #58, R2-071887, Kobe, Japan, May 2007.
  • Nokia: “Active Mode DRX”, 3GPP TSG-RAN WG2 Meeting #55, Seoul, Korea, Oct. 9-11, 2006, R2-062752.
  • NTT DoCoMo, Inc.: “Views on DRX/DTX control in LTE”, 3GPP TSG RAN WG2 #56, Riga, Lativa, Nov. 6-10, 2006, R2-063397.
  • Email Rapporteur (Nokia): “DRX in E-UTRAN”, 3GPP TSG-RAN WG2 Meeting #57, St. Louis, Missouri, Feb. 12-16, 2007, R2-070463.
  • Panasonic, “MAC PDU format for LTE”, 3GPP TSG RAN WG2 #56bis R2-070096, Jan. 2007.
  • Sammour et al., U.S. Appl. No. 60/863,185.
  • NTT Docomo et al: “MAC PD U structure for LTE”, 3GPP TSG RAN WG2 #56bis, R2-070280, Jan. 2007, XP050133369.
  • Catt et al: “Enhancement to Buffer Status Reporting”, 3GPP TSG-RAN WG2 #57bis, R2-071345, Mar. 2007, XP050134291.
  • LG Electronics Inc: “PDCP retransmissions” 3GPP Draft; R2-073041 PDCP RETRANSMISSIONS—V2, Aug. 16, 2007, XP050135778.
  • LG Electronics Inc: “Contents of PDCP Status Report R2-07xxxx”, 3GPP TSG-RAN WG2, 59, Oct. 8, 2007, pp. 1-3, XP002580785.
  • “PDCP Structure and Traffic Path” 3GPP Draft; R2-073259, Aug. 16, 2007, XP050135985.
  • Asustek: “Granularity Consideration for Variable RLC PDUsizes”; R2-070336, XP050133423.
  • “3GPP; Technical Specification Group Raido Access Network; Medium Access control (MAC) protocol specification (Release 7)”; XP050367709.
  • 3GPP Generation Partnership Project; 3Gpp Standard; 3Gpp TS 25.323, XP050367856.
  • Bosch: “Header Compression Signalling” 3GPP Draft; XP050114120.
  • Youjun Gao et al.: “Research on the access network and MAC technique for beyond 3G Systems” IEEEE Wireless Communications, IEEE Service Center, Piscataway, NJ, US, vol. 14, No. 2, Apr. 1, 2007, pp. 57-61, XP011184637 ISSN: 1536-1284.
  • 3rd Generation Partnership Project: Evolved Universal Terrestrial Radio Access (E-UTRA) Medium Access Control (MAC) protocol specification (Release 8), Technical Specification Group Radio Access Network, Mar. 1, 2008, XP050377617.
  • XP002460800; Alcatel-Lucent: “Downlink Control Signaling and Multiplexing for VOIP, R1-071721” Jun. 26, 2007, pp. 1-4.
  • XP002602993; Nokia Corporation, Nokia Siemens Networks: “MAC header format, R2-073891”, 3GPP TSG—RAN WG2 meeting 59bis, Oct. 1, 2007.
  • XP050134474; LG Electronics Inc: “Support for VoIP over MAC-hsEHS” 3GPP Draft; R2-071542, Apr. 2, 2007.
  • Nokia; “Requirements for redirection in E-UTRAN”, 3GPP TSG-RAN WG2 Meeting #56-bis, R2-070107, Jan. 2007.
  • LG Electronics; “Relative Buffer Status Reporting”, 3GPP TSG-RAN WG2 meeting #46bis, R2-050852, Apr. 2005.
  • IPWireless; “Layer 2 functions for LTE”, 3GPP TSG RAN WG2 #48bis, R2-052377, Oct. 2005.
  • Samsung; “Selective forwarding/retransmission during HO”, 3GPP TSG-RAN2 Meeting #56bish, R2-070130, Jan. 2007.
  • Samsung; “Re-use of PDCP SN at ARQ level?”, 3GPP TSG-RAN2 Meeting #53bis, R2-061829, Jun. 2006.
  • Ericsson: “Initial Random Access Procedure for E-UTRAN”, 3GPP TSG-RAN WG2 #55, Seoul, Korea, Oct. 9-13, 2006, R2-062853.
  • Samsung: “LTE Random access procedure”, 3GPP TSG RAN #54, Tallinn, Estonia, Aug. 28-Sep. 2, 2006, R2-062258.
  • Siemens: “Initial Access Procedure”, 3GPP TSG-RAN WG2 LTE Adhoc meeting, Cannes, France, Jun. 27-30, 2006, R2-061931.
  • IPWireless: “Contention Resolution in Non-Synchronous RACH Access”, RAN2 #54, Tallinn, Estonia, Aug. 28-Sep. 1, 2006, R2-062269.
  • Ericsson: “MAC header for improved L2 support for high data rates”, 3GPP TSG-RAN WG2 #57, St. Louis, Missouri, Feb. 12-16, 2007, R2-070810.
  • LG Electronics: “UL Timing Control related to Contention Resolution”, 3GPP TSG-RAN WG2 #61bis, Shenzhen, China, Mar. 31-Apr. 4, 2008, R2-081607, XP050139334.
  • Nokia et al: “UL reporting rate for DL quality measurements in CELL—FACH”, 3GPP Draft; R2-071404, vol. RAN WG2, XP050134343, Mar. 26-30, 2007, St. Julian's, Malta.
  • Alcatel-Lucent: “Downlink Control Signaling and Multiplexing for VOIP R1-071721”, 3Nu Generation Partnership Project (3GPP) Technicalspecification Group (TSG) Radio Access Network (RAN); Workinggroup 1 (WG1), No. 48bis, Mar. 26, 2007, pp. 1-4, XP002460800.
  • Nokia Corporation, Nokia Siemens Networks: “MAC Header Format, R2-073891”, #GPP TSG-RAN WG2 meeting 59bis, Oct. 1, 2007, XP002602993.
  • LG Electronics Inc.: “Support for VOIP Over MAC-hs/ehs”, 3GPP Draft; R2-071542 Support for VOIP Over MAC-HS, 3rd Generation Partnership Project (3GPP), Mobile Competence Centre; vol. RAN WG2, no. St. Julian; Apr. 2, 2007, XP050134474.
  • Nokia: “RACH reporting”, 3GPP Draft; 24A000008, 3rd Generation Partnership Project (3GPP), XP050141261, Sophia Antipolis, France.
  • 3GPP; “Packet Data Convergence Protocol (PDCP) Specification (Release 7)”, 3GPP TS 25.323, XP050367856, Mar. 1, 2007.
  • LG Electronics, DRX Scheme, 3GPP TSG-RAN WG2#56 R2-063248, Nov. 10, 2006.
  • Samsung: “DRX operations for connected mode UEs in LTE”, 3GPP DRAF; R2-063120 DRX for Connected UE, 3rd Partnership Project (3GPP), XP050132629, Meeting #56, Nov. 6-10, 2006, Riga, Latvia.
  • Ericssion: “Enhanced Paging Procedure”, 3GPP Draft; R2-070586, 3rd Generation Partnership Project (3GPP), Feb. 12-16, 2007, St. Louis, Missouri.
  • Ericssion: “Issues on DRX in ITE Active”, 3GPP Draft; R2-070797, 3rd Generation Partnership Project (3GPP), Feb. 12-16, 2007, St. Louis, Missouri.
  • LG Electronics Inc: “PDCP retransmissions.” 3GPP Draft; R2-073041 PDCP Retransmissions V2, Aug. 16, 2007, XP050135778.
  • NEC, Fast setup for PS services (Cell PCH & URA PCH), 3GPP TSG-RAN WG2#53 R2-061124. May 12, 2006.
  • ZTE: “MAC state transition Document: For Discussion”, 3GPP Draft; R2-060064, 3rd Generation Partnership Project (3GPP), vol. RAN WG2, XP050130225, Jan. 5, 2006.
  • “Summary of email discussion on DRX control”, 3GPP Draft: R2-07XXXX DRX Control LTE V6, 3rd Generation Partnership Project (3GPP), XP050602959, Mar. 23, 2007, p. 3.
  • Samsung, Contention resolution in a RACH, 3GPP TSG-RAN WG2#57bis R2-071386, Mar. 30, 2007.
  • TD Tech, Contention Resolution and Initial Random Access, 3GPP TSG-RAN WG2#57 R2-070910, Feb. 19, 2007.
  • IP Wireless, Initial Access Procedure and C-RNTI Allocation, 3GPP TSG-RAN WG2#56bis R2-070301, Jan. 19, 2007.
  • Ericssion: “Initial, Random Access and Identity Handling”, 3GPP Draft; R2-060592, (3GPP), XP050130549, Feb. 9, 2006.
  • R2-061986, “Initial Access Procedure”, LG Electronics, Jun. 27-30, 2006.
  • 3rd Generation Partnership Project “Radio Interface Protocol Aspects” 3GPP TR 25.813, May 29, 2006.
  • Ericsson “DRX and DTX in LTE—Active”, R2-060967, Mar. 27, 2006.
  • “ARQ operation and HARQ”, 3GPP TSG RAN WG2#55; R2-062843, 3rd Generation Partnership (3GPP), Oct. 9, 2006, pp. 1-4.
  • “LTE Handover procedures, text proposal”, 3GPP Draft; R2-061338 TP For TR 25813 on LTE Handover-FD, 3R ° Generation Partnership Project (3GPP), Mobile Competence Centre; 650, Route Des Lucioles; F-06921 Sophia-Antipolis Cedex; France, vol. Ran WG2, no. Shanghai, China; 20060504, May 4, 2006, XP050131278, [retrieved on May 4, 2006] “p. 1, lines 7-10, paragraph 2”; “p. 1, lines 15-16, paragraph 2”; “p. 1, lines 27-30, paragraph 2”; p. 3, lines 6-9*.
  • Samsung: “UL Timing Sync Procedure”, Internet Citation, Mar. 27, 2006, XP002434793, Retrieved from the Internet: UR L: http://www.3gDp.ocgiftp/tsg ran/WG2 RL2/TSGR2 52/Documents/ [retrieved on May 23, 2007] “p. 1, paragraph 1”; *p. 3, paragraph 2.3*; “p. 4, lines 5-6, paragraph 3” .
  • R2-063034, “Open issues in random access procedure”, Qualcomm Europe, Oct. 91″ to 131″ 2006 Entirety.
  • LG Electronics, Multi-level DRX Operation in CELL—PCH, 3GPP TSG-RAN WG2 #58, R2-071930, May 7-11, 2007.
  • NEC, Fast setup for PS services (Cell PCH & URA PCH), 3GPP TSG-RAN2 Meeting #54, Tdoc R2-062328, Aug. 28, 2006-Sep. 6, 2006.
  • Catt, “Non-synchronized access and C-RNTI allocation”, 3GPP TSG-RAN WG2 #55, Seoul, Korea, Oct. 9-13, 2006, R2-062933.
  • LG Electronics, “DRX Scheme”, 3GPP TSG-RAN WG2 #56bis, Jan. 15-19, 2007, Sorrento, Italy, R2-070265.
  • Nokia, “Discontinuous reception in CELL—FACH”, 3GPP TSG-RAN WG2 Meeting #58, St. Julian's, Malta, Mar. 26-30, 2007, R2-071403.
  • Catt, “Non-synchronized access and C-RNTI allocation”, 3GPP WSG-RAN WG2, #55, Seoul, Korea, Oct. 9-13, 2006, R2-062933.
  • NTT DoCoMo, Inc: “E-mail discussion on U-plane ciphering location for LTE”, 3GPP TSG RAN WG2 #57bis, St. Julian's, Malta, Mar. 26-30, 2007, R2-071293.
  • LG Electronics: “U-plane ciphering at MAC/Physical Layer”, 3GPP TSG RAN WG2 #57bis, St. Julian's, Malta, Mar. 26-30, 2007, R2-071550.
  • LG Electronics: “Discussion on Message 4 in Random Access”, 3GPP TSG-RAN WG2, #57, St. Louis, Missouri, Feb. 15-19, 2007, R2-070519.
  • LG Electronics: “Discussion on Message 4 in Random Access”, 3GPP TSG-RAN WG2, #57bis, St. Julian's Malta, Mar. 26-30, 2007, R2-071456.
  • LG Electronics: “Discussion on Message 4 in Random Access”, 3GPP TSG-RAN WG2, #58, Kobe, Japan, May 7-11, 2007, R2-071923.
Patent History
Patent number: RE45347
Type: Grant
Filed: Dec 20, 2013
Date of Patent: Jan 20, 2015
Assignee: LG Electronics Inc. (Seoul)
Inventors: Sung Duck Chun (Anyang-si), Young Dae Lee (Anyang-si), Sung Jun Park (Anyang-si), Seung June Yi (Anyang-si)
Primary Examiner: Ricky Ngo
Assistant Examiner: Iqbal Zaidi
Application Number: 14/137,548
Classifications
Current U.S. Class: Assembly Or Disassembly Of Messages Having Address Headers (370/474); Determination Of Communication Parameters (370/252)
International Classification: H04J 3/24 (20060101);