ALWAYS-ON BEARER FOR SMALL DATA TRANSFERS IN LTE SYSTEMS

• US 20150223284A1
• Filed: 09/27/2013
• Published: 08/06/2015
• Est. Priority Date: 09/28/2012
• Status: Active Grant

• Current Assignee: Apple Inc.
• Original Assignee: Intel Corporation
• Inventors: Jain, Puneet, Rao, Varun, Stojanovski, Alexandre Saso
• Granted Patent: US 9,609,602 B2
• Time in Patent Office: Days
• US Class Current: 1/1
• CPC Class Codes: H04B 17/318 Received signal strength
• CPC Class Codes: H04J 11/00 Orthogonal multiplex systems, e.g. using WALSH codesH04J13/00 takes precedence
• CPC Class Codes: H04J 11/0086 Search parameters, e.g. search strategy, accumulation length, range of search, thresholds code acquisition in DSSS H04B1/7075
• CPC Class Codes: H04J 3/1694 Allocation of channels in TDM/TDMA networks, e.g. distributed multiplexers Passive Optical Networks H04Q11/0062
• CPC Class Codes: H04L 1/1812 Hybrid protocols; Hybrid automatic repeat request [HARQ]
• CPC Class Codes: H04L 1/1861 Physical mapping arrangements for ACK signaling see also H04L5/0053
• CPC Class Codes: H04L 1/1864 ARQ related signaling H04L1/1607 takes precedence
• CPC Class Codes: H04L 1/1893 Physical mapping arrangements physical resource mapping in general H04L5/00
• CPC Class Codes: H04L 41/069 using logs of notifications; Post-processing of notifications
• CPC Class Codes: H04L 41/5032 Generating service level reports
• CPC Class Codes: H04L 43/16 Threshold monitoring
• CPC Class Codes: H04L 5/001 the frequencies being arranged in component carriers
• CPC Class Codes: H04L 5/0035 Resource allocation in a cooperative multipoint environment
• CPC Class Codes: H04L 5/0055 Physical resource allocation for ACK/NACK for physical mapping arrangements in ARQ protocols H04L1/1861
• CPC Class Codes: H04L 5/0057 Physical resource allocation for CQI
• CPC Class Codes: H04L 5/0073 Allocation arrangements that take into account other cell interferences for intercell interference mitigation or co-ordination in orthogonal multiplex systems H04J11/005
• CPC Class Codes: H04L 5/0091 Signaling for the administration of the divided path
• CPC Class Codes: H04L 5/14 Two-way operation using the same type of signal, i.e. duplex
• CPC Class Codes: H04L 65/60 Network streaming of media packets
• CPC Class Codes: H04L 65/612 for unicast
• CPC Class Codes: H04L 65/65 : Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
• CPC Class Codes: H04L 65/762 : at the source reformatting of additional data in video distribution servers H04N21/2355
• CPC Class Codes: H04L 67/10 : in which an application is distributed across nodes in the network software deployment G06F8/60; multiprogramming arrangements G06F9/46
• CPC Class Codes: H04W 24/02 : Arrangements for optimising operational condition
• CPC Class Codes: H04W 24/08 : Testing, supervising or monitoring using real traffic
• CPC Class Codes: H04W 24/10 : Scheduling measurement reports ; Arrangements for measurement reports
• CPC Class Codes: H04W 28/0205 : at the air interface dynamic wireless traffic scheduling H04W72/12
• CPC Class Codes: H04W 28/0215 : based on user or device properties, e.g. MTC-capable devices services for machine-to-machine communication [M2M] or machine type communication [MTC] H04W4/70; wireless resource selection or allocation plan definition based on terminal or device properties H04W72/51
• CPC Class Codes: H04W 28/0221 : power availability or consumption
• CPC Class Codes: H04W 28/0252 : per individual bearer or channel dynamic wireless traffic scheduling H04W72/12
• CPC Class Codes: H04W 28/0268 : using specific QoS parameters for wireless networks, e.g. QoS class identifier [QCI] or guaranteed bit rate [GBR] negotiating SLA or negotiating QoS H04W28/24
• CPC Class Codes: H04W 28/16 : Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
• CPC Class Codes: H04W 36/0061 : of neighbour cell information
• CPC Class Codes: H04W 36/0066 : of control information between different types of networks in order to establish a new radio link in the target network
• CPC Class Codes: H04W 36/0083 : Determination of parameters used for hand-off, e.g. generation or modification of neighbour cell lists
• CPC Class Codes: H04W 36/0085 : Hand-off measurements
• CPC Class Codes: H04W 36/0088 : Scheduling hand-off measurements
• CPC Class Codes: H04W 36/08 : Reselecting an access point
• CPC Class Codes: H04W 36/14 : Reselecting a network or an air interface
• CPC Class Codes: H04W 36/22 : for handling the traffic
• CPC Class Codes: H04W 4/70 : Services for machine-to-machine communication [M2M] or machine type communication [MTC]
• CPC Class Codes: H04W 40/005 : Routing actions in the presence of nodes in sleep or doze mode
• CPC Class Codes: H04W 40/246 : Connectivity information discovery
• CPC Class Codes: H04W 48/14 : using user query or user detection
• CPC Class Codes: H04W 48/16 : Discovering, processing access restriction or access information
• CPC Class Codes: H04W 48/18 : Selecting a network or a communication service
• CPC Class Codes: H04W 48/20 : Selecting an access point
• CPC Class Codes: H04W 52/0209 : in terminal devices terminal devices per se H04W88/02
• CPC Class Codes: H04W 52/0212 : managed by the network, e.g. network or access point is master and terminal is slave
• CPC Class Codes: H04W 52/0225 : using monitoring of external events, e.g. the presence of a signal
• CPC Class Codes: H04W 52/0235 : where the received signal is a power saving command
• CPC Class Codes: H04W 52/0258 : controlling an operation mode according to history or models of usage information, e.g. activity schedule or time of day
• CPC Class Codes: H04W 52/0261 : managing power supply demand, e.g. depending on battery level
• CPC Class Codes: H04W 52/04 : TPC
• CPC Class Codes: H04W 52/14 : Separate analysis of uplink or downlink
• CPC Class Codes: H04W 72/02 : Selection of wireless resources by user or terminal
• CPC Class Codes: H04W 72/044 : based on the type of the allocated resource
• CPC Class Codes: H04W 72/0453 : Resources in frequency domain, e.g. a carrier in FDMA
• CPC Class Codes: H04W 72/20 : Control channels or signalling for resource management
• CPC Class Codes: H04W 72/21 : in the uplink direction of a wireless link, i.e. towards the network
• CPC Class Codes: H04W 72/23 : in the downlink direction of a wireless link, i.e. towards a terminal
• CPC Class Codes: H04W 72/30 : Resource management for broadcast services
• CPC Class Codes: H04W 72/52 : based on load
• CPC Class Codes: H04W 72/541 : using the level of interference
• CPC Class Codes: H04W 74/002 : Transmission of channel access control information
• CPC Class Codes: H04W 74/004 : in the uplink, i.e. towards network
• CPC Class Codes: H04W 76/12 : Setup of transport tunnels
• CPC Class Codes: H04W 76/15 : Setup of multiple wireless link connections
• CPC Class Codes: H04W 76/16 : Involving different core network technologies, e.g. a packet-switched [PS] bearer in combination with a circuit-switched [CS] bearer
• CPC Class Codes: H04W 76/23 : Manipulation of direct-mode connections
• CPC Class Codes: H04W 76/27 : Transitions between radio resource control [RRC] states
• CPC Class Codes: H04W 76/28 : Discontinuous transmission [DTX]; Discontinuous reception [DRX]
• CPC Class Codes: H04W 76/30 : Connection release
• CPC Class Codes: H04W 8/08 : Mobility data transfer
• CPC Class Codes: H04W 80/10 : adapted for application session management, e.g. SIP [Session Initiation Protocol] connection management H04W76/00; arrangements for session management H04L67/14
• CPC Class Codes: H04W 84/042 : Public Land Mobile systems, e.g. cellular systems
• CPC Class Codes: H04W 84/12 : WLAN [Wireless Local Area Networks]
• CPC Class Codes: H04W 88/02 : Terminal devices
• CPC Class Codes: H04W 88/06 : adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals
• CPC Class Codes: H04W 88/08 : Access point devices
• CPC Class Codes: H04W 88/12 : Access point controller devices
• CPC Class Codes: H04W 88/14 : Backbone network devices
• CPC Class Codes: H04W 88/16 : Gateway arrangements
• CPC Class Codes: H04W 88/18 : Service support devices; Network management devices
• CPC Class Codes: Y02D 30/70 : in wireless communication networks

Abstract

When a UE in an LTE system 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. Described herein are methods and systems that provide an always-on S1-U bearer to reduce this signaling overhead.

Claims

1. An evolved Node B (eNB) for operating in an LTE (Long Term Evolution) network, comprising:

processing circuitry;

a radio interface for communicating with user equipment (UEs);

an S1-MME network interface for communicating with a mobile management entity (MME);

an S1-U network interface for communicating with a serving gateway (S-GW);

wherein the processing circuitry is to, when a request for an always-on S1-U bearer is received from the UE, instruct the MME to provide the UE with an S1-U bearer that persists as the UE moves between RRC_CONNECTED and RRC_IDLE states and preserve the UE context information during an S1 Release procedure or when the UE otherwise goes into an RRC_IDLE or ECM-IDLE state.

2. The eNB of claim 1 wherein the processing circuitry is to receive the request for the always-on S1-U bearer via an RRC Connection Request message from the UE with an always-on indicator contained therein.

3. The eNB of claim 2 wherein the always-on indicator in the RRC Connection Request message is an establishment cause for either mobile originating access or mobile terminating access.

4. The eNB of claim 1 wherein the processing circuitry is to inform the MME of the request for the always-on S1-U bearer by forwarding the establishment cause of the RRC Connection Request message containing the always-on indicator in an S1-AP Initial UE message to the MME.

5. The eNB of claim 1 wherein the processing circuitry is to inform the MME of the request for the always-on S1-U bearer by using non-access stratum (NAS) messages sent from the UE to the eNB and thence to the MME.

6. The eNB of claim 5 wherein the processing circuitry is to inform the MME of the request for the always-on S1-U bearer by forwarding an Attach Request message from the UE containing the always-on indicator in the EPS Attach Type field of the message.

7. The eNB of claim 5 wherein the processing circuitry is to inform the MME of the request for the always-on S1-U bearer by forwarding an Attach Request message from the UE containing the always-on indicator in the Update Type field of the message.

8. The eNB of claim 5 wherein the processing circuitry is to inform the MME of the request for the always-on S1-U bearer by forwarding an Attach Request message from the UE containing the always-on indicator in a separate information element (IE) of the message.

9. The eNB of claim 5 wherein the processing circuitry is to inform the MME of the request for the always-on S1-U bearer by forwarding a Service Request message from the UE containing the always-on indicator.

10. The eNB of claim 5 wherein the processing circuitry is to inform the MME of the request for the always-on S1-U bearer by forwarding a Tracking Area Update Request message from the UE containing the always-on indicator.

11. The eNB of claim 1 wherein the processing circuitry is to, after receiving an Attach Accept message from the MME in response to the Attach Request sent by the UE, forward the Attach Accept message to the UE, wherein the IP (internet protocol) address of the selected S-GW and the S-GW TEID (tunnel endpoint identifier) assigned to the always-on S1-U bearer are contained in the Attach Accept message.

12. The eNB of claim 1 wherein the processing circuitry is to, after receiving an Attach Accept message from the MME in response to the Attach Request sent by the UE, send an RRC Connection Reconfiguration message to the UE, wherein the IP (internet protocol) address of the selected S-GW and the S-GW TEID (tunnel endpoint identifier) assigned to the always-on S1-U bearer are contained in the RRC Connection Reconfiguration message.

13. The eNB of claim 1 wherein the processing circuitry is to, upon expiration of a user inactivity timer for a particular UE, check if an S1-U bearer for the particular UE is an always-on bearer and, if so, initiate an S1 Release procedure while retaining the particular UE'"'"'s context.

14. The eNB of claim 13 wherein the processing circuitry is to, after initiating an S1 Release for a UE with an always-on S1-U bearer, if a handover has occurred such that the UE has been assigned to a new eNB with an S-GW relocation, embed the new S-GW IP address and S-GW TEID assigned to the always-on S1-U bearer in an RRC Connection Release message.

15. The eNB of claim 1 wherein the processing circuitry is to, when a Tracking Area Update procedure with a change in S-GW occurs for a UE with an always-on S1-U bearer, forward the Tracking Area Update Accept message from the MME to the UE along with the new S-GW IP address and S-GW TEID assigned to the always-on S1-U bearer.

16. The eNB of claim 1 wherein the processing circuitry is to, after receiving an NAS Service Request message from a UE with an always-on S1-U bearer along with an S-GW IP address and S-GW TEID assigned to the always-on S1-U bearer, map the always-on S1-U bearer to a radio bearer of the UE.

17. The eNB of claim 16 wherein the processing circuitry is to, after mapping the always-on S1-U bearer to the radio bearer of the UE, connect to the always-on S1-U bearer and transmit data to the S-GW to inform the S-GW of the DL (downlink) eNB TEID.

18. The eNB of claim 1 wherein the processing circuitry is to, if a handover has occurred such that a UE with an always-on S1-U bearer has been newly assigned to the eNB, send a Path Switch Request Message to the UE'"'"'s MME and acquire the new S-GW IP address and S-GW TEID assigned to the always-on S1-U bearer from the MME in a Path Switch Request Acknowledge message.

19. The eNB of claim 1 further comprising:

an X2 network interface for communicating with another eNB;

wherein the processing circuitry is to;

after receiving an NAS Service Request message from a UE with an always-on S1-U bearer along with an S-GW IP address, S-GW TEID assigned to the always-on S1-U bearer, last eNB IP address, and last eNB ECGI (E-UTRAN Cell Global Identifier), and if the UE'"'"'s eNB has changed and a low mobility indication has been received from the UE;

send an enhanced UE Context Release message to the UE'"'"'s last eNB that informs the last eNB to release resources associated with the always-on S1-U bearer;

re-establish security context with the UE.

20. The eNB of claim 1 further comprising:

an X2 network interface for communicating with another eNB;

wherein the processing circuitry is to;

after receiving an NAS Service Request message from a UE with an always-on S1-U bearer along with an S-GW IP address, S-GW TEID assigned to the always-on S1-U bearer, last eNB IP address, and last eNB ECGI (E-UTRAN Cell Global Identifier), and if the UE'"'"'s eNB has changed;

send a Request Security Context message to the last eNB in order to request the last eNB to transfer the UE'"'"'s security context; and

,

receive a Security Context Response message from the last eNB that includes the UE'"'"'s security context.

21. The eNB of claim 1 further comprising:

an X2 network interface for communicating with another eNB;

wherein the processing circuitry is to;

after receiving an NAS Service Request message from a UE with an always-on S1-U bearer along with an S-GW IP address, S-GW TEID assigned to the always-on S1-U bearer, last eNB IP address, and last eNB ECGI (E-UTRAN Cell Global Identifier), and if the UE'"'"'s eNB has changed;

send to the UE'"'"'s MME an enhanced eNB Configuration Transfer message with the SON (Self-Organizing Network) Configuration Transfer IE and SON Information Request IE for forwarding to the last eNB as indicated in the Target eNB-ID IE included in the SON Configuration Transfer IE; and

,

receive the information requested by the enhanced eNB Configuration Transfer message from the last eNB including the UE'"'"'s security context.

22. A mobile management entity (MME) for operating in an LTE (Long Term Evolution) network, comprising:

processing circuitry;

an S1-MME network interface for communicating with a evolved Node B (eNB);

an S11 network interface for communicating with a serving gateway (S-GW);

wherein the processing circuitry is to, when a request for an always-on S1-U bearer is forwarded by the eNB from a UE (user equipment), establish an always-on S1-U bearer for the UE that persists as the UE moves between RRC_CONNECTED and RRC_IDLE states and preserve the UE context information during an S1 Release procedure or when the UE otherwise goes into an RRC_IDLE or ECM-IDLE state.

23. The MME of claim 22 wherein the processing circuitry is to establish the always-on S1-U bearer by sending a Create Session Request message, with a request type set to an always-on S1-U bearer, to a selected S-GW which is forwarded to a P-GW (packet data network gateway) in order to set up a default EPS (evolved packet system) bearer.

24. The MME of claim 23 further comprising an S6a network interface for communicating with an HSS (home subscriber server) and wherein the processing circuitry is to, before sending the Create Session Request message to establish the always-on S1-U bearer, confirm the need for the always-on S1U bearer by verifying the UE'"'"'s subscription data with the HSS.

25. The MME of claim 23 wherein the processing circuitry is to receive a Create Session Response message forwarded by the S-GW from the P-GW in response to the Create Session Request message and send an Attach Accept message to the UE as forwarded by the eNB to inform the UE of the IP (internet protocol) address of the selected S-GW and the S-GW TEID (tunnel endpoint identifier) assigned to the always-on S1-U bearer.

26. The MME of claim 23 wherein the processing circuitry is to, when eNB and S-GW relocations to a new eNB and a new S-GW occur and after receiving a Path Switch Request message from the new eNB, send a Create Session Request message to the new S-GW that updates bearer contexts for the default bearers that have been accepted by the new eNB, receive a Create Session Response message from the new S-GW, and send a Path Switch Request Acknowledgement message to the new eNB that contains updates for the IP address of the S-GW and the S-GW TEID (tunnel endpoint identifier) assigned to the always-on S1-U bearer.

27. A method for operating a serving gateway (S-GW) in an LTE (Long Term Evolution) network, comprising:

receiving a Create Session Request message with a request type set to an always-on S1-U bearer is received from an MME (mobility management entity) for a UE (user equipment); and

,

setting up a default EPS bearer with an always-on S1-U bearer for the UE that persists during an S1 Release procedure or when the UE otherwise goes into an RRC_IDLE or ECM-IDLE state.

28. The method of claim 27 further comprising, if the UE is not in a high mobility state, assigning the S-GW TEID (tunnel endpoint identifier) for the always-on S1-U bearer so that its value is unique for the S1-U interface used for the always-on S1-U bearer.

29. The method of claim 27 further comprising, if the UE is in a high mobility state, assigning the S-GW TEID (tunnel endpoint identifier) for the always-on S1-U bearer so that its value is unique across all S1-U interfaces served by the S-GW.

30. The method of claim 27 further comprising running an inactivity timer of same or less value than an inactivity timer used by the eNB and, if the S-GW'"'"'s inactivity timer expires, marking the UE as idle and send a downlink data notification to the MME if downlink data for the UE is received.

31. A UE (user equipment) for operating in an LTE (Long Term Evolution) network, comprising:

a radio transceiver to provide an air interface for communicating with an eNB (evolved node B); and

processing circuitry connected to the radio transceiver to, if an application is run with small data transfers such that the number of transitions between RRC_CONNECTED and RRC_IDLE states exceeds a specified threshold, send a message to the eNB that requests an always-on S1-U bearer that persists as the UE moves between RRC_CONNECTED and RRC_IDLE states.

32. The UE of claim 31 wherein the processing circuitry is to send the request for the always-on S1-U bearer via an RRC Connection Request message from the UE with an always-on indicator contained therein.

33. The UE of claim 31 wherein the processing circuitry is to send the request for the always-on S1-U bearer to the eNB via a non-access stratum (NAS) message.