Patent Application
20100278111
Radio communication systems, such as a wireless data networks (e.g., Third Generation Partnership Project (3GPP) Long Term Evolution (LTE) systems, spread spectrum systems (such as Code Division Multiple Access (CDMA) networks), Time Division Multiple Access (TDMA) networks, WiMAX (Worldwide Interoperability for Microwave Access), etc.), provide users with the convenience of mobility along with a rich set of services and features. This convenience has spawned significant adoption by an ever growing number of consumers as an accepted mode of communication for business and personal uses. To promote greater adoption, the telecommunication industry, from manufacturers to service providers, has agreed at great expense and effort to develop standards for communication protocols that underlie the various services and features. One area of effort involves the construction of data units, which are necessary to exchange information over the network. The fields and associated formats of these data units are designed to ensure reliable transmission, while minimizing overhead (i.e., maximizing throughput). Segmentation of the data units is a mechanism that provides protocol compatibility at the various protocol layers, as different protocols are likely to have different size requirements for payload and overhead fields. However, segmentation increases protocol overhead, and thus, wasting precious bandwidth.
Therefore, there is a need for an approach for selectively applying segmentation to minimize signaling overhead.
According to one embodiment of the invention, a method comprises generating a protocol data unit. The method also comprises inserting a dummy padding sub-header within a header of the protocol data unit.
According to another embodiment of the invention, an apparatus comprises a packet generator configured to generate a protocol data unit, and to insert a dummy padding sub-header within a header of the protocol data unit.
According to another embodiment of the invention, a method comprises receiving a protocol data unit that includes a dummy padding sub-header within a header of the protocol data unit.
According to yet another embodiment of the invention, a system comprises a base station configured to receive a protocol data unit that includes a dummy padding sub-header within a header of the protocol data unit.
Still other aspects, features, and advantages of the invention are readily apparent from the following detailed description, simply by illustrating a number of particular embodiments and implementations, including the best mode contemplated for carrying out the invention. The invention is also capable of other and different embodiments, and its several details can be modified in various obvious respects, all without departing from the spirit and scope of the invention. Accordingly, the drawings and description are to be regarded as illustrative in nature, and not as restrictive.
The embodiments of the invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings:
An apparatus, method, and software for padding a protocol data unit are disclosed. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the invention. It is apparent, however, to one skilled in the art that the embodiments of the invention may be practiced without these specific details or with an equivalent arrangement. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the embodiments of the invention.
Although the embodiments of the invention are discussed with respect to a communication network having a Third Generation Partnership Project (3GPP) Long Term Evolution (LTE) architecture, it is recognized by one of ordinary skill in the art that the embodiments of the inventions have applicability to any type of communication system and equivalent functional capabilities.
The UE 101 and eNB 103 include packet generators 105, 107 for generating data units (e.g., data packets). According to one embodiment, each of the packet generators includes padding logic 109, 111, which can operate at the Medium Access Control (MAC) layer to perform padding of a MAC PDU either by padding the MAC header (or sub-header) or the payload part or both. The MAC layer protocol is further detailed in 3GPP TS 36.321, entitled “Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA) Medium Access Control (MAC) protocol specification,” v.2.0.0 (Release 8); which is incorporated herein by reference in its entirety. By way of example, a Radio Link Control (RLC) sub-layer, as implemented by the packet generator 105, 107, uses dynamic PDU sizing to build each PDU according to the requested size by a lower layer protocol.
In general, a Service Data Unit (SDU) of a protocol layer is defined within a data unit, and is received from a next higher protocol layer. The protocol layer processes the SDU, which in case of a Radio Link Control (RLC) protocol, may require segmentation of the SDU into fragments. As a result of the protocol processing, the SDU is transformed or partitioned into one or more PDUs. These fragments are provided with an RLC header, which contains a sequence number, and form the payload or content of an RLC PDU. These RLC PDUs are processed in the MAC layer, which attaches a MAC header. Thereafter, the RLC PDUs (with or without MAC header) are provided as MAC SDUs to a subjacent protocol layer.
As evident from the above discussion, to allow for the transfer of variable size data blocks, the Radio Link Control (RLC) layer provides a segmentation and re-assembly multiplexing function. The segmentation and re-assembly multiplexing function reduces the size of the data unit prior to transmission RLC and is used when the transferred data block is larger than the maximum allowed Transport Block (TB) size. The segmentation size can be determined by the difference between the RLC PDU size and the header size of the RLC PDU. The size of the MAC PDU may be determined from a sum of the RLC PDU size, and the size of the MAC header. The padding function in MAC layer increases the data block or segmented data block size by padding with extra or “dummy” bits to fit a TB size. The RLC sub layer uses PDU size to build each PDU to the requested size by the lower layer. Each PDU can have multiple SDUs (Service Data Units) and segmentation of SDUs can be employed to fit within a given TB size.
In effect, using a relatively small RLC PDU results in a lower transfer data to control information ratio, consequently resulting in a less efficient use of radio resources. Likewise, the greater the difference between the transferred data block size and the next larger allowed TB size results in lowering the transfer data to used physical resources ratio consequently resulting in a less efficient use of radio resources. Therefore, maximizing the TB size is desired. The segmentation causes decreasing the size of the TB, thereby increasing RLC and MAC signaling overhead. Radio Resource Control (RRC) signaling is required between the UE 101 and eNB 103 to define the attributes of each established transport channels, including a list of potential transport block (TB) sizes. Alternatively, the list of TB sizes may be specified in the standard (as in High-Speed Downlink Packet Access (HSDPA) or High-Speed Uplink Packet Access (HSUPA)). Each transport block unit is transmitted in a given Transmission Time Interval (TTI). Signaling over the radio interface introduces system overhead, which reduces the physical resources available for user data transmission.
As shown, the MAC PDU header 203 includes one or more MAC PDU sub-headers 207 for each corresponding payload element; where each sub-header is defined as a combination of header information elements. By way of example, the sub-header includes the following header fields: a Logical Channel ID (LCID), an Extension bit (E) and Reserved bits (R) i.e., LCID/E/R/R. The LCID field identifies the logical channel instance of the corresponding MAC SDU or the type of the corresponding MAC Control element or padding for the DL (Down Link) and UL-SCH (Up Link Shared Channel), respectively. The intermediate sub-headers have the following format: LCID/E/R/R/F/L (where F denotes a Format field and L denotes a Length field). In general, all the sub-headers, except the last one, utilize the F and L fields. In an exemplary embodiment, a maximum of one MAC PDU can be transmitted per TB per UE, depending on the physical layer category.
To better appreciate the padding mechanism, MAC PDUs are further described with respect to encapsulation of RLC PDUs.
In another embodiment, a MAC PDU 307 has the following header fields 309: LCID/E/R/R/F/L/LCID/E/R/R. As such, the MAC PDU size totals the size of the RLC PDU 311 plus 4 bytes. This MAC PDU 307 holds a relatively reduced RLC PDU 311 and can be used e.g., for various real-time applications, such as Voice over Internet Protocol (VoIP), as well as any RLC unacknowledged mode (UM) or acknowledged mode (AM) data if the RLC PDU is shorter than the requested (for instance, a last RLC SDU of a data burst or shorter VoIP packet). The F field, as a single bit, can be set (e.g., to “1”) to indicate the size of the Length field. It is noted that one F field is utilized per MAC SDU, with the exception of the last MAC SDU.
In the example of MAC PDU 301, no padding is needed. With the MAC PDU 307, padding of one byte is utilized after inserting the RLC PDU and the necessary MAC header fields (LCID/E/R/R and F/L). This can be implemented by adding the normal MAC header indicating padding (LCID reserved for padding +E=0), but no actual padding is needed at the end of the MAC PDU. Padding bytes are added at the end of the MAC PDU when more padding is needed.
The L field indicates the length of the corresponding MAC SDU or MAC Control element (e.g., in bytes). According to one embodiment, there is one L field per MAC SDU included in the MAC PDU 307, except for the last MAC SDU. For MAC Control elements, the presence of an L field depends on the type of MAC Control element. The size of the L field is indicated by the F field.
The Extension (E) field is a flag that specifies whether more fields are present in the MAC header. The E field can be used not only for the extension of the next LCID/E/R/R, but also for the associated Format field (F)/Length field (L). For instance, if E is set to “1,” F/L and another set of LCID/R/R/E fields follow. However, if E is set to “0,” either a MAC SDU, a MAC control element or padding start at the next byte. In this example, the difference in length of the MAC PDU based on the setting of the extension field (i.e., E=“0” and E=“1”) is 2-bytes due to the F and L fields, and 1-byte due to the sub-header indicating padding.
If a single RLC PDU is 1 byte shorter than MAC PDU, then no length field is needed since the TB size indicates the length. If the difference is 4 bytes or more (as shown in
If the difference of RLC PDU and MAC PDU is 2 or 3 bytes, it is not possible to indicate with the existing standard. In other words, the scenarios in which the difference between the MAC PDU size and the RLC PDU size is 2 and 3 bytes cannot be supported with the above described approach without applying segmentation. As mentioned, segmentation increases overhead. Alternatively, a larger MAC PDU size, and thus also larger TB size, can be used. This is especially true in the downlink where the eNB can decide the TB size freely. However, the use of a larger TB size simply to accommodate a (unnecessary) larger MAC header size is also wasting capacity.
To avoid the unnecessary segmentation or unnecessary increase of MAC header and PDU size, an enhancement for the padding mechanism is proposed.
On the receive side, when the UE 101 receives the data unit, as in step 511, the UE 101 removes the padding (per step 513). It should be noted that the transmitter can also be the UE and the receiver the eNB, in fact, this may be a more typical case.
In
Traditionally, segmentation of the MAC PDUs 601, 607 would be required. By contrast, the padding mechanism involves determining the payload size according to the lowest data rate by eliminating Format (F) field and Length (L) fields; the maximum RLC PDU size can be achieved by bypassing segmentation according to what is considered optimal for the radio resource usage.
Normally the extension flag E=1 indicates that an F-flag and a length field follow as well as another sub-header (LCID/E/R/R). In this special case with padding (LCID=11111) E=1 does not indicate that F and L follow, but only that another sub-header (LCID/E/R/R) follows. Thus the receiver when reading the header notices from the special value of LCID (=11111) that next sub-header follows immediately (without F and L fields). In this instance, it is assumed that the same LCID value as for normal padding is used also in this special case. This has the advantage that no extra LCIDs need to be reserved. However, it is also possible to reserve another LCID for this purpose.
In principle, the special (dummy) padding sub-header could be in any position within the header. However, if e.g., in
The normal padding is indicated by inserting the padding sub-header (LCID=11111, E=0) at the end of the MAC header. It indicates that the extra bytes at the end of the MAC PDU not included in the MAC header, MAC control PDUs or MAC SDUs (=RLC PDU) are padding. The dummy padding sub-header, according to certain embodiments, can use the same special value of LCID=11111, and be placed at the beginning of the MAC header.
Alternatively, padding of 1 or 2 bytes can be indicated through the use of a special value of the length field L. For example, if one byte padding is needed, F could be set to F=0 to indicate that short L field follows; and L could be set to a reserved value, e.g., L=0000000 or L=1111111 as shown in
Similarly (as shown in
A common feature for these different dummy padding sub-headers described above is that the MAC PDUs with the dummy padding sub-header do not have any (data) padding bytes at the end of the MAC PDU. Thus, the dummy padding sub-headers introduce the padding of the MAC PDU into the MAC header instead of the normal padding at the end of the MAC PDU in the payload part. It is noted that one byte of the normal padding can be in the MAC header in the form of the normal padding sub-header, and the rest can be in the payload part at the end of the MAC PDU.
The MME (Mobile Management Entity)/Serving Gateways 701 are connected to the eNBs 103 in a full or partial mesh configuration using tunneling over a packet transport network (e.g., Internet Protocol (IP) network) 703. Exemplary functions of the MME/Serving GW 701 include distribution of paging messages to the eNBs 103, termination of U-plane packets for paging reasons, and switching of U-plane for support of UE mobility. Since the GWs 701 serve as a gateway to external networks, e.g., the Internet or private networks 703, the GWs 701 include an Access, Authorization and Accounting system (AAA) 705 to securely determine the identity and privileges of a user and to track each user's activities. Namely, the MME Serving Gateway 701 is the key control-node for the LTE access-network and is responsible for idle mode UE tracking and paging procedure including retransmissions. Also, the MME 701 is involved in the bearer activation/deactivation process and is responsible for selecting the SGW (Serving Gateway) for a UE at the initial attach and at time of intra-LTE handover involving Core Network (CN) node relocation.
A more detailed description of the LTE interface is provided in 3GPP TR 25.813, entitled “E-UTRA and E-UTRAN: Radio Interface Protocol Aspects,” which is incorporated herein by reference in its entirety.
In
The basic architecture of the system 702 contains following network elements. As seen in
The MME 708, as a key control node, is responsible for managing mobility UE identifies and security parameters and paging procedure including retransmissions. The MME 708 is involved in the bearer activation/deactivation process and is also responsible for choosing Serving Gateway 710 for the UE 101. MME 708 functions include Non Access Stratum (NAS) signaling and related security. MME 708 checks the authorization of the UE 101 to camp on the service provider's Public Land Mobile Network (PLMN) and enforces UE 101 roaming restrictions. The MME 708 also provides the control plane function for mobility between LTE and 2G/3G access networks with the S3 interface terminating at the MME 708 from the SGSN (Serving GPRS Support Node) 714.
The SGSN 714 is responsible for the delivery of data packets from and to the mobile stations within its geographical service area. Its tasks include packet routing and transfer, mobility management, logical link management, and authentication and charging functions. The S6a interface enables transfer of subscription and authentication data for authenticating/authorizing user access to the evolved system (AAA interface) between MME 708 and HSS (Home Subscriber Server) 716. The S10 interface between MMEs 708 provides MME relocation and MME 708 to MME 708 information transfer. The Serving Gateway 710 is the node that terminates the interface towards the E-UTRAN 712 via S1-U.
The S1-U interface provides a per bearer user plane tunneling between the E-UTRAN 712 and Serving Gateway 710. It contains support for path switching during handover between eNBs 712. The S4 interface provides the user plane with related control and mobility support between SGSN 714 and the 3GPP Anchor function of Serving Gateway 710.
The S12 is an interface between UTRAN 706 and Serving Gateway 710. Packet Data Network (PDN) Gateway 718 provides connectivity to the UE 101 to external packet data networks by being the point of exit and entry of traffic for the UE 101. The PDN Gateway 718 performs policy enforcement, packet filtering for each user, charging support, lawful interception and packet screening. Another role of the PDN Gateway 718 is to act as the anchor for mobility between 3GPP and non-3GPP technologies such as WiMax and 3GPP2 (CDMA 1X and EvDO (Evolution Data Only)).
The S7 interface provides transfer of QoS policy and charging rules from PCRF (Policy and Charging Role Function) 720 to Policy and Charging Enforcement Function (PCEF) in the PDN Gateway 718. The SGi interface is the interface between the PDN Gateway and the operator's IP services including packet data network 722. Packet data network 722 may be an operator external public or private packet data network or an intra operator packet data network, e.g., for provision of IMS (IP Multimedia Subsystem) services. Rx+ is the interface, between the PCRF and the packet data network 722.
As seen in
The eNB 103 communicates with the aGW 701 (Access Gateway) via an S1 interface. The aGW 701 includes a User Plane 701a and a Control plane 701b. The control plane 701b provides the following components: SAE (System Architecture Evolution) Bearer Control 735 and MM (Mobile Management) Entity 737. The user plane 701b includes a PDCP (Packet Data Convergence Protocol) 739 and a user plane functions 741. It is noted that the functionality of the aGW 701 can also be provided by a combination of a serving gateway (SGW) and a packet data network (PDN) GW. The aGW 701 can also interface with a packet network, such as the Internet 743.
In an alternative embodiment, as shown in
In the system of
The eNB 103 interfaces via the S1 to the Serving Gateway 745, which includes a Mobility Anchoring function 747. According to this architecture, the MME (Mobility Management Entity) 749 provides SAE (System Architecture Evolution) Bearer Control 751, Idle State Mobility Handling 753, and NAS (Non-Access Stratum) Security 755.
One of ordinary skill in the art would recognize that the processes for padding may be implemented via software, hardware (e.g., general processor, Digital Signal Processing (DSP) chip, an Application Specific Integrated Circuit (ASIC), Field Programmable Gate Arrays (FPGAs), etc.), firmware, or a combination thereof. Such exemplary hardware for performing the described functions is detailed below with respect to
The computing system 800 may be coupled via the bus 801 to a display 811, such as a liquid crystal display, or active matrix display, for displaying information to a user. An input device 813, such as a keyboard including alphanumeric and other keys, may be coupled to the bus 801 for communicating information and command selections to the processor 803. The input device 813 can include a cursor control, such as a mouse, a trackball, or cursor direction keys, for communicating direction information and command selections to the processor 803 and for controlling cursor movement on the display 811.
According to various embodiments of the invention, the processes described herein can be provided by the computing system 800 in response to the processor 803 executing an arrangement of instructions contained in main memory 805. Such instructions can be read into main memory 805 from another computer-readable medium, such as the storage device 809. Execution of the arrangement of instructions contained in main memory 805 causes the processor 803 to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the instructions contained in main memory 805. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the embodiment of the invention. In another example, reconfigurable hardware such as Field Programmable Gate Arrays (FPGAs) can be used, in which the functionality and connection topology of its logic gates are customizable at run-time, typically by programming memory look up tables. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
The computing system 800 also includes at least one communication interface 815 coupled to bus 801. The communication interface 815 provides a two-way data communication coupling to a network link (not shown). The communication interface 815 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information. Further, the communication interface 815 can include peripheral interface devices, such as a Universal Serial Bus (USB) interface, a PCMCIA (Personal Computer Memory Card International Association) interface, etc.
The processor 803 may execute the transmitted code while being received and/or store the code in the storage device 809, or other non-volatile storage for later execution. In this manner, the computing system 800 may obtain application code in the form of a carrier wave.
The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to the processor 803 for execution. Such a medium may take many forms, including but not limited to non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks, such as the storage device 809. Volatile media include dynamic memory, such as main memory 805. Transmission media include coaxial cables, copper wire and fiber optics, including the wires that comprise the bus 801. Transmission media can also take the form of acoustic, optical, or electromagnetic waves, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, CDRW, DVD, any other optical medium, punch cards, paper tape, optical mark sheets, any other physical medium with patterns of holes or other optically recognizable indicia, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave, or any other medium from which a computer can read.
Various forms of computer-readable media may be involved in providing instructions to a processor for execution. For example, the instructions for carrying out at least part of the invention may initially be borne on a magnetic disk of a remote computer. In such a scenario, the remote computer loads the instructions into main memory and sends the instructions over a telephone line using a modem. A modem of a local system receives the data on the telephone line and uses an infrared transmitter to convert the data to an infrared signal and transmit the infrared signal to a portable computing device, such as a personal digital assistant (PDA) or a laptop. An infrared detector on the portable computing device receives the information and instructions borne by the infrared signal and places the data on a bus. The bus conveys the data to main memory, from which a processor retrieves and executes the instructions. The instructions received by main memory can optionally be stored on storage device either before or after execution by processor.
While the invention has been described in connection with a number of embodiments and implementations, the invention is not so limited but covers various obvious modifications and equivalent arrangements, which fall within the purview of the appended claims. Although features of the invention are expressed in certain combinations among the claims, it is contemplated that these features can be arranged in any combination and order.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/IB08/00014 | 1/4/2008 | WO | 00 | 7/6/2010 |
