Abstract:
Presented are methods and apparatus for decoupling transport and control (T&amp;C) functions from a plurality of eNBs and collecting the T&amp;C functions in a centralized entity for managing the T&amp;C functions for a larger pool of eNBs. An enhanced interface and protocol is defined for allowing the new T&amp;C pool entity to communicate with the eNBs over a shared IP based network. The redistributed functionality provides for optimizing both data compression capabilities and security by compressing data earlier in its transmission path and by encrypting data before it is sent to an eNB.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
       [0001]    This application is a continuation of U.S. patent application Ser. No. 13/495,184, filed Jun. 13, 2012, which claims priority to Ser. No. 11/642,202, filed Dec. 20, 2006, now U.S. Pat. No. 8,213,300, issued Jul. 3, 2012, the entirety of which both are incorporated herein by reference. 
     
    
     TECHNICAL FIELD 
       [0002]    The present invention relates generally to telecommunications systems, and in particular, to methods, systems, devices and software for decoupling Packet Data Convergence Protocol (PDCP) and Radio Link Control (RLC) protocol functions from an eNode-B entity. 
       BACKGROUND 
       [0003]    Existing Third Generation Partnership Program (3GPP) universal terrestrial radio access networks (UTRAN)  100 , such as a wideband code division multiple access (WCDMA) network or a universal mobile telecommunications system (UMTS) network, depicted in prior art  FIG. 1 , split the UTRAN  102  into two entities. The first entity is a Radio Network Controller (RNC)  104  and the second entity is a node-B  106 . The RNC  104  controls the node-B  106  devices to which it is connected by providing radio resource management and a portion of the mobility management functions. The RNC  104  also provides data encryption/decryption services to protect the user data from being compromised while in transit to and from the user equipment (UE)  108 . The node-B  106  provides the transmitter and the receiver for communicating with the UEs  108  within the defined area of the cell. In order to facilitate the handover of a UE  108  from one node-B  106  to another node-B  106  under the control of a different RNC  104 , as the UE  108  changes geographical location, the RNCs  104  must communicate with both the core network  110  and the neighboring RNCs  106 . 
         [0004]    In contrast to the 3GPP UTRAN  100  of  FIG. 1 , the Long Term Evolution (LTE) based evolved universal terrestrial radio access networks (EUTRAN)  100  architecture, depicted in prior art  FIG. 2 , has removed the RNC  104  from the LTE network. The functionality of the RNC  104  has been distributed to both core network elements, such as the Mobility Management Entity (MME)  202 , and the evolved node-B (eNB)  204 . In a complicating factor, the introduction of a portion of the RNC  106  functionality into the eNB  204  has resulted in the requirement for new inter-eNB interfaces  206  and complex hand-off signaling protocols for exchanging information between eNBs  204  as the UE  108  moves around a cell and transitions from one eNB  204  to another. 
         [0005]    Further, the traditional LTE radio access network (RAN) is comprised of distributed eNBs  204  connected to MMEs  202 /serving gateways (S-GW) entities via the S1 interface  208  with the eNBs  204  connected to each other with the X2 interface  206 . The LTE eNB  204  hosts functions to support Transport and Control (T&amp;C) capabilities such as Radio Resource Management (RRM) (i.e., radio bearer control, radio admission control, connection mobility control and dynamic allocation of resources to UEs  108  in both uplink and downlink), Internet Protocol (IP) header compression and encryption of user data stream, selection of MME  202  at UE  108  attachment when no routing to an MME  202  can be determined from the information provided by the UE  108 , routing of user plane data toward the S-GW  202 , scheduling and transmission of paging messages originating from the MME  202 , scheduling and transmission of broadcast information originated from the MME  202  or Operations and Maintenance (O&amp;M) and measurement and measurement reporting configuration for mobility and scheduling. 
         [0006]    As depicted in prior art  FIG. 3  of existing 3GPP eNB  302  functions  300 , the eNB  302  embodies the T&amp;C functions required by an LTE network such that a common shared UTRAN  102  RNC  104  is not required. Specifically, the eNB  302  includes Radio Resource Control (RRC)  304  functions for managing mobility and radio resources for the UEs  108  in the eNBs  302  cell coverage area and Packet Data Coverage Protocol (PDCP)  306  functions to provide L3 services to the lower layers for user and control plane messages. Examples of the L3 services are in-sequence delivery of data including duplicate detection and elimination, user plane IP header compression and ciphering of user and control plane data and integrity protection of user and control plane data. Each eNB  302  traditionally supports a small number of cells that cover a tightly coupled geographical area. The cell count per eNB  302  is usually limited, e.g., three cells per eNB  302  and the RRC  304  and PDCP  306  functions embedded in the eNB  302  are limited to supporting the cells controlled by the eNB  302  and the UE  108  associated with those cells. 
         [0007]    Problems associated with the previously described architectures are magnified by the projected growth in the use of these services. Wireless broadband traffic is projected to more than double every year for the foreseeable future. Keeping pace with this growth will require a proportional increase in the number of cells in any given geographical area. With the introduction of LTE advanced features to support heterogeneous networks and the requirement for a larger number of cells, the number of cells in a given geographical area is expected to increase over one hundred times with the number of inter-cell mobility events increasing proportionally. 
         [0008]    Another emerging problem associated with an eNB  302  providing mobility management functions is the evolutionary trend of network deployments which include Multiple Radio Access Technology (Multi-RAT), i.e., mobility between different radio access technologies such as WCDMA, WiFi and CDMA. The issue arises because the LTE eNB  302  architecture includes mobility management functions. As a result, part of the mobility coordination is distributed at the eNB  302  level requiring the eNB  302  to be aware of each of the hardware technologies. 
         [0009]    Another issue related to problems with the existing architecture associated with increasing cell density is the number of user context (e.g., security keys, Robust Header Compression (ROHC), RRC  304  and session state) transfers between eNBs  302  increase as the number of mobility events increases. The successful and time sensitive of this data is critical for maintaining user sessions while the UE  108  is from one eNB  302  coverage area to another. Failure to meet the transfer requirements results in dropped calls or sessions. However, meeting this requirement is complex and error prone and engineering a RAN to provide the necessary high levels of mobility performance requires a relatively static network and significant operational overhead. LTE networks, however, are now in a growth portion of their lifecycle so consequently, maintaining mobility performance in networks that are inherently non-static will be problematic and expensive for network operators. Further, MME/S-GW nodes  202  are currently architected to handle a relatively limited number of S1 interfaces. Consequently, these nodes will struggle to perform efficiently with one hundred times the number of eNBs  302  deployed. 
         [0010]    As depicted in prior art  FIG. 4 , the interface  410  between the PDCP  406  and the RLC  408  is defined as an internal software interface associated with an eNB  402 . Accordingly, there is no protocol or transport specified for this interface, i.e., there is no way to distribute the RRC  404  and the PDCP  406  functions outside of the eNB  402 . It should be noted in the depicted prior art eNB  402  that the interfaces between the functions are not defined by the 3GPP specifications and no mechanism exists allowing the functions to be located in physically separate network elements. 
         [0011]    Market pressure is building for a solution that performs efficiently under the previously described conditions allowing better network performance with lower operating costs and a greater reliability compared to previously described solutions. 
       ABBREVIATIONS/ACRONYMS 
       [0012]    3GPP Third Generation Partnership Program 
         [0013]    CDMA Code Division Multiple Access 
         [0014]    DRB Data Radio Bearer 
         [0015]    EUTRAN Evolved Universal Terrestrial Radio Access Network 
         [0016]    GPRS General Packet Radio Service 
         [0017]    GTP GPRS Tunnelling Protocol 
         [0018]    IANA Internet Assigned Numbers Authority 
         [0019]    IP Internet Protocol 
         [0020]    LTE Long Term Evolution 
         [0021]    MAC Medium Access Layer 
         [0022]    MME Mobility Management Entity 
         [0023]    Multi-RAT Multiple Radio Access Technology 
         [0024]    O&amp;M Operation and Maintenance 
         [0025]    PDCP Packet Data Convergence Protocol 
         [0026]    PDU Protocol Data Unit 
         [0027]    PHY Physical Layer 
         [0028]    RAN Radio Access Network 
         [0029]    RBS Radio Base Station 
         [0030]    RLC Radio Link Control 
         [0031]    RNC Radio Network Controller 
         [0032]    ROHC Robust Header Compression 
         [0033]    RRC Radio Resource Control 
         [0034]    RRM Radio Resource Management 
         [0035]    SCTP Stream Control Transmission Protocol 
         [0036]    S-GW Serving Gateway 
         [0037]    SRB Signal Radio Bearer 
         [0038]    T&amp;C Transport and Control Functions 
         [0039]    TEID Tunnel Endpoint Identifier 
         [0040]    UDP User Datagram Protocol 
         [0041]    UE User Equipment 
         [0042]    UMTS Universal Mobile Telecommunications System 
         [0043]    UTRAN Universal Terrestrial Radio Access Network 
         [0044]    WCDMA Wideband Code Division Multiple Access 
         [0045]    WiFi Trademark for Wireless IEEE 802.11 Standards 
       SUMMARY 
       [0046]    According to one exemplary embodiment, a server for managing transport functions for a plurality of eNodeBs (eNBs) over a shared network comprises: a processor configured to execute computer instructions and a memory configured to store said computer instructions wherein said computer instructions further comprise: a Packet Data Convergence Protocol (PDCP) component configured to manage the transport functions for the plurality of eNBs in a manner which is decoupled from said plurality of eNBs; and a signaling protocol component configured to transmit transport packets between said server and said plurality of eNBs over said shared network. 
         [0047]    According to another exemplary embodiment, a method, stored in a memory and executing on a processor, for centralizing transport and control (T&amp;C) functions for management of a plurality of enhanced eNodeBs (eNBs) and their associated cells comprising: disposing said T&amp;C functions associated with each of said plurality of eNBs at one or more T&amp;C pool entities; coordinating mobility events associated with said plurality of eNBs between said one or more T&amp;C pool entities using an interface; and transmitting control signaling and data packets between said plurality of eNBs and said one or more T&amp;C pool entities using a protocol across a shared network associated with said control signaling and data packets. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0048]    The accompanying drawings illustrate exemplary embodiments, wherein: 
           [0049]      FIG. 1  depicts a prior art UMTS network architecture; 
           [0050]      FIG. 2  depicts a prior art E-UTRAN; 
           [0051]      FIG. 3  depicts a prior art 3GPP eNB and its associated functions; 
           [0052]      FIG. 4  depicts a prior art 3GPP LTE software layering architecture; 
           [0053]      FIG. 5  depicts an exemplary M-eNB providing the transport and control functions between a MME/S-GW and a large group of cells; 
           [0054]      FIG. 6  depicts an exemplary embodiment of a 3GPP E-UTRAN software layering separation with a dedicated T&amp;C pool entity; 
           [0055]      FIG. 7  depicts an exemplary embodiment of a MME server and a S-GW server integrated with PDCP and RRC functions; 
           [0056]      FIG. 8  depicts an exemplary embodiment of an inter-nodal PDCP-RLC interface between a T&amp;C pool entity and an eNB; 
           [0057]      FIG. 9  depicts an exemplary embodiment of T&amp;C pool interfaces and protocols for PDCP-PDU messaging for a control plane and a user plane; 
           [0058]      FIG. 10  depicts an exemplary embodiment of separate Transport and Control entities with a PDCP control interface; 
           [0059]      FIG. 11  depicts an exemplary embodiment of a GTPv1-P protocol entity for exchanging PDCP-PDUs; 
           [0060]      FIG. 12  depicts an exemplary embodiment of a S1AP-P protocol entity for exchanging PDCP-PDUs; 
           [0061]      FIG. 13A  depicts an exemplary embodiment of standalone separate Transport and Control entities using a dedicated interface for PDCP control data exchange; 
           [0062]      FIG. 13B  depicts an exemplary embodiment of Control functions integrated with MME and standalone Transport entity; 
           [0063]      FIG. 13C  depicts an exemplary embodiment of Transport functions integrated with S-GW and standalone Control entity; 
           [0064]      FIG. 13D  depicts an exemplary embodiment of Control functions integrated with MME and Transport functions integrated with S-GW; 
           [0065]      FIG. 14  depicts an exemplary method embodiment for centralizing transport and control functions; and 
           [0066]      FIG. 15  depicts an exemplary computing environment for implementing methods for centralizing transport and control functions. 
       
    
    
     DETAILED DESCRIPTION 
       [0067]    The following detailed description of the exemplary embodiments refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. Also, the following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims. 
         [0068]    Reference throughout the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of the present invention. Thus, the appearance of the phrases “in one embodiment” or “in an embodiment” in various places throughout the specification are not necessarily all referring to the same embodiment. Further, the particular features, structures or characteristics may be combined in any suitable manner in one or more embodiments. 
         [0069]    The exemplary embodiments described herein have a common set of characteristics that can be associated with the exemplary embodiments. Looking now to  FIG. 5  and one exemplary embodiment, the PDCP and the RRC functions can be decoupled from the eNB entity. In one aspect of the network  500  exemplary embodiment, the computer processing associated with the RRC and the PDCP functions is depopulated from the eNB. It should be noted in the exemplary embodiment that the depopulated PDCP and RRC functions (L3) from a plurality of eNBs are also known as the T&amp;C pool. Continuing with the exemplary embodiment, the eNBs become simpler to manage because they are focused on only the L1 and L2 functions. A new entity, a managed eNB (M-eNB)  502 , handles the L3 T&amp;C pool functions. Next in the exemplary embodiment, the L3 T&amp;C pool functions can be implemented using general purpose hardware platforms or embedded into existing network elements. Continuing with the exemplary embodiment, the L3 T&amp;C pool functions are centralized so they provide L3 services to a much larger number of eNBs and correspondingly to a much larger number of cells  506 . 
         [0070]    Continuing with the exemplary embodiment, the M-eNB  502  can correlate the physical, media access and radio link measurements from a large number of eNBs (cells), carriers and RATs allowing the M-eNB  502  to make first stage radio resource allocations (e.g. frequency selective scheduling) across a large number of eNBs (cells). It should be noted in the exemplary embodiment that the resource allocations are relatively long-lived, on the order of hundreds of milliseconds to seconds. It should further be noted in the exemplary embodiment that the transport function can be physically separated from the control function, exploiting the fact that transport traffic data and control traffic data volumes and their associated processor and memory requirements are not symmetric. 
         [0071]    Continuing with the exemplary embodiment, the T&amp;C pool function manages the correct transmission end user state and end user traffic during mobility events, therefore eliminating the requirement of eNB to eNB transfer of state and traffic data. Next in the exemplary embodiment, a modified interface X2′  504  is deployed between M-eNBs  502  with the number of inter-T&amp;C connections being relatively few. Continuing with the exemplary embodiment, protocols are defined for transmitting control signaling and data packets between the eNBs and the T&amp;C pool functions through a shared IP based network. It should be noted in the exemplary embodiment that existing 3GPP specifications do not provide a signaling protocol for transmitting T&amp;C packets through a shared network. 
         [0072]    Next in the exemplary embodiment, it should be noted that the LTE T&amp;C functions are dedicated to IP packet processing at layer 3 (network layer) and above for the data plane. For example, data plane security should be performed at a network location that is secure and protected from unauthorized access. Continuing with the exemplary embodiment, LTE data plane functions also include but are not limited to generation and management of encryption and integrity keying material for end user sessions and accordingly, by performing these functions centrally, the data plane packets are secure during transmission to the eNBs. This feature of the exemplary embodiment provides a greater level of security than the existing LTE network, which distributes this functionality between the MME  510  and the eNB with integrity keying material sent from the operator&#39;s core network to the eNBs, leaving user&#39;s data packets without 3GPP security applied until they reach the eNB. 
         [0073]    According to one exemplary embodiment, IP packet compression using RoHC offers better performance when compression (signal overhead savings) is accomplished as close to the operator&#39;s network as possible and where mobility events do not require the complex RoHC state transfer from one eNB to another. It should be noted in the exemplary embodiment that RoHC state context is transparent to eNB mobility events. 
         [0074]    According to an exemplary embodiment, the T&amp;C architecture comprises a T&amp;C entity such as an M-eNB  502  encompassing PDCP and RRC functions for one or more eNBs. It should be noted in this exemplary embodiment that the northbound S1 interfaces  508  from the M-eNB  502  to the MME/S-GW  510  remain unchanged. 
         [0075]    Looking now to  FIG. 6 , an exemplary embodiment of the 3GPP E-UTRAN software layering separation  600  for a dedicated T&amp;C pool entity, such as an M-eNB  602  is depicted. It should be noted in the exemplary embodiment that the software layering separation  600  is divided between an evolved control plane  604  and an evolved data plane  606  from the MME  608  to the UE  612  in the evolved control plane  604  and from the S-GW  610  to the UE  614  in the evolved data plane  606 . Next in the exemplary embodiment, the M-eNB  602  comprises a C pool  616  in the evolved control plane  604  and a T pool  618  in the evolved data plane  606 . Next in the exemplary embodiment, the C pool  616  comprises an RRC component  620  and a PDCP component  622 . Continuing with the exemplary embodiment, the T pool  618  comprises a GTP  624  and a PDCP  626 . It should be noted in the exemplary embodiment that the RoHC and the encryption/integrity flows from the M-eNB  602  to the UE  612 ,  614 . 
         [0076]    Continuing with the exemplary embodiment, a single eNB can be dedicated as the T&amp;C provider for a group of eNBs. In this exemplary embodiment architecture, all but one of the eNBs in the group can use the resources of the T&amp;C eNB. This exemplary embodiment is especially useful when a network is comprised of existing eNBs and is being augmented with heterogeneous style small cells. In this exemplary embodiment, the T&amp;C eNB acts as a controller and maintains the T&amp;C context for a large number of smaller and simpler eNB elements, providing for the distribution of the lower layer radio functions while acting as a single point for upper layer control and resource management. 
         [0077]    Looking now to  FIG. 7 , an exemplary embodiment of extending the existing MME  702 , S-GW  704  and MME/S-GW  706  nodes responsibilities by integrating the T&amp;C functions (PDCP/RRC) for one or more cells is depicted. It should be noted in the exemplary embodiment that the S1 interface associated with these nodes becomes an internal logical interface within the MME  702 , S-GW  704  and MME/S-GW  706  nodes. 
         [0078]    Looking now to  FIG. 8  for another aspect of the exemplary embodiment, a signaling protocol  800  for transmitting the T&amp;C packets over a shared IP network. The exemplary embodiment comprises new interfaces between an eRBS  802  (i.e., eNB) and the T&amp;C pool functions  804  and specifies protocols for PDCP-PDU  806  message exchange over an IP network  808 . Further in the exemplary embodiment, an interface and protocol  810  is defined for exchanging PDCP control data between the user plane transport and the control plane functions for applications when these functions are not co-located. It should be noted in the exemplary embodiment that the IP network  808  can use UDP  812  or SCTP  814  over the IP network  808 . 
         [0079]    Looking now to  FIG. 9  for another aspect of the exemplary embodiment, new interfaces and protocols  900  are depicted. Continuing with the exemplary embodiment, the 3GPP TS 36.412 “S1 Signaling Transport” and TS 36.413 “S1 Application Protocol (S1AP)” for the control plane, incorporated herein by reference and 3GPP TS 36.414 “S1 Data Transport” and TS 29.281 “General Packet Radio System Tunneling Protocol User Plane (GTPv1-U)” for the user plane, incorporated herein by reference, are extended to support transporting PDCP-PDUs through the E-UTRAN network, i.e., exchanging PDCP-PDU messages between network nodes across a shared communications network such as but not limited to an IP network. It should be noted in the exemplary embodiment that these extended interfaces and protocols are labeled as Sx-PDCP-c  902  for the control plane and Sx-PDCP-u  904  for the user plane. It should further be noted in the exemplary embodiment that the Sx-PDCP-c  902  interface and protocol provides communication capabilities between the T&amp;C pool functions  906  and the eNB  914  in the control plane and the Sx-PDCP-u  904  interface and protocol provides communication capabilities between the T&amp;C pool functions  908  and the eNB  916  in the user plane. 
         [0080]    Continuing with the exemplary embodiment, although the S1-MME interface and protocol between the T&amp;C pool functions  906  and the MME  910  and the S1-U interface and protocol between the T&amp;C pool functions  908  and the S-GW  912  remains unchanged, the T&amp;C pool functions  906 ,  908  can be integrated with existing network elements such as but not limited to a UTRAN RNC or a UTRAN MME and S-GW (e.g. the control functions RRC and PDCP for RRC can be integrated with the RNC and the user plane traffic PDCP functions can be integrated with the S-GW). It should be noted in the exemplary embodiment that the extended interfaces  902 ,  904  can exist as a single physical interface using either the same or different protocols. It should further be noted that the T&amp;C pool  906 ,  908  is a functional entity rather than a physical node and can be located in a separate, stand-alone node or integrated and co-located within existing nodes such as but not limited to the MME  910  and the S-GW  912 . 
         [0081]    Looking now to  FIG. 10 , an exemplary embodiment with the control plane and user plane functions instantiated in separate nodes  1000  is depicted. Continuing with the exemplary embodiment, an interface is defined to exchange PDCP control data between the control node  1002  and the transport node  1004 . It should be noted in the exemplary embodiment that this node is labeled the PDCP Ctrl  1006 . It should further be noted in the exemplary embodiment that this interface can use, but is not limited to, the GTPv1-P protocol or the S1AP-P protocol for exchanging PDCP control data between the nodes  1002 ,  1004 . It should also be noted in the exemplary embodiment that when the transport and/or control entity is integrated into the S-GW or the MME node, the PDCP control data can be included as new information elements within the existing S11 interface, i.e., 3GPP TS 23.401, incorporated herein by reference, and TS 36.300, incorporated herein by reference. 
         [0082]    Continuing with the exemplary embodiment, the PDCP-PDUs can be encapsulated and transported using the existing GTPv1-U protocol and/or S1AP protocol with modifications. It should be noted in the exemplary embodiment that the control and user plane traffic messages sent over the interfaces can be sent using the modified 3GPP TS 36.414 S1-U interface protocol described herein. In an alternative exemplary embodiment, the control and user plane traffic messages sent over the Sx-PDCP-c and Sx-PDCP-u interfaces can be sent using the modified 3GPP TS 36.412 signaling transport and the TS 36.413 S1AP interface protocol as described herein. In another aspect of the exemplary embodiment, the control messages sent over the Sx-PDCP-c interface can be sent over the modified 3GPP TS 36.412 S1AP interface protocol as described herein while the user plane messages sent over the Sx-PDCP-u interface can be sent over the modified 3GPP TS 36.414 S1-U interface protocol described herein. It should be noted in the exemplary embodiment that the message sequences between the T&amp;C pool and the RBS (eNB) match those of the S1AP and the GTPv1-U specifications. 
         [0083]    In another aspect of the exemplary embodiment, the T&amp;C pool entity can efficiently discriminate the traffic from existing traditional eNB cells using a standard S1-U and S1-C interface from M-eNB cells described herein, this ability provides for a simpler network deployment by allowing the multiplexing of traffic from all existing eNB cells and M-eNB cells to interface with a T&amp;C pool entity. Further in the exemplary embodiment, as eNB cells are upgraded to use the T&amp;C pool for their PDCP and RRC functions, the T&amp;C pool does not require any reconfiguration for its&#39; interfaces to the subject eNB. 
         [0084]    Looking now to  FIG. 11 , an exemplary embodiment GTPv1-P protocol entity  1100  for exchanging PDCP-PDUs is depicted. The exemplary embodiment protocol entity  1100 , based on the GTPv1-U protocol, is used to define GTPv1-P tunnels for carrying encapsulated PDCP-PDU messages between a given pair of GTPv1-P entities. Continuing with the exemplary embodiment, the GTPv1-P protocol entity  1100  provides packet transmission and reception services to PDCP  1106  and RLC  1108  entities in the T&amp;C pool  1102  and the M-eNB  1104 . Next in the exemplary embodiment, the GTPv1-P protocol entity receives traffic from a number of GTPv1-P tunnel endpoints and transmits traffic to a number of GTPv1-P tunnel endpoints. It should be noted in the exemplary embodiment that providing for the coexistence of existing GTPv1-U interfaces and the GTPv1-P interface described herein, the message header comprises an indication of the message contents so the existing GTPv1-U messages can be distinguished from the GTPv1-P messages. 
         [0000]    
       
         
               
             
               
               
             
               
               
               
               
               
               
               
               
               
             
               
               
               
               
               
               
               
             
               
               
             
           
               
                 TABLE 1 
               
             
             
               
                   
               
               
                 Example GTPv1-P Header 
               
             
          
           
               
                   
                 Bits 
               
             
          
           
               
                 Octets 
                 8 
                 7 
                 6 
                 5 
                 4 
                 3 
                 2 
                 1 
               
               
                   
               
             
          
           
               
                 1 
                 Version 
                 0 
                 1 
                 0 
                 0 
                 0 
               
             
          
           
               
                 2 
                 Message Type 
               
               
                 3 
                 Length (1st Octet) 
               
               
                 4 
                 Length (2nd Octet) 
               
               
                 5 
                 Tunnel Endpoint Identifier (1st Octet) 
               
               
                 6 
                 Tunnel Endpoint Identifier (2nd Octet) 
               
               
                 7 
                 Tunnel Endpoint Identifier (3rd Octet) 
               
               
                 8 
                 Tunnel Endpoint Identifier (4th Octet) 
               
               
                   
               
             
          
         
       
     
         [0085]    Continuing with the exemplary embodiment and as illustrated in Table 1, GTPv1-P packets can be distinguished from GTPv1-U packets by setting the fourth bit of the first octet to one. In another aspect of the exemplary embodiment, the message type field shown in the second octet can be used to indicate the type of PDCP-PDU contained in the GTPv1-P packet, e.g., SRB PDCP data PDUs, seven or twelve bit sequence number DRB PDCP data PDUs, RoHC feedback packet PDCP control PDUs or PDCP status report PDCP control PDUs. Continuing with the exemplary embodiment, the TEID present in the GTPv1-P header unambiguously identifies which PDCP and RLC instance maintains a given TEID, i.e., the TEID uniquely identifies a radio bearer. 
         [0086]    In another exemplary embodiment, each PDCP-PDU is encapsulated within a GTPv1-P header at the sending node. In one aspect of the exemplary embodiment the fourth bit in the first octet of the GTPv1-P header is set to one to indicate that this GTPv1-P packet contains a PDCP-PDU payload. It should be noted in the exemplary embodiment that this bit position is currently reserved and unused and will be inspected by only the M-eNB and the T&amp;C pool entities. Continuing with the exemplary embodiment, the GTPv1-P packet is then further encapsulated in UDP and IP, according to the GTPv1-U specifications, before transmission toward the packet destination. 
         [0087]    Next in the exemplary embodiment, the destination UDP port can be the same as the GTPv1-U specifications (3GPP TS 29.281, included herein by reference), i.e., UDP port 2152 or a different port can be used, e.g., a port chosen from within the IANA Registered Ports Range of 1024 to 49151. It should be noted in the exemplary embodiment, that choosing a different destination port than the port used by the GTPv1-U protocol, the receiving node, e.g., the T&amp;C pool entity or the S-GW, can distinguish messages at the UDP network layer allowing the flexibility to route the message internally within the node for more efficient processing. It should further be noted in the exemplary embodiment that the IP and UDP headers are removed at the receiving end of the communication and if the GTPv1-P packet was received at a port mutually agreed upon for exchanging PDCP-PDUs, the receiving entity can assume that the received packet contains a PDCP-PDU. 
         [0088]    Continuing with the exemplary embodiment, the GTPv1-P header can also indicate that the payload of the packet contains a PDCP-PDU. Next in the exemplary embodiment, the payload contents are passed to the PDCP functional entity responsible for processing PDCP-PDUs and based upon the Message Type and the TEID fields in the packet header, the PDCP-PDU can be associated with the unique PDCP or RLC instance for that PDCP-PDU. 
         [0089]    Looking now to  FIG. 12 , a diagram of PDCP-PDU messaging based on S1AP/S1-MME protocol  1200  is depicted. The exemplary embodiment comprises a MME node  1202 , a T&amp;C Pool node  1204 , an M-eNB node  1206  and a UE node  1208 . It should be noted in the exemplary embodiment that the M-eNB node is also known as an evolved RBS node or an evolved eNB node. Continuing with the exemplary embodiment, in order for the T&amp;C pool and evolved eNB to exchange PDCP-PDUs with the existing S1AP protocol and S1-MME interface, a number of extensions are required to the S1AP protocol and optionally to the S1-MME interface. It should be noted in the exemplary embodiment that the extended protocol is named S1AP-P herein. 
         [0090]    In another aspect of the exemplary embodiment, the S1AP protocol has signaling messages comprising fields of Message Type, MME UE S1AP ID and eNB UE S1AP ID that will be configured and interpreted in an extended fashion when the payload contains PDCP-PDU data in order to exchange PDCP-PDUs using S1AP/S1-MME. Next in the exemplary embodiment, the SCTP port can be the same as the S1AP specifications (3GPP TS 36.412, included herein by reference), i.e., UDP port 36412 or a different port can be used, e.g., a port chosen from within the IANA Registered Ports Range of 1024 to 49151. It should be noted in the exemplary embodiment, that choosing a different destination port than the port used by the S1AP protocol, the receiving node, e.g., the T&amp;C pool entity or the evolved eNB, can distinguish messages at the UDP network layer allowing the flexibility to route the message internally within the node for more efficient processing. 
         [0091]    Continuing with the exemplary embodiment, the SCTP payload protocol identifier can be different and the PDCP-PDU shall not be ASN.1 encoded. It should be noted in the exemplary embodiment that the PDCP-PDU shall be contained be contained within the modified S1AP packets as unmodified byte aligned data. It should further be noted in the exemplary embodiment that the modifications to the existing S1AP header fields allow for the S1AP and S1AP-P traffic to be terminated and processed separately by the same entity, e.g., the T&amp;C pool entity. 
         [0092]    Looking now to  FIG. 13 , four exemplary PDCP control interfaces where the transport and control entities are separated by a shared network are depicted. It should be noted in the exemplary embodiment that PDCP control data can be exchanged via either one or a combination of the GTPv1-P, S1AP-P and the s11 interface protocols. Continuing with the exemplary embodiment and looking to  FIG. 13A , the PDCP control data is exchanged between the T  1304  and C  1306  nodes using either GTPv1-P or S1AP-P messaging  1302 . Next, looking to  FIG. 13B  of the exemplary embodiment, the PDCP control data is exchanged between the T node  1308  and the MME+C node  1310  using GTPv1-P messaging  1314  between the T node  1308  and the S-GW node  1312  and the S11 interface messaging  1316  between the S-GW node  1312  and the MME+C node  1310 . Continuing with  FIG. 13C  of the exemplary embodiment, the PDCP control data is exchanged between the SGW+T  1318  and the C node  1320  using S1AP-P protocol messaging  1324  between the C node  1320  and the MME node  1322  and S11 interface messaging  1326  between the MME node  1322  and the S-GW+T node  1318 . Next, looking to  FIG. 13D  of the exemplary embodiment, the PDCP control data is exchanged between the S-GW+T node  1324  and the MME+C  1326  node using the S11 protocol messaging  1328  between the S-GW+T node  1324  and the MME+C node  1326 . It should be noted in the exemplary embodiment that for each of the aforementioned configurations the transport and control functions can similarly be integrated with a UTRAN RNC node. Continuing with the exemplary embodiment, the RNC can integrate the control functions for the LTE network while the transport is optimally routed directly between the S-GW containing the transport functions and the eNB. In another aspect of the exemplary embodiment, the transport functions can be integrated into an eNB. 
         [0093]    Embodiments described herein can provide various advantages and benefits. For example, T&amp;C functions can scale to support very large numbers of eNB cells, potentially tens of thousands; smaller, simpler and cheaper eNBs because fewer functions residing at the eNB; end user data plane security is applied at a centralized entity without the distribution of sensitive keying material to remote, potentially less secure eNB sites, i.e., the data plane packets are secured from the T&amp;C function to the UE; IP layer 3 and layer 4 services, such as but not limited to RoHC can be applied nearer to the operator&#39;s core network allowing the IP network to the eNB to benefit from these services, allowing more of the network to benefit from the data compression that RoHC provides, e.g., reducing traffic in the operator&#39;s network; the T&amp;C entity can correlate PHY, MAC and RLC measurements from a large number of eNBs allowing it to make first stage radio resource allocations, e.g., frequency selective scheduling, wherein these resource allocations are relatively long lived (100 s of milliseconds to seconds) allowing the radio resources to be utilized in a more efficient manner which will increase the capacity of the eNB cells managed by the T&amp;C pool; this architecture allows the development of separate hardware platforms dedicated to either forwarding user traffic or controlling user sessions and cell resources wherein the asymmetry of the user traffic and control traffic allows the hardware platforms to be cost optimized for a specific task. It should further be noted that the protocol allows the T&amp;C pool entity to be integrated into the MME and the S-GW nodes or to be located in separate nodes. 
         [0094]    Looking now to  FIG. 14 , an exemplary method embodiment  1400  for centralizing transport and control functions for efficient management of a plurality of eNBs and their associated cells is depicted. First at step  1402  of the exemplary method embodiment  1400 , the transport and control functions contained in the eNB are decoupled from each of the plurality of eNBs and relocated to the T&amp;C pool entities. It should be noted in the exemplary method embodiment  1400  that a T&amp;C pool entity can be but is not limited to an existing network node or a general purpose hardware node. 
         [0095]    Next, at step  1404  of the exemplary method embodiment, an interface is created and deployed to the T&amp;C pool entities for communication between the T&amp;C pool entities and coordinating mobility events between the T&amp;C pool entities. It should be noted in the exemplary method embodiment that the created protocol can be enhancements to an existing protocol that allow a node to simultaneously process packets from existing eNBs and from the enhanced eNBs described herein. 
         [0096]    Next, at step  1406  of the exemplary method embodiment, a protocol is created and deployed to the eNBs and to the T&amp;C pool entities for transmitting control signaling and data packets between said eNBs and said one or more T&amp;C pool entities over a shared network. It should be noted in the exemplary method embodiment that the created protocol can be an enhancement to an existing protocol. It should further be noted in the exemplary embodiment that the shared network can be an IP network. 
         [0097]    Looking now to  FIG. 15 , an example of a suitable computing system environment  1500  in which the claimed subject matter can be implemented, although as made clear above, the computing system environment  1500  is only one example of a suitable computing environment for an exemplary embodiment and is not intended to suggest any limitation as to the scope of use or functionality of the claimed subject matter. Further, the computing environment  1500  is not intended to suggest any dependency or requirement relating to the claimed subject matter and any one or combination of components illustrated in the example computing environment  1500 . 
         [0098]    Continuing with  FIG. 15 , an example of a device for implementing the previously described innovation includes a general purpose computing device in the form of a computer  1510 . Components of computer  1510  can include, but are not limited to, a processing unit  1520 , a system memory  1530 , and a system bus  1590  that couples various system components including the system memory to the processing unit  1520 . The system bus  1590  can be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. 
         [0099]    Computer  1510  can include a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer  1510 . By way of example, and not limitation, computer readable media can comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile as well as removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer  1510 . Communication media can embody computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and can include any suitable information delivery media. 
         [0100]    The system memory  1530  can include computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) and/or random access memory (RAM). A basic input/output system (BIOS), containing the basic routines that help to transfer information between elements within computer  1510 , such as during start-up, can be stored in memory  1530 . Memory  1530  can also contain data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit  1520 . By way of non-limiting example, memory  1530  can also include an operating system, application programs, other program modules, and program data. 
         [0101]    The computer  1510  can also include other removable/non-removable and volatile/nonvolatile computer storage media. For example, computer  1510  can include a hard disk drive that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive that reads from or writes to a removable, nonvolatile magnetic disk, and/or an optical disk drive that reads from or writes to a removable, nonvolatile optical disk, such as a CD-ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM and the like. A hard disk drive can be connected to the system bus  1590  through a non-removable memory interface such as an interface, and a magnetic disk drive or optical disk drive can be connected to the system bus  1590  by a removable memory interface, such as an interface. 
         [0102]    A user can enter commands and information into the computer  1510  through input devices such as a keyboard or a pointing device such as a mouse, trackball, touch pad, and/or other pointing device. Other input devices can include a microphone, joystick, game pad, satellite dish, scanner, or similar devices. These and/or other input devices can be connected to the processing unit  1520  through user input  1540  and associated interface(s) that are coupled to the system bus  1590 , but can be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). 
         [0103]    A graphics subsystem can also be connected to the system bus  1590 . In addition, a monitor or other type of display device can be connected to the system bus  1590  through an interface, such as output interface  1550 , which can in turn communicate with video memory. In addition to a monitor, computers can also include other peripheral output devices, such as speakers and/or printing devices, which can also be connected through output interface  1550 . 
         [0104]    The processing unit  1520  can comprise a plurality of processing cores providing greater computational power and parallel computing capabilities. Further, the computing environment  1500  can contain a plurality of processing units providing greater computational power and parallel computing capabilities. It should be noted that the computing environment  1500  can also be a combination of multi-processor and multi-core processor capabilities. 
         [0105]    The computer  1510  can operate in a networked or distributed environment using logical connections to one or more other remote computers, such as remote server  1570 , which can in turn have media capabilities different from device  1510 . The remote server  1570  can be a personal computer, a server, a router, a network PC, a peer device or other common network node, and/or any other remote media consumption or transmission device, and can include any or all of the elements described above relative to the computer  1510 . The logical connections depicted in  FIG. 15  include a network  1580 , such as a local area network (LAN) or a wide area network (WAN), but can also include other networks/buses. 
         [0106]    When used in a LAN networking environment, the computer  1510  is connected to the LAN  1580  through a network interface  1560  or adapter. When used in a WAN networking environment, the computer  1510  can include a communications component, such as a modem, or other means for establishing communications over a WAN, such as the Internet. A communications component, such as a modem, which can be internal or external, can be connected to the system bus  1590  through the user input interface at input  1540  and/or other appropriate mechanism. 
         [0107]    In a networked environment, program modules depicted relative to the computer  1510 , or portions thereof, can be stored in a remote memory storage device. It should be noted that the network connections shown and described are exemplary and other means of establishing a communications link between the computers can be used. 
         [0108]    Additionally, it should be noted that as used in this application, terms such as “component,” “display,” “interface,” and other similar terms are intended to refer to a computing device, either hardware, a combination of hardware and software, software, or software in execution as applied to a computing device implementing a virtual keyboard. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program and a computing device. As an example, both an application running on a computing device and the computing device can be components. One or more components can reside within a process and/or thread of execution and a component can be localized on one computing device and/or distributed between two or more computing devices, and/or communicatively connected modules. Further, it should be noted that as used in this application, terms such as “system user,” “user,” and similar terms are intended to refer to the person operating the computing device referenced above. 
         [0109]    Further, the term to “infer” or “inference” refer generally to the process of reasoning about or inferring states of the system, environment, user, and/or intent from a set of observations captured from events and/or data. Captured events and data can include user data, device data, environment data, behavior data, application data, implicit and explicit data, etc. Inference can be employed to identify a specific context or action, or can generate a probability distribution over states, for example. The inference can be probabilistic in that the computation of a probability distribution over states of interest based on a consideration of data and events. Inference can also refer to techniques employed for composing higher-level events from a set of events and/or data. Such inference results in the construction of new events or actions from a set of observed events and/or stored event data, whether or not the events are correlated in close temporal proximity, and whether the events and data come from one or several event and data sources. 
         [0110]    The above-described exemplary embodiments are intended to be illustrative in all respects, rather than restrictive, of the present innovation. Thus the present innovation is capable of many variations in detailed implementation that can be derived from the description contained herein by a person skilled in the art. All such variations and modifications are considered to be within the scope and spirit of the present innovation as defined by the following claims. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items.