ALWAYS-ON CARRIER FOR SMALL DATA TRANSFERS IN LTE SYSTEMS

Description

Technical Field

[0001] Embodiments described herein relate generally to wireless networks and communications systems.Background

[0002] In LTE (Long Term Evolution) cellular systems, as set forth in the LTE specifications of the 3rd Generation Partnership Project (3GPP), mobile terminals (where a terminal is referred to in LTE systems as user equipment or LTE) connect to a base station (referred in LTE systems as an evolved Node B or eNB) that provides connectivity for the UE to other network entities of the LTE system that connect to an external network such as the internet. Providing such network connectivity involves the setting up of bidirectional data pathways, referred to as bearers, between the different components of the LTE system. These bearers are set up when the UE transitions from, an idle state to a connected state and, for reasons of efficiency, are tom down when the UE is idle. Some UE applications, however, may involve frequent small data transfers where the UE transitions to an idle state after each such transfer. Repeatedly setting up and tearing down the bearers in these situations leads to a great deal of signaling overhead. Reducing that signaling overhead is an objective of the present disclosure. This objective is achieved through the invention as defined in the independent claims.

[0003] Patent Applications WO 2012 / 034580 A1 and US 2012 / 120789 A1 discuss storage and release of bearers to reduce control signaling in an EPC.Brief Description of the Drawings

[0004] Fig. 1 illustrates the primary network entities of an LTE system. Fig.2 illustrates an example of the operation of an always-on S1-U bearer that, saves SI-MME signaling. Fig. 3 illustrates an example of an RRC Connection Request with, an always-on indicator. Fig.4 illustrates an example of an enhanced Attach procedure for an always-on Sl-U bearer. Fig. 5 illustrates an example of an enhanced SI -release message sequence. Fig. 6 illustrates an example of an S1 release call flow decision. Fig. 7 illustrates an example of a Tracking Area Update with S-GW relocation. Fig. 8 illustrates an example of a modified Service Request. Fig. 9 illustrates an example of a downlink data transfer for an always-on Sl-U bearer. Fig. 10 illustrates an example of an eNB relocation with S-GW relocation. Fig. 11 illustrates an example of transferring security context from an old eNB to a new eNB over the X2 interface. Fig. 12 illustrates an example of transferring security context from an old eNB to a new eNB using a Configuration Transfer Procedure. Detailed Description

[0005] The essential features of the invention are outlined by the appended independent claims.

[0006] The high-level architecture of an LTE may be described as including three main components: user equipment (UE), the evolved UMTS terrestrial radio access network (E-UTRAN) and the evolved packet core (EPC), where the E-UTRAN together with the EPC are referred to as the EPS (evolved packet system). A UE may be a. cellular phone or other device that communicates wirelessly with the E-UTRAN, which is made up of a single component, the evolved Node B (eNB ). The eNB communicates with the EPC which, in tum, communicates with packet data networks in the outside world such as the internet.

[0007] Fig. 1 illustrates the primary network entities of an LTE system where a particular entity may include processing circuitry designated by an "a" suffixed to its reference numeral, network interface circuitry designated by a "b" suffixed to its reference numeral, and a radio-frequency (RF) transceiver with one or more antennas designated by an "c" suffixed to its reference numeral. The eNB 105 provides an RF communications link for the UE 100, sometimes referred to as the LTE radio or air interface. The eNB is a base station that serves the UEs one or more geographic areas called cells. A UE communicates with one eNB at a time and, as the UE moves, may switch to another eNB in a procedure known as handover. The eNB provides uplink and downlink data channels for all of the UEs in its cells and relays data traffic between the UE and the EPC. The eNB also controls the low-level operation of the UEs by sending them signaling messages. The main components of the EPC are shown as an MME 110 (mobility management entity), an HSS 125 (home subscriber server), an S-GW 115 (serving gateway), and P-GW 120 (packet data network (PDN) gateway). The MME controls the high-level operation of the UE including management of communications sessions, security, and mobility. Each UE is assigned to a single serving MME that may change as the UE moves. The HSS is a central database that contains information about all the network operator's subscribers. The P-GW is the EPC's point of contact with the outside world and exchanges data with one or more packet data networks such as the internet. The S-GW acts as a router between the eNB and P-GW. As with the MME, each UE is assigned to a single serving S-GW that may change as the UE moves.

[0008] The air interface provides a communications pathway between the UE and eNB. Network interfaces provide communications pathways between the eNB and the EPC and between the different components of the EPC. The network interfaces include an S1-MME interface between the eNB and the MME, an S1-U interface between the eNB and the S-GW, an X2 interface between different eNBs, an S10 interface between different MMEs, an S6a interface between the MME and the HSS, an S5 / S8 interface between the S-GW and the P-GW, and an SGi interface between the P-GW and the PDN. These network interfaces may represent data that is transferred over an underlying transport network.

[0009] At a high level, the network entities in Fig.1 communicate across the interfaces between them by means of packet flows, referred to as bearers, which are set up by specific protocols. The UE and eNB communicate over the air interface using both data radio bearers and signaling radio bearers (SRBs). The eNB communicates with the MME over the S1-MME network interface and with the S-GW over the S 1-U network interface with like-named bearers (the S1-MME bearer may also be referred to as the S1-AP (S1 application protocol) bearer). The combination of a data radio bearer, an S1-U bearer, and an S5 / S8 bearer is called an EPS bearer. The EPC sets up one EPS bearer known as the default bearer whenever a UE connects to the PDN. A UE may subsequently receive other EPS bearers called dedicated bearers.

[0010] Each of the interfaces discussed above is associated with a protocol stack that the network entities use to either exchange data. The protocols in LTE are divided into user plane protocols and control plane protocols. The user plane carries user data through what is called the AS (access stratum) and includes protocols for the air interface between the UE and the eNB, the S1-U interface between the eNB and the S-GW, and the S5 / S8 interface between the S-GW and the P-GW. The user plane parts of the S1-U and S5 / S8 interfaces use the GTP protocol (GPRS (general packet radio service) tunneling protocol) for transporting IP packets. GTP encapsulates the original IP packet to ensure that packets flow between the UE and the proper eNB.

[0011] The control plane is responsible for controlling the connections between the UE and the network and includes a protocol stack for the air interface between the UE and eNB, at the top of which is the RRC (radio resource control) protocol. The RRC is the main controlling protocol for the AS, being responsible for establishing radio bearers and configuring lower layers using RRC signaling between the eNB and the UE. The control plane protocols that run between the UE and the MME, and which lie above the RRC in the UE, are referred to as the NAS (non-access stratum) protocols and include the EMM (EPS mobility management) protocol and the ESM (EPS session management protocol). The NAS protocols are used by the MME to manage the connectivity of the UE with the EPC. Because the NAS protocols do not exist in the eNB, RRC and S1-AP (S1 application protocol) are used as transport protocols for NAS messages between the UE and the eNB and between the eNB and MME, respectively.

[0012] In the current 3GPP LTE architecture, a UE performs several steps for attaching itself to the EPS, First, it establishes an RRC connection with the eNB to set up SRBs (signaling radio bearers), moving from what is called RRC-_IDLE state to RRC_CONNECTED state. After establishing the RRC connection, the UE sets up the S1-MME bearer. Subsequently, the S5 / S8, S1-U, and radio bearers are set up to form the EPS bearer. This attachment to the network happens on a per UE basis and involves the creation of a number different data tunnels. When the UE enters the RRC_IDLE state, only the S5 / S8 EPS bearer context is retained, and the S1-U, S1-AP and radio bearers are released. These bearers have to be re-established on per UE basis when the UE returns to RRC_CONNECTED state. A number of UE applications may send small data frequently, which causes the UE to toggle between IDLE and CONNECTED states. This leads to a great deal of signaling overhead as the radio bearer and the S1-U bearer must be frequently re-established as the UE transitions between IDLE to CONNECTED states.Always-on S1-U bearer

[0013] A solution to avoid much of the overhead signaling while reestablishing tunnels is to have a default, always-on S1-U bearer. When the UE enters RRC_IDLE mode, the associated S1-U information can be maintained so that there is no need to re-establish the S1-U bearer when the UE wakes up from IDLE state. That is, when a UE in an RRC_IDLE state transitions to the RRC_CONNECTED state, it only needs to establish the radio bearer, and S1-MME signaling is not necessary. The scheme according to one embodiment is illustrated in Fig. 2 as stages 1 through 10 that involve the UE, eNB, S-GW, and P-GW. Stage 1 is the Attach procedure for the UE that creates the EPS bearer which is made up of a radio bearer, an S5 / S8 bearer, and an always-on S1-U bearer. At stage 2, the UE is in connected mode and is running an application with frequent small data transmissions. At stage 3, a user inactivity timer at the eNB expires which tells the eNB to put the UE in idle mode. As the RRC connection is released by the eNB, the UE retains the S-GW IP (internet protocol) address and the S-GW TIED (tunnel endpoint identifier for the always-on S1-U bearer at stage 4. The eNB retains the UE context at stage 5, and the S-GW retains information about the always-on S1-U bearer at stage 6 as well as maintaining the S5 / S8 bearer. The UE enters the idle mode at stage 7. At stage 8, the UE issues an NAS service request to the eNB (e.g., because it has data to send) and piggybacks the retained S-GW information in the message to the eNB. The radio bearer is re-established at stage 8a, and the eNB uses the piggybacked S-GW information to connect the radio bearer to the always-on S1-U bearer at stage 8b. At stage 9, the S-GW maps the always-on S1-U bearer to the S5 / S8 bearer at stage 9 using the retained context information. The EPS bearer is thus re-established at stage 10 with no S1-MME signaling involved.Modification of call flows

[0014] Described below are modifications to existing call flows in order to realize the concept of an always-on -S1-U bearer. Modifications are described for the Attach procedure, the S1-Release procedure, the Service Request procedure, the S-GW Relocation procedure, and Handover procedures. Both the eNB and the MME need to be made aware when the UE requests an always-on S1-U bearer. In one embodiment, the eNB is informed with an "always-on indicator" in RRC signaling. The RRC Connection Request message includes a UE identity and an establishment cause. A new establishment cause, the always-on S1-U indicator, is introduced in order to indicate that the UE wants to create an always-on S1-U bearer as shown in Fig.3 which lists the IBs (information elements) of the RRC Connection Request message. This always-on indicator informs the eNB that the S1-U bearer is a static, always-on bearer and that the eNB should not delete the UE context during an S1-Release procedure. The added establishment cause provides an indication of the request for the always-on S1-U bearer for either mobile originating access or mobile terminating access.

[0015] The MME may be made aware of a UE request for an always-on S1-U bearer by having the eNB, after receiving the UE. request for S1-U bearer as described above, forward the always-on indicator in the S1-AP Initial UE message, as part of the "RRC Establishment Cause" information element. Alternatively, NAS messages can also be used to convey to the MME that it has to establish an always-on S1-U bearer. With regard to the Attach Request message, the new indicator may be signaled in one of the following ways: 1) the field EPS Attach Type, used to indicate the type of the requested attach, can be enhanced to indicate the new attach type with an S1-U always-on bearer; 2) and an additional Update Type IE can be used to indicate a new attach type with an S1-U always-on bearer, or 3) a new IE in the Attach Request message can be defined. Similarly other NAS messages such as service request or tracking area update request can include the always on S1-U indication. The MME, upon on receiving NAS request with always-on S1-U indication is informed that an always-on bearer is going to be established so that the MME does not delete the UE context information during an S1 release.Enhancements to Attach Procedure

[0016] The attach procedure described in 3GPP TS 23.401., section 5.3.2 may be suitably modified to facilitate the creation of an always-on bearer for applications using the always-on indicator, including MTC (machine type communications) applications. In one embodiment, a UE can initially indicate that it needs an always-on bearer as it sends / receives small data frequently. This indication can either be piggybacked on an RRC Connection Request message or on an Attach Request message. This indication informs the eNB not to delete the UE context during the S I-release. The same indication may also be sent to the MME and the S-GW in order to retain UE context and EPS bearer information when an always on S1-U bearer is requested.

[0017] In one embodiment, the MME is allowed to validate the need for an always-on S1-U bearer. Depending on the user profile or other user behavior, the network operator may optionally configure optimized Attach (using always-on S1-U) in a user's subscription profile in the HSS. If activated, this parameter is downloaded to the MME as part of the update location procedure. Before the MME sends the Create Session Request message to the S-GW to create the always on bearer, it verifies the subscription data in HSS and confirms the need for an always-on bearer as shown in Stage 11 of Fig. 4 below.

[0018] In one embodiment, the S-GW is informed of always-on S1-U bearer in the following way. The MME selects an S-GW and allocates an EPS Bearer Identity for the Default Bearer associated with the UE. Then it sends a Create Session Request message to the selected S-GW. The Request type is set as one with an always-on S1-U bearer. This informs the S-GW that an always-on bearer has been created and to retain the context when the UE goes into IDLE mode. The TEID used by the S-GW on the S1-U interface (referred to as the "SGW TEID") may be assigned in either of the following ways: 1) If the always-on bearer is supported only for low mobility UEs, the S-GW TEID is assigned in the usual way, i.e. so that its value is unique on a given S1-U interface; or 2) If the always-on bearer is supported in conjunction with UE mobility, the S-GW TEID is assigned in such a way that its value is unique across all S1 interfaces served by the same S-GW. As explained below, this special way of S-GW TEID assignment enables the SGW to identify the always-on bearer for a specific user plane packet, regardless of the S1 instance on which this user plane packet was received.

[0019] In some embodiments, the UE is also informed of the S-GW TEID and S-GW IP address. This may be needed only if the always-on bearer is supported in conjunction with UE mobility. Some information about the S1 always-on bearer (namely, the SGW IP address and the SGW TEID assigned to the always-on bearer) is signaled to the UE via AS (access stratum) or NAS signaling. For example, the RRC Connection Reconfiguration message may be used to piggyback the S-GW TEID and the S-GW IP address to the UE or, alternatively, the information can be piggybacked in the Attach Accept message by the MME. The UE stores the information and passes it to eNB when it changes from IDLE to CONNECTED mode. The eNB then uses this information to identify and connect to the S-GW that "owns" the always-on S1-U bearer. It is important that the UE stores this information because the eNB which has retained the UE context may change if the UE is mobile (but new eNB may still have the same S-GW).

[0020] Fig. 4 illustrates an enhanced attach procedure to obtain an always-on S1-U bearer according to one embodiment made up of stages 1 through 26. At stage 1, the UE sends an Attach Request message to the eNB with an always-on bearer requested which is forwarded to the MME at stage 2. The always-on S1-U bearer may be requested by the eNB by setting the Attach Type. Identity Request and Identity Response messages are sent between the UE and the MME at stages 3 and 4. Authentication / Security, Identity Check, and Ciphered Options procedures take place at stages 5a-b and 6. At stages 7 and 8, the MME sends a Delete Session Request message to the P-GW and receives a Delete Session Response message in return in order to tear down the previous bearer. At stages 9 and 10, the MME sends an Update Location Request message to the HSS and receives an Update Location Response in return so that it can validate the request for an always-on S1-U bearer using the HSS information at stage 11. At stage 12, the MME sends a Create Session Request message to the S-GW with a Request Type set to always-on S1-U bearer, and the message is forwarded to the P-GW at stage 13. A Create Session Response message is received by the S-GW at stage 14 along with downlink data at stage 15 (if no handover has occurred), and the response is forwarded to the MME at stage 16. The MME next sends Initial Context Setup Request and Attach Accept messages to the eNB at stage 17. At stage 18, the eNB sends an RRC Connection Reconfiguration message to the UE that also informs the UE of the S-GW IP address and S-GW TEID for the always-all bearer. At stage 19, the UE sends an RRC Reconfiguration Complete message to the eNB. The eNB sends an Initial Context Setup Complete message to the MME at stage 20 and an Attach Complete message to the MME at stage 22. At stage 21, the UE sends a Direct Transfer message to the eNB. At stage 23, the MME sends a Modify Bearer Request message to the S-GW which is forwarded to the P-GW. At stage 24, the P-GW sends a Modify Request Response message to the S-GW which is forwarded to the MME. Notify Request and Notify Response messages are exchanged between the MME and the HSS at stages 25 and 26.Enhancement to S1 Release procedure

[0021] An example of an enhanced S1 Release procedure is shown in Fig. 5 that releases only the logical S1-AP signaling connection (over S1-MME). At stage 1, the user inactivity timer at the eNB expires to initiate the procedure. The UE context information is retained by the eNB and S-GW at stages 2 and 3, respectively. The eNB sends the UE an RRC Connection Release message at stage 5. After this procedure is complete, the UE moves from ECM-CONNECTED state to ECM-IDLE state. The UE related context information is retained at the eNB, MME and S-GW, as they are informed of the always on S1-U bearer during the Attach procedure described above.

[0022] In one embodiment, as illustrated by Fig. 6, when the user inactivity timer expires at the eNB at state 601, it checks whether the bearer established is an always-on S1-U bearer at stage 602. If so, then at stage 603, the eNB retains the UE context information, and the S-GW also retains the configuration details along with mapping details to the S5 / S8 bearer. Otherwise, at stage 604, it follows the normal release procedure as described in 3GPP TS 23.401, section 5.3.5.

[0023] The RRC Connection Release message is sent to the UE in order to release the RRC connection between the UE and the eNB. In case a handover has occurred, and the eNB has changed with an S-GW relocation, then the eNB can piggyback the new S-GW IP address and S-GW TEID using the RRC Connection Release message. The UE retains the S-GW TEID and S-GW IP address and supplies this information to the eNB in a Service Request message to connect to the always-on bearer, without any MME signaling needed.Enhanced Tracking Area Update Procedure with S-GW relocation

[0024] An enhanced Tracking Area Update procedure according to one embodiment is illustrated by Fig. 7. TAU (tracking area update) procedures are performed at stages 1 and 3. When a Tracking Area Update occurs with S-GW change, then the new S- GW sends a Create Session Response message to the new MME ate stage 2 which includes a new S- GW address and new S-GW TEID for user plane and P-GW TEIDs (for S5 / S8) for uplink traffic. This needs to be relayed to the UE so that the S-GW TEID and IP address is updated at the UE to facilitate connection to the always on tunnel. Before the UE is informed of the addresses, the old session is first deleted. The old MME sends the old S-GW a Delete Session Request message at stage 4 and receives a Delete Session Response at stage 5. Then the new S-GW IP address and S-GW TEID are piggybacked and sent through the Tracking Area Update Accept message at stage 6. The UE obtains the new S-GW IP address and S-GW TEID at stage 7, and sends the new MME a Tracking Area Update Complete message at stage 8.Enhanced Service Request procedures for always-on S1-U bearer

[0025] When an always-on bearer is used, a modified service request procedure can be used in order to attach to the network when the UE goes to the CONNECTED mode. An example of an enhanced Service Request procedure that saves S1-MME signaling according to one embodiment is illustrated by Fig. 8. At stage 1, the UE is in the IDLE mode after following the S1-Release procedure for the always on tunnel as described above. The UE initiates the Service Request while it is in the ECM-IDLE state at stage 4. An NAS Service Request message is sent from the UE to the eNB when the UE has to change from EMM_IDLE to EMM_REGISTERED mode. This message is sent when the UE is paged by the MME when there is downlink data or when there is UE initiated uplink data. At stage 3, the UE sends a NAS message Service Request to the eNB encapsulated in an RRC message. If the UE uses an always-on S1-U bearer, then it sends the S-GW TEID and the S-GW IP address to the eNB piggybacked in this message. Additionally, if a TAU has been performed, then the new S-GW TEID, S-GW address is sent to eNB to update the always on EPS bearer information and to connect to S1-U. At stage 4, the eNB receives the S-GW IP address and S-GW TEID and maps the radio bearer to the S1-U bearer. The eNB authenticates the UE and performs security related functions at stage 5. The Radio bearer is established between the UE and the eNB at stage 6. At stages 7a and 7b, the eNB connects to the S1-U bearer using the static S-GW TEID and S-GW address. At stage 7c, the eNB sends dummy UL data to inform the DL eNB TEID to S-GW. This can be done by defining a new "message type" from GTP-U header or an existing message such as an Echo Request may be modified. The context of s5 / S8 is maintained at the S-GW and the S1-U is mapped to S5 / S8 at stages 7d and 7e. End to end tunnels are established, and downlink data is routed to the S-GW and UE using the eNB TEID which is sent during the uplink at stage 8.

[0026] Fig. 9 illustrates paging from eNB / MME on getting downlink data according to one embodiment. When the PDN gateway sends a downlink packet to the UE, the packet is initially buffered at the S-GW at stage 901. The S-GW is informed during the initial attach that the S1-U bearer is always-on and determines that this is the case at stage 902. The S-GW, on knowing that the S1-U bearer is always-on, sends the packet to the eNB regardless of whether the UE is in IDLE mode or CONNECTED mode at stage 903. At stage 904, the eNB determines whether the UE is in CONNECTED or IDLE mode. If the UE is in CONNECTED mode, the packet is sent at stage 905. If the UE is in IDLE mode, at stage 906, the eNB pages the UE in its last registered cell using IMSI (international mobile subscriber identity) information of the UE and sets an appropriate paging cause. If the UE is still registered with the eNB, it receives the packet at stage 907. If the UE does not respond, the eNB informs S-GW of the failure to deliver the message via a new GTP-U message or via a modified existing message (e.g., an Echo Request) at stage 908. Subsequently, at stage 909, the S-GW requests the MME to deliver the message by paging the UE. The MME, on receiving this request, pages all the eNBs in the UE's Tracking Area List at stage 910, and the eNB to which UE is attached pages the UE to initiate a Service Request at stage 911. Optionally, stage 912 may be performed to check whether the UE is in a high mobility state or low mobility state. If the latter, the eNB can page the UE informing it to initiate a service request. If the UE is highly mobile, on the other hand, the S-GW can send a message to the MME to page the UE instead of asking the eNB to page the UE. Once the UE is informed of the downlink data, the UE initiates the enhanced Service Request procedure described above to register with the network and receive services.

[0027] In another embodiment, the S-GW runs an inactivity timer of the same or less value than the eNB inactivity timer. If the timer expires, the S-GW marks the UE as idle. In this case, if S-GW receives any downlink data it will not forward it to eNB and will send a downlink data notification to MME.Enhanced call flow for eNB relocation with S-GW relocation

[0028] When eNB relocation occurs with S-GW relocation, the contexts have to be updated at the S-GW, eNB and P-GW in order to facilitate the always-on S1-U bearer. An example embodiment of the stages involved in this process according to one embodiment is illustrated by Fig. 10. After receiving a Path Switch Request at stage 1, the MME sends a Create Session Request message to the Target S-GW with bearer contexts at stage 2. The message includes P-GW addresses, TEIDs for S5 / S8, eNB addresses and TEIDs for downlink user plane for the accepted EPS bearers per PDN connection for the default bearers that have been accepted by the target eNB. The target S-GW sends a Modify Bearer Request to the P-GW at stage 3a and receives a Modify Bearer Response in return at stage 3b. At stage 4, the target S-GW sends the MME a Create Session Response message. At stage 5, the MME sends the target eNB a Path Switch Request Acknowledgement message that gives the eNB the S-GW addresses and uplink TEID(s) for user plane message. Stages 6 and 7a-b show a Release Resource message sent by the target eNB to the source eNB and a Delete Session Request sent by the MME to the source S-GW with a Delete Session Response sent in return. A tracking area update procedure is performed at stage 8. The target eNB starts using the new S-GW address and TEID(s) for forwarding subsequent uplink packets. The UE is informed of the new S-GW TEID and S-GW IP address before the S-1 release (before UE goes into IDLE mode) by piggybacking this information in RRC Connection Release message as explained above. The UE can then use the new S-GW information and supply it to the eNB in. Service Request message to connect to the always-on bearer, without any signaling needed when it goes from IDLE to CONNECTED mode.Solutions for transferring UE, and Security Context

[0029] When the enhanced Service Request Procedure is performed as described above in order to connect to the always-on bearer, the UE goes from IDLE mode to CONNECTED mode. If the UE has changed its eNB when it was in IDLE mode and connects to a new eNB, then the security context of the UE has to be transferred from the old eNB to the new eNB. Described below are solutions for transferring the security context of the UE from the old eNB to the new eNB when a UE's eNB has changed,

[0030] One embodiment is as follows. For a user with low mobility, if the eNB does not change very often, then a normal service request procedure can be performed as described in Section 5.3.4 of 3GPP TS. 23.401. However, the new eNB should send a context release request to old eNB informing it to release the context pertaining to the UE. The UE can indicate that it has Low Mobility state to the eNB in the NAS Service Request. The new eNB, on receiving the Low Mobility indication, uses the ECGI (E-UTRAN cell global identifier), and old eNB IP address to establish an X2 Connection with the old eNB and sends a UE Context Release message. The existing UE Context Release message may be enhanced in order to inform the old eNB to release resources. A new message over the X2 interface, UE Context Release Reply, is created which is used to inform the new eNB of success / failure. Once, the new eNB receives confirmation of deletion of UE context, the normal Service Request procedure continues. Alternatively, context in the old eNB can be released by the S-GW once S1-U is established with the new eNB.

[0031] Another embodiment is as illustrated in Fig. 11. In this solution, the UE transfers the security context from the old eNB to the new eNB using the X2 interface. The UE obtains information about the eNB to which it is last connected to before it goes from CONNECTED mode to IDLE MODE. The UE obtains the ECGI and the IP address of the eNB piggybacked in an RRC Connection Release message at stages 1 and 2. After it enters the IDLE mode, then UE may be mobile and change eNBs. When the UE initiates or when there is a network initiated Service Request at stage 3, the UE connects to the new eNB and piggybacks its last eNB information to the new eNB in the NAS Service Request at stage 4. The new eNB checks if the UE has changed eNBs while in IDLE mode by comparing the ECGI sent by UE with its own ECGI at stage 5. If the E-CGI's differ, then the eNB uses the IP address information of the last eNB and establishes an X2 connection with it at stage 6. The Request Security Context X2 message at stage 7 is defined in order to request the old eNB to handover the relevant security context to the new eNB pertaining to the UE. The Security Context Response message at stage 8 is also defined in order to carry the security context from the old eNB to the new eNB over the X2 interface. Once the new eNB receives the security context from the last eNB to which UE was attached, it performs establishes the security context for the UE and the call flow continues such as from stage 6 in the enhanced Service Request procedure illustrated in Fig. 8.

[0032] in another embodiment, the Configuration Transfer procedure is used to transfer the security context at the Old eNB to the new eNB via the MME. When a UE initiates a Service Request procedure, it sends the new eNB the ECGI of the eNB it was last connected to. This is accomplished by piggybacking the last eNB information on the NAS Service Request. The eNB compares ECGI information with its own ECGI information and checks if the UE has changed eNBs. If so, the new eNB initiates a configuration transfer procedure as shown in Fig. 12. At stage 1, the new eNB sends the MME an eNB Configuration Transfer message with the SON (self organizing network) Configuration Transfer IE and SON Information Request IE. At stage 2, the MME transparently forwards this message to the eNB indicated in the Target eNB-ID IE which is included in the SON Configuration Transfer IE. At stages 3 and 4, the old eNB, on receiving the SON Information IE containing the SON Information Request IE, transfers back the requested information towards the eNB indicated in the Source eNB-ID IE of the SON Configuration Transfer IE by initiating the eNB Configuration Transfer procedure. The Configuration Transfer messages are enhanced in order to request the security context from the old eNB. In this embodiment, the context transfer via the MME as depicted in Fig. 12 would replace stages 6 through 8 in Fig. 11

[0033] The embodiments as described above may be implemented in various hardware configurations that may include a processor for executing instructions that perform the techniques described. Such, instructions may be contained in a machine-readable medium such as a suitable storage medium or a memory or other processor-executable medium.

[0034] The embodiments as described herein may be implemented in a number of environments such as part of a wireless local area network (WLAN), 3rd Generation Partnership Project (3GPP) Universal Terrestrial Radio Access Network (UTRAN), or Long-Term-Evolution (LTE) or a Long-Term-Evolution 10 (LTE) communication system, although the scope of the invention is not limited in this respect. An example LTE system includes a number of mobile stations defined by the LTE specification as User Equipment (UE), communicating with a base station, defined by the LTE specifications as eNode-B.

[0035] Antennas referred to herein may comprise one or more directional or omnidirectional antennas, including, for example, dipole antennas, monopole antennas, patch antennas, loop antennas, microstrip antennas or other types of antennas suitable for transmission of RF signals. In some embodiments, instead of two or more antennas, a single antenna with multiple apertures may be used. In these embodiments, each aperture may be considered a separate antenna. In some multiple-input multiple-output (MIMO) embodiments, antennas may be effectively separated to take advantage of spatial diversity and the different channel characteristics that may result between each of antennas and the antennas of a transmitting station. In some MIMO embodiments, antennas may be separated by up to 1 / 10 of a wavelength or more.

[0036] In some embodiments, a receiver as described herein may be configured to receive signals in accordance with specific communication standards, such as the Institute of Electrical and Electronics Engineers (IEEE) standards including IEEE 802.11-2007 and / or 802.11(n) standards and / or proposed specifications for WLANs, although the scope of the invention is not limited in this respect as they may also be suitable to transmit and / or receive communications in accordance with other techniques and standards. In some embodiments, the receiver may be configured to receive signals in accordance with the IEEE 802.16-2004, the IEEE 802.16(e) and / or IEEE 802.16(m) standards for wireless metropolitan area networks (WMANs) including variations and evolutions thereof! although the scope of the invention is not limited in this respect as they may also be suitable to transmit and / or receive communications in accordance with other techniques and standards. In some embodiments, the receiver may be configured to receive signals in accordance with the Universal Terrestrial Radio Access Network (UTRAN) LTE communication standards. For more information with respect to the IEEE 802.11 and IEEE 802.16 standards, please refer to "IEEE Standards for Information TechnologyTelecommunications and Information Exchange between Systems" - Local Area Networks - Specific Requirements - Part 11 "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY), ISO / IEC 8802-11: 1999", and Metropolitan Area Networks - Specific Requirements-- Part 16: "Air Interface for Fixed Broadband Wireless Access Systems," May 2005 and related amendments / versions. For more information with respect to UTRAN LTE standards, see the 3rd Generation Partnership Project (3GPP) standards for UTRAN-LTE, release 8, March 2008, including variations and evolutions thereof.

Claims

1. An apparatus of an enhanced Node B, eNB (105), configured for user plane evolved packet system, EPS, signaling overhead reduction functionality, the apparatus comprising: processing circuitry (105a) configured to: receive, from a user equipment, UE (100), in one of a radio resource control, RRC, Connection Request message or an Attach Request message, a request for an always-on S1-U bearer that persists as the UE transitions between an RRC connected state and an RRC idle state; instruct a mobility management entity, MME, to use the always-on S1-U bearer for the UE; perform a connection release procedure to release an RRC connection of the UE (100) that uses the always-on S1-U bearer while the UE is in an EPS connection management, ECM, connected state, wherein the connection release procedure comprises: storing a UE (100) context for the UE (100) when the UE (100) enters into an ECM-IDLE state from the ECM connected state; and sending an RRC connection release message to indicate to the UE (100) that the RRC connection is released; perform a connection re-establishment procedure to re-establish the RRC connection with the UE (100) to transition the UE (100) from the ECM idle state to the ECM connected state, the connection re-establishment procedure using the context of the UE to re-establish the RRC connection for the UE; and receive from the UE (100) retained S-GW information to be used by the eNB (105) to associate the always-on S1-U bearer with the re-established RRC connection.

2. The apparatus of claim 1 wherein when the request for the always-on S1-U bearer is received from the UE (100), the processing circuitry (105a) is to: preserve the UE (100) context during an S1 release procedure and when the UE (100) transitions to the ECM idle state.

3. The apparatus of claim 2 wherein the apparatus further includes: a radio interface for communicating with UEs (100); an S1-MME network interface for communicating with the MME (110); and an S1-U network interface for communicating with a serving gateway, S-GW (115).

4. The apparatus of claim 1, wherein the one of the RRC Connection Request message or the Attach Request message is the RRC Connection Request message, and wherein the RRC Connection Request message comprises an always-on S1-U indicator information element to indicate that the UE (100) wants to create the always-on S1-U bearer, wherein the information element indicates also either mobile originating or terminating access for the always-on S1-U bearer.

5. The apparatus of claim 4, wherein the always-on S1-U indicator information element is provided to a serving gateway, S-GW.

6. The apparatus of claim 1, wherein the one of the RRC Connection Request message or the Attach Request message is the Attach Request message, and wherein the Attach Request message further comprises an always-on indicator to indicate that the UE (100) wants to create the always-on S1-U bearer.

7. A non-transitory computer-readable storage medium that stores instructions for execution by one or more processors of an enhanced Node B, eNB, to cause the eNB to perform operations to: receive, from a user equipment, UE (100), in one of a radio resource control, RRC, Connection Request message or an Attach Request message, a request for an always-on S1-U bearer that persists as the UE transitions between an RRC connected state and an RRC idle state; instruct a mobility management, MME, (110) to use the always-on S1-U bearer for the UE; cause a connection release procedure to release an, RRC, connection of the UE (100) that uses the always-on S1-U bearer while the UE is in an EPS connection management, ECM, connected state, wherein the connection release procedure comprises: storing UE (100) context for the UE (100) when the UE (100) enters into an ECM-IDLE state from the ECM connected state; and sending a RRC connection release message to indicate to the UE (100) that the RRC connection is released; perform a connection re-establishment procedure to re-establish an RRC connection with a UE (100) to transition the UE (100) from an ECM idle state to an ECM connected state, the connection re-establishment procedure using the context of the UE to re-establish an RRC connection for the UE receive from the UE (100) retained S-GW information to be used by the eNB (105) to associate the always-on S1-U bearer with the re-established RRC connection.

8. The non-transitory computer-readable storage medium of claim 7 wherein when the request for the always-on S1-U bearer is received from the UE (100), the processing circuitry (105a) is to: preserve the UE (100) context during an Si release procedure and when the UE (100) transitions to the ECM idle state.