Patent Description:
Increased network density and increased heterogeneity are among the key factors complicating the design and implementation of wireless communication networks. Network designers and operators must balance the necessity of having good coverage, at least in areas of high use, and having the right type of coverage, e.g., high-data rate coverage, against the enormous capital and operating expenditures needed to deploy and maintain the kind of equipment needed to ensure that those necessities are being met.

In one approach to increasing network density, rather than simply adding more "macro" or large-cell base stations, network operators are deploying smaller, low-power base stations, or allowing third-parties, such as individual homeowners or other subscribers, to deploy such base stations. These base stations characteristically provide radio coverage in much smaller areas, e.g., only within the confines of a typical residence or office. Consequently, these coverage areas are often referred to as "small" cells.

The base stations or access points, APs, that provide small-cell coverage may or may not use the same Radio Access Technology, RAT, in use in the macro-layer of the network, and varying degrees of integration are contemplated for APs with respect to the network at large. For example, the APs may or may not be part of overall coordinated interference reduction schemes that coordinate scheduling or other operational aspects of the network across and between cells.

Merely by way of example, a network operator may lease or sell small, low-power APs that individual subscribers install in their homes or workplaces. These APs may provide better baseline coverage, or they may act as higher data-rate hotspots and, as such, they may have broadband connections back to the operator's network. In a particular approach, the APs couple to the operator's network through a controlling gateway. In such implementations, the AP has an air interface for connecting to devices and has one or more network connections, often "wired" connections, back to the controlling gateway, which in turn has some type of "backhaul" connection to the operator's core network.

The gateway arrangement provides a number of advantages. For example, one gateway may support more than one AP. Consequently, at least some of the processing can be consolidated in the gateway. The centralization of certain Radio Access Network, RAN, processing functions is a topic of growing interest, and it is envisioned as a key aspect of future-generation network implementations.

Broadly, the idea here involves dividing the overall air interface operations and management processing between the actual radio access points providing the radio bearers and centralized processing nodes that provide relatively cheap pools of processing resources that can be leveraged for potentially large numbers of radio access points, also referred to generically as "base stations". The lower-level functions, such as radio resource allocations and dynamic user scheduling are performed at the radio access nodes, which provide the actual radio link(s), while at least some of the higher-layer processing is moved to a central location.

This kind of disaggregation of the overall air interface processing protocols generally involves some "splitting" of the radio protocol stack between a radio access point and the centralized processing node. To better appreciate the split stack approach, consider the radio protocol stack used in Long Term Evolution or LTE. A wireless communication device and a network base station configured for operation in accordance with the LTE air interface each implements a version of the LTE protocol stack.

Protocol entities in the device-side stack mirror and communicate with corresponding peer entities in the network-side stack. The LTE stack includes a physical or PHY layer, as its bottommost layer, a Medium Access Control, MAC, layer above the physical layer, a Radio Link Control, RLC, layer above the MAC layer, a Packet Data Convergence Protocol, PDCP, layer above the RLC layer, and a Radio Resource Control, RRC, layer above the PDCP layer. For more details regarding these layers and their functions, the interested reader may refer to the following Third Generation Partnership Project, 3GPP, Technical Specifications: TS <NUM> for a discussion of the physical layer, TS <NUM> for a discussion of the MAC layer, TS <NUM> for a discussion of the RLC layer, TS <NUM> for a discussion of the PDCP layer, and TS <NUM> for a discussion of the RRC layer.

In the context of the aforementioned gateway arrangement, a residential or other such radio access point implements a portion of the radio protocol stack on the network side, with the remaining portion of the stack implemented at the controlling gateway. This arrangement provides the twofold benefit of simplifying the radio access point and leveraging the gateway node for supporting more than one radio access point. However, the protocol endpoints or peers for the network-side radio protocol stack exist in the device-side protocol stack, and there are no standardized endpoints or mechanisms for the split-stack interface between the radio access point and the controlling gateway.

It is recognized herein that the split should be transparent to the overall radio stack protocols and should be managed for link efficiencies and reliability. Further recognized herein are the dual needs for scalability and discoverability, e.g., so that individual connecting gateways can support tens, hundreds or even greater numbers of radio access points, and so that the involved inter-split connections can be easily configured between the involved controlling gateway and its supported radio access points.

Non-patent document "<NPL>, discloses the overall architecture of the UTRAN (Universal Terrestrial Radio Access Network), including internal interfaces and assumptions on the radio and Iu interfaces.

<CIT> discloses a method for optimizing a radio network layer to implement a network interconnection. A radio network controller is divided into radio access network servers and wireless adapters configured in a base station. The wireless adapters are adapted to process related radio interface protocols, and are connected to an optical access network via an adaptation function. The radio access network servers and a core network are respectively connected to optical network units to implement the interconnection between an optical network and a radio communication network.

According to the present disclosure, a method of operation in a gateway node and a gateway node that is coupled to a core network of a wireless communication network are provided according to the independent claims. Preferred embodiments are recited in the dependent claims.

Of course, the present invention is not limited to the above features and advantages. Indeed, those skilled in the art will recognize additional features and advantages upon reading the following detailed description, and upon viewing the accompanying drawings.

<FIG> illustrates a wireless communication network <NUM> configured to provide communication services to any number of wireless communication devices <NUM>, where only two such devices <NUM>-<NUM> and <NUM>-<NUM> are shown by way of example. Unless suffixes are needed for clarity, the reference number "<NUM>" is used herein, for both singular and plural reference to any given device, or devices. The same usage applies with respect to any other "base" reference number where suffixing is used herein.

The network <NUM> communicatively couples the individual devices <NUM> to one or more operator, OP, Internet Protocol, IP, services and/or external networks <NUM>, such as the Internet and may provide for inter-device communications within the network <NUM>. The network <NUM> includes a Radio Access Network, RAN <NUM>, and a Core Network, CN <NUM>. In this example, the RAN <NUM> includes a radio node <NUM> and a gateway node <NUM>. The gateway node <NUM> is configured to control the radio node <NUM> and to provide communicative coupling to the CN <NUM>. By way of example, the radio node <NUM> is a home base station or other small-cell device that provides radio coverage in a corresponding radio cell or cells <NUM>, which may have a limited coverage area, such as a low-power cell intended to encompass a single residence or other structure.

While only one cell <NUM> is illustrated, it will be appreciated that the radio node <NUM> may provide more than one cell <NUM>, e.g., by using different carrier frequencies, using different frequency subbands, using Time Division Multiplexing, TDM, etc. Although only one radio node <NUM> and one gateway node <NUM> are illustrated, the network <NUM> may include any number of radio nodes <NUM>, e.g., each at different locations within a broader geographic area. Further, the network <NUM> may include a gateway node <NUM> for each such radio node <NUM>, or may have one gateway node <NUM> for subsets or groups of radio nodes <NUM>. In one or more embodiments, it is contemplated to control potentially large numbers of radio nodes <NUM> via one gateway node <NUM>. Additionally, the network <NUM> may include other entities not illustrated or described, as will be understood by those of ordinary skill in the wireless communication arts. For example, in one or more non-limiting embodiments, the network <NUM> comprises a Long Term Evolution, LTE, or LTE-Advanced network, configuring according to the applicable technical specifications promulgated by the Third Generation Partnership Project, 3GPP. Consequently, the network <NUM> includes a variety of nodes or other entities associated with such networks, including Mobility Management Entities or MMEs in the CN <NUM>, along with a Packet Data Gateway Nodes or PDGN, providing a packet data interface between the CN <NUM> and the external network(s) <NUM>.

Regardless of whether the radio node <NUM> is implemented as a LTE Home eNB, HeNB, or as some other type of radio base station, it will be understood as comprising a mix of signal processing and control circuitry, along with supporting radio transceiver circuitry. In the example illustration, the radio node <NUM> includes first and second communication interfaces <NUM>-<NUM> and <NUM>-<NUM>-generally referred to as "communication interfaces <NUM>"-along with processing circuitry <NUM> that is operatively associated with the communication interfaces <NUM>.

The processing circuitry <NUM> comprises fixed circuitry, programmed circuitry, or a combination of fixed and programmed circuitry. In an example embodiment, the processing circuitry <NUM> is at least partly implemented using programmed circuitry and comprises, for example, one or more processors <NUM>, such as one or more microprocessors, Digital Signal Processors or DSPs, Application Specific Integrated Circuits or ASICs, Field Programmable Gate Arrays or FPGAs, or other digital processing circuitry. Correspondingly, the processing circuitry <NUM> includes or is associated with one or more types of computer-readable media-"STORAGE <NUM>" in the figure-such as one or more types of memory circuits such as FLASH, EEPROM, SRAM, DRAM, etc. Additionally, or alternatively, the storage <NUM> comprises hard disk storage, Solid State Disk, SSD, storage, etc..

In general, the storage <NUM> provides both working memory and longer-term storage. In at least one embodiment, the storage <NUM> provides non-transitory storage for a computer program <NUM> and one or more items of configuration data <NUM>. Here, non-transitory does not necessarily mean permanent or unchanging storage but does means storage of at least some persistence-i.e., holding information for subsequent retrieval. The computer program <NUM>, which may comprise a number of related or supporting programs, comprises program instructions that, when executed by the one or more processors <NUM> implement the processing circuitry <NUM> according to the configuration examples described herein. In other words, in some embodiments, one or more general-purpose processing circuits within the radio node <NUM> are specially adapted to carry out the teachings herein, based on their execution of the computer program instructions comprising the computer program <NUM>.

However implemented, the radio node <NUM> is configured to provide radio coverage in one or more cells <NUM>, and the first communication interface <NUM>-<NUM> is configured for communicating with wireless devices <NUM> operating in any of the one or more cells <NUM>. For example, the communication interface <NUM>-<NUM> is configured for transmitting and receiving radiofrequency signals according to the air interface protocols and signal structure adopted for the air interface between the radio node <NUM> and the devices <NUM>. To that end, the communication interface <NUM>-<NUM> includes one or more radiofrequency transmitters and receivers, and associated protocol processing circuitry that is adapted to support the uplink and downlink air interfaces implemented within the network <NUM>.

The radio node <NUM> further includes a second communication interface <NUM>-<NUM> configured to communicatively couple the radio node <NUM> to its controlling gateway node <NUM>, which in turn is coupled to the CN <NUM>. The second communication interface <NUM>-<NUM> may comprise a wired or wireless interface, e.g., a LAN or microwave-based interface, and shall be understood as providing physical-layer circuitry adapted for sending and receiving signals over the involved transmission medium, along with corresponding circuitry for protocol processing, as needed for communicating with the gateway node <NUM>.

Similarly, the gateway node <NUM> will be understood as comprising a mix of signal processing and control circuitry, along with supporting communication interfaces-i.e., communication interface circuits. In the example illustration, the gateway node <NUM> includes first and second communication interfaces <NUM>-<NUM> and <NUM>-<NUM>-generally referred to as "communication interfaces <NUM>"-along with processing circuitry <NUM> that is operatively associated with the communication interfaces <NUM>.

In general, the storage <NUM> provides both working memory and longer-term storage. In at least one embodiment, the storage <NUM> provides non-transitory storage for a computer program <NUM> and one or more items of configuration data <NUM>. As before, the term non-transitory does not necessarily mean permanent or unchanging storage, but does means storage of at least some persistence. The computer program <NUM>, which may comprise a number of related or supporting programs, comprises program instructions that, when executed by the one or more processors <NUM> implement the processing circuitry <NUM> according to the configuration examples described herein. In other words, in some embodiments, one or more general-purpose processing circuits within the gateway node <NUM> are specially adapted to carry out the teachings herein, based on their execution of the computer program instructions comprising the computer program <NUM>.

However implemented, the first communication interface <NUM>-<NUM> is configured for communicating with the radio node <NUM>, which is controlled by the gateway node <NUM>, and the second communication interface <NUM>-<NUM> is configured for communicating with one or more core network nodes-not individually depicted in <FIG>-in the CN <NUM> of the network <NUM>.

Now consider <FIG>, which illustrates a known radio protocol stack used in LTE. It will be appreciated that a complementary or mirror copy of the illustrated stack is conventionally implemented in each of the involved protocol endpoints-e.g., in a wireless device and in its serving base station. In the context of these teachings, the "network side" radio protocol stack is split between the radio node <NUM> and its controlling gateway node <NUM>.

<FIG> illustrates an example split-stack arrangement. In the diagram, a radio protocol stack <NUM> is split. The upper portion <NUM> of the radio protocol stack <NUM> resides in the gateway node <NUM> while a lower portion <NUM> of the radio protocol stack <NUM> resides in the radio node <NUM>.

In this example, the upper portion <NUM> includes a Packet Data Convergence Protocol, PDCP, layer and a Radio Resource Control, RRC, layer. In the hierarchy of the overall radio protocol stack <NUM>, the PDCP layer is "below" the RRC layer. The lower portion <NUM> of the radio protocol stack <NUM> includes a Radio Link Control, RLC, layer, a Medium Access Control, MAC, protocol layer below the RLC protocol layer, and a Physical, PHY, protocol layer below the MAC protocol layer.

<FIG> provides further example details. For example, one sees that a "PDCP stub" may be implemented in the lower portion <NUM> of the radio protocol stack <NUM>, to account for the fact that the illustrated split lies at the RLC-to-PDCP logical interface. According to the invention, the intra-stack IP link <NUM> / IP session(s) <NUM> communicatively couples the RRC and PDCP layers at the gateway node <NUM> to the RLC protocol layer at the radio node <NUM>. In particular, one or more IP sessions <NUM> are used to send SDUs from the RRC/PDCP layers RLC layer to the RLC layer over the intra-stack IP link <NUM> in the downlink direction and vice-versa in the uplink direction.

Turning back to <FIG>, the processing circuitry <NUM> of the gateway node <NUM> is operatively associated with the first and second communication interfaces <NUM> and is configured to determine that data is available for sending to a wireless device <NUM> that accesses the network <NUM> via a radio cell <NUM> provided by the radio node <NUM>, where the radio node <NUM> is coupled to the CN <NUM> of the network <NUM> via the gateway node <NUM>. The processing circuitry <NUM> is further configured to generate service data units corresponding to the data, based on processing the data according to an upper portion <NUM> of a radio protocol stack <NUM>. The radio protocol stack <NUM> is split between the gateway node <NUM>, which implements the upper portion <NUM> of the radio protocol stack <NUM>, and the radio node <NUM>, which implements the lower portion <NUM> of the radio protocol stack <NUM>.

Here, it shall be understood that the radio protocol stack <NUM> is the network-side stack and that the wireless device <NUM> implements a complementary device-side radio protocol stack having peer entities corresponding to the protocol entities seen in the network-side stack <NUM>. Thus, what is at issue here is the split between portions of the network-side radio protocol stack <NUM> and the need for establishing a reliable, efficient, and scalable mechanism for intra-stack communications between the protocol entities within the network-side radio protocol stack <NUM> that are exposed to the split.

To that end, the processing circuitry <NUM> of the gateway node <NUM> is configured to establish an IP session <NUM> towards the radio node <NUM>, via an intra-stack IP link <NUM> that communicatively couples the upper portion <NUM> of the radio protocol stack <NUM> at the gateway node <NUM> with the lower portion <NUM> of the radio protocol stack <NUM> at the radio node <NUM>. Notably, this IP session is distinct from and transparent to any IP sessions that may be running at the "applications" layer between the wireless device <NUM> and an application server in the OP services / external networks <NUM>. Indeed, according to the advantageous teachings herein, the IP session <NUM> is transparent to the end-to-end communications session(s) between the wireless device <NUM> and any end-point accesses via the network <NUM>, and is used purely to connect the upper portion <NUM> of the network-side radio protocol stack <NUM> at the gateway node <NUM> to the lower portion <NUM> of the network-side radio protocol stack <NUM> at the radio node <NUM>.

Advantageously, the IP session <NUM> is mapped to a radio bearer to be used for conveying the data to the wireless device <NUM> via an air interface of the radio cell <NUM>, and the processing circuitry <NUM> is configured to encapsulate the service data units in one or more IP packets, according to IP session parameters associated with the IP session <NUM>, and send the IP packets to the radio node <NUM> via the IP session <NUM>, for de-encapsulation and recovery of the service data units, for subsequent processing by the radio node <NUM> according to the remaining, lower portion <NUM> of the radio protocol stack <NUM>.

Complementary processing and functions at the gateway node <NUM> and at the radio node <NUM> provide for the transfer of uplink data and signaling from the wireless device over one or more IP sessions <NUM> on the intra-stack IP link <NUM>. That is, downlink data towards the wireless device <NUM> is processed at the gateway node <NUM> according to the protocol layers implemented in the upper portion <NUM> of the radio protocol stack <NUM>, and is encapsulated as IP traffic for conveyance over an IP session <NUM> supported via the intra-stack IP link <NUM>. The radio node <NUM> receives the encapsulated data and de-encapsulates it for processing according to the protocol layers implemented in the lower portion <NUM> of the radio protocol stack <NUM>. Conversely, uplink data-traffic or signaling-from the wireless device <NUM> is received by the radio node <NUM> and processed in the uplink direction according to the lower portion <NUM> of the radio protocol stack. The processed data is sent from the radio node <NUM> to the gateway node <NUM> as IP packets in an IP session <NUM> on the intra-stack IP link <NUM>. The gateway node <NUM> extracts the data encapsulated in the IP packets and continues processing that data in the uplink direction, according to the protocol layers implemented in the upper portion <NUM> of the radio protocol stack <NUM>.

In at least some embodiments, the processing circuitry <NUM> is configured to establish the IP session <NUM> using a User Datagram Protocol, UDP, when the radio bearer is a data radio bearer, and the wireless device <NUM> is operating in a Radio Link Control, RLC, Unacknowledged Mode, UM. The processing circuitry <NUM> is further configured to establish the IP session <NUM> using a Transmission Control Protocol, TCP, when the radio bearer is a data radio bearer and the wireless device <NUM> is operating in a RLC Acknowledged Mode, AM, or in a RLC Transparent Mode, TM. Still further, the processing circuitry <NUM> is configured to establish the IP session <NUM> using a Transport Layer Security, TLS, protocol, when the radio bearer is a signaling radio bearer, for transmitting Broadcast Control Channel, BCCH, or Paging Control Channel, PCCH, signaling. TLS is also used for SRB0 and SRB1, after AS. Further, in at least some embodiments, the IP session <NUM> is mapped uniquely for the radio bearer and the wireless device <NUM>, or is mapped according to a unique flow label assigned to the radio bearer, or is mapped to a unique flow label assigned to the wireless device <NUM>.

<FIG> illustrates a method <NUM> of operation in a gateway node <NUM> that is coupled to a CN <NUM> of a network <NUM>. By way of example, <FIG> focuses on downlink processing and the method <NUM> includes determining (Block <NUM>) that data is available for sending to a wireless device <NUM> that accesses the wireless communication network <NUM> via a radio cell <NUM> provided by a radio node <NUM> that is coupled to the CN <NUM> of the wireless communication network <NUM> via the gateway node <NUM>. The method <NUM> further includes generating (Block <NUM>) service data units corresponding to the data, based on processing the data according to an upper portion <NUM> of a radio protocol stack <NUM>, wherein the radio protocol stack <NUM> is split between the gateway node <NUM>, which implements the upper portion <NUM> of the radio protocol stack, and the radio node <NUM>, which implements a remaining, lower portion <NUM> of the radio protocol stack <NUM>.

Still further, the method <NUM> includes establishing (Block <NUM>) an IP session <NUM> towards the radio node <NUM>, via an intra-stack IP link <NUM> that communicatively couples the upper portion <NUM> of the radio protocol stack <NUM> at the gateway node <NUM> with the lower portion <NUM> of the radio protocol stack <NUM> at the radio node <NUM>. The IP session <NUM> is mapped to a radio bearer to be used for conveying the data to the wireless device <NUM> via an air interface of the radio cell <NUM>, and the method <NUM> includes encapsulating (Block <NUM>) the service data units in one or more IP packets, according to IP session parameters associated with the IP session <NUM>, and sending (Block <NUM>) the IP packets to the radio node <NUM> via the IP session <NUM>, for de-encapsulation and recovery of the service data units, for subsequent processing by the radio node <NUM> according to the remaining, lower portion <NUM> of the radio protocol stack <NUM>.

The IP link <NUM> in one embodiment comprises an IP Version <NUM>, IPv6, link. Of course, it is also contemplated that the IP link <NUM> be implemented as an IPv4 link and in operation, the gateway node <NUM> may support IP sessions <NUM> based on both IPv4 and IPv6. For example, a given radio node <NUM> may not support IPv6, while another radio node <NUM> does support IPv6.

<FIG> illustrates a method <NUM> in a radio node <NUM>, corresponding to the gateway method <NUM>. The radio node <NUM> is configured for operation in the network <NUM> and is particularly configured for being controlled by the gateway node <NUM>. The method <NUM> includes establishing (Block <NUM>) a radio bearer under control of a gateway node <NUM>, for communicating with a wireless device <NUM> and establishing (Block <NUM>) an IP session <NUM> with the gateway node <NUM>, via an intra-stack IP link <NUM> between the radio node <NUM> and the controlling gateway node <NUM>. Again, this IP link <NUM> is for connecting the upper and lower portions <NUM> and <NUM> of the split radio protocol stack <NUM>, and should not be confused with end-to-end IP sessions/links between the wireless device <NUM> and any "application" layer servers or systems.

The method <NUM> further includes receiving (Block <NUM>) one or more IP packets via the IP session <NUM> and de-encapsulating the received IP packets to recover the data targeted to the wireless device <NUM>. More particularly, the de-encapsulation involves de-encapsulating the IP packets to recover the SDUs incoming from the protocol layer operating in the gateway node <NUM> at the point where the radio protocol stack <NUM> is split between the gateway node <NUM> and the radio node <NUM>. Correspondingly, the method <NUM> further includes inputting (Block <NUM>) the de-encapsulated data into the remaining, lower-portion <NUM> of the radio protocol stack <NUM>, as implemented at the radio node <NUM>, for processing and sending to the wireless device <NUM> over the air interface.

<FIG> illustrate substantially similar processing as set forth in <FIG>, but are presented in the context of uplink processing. In particular, the method <NUM> of <FIG> depicts radio node processing and includes receiving (Block <NUM>) user traffic from a wireless device <NUM>. The method <NUM> further includes generating (Block <NUM>) SDU(s) from the received user traffic, via the lower portion <NUM> of the radio protocol stack <NUM>, and mapping (Block <NUM>) the radio bearer associated with the SDU(s) to an IP session <NUM> on the intra-stack IP link <NUM>. Processing continues with the radio node <NUM> encapsulating (Block <NUM>) the SDU(s) into one or more IP packets, in accordance with the mapped/Identified IP session <NUM>, and sending (Block <NUM>) the IP packet(s) towards the gateway node <NUM> over the intra-stack IP link <NUM>.

<FIG> illustrates a corresponding method <NUM> as carried out by the gateway node <NUM>. The method <NUM> includes receiving (Block <NUM>) an IP packet from the radio node <NUM> in an IP session <NUM> on the intra-stack IP link <NUM>, and mapping (Block <NUM>) the IP session <NUM> to a radio bearer, according to session/bearer mapping known at the gateway node <NUM>, e.g., from connection setup/establishment processing. Processing continues with the gateway node <NUM> de-encapsulating (Block <NUM>) the SDU(s) contained in the IP packet and inputting (Block <NUM>) the SDU(s) into the upper portion <NUM> of the radio protocol stack. The method <NUM> continues with the gateway node <NUM> sending (Block <NUM>) the data generated from processing the SDU(s) in the upper portion <NUM> of the radio protocol stack <NUM> on to the core network for higher-layer processing.

Consequently, it will be appreciated that a SDU output from the "top" of the lower portion <NUM> of the radio protocol stack <NUM> is encapsulated in an IP packet for transport over the intra-stack IP link <NUM>, in the IP session <NUM> to which the involved radio bearer is mapped. At the gateway node <NUM>, the SDU is extracted from the IP packet and passed into the "bottom" of the upper portion <NUM> of the radio protocol stack <NUM>, for completion of the overall protocol processing associated with the radio protocol stack <NUM> in the uplink direction. The converse is true in the downlink direction, i.e., SDUs emerging from the bottom of the upper portion <NUM> of the radio protocol stack <NUM> are encapsulated as IP packets and transported in a mapped IP session <NUM> over the intra-stack IP link <NUM>. The radio node <NUM> de-encapsulates those IP packets to recover the SDUs, which are then input to the top of the lower portion <NUM> of the radio protocol stack <NUM>, for completion of the overall stack processing in the downlink direction. It will be appreciated that the "bottom" of the upper portion <NUM> is taken as the stack layer at the gateway node <NUM> that is exposed to the split. Likewise, the "top" of the lower portion <NUM> is taken as the stack layer at the radio node <NUM> that is exposed to the split.

<FIG> illustrates an example embodiment in the context of a LTE network, wherein the CN <NUM> includes serving gateway, S-GW <NUM>, coupled to the gateway node <NUM> via a S1-UE interface, and a MME <NUM> coupled to the gateway node <NUM> via a S1-MME interface. The S-GW <NUM> and MME are communicatively coupled via a S11 interface, and the S-GW <NUM> is further communicatively coupled to a Packet Gateway, P-GW <NUM>, which provides the packet-routing interface, SGi, into and out of the network <NUM>. The MME <NUM> communicatively couples to a Home Subscriber Server, HSS <NUM>, via an S6a interface, and the HSS <NUM> couples to a Policy and Charging Rules Function, PCRF <NUM>, which is also coupled to the P-GW <NUM>. In the diagram, dashed connection lines are used to illustrate Control Plane, CP, signaling, while solid connection lines are used to illustrate User Plane, UP, signaling.

<FIG> illustrates an example splitting of the radio protocol stack <NUM> between the radio node <NUM> and the gateway node <NUM>, in the context of the LTE network example of <FIG>. <FIG> illustrates the further supporting protocol stacks used at the various other CN nodes seen in <FIG> and particularly highlights the IP link <NUM>/IP session <NUM> used to link the lower portion <NUM> of the split radio protocol stack <NUM>, as implemented in the radio node <NUM>, with the upper portion <NUM> of the stack <NUM>, as implemented in the gateway node <NUM>. It will be appreciated that there may be any number of split-stack "instances" implemented between the gateway node <NUM> and the radio node <NUM>, e.g., for simultaneously supporting multiple wireless devices <NUM>.

With the above example implementation details in mind, it shall be appreciated that the mapping of radio bearer, RB, traffic, e.g., PDCP PDUs, to IP sessions <NUM> provides for flexible connectivity between a gateway node <NUM> and any number of controlled radio nodes <NUM>. The proposed RB-to-IP mapping schemes provide a scalable solution that supports potentially large numbers of radio nodes <NUM> with respect to a controlling gateway node <NUM>.

Further, the mapping scheme(s) presented herein provide radio bearer traffic granularity and a sound, robust traffic isolation solution upon which various network use-cases become more easily deployable by the network operator. Example use cases include bearer-based or device-based routing policy deployment, for efficiently routing device traffic over the IP connection interconnecting the split stack <NUM>, e.g., using IPv6 flow labels. Another example is bearer-based and/or device-based access control security policy deployment, such as where firewalling parameters or policy settings are based on the identities of the wireless devices <NUM> being supported via the split-stack arrangement. Further examples include bearer-based and/or device-based Quality-of-Server, QoS, policy deployment, data packet inspection at the gateway node <NUM> on a per device <NUM> and a per radio node <NUM> basis, and lawful interception techniques, which typically requires per device discrimination.

The teachings herein further provide for the use of IP service discovery for dynamic configuration of the radio node <NUM>, e.g. IPv6 address auto- configuration-stateless address auto configuration or SLAAC-as well as dynamic discovery of the gateway node <NUM> by each radio node <NUM> to be controlled by the gateway node <NUM>. The teachings herein further provide for the use of Transport Layer Security, TLS, encryption to secure BCCH, PCCH, SRB0 and SRB1 traffic, which is not PDCP-ciphered. Here, "SRB0" and "SRB1" denotes Signaling Radio Bearer <NUM> and Signaling Radio Bearer <NUM>, respectively. The SRB0 and SRB1 are used for the transfer of RRC and Non-Access Stratum signaling messages. RRC messages go between the wireless device <NUM> and the radio node <NUM> and NAS messages go between the wireless device <NUM> and the MME <NUM>. Still further, the teachings herein enable the use of TCP for window-based flow control of RLC traffic in the AM mode.

In an example implementation, the radio node <NUM> provides the RLC/MAC/PHY layers of the radio protocol stack <NUM>, i.e., the lower portion <NUM> of the split stack <NUM> at the radio node <NUM> includes the RLC, MAC, and PHY layers. Correspondingly, the gateway node <NUM> provides centralized RRC and PDCP functions, which are managed by the involved network operator and are connected to any number of radio nodes <NUM>. Thus, the gateway node <NUM> provides centralized radio resource control for multiple radio nodes <NUM>. The gateway node <NUM> further provides the mapping between the GTP-U TEID-to-IP sessions for Data Radio Bearers, DRBs, as well as the mapping of RRC contexts-to-IP sessions for Signaling Radio Bearers, SRBs, based on the information supplied by each such radio node <NUM>.

In the LTE context and with reference again to <FIG>, the Uu and S1 interfaces are unchanged in one or more embodiments contemplated herein. The changes are limited to the newly proposed interface between the gateway node <NUM> and the radio node <NUM>, for communicatively coupling together the upper portion <NUM> of the split radio protocol stack <NUM> with the lower portion <NUM> of the split radio protocol stack <NUM>. This new interface, represented in <FIG> as the IP link <NUM> / IP session(s) <NUM>, transports packets between the protocol entities that are exposed to the split. In LTE, the CP and UP traffic carried over this new interface, where RRC messages may be simply forwarded on a "pass-through" basis from RLC entities to PDCP entities and vice versa. BCCH, PCCH, SRB0 and SRB1 traffic are sent over the IP link <NUM> using TLS/TCP/IP. SRB2 and DRBs are PDCP protected, i.e. encrypted, and, therefore, are sent over the IP link <NUM> using TCP or UDP. In one or more embodiments, Stream Control Transmission Protocol, SCTP, packets are avoided to prevent blocking issues that might otherwise arise with respect to CPE firewalling.

<FIG> illustrates an example call flow diagram covering local network attachment operations, wherein the radio node <NUM> connects to the local network provided by CPE. The radio node <NUM> sends router solicitation signaling and receives a return router advertisement, performs SLAAC processing, and then sends a DHCPv6 information request. The radio node <NUM> receives a corresponding response from the CPE that includes the address of the gateway node <NUM> supporting the radio node <NUM> and coupling it to the CN <NUM>. Note that the router advertisement will contain a prefix to auto-configure an address, e.g., using SLAAC, and will have the Obit set to initiate stateless DHCPv6. It is also contemplated to use a Fully Qualified Domain Name, FQDN, if load balancing and/or failover of the gateway node <NUM> are required.

<FIG> illustrates a call flow diagram covering a secure channel establishment between a radio node <NUM> and its supporting gateway node <NUM>. It is contemplated that in at least one embodiment of such signaling that a client certificate is used to authenticate the radio node <NUM> towards the network <NUM>. A TLS connection may be used for sending unencrypted control and data plane traffic over the IP link <NUM> / IP session <NUM>.

<FIG> illustrates a call flow diagram covering processing that follows the establishment of a secure connection between a radio node <NUM> and its supporting gateway node <NUM>. After establishing a secure channel, the radio node <NUM> connects to the gateway node <NUM> to initiate configuration. The gateway node <NUM> will then provide the radio initialization parameters, such as radio frequency bands, bandwidth, access schemes, antenna technology, physical channel configurations, etc., for the radio node <NUM>. After receiving the radio parameters, the radio node <NUM> sends the set of mappings between each radio bearer and the IP address plus the port and/or IPv6 flow label combination that it will use for traffic on that specific bearer, with respect to the IP link <NUM>.

Although it may be assumed that IPv6 links are used to transport data between the radio node <NUM> and the gateway node <NUM> for the IP link <NUM> supporting the stack split, the first mapping scheme presented below is also applicable to IPv4 links. It is assumed that there is a single PDU per IP packet, and all messages are sent in network byte order. All contemplated schemes consider UDP for bearers configured in RLC UM mode and TCP for RLC AM and TM.

In a first mapping option contemplated herein, there is a unique IP session <NUM> per bearer and per wireless device <NUM>. That is, there is an IP session <NUM> on the IP link <NUM> for each bearer with respect to each wireless device <NUM> being supported by the radio node <NUM>.

In a second mapping option contemplated herein, there is a unique IPv6 flow label per bearer type. As compared to the first mapping scheme, the difference is that flow isolation is achieved by using a different IPv6 flow label per radio bearer type. This second scheme allows for improved packet switching based on flow label or bearer type.

In a third mapping option, there is a unique IPv6 flow label per wireless device <NUM>. As compared to the second mapping scheme, the difference with this third mapping scheme is that flow isolation is achieved by using a different IPv6 flow label per wireless device <NUM>, which is identified with a C-RNTI-like ID. If the flow labels are exchanged on demand, for example, upon initial attachment of a wireless device <NUM> to the radio node <NUM>, the IPv6 flow labels could embed the C-RNTI of the attaching wireless device <NUM>.

<FIG> is a logic flow diagram illustrating another embodiment of a method <NUM> of processing at a gateway node <NUM> that is configured for operation in a network <NUM>, and for controlling a radio node <NUM> that is configured to communicatively couple one or more wireless devices <NUM> to the network <NUM> via a cell <NUM> provided by the radio node <NUM>. The method <NUM> focuses on a downlink example and begins with receiving a packet at the gateway node <NUM> for a given wireless device <NUM> (Block <NUM>). Processing continues with identifying the radio bearer or radio bearer type to be used for conveying the received packet (Block <NUM>). If the received packet is user traffic, it is associated with a DRB and processing continues in Block <NUM>, with performing Robust Header Compression, ROHC, and ciphering at the PDCP layer of the radio protocol stack <NUM>. Here, the PDCP layer resides in the gateway node <NUM>.

The involved DRB is mapped to an IP session <NUM> (Block <NUM>) that provides the intra-stack connection between the split entities of radio protocol stack <NUM>, and the RLC mode is determined (Block <NUM>). For AM mode operation, the method <NUM> includes checking whether a connection to the wireless device <NUM> has been established (Block <NUM>) and performing connection setup (Block <NUM>) if not. Once the connection has been setup, or if the RLC mode is UM, processing continues with encapsulating (Block <NUM>) the received user-traffic packet in an IP packet for conveyance (Block <NUM>) to the radio node <NUM> via the IP session <NUM> supported by the IP link <NUM> that interconnects the lower portion <NUM> of the split radio protocol stack <NUM> in the radio node <NUM> with the upper portion <NUM> of the split radio protocol stack <NUM> in the gateway node <NUM>.

That is, the encapsulation occurs here for purposes of conveying the packet between the split entities of the radio protocol stack <NUM>, as split between the gateway node <NUM> and the radio node <NUM>, and is unrelated to any IP running at protocol layers above the split radio protocol stack <NUM>. It will also be appreciated that a corresponding de-encapsulation, therefore, occurs within the lower portion <NUM> of the radio protocol stack <NUM> at the radio node <NUM>. Thus, this usage of IP conveyance is transparent to higher-layer protocol endpoints running at the wireless device <NUM> and, e.g., at the P-GW <NUM> or at some server external to the network <NUM>, and is operative only with respect to interconnecting the entities within the radio protocol stack <NUM> that are exposed to the split between the radio node <NUM> and the gateway node <NUM>.

On the other hand, with reference again to Block <NUM>, if the received packet is BCCH, PCCH, or otherwise associated with SRB0, SRB1 or SRB2 control signaling, RRC processing is performed at Block <NUM> and, for SRB1 signaling, processing includes determining whether AS Security-a LTE security protocol associated with RRC signaling-is active (Block <NUM>). If AS Security is not active, it is contemplated herein to advantageously apply TLS, and processing in this case thus continues with RB-to-IP-Session mapping (Block <NUM>), for the IP link <NUM>, and TLS encryption of the received packet (Block <NUM>). TLS could be used for the duration of the SRB1 traffic, but switching after AS is another option. For SRB2 signaling, or in the case where AS Security is active, the PDCP layer processing includes encryption of the packet, and thus processing can continue from Block <NUM> or Block <NUM> with PDCP processing (Block <NUM>) and RB-to-IP-Session mapping for the IP link <NUM> (Block <NUM>).

From Block <NUM>, processing continues with determining whether a connection to the wireless device <NUM> has been established (Block <NUM>) and, if so, performing IP encapsulation of the packet for conveyance over the IP link <NUM> in the mapped IP session <NUM> (Blocks <NUM> and <NUM>). If the connection has not already been setup, the connection is setup at Block <NUM> (NO from Block <NUM>), and then the encapsulation and conveyance operations in Blocks <NUM> and <NUM> are carried out.

Claim 1:
A method of operation in a gateway node (<NUM>) that is coupled to a core network (<NUM>) of a wireless communication network (<NUM>), the method comprising:
determining (<NUM>) that data is available for sending to a wireless device (<NUM>) that accesses the wireless communication network (<NUM>) via a radio cell (<NUM>) provided by a radio node (<NUM>) that is coupled to the core network (<NUM>) of the wireless communication network (<NUM>) via the gateway node (<NUM>);
generating (<NUM>) service data units corresponding to the data, based on processing the data according to an upper portion (<NUM>) of a radio protocol stack (<NUM>), wherein the radio protocol stack (<NUM>) is split between the gateway node (<NUM>), which implements the upper portion (<NUM>) of the radio protocol stack, and the radio node (<NUM>), which implements a remaining, lower portion (<NUM>) of the radio protocol stack (<NUM>);
establishing an intra-stack Internet Protocol, IP, link (<NUM>) with the radio node (<NUM>), communicatively coupling the upper portion (<NUM>) of the radio protocol stack (<NUM>) at the gateway node (<NUM>) with the lower portion (<NUM>) of the radio protocol stack (<NUM>) at the radio node (<NUM>), and
sending Service Data Units, SDUs, from the upper portion (<NUM>) of the radio protocol stack (<NUM>), as implemented in the gateway node (<NUM>), to the lower portion (<NUM>) of the radio protocol stack (<NUM>), as implemented in the radio node (<NUM>), via the intra-stack IP link (<NUM>),
wherein the radio protocol stack (<NUM>) includes as said upper portion (<NUM>) a Packet Data Convergence Protocol, PDCP, layer, and a Radio Resource Control, RRC, layer and includes as said lower portion (<NUM>) a Radio Link Control, RLC, protocol layer below the PDCP layer, a Medium Access Control, MAC, protocol layer below the RLC protocol layer, and a Physical, PHY, protocol layer below the MAC protocol layer, and
characterised in that
the intra-stack IP link (<NUM>) communicatively couples the gateway node (<NUM>) to the RLC protocol layer at the radio node (<NUM>).