WO2017202450A1

WO2017202450A1 - Mobility procedure with change of serving gateway

Info

Publication number: WO2017202450A1
Application number: PCT/EP2016/061662
Authority: WO
Inventors: Tony Olsson; Yong Yang
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2016-05-24
Filing date: 2016-05-24
Publication date: 2017-11-30

Abstract

The invention relates to a network gateway (nob) and a method of the network gateway in a communications network (10b) for handling a mobility procedure of a wireless communication device (101), WCD, including a change from an old serving gateway (108a) to a new serving gateway (108b) for serving the WCD (101). The method comprises: receiving (610, 710) from the new serving gateway (108b), a request message relating to mobility of the WCD (101) and relating to a PDN-connection of the WCD (101) and comprising a new id-information indicating an identity of the new serving gateway (108b); receiving (630, 720) thereafter from the old serving gateway (108a), a command message indicating an operation to be performed by the network gateway (nob) with respect to the PDN-connection of the WCD (101) and comprising an old id-information indicating an identity of the old serving gateway (108a); and rejecting (640, 730) the command message based on the new id-information and the old id-information.

Description

MOBILITY PROCEDURE WITH CHANGE OF SERVING GATEWAY

TECHNICAL FIELD

The invention relates to a network gateway and a method of the network gateway in a communications network for handling a mobility procedure of a wireless communication device (WCD) including a change from an old serving gateway to a new serving gateway for serving the WCD

BACKGROUND

Mobility procedures are one of the key functions in 3rd Generation

Partnership Project (3GPP) communication networks, e.g. such as the Long Term Evolution (LTE) and the Universal Mobile Telecommunications System (UMTS) and the Global System for Mobile Communications (GSM) or similar networks. The mobility procedures allow a wireless communication device (WCD) such as a User Equipment (UE) or similar to work such that e.g.

services can be delivered to the WCD regardless of its location within the coverage of the communication network.

A GSM or UMTS or LTE network or similar is, like most other cellular networks, basically a network of individual cells each covering a small geographical area. Each cell is associated with a radio access node (e.g. a base station or similar) for communicating wirelessly with a WCD located within the cell. By combining the coverage of all cells of a cellular network and their corresponding radio access nodes extends the coverage of the cellular network over a much wider area than a single cell.

In GSM EDGE Radio Access Network (GERAN) / UMTS Terrestrial Radio Access Network (UTRAN) a number of adjacent or neighbouring cells can be grouped into a so-called Routing Area (RA), and into a so-called Tracking Area (TA) in Evolved UTRAN (E-UTRAN). A mobility procedure in the form of a Tracking Area Update (TAU) or a Routing Area Update (RAU) is initiated when a UE enters a new TA or RA respectively. The mobility procedure may e.g. be initiated by moving UE. Another mobility procedure in cellular networks is the so-called handover procedure, which is the process of transferring an ongoing session such as a call or data session or similar from one radio access node to another radio access node without loss or interruption of service. Typically, handover occurs when a UE moves away from the area covered by one cell and entering the area covered by another cell, whereupon the ongoing session is transferred to the second cell in order to avoid service termination Handover may occur in other situations, e.g. handover from a first cell to second cell when the UE is located in an area overlapped by both cell and the capacity of the first cell is exhausted, or handover from a macro cell to a nearby micro cell to off load the macro cell etc.

The above mentioned and exemplifying mobility procedures TAU, RAU and handover are well known to those skilled in the art and they need no detailed description as such.

Figure la shows a schematic block diagram illustrating a known

communications network 10a wherein mobility procedures such as TAU, RAU and handover or similar may be performed. The wireless

communication network 10a comprises a Radio Access Network (RAN) 103 in turn comprising a RAN node 102 connected to a Mobility Management

Entity (MME) 105 and to a Serving Gateway (SGW) 108, in turn connected to the MME 105, and a Packet Data Network Gateway (PGW) 110, which in turn is connected to a Policy and Charging Rules Function (PCRF) 130. The RAN node 102 is a radio access node that interfaces with a wireless communication device (WCD).

The WCD, as exemplified by an UE 101 in figure la, is a device by which a subscriber accesses services offered by an operator's network and services outside operator's network to which the operators radio access network and core network provide access, e.g. access to the Internet (c.f. the Packet Data Network (PDN) 115 in figure la). The UE 101 in figure la may be any device, mobile or stationary, enabled to communicate in the communications network, for instance but not limited to e.g. user equipment, mobile phone, smart phone, sensors, meters, vehicles, household appliances, medical appliances, media players, cameras, Machine to Machine (M2M) device, Device to Device (D2D) device, Internet of Things (IoT) device or any type of consumer electronic, for instance but not limited to television, radio, lighting arrangements, tablet computer, laptop or Personal Computer (PC). The UE 101 may be portable, pocket storable, hand held, computer comprised, or vehicle mounted devices, enabled to communicate voice and/or data, via the radio access network, with another entity, such as another UE or a server. The RAN 103 in figure la is represented by an Evolved-Universal Terrestrial Radio Access Network (E-UTRAN) and the RAN node 102 in the E-UTRAN is represented by an evolved NodeB (eNode B, eNB). However, the RAN node may for example be a base station (in the GSM EDGE Radio Access Network (GERAN) 122), a NodeB (in the Universal Terrestrial Radio Access Network (UTRAN) 125), Radio Network Controller (RNC) (in the UTRAN 125) or any other element capable of wireless communication with the UE 101 or similar at one end and a Core Network (CN) serving the UE 101 at the other end. The reference point between the UE 101 and the E-UTRAN 103 may be referred to as Long Term Evolution-Uu (LTE-Uu). GSM is short for Global System for Mobile Communications and EDGE is short for Enhanced Data Rates for GSM Evolution.

The MME 105 is connected to the E-UTRAN 101 via the reference point Si- MME. The MME 105 is an element having functions such as e.g. Non-Access Stratum (NAS) signalling, Inter Core Network (CN) node signalling for mobility between 3rd Generation Partnership Project (3GPP) access networks, UE reachability, Tracking Area (TA) list management, PGW and SGW selection, MME selection for handover with MME change etc. S10 is the reference point between MMEs 105 for MME relocation and MME to MME information transfer.

The SGW 108 routes and forwards user data packets for the UE 101 over the Si-U interface, whilst also acting as the mobility anchor for the user plane of the UE 101 during inter-eNodeB handovers and as the anchor for mobility between LTE and other 3GPP technologies (terminating S4 interface and relaying the traffic between 2G/3G systems and the PGW 110a). For idle state UEs, the SGW terminates the downlink (DL) data path and triggers paging when DL data arrives for the UE 101 and further manages and stores UE contexts, e.g. parameters of the IP bearer service, network internal routing information. It also performs replication of the user traffic in case of lawful interception. The SGW communicates with the MME 105 via the S11 interface and with the PGW 110a via the S5 interface. Further, the SGW may

communicate with the UTRAN 125 and with the GERAN 122 via the S12 interface.

The PGW 110a is the gateway which terminates the SGi interface towards the Packet Data Network (PDN) 115. The PDN 115 is illustrated in figure 1 by the Operator's IP Services (e.g. IMS, PSS etc.). IMS is short for IP Multimedia Subsystem or IM Multimedia core network Subsystem and PSS is short for Packet Switched Streaming. If the UE 101 is accessing multiple PDNs, there may be more than one PGW 110a for that UE 101. Functions of the PGW 110a are e.g. providing connectivity from the UE 101 to external PDNs by being the point of exit and entry of traffic for the UE 101 with respect to the Core Network (CN) of the communications network 10a, performing policy enforcement, packet filtering for each user, charging support, lawful interception and packet screening etc. S5 is the reference point which provides user plane tunnelling and tunnel management between the SGW 108 and the PGW 110a. The SGSN 118 is responsible for the delivery of data packets from and to the UE's 101 within its geographical service area. One of the SGSN's 118 functions is to provide signaling for mobility between 2G/3G and E-UTRAN 103 access networks. 2G/3G access network are exemplified with GERAN 122 and UTRAN 125 in figure la. Some further functions of the SGSN 118 are to handle packet routing and transfer, mobility management (attach/detach and location management), logical link management, and authentication and charging functions etc. S3 is the interface between the SGSN 118 and the MME 105. S4 is a reference point between the SGSN 118 and the SGW 108. S12 is the reference point between the SGW 108 and the UTRAN 125. In some embodiments, the SGSN 118 and the MME 105 are co-located in one node. In this text, the term MME/SGSN will refer to any one of a standalone MME 105 or a standalone SGSN 108 or a combined MME 105 and SGSN 118 node. The SGSN 118 may also be referred to as a S4-SGSN. In the following, when the term MME is used, it refers to any of the standalone MME, a combined MME/SGSN or a combined MME/S4-SGSN. The term MME is used for the sake of simplicity.

The Home Subscriber Server (HSS) 128 is a subscriber server node similar to the GSM Home Location Register (HLR) and Authentication Centre (AuC). The HSS 128 comprises subscriber-related information (subscriber profiles), performs authentication and authorization of the user, and may provide information about the subscriber's location and IP information. The reference point S6a enables transfer of subscription and authentication data for authenticating/authorizing user access to the evolved system between the MME 105 and the HSS 128.

The PCRF 130 is a policy and charging control element. The PCRF 130 encompasses policy control decision and flow based charging control functionalities, it provides network control regarding the service data flow detection, gating, Quality of Service (QoS) and flow based charging etc. The PCRF 130 may be described as a functional entity which may be a standalone node or a function implemented in another node. The reference point Gx provides transfer of (QoS) policy and charging rules from the PCRF 130 to a Policy and Charging Enforcement Function (PCEF) in the PGW 110a or similar. Rx is the reference point which resides between the PCRF 130 and the Operator's IP Services represented by the PDN 115 in figure la. The Rx reference point is used to exchange application level session information between the PCRF 130 and one or more Application Functions (AF) (not shown). In some embodiments, a communications network may be divided into a RAN and a Core Network (CN). Thus, the UE 101 reaches the CN using a suitable RAN technology, for example the E-UTRAN 103 as exemplified in figure la. Note that figure la uses E-UTRAN 103 as an example, and that the UE 101 may reach the CN using any other suitable access technology, both 3GPP technologies and non-3GPP technologies.

As described above, the E-UTRAN 103 may comprise a RAN node such as e.g. an eNB 102. Using figure la as an example, the CN may comprise several or even all of the MME 105, the SGWs 108, the PGW 110a, the SGSN 118, the HSS 128 and the PCRF 130. The RAN and the CN may each comprises additional entities not shown in figure la. The CN may be a Packet Switched (PS) core network or a Circuit Switched (CS) core network. In other embodiments, the communications network 10a is not divided into a RAN and a CN. Instead, the communications network 10a may comprise a virtualized CN, and the control and user planes may be split. Terms such as Software Defined Network (SDN), Network Functions Virtualization (NFV) and Network Virtualization (NV) may be used in a scenario with a virtualized CN where the control and user planes are split. The user plane (sometimes known as the data plane, forwarding plane, carrier plane or bearer plane) carries the network user traffic and that the control plane carries signalling traffic. As the SDN may decouple the user and control planes, it removes the control plane from network hardware and implements it in software instead, which enables programmatic access and, as a result, makes network administration much more flexible. The control plane signalling may be routed to the virtualized CN and the user plane signalling is bypassed the virtualized CN. A virtualized CN may comprise virtual network services enabled by a virtualized MME (vMME), virtualized SGSN (vSGSN), virtualized PGW (vPGW), virtualized SGW (vSGW), virtualized Gateway GPRS Support Node (vGGSN), virtualized PCRF (vPCRF), virtualized Deep Packet Inspection (vDPI), vProbe, virtualized Evolved Packet Data Gateway (vePDG) and virtualized Trusted Wireless Local Area Network Access

Gateway (vTWAG) etc. It should be noted that the communication links in the communications systems seen in figures la may be of any suitable kind including either a wired or wireless link. The link may use any suitable protocol depending on type and level of layer (e.g. as indicated by the Open Systems Interconnection (OSI) model) as understood by the person skilled in the art.

As indicated above, the PGW iioa provides connectivity for the UE 101 to one or more PDNs, e.g. PDN 115. The UE 101 may have simultaneous connectivity with more than one PGW for accessing multiple PDNs.

Before proceeding it should be mentioned that PGW 110a provides PDN connectivity for the UE 101 by creating a PDN-connection to the PDN 115 served by the PGW 115. The PDN-connection may e.g. be requested by the UE 101, e.g. by sending a message to the PGW 110a. The PDN-connection is defined in the 3GPP specification TS 23.401 chapter 3 as an "association between a UE represented by one IPv4 address and/or one IPv6 prefix and a PDN represented by an APN". IPv4 is short for Internet Protocol version 4, IPv6 is short for Internet Protocol version 6 and APN is short for Access Point Name. The APN is used to identify the PDN 115 to which the PDN-connection is to be created for the UE 101. A PDN-connection consists of one default Evolved Packet System (EPS) Bearer and zero or more dedicated EPS

Bearers. One piece of UE can have a number of PDN-connections, and each PDN-connection can have one or more EPS Bearers. Thus, the EPS bearer is between the UE 101 and the PDN 115, and is used to transport IP (v4 and/or v6) packets to and from the UE 101 and PDN 115.

Now, during a mobility procedure (e.g. a TAU, RAU or handover as described above) wherein a session (e.g. a PDN-connection) is moved from an old SGW to a new SGW (or from an old MME/S4-SGSN to a new MME/S4-SGSN), the old SGW is allowed to send control signaling messages in the time-gap from when the session has moved to the new SGW until when the session is removed from the old SGW. The 3GPP protocol requires that the receiving node replies to the old SGW that sent the message. In many cases the receiving node will not be aware that the message was sent from an old SGW that no longer owns the session, and/or the receiving node may take inappropriate actions with respect to the old SGW and/or with respect to the session in question.

SUMMARY

An object of the present invention is to solve, or at least mitigate, the problem(s) associated with mobility procedures as those mentioned above, wherein the receiving node is not aware of that a received message was sent from an old node that no longer owns the session in question, and/or wherein the receiving node may have information about that the message was sent from an old node but nevertheless take inappropriate actions with respect to the old node and/or with respect to the session in question.

This object is attained in a first aspect of the present solution wherein a method of a network gateway node in a communications network for handling a mobility procedure of a wireless communication device (WCD), including a change from an old serving gateway to a new serving gateway for serving the WCD, the method comprises: receiving from the new serving gateway, a request message relating to mobility of the WCD and relating to a packet data network, PDN, connection of the WCD and comprising a new id-information indicating an identity of the new serving gateway; receiving thereafter from the old serving gateway, a command message indicating an operation to be performed by the network gateway node with respect to the PDN-connection of the WCD and comprising an old id-information indicating an identity of the old serving gateway; and rejecting the command message based on the new id-information and the old id-information. This object is attained in a second aspect of the present solution directed to a network gateway node operable in a communications network for handling a mobility procedure of a wireless communication device (WCD), including a change from an old serving gateway to a new serving gateway for serving the WCD, the node comprises comprises a processor and a memory, said memory containing instructions executable by said processor, whereby said network gateway is operative to: receive from the new serving gateway, a request message relating to mobility of the WCD and relating to a packet data network, PDN, connection of the WCD and comprising a new id-information indicating an identity of the new serving gateway; receive thereafter from the old serving gateway, a command message indicating an operation to be performed by the network gateway node with respect to the PDN-connection of the WCD and comprising an old id-information indicating an identity of the old serving gateway; and reject the command message based on the new id-information and the old id-information. The rejection of the command message by the network gateway means e.g. that the gateway will not respond to the command message by sending any request message or similar to the old serving gateway, which in turn will thus not respond back to the network gateway with any error message and the network gateway will thus not delete the above mentioned PDN-connection that is associated with the WCD, which in turn will reduce the risk of leaving the new serving gateway with a hanging PDN-connection.

These and further embodiments of the invention will be discussed in more detail in the detailed description hereinbelow with reference made to the accompanying drawings. Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a/an/the element, apparatus, component, means, step, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated. BRIEF DESCRIPTION OF THE DRAWINGS

The invention is now described, by way of example, with reference to the accompanying drawings, in which:

Figure la shows a schematic block diagram illustrating a known

communications network (10a) wherein mobility procedures may be performed;

Figure lb shows a schematic block diagram illustrating a communications network (lob), wherein embodiments of the present solution can be implemented;

Figure 2 shows a signalling diagram illustrating a mobility procedure and a known procedure for modifying the quality of service associated with a bearer;

Figure 3 shows a known example of addresses in GTP messages;

Figure 4 shows another known example of addresses in GTP messages; Figure 5 shows a signalling diagram illustrating a mobility procedure including a change of serving gateway from an old SGW to a new SGW;

Figure 6 shows a signalling diagram illustrating a mobility procedure according to an embodiment of the present solution, including a change of serving gateway from an old SGW to a new SGW;

Figure 7 shows a flowchart illustrating a method according to an

embodiment of the present solution;

Figure 8 illustrates a network gateway node according to an embodiment of the present solution.

DETAILED DESCRIPTION

The invention will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout the description.

Figure lb shows a schematic block diagram illustrating a communications network lob, wherein exemplifying embodiments the present solution can be implemented. The communications network lob corresponds to the communication network 10a previously described above with reference to figure la and the same reference numbers represent the same nodes.

However, it should be noted that communication network lob comprises a PGW nob and two or more SGWs, i.e. SGW 108a and SGW 108b. Here, the SGWs io8a, 108b and the PGW nob correspond to SGW 108 and PGW noa respectively as shown in figure la, except that at least SGW 108a and PGW nob are provided with additional functions, e.g. implemented in hardware and/or software, for executing actions relating to embodiments of the present solution.

Figure 2 shows a signalling diagram illustrating a known mobility procedure and a known modification procedure for modifying parameter(s) associated with a bearer. The Modify Bearer Request message in the mobility procedure of figure 2 is used in a number of procedures over General Packet Radio System (GPRS) Tunnelling Protocol (GTP) based interfaces, most notably mobility

procedures (e.g. TAU/RAU/Handover). In these procedures the MME 105 sends one or more Modify Bearer Request messages (one such message per PDN-connection) over the S11/S4 interface to the SGW 108. The MME 105 includes its Fully Qualified Tunnel Endpoint Identifier (F-TEID) in the Modify Bearer Request message. In turn, the SGW 108 forwards the received Modify Bearer Request message to the PGW 110a over the S5/S8 interface and includes its F-TEID in the forwarded message. The PGW 110a responds by returning a Modify Bearer Response message to the SGW 108. In turn the SGW 108 sends/forwards the Modify Bearer Response message to the MME 105. The Modify Bearer Request messages and the Modify Bearer Response message now mentioned are well known to those skilled in the art and they need no detailed description as such. Further details on these messages can e.g. be found in 3GPP specifications TS 23.401 and TS 29.274, see e.g. chapter 7.2.7-7.2.8.

The Modify Bearer Command message in the modification procedure of figure 2 is sent by the MME 105 to the SGW 108 over the S11 interface as part of a HSS Initiated Subscribed Modification procedure or similar, e.g. a procedure for modifying the parameter(s) associated with a bearer (e.g.

Quality of Service (QoS) parameters). In turn, the SGW 108 forwards the received Modify Bearer Command message to the PGW 110a over the S5/S8 interface. It may also be sent on the S4 interface by the SGSN 118 to the SGW and on the S5/S8 interface by the SGW to the PGW 110 as part of the HSS Initiated subscribed QoS modification procedure. The PGW 110a responds by returning an Update Bearer Request message to the SGW 108. The PGW 110a includes its F-TEID in the Modify Bearer Request message. In turn the SGW 108 sends/forwards the Update Bearer Request message to the MME 105. Then the MME 105 responds by returning an Update Bearer

Response message to the SGW 108, which forwards the received Update Bearer Response message to the PGW 110a. The Modify Bearer Command, the Update Bearer Request and the Update Bearer Response messages are well known to those skilled in the art and they need no detailed description as such. Further details on these messages can e.g. be found in 3GPP

specifications TS 23.401 and TS 29.274, see e.g. chapter 7.2.14-7.2.16. Before proceeding it should be clarified that the above mentioned Fully Qualified Tunnel Endpoint Identifier (F-TEID) may be a GTP version 2 Control plane (GTPv2-C) Information Element (IE), e.g. as defined in 3GPP specification TS 29.274 chapter 8.22. The GTPv2-C F-TEID contains a header, and the following fields:

· V4 (flag, one bit)

V6 (flag, one bit) Interface Type

TEID/GRE Key (four octets)

IPv4 address (present if flag V4=i, otherwise not present)

IPv6 address (present if flag V6=i, otherwise not present) The TEID and the IPv4 and IPv6 addresses relate to the sender/source node.

Before proceeding the attention is directed to Figure 3, which shows a known example of addresses in a GTP message. As can be seen in Figure 3 an initial or triggered GTP message may comprise three individual headers - an outer IP header, a UDP header, and a GTP header for GTP tunneling. The headers are followed by zero or more Information Elements (IEs), e.g.

GTPv2-C IEs relating to the Modify Bearer Request, the Modify Bearer Response, the Modify Bearer Command, the Update Bearer Request and the Update Bearer Response mentioned above or similar messages. Further details about initial and triggered messages etc can e.g. be found in 3GPP TS 29.274 chapter 4.2.5. The outer IP header comprises the Source IP (SIP) address of the source/sending node and the Destination IP (DIP) address of the receiving node. The receiving node that receives a GTP message may use the SIP address of the source node as the DIP address for sending back a GTP message to the source node. The receiving node then uses its own IP address as the SIP address, which actually corresponds to the DIP address in the previously received GTP message. This has been illustrated in figure 3 by the two arrows that cross each other in the middle of figure 3, schematically indicating that the SIP and DIP addresses in the received GTP message switch positions in a GTP message that is sent back by the receiving node to the source/sending node.

As further specified in Figure 4, the SIP address in the outer IP header may differ from the IPv4 and/or IPv6 address in the sender/source F-TEID Information Element (IE) of a GTP message. Figure 5 shows a signalling diagram illustrating a mobility procedure for a UE 101 including a change of serving gateway for the UE 101 from the old SGW 108 to the new SGW 108b. Preferably the old SGW 108 was already registered at the PGW 110a for serving the UE 101 before initiation of the present mobility procedure causing a change from the old SGW 108 to the new SGW 108b for serving the UE 101. For example, the old SGW 108 may have been previously registered at the PGW 110a by means of a previous "Attach" procedure or a previous mobility procedure (TAU/RAU/Handover), e.g. comprising a Modify Bearer Request or similar previously sent by the old SGW 108 to the PGW 110a.

Now, in the present mobility procedure (e.g. TAU/RAU/Handover) it is preferred that the MME 105 sends a Modify Bearer Request message to the new SGW 108b (not shown in figure 5), whereby the new SGW 108b forwards the received Modify Bearer Request message to the PGW 110a and includes its sender/source F-TEID in the message. The Modify Bearer

Request message relates to a PDN-connection that is associated with the UE 101 and that comprises one default bearer and zero or more dedicated bearers. The PGW 110a responds by returning a Modify Bearer Response message to the new SGW 108b. The sending and forwarding of the Modify Bearer Request by the MME 105 and the new SGW 108b respectively and the response by the PGW 110 corresponds to the sending, forwarding and response described above with reference to figure 2. A consequence of the mobility procedure is that the old SGW 108 shall not serve the UE 101, at least not for the PDN-connection that is related to the Modify Bearer

Request. This is a task for the new SGW 108b.

Next, before the present mobility procedure is completed, a late Modify Bearer Command message arrives at the PGW 110a from the old SGW 108. The late Modify Bearer Command message corresponds to the Modify Bearer Command described above with reference to figure 2. The late Modify Bearer Command relates to the same PDN-connection as the previous Modify Bearer Request.

According to the current 3GPP protocol it is required that the PGW 110a replies to the received Modify Bearer Command by sending an Update Bearer Request message to the old SGW 108 that sent the Modify Bearer Command message. Further, according to the current 3GPP standard (3GPP TS 29.274), the Modify Bearer Command does not comprise any

sender/source TEID and the PGW 110a will not detect that the Modify Bearer Command was sent from the old SGW 108 that shall not serve the UE 101. The PGW 110a will therefore unknowingly reply by sending an Update Bearer Request to the SIP address in the outer IP header of the GTP message that carried the Modify Bearer Command previously received from the old SGW 108 (3GPP TS 29.274 chapter 4.2.2 'IP header and IP addresses', also see figures 3-4 discussed above). In other words, the PGW 110a will not send the Update Bearer Request message to the new SGW 108b that will serve the UE 101 but to the old SGW 108 that will not serve the UE 101, at least not for the PDN-connection that is related to the Modify Bearer Command and the Update Bearer Request.

Furthermore, according to the current 3GPP protocol, the TEID of the Update Bearer Request message shall be copied from the TEID in the F-TEID that was most recently received by the PGW 110 from a SGW (see e.g. 3GPP TS 29.274 chapter 4.1 GTP Tunnel). In the example in figure 5 this is the F-TEID that was received in the Modify Bearer Request from the new SGW 108b, since, as noted above, the later Modify Bearer Command message from the old SGW 108 does not carry any F-TEID and thus no TEID. This has been illustrated in figure 5 by an arrow from the F-TEID in the Modify Bearer Request message to the TEID in the Update Bearer Request message. Thus, the PGW 110a will for the same message - i.e. the Update Bearer Response - use the IP address to the old SGW 108 and the TEID of the new SGW 108b. This is a consequence of how the 3GPP GTPv2-C standard is currently written. However, since the Update Bearer Request message is addressed to a TEID that relates to the new SGW 108b and therefore is unknown to the old SGW 108(a) it follows that the old SGW 108a will reject the Update Bearer Request message, e.g. by sending to the PGW 110a an Update Bearer Response message with Cause "Context Not Found" (3GPP TS 29.274 chapter 8.4), and the GTP-C Header TEID set to "o" (3GPP TS 29.274 chapter 5.5.2). Upon receiving the Update Bearer Response with Cause "Context Not Found" and GTP-C Header TEID set to "o" the PGW 110a deletes the PDN-connection.

The new SGW 108b, to which the PDN-connection had been moved, may not be informed that the PGW 110 has deleted the PDN-connection. The new SGW 108b may thereby be left with a hanging PDN-connection. The same condition applies to the MME/S4-SGSN.

In other words, in the scenario of figure 5, the PGW 110a will not only send the Update Bearer Request message to the old SGW 108 that shall not serve the UE 101, but the old SGW 108 will also reject the Update Bearer Request causing the PGW 110a to delete the PDN-connection that is related to the Update Bearer Request, which in turn will leave the new SGW 108b with a hanging PDN-connection.

This scenario and particularly the late Modify Bearer Command message from the old SGW 108 to the PGW 110, occurs in the time-gap from the time when the session in question has moved to the new SGW 108b until the time when the session is removed from the old SGW 108. Particularly it may occur in Inter- RAT mobility procedures, where Quality of Service (QoS) parameters need to be modified as the UE moves from one type of Radio Access

Technology (RAT) to another, particularly if the UE 101 moves fast.

Figure 6 shows a signalling diagram illustrating a mobility procedure for a UE 101 according to an embodiment of the present solution, including a change of serving gateway for serving the UE 101 from an old SGW 108a to a new SGW 108b. Preferably the old SGW 108a was already registered at the PGW 110b for serving the UE 101 before initiation of the present mobility procedure causing a change from the old SGW 108a to the new SGW 108b for serving the UE 101. For example, the old SGW 108a may have been previously registered at the PGW 110b by means of a previous "Attach" procedure or a previous mobility procedure (TAU/RAU/Handover), e.g. comprising a Modify Bearer Request or similar previously sent by the old SGW 108a to the PGW 110b.

In action 610 of the present mobility procedure it is preferred that the new SGW 108b sends a Modify Bearer Request message to the PGW 110b, e.g. as described above with reference to figure 2. Indeed, the Modify Bearer

Request message may have been previously sent by the MME 105 to the new SGW 108b and now merely forwarded by the new SGW 108b to the PGW 110b, but this has not been explicitly shown in figure 6.

As indicated in figure 6, the new SGW 108b includes its sender/source F-TEID in the Modify Bearer Request sent to the PGW 110b. The F-TEID corresponds to new id-information that indicates the identity of the new SGW 108b to the PGW 110b. The Modify Bearer Request relates to a PDN— connection that is associated with the UE 101.

In action 620 it is preferred that the PGW 110 responds to the received Modify Bearer by returning a Modify Bearer Response message to the new SGW 108b.

In action 630, occurring after action 610 but before the present mobility procedure is completed; a late Modify Bearer Command message is received by the PGW 110b from the old SGW 108a. Alternatively, the command message may be a Bearer Resource Command message or a Delete Bearer Command message or some other similar command message. It is preferred that the command message and the above mentioned Modify Bearer Request message relates to the same PDN-connection that is associated with the UE 101. l8

The command message indicates an operation to be performed by the PGW 110b with respect to the PDN-connection associated with the UE 101. For example, indicates that the PGW 110b should send to the old SGW 108a a request message relating to the PDN-connection of the UE 101, e.g. an Update Bearer Request as previously discussed above with reference to figure 5.

As indicated in figure 6, the command message also comprises the F-TEID or at least the TEID of the old SGW 108a. The F-TEID/TEID corresponds to old id-information that indicates the identity of the old SGW 108a. Alternatively, the old id-information may be defined in the Modify Bearer Command message or similar command message as a Private Extension information element (3GPP TS 29.274 chapter 8.67) or similar. The same applies for Delete Bearer Command message and Bearer Resource Command message and similar. In action 640, the PGW 110b rejects the command message received in action 630 when the old id-information (e.g. the TEID of the old SGW 108a) received in the Modify Bearer Command is different from the new

id-information (e.g. the TEID of the new SGW 108b) received in the Modify Bearer Request. For example, there may be two different TEIDs, as is the case in the scenario illustrated in figure 6. To determine that a rejection is suitable the PGW 110b may for example compare the old id-information with the new id-information. The rejection of the command message results in that the PGW 110b will not carry out any operation that was indicated by the command message. For example, the PGW 110b will not carry out the operation of sending a request message (e.g. such as the Update Bearer Request shown in figure 5) to the old SGW 108a and particularly not a request message or a similar message that relates to the above mentioned PDN-connection associated with the UE 101.

Thus, the rejection by the PGW 110b means e.g. that the PGW 110b will not respond to the Modify Bearer Command or similar command message by sending any Update Bearer Request or similar to the old SGW 108a, which in turn will thus not respond back to the PGW nob with any error message and the PGW nob will thus not delete the above mentioned PDN-connection that is associated with the UE 101, which in turn will reduce the risk of leaving the new SGW 108b with a hanging PDN-connection. The present embodiment may in some instances end by the rejecting action 640. However, some embodiments may proceed with action 650 below.

Before proceeding it should be clarified that there may indeed be situations when a Modify Bearer Command message received by the PGW 110b from SGW 108a may be accepted, whereupon the PGW 110b may reply back to the SGW 108a with an Update Bearer Request message or similar (not indicated in figure 6). This may for example be the case where the mobility procedure does not involve any change of SGWs.

In action 650, the PGW 110 may send an error message to the old SGW 108a. The error message may e.g. indicate that UE 101 is not served by the old SGW 108a and/or that the operation indicated by the command message received in action 630 has not been performed by the PGW 110. For example, the error message may be a Modify Bearer Failure message, e.g. comprising a failure cause "invalid peer" and/or a failure code, e.g. cause value 109

(decimal), see e.g. 3GPP TS 29.274 chapter 8.4.

Figure 7 shows a flowchart illustrating a method according to an

embodiment of the present solution. The method is performed in the PGW 110b operating in the communications network 10b for handling a mobility procedure of the UE 101 or similar, which mobility procedure includes a change from the old SGW 108a to the new SGW 108b for serving the UE 101.

In a first step 710 the PGW 110b receives from the new SGW 108b, a request message relating to mobility of the UE 101 and relating to a

PDN-connection of the UE 101 and comprising a new id-information (e.g. a first F-TEID) indicating the identity of the new SGW 108b. The first step corresponds to action 610 described above.

In a second step 720 the PGW nob thereafter receives from the old SGW 108a a command message indicating an operation to be performed by the PGW 110b with respect to the PDN-connection of the UE 101, and comprising an old id-information (e.g. a second F-TEID) indicating the identity of the old SGW 108a. The second step corresponds to action 620 described above.

In a third step 730 the PGW 110b rejects the command message based on the new id-information and the old id-information. The third step

corresponds to action 640 described above.

In a fourth step 740 the PGW 110b may send an error message to the old SGW 108a. The fourth step corresponds to action 650 described above.

Figure 8 illustrates a network gateway node 110b for handling a mobility procedure of a UE 101, including a change from an old serving gateway 108a to a new serving gateway 108b for serving the UE 101 according to

embodiments described herein. The network gateway node 110b comprises a processor 82; and a memory 84, said memory 84 contains instructions executable by said processor 82, whereby said network gateway 100b is operative to:

- receive, from the new serving gateway 108b, a request message relating to mobility of the UE 101 and relating to a PDN-connection of the UE 101 and comprising a new id-information indicating an identity of the new serving gateway 108b;

- receive thereafter from the old serving gateway 108a, a command message indicating an operation to be performed by the network gateway node 110 with respect to the PDN-connection of the UE 101 and comprising an old id-information indicating an identity of the old serving gateway 108a; - reject the command message based on the new id-information and the second old id-information.

Optionally, the network gateway node nob may be operative to send an error message to the old serving gateway 108b when the old id-information is different from the new id-information.

Some embodiments described above may be summarised in the following manner:

A first embodiment is directed to a method of a network gateway in a communications network for handling a mobility procedure of a wireless communication device (WCD), including a change from an old serving gateway to a new serving gateway for serving the WCD, the method comprises:

receiving from the new serving gateway, a request message relating to mobility of the WCD and relating to a PDN-connection of the WCD and comprising a new id-information indicating an identity of the new serving gateway,

- receiving thereafter from the old serving gateway, a command message indicating an operation to be performed by the network gateway with respect to the PDN-connection of the WCD and comprising an old id-information indicating an identity of the old serving gateway, rejecting the command message based on the new id-information and the old id-information.

The above mentioned request message may be a modify bearer request message.

The command message may indicate that the operation to be performed by the network gateway comprises sending to the old serving gateway a request message relating to the PDN-connection of the WCD. Here, the request message may be one of: an Update Bearer Request, a Create Bearer Request, or a Delete Bearer Request.

The command message may be one of: a Modify Bearer Command, a Bearer Resource Command, or a Delete Bearer Command. The rejecting may comprise rejecting the command message when the old id-information is different from the new id-information.

The rejecting may comprise sending an error message to the old serving gateway. The error message may indicate at least one of: that the WCD is not served by the old serving gateway, or that the operation indicated by the received command message has not been performed by the network gateway.

The network gateway is a PGW, and the old serving gateway is a S4-SGSN or a SGW, and the new serving gateway is a S4-SGSN or a SGW.

The new id-information may indicate a first TEID associated with the new serving gateway, and the old id-information may indicate a second TEID associated with the old serving gateway.

Some other embodiments described above may be summarised in the following manner: A second embodiment is directed to a network gateway operable in a communications network for handling a mobility procedure of a wireless communication device (WCD), including a change from an old serving gateway to a new serving gateway for serving the WCD, the network gateway comprises a processor and a memory, said memory containing instructions executable by said processor, whereby said network gateway is operative to: receive from the new serving gateway, a request message relating to mobility of the WCD and relating to a PDN-connection of the WCD and comprising a new id-information indicating an identity of the new serving gateway, receive thereafter from the old serving gateway, a command message indicating an operation to be performed by the network gateway with respect to the PDN-connection of the WCD and comprising an old id-information indicating an identity of the old serving gateway, and - reject the command message based on the new id-information and the old id-information

The above mentioned request message may be a modify bearer request message. The command message may indicate that the operation to be performed by the network gateway comprises sending to the old serving gateway a request message relating to the PDN-connection of the WCD. Here, the request message may be one of: an Update Bearer Request, a Create Bearer Request, or a Delete Bearer Request. The command message may be one of: a Modify Bearer Command, a Bearer Resource Command, or a Delete Bearer Command.

The reject may comprise a reject of the command message when the old id-information is different from the new id-information.

The reject may comprise sending an error message to the old serving gateway.

The error message may indicate at least one of:

- that the WCD is not served by the old serving gateway, or

- that the operation indicated by the received command message has not been performed by the network gateway. The network gateway may be PGW and the old serving gateway may be a S4-SGSN or a SGW, and the new serving gateway may be a S4-SGSN or a SGW. The new id-information may indicate a first TEID associated with the new serving gateway, and the old id-information may indicate a second TEID associated with the old serving gateway.

The invention has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims

Claims

1. A method of a network gateway (110b) in a communications network (10b) for handling a mobility procedure of a wireless communication device (101), WCD, including a change from an old serving gateway (108a) to a new serving gateway (108b) for serving the WCD (101), the method comprises: - receiving (610, 710) from the new serving gateway (108b), a request

message relating to mobility of the WCD (101) and relating to a packet data network, PDN, connection of the WCD (101) and comprising a new id-information indicating an identity of the new serving gateway (108b), - receiving (630, 720) thereafter from the old serving gateway (108a), a command message indicating an operation to be performed by the network gateway (110b) with respect to the PDN-connection of the WCD (101) and comprising an old id-information indicating an identity of the old serving gateway (108a),

- rejecting (640, 730) the command message based on the new

id-information and the old id-information.

2. The method according to claim 1, wherein the request message is a modify bearer request message.

3. The method according to any one of claim 1 or 2, wherein the command message indicates that the operation to be performed by the network gateway (110b) comprises sending to the old serving gateway (108a) a request message relating to the PDN-connection of the WCD (101).

4. The method according to claim 3, wherein the request message is one of: an Update Bearer Request, a Create Bearer Request, or a Delete Bearer Request.

5. The method according to any one of claim 1, 2, 3 or 4, wherein the command message is one of: a Modify Bearer Command, a Bearer Resource Command, or a Delete Bearer Command.

6. The method according to any one of claim 1, 2, 3, 4 or 5, wherein the rejecting comprises rejecting the command message when the old

id-information is different from the new id-information.

7. The method according to any one of claim 1, 2, 3, 4, 5 or 6, wherein the rejecting comprises sending (650, 740) an error message to the old serving gateway (108a).

8. The method according to claim 7, wherein the error message indicates at least one of:

- that the WCD (101) is not served by the old serving gateway (108a), or

- that the operation indicated by the received command message has not been performed by the network gateway (110b).

9. The method according to any one of claim 1, 2, 3, 4, 5, 6 or 7, wherein the network gateway (110b) is a packet data network gateway, PGW, and the old serving gateway (108a) is a S4 Serving GPRS Support Node, S4-SGSN, or a serving gateway, SGW, and the new serving gateway (108b) is a S4-SGSN or a SGW.

10. The method according to any one of claim 1, 2, 3, 4, 5, 6, 7, 8 or 9, wherein the new id-information indicates a first tunnel endpoint identifier, TEID, associated with the new serving gateway (108b), and the old

id-information indicates a second TEID associated with the old serving gateway (108a).

11. The method according to any one of claim 1, 2, 3, 4, 5, 6, 7, 8, 9 or 10, wherein the command message is received before the mobility procedure is completed.

12. A network gateway (110b) operable in a communications network (10b) for handling a mobility procedure of a wireless communication device (101), WCD, including a change from an old serving gateway (108a) to a new serving gateway (108b) for serving the WCD (101), the network gateway (110b) comprises a processor (82) and a memory (84), said memory (84) containing instructions executable by said processor (82), whereby said network gateway (100b) is operative to:

- receive from the new serving gateway (108b), a request message relating to mobility of the WCD (101) and relating to a packet data network, PDN, connection of the WCD (101) and comprising a new id-information indicating an identity of the new serving gateway (108b),

- receive thereafter from the old serving gateway (108a), a command

message indicating an operation to be performed by the network gateway (110b) with respect to the PDN-connection of the WCD (101) and comprising an old id-information indicating an identity of the old serving gateway (108a), and

- reject the command message based on the new id-information and the old id-information.

13. The network gateway (110b) according to claim 12, wherein the request message is a modify bearer request message.

14. The network gateway (110b) according to any one of claim 12 or 13, wherein the command message indicates that the operation to be performed by the network gateway (110) comprises sending to the old serving gateway (108a) a request message relating to the PDN-connection of the WCD (101).

15. The network gateway (110b) according to claim 14, wherein the request message is one of: an Update Bearer Request, a Create Bearer Request, or a Delete Bearer Request.

16. The network gateway (110b) according to any one of claim 12, 13, 14 or 15, wherein the command message is one of: a Modify Bearer Command, a Bearer Resource Command, or a Delete Bearer Command.

17. The network gateway (110b) according to any one of claim 12, 13, 14, 15 or 16, wherein the reject comprises a reject of the command message when the old id-information is different from the new id-information.

18. The network gateway (110b) according to any one of claim 12, 13, 14, 15, 16 or 16, wherein the reject comprises sending (650, 740) an error message to the old serving gateway (108a).

19. The network gateway (110b) according to claim 18, wherein the error message indicates at least one of:

- that the WCD (101) is not served by the old serving gateway (108a), or - that the operation indicated by the received command message has not been performed by the network gateway (110b).

20. The network gateway (110b) according to any one of claim 12, 13, 14, 15, 16, 17, 18 or 19, wherein the network gateway (110b) is a packet data network gateway, PGW, and the old serving gateway (108a) is a S4 Serving GPRS Support Node, S4-SGSN, or a serving gateway, SGW, and the new serving gateway (108b) is a S4-SGSN or a SGW.

21. The network gateway (110b) according to any one of claim 12, 13, 14, 15, 16, 17, 18, 19 or 20, wherein the new id-information indicates a first tunnel endpoint identifier, TEID, associated with the new serving gateway (108b), and the old id-information indicates a second TEID associated with the old serving gateway (108a).

22. The network gateway (110b) according to any one of claim 12, 13, 14, 15, 16, 17, 18, 19, 20 or 21, wherein the command message is received before the mobility procedure is completed.