WO2019160546A1

WO2019160546A1 - Session mobility for packet data unit connectivity services

Info

Publication number: WO2019160546A1
Application number: PCT/US2018/018206
Authority: WO
Inventors: Colin Kahn; Thomas Theimer; Devaki Chandramouli; Laurent Thiebaut
Original assignee: Nokia Technologies Oy; Nokia Usa Inc.
Priority date: 2018-02-14
Filing date: 2018-02-14
Publication date: 2019-08-22

Abstract

A radio access network (RAN) transmits a request to a session management function, SMF (510). The request is to relocate a packet data unit (PDU) session anchor for a user equipment from a first user plane function, UPF (535), to a second UPF (540), without intervention by the SMF (510). The RAN receives authorization to relocate the PDU session anchor for the user equipment (555). The PDU session anchor is relocated from the first UPF (535) to the second UPF (540) concurrently with handover of the user equipment (555) from a first base station (525) to a second base station (530) associated with the second UPF (540) without intervention by the SMF (510).

Description

SESSION MOBILITY FOR PACKET DATA UNIT CONNECTIVITY SERVICES

BACKGROUND

The Third Generation Partnership Project (3GPP) defines protocols to support packet data unit (PDU) connectivity between user equipment and a packet data network (PDN). A PDU session is terminated by the user equipment and a user plane function (UPF) that anchors the PDU session and conveys the packets associated with the session. The packets are transported over the PDU session as Ethernet packets that include media access control (MAC) addresses, Internet protocol (IP) packets that include an IP address of the user equipment, or unstructured packets such as Bluetooth packets. The UPF monitors and processes the user plane to support functions including charging, lawful intercept, packet inspection, quality-of-service (QoS), and packet marking. User equipment set up a PDU connectivity service by sending a request (via a base station such as a next generation node B, or gNB) to a session management function (SMF), which selects a UPF to service the request. The SMF chooses the UPF based on information such as a data network that the user equipment would like to connect to, loading of the UPF, locations of the user equipment or the UPF, capabilities of the UPF, and the like.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure may be better understood, and its numerous features and advantages made apparent to those skilled in the art by referencing the accompanying drawings. The use of the same reference symbols in different drawings indicates similar or identical items.

FIG. 1 is a block diagram of a communication system that supports PDU session anchor relocation.

FIG. 2 is a block diagram of an NFV architecture according to some embodiments.

FIG. 3 illustrates a message flow that is used to perform a break-before-make PDU session anchor relocation.

FIG. 4 illustrates a message flow that is used to perform a make-before-break PDU session anchor relocation.

FIG. 5 is a block diagram of a communication system that implements autonomous PDU session anchor relocation concurrently with handover between base stations that are collocated with UPFs according to some embodiments.

FIG. 6 is a block diagram of a communication system that implements concurrent handover and autonomous PDU session anchor relocation between UPFs that are collocated with multiple base stations according to some embodiments. FIG. 7 is a first portion of a message flow that is used to perform autonomous PDU session anchor relocation concurrently with handover of the user equipment between collocated base stations and UPFs according to some embodiments.

FIG. 8 is a second portion of a message flow that is used to perform autonomous PDU session anchor relocation concurrently with handover of the user equipment between collocated base stations and UPFs according to some embodiments.

FIG. 9 is a block diagram of a communication system that implements a two-hop architecture for selfbackhaul according to some embodiments.

DETAILED DESCRIPTION

In some operational modes, a packet data unit (PDU) session anchor can be relocated from an initial user plane function (UPF) to a new UPF after initial assignment of the PDU session. For example, two of the three available session and service continuity (SSC) modes allow PDU session anchor relocation. A session management function (SMF) is able to select a different UPF to serve as the PDU session anchor for user equipment at any time. Reselection may be performed in response to a user equipment moving to a new location, offloading of data from the network at a local UPF, availability of local content or services at the new UPF, decreased congestion at the new UPF, or security or jurisdictional considerations. Anchor relocation is a break-before-make process in SSC mode 2. The network instructs the user equipment to release the PDU session anchor and subsequently request establishment of a new PDU session anchor in the same data network. The SMF is then able to select a different PDU session anchor (and UPF). Anchor relocation is a make- before-break process in SSC mode 3 because the new PDU session anchor is established before the previous connection is terminated. The IP address for IPv4 or IPv6 PDU sessions may not be preserved and the SMF may assign a new address corresponding to the new PDU session anchor. In either mode, conventional PDU session release and establishment procedures require exchanging approximately 14 and 17 messages, respectively.

The signaling overhead required for conventional PDU session anchor relocation has minimal impact upon conventional 3GPP networks because anchor relocation is a relatively infrequent operation. For example, a UPF that is deployed in a mobile network operator (MNO) or enterprise data center (DC) typically serves several gNBs dispersed throughout a relatively large geographic area associated with the MNO or DC. Anchor relocation for the PDU session may occur in response to a user equipment leaving a geographic area associated with one MNO or DC and entering a different geographic area associated with another MNO or DC. However, UPF functionality can also be moved closer to an edge of a network. For example, UPF functionality can be collocated with a single gNB or associated with a small number of gNBs within a relatively small geographic area. Collocating a UPF with one or more gNBs is used to support ultra-low latency cases by reducing transport delay, localized deployments to provide an access point with an ethernet interface or self-backhaul over multiple hops supported by corresponding self-contained PDU sessions. The frequency of PDU session anchor relocations increases when UPF functionality is collocated with one or more gNBs, which creates a corresponding increase in the volume of messages exchanged during PDU session anchor relocations. Furthermore, hand off between gNBs is conventionally performed independently of PDU session anchor relocation, which further adds to the volume of messages transported through the network when the user equipment hands off from one collocated gNB/UPF to another collocated gNB/UPF.

FIGs. 1-4 describe conventional PDU session anchor relocation. FIGs. 5-9 disclose techniques that significantly reduce overhead for handover of a user equipment and relocation of a PDU session anchor (relative to the conventional relocation process) by authorizing a radio access network (RAN) to relocate the PDU session anchor for the user equipment from a first user plane function (UPF) to a second UPF without intervention by a session management function (SMF). The PDU session anchor relocation is performed concurrently with the user equipment handing off from a first base station to a second base station. The SMF authorizes the RAN to relocate the PDU session anchor in response to the SMF receiving, prior to the user equipment handing off from the first base station to the second base station, an indication in a message that relocation is permitted to a second UPF that is collocated or associated with the second base station. In some embodiments, the first base station provides a message to the SMF indicating that the first base station is collocated or associated with the first UPF in response to the user equipment initiating establishment of the PDU session with the first UPF. The SMF responds with an acknowledgment that authorizes the RAN to select the first UPF as the PDU session anchor without further intervention by the SMF. The acknowledgment also authorizes the RAN to relocate the PDU session anchor. The RAN is therefore able to relocate the PDU session anchor from the first UPF to the second UPF concurrently with the user equipment handing off from the first base station to the second base station without further intervention by the SMF. If the second UPF is not collocated or associated with the second base station, the RAN can transmit a message requesting that the SMF select the second UPF and perform the PDU session anchor relocation, e.g., using the conventional PDU session anchor relocation message flows. Autonomous PDU session anchor relocation may be used to change relay nodes in a wireless self-backhaul network.

FIG. 1 is a block diagram of a communication system 100 that supports PDU session anchor relocation. The communication system 100 provides support for both mobile and fixed access. As used herein, the term“mobile access” refers to accessing a communication system (e.g., the communication system 100) over an air interface. Mobile access can therefore be referred to as wireless access, mobile communication, wireless communication, or other similar terms. The term “fixed access” refers to accessing to a communication system using a device that is physically connected to the communication system, e.g., accessing a communication system such as the communication system 100 via wires, optical fibers, and the like. Fixed access can therefore be referred to as wireline access, wired communication, or other similar terms. In some embodiments, the final leg of a fixed access connection can be provided by a wireless access point such as a Wi-Fi access point. The communication system 100 supports hybrid access that allows devices to concurrently access the communication system 100 using mobile access and fixed access. The communication system 100 includes a core network 105 that is accessible by either mobile or fixed devices using a common user plane access and a control plane that supports common authentication, authorization, and accounting (AAA) and policy control. As used herein, the phrase “user plane” refers to a portion of a routing or forwarding architecture that performs routing or forwarding of packets that arrive on an inbound interface. For example, the user plane can be implemented using routing tables to determine a path from the inbound interface through a forwarding fabric to the proper outgoing interface. The user plane can also be referred to as a data plane or a forwarding plane. As used herein, the phrase“control plane” refers to a portion of the routing architecture that transports messages to define network topology, authenticates devices, establishes user sessions, tracks device location, and authorizes access to data networks among other functions. For example, the control plane can be used to configure the routing tables that are used to forward packets on the user plane. Control plane logic can also be used to establish priority or quality-of- service for the packets or to identify packets that should be discarded.

The core network 105 includes an access and mobility management function (AMF) 110 that manages access control and mobility for devices in the communication system 100. The core network 105 also includes one or more session management functions (SMF) 115, 120 to set up and manage sessions in the communication system 100 according to network policies. An association between user equipment and a data network accessed through a UPF 130 or 125 can be represented as a protocol data unit (PDU) session that can be managed by one of the SMFs 115, 120. The PDU session supports data connectivity between user equipment and a data network. The core network 105 further includes an authentication service function (not shown in FIG. 1 in the interest of clarity) that stores subscriber authentication information for the user equipment that are connected to the core network 105. Information stored in the authentication service function is therefore used to authenticate user equipment before allowing the user equipment access to the communication system 100.

The core network 105 further includes one or more user plane functions (UPFs) 125, 130 that are deployed in the communication system 100 to provide services to users of the communication system 100. The UPFs 125, 130 are PDU session points of interconnect to data networks for service flows that are used to broadcast, multicast, or unicast packets, as discussed herein. The UPFs 125, 130 are configured to anchor PDU sessions for user equipment. The UPFs 125, 130 therefore convey packets associated with the PDU session. The UPFs 125, 130 are configured to monitor and process a user plane to support functions such as charging, lawful intercept, packet inspection, e.g., for application detection, quality-of-service (QoS), packet marking, and the like. The core network 105 also includes a unified data manager (not shown in FIG. 1 in the interest of clarity) that processes credentials, location management, subscription management, and the like. The unified data manager stores data including user subscription data, such as subscription identifiers, security credentials, access and mobility related subscription data, and session related subscription data.

Entities within the core network 105 are connected by various interfaces. In some embodiments, the interfaces between the entities in the core network 105 are implemented according to standards such as the Third Generation Partnership Project (3GPP) Fifth Generation (5G) network architecture. For example, the interfaces in a 5G system correspond to the N12, N8, N11 , N13, and N10 interfaces, among others. The communication system 100 defines other interfaces between entities that are disposed interior and exterior to the core network 105. The interfaces are not indicated by a reference numeral in the interest of clarity. The communications system 100 also defines service-based interfaces between entities interior to the core network 105. For example, the Namf interface exhibits services offered by AMF 1 10 and the Nsmf interface exhibits services offered by SMF 1 15, 120. The service-based interfaces are not indicated by a reference numeral in the interest of clarity.

Some embodiments of the core network 105 include other functionality such as a policy control function and a network repository function, which are not shown in FIG. 1 in the interest of clarity.

Some embodiments of the core network 105 are implemented using network function virtualization and software defined networking, as discussed herein. For example, different instances of the AMF 110, the SMFs 1 15, 120, and the UPFs 125, 130 can be instantiated in different network slices for different users or devices. Each PDU session is part of one network slice.

The core network 105 provides network access to user equipment 135 via mobile access. For example, the user equipment 135 can access the core network 105 via a base station 140 that is connected to the AMF 1 10 over a corresponding interface such as an N2 interface. The base station 165 can be implemented as a 5G NodeB (gNB) in accordance with standards defined by the 3GPP or a Terrestrial Broadcast 5G gNB in accordance with standards defined by the 3GPP. An interworking function (not shown in FIG. 1 of the interest of clarity), which can be referred to as a non-3GPP interworking function (N3IWF) is configured to modify or translate messages conveyed from a fixed access user equipment to the core network 105 so that the fixed access user equipment may access the core network 105 according to common standards or protocols from the perspective of the core network 105. The interworking function is also configured to modify or translate messages conveyed from the core network 105 to the fixed access user equipment so that the messages received by the fixed access user equipment conform to corresponding fixed access standards or protocols. The interworking function supports interfaces with the AMF 110 and the UPFs 125, 130.

The user equipment 135 sets up a PDU connectivity service by sending a request to the SMF 1 15 via the base station 140. The SMF 115 chooses the corresponding UPF 125 to service the request for the PDU connectivity service. Selection of the UPF 125 is based on network characteristics or parameters such as the data network that the user equipment 135 is attempting to connect to, loading of the UPFs 125, 130, a location of the user equipment 135, locations of the UPFs 125, 130, capabilities of the UPFs 125, 130, and the like. The PDU sessions maintained by the user equipment 135 are each associated with a session and service continuity (SSC) mode that determines the mobility properties of the PDU session anchors, e.g., the UPF 125, after initial assignment of the PDU session anchor. The SSC modes operate according to standards defined by the 3GPP Technical Specification 23.501 , which is incorporated herein by reference in its entirety. Two of the three available SSC modes allow PDU session anchors to be relocated, e.g., from the UPF 125 to the UPF 130, as indicated by the arrow 145. In SSC mode 2, the core network 105 instructs the user equipment 135 to release the PDU session anchor (e.g. the UPF 125) and subsequently request establishment of a new PDU session anchor in the core network 105. In response to the request, the SMF 1 15 or the SMF 120 selects a different PDU session anchor, e.g., the UPF 130. The SSC mode 2 therefore implements a break-before-make PDU session anchor relocation. In SSC mode 3, the user equipment 135 establishes a connection to a new PDU session anchor (e.g., the UPF 130) before a previous connection to the UPF 125 is terminated. For PDU sessions that are established according to IPv4 or IPv6, the IP address assigned to the UE by the old PDU session anchor may not be preserved and a new address may be assigned to the UE by the new PDU session anchor. However, ongoing transactions may be maintained on the old PDU session anchor for a transition time interval so that the ongoing transactions can be gracefully mitigated or terminated. The PDU session anchor relocation is performed according to standards defined by the 3GPP Technical Specification 23.502, Release 15 PDU, which is incorporated herein by reference in its entirety. In particular, PDU session anchor relocation is disclosed in section 4.3.5 of 3GPP TS 23.502.

The SMFs 1 15, 120 can choose a different UPF 125, 130 to serve as a PDU session anchor at any time and the SMFs 1 15, 120 are not required to wait for a request from the user equipment 135. Reasons or triggers for a PDU session anchor relocation include movement of the user equipment 135 to a location that is closer to a newly selected UPF. For example, the SMF 1 15 can trigger a PDU session anchor relocation in response to the user equipment 135 moving from a location that is proximate the UPF 125 to a location that is proximate the UPF 130. The PDU session anchor relocation can therefore shorten the data path, potentially improving latency or throughput. The SMF 150 also triggers a PDU session anchor relocation to offload data from the network to a local UPF. PDU session anchor relocation can also be triggered if local content or services are available through the new UPF, there is greater congestion at the current UPF than at the new UPF, security or jurisdictional considerations make the new UPF preferred or required, and the like.

FIG. 2 is a block diagram of an NFV architecture 200 according to some embodiments. The NFV architecture 200 is used to implement some embodiments of the communication system 100 shown in FIG. 1 . For example, instances of the AMF 1 10, SMFs 115, 120, and the UPFs 125, 130 can be instantiated as virtual functions in the NFV architecture 200. The NFV architecture 200 includes hardware resources 201 including computing hardware 202, storage hardware 203, and network hardware 204. The computing hardware 202 is implemented using one or more processors, the storage hardware 203 is implemented using one or more memories, and the network hardware 204 is implemented using one or more transceivers, transmitters, receivers, interfaces, and the like.

A virtualization layer 205 provides an abstract representation of the hardware resources 201 . The abstract representation supported by the virtualization layer 205 can be managed using a virtualized infrastructure manager 210, which is part of the NFV management and orchestration (M&O) module 215. Some embodiments of the manager 210 are configured to collect and forward performance measurements and events that may occur in the NFV architecture 200. For example, performance measurements may be forwarded to an orchestrator (ORCH) 217 implemented in the NFV M&O 215. The hardware resources 201 and the virtualization layer 205 may be used to implement virtual resources 220 including virtual computing resources 221 , virtual storage resources 222, and virtual networking resources 223.

Virtual networking functions (VNF1 , VNF2, VNF3) run over the NFV infrastructure (e.g., the hardware resources 201) and utilize the virtual resources 220. For example, the virtual networking functions (VNF1 , VNF2, VNF3) may be implemented using virtual machines supported by the virtual computing resources 221 , virtual memory supported by the virtual storage resources 222, or virtual networks supported by the virtual network resources 223. Element management systems (EMS1 , EMS2,

EMS3) are responsible for managing the virtual networking functions (VNF1 , VNF2, VNF3). For example, the element management systems (EMS1 , EMS2, EMS3) may be responsible for fault and performance management. In some embodiments, each of the virtual networking functions (VNF1 , VNF2, VNF3) is controlled by a corresponding VNF manager 225 that exchanges information and coordinates actions with the manager 210 or the orchestrator 217.

The NFV architecture 200 may include an operation support system (OSS)/business support system (BSS) 230. The OSS/BSS 230 deals with network management including fault management using the OSS functionality. The OSS/BSS 230 also deals with customer and product management using the BSS functionality. Some embodiments of the NFV architecture 200 use a set of descriptors 235 for storing descriptions of services, virtual network functions, or infrastructure supported by the NFV architecture 200. Information in the descriptors 235 may be updated or modified by the NFV M&O 215.

The NFV architecture 200 implements network slices that provide control plane functions or user plane functions, such as instances of the AMF 110, SMFs 1 15, 120, and the UPFs 125, 130 shown in FIG. 1 . A network slice is a complete logical network that provides communication services and network capabilities, which can vary from slice to slice. User equipment can concurrently access multiple slices that support multiple service flows between a core network and the user equipment. Some embodiments of user equipment provide Network Slice Selection Assistance Information (NSSAI) parameters to the network to assist in selection of a slice instance for the user equipment. A single NSSAI may lead to the selection of several slices. The NFV architecture 200 can also use device capabilities, subscription information and local operator policies to do the selection. An NSSAI is a collection of smaller components, Single-NSSAIs (S-NSSAI), which each include a Slice Service Type (SST) and possibly a Slice Differentiator (SD). Slice service type refers to an expected network behavior in terms of features and services (e.g., specialized for broadband or massive loT), while the slice differentiator can help selecting among several network slice instances of the same type, e.g. to isolate traffic related to different services into different slices. FIG. 3 illustrates a message flow 300 that is used to perform a break-before-make PDU session anchor relocation. The message flow 300 is implemented in some embodiments of the communication system 100 shown in FIG. 1. Initially, the user equipment (UE) has established a PDU session that is anchored by a first UPF (UPF1) and managed by a first SMF (SMF1). The user equipment therefore is able to exchange packets with the UPF1 via a radio access network (RAN), as indicated by the double-headed arrow 305.

At block 310, the SMF1 determines that there is a need to perform PDU session anchor relocation to a new UPF2. In the message flow 300, the PDU session anchor relocation to the new UPF2 also includes relocating to a new SMF2. At the message block 315, the UE exchanges messages with the UPF1 and the SMF1 to release the current PDU session that is anchored by the UPF1 . The message block 315 typically includes approximately 14 messages that are exchanged between the UE, RAN, UPF1 , SMF1 and other elements within the communication system 100 of Figure 1 . Once the PDU session is released by the UPF1 , the UE exchanges messages with the UPF2 and the SMF2 in message block 320 to establish a new PDU session that is anchored by the UPF2. The message block 320 typically includes approximately 17 messages that are exchanged between the UE, RAN, UPF2, SMF2 and other elements within the communication system 100 of Figure 1 . The UE is then able to exchange packets with the UPF2 via the RAN, as indicated by the double-headed arrow 325.

FIG. 4 illustrates a message flow 400 that is used to perform a make-before-break PDU session anchor relocation. The message flow 400 is implemented in some embodiments of the communication system 100 shown in FIG. 1. Initially, the user equipment (UE) has established a PDU session that is anchored by a first UPF (UPF1) and managed by a first SMF (SMF1). The user equipment therefore is able to exchange packets with the UPF1 via a radio access network (RAN), as indicated by the double-headed arrow 405.

At block 410, the SMF1 determines that there is a need to perform PDU session anchor relocation to a new UPF2. In the message flow 400, the PDU session anchor relocation to the new UPF2 also includes relocating to a new SMF2. The SMF1 transmits a message 415 to the AMF to inform the AMF of the impending PDU session anchor relocation. The AMF transmits an acknowledgment message 420 to acknowledge receipt of the message 415. In response to receiving the message 415, the AMF also transmits a PDU session modification command 425 to the UE, which initiates the PDU session anchor relocation in response to receiving the PDU session modification command 425.

At the message block 430, messages are exchanged between the UE, RAN, SMF2 and UPF2 to establish a new PDU session that is anchored by the UPF2. The message block 430 typically includes approximately 17 messages that are exchanged between the UE, RAN, UPF2, SMF2 and other elements within the communication system 100 of Figure 1 . The UE is then able to exchange packets with the UPF2 via the RAN, as indicated by the double-headed arrow 435. At the message block 440, the UE, RAN, SMF1 , UPF1 and other elements within the communication system 100 of Figure 1 exchange messages to release the current PDU session that is anchored by the UPF1 . The message block 440 typically includes approximately 14 messages that are exchanged between the UE, RAN, UPF1 , SMF1 and other elements within the communication system 100 of Figure 1.

The conventional message flows 300, 400 shown in FIGs. 3 and 4 include a significant amount of signaling to perform the PDU session anchor relocation. As discussed above, releasing a PDU session anchor and establishing a new PDU session anchor conventionally requires the exchange of more than 30 messages. Signaling with the UE is required for PDU sessions of type“IP” to update the UE’s IP address to reflect the new point of attachment (UPF), and for both Ethernet and IP PDU sessions, signaling is necessary within the core network for the SMF to release an old PDU session anchor and establish a new PDU session anchor. The impact of messages exchanged to perform PDU session anchor relocations is comparatively small when PDU session anchor relocations are relatively infrequent, as may be the case when the UPFs are deployed in a mobile network operator (MNO) or Enterprise Data Centers (DC) and serve many base stations, e.g., each UPF is the PDU session anchor for more than 15 base stations covering at least a local geographic area associated with the DC. A PDU session anchor relocation occurs in these cases only when a UE enters a region with closer proximity to a new DC or when a UE enters a facility/enterprise large enough to have its own DC where a local UPF is hosted. For these scenarios, the signaling overhead in the procedures currently specified by 3GPP for PDU session anchor relocation occurs infrequently and is minimally disruptive.

However, in other circumstances, such as when an Ethernet service is provided and each UPF is collocated with a base station or local to a few base stations, the signaling overhead in a conventional PDU session anchor relocation places a significant and largely unnecessary burden on the network. The large number of messages exchanged to perform PDU session anchor relocation increases the packet transport latency, which is contrary to the goal of integrating the UPF and base station functionality. One example of a collocated UPF/base station includes a UPF that is integrated within a base station to shorten the delay or latency required to transport packets to their destinations. Another example of a collocated UPF/base station includes enterprise, home, or other localized deployments that use sets of base stations that are collocated with corresponding UPFs to provide a Fifth

Generation (5G) access point including an Ethernet interface. Yet another example of collocated UPF/base stations include relay nodes in a self-backhaul network that are used to convey packets from a base station to a data center via multiple hops. Each hop is supported using a self-contained PDU session. At handover of a downstream relay node to a target upstream relay node, the PDU session anchor in the source upstream relay node is relocated to the target upstream relay node.

Furthermore, conventional PDU session anchor relocation is performed independently of handover of the user equipment from a source base station to a target base station even when the base stations include integrated collocated UPFs. For example, in SSC mode 2, after a user equipment has handed over from a source base station (and UPF) to a target base station (and UPF), the SMF releases a PDU session anchor in the source base station and establishes a new PDU session anchor in the target base station. During the interval between the handover and PDU session anchor relocation, packets are forwarded by the network from the target base station to the source base station that includes the UPF that anchors the PDU session, which add additional delay and is not practical for scenarios such as a multi-hop self-backhaul because forwarding the packets from the target base station to the source base station can require additional wireless backhaul hops. The packet flow is also disrupted between release of the PDU session anchor at the source base station/UPF and establishment of the PDU session anchor at the target base station/UPF. For another example, in SSC mode 3, just prior to a handover, the SMF establishes a new PDU session anchor in a potential target base station that is collocated with a target UPF. The SMF must therefore be aware of the target base station prior to the RAN becoming aware of the target base station, which is a difficult or impossible problem because the RAN makes the handover decisions based on measurements of the UE signal strength or quality and then instructs the other entities to perform the handover.

FIG. 5 is a block diagram of a communication system 500 that implements autonomous PDU session anchor relocation concurrently with handover between base stations that are collocated with UPFs according to some embodiments. The communication system 500 includes an AMF 505 and an SMF 510 that are implemented at a core network site 515. Although a single AMF 505 and a single SMF 510 are shown in FIG. 5, some embodiments of the communication system 500 include additional AMF or SMF entities that may be implemented at the core network site 515.

[0001] A RAN site 520 includes base stations 525, 530 that are integrated with corresponding UPFs 535, 540, as indicated by the dashed ovals 545, 550. The base stations 525, 530 and the UPFs 535, 540 are therefore collocated. Although the base stations 525, 530 and the UPFs 535, 540 are disposed at the same RAN site 520 in FIG. 5, some embodiments of the communication system 500 include base stations and collocated UPFs that are disposed in other RAN sites. The base stations 525, 530 and the UPFs 535, 540 support PDU sessions involving a user equipment 555. In some embodiments, no address is allocated to the user equipment 555. For example, Ethernet PDU sessions transmit packets that include media access control (MAC) information and do not require an IP address to identify the user equipment 555. For another example, PDU sessions that carry unstructured data such as Bluetooth data packets do not require an IP address to identify the user equipment 555. Although a single RAN site 520 shown in FIG. 5, some embodiments of the communication system 500 implement the entities 545, 550 in different RAN, which can operate according to different radio access technologies. For example, the collocated base station 525 and UPF 535 can operate according to 3GPP standards and the collocated base station 530 and UPF 540 can operate according to non-3GPP standards and communicate with the collocated base station 525 and UPF 535 via an interworking function.

The communication system 100 supports seamless handover between the base stations 525, 530 concurrently with autonomous PDU session anchor relocation between the collocated UPFs 535, 540. The concurrent handover and PDU session anchor relocation are supported for UPFs 535, 540 with and without a 3GPP-defined N4 interface between the UPFs 535, 540 and the SMF 510. The N4 interface is used if the UPFs 535, 540 supports services that are managed by the SMF 510 such as QoS policy, charging, lawful intercept, and the like. The N4 interface can be omitted if the UPFs 535, 540 are configured in another manner (e.g., by a management plane) or if the UPFs 535, 540 only provide ethernet forwarding.

Initially, the user equipment 555 transmits a message to the core network requesting establishment of a PDU session. For example, the user equipment 555 can send message over a 3GPP-defined N1 interface to the AMF 505 via the base station 525. In response to receiving the message, the base station 525 transmits an indication of the presence of a collocated UPF 535 and, optionally, an N4 interface address of the collocated UPF 535 to the core network. The SMF 510 is selected to manage the PDU session. However, the SMF 510 determines whether to select the collocated UPF 535 for a PDU session and whether to authorize autonomous PDU session anchor relocation by the RAN. For example, the indication of the presence of the collocated UPF 535 is used as an indication that the RAN is requesting authorization for autonomous PDU session anchor relocation. The SMF 510 determines whether the collocated UPF 535 is to be used as the PDU Session anchor for a PDU session and whether to authorize autonomous PDU session anchor relocation based on factors such as subscription data for the user equipment 555. The SMF 510 responds to the base station 525 with an acknowledgment message that indicates whether the RAN is authorized to use the collocated UPF 535 and whether the RAN may perform autonomous PDU session anchor relocation. If an N4 address of the UPF 535 was provided by the RAN, the SMF 510 may provide services to the UPF 535 via the N4 interface. In some embodiments, the authorization from the SMF 510 authorizes the RAN to select and configure the UPF 535 as the PDU session anchor without further intervention by the SMF 510. The user equipment 555 can subsequently be handed over from the source base station 525 to the target base station 530, as indicated by the arrow 560.

Concurrent handover and PDU session anchor relocation is selectively performed based on locations of the source and target base stations and UPFs. If the PDU session is anchored in a UPF that is collocated with the source base station, the RAN determines whether to autonomously perform the PDU session anchor relocation concurrent with handover of the user equipment 555 based on whether the target base station is collocated with a target UPF. For example, as shown in FIG. 5, at handover of the user equipment 555 from the base station 525 to the base station 530, the anchor for the PDU session can be concurrently relocated to a new UPF using autonomous PDU session anchor relocation by the RAN. The RAN automatically selects the UPF 540 for PDU session anchor relocation without intervention or involvement by the core network, e.g., the SMF 510. In some embodiments, the SMF 510 receives a path switch request message that includes an N4 address that identifies the UPF 540 as the new anchor for the PDU session. The path switch request message is not necessary if the SMF 510 does not need to be informed of the N4 address and the PDU sessions for the user equipment 555 are using the collocated UPF 540. However, if the target base station does not have a collocated UPF, the base station transmits a path switch request message that includes an indication that the SMF 510 is to select a target UPF for the PDU session anchor relocation. Thus, the path switch request triggers the PDU session anchor relocation that is performed by the SMF 510. In some cases, the user equipment 555 is handed over from a source base station that is not collocated with a UPF. Nevertheless, if the target base station is collocated with a UPF, e.g., if the user equipment 555 is handed over to the base station 530 that is collocated with the UPF 540, a path switch request transmitted by the target base station 530 includes information indicating presence of the collocated UPF 540. The path switch request can also include an N4 address of the collocated UPF 540. If the SMF 510 agrees that the collocated UPF 540 should be used to anchor the PDU session, the SMF 510 provides an acknowledgment to the path switch request message that includes information indicating that the RAN is authorized to autonomously perform PDU session anchor relocation to the collocated UPF 540 concurrently with the handover. If the SMF 510 does not agree that the collocated UPF 540 should be used to anchor the PDU session, the SMF 510 selects a non- collocated UPF and provides information identifying the non-collocated UPF to the RAN to initiate the PDU session anchor relocation.

FIG. 6 is a block diagram of a communication system 600 that implements concurrent handover and autonomous PDU session anchor relocation between UPFs that are collocated with multiple base stations according to some embodiments. The communication system 600 includes an AMF 605 and an SMF 610 that are implemented at a core network site 615. Although a single AMF 605 and a single SMF 610 are shown in FIG. 6, some embodiments of the communication system 600 include additional AMF or SMF entities that may be implemented at the core network site 615. A RAN site 620 includes base stations 625, 630 that are disposed locally to UPF 635, as indicated by the dashed oval 640, and base station 645, 650 that are disposed locally to UPF 655, as indicated by the dashed oval 660. The UPFs 635, 655 are able to anchor PDU sessions for a user equipment 665 that is served by the corresponding base stations 625, 630, 645, 650. The base stations 625, 630, 645, 650 are therefore collocated with the corresponding UPFs 635, 655, even though the local base stations 625, 630, 645, 650 are not necessarily integrated with the corresponding UPFs 635, 655. Concurrent handover and PDU session anchor relocation (as indicated by the arrow 670) is selectively performed for the user equipment 665 based on locations of the source and target base stations and UPFs in the communication system 600, as discussed herein.

FIG. 7 is a first portion 700 of a message flow that is used to perform autonomous PDU session anchor relocation concurrently with handover of the user equipment between collocated base stations and UPFs according to some embodiments. The first portion 700 of the message flow is implemented in some embodiments of the communication system 500 shown in FIG. 5 and the communication system 600 shown in FIG. 6. A user equipment (UE) has established a PDU session that is anchored by a first UPF collocated with a first base station (SOURCE). The user equipment exchanges data via the collocated first base station/UPF as indicated by the double-headed arrow 705.

In block 710, the AMF provides mobility control information to the collocated first base station/UPF.

The mobility control information is used to manage mobility of the user equipment, e.g., handoffs and PDU session anchor relocations. In block 715, the user equipment performs measurements of parameters such as signal strengths, signal quality, and the like, which can be used to determine when to hand off from the first base station. The user equipment reports the values of the performance measurements to the first base station. At block 720, the first base station determines whether to hand off the user equipment.

In response to determining that the user equipment is to be handed off from the first base station to the second base station, which is collocated with a second UPF (TARGET), the first base station transmits a handover request to the second base station. The handover request includes information requesting a PDU session anchor relocation from the collocated first UPF to the collocated second UPF. At block 730, the second base station determines whether it can handle the request for the concurrent PDU session anchor relocation. The second base station then transmits a message 735 that informs the first base station whether the second base station can or cannot handle the request.

At block 740, handover of the user equipment from the first base station to the second base station is triggered. A status transfer message 745 is transmitted to the second base station to indicate that the handover has been triggered. At block 750, the user equipment detaches from the first base station and synchronizes to the second base station. At block 755, the first base station identifies buffered or in-transit user data associated with the user equipment and then forwards this data to the second base station, as indicated by arrow 760. The user data received from the first base station is buffered by the second base station at block 765. Although the actions 740, 745, 750, 755, 760, 765 are depicted sequentially in FIG. 7, some embodiments perform the actions 740, 745, 750, 755, 760, 765 in other orders or concurrently. If the second base station accepted the request to perform the PDU session anchor relocation to the collocated second base station/UPF in block 730, the PDU session anchor relocation is performed concurrently with handover of the user equipment from the first base station to the second base station, e.g., concurrently with some or all of the actions 740, 745, 750, 755, 760,

765.

At block 770, the user equipment synchronizes to the second base station and completes the radio resource control (RRC) handover procedure. The user equipment then begins exchanging user data with the second base station, as indicated by the double-headed arrow 775. If the PDU session anchor relocation was performed concurrently with the handover of the user equipment, the second UPF is now the anchor for the PDU session with the user equipment. However, concurrent PDU session anchor relocation is not necessary to begin the exchange of user data with the second base station.

FIG. 8 is a second portion 800 of a message flow that is used to perform autonomous PDU session anchor relocation concurrently with handover of the user equipment between collocated base stations and UPFs according to some embodiments. The second portion 800 is implemented in some embodiments of the communication system 500 shown in FIG. 5 and the communication system 600 shown in FIG. 6. The second portion 800 is performed subsequently to the first portion 700 of the message flow shown in FIG. 7. The second base station (which is collocated with the second UPF) transmits a path switch request 805 to the AMF if the UE has or requires PDU sessions with non-collocated UPFs or if the SMF needs to be informed of the identity of the second, collocated UPF that is now the anchor of a PDU session.

If concurrent handover and PDU session anchor relocation were performed, e.g., as in the first portion 700 of the message flow illustrated in FIG. 7, the path switch request 805 informs the AMF of the identity of the second UPF that is now the anchor for the PDU session. For example, the path switch request 805 contains an N4 address of the second UPF if the collocated second base station/UPF supports an N4-capable UPF. If concurrent handover and PDU session anchor relocation was not performed, e.g., because the collocated second base station/UPF was not able to accept the request or because the second base station was not collocated with a second UPF, the path switch request 805 includes a request to have an SMF select another UPF for PDU session anchor relocation.

At block 810, the AMF interacts with the SMF and UPF to perform the requested path switch including related core network internal signaling and downlink path switches in zero or more non-collocated UPFs. The AMF triggers the SMF also (optionally) to perform a PDU session anchor relocation if the path switch request 805 included the request to have an SMF select one or more of the other UPFs for PDU session anchor relocation, e.g., in the event that the second base station was not able to accept the relocation request or was not collocated with another UPF. If a non-collocated UPF was used by the first base station, the UPF sends an end marker 815 to indicate a last packet that was transmitted to the user equipment via the first base station and the first base station transmits a message 820 including the end marker to the second base station. If the SMF selected one or more of the other UPFs as the new anchor for the PDU session, user data is conveyed between the second base station and a newly selected anchor UPF, as indicated by the double-headed arrow 825.

The AMF transmits an acknowledgment 830 of the path switch request to the second base station. In response to receiving the acknowledgment 830, the second base station transmits a UE context release message 835 to the first base station, which releases a previously stored context for the user equipment in response to receiving the message 835.

FIG. 9 is a block diagram of a communication system 900 that implements a two-hop architecture for self-backhaul according to some embodiments. The communication system 900 supports selfbackhaul from a first relay node 910 that serves user equipment 905. The first relay node 910 includes a distributed unit (DU) 91 1 and a relay node user equipment (RN-UE) 912. The distributed unit 91 1 is used to terminate one end of a tunnel that is also terminated by a corresponding central unit (CU) 915 that is implemented in a data center 920. The RN-UE 912 allows the first relay node 910 to form wireless connections with other relay nodes including a second relay node 925.

The second relay node 925 implements a RAN 926 and a first UPF 927 that is an anchor for a first PDU session with the RN-UE 912. The first PDU session is used to convey backhaul packets for the first relay node 910 through a first portion of the tunnel that is terminated by the central unit 915. The second relay node 925 also includes a relay node user equipment (RN-UE) 928, which allows the second relay node 925 to form wireless connections with other nodes including a donor node 930. In the illustrated embodiment, the donor node 930 is connected to the data center by a fiber connection such as a fiber connection to a central unit (CU) 935 that is associated with a second UPF 940. The second UPF 940 is an anchor for a second PDU session established by the RN-UE 928 in the second relay node 925. The second PDU session is used to convey backhaul packets through a second portion of the tunnel that is terminated by the central unit 915.

The data center 920 also includes a third UPF 945 that is an anchor for a third PDU session with the user equipment 905. Thus, the first PDU session is used to support a first hop in the two-hop architecture implemented in the communication system 900 and the second PDU session is used to support a second hop in the two-hop architecture. The first and the second PDU sessions transport a tunnel that is established between the central unit 915 and the distributed unit 91 1. The third PDU session between the user equipment 905 and the data center 920 provides the overarching connection between the user equipment 905 and the data center 920. Although a two-hop architecture is shown in FIG. 9, some embodiments of the communication system 900 include additional hops to form the self-backhaul connection.

The first relay node 910 or the second relay node 925 can be handed off to a different relay node, e.g., due to changing radiofrequency conditions or movement of the user equipment 905. In the illustrated embodiment, the first relay node 910 is handed off to a third relay node 950 that implements a RAN 951 , a UPF 952, and an RN-UE 953. In response to the first relay node 910 handing off to the third relay node 950, the PDU session anchor in the UPF 927 is relocated to the UPF 952. Relocation of the PDU session anchor is performed concurrently with handover of the third relay node 950, e.g., using some embodiments of the first portion 700 and the second portion 800 of the message flow shown in FIGs. 7 and 8, respectively.

Some embodiments of the concurrent handover and PDU session anchor relocation techniques disclosed herein have a number of advantages over conventional PDU session anchor relocation, which is performed independently of handover. For example, the number of messages transmitted to perform the handover and the PDU session anchor relocation is significantly reduced. The number of messages used in the conventional practice is estimated as 34 messages when using techniques disclosed in the 3GPP Technical Specification 23.502, which is incorporated herein by reference in its entirety. This estimate assumes that relocation is performed in SSC mode 3, in which a new PDU session is established and the prior PDU session is released. The messages are exchanged amongst the UE, RAN, AMF, and SMF after the handover is completed. Embodiments of the techniques disclosed herein require no new additional messages beyond the messages used for handover if the N4 interface of the collocated UPF is controlled by the SMF. Two fewer messages are required if the N4 interface is not implemented because the path switch request and acknowledgment messages can be eliminated from the handover sequence. Furthermore, handover and reselection of a collocated UPF occurs without core network involvement when there is no N4 interface. Combining handover and reselection of the collocated UPF reduces or eliminates service interruptions and avoids circuitous routing of packets from a target base station to a source base station in the interval between handover and the PDU session anchor relocation.

In embodiments in which a local UPF is not controlled by an SMF via an N4 interface, some policy control, charging, lawful intercept, and QoS policies may be restricted because these are not controlled on a per-session or per-user equipment basis. The RAN may have a local control interface towards the UPF, e.g., to update GTP tunneling endpoints for path switching in cases where the UPF and the RAN node are physically separate. The local interface can also be used to set PDU session characteristics that are known to the RAN.

In some embodiments, certain aspects of the techniques described above may implemented by one or more processors of a processing system executing software. The software comprises one or more sets of executable instructions stored or otherwise tangibly embodied on a non-transitory computer readable storage medium. The software can include the instructions and certain data that, when executed by the one or more processors, manipulate the one or more processors to perform one or more aspects of the techniques described above. The non-transitory computer readable storage medium can include, for example, a magnetic or optical disk storage device, solid state storage devices such as Flash memory, a cache, random access memory (RAM) or other non-volatile memory device or devices, and the like. The executable instructions stored on the non-transitory computer readable storage medium may be in source code, assembly language code, object code, or other instruction format that is interpreted or otherwise executable by one or more processors.

A computer readable storage medium may include any storage medium, or combination of storage media, accessible by a computer system during use to provide instructions and/or data to the computer system. Such storage media can include, but is not limited to, optical media (e.g., compact disc (CD), digital versatile disc (DVD), Blu-Ray disc), magnetic media (e.g., floppy disc, magnetic tape, or magnetic hard drive), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or Flash memory), or microelectromechanical systems (MEMS)-based storage media. The computer readable storage medium may be embedded in the computing system (e.g., system RAM or ROM), fixedly attached to the computing system (e.g., a magnetic hard drive), removably attached to the computing system (e.g., an optical disc or Universal Serial Bus (USB)-based Flash memory), or coupled to the computer system via a wired or wireless network (e.g., network accessible storage (NAS)).

Note that not all of the activities or elements described above in the general description are required, that a portion of a specific activity or device may not be required, and that one or more further activities may be performed, or elements included, in addition to those described. Still further, the order in which activities are listed are not necessarily the order in which they are performed. Also, the concepts have been described with reference to specific embodiments. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the present disclosure as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present disclosure.

Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any feature(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature of any or all the claims. Moreover, the particular embodiments disclosed above are illustrative only, as the disclosed subject matter may be modified and practiced in different but equivalent manners apparent to those skilled in the art having the benefit of the teachings herein. No limitations are intended to the details of construction or design herein shown, other than as described in the claims below. It is therefore evident that the particular embodiments disclosed above may be altered or modified and all such variations are considered within the scope of the disclosed subject matter. Accordingly, the protection sought herein is as set forth in the claims below.

Claims

WHAT IS CLAIMED IS:

1 . A method comprising:

transmitting, from a radio access network (RAN) to a session management function (SMF), a request to relocate a packet data unit (PDU) session anchor for a user equipment from a first user plane function (UPF) to a second UPF without intervention by the SMF;

receiving, at the RAN, authorization to relocate the PDU session anchor for the user

equipment; and

relocating the PDU session anchor from the first UPF to the second UPF concurrently with handover of the user equipment from a first base station to a second base station associated with the second UPF without intervention by the SMF.

2. The method of claim 1 , wherein transmitting the request to relocate a PDU session anchor for the user equipment comprises transmitting a message to the SMF indicating that the first base station is collocated with a first UPF that is available for assignment to the PDU session by the SMF in response to the user equipment initiating establishment of a PDU session.

3. The method of claim 2, wherein receiving the authorization to relocate a PDU session anchor for the user equipment comprises receiving authorization to select the first UPF as the PDU session anchor for the user equipment without further intervention by the SMF.

4. The method of claim 1 , wherein relocating a PDU session anchor from the first UPF to the second UPF concurrently with the handover comprises transmitting a handover request message including information requesting relocation of a PDU session anchor from the first UPF to the second UPF.

5. The method of claim 4, wherein relocating a PDU session anchor from the first UPF to the second UPF concurrently with the handover comprises receiving an acknowledgment of the handover request and the requested relocation of the PDU session anchor from the first UPF to the second UPF.

6. The method of claim 1 , wherein relocating a PDU session anchor from the first UPF to the second UPF comprises relocating the PDU session anchor to a second base station that is collocated with the second UPF.

7. The method of claim 1 , wherein relocating a PDU session anchor from the first UPF to the second UPF comprises relocating the PDU session anchor to a second base station that is associated with the second UPF.

8. The method of claim 1 , wherein a type of the PDU session is ethernet or unstructured data.

9. A radio access network (RAN) comprising: a transmitter configured to transmit, to a session management function (SMF), a request to relocate a packet data unit (PDU) session anchor for a user equipment from a first user plane function (UPF) to a second UPF without intervention by the SMF;

a receiver configured to receive authorization to relocate the PDU session anchor for the user equipment; and

a processor configured to relocate the PDU session anchor from the first UPF to the second UPF concurrently with handover of the user equipment from a first base station to a second base station associated with the second UPF without intervention by the SMF.

10. The RAN of claim 9, wherein the transmitter is configured to transmit a message to the SMF indicating that the first base station is collocated with a first UPF in response to the user equipment initiating establishment of a PDU session that is anchored by the first UPF.

1 1. The RAN of claim 10, wherein the receiver is configured to receive authorization to select the first UPF as a PDU session anchor for the user equipment without further intervention by the SMF.

12. The RAN of claim 9, wherein the transmitter is configured to transmit a handover request message including information requesting relocation of a PDU session anchor from the first UPF to the second UPF.

13. The RAN of claim 12, wherein the receiver is configured to receive an acknowledgment of the handover request and the requested relocation of a PDU session anchor from the first UPF to the second UPF.

14. The RAN of claim 9, wherein the processor is configured to relocate a PDU session anchor to a second base station that is collocated with the second UPF.

15. The RAN of claim 9, wherein the processor is configured to relocate a PDU session anchor to a second base station that is associated with the second UPF.

16. The RAN of claim 9, wherein a type of the PDU session is ethernet or unstructured data.

17. A first relay node (RN), comprising:

a transceiver configured to convey backhaul information for a user equipment that has

established a first packet data unit (PDU) session anchored by a first user plane function (UPF); and

a first RN user equipment (RN-UE) configured to establish a second PDU session anchored by a second UPF, wherein the second PDU session is used to convey the backhaul information,

wherein a session management function (SMF) has authorized relocation of a PDU session anchor for the first RN user equipment (RN-UE) from the second UPF to a third UPF without intervention by the SMF.

18. The first RN of claim 17, wherein the PDU session anchor for the second PDU session is relocated from the second UPF to the third UPF concurrently with the first RN-UE handing over from a first base station to a second base station.

19. The first RN of claim 17, wherein the second base station is collocated the third UPF.

20. The first RN of claim 19, wherein the second UPF is implemented in a second RN and the third

UPF is implemented in a third RN.

21. The first RN of claim 17, wherein the second PDU session is used to convey packets within a tunnel established between a distributed unit implemented in the first RN and a central unit implemented in a data center.

22. The first RN of claim 17, wherein the transceiver is configured to transmit a request to have the

SMF select the third UPF in response to the third UPF not being collocated with a base station.

23. The first RN of claim 17, wherein a type of the PDU session is ethernet or unstructured data.