WO2019157732A1

WO2019157732A1 - Systems and methods for bearer identifier transfer between functionalities with non-homogeneous bearer capabilities

Info

Publication number: WO2019157732A1
Application number: PCT/CN2018/076873
Authority: WO
Inventors: Shuang Liang; Fei Lu; Jinguo Zhu; Zhendong Li
Original assignee: Zte Corporation
Priority date: 2018-02-14
Filing date: 2018-02-14
Publication date: 2019-08-22

Abstract

Systems, methods and devices for bearer identifier transfer between functionalities with non-homogeneous bearer capabilities are disclosed herein. In accordance with one exemplary embodiment, a method includes: receiving a request to transfer one or more bearer contexts, where the bearer contexts comprise a bearer identifier value; determining whether to transfer the bearer contexts using first information elements or second information elements based on the bearer identifier value; transferring the bearer contexts; and receiving a confirmation of bearer context setup.

Description

SYSTEMS AND METHODS FOR BEARER IDENTIFIER TRANSFER BETWEEN FUNCTIONALITIES WITH NON-HOMOGENEOUS BEARER CAPABILITIES

TECHNICAL FIELD

The disclosure relates generally to wireless communications and, more particularly, to systems and methods for bearer identifier transfer between functionalities with non-homogeneous bearer capabilities.

BACKGROUND

As the number of applications and services for digital data continues to explode, the demands and challenges placed on network resources and operators will continue to increase. Being able to deliver a wide variety of network performance characteristics that future services will demand is one of the primary technical challenges faced by service providers today. The performance requirements placed on the network will demand connectivity in terms of data rate, latency, QoS, security, availability, and many other parameters, all of which will vary from one service to the next. Thus, enabling a network to allocate resources in a flexible manner to provide customized connectivity for each different type of service will greatly enhance the network’s ability to meet future demands.

As used herein, the term "network" or "communication network" refers to infrastructure resources provided by a network operator to provide data communication services, which may include both wired and wireless services, to customers of the network operation. Examples of such network operators include AT&T, Verizon, Sprint, Vodafone, etc. Such a network may include a core portion, a radio access network (RAN) portion and backhaul portion, for example. The network may further comprise various virtualized resources and functions as would be understood by persons of ordinary skill in the art. As these networks adopt the next generation network standards (i.e., 5G) , referred to as “5G networks, ” they will become capable of dynamic reconfiguration, as described in further detail below.

Figure 1 illustrates an exemplary conventional architecture of an evolved packet system (EPS) 100. The EPS 100 may include a radio network controller (RNC) 102 and an evolved node B (E-NodeB or eNodeB) 102 as part of a radio access network (RAN) .

At the core network, a serving general packet radio service support (GPRS) node (SGSN) 104 may communicate with the RNC 102 over an interface Iu. A mobility management entity (MME) 106 may communicate with the SGSN 104 over an interface S3, communicate with the E-NodeB over an interface S1-MME, and with itself via an interface S10. A serving gateway (Serving GW) 108 may communicate with the SGSN 106 via an interface S4, the MME 108 via an interface S11, and the E-NodeB 104 via an interface S1-U. A home subscriber service (HSS) 112 may communicate with the SGSN 106 via an interface Gr and with the MME 108 via an interface S6a. A packet data network gateway (PDN GW) 114 may communicate with the Serving GW 110 via an interface S5. A policy and charging rules function (PCRF) 116 may communicate with the PDN GW 114 via an interface S7. A packet data network (PDN) 118 may communicate with the PCRF 116 via an interface Rx+ and with the PDN GW 114 via an interface SGi.

In the evolved packet core (EPC packet core) network (e.g., the core network part of the EPS 100) , the HSS 112 may be a permanent storage site of user subscription data, located in a user subscription home network. The MME 108 may be a storage site of the user subscription data in the current network and be responsible for signaling management from a terminal (e.g., a user equipment, or UE) to a non-access stratum (NAS) of the network, tracking and paging management function of the user in an idle mode, and bearer management. The serving gateway (S-GW or Serving GW 110) may be a gateway from the core network to a wireless system. The Serving GW 110 may be responsible for a user plane bearer from the terminal (e.g., UE) to the core network, data cache of the terminal (e.g., UE) in an idle mode, a function of the network side sending a service request, lawful eavesdropping and packet data routing and forwarding function, and the like. The packet data network gateway (PDN GW) 114 (e.g., P-GW) is a gateway of the evolved packet system (EPS) and an external network of the system and may be responsible for functions, such as, internet protocol (IP) address allocation of the terminal (e.g., UE) , charging function, packet filtering, policy application and so on. The SGSN 106 may be a service support point of accessing to the EPC network by the user of the GSM EDGE radio access network (GERAN) and universal terrestrial radio access network (UTRAN) , of which the function may be similar to that of the MME. The SGSN 106 may be responsible for functions, such as location update of the user, paging management and bearer management. The PCRF 116 may be responsible for providing a policy control and charging rule to a policy and charging enforcement function (PCEF) .

Figure 2 illustrates an exemplary conventional interworking architecture 200 between an EPS and a 5G core network (5GC) . The interworking architecture 200 may include a user equipment (UE) 202. The UE may also be referred to as a terminal. The UE may be connected with an Access and Mobility Management Functionality (AMF) 208 via a N1 interface, a 5G RAN 204 via a 5G radio interface, a 4G RAN via a 4G radio interface, and a MME 214 via a EPC non-access stratum (NAS) interface. The AMF 208 may be connected with the 5G RAN 204 via an N2 interface, the MME via an N26/S10 interface, and a session management function /gateway-control plane (SMF/GW-C) 216 via an N11 interface. The MME may be connected with the 4G RAN 206 via a S1-C interface, and with a S-GW 212 via a S11 interface. The S-GW 212 may be connected with the 4G RAN 206 via a S1-U interface, the SMF/GW-C 216 via the S5-C interface, and a user plane function /gateway-user plane (UPF/GW-U) 218 via a S5-U interface, and the 5G RAN 204 via the N3 interface, and a data network (DN) 220. A policy and charging rules function /policy control function (PCRF/PCF) 222 may be connected with the SMF/GW-C. Also, the interworking architecture 200 may include a home subscriber server /unified data management (HSS/UDM) 224.

The AMF 208 may not necessarily handle the session management (SM) messages between the UE 202 and the SMF 216 or between the next generation (NG) RAN and SMF 216. It may be assumed that a UE 202 that is capable of supporting 5GC non-access stratum (NAS) procedures may also be capable of supporting EPC NAS to operate in legacy networks. Stated another way, the UE may use EPC NAS in the legacy network and 5GC NAS in 5G access. The UE 202 may use EPC NAS or 5GC NAS procedures, depending on the core network by which it is served. In order to support smooth migration, the EPC and the 5GC may have access to a common subscriber database. For example, the HSS 224 in case of EPC and the unified data management (UDM) 224 in case of 5GC. The N26 interface may be an inter-core network (CN) interface between the MME and 5GS AMF in order to enable interworking between EPC and the next generation (NG) core. Support of the N26 interface in the network is optional for interworking. By interworking, the UE may move between 5G and 4G RANs in a manner involving both RAN nodes and CN nodes. The N26 may support a subset of the functionalities (which may be essential for interworking) that are supported over S10.

Nodes with multiple functionalities (e.g., PCF + PCRF; packet data network gateway -control plane (PGW-C) + SMF; and user plane function (UPF) + PGW-U) may be dedicated for interworking between 5GS and EPC. However, such multiple functionality nodes are optional and are based on UE and network capabilities. UEs that are not subject to 5GS and EPC interworking may be served by entities not dedicated for interworking (e.g., either by a packet data network gateway (PGW) /PCRF or SMF/user plane function (UPF) /policy control function (PCF) ) .

A bearer may refer to a particular path that data traffic may flow when passing through a network. Certain legacy systems may not support more than a set number of bearer identifiers or contexts. A bearer identifier may refer to a bearer context (e.g., a collection of information characterizing a bearer) . For example, in legacy evolved packet systems (EPS) , radio access networks (RANs) (e.g., eNodeBs) may only support 8 maximum bearers simultaneously. Also, for EPS bearer identifier (ID) coding, 11 bearer IDs may be allocated by a mobility management entity (MME) . However, newer communication systems contemplate supporting more than the previously supported set number of bearers. For example, new features supporting 15 bearers are being introduced. However, legacy EPS which may support a set number of bearers (e.g., 8 bearers) may not support more than 8 bearers. As a result of non-homogeneous bearer capabilities (e.g., different systems supporting different number of bearers) , incompatibilities may result when functionalities (e.g., specific functions performed by a node of a RAN) are transferred between different systems (e.g., different nodes or different RANs) that support different numbers of bearers. For example, a system that supports 15 bearers may have difficulty transferring functionalities to a system that supports only 8 bearers.

SUMMARY OF THE INVENTION

The exemplary embodiments disclosed herein are directed to solving the issues relating to one or more of the problems presented in the prior art, as well as providing additional features that will become readily apparent by reference to the following detailed description when taken in conjunction with the accompany drawings. In accordance with various embodiments, exemplary systems, methods, devices and computer program products are disclosed herein. It is understood, however, that these embodiments are presented by way of example and not limitation, and it will be apparent to those of ordinary skill in the art who read the present disclosure that various modifications to the disclosed embodiments can be made while still remaining within the scope of the invention.

In accordance with one exemplary embodiment, a method includes: receiving a request to transfer one or more bearer contexts, where the bearer contexts comprise a bearer identifier value; determining whether to transfer the bearer contexts using first information elements or second information elements based on the bearer identifier value; transferring the bearer contexts; and receiving a confirmation of bearer context setup.

In another embodiment, an apparatus includes: a receiver configured to: receive a request to transfer one or more bearer contexts, where the bearer contexts comprise a bearer identifier value, and receive a confirmation of bearer context setup; at least one processor configured to: determine whether to transfer the bearer contexts using first information elements or second information elements based on the bearer identifier value; and a transmitter configured to: transfer the bearer contexts.

Another embodiment includes a non-transitory computer readable medium having instructions stored thereon, wherein the instructions, when executed by a processor, cause a device to perform operations including: receiving a request to transfer bearer contexts; determining, based on the request, whether to transfer the bearer contexts to a target, wherein the request indicates whether the target supports the bearer contexts; and transferring a first bearer context of the bearer contexts to the target.

BRIEF DESCRIPTION OF THE DRAWINGS

Various exemplary embodiments of the invention are described in detail below with reference to the following Figures. The drawings are provided for purposes of illustration only and merely depict exemplary embodiments of the invention. These drawings are provided to facilitate the reader's understanding of the invention and should not be considered limiting of the breadth, scope, or applicability of the invention. It should be noted that for clarity and ease of illustration these drawings are not necessarily drawn to scale.

Figure 1 illustrates an exemplary conventional architecture of an evolved packet system (EPS) 100.

Figure 2 illustrates an exemplary conventional interworking architecture 200 between an EPS and a 5G core network (5GC) .

Figure 3 is a block diagram of a node, in accordance with some embodiments.

Figure 4 is a flow chart of a serving gateway relocation process, in accordance with some embodiments.

Figure 5 is a flow chart of a mobility management entity relocation process, in accordance with some embodiments.

Figure 6 is a flow chart of a bearer context retrieval process, in accordance with some embodiments.

[Rectified under Rule 91, 20.06.2018]
Figure 7 is a flow chart of a tracking area update (TAU) or routing area update (RAU)process, in accordance with some embodiments.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Various exemplary embodiments of the invention are described below with reference to the accompanying figures to enable a person of ordinary skill in the art to make and use the invention. As would be apparent to those of ordinary skill in the art, after reading the present disclosure, various changes or modifications to the examples described herein can be made without departing from the scope of the invention. Thus, the present invention is not limited to the exemplary embodiments and applications described and illustrated herein. Additionally, the specific order or hierarchy of steps in the methods disclosed herein are merely exemplary approaches. Based upon design preferences, the specific order or hierarchy of steps of the disclosed methods or processes can be rearranged while remaining within the scope of the present invention. Thus, those of ordinary skill in the art will understand that the methods and techniques disclosed herein present various steps or acts in a sample order, and the invention is not limited to the specific order or hierarchy presented unless expressly stated otherwise.

As described below, the operations illustrated may refer to functional entities, such as UE, AMF, RAN, etc. (either in physical or virtual form) , which are similar to those mentioned above with respect to conventional communication systems. As would be understood by persons of ordinary skill in the art, however, such conventional functional entities do not perform the functions described below, and therefore, would need to be modified or specifically configured to perform one or more of the operations described below. Additionally, persons of skill in the art would be enabled to configure functional entities to perform the operations described herein after reading the present disclosure. The term “configured” as used herein with respect to a specified operation or function refers to a system, device, component, circuit, structure, machine, etc. that is physically or virtually constructed, programmed and/or arranged to perform the specified operation or function.

In the present disclosure, functional entities, or various discrete components of a network, communication network, or communication environment may be described herein as non-limiting examples of communication nodes or nodes, which can practice the methods, or a part of the methods, disclosed herein. Such communication nodes may be capable of wireless and/or wired communications, in accordance with various embodiments. Although various embodiments are described herein in the context of specific communication environments, it is understood that embodiments may be practiced in any communication environment in which two or more nodes can communicate with each other. Networks also differ according to the switching/routing technique used to interconnect the various network nodes and devices (e.g. circuit switching vs. packet switching) , the type of physical media employed for transmission (e.g. wired vs. wireless) , and the set of communication protocols used (e.g., Internet protocol suite, SONET (Synchronous Optical Networking) , Ethernet, etc. ) . Various processes and methods can be used for transmissions in a communication network. For example, signals can be sent and received in accordance with orthogonal frequency division multiplexing (OFDM) /orthogonal frequency division multiple access (OFDMA) techniques, or code division multiple access (CDMA) techniques.

Figure 3 illustrates a block diagram of a communication node 302, in accordance with some embodiments. The node 302 is an example of a device that can be configured to implement the various methods described herein, or a component of the various methods described herein. The node 302 may include a housing 300 containing a system clock 301, a processor 303, a memory 305, a transceiver 306 comprising a transmitter 307 and receiver 309, a signal detector 311, and a power module 313.

The system clock 301 provides the timing signals to the processor 303 for controlling the timing of operations of the node 302. The processor 303 controls the general operation of the node 302 and can include one or more processing circuits or modules such as a central processing unit (CPU) and/or any combination of general-purpose microprocessors, microcontrollers, digital signal processors (DSPs) , field programmable gate array (FPGAs) , programmable logic devices (PLDs) , controllers, state machines, gated logic, discrete hardware components, dedicated hardware finite state machines, or any other suitable circuits, devices and/or structures that can perform calculations or other manipulations of data.

The memory 305 or data store, which can include both read-only memory (ROM) and random access memory (RAM) , can provide instructions and data to the processor 303. A portion of the memory 305 can also include non-volatile random access memory (NVRAM) . The processor 303 typically performs logical and arithmetic operations based on program instructions stored within the memory 305. The instructions (a.k.a., software) stored in the memory 305 can be executed by the processor 303 to perform the methods described herein. The processor 303 and memory 305 together form a processing system that stores and executes software. As used herein, “software” means any type of instructions, whether referred to as software, firmware, middleware, microcode, etc. which can configure a machine or device to perform one or more desired functions or processes. Instructions can include code (e.g., in source code format, binary code format, executable code format, or any other suitable format of code) . The instructions, when executed by the one or more processors, cause the processing system to perform the various functions described herein.

The transceiver 306, which includes the transmitter 307 and receiver 309, allows the node 302 to transmit and receive data to and from a remote node. In certain embodiments, an antenna 310 is attached to the housing 300 and electrically coupled to the transceiver 306. In various embodiments, the node 302 include (not shown) multiple transmitters, multiple receivers, multiple transceivers, and/or multiple antennas. In particular embodiments, an antenna for wireless communication is not utilized when the node may communicate via a wired network.

The transmitter 307 can be configured to transmit packets or frames having different packet or frame types or functions, such packets or frames being generated by the processor 303. Similarly, the receiver 309 is configured to receive packets or frames having different packet or frame types or functions, and the processor 303 is configured to process packets of a plurality of different packet or frame types. For example, the processor 303 can be configured to determine the type of packet or frame and to process the packet or frame and/or fields of the packet or frame accordingly.

In accordance with some embodiments, the node 302 can also include the signal detector 311, which can be used to detect and quantify the level of signals received by the transceiver 306. The signal detector 311 can detect and quantify such parameters as total energy, energy per subcarrier per symbol, power spectral density and other signals. The power module 313 can include a power source such as one or more batteries, and a power regulator, to provide regulated power to each of the above-described

modules

303, 305, 306 (307 and 309) and 311. In some embodiments, if node 302 is coupled to a dedicated external power source (e.g., a wall electrical outlet) , the power module 313 can include a transformer and a power regulator.

The various modules discussed above are coupled together by a bus system 315. The bus system 315 can include a data bus and, for example, a power bus, a control signal bus, and/or a status signal bus in addition to the data bus. It is understood that the modules of the node 302 can be operatively coupled to one another using any suitable techniques and mediums.

Although a number of separate modules or components are illustrated in Figure 3, persons of ordinary skill in the art will understand that one or more of the modules can be combined or commonly implemented. For example, the processor 303 can implement not only the functionality described above with respect to the processor 303, but also implement the functionality described above with respect to the signal detector 311. Conversely, each of the modules illustrated in Figure 3 can be implemented using a plurality of separate components or elements.

Systems and methods in accordance with various embodiments disclose techniques for bearer context transfer between functionalities with non-homogeneous bearer capabilities. A bearer context may include information that characterizes a bearer, such as a bearer identifier (ID) . These bearer contexts may be transferred among any functionality hosted at a node (e.g., an EPS node) , such as for a MME, serving gateway (SGW) , packet data network gateway (PGW) and the like. Each functionality may have different bearer capabilities (e.g., support a different threshold quantity of bearer contexts, with associated respective bearer identifiers, or a different number of bearers) .

In various embodiments, reference to a legacy system refers to a system that cannot support bearer contexts extending beyond a threshold quantity (e.g. 8 or 11) . For the nodes in such a system, the new or second information elements may not be understood and then may be discard upon reception of such information elements. Only legacy or first information element can be understood and handled. To be clear, first information element can also be referred to as legacy information elements and second information element can also be referred to as new information elements, in certain embodiments.

Also, bearer contexts may be transferred utilizing information elements. Information elements are conventional and will not be discussed in detail herein. These information elements may include legacy information elements (e.g., first information elements, or a first type of information elements) and new information elements (e.g., second information elements, or a second type of information elements. In certain embodiments, the specific choice of whether to utilize legacy information elements and/or new information elements may depend on whether an enumerated value of a bearer identifier for an associated bearer context extends beyond a threshold quantity of bearers that are traditionally acceptable in legacy systems. Extending beyond (e.g., being beyond) may refer to crossing a threshold value by becoming either greater or less than the threshold value. For example, when the threshold quantity of bearers is 8, either a bearer identifier value of 9 when each bearer identifier is sequentially enumerated up from 1 or a bearer identifier value of 8 when each bearer identifier is sequentially enumerated up from 9 is a bearer identifier value that extends beyond the threshold quantity of bearers by being greater than a threshold quantity value (e.g., 8 or 7, respectively) . As another example, when the threshold quantity of bearers is 8, a bearer identifier value of 2 when each bearer identifier is sequentially enumerated down from 11 is a bearer identifier value that extends beyond the threshold quantity of bearers by being less than the threshold quantity value of 3. In certain embodiments, an extension beyond (e.g., extending beyond) may refer to moving beyond either a upper or a lower threshold quantity value. For example, a threshold quantity of bearers of 8 may be numerated from the range of

bearer identifier values

5, 6, 7, 8, 9, 10, 11, 12. Accordingly, the threshold quantity values of such a range of bearer identifier values may be 12 or 5. Depending on whether an addition of bearer identifier values (e.g., for an addition of bearer contexts) are enumerated up or down, a bearer identifier value of either 13 or 4 would extend beyond the threshold quantity values of such a range of bearer identifiers.

For ease of discussion below, a particular value of a bearer identifier may be a sequentially enumerated value that counts off the number of active bearers, up or down. For example, the value of a bearer identifier may be sequentially enumerated up from the value 1 or the value 0. Accordingly, the value of a bearer identifier (e.g., the values 8, 11, or 15 when counted from the value 1; or the values 7, 10, or 14 when counted from the value 0) also refers to a quantity of active bearer identifiers or contexts (e.g., a quantity of 8, 11, or 15, respectively) . Stated another way, it should be understood that any numbering system may be utilized for bearer identifiers so long as each value of such a numbering system for bearer identifiers may also be utilized to identify a particular quantity value. For example, a quantity of 8 may be expressed by the value 7 for a numbering system sequentially counted or enumerated up from the value 0. As another example, the quantity of 8 may be expressed by the value 8 for a numbering system sequentially counted or enumerated up from the value 1.

Also, the specific choice of whether to utilize legacy information elements and/or new information elements may depend on whether a particular bearer context to be transferred or sent is a default bearer or a dedicated bearer. A default bearer may be an EPS bearer which is first established for a new PDN connection and remains established throughout the lifetime of the PDN connection. A dedicated bearer may be any additional EPS bearer that is established for the same PDN connection.

For example, and as will be discussed in further detail below, bearer contexts that include a bearer identifier with a numerated value (e.g. the value 9 when counted from the value 1 or the value 8 when counted from the value 0) that extend beyond a threshold quantity of bearer identifiers or contexts that are acceptable (e.g., a quantity of 8) may be sent with new information elements. Also, bearer identifiers with a numerated value not extending beyond a threshold quantity of acceptable bearer identifiers or contexts may be sent with legacy information elements. Furthermore, dedicated bearers may be transmitted in new information elements along with default bearers when the default bearers have a value extending beyond the threshold quantity.

In various embodiments, bearer contexts may include bearer identifiers with specific numerated values. These specific numerated values may be, for example, within a range of values (e.g. the value 5 to 11) . Although specific numerated values may be referenced in particular embodiments, any numerated value may be utilized in a bearer identifier as desired for different applications in numerous embodiments. For example, bearer identifiers may be numerated to increment as odd numbers (e.g., 3, 5, 7, and so on) or even numbers (e.g., 2, 4, 6, and so on) in particular embodiments. As discussed above, a quantity may be inferred from the range of numerated values as the numerated values may increase or decrease incrementally in a known manner (e.g., sequentially) from a starting value to reflect changes in quantity.

In particular embodiments, in order to support beyond a threshold quantity of bearer identifiers or contexts, reserved values for bearer identifiers may be utilized. These reserved values may be values for identifiers that are reserved for specific uses and not assigned or allocated for uses that do not fall within the specific uses for the reserved values. For example, values of 0, 1, 2, 3, and 4 may be reserved values for bearer identifiers (e.g., bearer identifiers that are part of bearer contexts that satisfy particular criteria) . In certain embodiments, these reserved bearer identifier values may be utilized for bearer identifiers when a desired quantity of bearer identifiers extends beyond a particular threshold quantity. For example, if a node receives a request to support beyond a threshold quantity of bearer contexts (e.g., 8 bearer contexts) , the node may assign reserved bearer identifier values to the additional bearer contexts that extend beyond the threshold quantity of bearer contexts. As a more specific example, an exemplary node may have bearer identifier values incremented from the value 5 to a maximum supported value of 12 (e.g., indicating a threshold quantity of 8) , with the values 0 to 4 as reserved values for bearer identifiers. Accordingly, the exemplary node may utilize bearer identifier values 5 to 12 for the threshold quantity of 8 supported bearer contexts, with a threshold quantity value of 12. Also, the system that the exemplary node is part of may begin numerating bearer identifiers incrementally from a bearer identifier value of 5. However, in certain embodiments, the exemplary node may also assign the reserved bearer identifier values of 0 to 4 for up to 5 additional bearer contexts beyond the originally supported 8 bearer contexts (e.g., within the threshold quantity of 8) in order to support a new maximum of 13 supported bearer contexts or 13 supported bearer identifier values.

Figure 4 is a flow chart of a serving gateway (SGW) relocation process 400, in accordance with some embodiments. In the SGW relocation processes 400, the MME may not need to change (e.g., not need to change to effectuate the SGW relocation processes 400) . The SGW relocation process 400 illustrates operations between a UE 402, a source eNB 404, a target eNB 406, a MME 408, a source SGW 410, a target SGW 412, and a PGW 414. As part of the SGW relocation process 400, and other processes discussed further below, source functionalities (e.g., a source SGW) may be relocated, or transferred to a target functionality (e.g., a target SGW) . This may be performed, for example, by relocating or transferring bearer IDs from the source functionality to the target functionality. It is noted that the SGW relocation process 400 is merely an example, and is not intended to limit the present disclosure. Accordingly, it is understood that additional operations may be provided before, during, and after the SGW relocation processes 400 of Figure 4, certain operations may be omitted, certain operations may be performed concurrently with other operations, and that some other operations may only be briefly described herein.

At operation 1, the UE may establish several EPS bearers, with associated bearer identifiers. The EPS bearer identifiers may be allocated beyond a threshold quantity, such as 8 (e.g., there may be more than 8 bearer identifiers that are associated with respective bearer contexts) . The source side may include the UE 402, a RAN, the MME 408, the source SGW 410, and the PGW 414, that each supports a set number of bearers (e.g., 15) beyond the threshold quantity (e.g., 8) of bearers supported by legacy systems. By the UE 402 establishing several EPS bearers, the UE 402 may inform the MME 408 of its bearer capability during attach. The MME 408 then may allocate the EPS bearer identifiers beyond the threshold quantity (e.g., 8) to the UE.

At operation 2, the SGW relocation may occur in such cases as a handover with MME 408 unchanged or when the MME 408 triggers SGW relocation due to events other than mobility events (e.g., a PDN session establishment) . In the case of a handover (e.g., a HO procedure) with MME unchanged, operation 2 may be performed after the MME 408 receives a path switch from the target RAN. In case of SGW relocation due to a non-mobility event, operation 2 may be performed after the MME 408 receives a PDN session establishment request from the UE 402, or some internal configuration or operations and management (OAM) configuration update in the MME 408.

At operation 3, the MME 408 may send a create session request message per PDN connection to the target serving GW 412. For example, the create session request may include: bearer context (s) with packet data network gateway addresses (PDN GW addresses) and tunneling endpoint identifiers (TEIDs) (e.g., for the general packet radio service (GPRS) ) , tunneling protocol (GTP-based S5/S8) or generic routing encapsulation (GRE) keys (for proxy mobile IPv6 (PMIP) based S5/S8) at the PDN GW (s) for uplink traffic, eNodeB address (es) and TEIDs for downlink user plane for the existing EPS bearers, the protocol type (e.g., GTP or PMIP protocols) over S5/S8, and serving network information.

The MME may not decide or know whether the SGW can support the set quantity of bearer identifiers or associated respective bearer contexts (e.g., 15) beyond a threshold quantity of bearer identifiers or associated respective bearer contexts (e.g., 8) . Also, the UE may be configured to utilize EPS bearers with EPS bearer identifiers or contexts beyond a threshold quantity of bearer identifiers or contexts (e.g., 8 or 11) . Accordingly, the MME may transfer the context (e.g., transfer bearer identifiers associated with the transferred bearer contexts) in accordance with the following possible subsets of operation 3:

Operation 3a: If the EPS bearers within the PDU session have no EPS bearer identifier (s) or context (s) beyond the threshold quantity of bearer identifiers or contexts, the MME sends the bearer contexts in the legacy information elements (IEs) .

Operation 3b: If the EPS bearer identifier value of the default bearer is not beyond the threshold quantity of bearer identifiers or contexts (e.g., 8 or 11) while the EPS bearer identifier values of one or more dedicated bearers is beyond the threshold quantity of bearer identifiers (e.g., 8 or 11) , the MME may send the bearer contexts (e.g., bearer identifiers and information associated with a bearer identifier) whose EPS bearer identifier value is not beyond the threshold quantity of bearer identifiers or contexts (e.g., 8 or 11) in the legacy information elements. The MME may also send a new information element to transfer the bearer contexts whose EPS bearer identifier value is beyond the threshold quantity of bearer identifiers or contexts (e.g., 8 or 11) . For example, in certain embodiments, the new information elements may only include the bearer contexts which are not sent in legacy information elements. In further embodiments, the new information elements may include all the bearer contexts for such PDN sessions. In additional embodiments, the new information elements may include all the bearer contexts no matter whether they are sent in legacy information elements or not.

Operation 3c: If the EPS bearer identifier value of the default bearer is beyond the threshold quantity of bearer identifiers or contexts (e.g., 8 or 11) and the EPS bearer identifier values of other dedicated bearers related to the same PDN session are beyond the threshold quantity of bearer identifiers or contexts (e.g., 8 or 11) , the bearer contexts of such a PDN session may be included in a new information element rather than the legacy information element. In additional embodiments the new information elements may include all the bearer contexts no matter whether they are sent in legacy information elements or not.

It may be desirable to introduce a new information element in the manner noted above. For example, if the target SGW does not support beyond the threshold quantity of bearer identifiers or contexts (e.g., if the target SGW does not support 15 bearers) , it can handle the legacy information elements normally and will not cause any rejection of the bearer identifiers or contexts in the legacy information elements. The new information elements which the target SGW cannot understand can be discarded. For operation 3c, the EPS bearer identifiers or contexts for such a default bearer may be beyond the threshold quantity of bearer identifiers or contexts (e.g., 8 or 11) , which is not supported by the target SGW. Thus, the default bearer will fail to establish. Accordingly, it may be unnecessary to include the bearer contexts in legacy information elements.

If the MME selects a SGW that supports a quantity of bearer identifiers or contexts (e.g., 15 bearers) beyond the threshold quantity of bearer identifiers or contexts, bearer contexts can also transferred via the method above (e.g., in accordance with operation 3) . They also can be transferred in a legacy way with an enhanced EPS bearer identifier (e.g., for 15 bearers) beyond the threshold quantity of bearer identifiers or contexts (e.g., 8 or 11) .

At operation 4, the new serving GW (e.g., target SGW 412) assigns addresses and TEIDs (one per bearer) for downlink traffic from the PGW 414.

The target SGW 412 allocates downlink (DL) TEIDs on S5/S8. It may also send a modify bearer request (e.g., SGW addresses for user plane and TEID (s) ) message per PDN connection to the PDN GW (s) (e.g., PGW 414) . The PDN GW (e.g., PGW 414) may update its context field and return a modify bearer response (e.g., charging identifier (ID) , mobile station international subscriber directory number (MSISDN) , etc. ) message to the serving GW (e.g., target SGW 412) . The MSISDN is included if the PDN GW has it stored in its UE context.

At operation 5, the target SGW 412 sends a create session response (e.g., serving GW addresses and uplink TEID (s) for user plane) message back to the MME 408. The target SGW may also include a list of bearer identifiers indicating whether the bearer contexts are set up successfully or not (e.g., failed) . If the target SGW 412 supports the set quantity of bearer identifiers or contexts (e.g., 15) beyond threshold quantity of bearer identifiers or contexts (e.g., 8 or 11) , the bearer contexts whose EPS bearer IDs are beyond the threshold quantity of bearer identifiers or contexts (e.g., 8 or 11) , will be included, via a legacy information element or a new information element.

At operation 6, the MME 408 checks whether all the bearers are established (e.g., if all bearer IDs are accepted or usable after being communicated) to the target side. For the bearer contexts that fail to establish (e.g., bearer identifiers or contexts not supported by the targets) , the MME may initiate a delete bearer command or delete session request to release the dedicated bearer or the whole PDN session to the PGW via the source SGW 410. With reference to operation 2, in the case of a handover (e.g., a HO procedure) the MME may include the failed bearer identifier or context list in a path switch acknowledgement (ack) message to the target eNB. In case of SGW relocation due to a non-mobility event, the MME may perform a radio access bearer (RAB) release to the eNB.

Figure 5 is a flow chart of a mobility management entity (MME) relocation process 500, in accordance with some embodiments. This MME relocation process 500 may be performed in a connected mode, where the the UE has activated bearers and has data transferred. The MME relocation process 500 illustrates operations between a UE 502, a source RAN 504, a source MME/SGSN 506, a target RAN 508, a target MME/SGSN 510, a source SGW 512, a target SGW 514, and a PGW 516. It is noted that the MME relocation process 500 is merely an example, and is not intended to limit the present disclosure. Accordingly, it is understood that additional operations may be provided before, during, and after the MME relocation process 500 of Figure 5, certain operations may be omitted, certain operations may be performed concurrently with other operations, and that some other operations may only be briefly described herein.

Examples of MME relocation processes 500 in a connected mode may include when the UE moves within an EPS. In such a case, the source RAN may be an eNB. The source CN node may be the MME. The target RAN may be another eNB. The target node may be another MME. Although a specific example of a mobility management entity relocation process 500 in a connected mode is described below, other examples of mobility management entity relocation processes in a connected mode may be implemented as desired for different applications in various embodiments. For example, another example of a mobility management entity relocation process in a connected mode may include the UE moving within a GSM EDGE radio access network (GERAN) /UTRAN. In such a case, the source RAN may be n radio network controller (RNC) /basic service set (BSS) . The source CN node may be the SGSN. The target RAN may be another RNC/BSS. Lastly, the target node may be another SGSN. Also, another example of a mobility management entity relocation process in a connected mode may include when the UE moves from GERAN/UTRAN to an EPS. The source RAN may be an RNC/BSS. The source CN node may be an SGSN. The target RAN may be an eNB. Lastly, the target node may be an MME.

At operation 1, the UE may establish several EPS bearers, with associated bearer identifiers or contexts. The EPS bearer identifiers or contexts may be allocated beyond a threshold quantity, such as 8 (e.g., there may be more than 8 bearer identifiers or contexts) . The source side may include the UE 502, RAN 504, MME 506, SGW 512, PGW 516, and may each supports 15 bearers. Stated another way, they may each support a set quantity of bearer identifiers or contexts (e.g., 15) beyond a threshold quantity of bearer identifiers or contexts (e.g., 8) . By having the UE 502 establish several EPS bearers, the UE 502 may inform the MME 506 of its bearer capability during attach. The MME 506 then may allocate the EPS bearer ID beyond the threshold quantity (e.g., 8) to the UE.

At operation 2, the source RAN 504 decides to initiate an S1-based handover to the target eNodeB. The source RAN 504 may send a handover required signal (e.g., direct forwarding path availability, a source to target transparent container, target RAN identifier, closed subscriber group identifier (CSG ID) , CSG access mode, target tracking area identifier (TAI) , and the like) to the source MME/SGSN 506.

If the source eNodeB can’t know (e.g., either is not allowed to know or does not know) the bearer capability of the target side, the MME may transfer the context (e.g., bearer identifiers) in accordance with one of the following two options. As a first option, if the enumerated value of the E-UTRAN radio access bearer (E-RAB) identifier (e.g., the bearer identifier) , is not beyond the threshold quantity of bearer identifiers or contexts (e.g., 8) , the bearer contexts are transferred in legacy information elements. As a second option, for the E-RAB with the E-RAB identifier (e.g., bearer identifier) beyond the threshold quantity of bearer identifiers or contexts (e.g., 8) , the bearer contexts are transferred in new information elements.

At operation 3, the source MME 506 may determine whether the target side supports a number of bearer identifiers at a particular set value (e.g., for 15 bearers) beyond a threshold quantity of bearer identifiers (or bearer contexts) or not. This determination may be based on a dedicated core network identifier (DCN ID) or other configuration.

At operation 4, the source MME 506 may select the target MME 510 based on the DCN ID or other information and try to select a target MME 510 that supports a number of bearer identifiers at a particular set value (e.g., 15 bearers) beyond a threshold quantity of bearer identifiers or contexts (e, g., 8 bearers) , if the UE has indicated supporting such a feature. The MME 506 may send a forward relocation request (e.g., a MME UE context, source to target transparent container, RAN cause (e.g., why HO is triggered) , target eNodeB identity/identifier, closed subscriber group (CSG) identifier (ID) , CSG membership indication, target tracking area identity/identifier (TAI) , MS (e.g., UE) information change reporting action (if available) , CSG information reporting action (if available) , UE time zone, direct forwarding flag, serving network, local home network identifier (ID) ) message to the target MME 510. The UE context may include associated bearer contexts, along with other information such as a security context, charging information, and the like.

The MME 506 may not decide or know whether the MME 510 can support the set quantity of bearer identifiers or contexts (e.g., 15) beyond a threshold quantity of bearer identifiers or contexts (e.g., 8) . Also, the UE may be configured to utilize EPS bearers with EPS bearer identifiers or contexts beyond the threshold quantity of bearer identifiers or contexts (e.g., 8 or 11) . Accordingly, the MME should transfer the context (e.g., transfer bearer identifiers) in accordance with the following possible subsets of operation 4:

Operation 4a: If the EPS bearers within the PDU session have no EPS bearer identifier (s) or contexts beyond the threshold quantity of bearer identifiers or contexts, the MME sends the bearer contexts in the legacy information elements (IEs) .

Operation 4b: If the EPS bearer identifier value of the default bearer is not beyond the threshold quantity value of bearer identifiers or contexts (e.g., 8 or 11) while the EPS bearer identifier values of one or more dedicated bearers is beyond the threshold quantity of bearer identifiers or contexts (e.g., 8 or 11) , the MME may send the bearer contexts (e.g., bearer identifiers and information associated with a bearer identifier) whose EPS bearer identifier value is not beyond the threshold quantity of bearer identifiers or contexts (e.g., 8 or 11) in the legacy information elements. The MME may also send a new information element to transfer the bearer contexts whose EPS bearer identifier value is beyond the threshold quantity of bearer identifiers or contexts (e.g., 8 or 11) . For example, in certain embodiments, the new information elements may only include the bearer contexts which are not sent in legacy information elements. In further embodiments, the new information elements may include all the bearer contexts for such PDN sessions. In further embodiments, the new information elements may include all the bearer contexts no matter whether they are sent in legacy information elements or not.

Operation 4c: If the EPS bearer identifier value of the default bearer is beyond the threshold quantity of bearer identifiers or contexts (e.g., 8 or 11) and the EPS bearer identifier values of other dedicated bearers related to the same PDN session are beyond the threshold quantity of bearer identifiers or contexts (e.g., 8 or 11) , the bearer contexts of such a PDN session may be included in a new information element rather than the legacy information element. In further embodiments, the new information elements may include all the bearer contexts no matter whether they are sent in legacy information elements or not.

It may be desirable to introduce a new information element in the manner noted above. For example, if the target MME 510 does not support beyond the threshold quantity of bearer identifiers or contexts (e.g., if the target MME 510 does not support 15 bearers) , it can handle the legacy information elements normally and will not cause any rejection of the bearer identifiers or contexts in the legacy information elements. The new information elements which the target MME 510 cannot understand can be discarded. For operation 4c, the EPS bearer identifier values of such a default bearer may be beyond the threshold quantity of bearer identifiers or contexts (e.g., 8 or 11) , which is not supported by the target MME 510. Thus, the default bearer will fail to establish. Accordingly, it may be unnecessary to include the bearer contexts in legacy information elements.

If the MME 506 selects a target MME 510 that supports a quantity of bearer identifiers (e.g., 15 bearers) beyond the threshold quantity of bearer identifiers or contexts, bearer contexts can also transferred via the method above (e.g., in accordance with operation 3) . They also can be transferred in a legacy way with an enhanced EPS bearer identifier value (e.g., for 15 bearers) beyond the threshold quantity of bearer identifiers or contexts (e.g., 8 or 11) .

At operation 5, if the MME has been relocated, the target MME 510 verifies whether the source SGW 512 can continue to serve the UE. If not, it selects a new SGW 514. The selection of a new SGW 514 may be similar with operations 3-4 in Figure 4 and will not be repeated here for brevity.

At operation 6, the target MME 510 may send a handover request (e.g., EPS bearers to setup, aggregate maximum bit rate (AMBR) , information on a cause for the handover request, a source to target transparent container, CSG ID, CSG membership indication, handover restriction list) message to the target RAN 508 (and in some embodiments, a target eNodeB) .

If the target MME 510 can’t support the set value of bearer identifiers (e.g., 15 bearers) beyond the threshold quantity of bearer identifiers or contexts, the EPS bearers in setup will not include the bearers beyond the threshold quantity of bearer identifiers or contexts (e.g., 8) .

At operation 7, the target RAN 508 (and in some embodiments, a target eNodeB) sends a handover request acknowledge (e.g., EPS bearer setup list, EPS bearers failed to setup list, target to source transparent container) message to the target MME 510. If the target RAN 508 (and in some embodiments, a target eNodeB) supports the set value of bearer identifiers beyond the threshold quantity of bearer identifiers or contexts (e.g., 15 bearers) , the bearer contexts whose E-RAB bearer identifier values are beyond the threshold quantity of bearer identifiers or contexts (e.g., 8) , will be included, via a legacy information element or a new information element.

At operation 8, the target MME may send a forward relocation response (e.g., information identifying a case for the response, a target to source transparent container, a serving gateway change indication, EPS bearer setup list, addresses and TEIDs) message to the source MME 506. The target MME may also include the EPS bearer setup list indicating whether the bearer contexts are setup successfully. If the target MME 510 supports the set value of bearer identifiers beyond the threshold quantity of bearer identifiers or contexts (e.g., 15 bearers) , the bearer contexts whose EPS bearer identifier values are beyond the threshold quantity of bearer identifiers or contexts (e.g, 8 or 11) , will be included, via a legacy information element or a new information element.

In certain embodiments, the source MME 506 checks whether all the bearers are established at the target side. For the bearer contexts that fail to establish (e.g., that are not supported by the target system) , the MME 506 may initiate a delete bearer command or delete session request to release the dedicated bearer or the whole PDN session.

At operation 9, the MME 506 may send the handover command to the source RAN 504 (and in some embodiments, a source eNB) . Then the nodes involved in a handover procedure may perform the left steps, or the remaining conventional steps for performance after a handover command is sent (e.g., complete the handover procedure) .

Figure 6 is a flow chart of a bearer context retrieval process 600, in accordance with some embodiments. The bearer context retrieval process 600 illustrates operations between a UE 602, a NG RAN 604, an AMF 606, a SMF/PGW-C 608, and a UPF/GW-U 610. This bearer context retrieval process 600 may be a retrieval from the SMF/PGW-C 608. It is noted that the bearer context retrieval process 600 is merely an example, and is not intended to limit the present disclosure. Accordingly, it is understood that additional operations may be provided before, during, and after the bearer context retrieval process 600 of Figure 6, certain operations may be omitted, certain operations may be performed concurrently with other operations, and that some other operations may only be briefly described herein.

At operation 1, the UE 602 may establish several PDU sessions in 5GS.

At operation 2, the AMF 606 may detects some triggers of mobility events to an EPC. For example, the AMF 606 may receive HO requests from the NG RAN, where the target cell is a eNB. As another example, the AMF 606 may receive a context request from an MME when a tracking area update (TAU) /attach is triggered in the EPC.

At operation 3, the AMF 606 may send a PDU session context request (e.g., Nsmf_PDUSession_ContextRequest) that requests the PGW-C+SMF (e.g., SMF/PGW-C 608) for each PDU session associated with 3GPP access to retrieve a session management (SM) context that also includes the mapped EPS bearer contexts. For PDU sessions with PDU session type ethernet or PDU session type unstructured, the SMF provides SM context for a non-internet protocol (IP) PDN type.

In case of a HO procedure, after the AMF 606 receives a handover required from a NG RAN, the AMF 606 sends the PDU session context request (e.g., Nsmf_PDUSession_ContextRequest) . In case of a tracking area update (TAU) procedure from the EPS, after the AMF 606 receives a context request from the target MME, the AMF 606 sends the PDU session context request (e.g., Nsmf_PDUSession_ContextRequest) .

The AMF 606 may provide the target MME capability to the SMF 608 in the request to allow the SMF 608 to determine whether to include a EPS bearer context whose EPS bearer identifier (ID) is beyond a threshold quantity (e.g., 8 or 11) . This step may be performed with all PGW-C+SMFs (e.g., SMF/PGW-C 608) allocated to the UE for each PDU Session of the UE.

The bearer capability may be indicated by the target MME, if such procedure is part of a tracking area update (TAU) from 5GC to EPC. The bearer capability may be configured by an operator or based on the data core network identifier (DCN ID) of the target MME. The bearer capability may be also indicated by the source new radio access network (NR RAN) , in the case of a HO procedure. If the bearer capability is included in the request and the target MME does not support an EPS bearer quantity beyond a threshold quantity (e.g., 8 or 11) , the SMF/PGW-C 608 may decide not to transfer an EPS bearer context whose EPS bearer identifier (ID) is beyond a threshold quantity (e.g., 8 or 11) . Accordingly, the SMF/PGW-C 608 may transfer a EPS bearer context whose EPS bearer identifier (ID) is beyond a threshold quantity (e.g., 8 or 11) as described in operation 4, below. If the SMF/PGW-C 608 decides not to transfer an EPS bearer context whose EPS bearer identifier (ID) is beyond a threshold quantity (e.g., 8 or 11) , the SMF/PGW-C 608 may initiate a PDU session update or PDU session release to release a particular bearer context, the dedicated bearer or the whole PDU session.

At operation 4, the SMF 608 may return mapped EPS bearer contexts as part of session management (SM) contexts. For example, the SMF 608 may send a PDU session context response (e.g., Nsmf_PDUSession_ContextResponse) . If the SMF 608 cannot or does not know the bearer capability of the target side or the SMF know the target side does not support a set value or quantity of bearer identifiers or contexts (e.g., for 15 bearers) beyond a threshold quantity of bearer identifiers or contexts, the SMF should transfer the context (e.g., transfer bearer identifiers) in accordance with the following possible subsets of operation 4:

Operation 4a: If the EPS bearers within the PDU session have no EPS bearer identifier value (s) beyond the threshold quantity of bearer identifiers or contexts, the SMF 608 sends the bearer contexts in the legacy information elements (IEs) .

Operation 4b: If the EPS bearer identifier value of the default bearer is not beyond the threshold quantity of bearer identifiers or contexts (e.g., 8 or 11) while the EPS bearer identifier values of one or more dedicated bearers is beyond the threshold quantity of bearer identifiers or contexts (e.g., 8 or 11) , the SMF 608 may send the bearer contexts (e.g., bearer identifiers and information associated with a bearer identifier) whose EPS bearer identifier value is not beyond the threshold quantity of bearer identifiers or contexts (e.g., 8 or 11) in the legacy information elements. The SMF 608 may also send a new information element to transfer the bearer contexts whose EPS bearer identifier value is beyond the threshold quantity of bearer identifiers or contexts (e.g., 8 or 11) . For example, in certain embodiments, the new information elements may only include the bearer contexts which are not sent in legacy information elements. In further embodiments, the new information elements may include all the bearer contexts for such PDN sessions. In further embodiments, the new information elements may include all the bearer contexts no matter whether they are sent in legacy information elements or not.

It may be desirable to introduce a new information element in the manner noted above. The AMF will transparent (e.g., transfer) the SM context to the target MME. For example, if the target MME does not support beyond the threshold quantity of bearer identifiers or contexts (e.g., if the target MME does not support 15 bearers) , it can handle the legacy information elements normally and will not cause any rejection of the bearer identifiers or contexts in the legacy information elements. The new information elements which the target MME cannot understand can be discarded. For operation 4c, the EPS bearer identifier values of such a default bearer may be beyond the threshold quantity of bearer identifiers or contexts (e.g., 8 or 11) , which is not supported by the target MME. Thus, the default bearer will fail to establish. Accordingly, it may be unnecessary to include the bearer contexts in legacy information elements.

At operation 5, the SMF 608 may initialize a N4 session release/modification to the UPF as the current specification.

At operation 6, in the case of a HO procedure, the AMF 606 may send the forward relocation request to the MME, which includes the bearer context received from the SMF 608. Then the nodes involved in a handover procedure may perform the remaining steps executed after the forward relocation request is sent. This operation may be is similar to operation 4 of Figure 4, discussed above. For example, the target MME may send a forward relocation response (e.g., information identifying a case for the response, a target to source transparent container, a serving gateway change indication, EPS bearer setup list, addresses and TEIDs) message to the AMF 606. The target MME may also include the EPS bearer setup list indicating whether the bearer contexts are setup successfully. In certain embodiments, the AMF 606 checks whether all the bearers are established at the target side. For the bearer contexts that fail to establish (e.g., that are not supported by the target system) , the AMF 606 may initiate a PDU session update or PDU session release to release the dedicated bearer or the whole PDN session to the SMF 608.

In case of a TAU procedure, the AMF 606 may send a context response to the MME, which includes the bearer context received from the SMF 608. Then the nodes involved in the TAU procedure may perform the remaining steps executed after the context response is sent. The procedure is similar with step 3 and forward in fig. 7. The target MME may send a context acknowledgement (ack) the AMF 606. If the a new information element is included in operation 4 and the target MME can handle it, the target MME may send a confirmation of bearer context setup indication included in the context ack message. The confirmation of bearer context setup indication may indicate successful bearer identifier (s) for bearer identifier (s) or context (s) that are associated with a successful set up (e.g., that are supported at the target MME 710) .

The AMF 606 may check whether such a confirmation of bearer context setup indication is included. If the bearer contexts whose bearer identifier values are beyond the threshold value are all transferred and such indication is not included, the AMF 606 may deem such bearers as failed in the target side due to the target MME not supporting such a feature. In certain embodiments, the AMF 606 may initiate a delete bearer command or delete session request to release the dedicated bearer or the whole PDN session to the SMF 608.

Figure 7 is a flow chart of a tracking area update (TAU) or routing area update (RAU) process 700, in accordance with some embodiments. The TAU or RAU process 700 illustrates operations between a UE 702, a source RAN 704, a target RAN 706, a source MME 708, a target MME 710, a SGW 712, and a PGW 714. This TAU or RAU process 700 may be an example of a TAU where the context is transferred from a source MME to a target MME. Figure 7 may also reflect scenarios such as when a UE initiates a TAU and a target MME requests bearer contexts from a SGSN; and when a UE initiates a RAU and a target SGSN requests bearer contexts from a MME or SGSN. It is noted that the TAU or RAU process 700 is merely an example, and is not intended to limit the present disclosure. Accordingly, it is understood that additional operations may be provided before, during, and after the TAU or RAU process 700 of Figure 7, certain operations may be omitted, certain operations may be performed concurrently with other operations, and that some other operations may only be briefly described herein.

At operation 1, the UE 702 may establish several EPS bearers, with associated bearer identifiers. The EPS bearer identifiers may be allocated beyond a threshold quantity (e.g., a threshold quantity of 8 bearer identifiers) . The source side may include the UE 702, source RAN 704, source MME 708, SGW 712, and PGW 714. The source side may support a set quantity of bearer identifiers or contexts (e.g., 15) beyond a threshold quantity of bearer identifiers or contexts (e.g., 8) . By having the UE 702 establish several EPS bearers, the UE 702 may inform the MME 708 of its bearer capability during attach. The MME 708 may then may allocate EPS bearer identifiers beyond the threshold quantity (e.g., 8) of bearer identifiers or contexts to the UE 702.

At operation 2, the UE 702 may move to a new tracking area (TA) and initiate a TAU procedure. The target RAN 706 may perform a MME selection and select a target MME 710. As part of the TAU procedure, a target eNB may transfer a TAU request to the target MME 710.

At operation 3, the new or target MME 710 may determine a source MME or SGSN that uses a particular global unique temporary identifier (GUTI) received from the UE 702. The target MME 710 may derive a MME/SGSN address associated with the source MME or SGSN. The target MME 710 may send a context request message to the source MME or SGSN to retrieve user information. The context request message may include, for example, the old GUTI, a complete TAU request message, packet-temporary mobile subscriber identity (P-TMSI) signature, MME address, UE validated, and/or a cellular Internet of things (CIoT) EPS optimization support indication.

At operation 4, the source MME 708 may respond with a context response message. The context response message may include an international mobile subscriber identity (IMSI) , mobile equipment (ME) identity (IMEISV) , mobility management (MM) context, EPS bearer context (s) , serving GW signaling address and TEID (s) , idle mode signaling reported (ISR) supported, MS info change reporting action (if available) , closed subscriber group (CSG) information reporting action (if available) , UE time zone, UE core network capability, UE specific discontinuous reception (DRX) parameters.

The source MME 708 may not decide or know whether the target MME 710 can support the set quantity of bearer identifiers (e.g., 15) beyond a threshold quantity of bearer identifiers (e.g., 8) . Also, the UE 702 may be configured to utilize EPS bearers with EPS bearer identifiers beyond the threshold quantity of bearer identifiers (e.g., 8) . Accordingly, the source MME 708 should transfer the bearer contexts (e.g., transfer bearer identifiers) in accordance with the following possible subsets of operation 4:

Operation 4a: If the EPS bearers within the PDU session have no EPS bearer identifier value (s) beyond the threshold quantity of bearer identifiers or contexts, the MME 708 sends the bearer contexts in the legacy information elements (IEs) .

Operation 4b: If the EPS bearer identifier of the default bearer is not beyond the threshold quantity of bearer identifiers (e.g., 8) while the EPS bearer identifier values of one or more dedicated bearers is beyond the threshold quantity of bearer identifiers or contexts (e.g., 8) , the MME 708 may send the bearer contexts (e.g., bearer identifiers and information associated with a bearer identifier) whose EPS bearer identifier value is not beyond the threshold quantity of bearer identifiers (e.g., 8) in the legacy information elements. The MME 708 may also send a new information element to transfer the bearer contexts whose EPS bearer identifier value is beyond the threshold quantity of bearer identifiers (e.g., 8) . For example, in certain embodiments, the new information elements may only include the bearer contexts which are not sent in legacy information elements. In further embodiments, the new information elements may include all the bearer contexts for such PDN sessions. In further embodiments, the new information elements may include all the bearer contexts no matter whether they are sent in legacy information elements or not.

Operation 4c: If the EPS bearer identifier value of the default bearer is beyond the threshold quantity of bearer identifiers (e.g., 8) and the EPS bearer identifier values of other dedicated bearers related to the same PDN session are beyond the threshold quantity of bearer identifiers (e.g., 8) , the bearer contexts of such a PDN session may be included in a new information element rather than the legacy information element. In further embodiments, the new information elements may include all the bearer contexts no matter whether they are sent in legacy information elements or not.

It may be desirable to introduce a new information element in the manner noted above. For example, if the target MME 710 does not support beyond the threshold quantity of bearer identifiers or contexts (e.g., if the target MME 710 does not support 15 bearers) , it can handle the legacy information elements normally and will not cause any rejection of the bearer identifiers in the legacy information elements. The new information elements which the target MME 710 cannot understand can be discarded. For operation 4c, the EPS bearer identifiers of such a default bearer may be beyond the threshold quantity of bearer identifiers (e.g., 8) , which is not supported by the target MME 710. Thus, the default bearer will fail to establish. Accordingly, it may be unnecessary to include the bearer contexts in legacy information elements.

If the target MME 710 that supports a quantity of bearer identifiers (e.g., 15 bearers) beyond the threshold quantity of bearer identifiers or contexts, bearer contexts can also transferred via the method above (e.g., in accordance with operation 4) . This may be because the bearer contexts can also be transferred in a legacy way with an enhanced EPS bearer identifier (e.g., for 15 bearers) beyond the threshold quantity of bearer identifiers (e.g., 8) .

At operation 6, the target MME 710 may send a context acknowledgement (ack) message to the source MME 708. If a new information element is included in operation 4 and the target MME 710 can handle it (e.g., the target MME 710 supports a quantity of bearer identifiers (e.g., 15 bearers) beyond the threshold quantity of bearer identifiers or contexts) , the target MME may send a confirmation of bearer context setup indication in the context ack message. The confirmation of bearer context setup indication may indicate a successful bearer identifier that has been successfully set up or is supported at the target MME 710. The confirmation of bearer context setup indication may indicate successful bearer identifier (s) for bearer identifier (s) or context (s) that are associated with a successful set up (e.g., that are supported at the target MME 710) . The source MME 708 may check whether such a confirmation of bearer context setup indication is received. If the source MME 708 transfers bearer contexts whose bearer identifier values are beyond the threshold quantity of bearer identifiers or contexts, and such a confirmation of bearer context setup indication is not recieved, the source MME 708 may deem that such bearers are failed at the target side (e.g., the target MME cannot support such a feature) . Accordingly, the source MME may initiate a delete bearer command or delete session request to release the dedicated bearer or the whole PDN session.

At operation 7, the MME 708 may send create session request/modify bearer request to the SGW 712. Then, the nodes involved in the TAU or RAU process 700 may perform the left, or remaining operations in a conventional TAU or RAU procedure.

While various embodiments of the invention have been described above, it should be understood that they have been presented by way of example only, and not by way of limitation. Likewise, the various diagrams may depict an example architectural or configuration, which are provided to enable persons of ordinary skill in the art to understand exemplary features and functions of the invention. Such persons would understand, however, that the invention is not restricted to the illustrated example architectures or configurations, but can be implemented using a variety of alternative architectures and configurations. Additionally, as would be understood by persons of ordinary skill in the art, one or more features of one embodiment can be combined with one or more features of another embodiment described herein. Thus, the breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments.

It is also understood that any reference to an element herein using a designation such as "first, " "second, " and so forth does not generally limit the quantity or order of those elements. Rather, these designations can be used herein as a convenient means of distinguishing between two or more elements or instances of an element. Thus, a reference to first and second elements does not mean that only two elements can be employed, or that the first element must precede the second element in some manner.

Additionally, a person having ordinary skill in the art would understand that information and signals can be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits and symbols, for example, which may be referenced in the above description can be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

A person of ordinary skill in the art would further appreciate that any of the various illustrative logical blocks, modules, processors, means, circuits, methods and functions described in connection with the aspects disclosed herein can be implemented by electronic hardware (e.g., a digital implementation, an analog implementation, or a combination of the two, which can be designed using source coding or some other technique) , various forms of program or design code incorporating instructions (which can be referred to herein, for convenience, as "software" or a "software module) , or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware, firmware or software, or a combination of these technique, depends upon the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in various ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

Furthermore, a person of ordinary skill in the art would understand that various illustrative logical blocks, modules, devices, components and circuits described herein can be implemented within or performed by an integrated circuit (IC) that can include a general purpose processor, a digital signal processor (DSP) , an application specific integrated circuit (ASIC) , a field programmable gate array (FPGA) or other programmable logic device, or any combination thereof. The logical blocks, modules, and circuits can further include antennas and/or transceivers to communicate with various components within the network or within the device. A general purpose processor can be a microprocessor, but in the alternative, the processor can be any conventional processor, controller, or state machine. A processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other suitable configuration to perform the functions described herein.

If implemented in software, the functions can be stored as one or more instructions or code on a computer-readable medium. Thus, the steps of a method or algorithm disclosed herein can be implemented as software stored on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that can be enabled to transfer a computer program or code from one place to another. A storage media can be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer.

In this document, the term "module" as used herein, refers to software, firmware, hardware, and any combination of these elements for performing the associated functions described herein. Additionally, for purpose of discussion, the various modules are described as discrete modules; however, as would be apparent to one of ordinary skill in the art, two or more modules may be combined to form a single module that performs the associated functions according embodiments of the invention.

Additionally, memory or other storage, as well as communication components, may be employed in embodiments of the invention. It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processing logic elements or domains may be used without detracting from the invention. For example, functionality illustrated to be performed by separate processing logic elements, or controllers, may be performed by the same processing logic element, or controller. Hence, references to specific functional units are only references to a suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.

Various modifications to the implementations described in this disclosure will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other implementations without departing from the scope of this disclosure. Thus, the disclosure is not intended to be limited to the implementations shown herein, but is to be accorded the widest scope consistent with the novel features and principles disclosed herein, as recited in the claims below.

Claims

A method comprising:

receiving a request to transfer one or more bearer contexts, where the bearer contexts comprise a bearer identifier value;

determining whether to transfer the bearer contexts using first information elements or second information elements based on the bearer identifier value;

transferring the bearer contexts; and

receiving a confirmation of bearer context setup.
The method of claim 1, further comprising:

transferring a first bearer context of the bearer contexts in the first information elements, wherein the first bearer context comprises a first bearer identifier value not beyond a threshold quantity value; and

transferring a second bearer context of the bearer contexts using the second information elements, wherein the second bearer context comprises the bearer identifier value, wherein the bearer identifier value is beyond the threshold quantity value.
The method of claim 1, further comprising:

transferring all of the bearer contexts using the second information elements; and

transferring a first bearer context of the bearer contexts in the first information elements, wherein the first bearer context comprises a first bearer identifier value not beyond a threshold quantity value.
The method of claim 1, wherein the confirmation of bearer context setup comprises either:

an indication of whether the bearer contexts included in the first information elements or the second information elements are set up successfully, or

a setup list that comprises a successful bearer identifier, where the successful bearer identifier identifies a bearer context set up successfully.
The method of claim 1, further comprising: releasing failed bearer contexts.
The method of claim 1, further comprising transferring the bearer contexts to a serving gateway, wherein the method is performed by a mobility management entity.
The method of claim 1, further comprising transferring the bearer contexts to a target mobility management entity, wherein the method is performed by a source mobility management entity.
The method of claim 1, further comprising transferring the bearer contexts to a target mobility management entity via a access and mobility management function, wherein the method is performed by a session management functionality.
The method of claim 1, wherein the method is performed by a radio access network.
The method of claim 1, wherein the bearer identifier value is beyond a threshold quantity value.
The method of claim 1, wherein the bearer identifier value is for a default bearer.
The method of claim 11, further comprising transferring the bearer contexts in the second information elements, wherein the bearer contexts comprise one or more dedicated bearers linked with the default bearer.
The method of claim 1, further comprising transferring the bearer contexts in the second information elements, wherein the bearer identifier value is for a dedicated bearer.
An apparatus, comprising:

a receiver configured to:

receive a request to transfer one or more bearer contexts, where the bearer contexts comprise a bearer identifier value, and

receive a confirmation of bearer context setup;

at least one processor configured to:

determine whether to transfer the bearer contexts using first information elements or second information elements based on the bearer identifier value; and

a transmitter configured to:

transfer the bearer contexts.
The apparatus of claim 14, wherein the transmitter is configured to:

transfer a first bearer context of the bearer contexts in the first information elements, wherein the first bearer context comprises a first bearer identifier value not beyond a threshold quantity value; and

transfer a second bearer context of the bearer contexts using the second information elements, wherein the second bearer context comprises the bearer identifier value, wherein the bearer identifier value is beyond the threshold quantity value.
The apparatus of claim 14, wherein the transmitter is configured to:

transfer all of the bearer contexts using the second information elements; and

transfer a first bearer context of the bearer contexts in the first information elements, wherein the first bearer context comprises a first bearer identifier value not beyond a threshold quantity value.
The apparatus of claim 14, wherein the confirmation of bearer context setup comprises either:

an indication of whether the bearer contexts included in the first information elements or the second information elements are set up successfully, or

a setup list that comprises a successful bearer identifier, where the successful bearer identifier identifies a bearer context set up successfully.
The apparatus of claim 14, wherein the first information elements are legacy information elements and the second information elements are new information elements.
A non-transitory computer readable medium having instructions stored thereon, wherein the instructions, when executed by a processor, cause a device to perform operations comprising:

receiving a request to transfer bearer contexts;

determining, based on the request, whether to transfer the bearer contexts to a target, wherein the request indicates whether the target supports a bearer identifier value that extends beyond a threshold quantity value; and

transferring a first bearer context of the bearer contexts to the target.
The non-transitory computer readable medium of claim 19, the operations further comprising: transferring all of the bearer contexts to the target.
The non-transitory computer readable medium of claim 19, the operations further comprising: releasing a second bearer context of the bearer contexts, wherein the second bearer context comprises the bearer identifier value that extends beyond the threshold quantity value.
The non-transitory computer readable medium of claim 19, wherein where the bearer contexts comprise the bearer identifier value that extends beyond the threshold quantity value.
The non-transitory computer readable medium of claim 22, the operations further comprising: determining whether to transfer the bearer contexts using first information elements or second information elements based on the bearer identifier value.