WO2017110650A1

WO2017110650A1 - Method for selection and relocation of user plane functionality

Info

Publication number: WO2017110650A1
Application number: PCT/JP2016/087406
Authority: WO
Inventors: Genadi Velev; Toshiyuki Tamura
Original assignee: Nec Corporation
Priority date: 2015-12-22
Filing date: 2016-12-15
Publication date: 2017-06-29

Abstract

The invention describes a method for user plane functional entity (UP FE) relocation due to overload with minimal impact to the MME. In another method of this invention, a control plane functional entity (CP FE) and UP FE selection is described where the CP FE selects an UP FE in an optimal way considering various additionally introduced informational elements.

Description

METHOD FOR SELECTION AND RELOCATION OF USER PLANE FUNCTIONALITY

This disclosure relates to a communication method for relocating a User Plane function entity and a mobility management function.

The following abbreviations and terminology (whenever differently stated) are used in the current disclosure:

The following terminologies are used within this disclosure.

The terms ‘serving node’ or ‘MME/SGSN’ or ‘MSC/SGSN/MME’ is generally used through the various aspects of this disclosure to describe a functional entity like MSC, or SGSN or MME, or other possible control plane functional entity in the mobile network which terminate the control plane signalling between the core network and the terminal. The serving node (MME/SGSN) can be also a functional entity from future generation networks which is responsible for mobility and session management.

The term HSS/HLR means the repository where the UE’s subscription data is stored and can be either an HSS or an HLR or a combined entity.

The terms ‘terminal’, or ‘device’, or ‘user terminal’ or ‘UE’ (User Equipment) or ‘MT’ (Mobile Terminal) are used in an inter-exchangeable manner where all of the terms express the similarly the equipment used to send/receive data and signalling from network or mobile network.

In the recent years due to the penetration of Network Function Virtualization (NFV) technology the standard bodies like 3^rd Generation Partnership Project (3GPP) start work to split the functionality of traditional mobile core gateways into control plane (CP) and user plane (UP) functional components/entities. Such mobile core gateways are the Serving Gateway (SGW), and PDN Gateway (PGW) and Traffic Detection Function (TDF) which are part of the Evolved Packet Core (EPC) network, but it can be GPRS core network gateway like SGSN and GGSN. Also, in the future any gateway or data plane specific functionality can be realized by CP and UP split functionality. 3GPP SA2 working group started activity to specify an open interface between the CP and UP of the SGW, PGW and TDF entities. The documentation of this study is captured in the document 3GPP TR23.714.

The control and user plane separation of EPC nodes is shortly called CUPS. The idea of CUPS is the potential architecture enhancements for the separation of user plane functionality from control plane functionality in the EPC's SGW, PGW and TDF to further enable flexible (i.e. distributed or centralized) network deployment and operation.

Example architecture for the separation of CP and UP functional entities of the SGW, PGW and TDF is shown in Figure 1. For simplicity it is called ‘split architecture’. The detailed description of the reference points (interfaces) can be found in specification 3GPP TS23.401 and 3GPP TS23.203. The reference points shown with dotted line are assumed to be in the CP and the reference points shown with solid line are assumed to be in the UP.

Figure 2 shows an exemplary overview of the EPS system with the split architecture of SGW, PGW and TDF functional entities. Please note that this architecture may be an assumption in this disclosure and may include novel aspects, e.g. the inclusion of (1) the UTRAN access (NB, RNC and SGSN functional entities from the 3G architecture) or (2) the aspects of Local GW (L-GW). In addition, the CP and UP split is shown also for the Local GW (LGW) functional entity. As the legend of the figure shows, the reference points shown with dotted line are assumed to be in the CP and the reference points shown with solid line are assumed to be in the UP. The interfaces shown with a star (*) at the end are assumed to be new reference points based on new or modified old protocols. For example the S5c* interface can be based on the existing or modified GTP-C protocol as used today over the S5 reference point. Similarly the S5u* interface can be based on the existing or modified GTP-U protocol as used today. The reference points Scu*, Stu* are meant to be new interfaces as Sxa, Sxb and Sxc from Figure 1, which identify the interfaces between the CP and UP of the corresponding entity SGW, PGW (LGW) or TDF.

The so called ‘split architecture’ allows one or more CP functional entities (for short CP FE) to be connected to one or more UP functional entities (for short UP FE). This allows a flexibility to change UP FE without the change of CP FE controlling the concerned UP FE. The UP FE can be a (1) mobility anchor point, e.g. in case of SGW; and also (2) a mobility anchor and access router, e.g. in case of PGW. The change of UP FE can happen due to the following exemplary reasons:
　　　　- Due to mobility event. If a terminal moves (e.g. changing base stations or NodeBs (NB) or eNBs) the UP FE can change.
　　　　- Due to load balancing reasons, the network operator can decide to relocate the UE from one UP FE to another UP FE.

The relocation of SGW, due to reasons different from mobility events, is specified in 3GPP TS 23.401 section 5.10.4 and shown in Figure 3. One example scenario for the MME triggered SGW relocation is during the establishment of a SIPTO (selected IP traffic offload) at local network PDN connection with stand-alone GW or during the establishment of a SIPTO above RAN PDN connection. The detailed description of the steps in Figure 3 can be found in reference [1] 3GPP TS 23.401 section 5.10.4.

In the split architecture, one main feature is that there can be multiple UP FEs controlled by a single or multiple CP FEs. It is expected that a common scenario would be that a single CP FE controls multiple UP FEs. In such a scenario the CP FE can decide to relocate UE(s) from one UP FE to another UP FE based on various criteria. The change of UP FE can be due to reason other than UE mobility scenarios, e.g. due to load balancing. For example to accommodate the changing traffic requirements or bandwidth requirements (e.g. due to traffic fluctuation during day and night hours), the UP may be expanded or contracted (e.g. on scheduled or unscheduled basis) in terms of resources (e.g. CPU, memory, network interfaces, user plane functions, etc.). These procedures are also known as scale-in and scale-out using NFV terminology.

As part of it, new UP resources may be added or existing UP resources may be removed at runtime, and the existing UE sessions may need to be re-distributed over the available set of resources. As a result, the user plane session identity (e.g. GTP-U end-point identity, which is TEID and IP address) for one or more sessions may change and in that case the new user plane session identity needs to be communicated to the peer node(s).

3GPP TS 23.401, General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access; 3GPP TR 23.714, Study on control and user plane separation of EPC nodes;

Problem description 1: on an SGW-C initiated SGW relocation procedure
The relocation of UE(s) from one UP FE to another UP FE would mean at least changing of the UP session identity (e.g. IP address, GTP TEID, or other tunnel IDs) for the established UEs’ sessions. With other words taking the example of SGW, if the CP FE of the SGW (e.g. SGW-C) decides to relocate UE(s) from one UP FE of the SGW (SGW-U) to another UP FE of the same SGW, there is no standardized procedure.

Problem description 2: on an SGW-U selection
According to the TS 23.401[1] Section 4.3.8.2, Serving GW selection function is defined as follows.
　　　　Serving GW Service Area: A Serving GW Service Area is defined as an area within which a UE may be served without need to change the Serving GW. A Serving GW Service Area is served by one or more Serving GWs in parallel. Serving GW Service Areas are a collection of complete Tracking Areas. Serving GW Service Areas may overlap each other.

In addition, Serving GW selection function is defined in Section 4.3.8.2 as follows.
　　　　The Serving GW selection function selects an available Serving GW to serve a UE. The selection bases on network topology, i.e. the selected Serving GW serves the UE's location and for overlapping Serving GW service areas, the selection may prefer Serving GWs with service areas that reduce the probability of changing the Serving GW.

With the two definitions above, it can be concluded that;
1) According to the definition, Serving GW Service Areas are a collection of complete Tracking Areas. In the SGW split architecture, it is a fact that the SGW-C does not communicate to eNBs. The SGW-C communicates to functional entities like serving node (MME, SGSN) and PGW and/or SeGW (security gateway for access other than 3GPP defined) for dealing with PDN connections. On the other hand, the SGW-U communicates to eNB over the S1-U reference point.

Considering two facts, it can be concluded that Serving GW Service Areas according to state-of-the-art should associate with the SGW-Us.

In addition, the SGW-C should have multiple associations to SGW-Us while each SGW-U has its own SGW Service Areas. However, according to the latest 3GPP specifications, this architecture has not yet standardized.

2) In contrast, some SGW-U may cover a large area spanning among multiple service areas where multiple SGW-C covers. However, according to the latest 3GPP specifications, this architecture has not yet standardized.

3) The SGW selection function as per state-of-the-art has a basic assumption that SGW is single logical node per UE. On the other hands, the SGW selection function is performed in the MME according to the step 12) in section 5.3.2.1 TS 23.401[1].

Considering the two facts, it can be concluded that the SGW selection function in the serving node (MME) means to find the SGW-C in the split SGW architecture. Once the serving node (MME) finds an associated SGW, the MME sends a Create Session Request message to an IP address of associated SGW, which in split architecture would mean to SGW-C.

Further, particular UP FEs may implement specific functionality which is used only by a limited number of UEs or for limited number of services. There is need to select the correct UP FE for a given UE or for a given service. One example for such a service is the support of High-latency communication (HLCom) feature as specified in TS23.682 (section 4.5.7) and TS23.401 (section 4.3.17.7). According to HLCom feature, the SGW should implement a specific buffering functionality. If such specific feature, e.g. buffering, is implemented in the UP FE in the split architecture, then there is mechanism needed to select the correct UP FE.

The solutions should be able to;
　　　　- Find new UP FE that can cover all Tracking Areas that UE has informed by the MME with TA-list parameter when UP FE relocation. For example, if UE has TA1 and TA2 as the TA list, then the SGW-U1 has to be chosen as new UP-FE.
　　　　- Find new UP FE that are suitable to accommodate UE based on UE characteristics. For example, if UE has High-latency communication (HLCom) feature, then new UP FE should have big buffer for buffering DL packets.

According to the latest 3GPP specifications, these two requirements have not yet standardized and thus there is no procedure to be referred.

In one aspect, the invention provides a communication method for relocating a UserPlane function entity, comprising: initiating a UserPlane function entity relocation procedure; sending a message for initiating mobility management function triggered UserPlane function entity relocation procedure, to a mobility management function; receiving a Create Session Request message; sending a Create Session Response for continuing the mobility management function triggered UserPlane function entity relocation procedure.

In one aspect, the invention provides a session management function for relocating a UserPlane function entity, comprising: a means for initiating a UserPlane function entity relocation procedure; a means for sending a message for initiating mobility management function triggered UserPlane function entity relocation procedure, to a mobility management function; a means for receiving a Create Session Request message; a means for sending a Create Session Response for continuing the mobility management function triggered UserPlane function entity relocation procedure.

In one aspect, the invention provides a communication method for relocating a UserPlane function entity, comprising: receiving a message for initiating mobility management function triggered UserPlane function entity relocation procedure, from session management function; sending a Create Session Request to the session management function; receiving a Create Session Response to continue the mobility management function triggered UserPlane function entity relocation procedure.

In one aspect, the invention provides a mobility management function, comprising: a means for receiving a message for initiating mobility management function triggered UserPlane function entity relocation procedure, from session management function; a means for sending a Create Session Request to the session management function; a means for receiving a Create Session Response to continue the mobility management function triggered UserPlane function entity relocation procedure.

1) The solution for UP FE relocation requires minimal impacts to the MME.
2) The solution for CP FE and UP FE selection procedure has the benefit on an optimal UP FE selection where the CP FE considers various additionally introduced informational elements from the serving node to the CP FE.

Figure 1 shows example architecture for the separation of CP and UP functional entities of the SGW, PGW and TDF. Figure 2 shows an exemplary overview of the EPS system with the split architecture of SGW, PGW and TDF functional entities. Figure 3 shows the relocation of SGW, due to reasons different from mobility events. Figure 4 shows SGW Service area deployment example with multiple SGW-Us. Figure 5 shows SGW Service area deployment example with SGW-U that covers large area. Figure 6 shows an exemplary signalling flow for a main example embodiment of this invention based on CP FE initiated relocation towards the MME where the MME applies the existing triggered SGW relocation. Figure 7 shows an exemplary signalling flow for solution (2) of this invention based on SGW-C initiated SGW-U relocation towards PGW firstly and then towards MME. Figure 8 shows example architecture of colocation CP FEs of the SGW and PGW. Figure 9 shows the signalling flow of the CP FE and UP FE selection. Figure 10 shows ATTACH procedure. Figure 11 shows an example of Tracking Area Update (TAU) procedure with Serving GW (SGW) relocation. Figure 12 shows an example of the E-UTRAN Tracking Area Update without SGW Change procedure. Figure 13 shows a block diagram for serving node. Figure 14 shows a block diagram for CP FE or UP FE.

Solution to Problem description 1
In order to solve the above described problem, different solutions are described in various aspects herewith.

A main requirement to the solution(s) described in this disclosure is re-use the existing procedure of SGW relocation as much as possible. Especially the impact on the RAN and UE should be minimized.

The main idea of the present disclosure is to rely on the existing procedure of MME triggered SGW relocation, however to initiate the procedure from the CP FE of the SGW (SGW-C). With other words, the solution can be described as SGW-C triggered MME-centric solution.

The initiation of the UP FE relocation can be based on non-mobility events such like a node overload or increase or decrease of data traffic where scale-in/scale-out is initiated for the UP FE or other network management procedures are triggered.

In some aspects, the SGW-C should have multiple associations to SGW-Us while each SGW-U has its own SGW Service Areas. This is reasonable architectural requirement as having wide SGW Service Area means that the SGW-U has to have many GTP-U associations to many eNB and this leads costs. It is an implicit assumption that the SGW-U is located closer to the edge (i.e. access network) and the SGW-U has smaller Service Area than the SGW-C, which is located more in the network core. Figure 4 shows the assumptions explained above. Figure 4 may include novel and inventive parts, e.g. showing the service areas (e.g. Service Area 1) of the new functional entities like CP FE (e.g. SGW-C) and the service area of UP FE (e.g. SGW-U1 or SGW-U2). For example the service area of the SGW-U1 is the area covered by Tracking Area 1 and Tracking Area 2, whereas the service area of the SGW-U2 is the area covered by Tracking Area 2 and Tracking Area 3.

In some aspects, some SGW-U may cover a large area spanning among multiple service areas where multiple SGW-C covers. This network configuration could be feasible for supporting ultra-high speed moving objects such as bullet train or airplane as user plane path between the PGW and SGW-U can remain the same even UE traverses SGW-C service area. An additional benefit is that DL packet forwarding procedure using end marker packet due to SGW change mobility can be avoided as the SGW-U remains the same even UE traverses SGW-C service area. Figure 5 shows the assumptions explained above. Figure 5 may include novel and inventive parts, e.g. showing the service areas (e.g. Service Area 1) of the new functional entities like CP FE (e.g. SGW-C) and the service area of UP FE (e.g. SGW-U1, SGW-U2 or SGW-U3). Another essential new part is that a single UP FE can be served by multiple CP FEs (e.g. SGW-C1 and SGW-C2).

Figure 6 shows an exemplary signalling flow for a main example embodiment of this disclosure based on CP FE (e.g. SGW-C) initiated relocation towards the MME where the MME applies the existing triggered SGW relocation. This is referred as solution (1) in this disclosure.

The description of the steps in Figure 6 is provided below:
　　　　Step (0) As a starting point in the split architecture, the UP bearer tunnels (GTP-based or PMIP based or other tunnelling protocol) are established between the PGW-U and SGW-U on one side (S5 reference point) and from SGW-U to eNB on the other side (S1 reference point). Note that one SGW-U can be connected to multiple SGW-Us and to multiple eNBs.
Multiple combinations of S1-U and S5-U/S8-U UP bearer tunnels exit per UE when UE supports Multiple-PDN connections.
From the SGW-U point of view, multiple S1-U and S5-U/S8-U UP bearer tunnels exist for multiple UEs that use the SGW-U.

　　　　Step (1)　　 Due to non-mobility events the SGW-C decides to initiate UP FE relocation. Depending on the situation, it is the SGW-C decision which UEs or UE’s bearers are to be relocated to a new SGW-U FE. For this purpose the SGW-C can build a list of UEs to be relocated (or re-assigned).

　　　　Step (2)　　The SGW-C may initiate a preparation procedure for instantiation of the new SGW-U FE as a destination of new SGW-U for SGW-U relocation procedure to be taken in.
The SGW-C may also request UP identifier (IP address of the UP FE’s interface, tunnel endpoint ID (e.g. GTP TEID), etc.) assignment for the UE determined in step (1). As a result of this step, the SGW-C knows the new UP IDs for each UE. The new UP IDs for each UE is referred by the SGW-C when the Create Session Request message is arrived from the MME when Step 4.1 or Step 4.2 is taken.

　　　　Step (3)　　SGW-C sends new GTP-C message “Serving GW relocation command” message to the MME to perform the “MME triggered Serving GW relocation” procedure as per TS23.401 section 5.10.4. The SGW-C can send a separate “Serving GW relocation command” message per UE or can send a single “Serving GW relocation command” message to the MME to request MME to perform the “MME triggered Serving GW relocation” procedure as per TS23.401 section 5.10.4 for multiple UEs. In this case, “Serving GW relocation command” message contains a list of UEs’ IDs for example, a list of S11-TEID-Cs or a list of IMSIs.
This Step (3) can be either a “Serving GW relocation command” message as no response message required from the MME or “Serving GW relocation Request” message and an associated “Serving GW relocation Response” message.

　　　　Step (4.1)　　MME initiates the “MME triggered Serving GW relocation” procedure according TS23.401 section 5.10.4 starting from Step (2). This means the MME sends Create Session Request message back to the SGW-C, the SGW-C requests the bearer modification to PGW. After the successful response from the SGW-C, the MME continues with the SGW relocation towards the eNB sending “Serving GW relocation Notification” message. These procedures are performed per UE and/or per bearer.

　　　　Step (4.2)　　This optional procedure is similar to step (4.1), i.e. to “MME triggered Serving GW relocation” procedure, however instead of sending signalling messages per UE (and/or per bearer) the bulk signalling is applied. This means the signalling message, e.g. Create Session Request/Response or Modify Bearer Request/Response messages include a list of UEs and corresponding UP IDs.

　　　　Step (5)　　The SGW-C may delete the old SGW-U FE if all associated bearers have been relocated to a new UP FE. This decision can be made by either receiving explicit “Serving GW relocation Response” message from the MME or confirming all sessions associated with the old SGW-U FE have been removed by Step 4. With this the relocation of the UEs to a new UP FE is completed.

It is noted that the SGW-U FEs can implement additional functionality to prevent packet losses and/or to avoid if possible packet re-ordering. For this purpose the old SGW-U FE can send an ‘end-marker’ to the corresponding eNB in the downlink to notify that no more Downlink packets should be expected.

One drawback of the solution shown in Figure 6 is that the signalling is not optimal. For example the SGW-C requests the MME to initiate the “MME triggered SGW relocation” procedure, and then the MME sends request to SGW-C to perform SGW relocation. This is not optimal as more-or-less similar content of messages is sent in both directions over the same reference point; and in addition this signalling is executed per UE. Thus, optimizations can be introduced as described below.

One Variant
In another solution of this invention, referred as solution (2), an optimization to the solution (1) is proposed in order to reduce the signaling in the network. The main idea of solution (2) is that the SGW-C initiates the relocation of UE to another UP FE (e.g. SGW-U), as the SGW-C firstly requests the PGW (e.g. PGW-C) to update its UP-FE (e.g. PGW-U) with the new UP IDs. After successful update of the PGW, i.e. after the PGW-C acknowledges the updated of PGW-U, the SGW-C request the MME to update the S1-U bearer UP IDs in the RAN node.

Comparing solution (2) with solution (1), solution (2) can be described as SGW-C centric and SGW-C triggered allocation of the SGW-U session IDs.

Please note that solution (2) has bigger impact on the MME, as the SGW-C will indicate to the MME the already executed relocation of the UP IDs (UP FEs), so that the MME does not need to contact the SGW anymore.

Figure 7 shows an exemplary signalling flow for solution (2) of this invention based on SGW-C initiated SGW-U relocation towards PGW firstly and then towards MME.

　　　　Step (0)　　As a starting point in the split architecture, the UP bearer tunnels (GTP-based or PMIP based, or other tunnelling protocol) are established between the PGW-U and SGW-U on one side (S5 reference point) and from SGW-U to eNB on the other side (S1 reference point). Note that one SGW-U can be connected to multiple SGW-Us and to multiple eNBs.

　　　　Step (1)　　Due to non-mobility events the SGW-C decides to initiate a UP FE relocation. Depending on the situation, it is the SGW-C decision which UEs or UE’s bearers are to be relocated to a new SGW-U FE. For this purpose the SGW-C can build a list of UEs to be relocated (or re-assigned) from one SGW-U FE (SGW-U) to another SGW-U FE (SGW-U).

　　　　Step (2)　　The SGW-C initiates a preparation procedure for instantiation of the new SGW-U FE and/or request UP identifier (IP address of the UP FE’s interface, tunnel endpoint ID (e.g. GTP TEID), etc.) assignment for the UE determined in step (1). As a result of his step, the SGW-C knows the new UP IDs for each UE.

　　　　Step (3)　　The SGW-C identifies the PGW corresponding to the UE which UP ID should be updated and the SGW-C requests the PGW (or PGW-C FE) to update the UP ID(s) for a given UE. This signalling request is performed per UE. Optionally the SGW-C can send a bulk signalling message, e.g. with a list of UEs which are served by the same PGW.
　　　　　　　　Step (3.1)　　During this step the PGW updates internally the UP ID(s) for all UEs which have been indicated by the SGW-C.
　　　　　　　　Step (3.2)　　the PGW (or PGW-C) replies to the SGW-C about the success or non-success of the UP ID update from step (3.1). If a reply from the PGW (PGW-C) is positive, then the SGW-C proceeds with step (4). If a reply from the PGW (PGW-C) is negative, i.e. the UP IDs in the PGW (PGW-U) couldn’t be updated, then the SGW-C reverts the UP IDs for the UEs, for which the reply was negative.

　　　　Step (4)　　The SGW-C requests MME to update the UE’s UP IDs. With other words, the SGW-C initiates the UP ID update, but there is an indication that the MME can directly proceed with this request towards the RAN nodes without requesting of UP ID update back to the SGW. For example the existing Bearer Update Request procedure can be modified, e.g. by a new indication or a new Informational Element (IE). Also a new message (e.g. GTP-C message or any other tunnel control protocol) can be specified to fulfil this purpose.

　　　　Step (5.1)　　The MME verifies the request from the SGW-C, e.g. for validity. The MME determines whether the concerned UE is registered at any RAN node currently (e.g. whether the MME is in CONENCTIVE or ACTIVE mode). If the concerned UE is not registered (e.g. the UE is in IDLE state) then the MME stores the request in the UE’s context and send the updated UP IDs at the next context establishment at any RAN node. If the UE is registered with a RAN node, then the MME initiates procedure for UP ID update in the RAN node. For example such procedure can the existing S1-AP Relocation Request procedure, but also another update procedures are possible, also another protocols like RANAP or any other control protocol between the RAN and CN.

　　　　Step (5.2)　　The RAN node replies with success or non-success of the UP ID update procedure.

　　　　Step (6)　　If the UE is registers at a RAN node, the MME replies to the SGW-C with the result of the procedure in steps (5.1) and (5.2). If the UE is not registers at a RAN node, the MME replies to the SGW-C without performing the steps (5.1) and (5.2). The reply from MME to SGW-C uses a message corresponding to the one in step (4), i.e. GTP-C or other protocol message.

　　　　Step (7)　　The SGW-C instructs the old SGW-U FEs to delete the UE’s states. With this the relocation of the UEs to a new UP FE is completed. The data flows in UL and DL over the new SGW-U FE to/from the PGW (PGW-U) and the RAN node.

Please note the update procedures within SGW-C and SGW-U and PGW-C and PGW-U in Figure 6 and Figure 7 are similar.

Another Variant
In another solution of this invention, referred as solution (3), an optimization to the solution (1) is proposed in order to reduce the signaling in the network. The main idea of solution (3) is that the SGW-C initiates the relocation of UE to another UP FE (meaning the update of UE’s UP IDs in PGW and RAN node), as the SGW-C requests simultaneously the PGW (e.g. PGW-C) and MME to update the corresponding UP FE (PGW-U and eNB) with the new UP IDs. In such a case the update of the UP IDs in the PGW and RAN nodes are performed faster than in solutions (1) and (2), however, there could be issues if the procedure is not successful in either PGW or RAN node.

Another variant
In another solution of this invention, referred as solution (4), the SGW-C can include a time value at which the update with the new UP IDs in PGW (UP FE) and RAN node are activated.
Taking an example as per Figure 7, the CP FE can inform during the update procedures in steps (3), step (4) and step (5) the PGW’s UP FE and the RAN node about a timer (e.g. 300 milliseconds) after those expiration the update in the UP FE should become effective. Alternatively the CP FE can inform the PGW’s UP FE and the RAN node about an absolute time value (e.g. HH:MM:SS meaning ‘hours:minutes:seconds’ in a given time zone) at which the update in the UP FE should become effective.

Another Variant (Co-located CP FE of SGW and PGW)
In optimized split architecture, it is assumed that at least the SGW-C and PGW-C are co-located, e.g. implemented is the same data center (i.e. no reference point / interface between these 2 functional entities is needed). Such a scenario is shown in Figure 8 based on the assumptions from Figure 2.

In this alternative solution, the CP FEs of the SGW and PGW can be co-located (shown as S/PGW-C) which would simplify the CP signaling exchange procedures, and further it would simplify the selection and/or relocation of the UP FE(s). This would be beneficial especially in a simplified User plane where SGW-U and PGW-U are also co-located, i.e. a single UP FE. For example, depending on the characteristics of the UE, e.g. speed, activated service, the CP FE can decide to allocate an UP FE which is closer to the edge, or more deeper in the core.

In the case of problem description 1, it is assumed that SGW-U and PGW-U are separate functional entities, and re-allocation of the UP session ID is needed. In this case, the S/PGW-C after deciding to update the SGW-U IDs, the S/PGW-C can apply either solution (1) or solution (2) or solution (3) from above.

The procedures shown in Figure 6 and Figure 7 can be optimized in case of co-located S/PGW-C. This invention does not show these optimizations as they are considered as engineering effort.

According to the example embodiments in this invention, the serving node (MME/SGSN/MSC) should be modified/extended to be able to behave according to the proposed solution(s). The serving node can be described schematically via the block diagram as in Figure 2:

The protocol to be used over the reference points [Sxa, Sxb and Sxc] or [Scu, Stu] is to be studied, but possible alternatives could be GTP-C or OpenFlow.

The main features of the current invention include the following:
　　　　- SGW-C determines that SGW-U needs to be relocated and scale-in/scale-out is performed.
　　　　- CP FE (SGW-C, PGW-C, TDF-C) considers the specific characteristics of the UP FEs (SGW-U, PGW-U, TDF-U) when selecting an UP FE. For example if one out of multiple UP-FE implements features needed for e.g. High-latency Communication (Rel-13 HLCom feature, as per TS23.682 section 4.5.7 and TS23.401 section 4.3.17.7) then the CP FE selects this UP FE for UEs (or PDN connections or bearers) having high-latency communication characteristics.

Solution to Problem description 2
To address the scenario and problems from the problem description 2 in the split architecture, this invention proposes that the MME selects such a CP FE of the gateway (e.g. SGW-C or co-located S/PGW-C) whose Service Area covers at least the TAI list to be assigned to the UE. The CP FE of the gateway is then responsible to select UP FE of the gateway (e.g. SGW-U or co-located S/PGW-U) which is close enough to access network, e.g. to the RAN, and also having a Service Area covers at least the TAI list to be assigned to the UE.

It is assumed that the service area of the CP FE (understood as the CP FE of the gateway which is may be used as mobility anchor point) is larger than the service area of the UP FEs controlled by the CP FE. In this invention the UP FE is meant as the UP FE of the gateway which can be used as mobility anchor point. With other words the service areas of the UP FEs are a subset of the service area of CP FE as shown in Figure 4.

There is a resulting problem in the case of UE movement - when the UE leaves a previously assigned mobility area (e.g. a TAI list) the UE performs Idle or Connected mode mobility procedure with e.g. the serving node. The serving node may assign a new TAI list which is still in the service area of the CP FE (SGW-C or S/PGW-C). With this the serving node would not initiate any procedures with CP FE, however, the new TAI list may not be in the service area of the UP FE (e.g. SGW-U). So, the UE would leave the UP FE service area and the UE would lose connectivity.

In order to solve the above mentioned problem, it is proposed that the serving node always informs the CP FE about the change of UE’s mobility tracking location (e.g. changing the TAI list), even though the service area of the CP would cover the new assigned UE’s mobility tracking location (e.g. new TAI list). This would require changes in the serving node internal processing of triggering update procedure to the CP FE. The MME may have internal logic to decide whether to start or not the update procedure towards the CP FE. For example the MME may consider the following parameters when deciding whether to update the CP FE: 1) change of the UE’s topological location, 2) the used application/services or activated bearers (PDN connections), e.g. assuming that the MME knows the level of coverage of the selected UP FE.

For this purpose the main idea of this solution is that the CP FE of the gateway should be aware about the network topological location (meaning the cell IDs or TAI list) or geographical location (geographical area) which is assigned to the UE for mobility management. In order to provide this network mobility topological location to the CP FE of the gateway, it is proposed that the serving node transmits this information to the CP FE of the gateway. With other words, the serving node sends the topological location (e.g. TAI list) assigned to the UE for mobility to the CP FE of the gateway. CP FE of the gateway uses this information to select an optimal UP FE of the gateway which e.g. covers this network topological location.

In addition, the serving node sends to the CP FE of the gateway information related to (a) type of UE or (b) desired UP FE characteristics in order to facilitate the selection of an optimal UP FE of the gateway. For example the ‘type of UE’ can be the UE Usage Type specified for Dedicated CNs (DECOR) or “IoT” or any similar UE characteristic to allow the CP FE of the gateway to select a UP FE of the gateway from the corresponding DCN or network slice configured on the user plane.

Another useful UE characteristic could be the UE’s mobility level or mobility pattern, e.g. whether the UE is static, semi-static, nomadic, pedestrian mobility pattern, or is it a moving train or car. This mobility pattern can be used by the CP FE of the gateway to select UP FE of the gateway which is closer to the edge/RAN (e.g. if the UE is static, or semi-static) or not so close to the edge/RAN (e.g. if the UE is moving with high-speed). In addition, if the UE moves with very-high-speed, for example bullet train or airplane, then UP FE that has large coverage spanning among multiple service area should be chosen in order to avoid user plane path change between the SGW and PGW due to SGW change mobility event.

In another example, the serving node sends to the CP FE of the gateway the desired UP FE characteristics, e.g. UP FE with increased buffer capability e.g. for high latency communication (HLCOM), or enhance DRX (eDRX) handling, or Power Saving Mode (PSM) handling, or specific M2M/IoT specific feature, or any other feature which can be relevant for the selection of UP FE.

Yet another useful information which can be sent from the serving node to the CP FE of the gateway could be the location of the access/RAN node, e.g. the NB, eNB, BS, etc. For example this information can be used by the CP FE of the gateway to select UP FE of the gateway which is close to a particular RAN node, especially of the UE is static or semi-static.

In summary, the proposed solution also depicted in Figure 9 include the procedure for initial selection of UP FE, but also for re-selecting (i.e. updating) the already existing UP FE with a new UP FE. The re-selection (update) of the UP FE is based on trigger from the serving node, e.g. due to a user mobility event.

Figure 9 shows the signalling flow of the CP FE and UP FE selection as described above.

The steps from Figure 9 are described as follows:
　　　　Step (0)　　UE sends a Mobility request message to the serving node due to mobility event, e.g. Attach procedure or change of TA. For example the UE can send a TAU request due to mobility event. Please note that this step can be a part of a more general procedure, e.g. Attach procedure with Attach request message where the ‘mobility request’ is a part of the more general message.

　　　　Step (1)　　The serving node (MME, SGSN, MSC or other mobility/session management entity) selects a CP FE (S/PGW-C) based on the network topological location assigned to a given UE (e.g. TAI list) and Serving Area of the CP FE. The CP FE selection can be e.g. based on DNS resolution considering UE’s mobility tracking location (e.g. new TAI list), the UE type/characteristics or other required functionality.

　　　　In case of mobility event, e.g. changing of TAI list, the serving node informs the CP FE about the change of UE’s mobility tracking location (e.g. changing the TAI list) even though the CP FE service area would cover the new assigned UE’s mobility tracking location. In this case the serving node triggers an Update procedure towards the CP FE.

　　　　The serving node implements means to transmit and process a request from the UE, to trigger internal process of generating message e.g. Create/Update UP session request, to the CP FE; but also to transmit and process information towards/from CP FE.

　　　　According to an alternative solution described below, the serving node can compare the possibly new UE’s mobility tracking location (e.g. new TAI list) with the stored service area of the serving UP FE. The serving node initiates Update procedure towards the CP FE only if the UP FE service area does not cover the possibly new UE’s mobility tracking location (e.g. new TAI list).

　　　　Please note that the serving may or may not be aware about the separation of the C/U plane, i.e. whether the CP FE and UP FE are different entities. If the CP FE and UP FE are collocated, then the procedure can be similar to the existing S/PGW selection procedure.

　　　　Step (2)　　The serving node sends Create/Update UP session request to the CP FE for UP session establishment. The UP session establishment may mean tunnel establishment or stateless session. The Create UP session request can include one or more of the information (information elements, IE) described above in this solution. More specifically it could include: (Tunnel ID, UE topological location, UE characteristics, UP characteristics, eNB location, etc.).

　　　　This step can be similar to step 12 from Figure 10 or step 8 from Figure 11, however extended with the above mentioned information.

　　　　Note that the Create/Update UP session request/response messages mentioned here can be existing GTP messages such as Create Session Request/Response and Modify Bearer Request/Response messages; or it can be a new/existing message of other protocol (e.g. OpenFlow) defined e.g. by 3GPP CT4 working group or other organization.

　　　　Step (3)　　The CP-FE processes the received information and based on the included IEs selects, if necessary, an UP FE. How the information (IEs) can be used to select an appropriate UP FE is described above in this solution.

　　　　In case of user mobility event, the CP FE of the gateway can decide to select a new UP FE based on the new UE’s mobility tracking location (e.g. new TAI list). This step can include a procedure for the gateway (mobility anchor point) relocation. For this purpose the CP FE implements means for selection/reselection of the UP FE based on information received in step (2).

　　　　The CP FE of the gateway may store or maintain the UE’s mobility tracking location (and other information received in step (2)) in order to assign a new UP FE in case of congestion or overload or other maintenance reasons like restoration of the UP entity (or mobility anchor point), etc.

　　　　Also other procedures may be performed by the CP FE related to the establishment of new data sessions in the UP FE, e.g. update to other CP FE of different gateway (PGW-C, different mobility anchor like PGW). Those procedures are not shown in the figure.

　　　　Step (4)　　The CP FE requests the selected UP FE to establish/allocate or update the UP resources for the given traffic flow or bearer.

　　　　If a selection of new UP FE is done or update of the UP FE is performed, the CP FE needs to delete the context in the old UP FE. This delete procedure is not shown in the figure for simplicity.

　　　　Note that the Allocate/Relocate UP resource request/response messages mentioned here can be existing GTP messages such as Create Session Request/Response and Modify Bearer Request/Response messages; or it can be a new/existing message of other protocol (e.g. OpenFlow) defined e.g. by 3GPP CT4 working group or other organization.

　　　　Step (5)　　The CP FE sends response to the serving node about the success or failure of the UP resource establishment. The CP FE of the gateway can inform the serving node about the identities of the selected (or updated) UP FE (or UP session identity) in case the serving node needs to update or inform a RAN node about the UP FE identity (e.g. UP session identity).
This step can be similar to step 16 from Figure 10 or step 11 from Figure 11.

　　　　Also, optionally this step can be performed immediately after step (2) if there is no need for selection/reselection or update of the UP FE.

　　　　Optionally, according one alternative solution described below, the CP FE can indicate to the serving node the service area of a selected UP FE. The serving node can store the UP FE service area in order to decide at any next UE mobility event whether Update procedure towards the CP FE, i.e. step (2), is needed. The CP FE and serving may be configured with this option of exchanging UP FE service area, or serving node and CP FE may exchange capabilities when establishing a session.

　　　　Step (6)　　The serving node sends a response to the UE request from step (1). This step indicates the result of the UE’s mobility tracking location area update. For example this response can be TAU accept or TAU reject message

In one alternative of the above solution, the CP FE of the gateway (or of the mobility anchor point) can select multiple UP FE of the gateway (or of the mobility anchor point) e.g. for different service traffic flows. With other words, one S/PGW-C can be connected to 2 or more S/PGW-Us. For example, the UE can use different data traffic flows (e.g. PDN connection, PDP contexts, bearers) to different services like Internet access and Voice/Video service. For example the Internet access service is not very delay sensitive (or no IP address continuity is necessary) so that the mobility anchor point (SGW-U or S/PGW-U) for this traffic flow can be located closer to the access network (aka closer to the edge). The frequent relocation of SGW-U in this case would not considerably impact the UE used service.

On the contrary in case of Voice/Video or other traffic flows, the mobility anchor point (SGW-U or S/PGW-U) can be located more centrally in the core network in order to avoid frequent gateway relocation (e.g. to assure IP address continuity).

Having such a scenario, in case of initial CP FE and UP FE assignment (e.g. during Attach procedure), the serving node provides to the selected CP FE in addition information about the UE’s used applications/services. This would assist the CP FE to select an appropriate UP FE or multiple UP FEs for the particular UE.

In case of mobility event of the UE, the CP FE can decide to relocate only one UP FE but keep the other UP FEs unchanged.

In another alternative option, it is possible that the CP FE indicates the service area of the selected UP FE to the serving node, so that the serving node can select TAI list at next UE mobility events which matches to the UP FE service area. The serving node has means to store the service of each UP FE which is in use currently. In such case the serving does not need to initiate Update procedure each time when the UE performs a Mobility request procedure, but instead the serving node checks whether the UE moves to areas which are not covered by the UP FE service area, so that the serving node needs to perform Create/Update UP session procedure (step (2)) towards the CP FE.

In another alternative, considering network slicing, an architecture can be assumed where a single serving node may select multiple CP FE of the gateways depending on the UE’s used application/services.

ATTACH Procedure
When the MME sends the Create Session Request message to SGW when UE attaches to the network, the Create Session Request message includes TA-list that UE will be informed in the ATTACH procedure. The TA-list can help the SGW-C to determine which SGW-U to be chosen to the UE.

Similarly, the MME includes subscriber data ex. APN, UE sage type and etc. to the Create Session Request message so that SGW-C can choose suitable SGW-U FE based on UE characteristic.

Figure 10 shows an example of the Attach procedure. In this figure, step 12 is extended to include the UE’s network topological location and additional information to be provided from the MME to the SGW (SGW-C) for UP FE (e.g. SGW-U) selection.

Tracking Area Update procedure with Serving GW change Procedure

When the MME sends the Create Session Request message to new SGW when UE performs Tracking Area Update procedure, the Create Session Request message includes TA-list that UE will be informed in the Tracking Area Update procedure. The TA-list can help the SGW-C to determine which SGW-U to be chosen to the UE.

Similarly, the MME includes subscriber data ex. APN, UE sage type and etc. to the Create Session Request message so that SGW-C can choose suitable SGW-U FE based on UE characteristics.

In addition, the MME may populate SGW-U related information that is being used in the Create Session Request message. The SGW-U information can be SGW-U identifier or/and IP address and TEID for S1-U and S5/S8 reference points. This information can help new SGW-C to judge whether the SGW-U being used can continuously be used after the TAU procedure as the SGW-U being used has large coverage including the TA-list that the MME sends to the new SGW-C. If the SGW-C finds out that the SGW-U being used can continuously be used, then the new SGW-C populates an indication flag in the Modify Bearer Request message as shown in step 9 in Figure 10 to indicate the PGW that an insertion of end marker is not needed as no SGW-U change to be happened.

Alternatively, the P-GW solely makes a decision of no end marker insertion by comparing a S5/8-U SGW F-TEID in each bearer context in the Modify Bearer Request message with the S5/8-U SGW F-TEID being used in the P-GW. If it matches then no need to insert end markers.

Figure 11 shows an example of the TAU procedure with SGW relocation. In this figure, step 8 is extended to include the UE’s network topological location and additional information to be provided from the MME to the SGW (SGW-C) for UP FE (e.g. SGW-U) selection.

E-UTRAN Tracking Area Update without SGW Change Procedure

When the MME sends the Modify Bearer Request message to SGW when UE performs Tracking Area Update procedure, the Modify Bearer Request message includes TA-list that UE will be informed in the Tracking Area Update procedure (e.g. in the TAU Acknowledge message). The TA-list can help the SGW-C to determine which SGW-U to be chosen to the UE if the SGW-U relocation is required.

Similarly, the MME includes subscriber data ex. APN, UE sage type and etc. to the Modify Bearer Request message so that SGW-C can choose suitable SGW-U FE based on UE characteristics.

Figure 12 shows an example of the E-UTRAN Tracking Area Update without SGW Change procedure. In this figure, step 9 is extended to include the UE’s network topological location and additional information to be provided from the MME to the SGW (SGW-C) for UP FE (e.g. SGW-U) selection.

According to the example embodiments in this invention, the serving node (e.g. a MME, SGSN, MSC) is modified to be able to handle the signaling to/from the SGW in order to utilize the solutions described in this invention. The serving node 30 can be represented schematically via the block diagram as in Figure 13. The Network Interface box can implement S1-MME interface or S11 interface and/or other CN interfaces towards other CN functional entities e.g. in the user plane.

As shown in Figure 13, the serving node 30 comprises a transceiver circuit 31 and a network interface 32 for transmitting signals to and for receiving signals from other network entities. The serving node 30 comprises a controller 33 to control the operation of the serving node 30. The controller 33 is associated with a memory 34.

Software may be pre-installed in the memory 34 and/or may be downloaded via a communication network or from a removable data storage device (RMD), for example. The controller 33 is configured to control the overall operation of the serving node 30 by, in this example, program instructions or software instructions stored with in the memory 34. As shown, there software instructions include, among other things, an operating system 35 and a communication module 36.

The communication control mode 36 controls the communication between the serving node 30 and other network entities that are connected to the serving node 30. The communication control node 36 includes a transceiver control module 37.

According to the example embodiments in this invention, the CP FE (e.g. a SGW-C, or combined S/PGW-C, or SGSN-C) and the UP FE (e.g. SGW-U, or combined S/PGW-U, or SGSN-U) is modified to be able to handle the signaling to/from the MME in order to utilize the solutions described in this invention. The CP FE and the UP FE 40 can be represented schematically via the block diagram as in Figure 14. The Network Interface box can implement S1-U interface or S5 interface, or S11 and/or other CN interfaces towards other CN functional entities.

As shown in Figure 14, the CP FE or the UP FE 40 comprises a transceiver circuit 41 and a network interface 42 for transmitting signals to and for receiving signals from other network entities. The CP FE or the UP FE 40 comprises a controller 43 to control the operation of the CP FE or the UP FE 40. The controller 43 is associated with a memory 44.

Software may be pre-installed in the memory 44 and/or may be downloaded via a communication network or from a removable data storage device (RMD), for example. The controller 43 is configured to control the overall operation of the CP FE or the UP FE 40 by, in this example, program instructions or software instructions stored with in the memory 44. As shown, there software instructions include, among other things, an operating system 45 and a communication module 46.

The communication control mode 46 controls the communication between the CP FE or the UP FE 40 and the other network entities connected to the CP FE or the UP FE 40. The communication control node 46 includes a transceiver control module 47.

While the invention has been particularly shown and described with reference to example embodiments thereof, the invention is not limited to these embodiments. It will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the sprit and scope of the present invention as defined by the claims.

This application is based upon and claims the benefit of priority from European Patent application No. EP15202209.1, filed on December 22, 2015 and from European Patent application No. EP16151157.1, filed on January 13, 2016, the disclosures of which are incorporated herein in their entirety by reference.

Claims

A communication method for relocating a UserPlane function entity, comprising:
　　　　initiating a UserPlane function entity relocation procedure;
　　　　sending a message for initiating mobility management function triggered UserPlane function entity relocation procedure, to a mobility management function;
　　　　receiving a Create Session Request message;
　　　　sending a Create Session Response for continuing the mobility management function triggered UserPlane function entity relocation procedure.
The communication method according to claim 1, further comprising:
　　　　deciding which at least one of UEs (user equipments) and UE’s bearers are to be relocated to a new UserPlane function entity.
The communication method according to claim 2, further comprising:
　　　　creating a list of the UEs to be relocated.
The communication method according to any one of claim 1 to 3, further comprising:
　　　　sending the message to the UserPlane function entity per UE.
The communication method according to any one of claim 1 to 4, wherein
　　　　the sending the message is performed by sending a single message to the mobility management function for a plurality of UEs.
The communication method according to claim 5, wherein
　　　　the message includes at least one of a list of UE’s Identifiers, a list of S11-TEID(Tunnel Endpoint IDentifier)-Cs, and a list of IMSIs (International Mobile Subscriber Identities).
The communication method according to any one of claim 1 to 6, further comprising:
　　　　requesting the UserPlane function entity to an identifier for the UserPlane function entity.
The communication method according to claim 7, further comprising:
　　　　receiving the identifier for the UserPlane function entity for each UEs.
The communication method according to claim 1 to 8, wherein
　　　　the mobility management function triggered UserPlane function entity relocation procedure is performed per at least one of UEs and bearer.
The communication method according to claim 1 to 9, further comprising:
　　　　deleting an old UserPlane function entity if all bearers associated to the old UserPlane function entity is relocated to a new UserPlane function entity.
The communication method according to claim 10, further comprising:
　　　　deciding to perform the deleting the old UserPlane function entity by at least one of receiving a response message from the mobility management function and confirming all sessions associated with the old UserPlane function entity is removed.
A session management function for relocating a UserPlane function entity, comprising:
　　　　a means for initiating a UserPlane function entity relocation procedure;
　　　　a means for sending a message for initiating mobility management function triggered UserPlane function entity relocation procedure, to a mobility management function;
　　　　a means for receiving a Create Session Request message;
　　　　a means for sending a Create Session Response for continuing the mobility management function triggered UserPlane function entity relocation procedure.
A computer program comprising computer implementable instructions for causing a programmable communications device to perform the method of any claims of 1 to 11.
A communication method for relocating a UserPlane function entity, comprising:
　　　　receiving a message for initiating mobility management function triggered UserPlane function entity relocation procedure, from session management function;
　　　　sending a Create Session Request to the session management function;
　　　　receiving a Create Session Response to continue the mobility management function triggered UserPlane function entity relocation procedure.
A mobility management function, comprising:
　　　　a means for receiving a message for initiating mobility management function triggered UserPlane function entity relocation procedure, from session management function;
　　　　a means for sending a Create Session Request to the session management function;
　　　　a means for receiving a Create Session Response to continue the mobility management function triggered UserPlane function entity relocation procedure.
A system comprising the session management function according to claim 12; and the mobility management function according to claim 15.