System and method for application-friendly protocol data unit session management

Abstract

The present application provides a system and method for application-friendly protocol data unit session management, which is a method for exchanging user plane (UP) management information between an application function (AF) supporting one or more applications and a slice management function (SMF) configured to manage service flows in a given network slice. The exchange of UP management information can be initiated from the AF or SMF. In the case where the information exchange is initiated by the AF, the UP management information provided by the AF may include the service requirements of the applications supported by the AF. In the case where the information exchange is initiated by the SMF, the UP management information provided by the SM may include operator policy information or events, and the AF may respond to the service requirement information of the applications supported by the AF.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 442,857, filed on January 5, 2017, entitled “Protocol Data Unit (PDU) Session Management System and Method”; U.S. Provisional Patent Application No. 62 / 455,368, filed on February 6, 2017, entitled “Protocol Data Unit (PDU) Session Management System and Method”; U.S. Provisional Patent Application No. 62 / 459,985, filed on February 16, 2017, entitled “Protocol Data Unit (PDU) Session Management System and Method”; U.S. Provisional Patent Application No. 62 / 473,274, filed on March 17, 2017, entitled “Protocol Data Unit (PDU) Session Management System and Method”; U.S. Provisional Patent Application No. 62 / 477, filed on March 27, 2017, entitled “Protocol Data Unit (PDU) Session Management System and Method” 384, U.S. Provisional Application No. 62 / 487,960, filed on April 20, 2017; U.S. Provisional Application No. 62 / 491,529, filed on April 28, 2017, entitled “System and Method for Application-Friendly Protocol Data Unit (PDU) Session Management”; U.S. Provisional Application No. 62 / 522,040, filed on June 19, 2017, entitled “System and Method for Application-Friendly Protocol Data Unit (PDU) Session Management”, U.S. Patent Application Serial No. 15 / 832,103, filed on December 5, 2017, and Chinese Patent Application No. CN201880006110.5, filed on January 5, 2018 with the State Intellectual Property Office of China, the entire contents of each of which are incorporated herein by reference. Technical Field

[0003] The present application relates to the field of protocol data unit (PDU) session management in communication networks and network management systems, and in particular to a system and method for enabling application-aware and application-friendly protocol data unit (PDU) session management. Background Art

[0004] 3rd Generation Partnership Project (3 rd In September 2016, the 3GPP released a technical report numbered TR 23.799, entitled "Study of the architecture of the next generation system", version 0.8.0 (hereinafter referred to as TR 23.799), which represents a design method for the architecture of the next generation mobile network system, also known as the fifth generation (5G).th generation, 5G) network. As proposed in the literature cited above, the network can be logically divided into a control plane (CP) that supports network control functions and a user plane (UP) that supports data services transmitted between user equipment (UE), servers, and network functions available on the network. In some embodiments, a management plane can also be defined. It should be understood that the different planes are logical constructs. In many cases, nodes and functions within the network can use the same physical hardware and connections, although they are considered to be logically different.

[0005] The communication between connected devices, such as UE and server, is managed by CP. Unlike current communication networks, where fixed short-duration PDU sessions are established between endpoints, in next generation networks, it is proposed that PDU sessions can be maintained for relatively long periods, during which PDU session parameters may need to be changed.

[0006] Therefore, there is a need for a method and apparatus for serving a mobile wireless communication device in a wireless communication network, such as the proposed 5G network, wherein a PDU session can be at least one of configured and updated to reflect current PDU session parameters, such as application system location or UP selection.

[0007] Network function virtualization (NFV) is a network architecture concept that uses IT virtualization technology to create entire categories of virtualized network functions as building blocks that can be connected to each other or other entities, or can be linked together to create communication services. NFV relies on, but is different from, traditional server virtualization technology, such as that used in enterprise IT. Instead of customizing hardware devices for each network function, a virtualized network function (VNF) can include one or more virtual machines (VMs) running different software and processes, standard high-capacity servers, switches and storage devices, and even cloud computing infrastructure. In other embodiments, VNFs can be provided without the use of virtual machines by using other virtualization technologies including the use of containers. In further embodiments, customized hardware devices can reside within the physical infrastructure for different virtual networks and can be presented to each virtual network as a virtual version of itself based on the division of device resources between networks. For example, a virtual session border controller can be instantiated on existing resources to protect a network domain without the typical cost and complexity of obtaining and installing a physical network protection unit. Other examples of VNFs include virtualized load balancers, firewalls, intrusion detection devices, and wide area network (WAN) accelerators.

[0008] The NFV framework consists of three main parts:

[0009] A virtualized network function (VNF) is a software implementation of a network function that can be deployed on a network functions virtualization infrastructure (NFVI).

[0010] Network Function Virtualization Infrastructure (NFVI) is the sum of all the hardware and software components that provide the resources required to deploy VNFs. NFV infrastructure can span multiple locations. The network that provides connectivity between these locations is considered part of the NFV infrastructure.

[0011] A network function virtualization management and orchestration (MANO) architectural framework (NFV-MANO architectural framework, such as NFV-MANO defined by the European telecommunicationsstandards institute (ETSI), referred to as ETSI_MANO or ETSI NFV-MANO) is a set of all functional blocks, data repositories used by these functional blocks, and reference points and interfaces through which these functional blocks exchange information in order to manage and orchestrate NFVI and VNFs.

[0012] The building blocks for NFVI and NFV-MANO are the resources of the NFV platform. These resources can include virtual and physical processing and storage resources, virtualization software, and can also include connectivity resources, such as communication links between data centers or nodes that provide physical processing and storage resources. In the NFV-MANO role, the NFV platform consists of VNFs and NFVI managers and virtualization software running on the hardware platform. The NFV platform can be used to implement carrier-grade features for managing and monitoring platform components, recovering from failures and providing appropriate security - all of which are required for public carrier networks.

[0013] Software-defined topology (SDT) is a networking technology that defines the logical network topology in a virtual network. Based on the requirements of the services provided on the virtual network and the available underlying resources, virtual functions and logical links connecting the functions can be defined by the SDT controller, and then the topology can be instantiated for a given network service instance. For example, for a cloud-based database service, the SDT may include logical links between a client and one or more instances of a database service. As the name implies, the SDT is typically generated by an SDT controller, which itself can be a virtualized entity in a different network or network slice. Logical topology determination is done by the SDT controller, which generates a network service infrastructure (NSI) descriptor (NSL descriptor, NSLD) as output. It can use an existing template for the NSI and add parameter values ​​to it to create an NSLD, or it can create a new template and define the composition of the NSI.

[0014] A software defined protocol (SDP) is a logical end-to-end (E2E) technology that can be used within a network service instance. SDP allows the generation of customized protocol stacks (which can be created using a set of available functional building blocks) that can be provided to different nodes or functions within a network or network slice. The definition of slice-specific protocols can result in different nodes or functions within a network slice having defined procedures to execute when a type of packet is received. As the name suggests, SDP is typically generated by one or more SDP controllers, which can be virtualized functions instantiated on a server.

[0015] Software-defined resource allocation (SDRA) refers to the process of allocating network resources to logical connections in a logical topology associated with a given service instance or network slice. In an environment where the physical resources of the network are used to support multiple network slices, the SDRA controller allocates the processing, storage, and connection resources of the network to different network slices to best suit the agreed service requirements of each network slice. This may result in a fixed allocation of resources, or it may result in a dynamically changing allocation to accommodate different time distributions of business and processing requirements. As the name implies, the SDRA controller will typically determine the allocation of resources and can be implemented as a function instantiated on a server.

[0016] Service-oriented network auto creation (SONAC) is a technology that uses software-defined topology (SDT), software-defined protocol (SDP) and software-defined resource allocation (SDRA) technology to create a network or virtual network for a given network service instance. By coordinating SDT, SDP, SDRA and software-defined network (SDN) control in some embodiments, optimization and further efficiency can be obtained. In some cases, a SONAC controller can be used to create a network slice, in which a virtualized infrastructure (e.g., VNF and logical links) can be used to create a network that complies with the Third Generation Partnership Project (3GPP) to provide a virtual network (VN) service. Those skilled in the art will understand that the resources allocated to different VNFs and logical links can be controlled by the SDRA type function of the SONAC controller, and the way the VNF is connected can be determined by the SDT type function of the SONAC controller. The way VNF processes data packets can be defined by the SDP type function of the SONAC controller. The SONAC controller can be used to optimize network management and can therefore also be considered a network management (NM) optimizer.

[0017] As NFV implementation details and standards evolve, systems and methods for ensuring that service level agreements (SLAs) are met in a consistent and reliable manner are highly desirable.

[0018] In the present disclosure, abbreviations not specifically defined herein should be interpreted according to the 3rd Generation Partnership Project (3GPP) technical standards, such as technical standard TS 23.501 V0.3.1 (March 2017).

[0019] This background information is provided to disclose information believed by the applicant to be potentially relevant to the present invention. No admission or interpretation is made that any of the foregoing information constitutes prior art to the present invention. Summary of the invention

[0020] According to the object of embodiments of the present application, a system and method for ensuring that a service level agreement (SLA) can be met is provided.

[0021] In a first aspect of the present invention, a method for managing subscription notifications is provided. The method includes a session management function (SMF) obtaining information associated with user plane (UP) selection or reselection notification subscription from an application function (AF); and the SMF sending a notification of UP selection or reselection to the AF, the notification type indicating whether the notification is sent before or after the UP path is configured.

[0022] In one embodiment of the first aspect of the present invention, the information from the AF indicates the notification type. In another embodiment, the notification also includes the application location.

[0023] In a second aspect of the present invention, a function such as a session management function (SMF) is provided. The function includes a processor and a computer-readable memory. The computer-readable memory stores instructions, and when executed by the processor, the SMF is configured to obtain information associated with at least one of a user plane (UP) selection notification subscription and a UP reselection notification subscription from an application function (AF); and send a notification of at least one of UP selection and UP reselection to the AF through a network interface, the notification including a notification type, the notification type indicating whether the notification is sent before or after the UP path is configured.

[0024] In one embodiment of the second aspect of the present invention, the information obtained from the AF indicates the notification type. In another embodiment, the notification also includes the application location.

[0025] In a third aspect of the present invention, a method for managing subscription notifications is provided. The method includes an application function (AF) subscribing to a notification about user plane (UP) selection or reselection; and the AF receiving a message including a notification type, the notification type indicating that the message is sent before or after a UP path is configured, wherein the message is associated with the notification about UP selection or reselection.

[0026] In an embodiment of the third aspect, subscribing to notifications comprises sending a request to subscribe to notifications, the request comprising a notification type. In another embodiment, the message comprises an application location.

[0027] In a fourth aspect of the present invention, a network function, such as an application function (AF), is provided. The network function includes a processor and a computer-readable memory. The computer-readable memory stores instructions, and when executed by the processor, the network function is configured to subscribe to notifications about at least one of user plane (UP) selection and UP reselection; and receive a message including a notification type, the notification type indicating that the message is sent before or after the UP path is configured, wherein the message is associated with a notification about UP selection or reselection.

[0028] In an embodiment of the fourth aspect of the present invention, the computer readable memory stores instructions which, when executed by the processor, further cause the AF to be configured to subscribe to notifications by sending a request to subscribe to notifications, the request including a notification type. In another embodiment, the received message includes an application location.

[0029] Those skilled in the art will appreciate that the above embodiments may be implemented in conjunction with the embodiments including the description thereof, and may be implemented in conjunction with other embodiments of the present aspects including the description thereof. In some cases, even if not explicitly described as applicable to the above, embodiments may also be implemented in conjunction with complementary aspects.

[0030] Accordingly, one aspect of the present invention provides a method by which user plane (UP) management information is exchanged between an application function (AF) supporting one or more applications and a slice management function (SMF) configured to manage service flows in a given network slice.

[0031] In one implementation, a method for managing protocol data unit session data services on a network is provided, the method comprising a control plane entity available on the network: receiving an application system (AS) location notification based on an application program interface (API) from an application system (AS) controller, the API-based AS location notification identifying an AS location and data services to be associated with the identified AS location; and sending the AS location notification to locate the AS.

[0032] In one implementation, before the control plane entity sends the AS location notification, the method further includes the control plane entity authenticating the AS controller. Authenticating the AS controller may include sending an authentication request to an authentication server function (AUSF) available on the network; and receiving an authentication response from the AUSF indicating an authentication result in response to the authentication request.

[0033] In one implementation, the AS location notification includes an AS relocation notification that changes an existing location of a PDU session.

[0034] In one implementation, the AS location notification includes an AS location notification for establishing a future PDU session location. The AS relocation notification may be sent to a session management function (SMF) to configure traffic redirection of data traffic for the relocated AS.

[0035] In one implementation, the AS location notification is sent to a policy control function (PCF) to generate a user plane (UP) selection policy and a traffic steering policy for data traffic.

[0036] In one implementation, a method for managing protocol data unit (PDU) session data services exchanged with a user equipment (UE) connected to a network is provided, the method comprising, at a control plane entity available on the network: receiving a PDU session request from the UE; validating the UE context based on user subscription data and authorizing the session request, and if authorized, the method further comprises: selecting and establishing a user plane (UP) path for the requested PDU session; and sending a PDU session request response to the UE.

[0037] In one implementation, the PDU session request includes a session ID.

[0038] In one implementation, the PDU session request includes a preferred session and service continuity (SSC) mode for the requested PDU session.

[0039] In one implementation, the PDU session request includes an application identifier indicating that the PDU session request is specific to an application associated with the application identifier. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Other features and advantages of the present invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings, in which:

[0041] Figure 1 is a block diagram of a computing system 100 that may be used to implement apparatus and methods according to a representative embodiment of the present invention;

[0042] Figure 2 is a block diagram schematically illustrating the architecture of a representative server that can be used in embodiments of the present invention;

[0043] Figure 3A is a block diagram illustrating a service-based view of the system architecture of a 5G core network;

[0044] Figure 3B An embodiment of an application system controller is shown, which is responsible for locating, relocating, selecting or reselecting an AS within an AS network;

[0045] Figure 4 is a block diagram schematically illustrating application relocation;

[0046] Figure 5 A signaling diagram illustrating an embodiment of an AS location or relocation notification is presented;

[0047] Figure 6 A signaling diagram illustrating an embodiment of a UP (re)selection notification request procedure is presented;

[0048] Figure 7 A signaling diagram illustrating an embodiment of a UP (re)selection notification procedure is presented;

[0049] Figure 8 A signaling diagram illustrating an embodiment of an application-friendly PDU session establishment procedure is presented;

[0050] Fig. 9 A signaling diagram illustrating an embodiment of an application-friendly UP reselection procedure for PDU session modification is presented;

[0051] Fig.10 is a block diagram illustrating an embodiment of a network architecture;

[0052] Fig.11A and 11B is a signaling diagram illustrating an embodiment of application-influenced UP selection performed by the SMF as part of session establishment;

[0053] Fig. 12A and 12B is a signaling diagram illustrating an embodiment of an application-influenced UP reselection procedure;

[0054] Fig.13 is a signaling diagram illustrating an embodiment of a procedure for applying a (re)location notification service;

[0055] Fig.14 is a signaling diagram illustrating an embodiment of a UP (re)selection notification service;

[0056] Fig.15 is a block diagram showing the relationship between user plane functions, dynamic network access identifiers and application hosts to indicate the (possibly) implicit selection of user plane functions due to selection of a dynamic network;

[0057] Fig.16 is a signaling diagram illustrating an embodiment of a UP (re)selection notification procedure;

[0058] Fig.17 is a signaling diagram illustrating an embodiment of a UE-requested PDU session establishment procedure for non-roaming and roaming with local breakout;

[0059] Fig.18A and 18B shows a signaling diagram illustrating an embodiment of a PDU session anchor reconfiguration due to application relocation;

[0060] Fig.19is a signaling diagram illustrating an embodiment of a method for PDU session anchor relocation for a PDU session dedicated to edge computing applications.

[0061] Fig. 20 is a signaling diagram illustrating an embodiment of a PDU session anchor relocation method for a PDU session shared by multiple edge computing applications;

[0062] Fig.21 is a simplified network diagram providing an illustration of an embodiment of segment management;

[0063] Fig. 22 is a simplified network diagram illustrating segment management according to an embodiment of the present invention;

[0064] Fig.23 is a call flow diagram illustrating various example processes according to an embodiment of the present invention;

[0065] Fig.24 is a call flow diagram illustrating various example processes according to an embodiment of the present invention;

[0066] Figures 25A-25C is a call flow diagram illustrating various example processes according to an embodiment of the present invention;

[0067] Fig.26 is a call flow diagram illustrating another example process according to an embodiment of the present invention;

[0068] Fig.27A and 27B A call flow diagram of various processes of UP path management notification to AF according to an exemplary embodiment of the present invention is shown;

[0069] Fig.28A and 28B A call flow diagram of a replacement process of a UP path management notification to an AF according to an exemplary embodiment of the present invention is shown;

[0070] Fig.29A and 29B A call flow diagram of another alternative process of UP path management notification to AF according to an exemplary embodiment of the present invention is shown; Fig.30 is a flow chart illustrating a process according to an exemplary embodiment of the present invention; and

[0071] Fig.31 is a logical block diagram illustrating an example relationship between an application location, a data network access identifier (DNAI), and a UPF according to an embodiment of the present invention.

[0072] It should be noted that throughout the drawings, like features are identified by like reference numerals. DETAILED DESCRIPTION

[0073] In this application, the term IP address has been used in exemplary embodiments. It should be understood that in different embodiments, different identifiers and addresses may be used, such as hardware addresses, IP addresses, media access control (MAC) addresses, or other addresses that may be used instead of applicable IP addresses.

[0074] Figure 1 It is a block diagram of a computing system 100 that can be used to implement the devices and methods disclosed herein. A specific device can utilize all of the components shown or only a subset of the components, and the degree of integration can vary with the device. In addition, the device can contain multiple instances of components, such as multiple processing units, processors, memories, transmitters, receivers, etc. The computing system 100 includes a processing unit 102. The processing unit 102 can also be referred to as an electronic device (electronic device, ED). In some embodiments, the processing unit 102 can be a user equipment (UE), while in other embodiments, it can be a computing platform of a computing server in a data center environment, for example. The processing unit 102 typically includes a central processing unit (centralprocessing unit, CPU) 114, a bus 120, and a memory 108, and can also optionally include a mass storage device 104, a video adapter 110, and an I / O interface 112 (shown in dotted lines). It will be understood by those skilled in the art that CPU 114 represents processing power. In some embodiments, a dedicated processing core can be provided to replace a traditional CPU. For example, a graphics processing unit (GPU) or other so-called accelerated processor (or processing accelerator) may be provided in addition to or instead of the CPU.

[0075] CPU 114 may include any type of electronic data processor. Memory 108 may include any type of non-transitory system memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or a combination thereof. In one embodiment, memory 108 may include ROM for booting, and DRAM for program and data storage used when executing programs. Bus 120 may be one or more of any type of several bus architectures, including a memory bus or memory controller, a peripheral bus, or a video bus.

[0076] Mass storage 104 may include any type of non-transitory storage device configured to store data, programs, and other information and make the data, programs, and other information accessible via bus 120. Mass storage 104 may include, for example, one or more of a solid-state drive, a hard disk drive, a magnetic disk drive, or an optical disk drive.

[0077] Video adapter 110 and I / O interface 112 provide optional interfaces to couple external input and output devices to processing unit 102. Examples of input and output devices include display 118 coupled to video adapter 110 and I / O device 116, such as a touch screen coupled to I / O interface 112. Other devices may be coupled to processing unit 102, and additional or fewer interfaces may be used. For example, a serial interface such as a universal serial bus (USB) (not shown) may be used to provide an interface for external devices.

[0078] The processing unit 102 may also include one or more network interfaces 106, which may include at least one wired link, such as an Ethernet cable, and a wireless link for accessing one or more networks 122. The network interface 106 allows the processing unit 102 to communicate with remote entities via the network 122. For example, the network interface 106 may provide wireless communication via one or more transmitters / transmit antennas and one or more receivers / receive antennas. In one embodiment, the processing unit 102 is coupled to a local area network or a wide area network for data processing and communication with remote devices, such as other processing units, the Internet, or a remote storage facility.

[0079] Figure 2 2 is a block diagram schematically illustrating the architecture of a representative server 200 that may be used in embodiments of the present invention. It is contemplated that the server 200 may be physically implemented as one or more computers, storage devices, and routers (any or all of which may be described in detail in the above reference). Figure 1 The system 100 described herein is interconnected to form a local network or cluster and executes appropriate software to perform its intended functions. A person of ordinary skill will recognize that there are many suitable hardware and software combinations that can be used for the purposes of the present invention, which are either known in the art or can be developed in the future. Therefore, a diagram showing physical server hardware is not included in this specification. However, Figure 2 The block diagram of shows a representative functional architecture of server 200, but it should be understood that the functional architecture can be implemented using any suitable combination of hardware and software.

[0080] like Figure 2As shown in , the illustrated server 200 generally includes a host infrastructure 202 and an application platform 204. The host infrastructure 202 includes physical hardware resources 206 of the server 200 (e.g., information processing, service forwarding, and data storage resources), and a virtualization layer 208 that presents an abstraction of the hardware resources 206 to the application platform 204. The specific details of the abstraction will depend on the needs of the applications carried by the application layer (as described below). Thus, for example, an application that provides service forwarding functionality can be presented together with an abstraction of the hardware resources 206, which simplifies the implementation of service forwarding policies in one or more routers. Similarly, an application that provides data storage functionality can be presented together with an abstraction of the hardware resources 206, which facilitates the storage and retrieval of data (e.g., using a lightweight directory access protocol - LDAP (lightweight directory access protocol)).

[0081] The application platform 204 provides capabilities for hosting applications and includes a virtualization manager 210 and application platform services 212. The virtualization manager 210 supports a flexible and efficient multi-tenant runtime and hosting environment for applications 214 by providing an infrastructure as a service (IaaS) facility. In operation, the virtualization manager 210 can provide security and resource "sandboxes" for each application hosted by the platform 204. Each "sandbox" can be implemented as a virtual machine (VM) 216, or can be implemented as a virtualized container, which includes an appropriate operating system and controlled access to the (virtualized) hardware resources 206 of the server 200. The application platform services 212 provide a set of middleware application services and infrastructure services to the applications 214 hosted on the application platform 204, which will be described in more detail below.

[0082] Applications 214 from suppliers, service providers, and third parties may be deployed and executed within corresponding virtual machines 216. For example, MANO and SONAC (and their various functions, such as SDT, SDP, and SDRA) may be implemented with the aid of one or more applications 214 hosted on the application platform 204 as described above. The communication between the application 214 and the services in the server 200 may be conveniently designed according to the principles of a service-oriented architecture (SOA) known in the art.

[0083] The communication services 218 may allow applications 214 hosted on a single server 200 to communicate with the application platform services 212 (eg, via predefined application programming interfaces (APIs)) and with each other (eg, via service-specific APIs).

[0084] The service registry 220 can provide visibility of available services on the server 200. In addition, the service registry 220 can provide service availability (e.g., the status of the service) and related interfaces and versions. Applications 214 can use it to discover and locate endpoints of services required by the application, and publish their own service endpoints for use by other applications.

[0085] Mobile edge computing allows cloud application services to be hosted with mobile network elements and also helps to take advantage of available real-time network and wireless information. Network information services (NIS) 222 can provide low-level network information to applications 214. For example, the information provided by NIS 222 can be used by applications 214 to calculate and present high-level and meaningful data, such as: cell ID, user's location, cell load, and throughput guidance.

[0086] Traffic off-load function (TOF) service 224 can prioritize traffic and route selected, policy-based user data flows to and from application 214. TOF service 224 can be provided to application 214 in various ways, including: forwarding mode, where traffic (at least one of uplink and downlink) is passed to application 214, which can monitor, modify or shape the traffic and then send it back to the original packet data network (PDN) connection (e.g., 3GPP bearer); and endpoint mode, where the traffic is terminated by application 214 acting as a server.

[0087] Figure 3AA service-based architecture 300 for a 5G or next generation core network (5GCN / NGCN / NCN) is shown. This diagram depicts logical connections between nodes and functions, and the connections shown should not be interpreted as direct physical connections. ED 102 forms a radio access network connection with a (radio) access network ((R)AN) node 302 (which may be, for example, a gNodeB (gNB)), which is connected to a user plane (UP) function (UPF) 304, such as a UP gateway via a network interface, providing a defined interface, such as an N3 interface. UPF 304 provides a logical connection to a data network (DN) 306 via a network interface, such as an N6 interface. The radio access network connection between ED 102 and (R)AN node 302 may be referred to as a data radio bearer (DRB).

[0088] DN 306 may be a data network used to provide operator services, or it may be outside the scope of standardization of the 3rd Generation Partnership Project (3GPP), such as the Internet, which is used to provide third-party services, and in some embodiments, DN 306 may represent an edge computing network or resource, such as a mobile edge computing (MEC) network.

[0089] ED 102 is also connected to an access and mobility management function (AMF) 308 via a logical N1 connection (although the physical path of the connection is not direct). AMF 308 is responsible for authentication and authorization of access requests, as well as mobility management functions. AMF 308 can perform other roles and functions defined by 3GPP technical specification (TS) 23.501. In a service-based view, AMF 308 can communicate with other core network control plane functions through a service-based interface denoted as Namf.

[0090] The session management function (SMF) 310 is a network function that is responsible for the allocation and management of IP addresses assigned to EDs, and the selection of a UPF 304 (or a specific instance of a UPF 304) for services associated with a particular session with an ED 102. It will be appreciated that there will typically be multiple SMFs 310 in the network 300, each of which may be associated with a corresponding set of EDs 102, (R)AN nodes 302, or UPFs 304. The SMF 310 may communicate with other core network functions in a service-based view through a service-based interface denoted as Nsmf. The SMF 310 may also be connected to the UPF 304 through a logical interface such as a network interface N4.

[0091] The Authentication Server Function (AUSF) 312 provides authentication services to other network functions through the service-based Nausf interface.

[0092] A network exposure function (NEF) 314 may be deployed in the network to allow servers, functions, and other entities outside of, for example, a trusted domain to be exposed to services and capabilities within the network. In one such example, the NEF 314 may be very similar to a proxy between an application server external to the network shown and network functions such as a policy control function (PCF) 314, SMF 310, a unified data management function (UDM) 320, and AMF 308, so that an external application server may provide information that may be used in the setting of parameters associated with a data session. The NEF 314 may communicate with other network functions via a service-based Nnef network interface. The NEF 314 may also have an interface to non-3GPP functions.

[0093] The network repository function (NRF) 318 provides a network service discovery function. The NRF 318 may be specific to the public land mobility network (PLMN) or network operator associated with it. The service discovery function may allow network functions and EDs connected to the network to determine the location and method of accessing existing network functions, and may present a service-based interface Nnrf.

[0094] The PCF 314 communicates with other network functions through a service-based Npcf interface and can be used to provide policies and rules to other network functions, including those within the control plane. The implementation and application of policies and rules is not necessarily the responsibility of the PCF 314, but is typically the responsibility of the function to which the PCF 314 sends policies. In one such example, the PCF 314 can send policies associated with session management to the SMF 310. This can be used to allow a unified policy framework with which network behavior can be managed.

[0095] The unified data management function (UDM) 320 may present a service-based Nudm interface to communicate with other network functions and may provide data storage facilities to other network functions. Unified data storage may allow for a unified view of network information that may be used to ensure that the most relevant information is available to different network functions from a single resource. This may make the implementation of other network functions easier because they do not need to determine where a particular type of data is stored in the network. The UDM 320 may connect to a user data repository (UDR) 322 using an interface such as Nudr. The PCF 314 may be associated with the UDM 320 in that it may be involved in requesting and providing subscription policy information to the UDR, but it should be understood that the PCF 314 and the UDM 320 are typically independent functions.

[0096] PCF 314 may have a direct interface to UDR 322, or may use a Nudr interface to connect to UDR 322. UDM 320 may receive a request to retrieve content stored in UDR 322, or a request to store content in UDR 322. UDM 320 is typically responsible for functions such as credential processing, location management, and subscription management. UDR 322 may also support any or all of authentication credential processing, user identity processing, access authorization, registration / mobility management, subscription management, and short message service (SMS) management. UDR 322 is typically responsible for storing data provided by UDM 320. The stored data is typically associated with policy profile information (which may be provided by PCF 314), which manages access rights to the stored data. In some embodiments, UDR 322 may store policy data, as well as user subscription data that may include any or all of subscription identifiers, security credentials, access and mobility-related subscription data, and session-related data.

[0097] The application function (AF) 324 represents the non-data plane (also known as non-user plane) functions of applications deployed within the network operator domain and within a 3GPP compliant network. The AF 324 interacts with other core network functions through a service-based Naf interface and can access network capability exposure information, as well as application information for decisions such as service routing. The AF 324 can also interact with functions such as the PCF 314 to provide application-specific inputs into policy and policy implementation decisions. It should be understood that in many cases, the AF 324 does not provide network services to other NFs, but is often viewed as a consumer or user of services provided by other NFs. Applications outside the 3GPP network can perform many of the same functions as the AF 324 by using the NEF 314.

[0098] ED 102 communicates with network functions in the user plane (UP) 326 and the control plane (CP) 328. UPF 304 is part of CN UP 326 (DN 306 is outside 5GCN). (R)AN node 302 can be considered as part of the user plane, but because it is not strictly part of the CN, it is not considered as part of CN UP 326. AMF 308, SMF 310, AUSF 312, NEF 314, NRF 318, PCF 314 and UDM 320 are functions that reside within CN CP 328 and are generally referred to as control plane functions. AF 324 can communicate with other functions within CN CP 328 (directly or indirectly through NEF 314), but is generally not considered as part of CN CP 328.

[0099] Those skilled in the art will appreciate that multiple UPFs may be connected in series between the (R)AN node 302 and the DN 306, and multiple data sessions to different DNs may be accommodated by using multiple UPFs in parallel.

[0100] Figure 3B A portion of a wireless communication network 300 is shown, wherein a UE 102 is connected to a core network (CN) control plane (CP) 328 and a CN user plane (UP) 326 via an access node (AN) 302. The CN CP 328 includes a unified data management (UDM) function 320, which communicates with a management plane 330.

[0101] The application system (AS) controller 332 is responsible for locating, relocating, selecting or reselecting an AS within the AS network 334. The AS controller 332 is connected to the CN CP 328 via the network exposure function (NEF) 314.

[0102] The CN CP 328 is used to manage the logical location of resources within the 3GPP domain. The application server or application system of the AS network 334 is managed by the AS controller 332. The service steering capability or interconnection quality (e.g., measured by throughput, delay, load of PDU sessions, etc.) between the CN UP 326 and the AS is provided to the CN CP 328 by the network function in the management plane 330, and information associated with these capabilities and connection quality parameters can be stored in the UDM 320. The CP 328 can use the service steering capability information to establish an effective end-to-end path between the communicating parties.

[0103] The CN CP 328 communicates with the connected UE 102 via interface NG1, and communicates with the AN 302 providing the connection via interface NG2. The AN 302 communicates with the CN UP 326 via interface NG3. The CN UP 326 is controlled by the CN CP 328 via interface NG4. Interfaces NG1, NG2, NG3 and NG4 are described and defined in more detail by the 3GPP mobile broadband standard. Those skilled in the art will appreciate that the specific definitions of these interfaces may be varied without departing from the invention disclosed herein. The specific definition clauses of these interfaces may be found in publicly accessible documents (e.g., see the historical and current standard documents at www.3gpp.org).

[0104] The CN CP 328 is responsible for configuring traffic steering at the user plane (UP) gateway (GW) 336 for routing uplink (UL) application traffic to the appropriate AS location, possibly taking into account possible intra-AS (re)location.

[0105] The AS network 334 is responsible for steering downlink (DL) application traffic to the appropriate UP GW 336, possibly taking into account possible internal UP (re)selection.

[0106] The traffic redirection performed by the AS network 334 may be configured by the AS controller 332. In some embodiments, the traffic redirection performed by the AS network 334 may be configured or implemented by an upper layer mobility management mechanism within the AS network 334 itself. Figure 3B In the example of FIG. 3 , the straight line connecting UP GW 336 to AS network 334 indicates a link connecting CN UP 326 to AS network 334 implemented by traffic steering. The following signaling diagrams in this application describe implementations highlighting the interactions between CN UP 326 and AS network 334 to implement application-aware PDU session management of application traffic using an efficient end-to-end path.

[0107] Figure 3BThe network architecture shown in provides an interface that may be necessary to implement interaction between CP 328 (or nodes and functions within CP) and AS controller 332. This interface can be used to enable application-aware PDU session management for application services that require an efficient end-to-end path.

[0108] Broadly speaking, embodiments of the present invention provide a method by which user plane (UP) management information can be exchanged between an application function (AF) supporting one or more applications and a session management function (SMF). The AF is typically a function outside a 3GPP-compatible network (in some examples, it can be a server or set of servers that provides services to UEs connected to a 3GPP-compatible network, while in other examples, the AF can be a function instantiated in a mobile edge computing environment outside a 3GPP-compatible core network or outside a 3GPP-compatible RAN). In some embodiments, the AF is referred to as an AS controller. The AF can be a function outside the scope of the 3GPP standard. The AF can be instantiated on an application server outside the 3GPP core network and can act as a controller to be responsible for functions such as AS (re)location (or AS (re)selection) within a local DN.

[0109] The SMF is a 3GPP-compliant network function, typically within a control plane (CP), configured to manage service flows, typically within a given network slice. In short, the exchange of UP management information associated with a specific service flow can be initiated from the AF or SMF associated with the service flow. In the case where the AF initiates the information exchange, the UP management information provided by the AF may include the service requirements of the applications supported by the AF. In the case where the SMF initiates the information exchange, the UP management information provided by the SMF may include operator policy information or events, and the AF may respond with service requirement information of the applications supported by the AF. In some embodiments, other network entities may trigger the process by sending a message to the SMF, and the SMF may initiate the process in response to such a request received.

[0110] Application functions can send requests to influence SMF routing decisions for PDU session traffic. AF requests can influence UPF (re)selection and allow user traffic to be routed to local access to the data network (identified by the Data Network Access Identifier (DNAI)).

[0111] It is assumed that the application function making such a request belongs to the PLMN serving the UE. The application function may make the request on behalf of an application not owned by the PLMN serving the UE.

[0112] If the operator does not allow the application function to access the network directly, the application function will use NEF to interact with the 5GC. This operation can follow the provisions of the relevant technical standards, for example, clause 6.2.10 of 3GPP technical standard TS23.501V0.3.1 (March 2017). In an embodiment where the AF does not directly access the network, an NEF may be provided to provide an interface for the CP function that allows the AF to access the network. Although a trusted AF may be provided with the ability to interact with the CN CP function, there may be too many functions in some networks to provide access to the CP function to each of them. Instead, the NEF may act as a proxy for an AF outside the CN to exchange information with the CP function. By using the NEF, the AF may be provided with a path to communicate with the CP function, but the address or network name of the function with which it communicates may not be directly known.

[0113] The Application Function may be responsible for the (re)selection or relocation of applications within the local DN.For this purpose, the AF may request to receive notifications about events related to the PDU Session.

[0114] In some embodiments, for AFs that allow direct interaction with 5GC NFs, AF requests for ongoing PDU sessions for individual UEs may be sent to the PCF via N5. In some embodiments, the AF request may be sent via NEF. Requests for multiple UEs may be sent via NEF, and may be for multiple PCFs. The PCF may then convert the AF request into a policy that is applied to the PDU session. Those skilled in the art will appreciate that the conversion of AF requests to policies may be implemented in a variety of different ways, including generating a policy that may be sent by the PCF to the UPF or a UPF that manages the processing of identified services associated with the service in the session, and performing the generation of the policy based on the received AF request. When the AF has subscribed to SMF notifications, such notifications may be sent to the AF directly or via the NEF.

[0115] PCF can also subscribe to such notifications.

[0116] Such an AF request may contain at least:

[0117] Information used to identify the service to be routed. The service can be identified in the AF request by: a data network number (DNN) or other type of DN identifier and possible slice information (e.g.

[0118] For example, single network slice selection assistance information (single network slice selection assistance information,

[0119] S-NSSAI) or AF Service Identifier).

[0120] When the AF provides the AF service identifier (i.e., the identifier of the service on whose behalf the AF is making the request), the 5G core network function

[0121] The NEF (e.g., NEF or PCF) can map this identifier to the target DNN and slice information (S-NSSAI). When the NEF processes the AF request, the AF service identifier can be used to authorize the AF request.

[0122] Application identifier or service filtering information (e.g., IP address 5-tuple). The application identifier refers to the application that handles the UP service, and the UPF can use it to detect the application's service. The AF can also associate a packet filter description (PFD) with the application identifier, but this association can be done through a separate request.

[0123] Information about the N6 service routing requirements of the service identified by the above information. It should be understood that N6 refers to the interface between the UPF and the DN outside the CN. When the application is statically instantiated (i.e., each routing profile ID corresponds to a DNAI), information about the service routing requirements can be provided in the form of a list of routing profile IDs, each of which corresponds to a single host location of the application in the local DN. When the DNAI of the instantiated application can change dynamically, it can be provided in the form of a DNAI list and related N6 routing information. Based on the information about the N6 service routing requirements, which may include a routing profile ID in some embodiments, the PCF determines a list of service steering profile IDs corresponding to each steering behavior pre-configured on the SMF or UPF. The PCF sends the service steering policy ID to the SMF. The service steering policy ID is related to the mechanism for enabling service steering to the DN. If the AF interacts with the PCF via the NEF, it can indicate at least one of the DNN and the host location in the form of the address or name of the application, and the NEF can map the information to the routing profile ID. In one embodiment, the SMF is used to receive the service steering policy ID and determine which service steering policy ID and corresponding service steering behavior should be applied. The SMF passes the selected service redirection policy ID to the UPF. In one embodiment, the UPF is used to identify the corresponding service redirection parameters that are pre-configured and associated with the selected service redirection policy ID. The UPF can also further apply the corresponding service redirection parameters when processing data services.

[0124] The N6 service routing requirements are related to the mechanism for implementing service steering in the local access DN. They should correspond to the local rules configured in the UPF to support service steering. The routing profile IDs may refer to pre-agreed policies between the AF and the 5GC, or in alternative embodiments, they may simply refer to predefined routing requirements. The policy may refer to different steering policy IDs sent to the SMF. In some embodiments, the policy may be based on other conditions, such as time conditions (e.g., based on time of day, etc.).

[0125] The potential location of the application to which the application traffic should be routed. The potential location of the application is or may be represented as a DNAI list. In some embodiments, when the AF interacts with the PCF via the NEF, the AF may provide the PCF or NEF with a list of host addresses or host names of the application, which is converted to a DNAI list by the NEF. In some embodiments, when the AF interacts with the PCF via the NEF, the NEF may map the AF service identifier information provided by the AF to a DNAI list. In either case, the DNAI may be used for, for example, UPF (re)selection.

[0126] AF requests may also contain:

[0127] Information about the UE for which traffic is to be routed. This may correspond to using an external identity as defined in, for example, TS 23.682

[0128] The PDU type may be an individual UE identified by an MSISDN, or an IP address / prefix as described in TS23.003, or may correspond to a group of UEs identified by a group identifier, for example, an external group identifier such as those defined in TS23.682, or any UE accessing a combination of DNN, S-NSSAI and DNAI to which the request applies, which may be identified by an indicator. In the case or embodiment where the PDU type is IP, when the AF provides the IP address / prefix of the UE, this allows the PCF to identify the PDU-CAN session to which the request applies, and the AF request applies only to the current PDU-CAN session for that UE. In this case, additional information such as the UE identification may also be provided to help the PCF identify the correct PDU-CAN session.

[0129] Otherwise, the request may apply to any future PDU Sessions matching the parameters in the AF Request.

[0130] When an AF request targets any UE or UE group, the AF request may affect multiple PDU sessions that may be served by multiple SMFs and PCFs.

[0131] When the AF request targets a group of UEs, it provides one or more group identifiers in its request. In some embodiments, the members of the group include group information in their subscriptions (i.e., group identifiers), which is stored in the UDM. In one implementation, the group information can be retrieved by the SMF, for example via the N10 interface, and passed to the PCF when the PDU-CAN session is established, for example via the N7 interface. The implementation allows the group identifier to be provided to the AMF as well, for example via the N8 interface. In some embodiments, the group identifier can be stored as PCF non-standard data in the UDR (acting as a subscription profile repository "subscription profile repository, SPR"). In some embodiments, a UE can belong to multiple groups.

[0132] Information about when to apply the traffic route (e.g., time validity conditions). Using time validity conditions allows

[0133] A time period is associated with an AF request, or allows a condition to apply during a defined time window. These defined time windows can be recurring or one-time.

[0134] Information about where the UE will be when traffic routing is applied (spatial validity condition). In one embodiment, this is done by

[0135] For example, it is provided in the form of a geographical or topological identifier of a RAN node identifier, indicating a possible serving RAN node for the UE when applying service routing. If the AF interacts with the PCF via the NEF, it provides or may provide in some embodiments a list of geographical area identifiers, and the NEF maps the information to the RAN node identifier. In one embodiment, the spatial validity condition may be provided in the form of an area of ​​interest. The area of ​​interest may include, for example, a geographical area or a topological area that defines an area of ​​interest with respect to the network topology. The area of ​​interest may be specified using spatial identifiers such as tracking area IDs, (R)AN node IDs, cell IDs, etc. If the AF interacts with the PCF via the NEF, it may provide a list of geographical area identifiers, and the NEF may map the information to the area of ​​interest based on pre-configured information. The pre-configuration may be done by a management plane function. The pre-configuration may include a mapping of area ID→area information / configuration→area of ​​interest (or RAN node ID or cell ID).

[0136] Alternatively, the AF can provide the region ID → region information / configuration mapping to the NEF in a separate process that occurs previously.

[0137] The management plane function configures the NEF with the information of the RAN node or the cell location information or the predefined area of ​​interest information. The NEF can use the information provided by the AF and the information provided by the management plane (both of which are pre-configured information) for mapping.

[0138] AF subscribes to the following events.

[0139] Notification of UP path management events: Change of DNAI of UPF serving UE when UPF changes.

[0140] The corresponding notification of the change of the source DNAI to the target DNAI sent by the SMF to the AF includes the identity of the target DNAI and the address of the anchor UPF. In some embodiments, the notification may also include the IP address / prefix of the UE, UE identity information (e.g., external identifier or MSISDN) and N6 routing information related to the core network.

[0141] In some embodiments, if the PDU session type is IP, the UE identification information and the core network communication may not be required.

[0142] At least one of the N6 routing information related to the device.

[0143] Subscription can be used for at least one of pre-notification and post-notification. In the case of subscription for pre-notification, SMF sends notification before performing UPF (re)selection. In the case of subscription for post-notification, SMF sends notification when UPF (re)selection is completed.

[0144] Application functions can send requests to influence SMF routing decisions, for event subscriptions, or both.

[0145] The PCF authorizes the request received from the application function and determines the service steering policy based on the information received from the AF, the operator's policy, etc. The service steering policy may indicate a list of suitable service steering profiles configured in the SMF, and in some embodiments, the service steering policy may include N6 routing information, for example, when the N6 routing information associated with the application is explicitly provided by the AF. The service steering profile may include at least one of its supported routing profile IDs and a corresponding data network access identifier (DNAI). The DNAI is related to information that the SMF considers for UPF selection, for example, for transferring (locally) some services that match the service filters provided by the PCF.

[0146] The PCF confirms the request to the AF or NEF.

[0147] During the session establishment process, the UE may provide an application identifier in the session request, indicating that the PDU session is intended or dedicated to the application identified by the application identifier. When the DNN in the session request points to the local DN and the application identifier is included in the session request, the SMF may initiate third-party authentication / authorization as described in TS23.501, clause 5.6.6, to verify application access.

[0148] In the PDU session establishment process (an embodiment of which is in Fig.28A During the process (shown in FIG. 28 ), the SMF may obtain subscription group information (e.g., IMSI-group identifier) ​​from the UDR via the UDM (e.g., steps 2806 and 2808). The SMF provides the application identifier (if available) and subscription information to the PCF (e.g., steps 2814 or 2818) to apply the operator policy.

[0149] For a PDU-CAN session corresponding to an AF request, the PCF provides the SMF with a policy and charging control (PCC) rule that may include at least one of: application information (i.e., application identifier) ​​and at least one of information about the DNAI for the service routing that should be applied; and at least one of a service steering profile ID list, a spatial validity condition, and information about the AF subscription to SMF events. In an embodiment where the N6 routing information associated with the application is explicitly provided in the AF request, the PCF may also provide the N6 routing information to the SMF as part of the PCC rules. This is accomplished by providing a policy when the PDU-CAN session is established, or by initiating a PDU-CAN session modification procedure. In some embodiments, the PCF periodically evaluates the time validity conditions of the AF request and, based on the evaluation results, notifies the SMF to activate or deactivate the corresponding PCC rules.

[0150] If the activated PCC rule contains a spatial validity condition, the SMF subscribes to receive UE mobility information from the AMF, which is associated with the UE entering or leaving the area of ​​interest specified in the spatial validity condition. The SMF uses the UE mobility information and the spatial validity condition to determine whether the PCC rule is valid for the application.

[0151] When a PCC rule is in effect, the SMF may consider the information in the PCC rule based on local policy to:

[0152] (Re)select UPF for PDU Session. SMF is responsible for handling UE location (TAI / Cell-Id) associated with UPF

[0153] The SMF is responsible for selecting the UPF that provides services for the PDU session. This operation may comply with the provisions of relevant technical standards, for example, Section 6.3.3 of 3GPP technical standard TS23.501V0.3.1 (March 2017).

[0154] Activate mechanisms for service multi-homing or implement UL Classifier (UL CL). These mechanisms may comply with relevant technical standards

[0155] The UPF may include provisions of the 3GPP technical standard TS23.501V0.3.1 (March 2017), such as clause 5.3.5 of the 3GPP technical standard TS23.501V0.3.1 (March 2017). This may include providing service forwarding (e.g., separation) rules and associated N6 routing information to the UPF if the N6 routing information is part of the PCC rules. The service forwarding rules may include an application identifier and a service steering policy ID. The application identifier refers to an application service detection rule configured at the UPF. In one embodiment, the application header may be used to associate the application identifier with the application service detection rule.

[0156] Notify the application function to (re)select the UP path (e.g., change DNAI and PDU session location).

[0157] The SMF may configure the UPF to report detection of application services. According to the configuration, upon application service detection, the UPF notifies the SMF of the application identifier. The SMF may use the reported application identifier and other information to obtain PCC rules from the PCF to apply AF influence to the service routing of the PDU session. Therefore, the SMF may apply the configuration to the UPF to configure the service processing policy based on the rules and configuration associated with the AF identified by the reported application identifier. In some embodiments, the SMF may reselect a new UPF and configure the new UPF for processing application services.

[0158] In some embodiments, when the UE provides an application identifier during establishment of a PDU session, the SMF may be used to send an application identifier to the DN. In some implementations, the SMF may be used to send the application identifier to the authentication / authorization entity of the DN. The network node, entity, or function within the DN may be used to perform application-specific authentication / authorization based on the received application identifier. In an alternative embodiment, the SMF does not provide the application identifier to the network node, entity, or function within the DN as input. Instead, the network node, entity, or function within the DN returns a list of application identifiers to the SMF. In this case, the SMF must verify the application identifier provided by the UE for the application. The difference between these embodiments is that the application identifier is provided to the DN as input to the authentication / authorization process. As a result, the authentication / authorization can be an application-specific identifier list returned by the DN in order to provide application-specific authorization.

[0159] Figure 4 A scenario of application relocation in a virtual environment is shown, where application App-1 (e.g., a video streaming application) is relocated in three steps, for example, due to loading issues. The first step occurs within DNAI-1 and is invisible to the 5GC. The 5GC reselects DNAI-2 (changed from the initial DNAI-1) in response to relocation step 2, and then the 5GC reselects UPF-2 (changed from UPF-1) and DNAI-2 (changed from DNAI-2) with respect to application relocation step 3. The third step occurs on Data Center-A and Data Center-B. Moving application functionality to the second data center is an event that can trigger UPF reselection.

[0160] Two embodiments for triggering UPF / DNAI reselection are discussed below.

[0161] In a first embodiment, DNAI is used without AF impact on service routing. In this case, AF impact on service routing (i.e., UPF reselection / service diversion reconfiguration) can be implemented after detecting application traffic at the UPF or in the DN. That is, the UPF or AF can send a notification to the control plane function by sending, for example, a service diversion reselection request to indicate that the session contains data traffic associated with the application ("application traffic detection"). In some embodiments, this can be performed by the AF sending a request or notification to the SMF, optionally through interaction with the NEF. In other examples, the UPF can send a request or notification in response to the detection of traffic in a session with application functions in a DN accessed through the UPF. In response to the receipt of the service diversion reselection request, the control plane entity can request or call a service diversion reselection process (sometimes referred to as "triggering" service diversion reselection). In some embodiments, the AF can also send a UPF reselection request to the control plane entity of the control plane to reselect the UPF (sometimes referred to as "triggering" UPF reselection). Therefore, end-to-end path efficiency is only applied to a portion of the traffic associated with the PDU session.

[0162] In a second embodiment, DNAI is used in situations where service routing has an AF impact. In this embodiment, the UE provides an application identifier to the SMF as part of the session request. The application identifier can be associated with the PDU session identifier, indicating that the PDU session is intended for or dedicated to services associated with the application. The identifier can be used to indicate to functions in the UP path that specific service processing policies or rules, or specific service routing policies, should be applied. This allows the control plane function to configure the UPF function by sending a service processing policy that indicates how any or all service flows with a specific identifier should be handled. For example, a service routing policy can be defined to ensure that data services associated with a PDU session are routed through a defined path through the CN towards or away from the DN associated with the application.

[0163] Thus, end-to-end path efficiency can be provided to application traffic from the very beginning of the relocation process. In some embodiments, if the UE uses the same PDU session for both the identified application and another application, the UP path may not be optimally efficient for the other application. In these cases, improved path efficiency can be achieved after application traffic related to other applications is detected. In some such embodiments, the UPF or AF can determine that the session contains traffic associated with another application (or application function), and can notify the control plane function (e.g., SMF) of the detected application traffic to trigger the control plane function for reselecting traffic steering as described in the first embodiment.

[0164] As an example, when the UE wants to access an application in a local DN that has strict requirements on end-to-end path efficiency, the second embodiment can be applied. For example, the first embodiment can be applied in other scenarios (i.e., when the end-to-end path efficiency requirement of the application is lower than a predetermined threshold).

[0165] When the UE provides an application identifier, the SMF can initiate a third-party authentication / authorization to use a PDU session for the application. Third-party authentication / authorization may be useful because application-specific UP management can be applied to the PDU session based on the application identifier. This third-party authentication / authorization can avoid situations where information received from the UE (e.g., application identifier) ​​cannot be relied upon. For example, the third-party authentication / authorization mechanism described in TS23.501, 5.6.6 uses the user plane for information exchange or communication between the SMF and the third-party authentication / authorization function. In one embodiment, the present application proposes to extend the mechanism to allow third-party authentication / authorization to be performed via the NEF (which can allow third-party authentication / authorization to be performed in the extended control plane). By allowing access through the NEF, the third-party authentication / authorization function is able to perform functions equivalent to the AF, depending on the access level provided. This embodiment provides additional functionality to support situations where the third-party authentication / authorization function is not in the DN. In one implementation, the NEF provides interfaces and functions to provide the third-party authentication / authorization function with the ability to act as an AF.

[0166] When establishing a PDU session to a DN:

[0167] - In some embodiments, the UE may be authenticated / authorized by a third party, which may be located in the DN, for example, a DN-AAA server.

[0168] If the UE provides authentication / authorization information during the establishment of the PDU Session and the SMF

[0169] If it is determined that third-party authentication / authorization is required for the establishment of the PDU session, the SMF passes the authentication / authorization information of the UE to the third party. In one embodiment, if the third party is located in the DN, the information can be passed to the third party in the DN via the UPF. In one embodiment, if the third party is not in the DN, the information can be passed to the third party via the NEF. When using the NEF, the third party can appear as the AF. If the SMF determines that third-party authentication / authorization is required for the establishment of the PDU session but the UE does not provide authentication / authorization information, the SMF can reject the establishment of the PDU session.

[0170] In one implementation, the third party can authenticate / authorize the PDU session establishment and return the authentication / authorization result to the UPF.

[0171] In one implementation, the third party can authenticate / authorize the PDU session establishment and pass the authentication /

[0172] The authorization result is returned to SMF.

[0173] If the UE provides an application identifier to the SMF during the establishment of the PDU Session, the SMF may pass the application identifier to the

[0174] To a third party. The third party can perform application-specific authentication / authorization based on the application identifier.

[0175] The SMF can determine the application identifier based on the DN policy, the authorization based on the DN policy, the local configuration and the application identifier provided by the UE.

[0176] Determine whether to use UPF or NEF for at least one third-party certification.

[0177] At least one DN authentication and authorization occurs for the purpose of PDU session authorization, except in the following cases:

[0178] 5GC access authentication handled by AMF (in one embodiment, authentication may be performed according to the method described in clause 5.2 of TS23.501).

[0179] PDU Session Authorization related to subscription data that the SMF is forced to retrieve from the UDM.

[0180] Based on local policy, the SMF may initiate at least one of DN authentication and authorization as part of PDU session establishment.

[0181] If the UE provides an application identifier during the establishment of the PDU session and if the UPF is used for third-party authentication / authorization, the service redirection at the UPF can be configured based on the application identifier. If the UE provides an application identifier during the establishment of the PDU session and if the NEF is used for third-party authentication / authorization, the SMF sends the DNN, S-NSSAI and application identifier to the NEF, at which point the NEF can select an AF (e.g., a third-party authentication / authorization function) based on the information sent by the SMF (e.g., the received DNN, S-NSSAI and application identifier).

[0182] The UE can provide the SM information required to support third-party user authentication through NAS.

[0183] In some embodiments, when the SMF adds a PDU Session Anchor (such as the PDU Session Anchor defined in clause 5.6.4 of TS23.501) to a PDU Session, third party authentication and / or authorization may not be performed. In some embodiments, the SMF policy may require the SMF to notify third parties when new IP addresses have been added to or removed from a PDU Session, or when an existing ID address associated with a session is changed by modification or replacement of a prefix.

[0184] The indication of PDU session establishment rejection can be sent by the SMF to the UE via the NAS SM.

[0185] In some embodiments, the third party can revoke the authorization to the PDU session. In some embodiments, the third party can revoke the authorization to the PDU session at any time point.

[0186] See also Figure 5 , a signaling diagram is given to illustrate an embodiment of AS location or relocation notification.

[0187] In step 500, NEF 314 receives an AS location or relocation notification based on an application program interface (API) from AS controller 332. In the figure, the term (re)location refers to a location notification or a relocation notification. Similarly, the term (re)selection refers to selection or reselection, and its specific indication depends on the situation.

[0188] The notification may include the AS location appropriate for use therein, and may be considered during UP selection or reselection, as appropriate. In the case of AS relocation for an existing session, the notification may indicate the new AS location to use from that point forward. The notification may contain some or all of the following features:

[0189] The AS location, which may be specified using a network address of a known address such as an IP address, a MAC address, or some other type of identifying information.

[0190] Traffic diversion indicator, which indicates whether traffic diversion from UP 326 to AS should be configured by CP or handled by AS network 334.

[0191] Time information, which indicates when the AS (re)location is applied. In a non-limiting embodiment, the time information is empty, which means that the AS (re)location is performed immediately.

[0192] UE location information, which indicates that AS (re)positioning is applied when UE 102 is present in a specified location (e.g., geographic location). In a non-limiting embodiment, the location information is empty, which means that AS (re)positioning is performed without considering the UE location.

[0193] A service filter that indicates the service that the AS (re)locates may apply. The service may belong to an ongoing PDU session (ongoing service) or a future PDU session (future service). The service filter includes an application indicator that indicates the application associated with the service; and a UE indicator that identifies the UE 5 associated with the service.

[0194] The UE indicator may be an IP address associated with a service. In this case, the service is an ongoing service, and the AS controller 332 learns the IP address from the AS. The UE indicator may also be allocated by the CP 328 and exposed to the UE ID of the AS controller 332 through the NEF 314. In this case, the service may include ongoing services and future services.

[0195] Optionally, the UE indicator indicates more than one UE 102. Furthermore, a traffic filter may not include any UE indicator, which means that the AS (re)location applies to traffic for any (ie all) UEs 102 that meet the traffic filter definition criteria.

[0196] In one implementation, the received location information may include a geographic location. NEF 314 may be used to convert the received geographic location into a location associated with the network topology, such as a corresponding cell ID, and forward the cell ID as the UE location to SMF 310 or PCF 314 via AS (re)location. In one implementation, NEF 314 may be used to forward the geographic location as the UE location to SMF 310 or PCF 314.

[0197] Next, in step 502, if the AS controller 332 is not located in the trusted domain, the NEF 314 sends an authentication request to the authentication service function (AUSF) 312. If the AS controller 332 provides the AS controller identity information in the API-based AS (re)location notification step 500, the authentication request may include the identity information of the AS controller 332.

[0198] In optional step 504 (shown in dashed lines), the AUSF 312 obtains the identity of the AS controller 332. If the authentication request in step 502 does not include an AS controller identity, step 504 is performed.

[0199] In step 506, the AUSF 314 authenticates the AS controller 332 and sends an authentication response to the NEF 314. The authentication response indicates the authentication result.

[0200] If the authentication is successful, the NEF 314 acknowledges the notification and performs the next steps, which are determined based on whether the AS relocation applies to ongoing services or to future PDU sessions.

[0201] In one implementation, the process includes only one of process 508 (AS relocation for an ongoing PDU session) and process 510 (AS (re)location for a future PDU session). In one implementation, process 508 is not used, and process 510 is implemented for AS relocation of an ongoing PDU session, a future PDU session, or a combination of ongoing and future PDU sessions. In the case where process 510 is implemented for an ongoing PDU session, PCF 314 triggers SMF 310 to perform UP reselection by sending a UP reselection trigger to SMF 310 so as to reselect the corresponding UP for the ongoing PDU session. In an alternative implementation, process 510 is not used and only process 508 is used. In this alternative implementation, SMF 310 is used to perform AS relocation for future PDU sessions based on the receipt of an AS relocation notification sent by NEF 314, for example.

[0202] In general, process 508 may be performed for an ongoing PDU session (i.e., ongoing data service) in the case of AS relocation. First, NEF 314 identifies a PDU session associated with the service, and SMF 310 manages the identified PDU session, generates an AS relocation notification based on an API-based AS relocation notification, and in step 512, sends the AS relocation notification to the identified SMF 310. In one implementation, NEF 314 may identify SMF 310 by interacting with a network function repository function (NRF) 318.

[0203] After receiving the AS relocation notification, SMF 310 can determine whether to perform UP reselection for the affected services based on the new AS location of the PDU session, operator policy, and session and service continuity (SSC) mode.

[0204] In step 514A, if SMF 310 determines that UP reselection is not required, and if the AS relocation notification indicates the need for service diversion configuration, SMF 310 configures service diversion by updating service diversion at UP GW 336. Alternatively, in step 514B, if SMF 310 determines that UP reselection is required, SMF 310 initiates a UP reselection process. If necessary, SMF 310 may also configure service diversion at the reselected UP GW 336.

[0205] Typically, process 510 is performed in the case where the AS (re)location applies to future services. In step 516, the NEF 314 identifies the policy control function (PCF) 314 responsible for the operator policy for future services, generates an AS (re)location notification based on the API-based AS (re)location request, and sends the AS (re)location notification to the PCF 314. The NEF 314 can identify the PCF 314 by interacting with the NRF 318. In optional step 518, the PCF 314 configures the service redirection with the UP GW 336. In implementation, the configuration can be applied to all UP GWs 336 that may potentially be used to support the requested PDU session (current or future). Specifically, based on the AS (re)location notification, subscription data and current operator policy, the PCF 314 can generate a UP selection policy and a service redirection policy for the service. In implementation, optional step 518 is not performed because the service redirection can be configured separately during the UP (re)selection (i.e., step 514 or 516).

[0206] In one embodiment, where the AS (re)location notification indicates the possibility of future AS relocation, the PCF 314 may generate a Session and Service Continuity (SSC) mode selection policy, e.g., any PDU session associated with the application should have an SSC mode not equal to 1.

[0207] As will be readily appreciated by those skilled in the art, there are situations where AS (re)location may affect ongoing and future traffic flows. In this case, process 508 and process 510 may be performed.

[0208] In step 520, the NEF 314 sends an API-based AS (re)location notification confirmation back to the AS controller 332, either confirming the receipt of the AS (re)location notification, or rejecting the AS (re)location notification. In the case of rejection, the message includes an error code indicating the reason for the rejection. In implementation, the response includes a transaction token identifying the AS (re)location notification. The AS controller 332 can use the transaction token to later update the AS (re)location notification without providing full details and requesting at least one of the UPs affected by the AS (re)location notification (re)selection.

[0209] Figure 66 shows a UP (re)selection notification request process. In step 600, the NEF 314 receives an API-based UP (re)selection notification request from the AS controller 332. The API-based UP (re)selection notification request may include a transaction token from a previous AS (re)location notification process. The token may indicate that the current request corresponds to any UP (re)selection process affected by the AS (re)location notification. Alternatively, the request may include some or all of the following information:

[0210] Time information, indicating when the notification request is applicable. The time information may be empty, indicating that the notification request is to proceed immediately. UE location information, indicating that the notification request is to be applied when the UE 5 is present at a specified location (e.g., geographic location). The UE location information may be empty, indicating that the notification request proceeds regardless of the UE location.

[0211] A service filter indicating a data service to which the notification request can be applied. The service may belong to an ongoing PDU session (ongoing service) or a future PDU session (future service). The service filter may also include an application indicator indicating a specified application associated with the data service.

[0212] The service filter optionally includes a UE indicator, which indicates the UE 102 associated with the data service. The UE indicator can be an IP address associated with the data service. In this case, the data service is an ongoing service, and the AS controller 332 learns the IP address from the AS. The UE indicator can also be an ID of a UE assigned by the CN CP 328 and exposed to the AS controller 332. In this case, the data service can include ongoing services and future services. The UE indicator can indicate more than one UE 102. When the service filter does not include a UE indicator, it indicates that the notification request is applicable to the data service of any UE 102 that meets the criteria defined by the service filter.

[0213] After receiving the API-based UP (re)selection notification request, in step 602, if the AS controller 332 is not located in the trusted domain, the NEF 314 sends an authentication request to the AUSF 312. If the AS controller 332 provides information in the API-based UP (re)selection notification request, the authentication request may include identification information of the AS controller 332.

[0214] In optional step 604, the AUSF 312 obtains the identity of the AS controller 332. This step is performed if the authentication request 602 does not include identification information of the AS controller 332.

[0215] In step 606 , the AUSF 312 authenticates the AS controller 332 and sends an authentication response indicating the authentication result to the NEF 314 .

[0216] It should be noted that if the API-based UP (re)selection notification request includes a transaction token, each of the authentication request, obtain identification and authentication response steps is optional.

[0217] In step 608, the NEF 314 generates a UP (re)selection notification request based on the API-based UP (re)selection notification request and sends it to the PCF 314. The PCF 314 may verify the request, and if the request is valid, the PCF 314 may generate a UP (re)selection notification policy based on the received UP (re)selection notification request. In optional step 610, the PCF 314 may send a UP (re)selection authentication response to the NEF 314 to indicate the verification result.

[0218] In step 612, the NEF 314 sends an API-based UP (re)location notification response back to the AS controller 332, either confirming receipt of the AS (re)location notification, or rejecting the AS (re)location notification. In the case of rejection, the message includes an error code indicating the reason for the rejection. In implementation, the response includes a transaction token identifying the AS (re)location notification. The AS controller 332 can use the transaction token to later update the AS (re)location notification without providing full details and requesting at least one of the UP (re)selection notifications affected by the AS (re)location notification.

[0219] Figure 7 The UP (re)selection notification process is shown. If, after performing UP (re)selection, UP (re)selection notification is required as a result of the UP (re)selection notification request process (e.g., as described above), the SMF 310 initiates the UP (re)selection notification process.

[0220] In step 700, SMF 310 sends a UP (re)selection notification to NEF 314. The UP (re)selection notification may include at least one of a transaction token of a corresponding UP (re)selection notification request, an indication of an AS location, and an indication of a location of UP GW 336. For example, the location information may be in the form of a network address.

[0221] In step 702, NEF 314 generates an API-based UP (re)selection notification based on the UP (re)selection notification and sends it to AS controller 332. AS controller 332 transmits an acknowledgment of receiving the API-based UP (re)selection notification to NEF 314. Before sending the acknowledgment, AS controller 332 may perform necessary steps of the AS (re)location or AS state (re)location process, which may include releasing resources and data structures, configuring service control, etc.

[0222] In step 704 , the NEF 314 sends a UP (re)selection notification confirmation to the SMF 310 , confirming receipt of the API-based UP (re)selection notification confirmation received from the AS controller 332 .

[0223] Figure 8 A process for application-friendly PDU session establishment is shown. In step 800, the AS controller 332 initiates the AS (re)location notification process for future traffic associated with the UE 102 using the CP 328, targeting a specified application that generates application-aware UP selection policies and traffic steering policies.

[0224] In step 802, the AS controller 332 also initiates a UP (re)location notification request procedure for future traffic associated with the UE 102 using the CP 328, for a specified application that generates an application-aware UP selection policy and traffic steering policy.

[0225] In process 804, UE 102 may initiate a session establishment procedure when it has application traffic to send or receive from an application. In step 806, UE 102 sends a session request to SMF 310 via core access and mobility management function (AMF) 308. The session request may include a session ID and a preferred SSC mode (optional). The session request may also include an application identifier indicating that it is a dedicated session request for an application. In step 808, SMF 310 validates the UE context with UDM 320 and authorizes the session request based on the user subscription data.

[0226] If the session request is authorized, the SMF 310 initiates the UP selection process 810. In a first step 812, the SMF 310 obtains the operator policy from the PCF 314, including the application-friendly policy resulting from the AS (re)location notification step 800. In an optional step 814, the SMF 310 selects the SSC mode for the PDU session based on the session request, the operator policy, the UE type, and other necessary information. For example, if the request includes an application identifier but no preferred SSC mode, and if the operator policy indicates potential future AS relocation, the SMF 310 may set the SSC mode of the PDU session to 2 or 3 to allow UP reselection for a valid end-to-end path.

[0227] In step 816, SMF 310 interacts with UDM 320 to obtain the traffic steering capabilities between the candidate UP GW 336 and the AS location, and selects a UP path for the PDU session with respect to the operator policy based on the information provided by UDM 320. In step 818, SMF 310 triggers UP setup and configures traffic steering at UP GW 336 if the operator policy indicates that traffic steering configuration is required.

[0228] In step 820, SMF 310 sends a connection establishment request to AN 302 to connect to UP 326. In this step, AN 302 may allocate RAN resources for the PDU session.

[0229] If the operator policy indicates that UP (re)selection notification is required, then in step 822, SMF 310 notifies AS controller 332 of the UP selection through the UP selection notification procedure.

[0230] In step 824, SMF 310 sends a PDU session request response to UE 102 via AMF 308. If UE 102 did not provide a preferred SSC mode in the session request, the response includes the SSC mode selected for the PDU session. In step 826, traffic transmission occurs from UE 102 via UP GW 336.

[0231] Fig. 9 9 shows an application-aware UP reselection process for PDU session modification. In this process, in step 900, UE 102 includes an established PDU session carrying application traffic via UP-A 326A. Fig. 9 As shown, application traffic transmission 902 is through UP-A 326A.

[0232] SMF 310 receives a trigger for UP reselection for application services carried by a PDU session. The trigger may come from: AS relocation notification process 904, indicating a new AS location; handover process 906, indicating a new serving AN; or policy trigger 908 from PCF 314, indicating a policy change affecting UP selection for a PDU session.

[0233] In response to receiving the trigger, in step 910, the SMF 310 sends a session redirection message to the UE 102 via the AMF 308. This step is optional if the established PDU session is to be pre-serviced or reused according to the SSC mode configuration.

[0234] In step 912, UE 102 sends a session request for establishing a new session in response to the received session redirection. Note that this step is also optional because it only occurs when a session redirection message is received from SMF 310.

[0235] In step 914, SMF 310 uses the UP (re)selection procedure to establish UP-B 326B for the application service. Step 914 is similar to Figure 7 The UP selection process shown in and described above.

[0236] In the case where step 912 is optional, if the PDU session is not a dedicated PDU session for an application and has an SSC mode of 3, the SMF 310 may insert a branch point into the UP path so that UP-A 326A and UP-B 326B are two branches of the UP path. The SMF 310 instructs the branch point to divert traffic associated with the application to UP-B 326B, for example, based on a combination of a destination address or a destination address and a port number.

[0237] In step 916, SMF 310 sends a session response to UE 102 via AMF 308 to close the session request sent in step 912. If the ongoing PDU session is not a dedicated PDU session for an application and has an SSC mode of 3, the response should indicate the application service to be redirected to the new PDU session, for example, by a destination address or a combination of a destination address and a port number). UE 102 will perform the redirection of the service according to the redirection indication in the session response.

[0238] In step 918, SMF 310 establishes traffic redirection from UP-A 326A to UP-B 326B for the remaining traffic. In step 920, future application traffic is now continued through UP-B 326B.

[0239] In an embodiment, a system and method for SSC and UP management affecting applications for edge computing is provided. In this embodiment, it is assumed that the application (ie, AS) is deployed in the operator's local network, ie, the local DN.

[0240] See also Fig.10 , an application function (AF) 324 (non-3GPP function) is responsible for the AS (re)location (or AS (re)selection) within the local DN. The application function 324 interacts with the CP 328 via the NEF 314. The behavior of the application function 324 and the actual relocation of the application or application context are not yet defined under the current standards and are not relevant to this application.

[0241] CN CP 328 has information about the traffic steering capabilities between UPF 304 and AS locations. This information is provided by network management components, such as a network manager in management plane 330, and is used by NEF 314 to determine the suitability or preference of UPF 304 for an application.

[0242] SMF 310 is responsible for configuring traffic steering at UPF 304 to route UL traffic to the appropriate AS location in the face of AS (re)location.

[0243] The local DN is responsible for redirecting DL traffic to the appropriate UPF 304 in the face of UP (re)selection. The UPF 304 identifies the UE IP address associated with the DL traffic as a valid IP address. To ensure that the UPF 304 identifies the UE IP address, in some embodiments, each UPF 304 can use the same private IP address space.

[0244] DL traffic steering may be configured by application function 324 or implemented by upper layer mobility management mechanisms within the local DN. UPF 304 may identify the UE IP address in the DL traffic as a valid identifier. This may be implemented, for example, by applying the same private IP address space at UPF 304. As described above, in embodiments where IP addressing is not used, other address types or identifiers may be employed. The behavior of the local DN for traffic steering to DL is not germane to the following discussion.

[0245] Fig.10 The interface marked by a dotted line has not yet been defined under an existing standard, and how to construct it is not closely related to the following discussion.

[0246] This section describes the necessary interactions between CP 328 and application functions 324 to enable application-friendly UP management for applications that require an efficient end-to-end path.

[0247] In this example embodiment, it is assumed that NEF 314 authenticates and validates information received from application function 324. As will be appreciated by those skilled in the art, this responsibility may be moved to another function with corresponding changes in the control signaling.

[0248] Reference Fig.11A , a signaling diagram is given to illustrate an embodiment of application-influenced UP selection performed by SMF 310 as part of session establishment. In step 1100, the application function notifies the network of the application location of future application traffic associated with UE 102 through the procedures of the "Application (Re) Location Notification" service of NEF 314, where the UP selection policy and traffic steering rules are generated by PCF 314. In one implementation, the procedures of the Application (Re) Location Notification service of NEF 314 can be implemented using any number of different methods, including some of those described elsewhere in this application.

[0249] In step 1102, the application function 324 may subscribe to UP 326 (re)selection notifications for future application traffic associated with the UE 102 via the procedures (part 1) of the “UP (re)selection notification” service of the NEF 314, wherein the UP (re)selection notification policy is generated by the PCF 314. In an implementation, the procedures of the “UP (re)selection notification” service of the NEF 314 may be implemented. Step 1102 is an optional step, which may be determined by the application function 324. In some implementations, steps 1100 and 1102 may operate independently of each other.

[0250] In step 1104, UE 102 sends a session request including a local DN identifier to SMF 310. The request may include an application identifier, indicating that it is a dedicated PDU session for an application. The local DN identifier and the application identifier may be two parts of an integrated identifier (as a local DN identifier or an application identifier), or may be two separate identifiers.

[0251] In step 1106, SMF 310 verifies the UE context and authorizes the session request based on the user subscription data. In step 1108, SMF 310 obtains the operator policy from PCF 314, including the application-affected UP management policy generated by steps 1100 and 1102. In step 1110, SMF 310 selects an SSC mode for the PDU session based on the session request, operator policy, UE type and other necessary information. If the session request includes an application identifier and if the operator policy indicates application mobility (i.e., potential application relocation), SMF 310 may select SSC mode 2 for the PDU session. If the session request does not include an application identifier and if the operator policy indicates that the potential UE-accessed application has mobility, SMF 310 may select SSC mode 3 for the PDU session.

[0252] In step 1112, SMF 310 may select an end-to-end UP path for the PDU session in accordance with the operator policy. The end-to-end path in UP 326 may include an application location selected for the PDU session.

[0253] In step 1114, SMF 310 requests AN 302 to establish an N3 connection. In optional step 1116, AN 302 may allocate RAN resources for the PDU session.

[0254] In step 1118, AN 302 responds to SMF 310, indicating the completion of N3 connection establishment.

[0255] In step 1120, SMF 310 establishes the UP path. In step 1122, SMF 310 may configure traffic steering on the N6 interface at anchor UPF 304 of UP 326. In some embodiments, steps 1120 and 1122 may be combined in a single integrated configuration step, where UP setup and traffic steering configuration are performed together.

[0256] In step 1124, SMF 310 may notify application function 324 of the end-to-end UP path selection via the procedure (part 2) of the "UP (re)selection notification" service of NEF 314. The notification indicates the PDU session location and the application location. In some embodiments, the PDU session location may be used as the anchor UPF IP address. In other embodiments, the UE IP address may be used for the PDU session location. If step 1102 is not present or step 1102 does not indicate the need for UP (re)selection publication notification, step 1124 is optional.

[0257] In step 1126, SMF 310 sends a session response to UE 102 via AMF 308. The manner in which the PDU session establishment is performed may vary in different implementations. Those skilled in the art will appreciate that the procedure may be standardized and that the details of such a procedure are not necessarily closely related to the present application.

[0258] Fig. 11B An alternative embodiment is shown that includes an additional optional step 1128. In step 1128, the SMF 310 notifies the application function 324 of the end-to-end UP path selection via the "UP (re)selection notification" service procedure (part 2) of the NEF 314. The notification indicates the PDU session location and the application location. In some embodiments, the PDU session location is the IP address of the anchor UPF. In other embodiments, the IP address of the UE can be used as the PDU session location. Step 1128 is an optional pre-notification step, for example, if step 1102 is not present or if step 1102 does not indicate the need for a UP (re)selection pre-notification.

[0259] Fig. 12A and 12B 102 is a signaling diagram illustrating an embodiment of an application-influenced UP reselection process. The process does not change the UE's IP address and is therefore transparent to the UE 102. Fig. 12A and 12B The embodiment assumes that UE 102 already has an established PDU session via UP-A 326A.

[0260] Reference Fig. 12A In step 1200, the application function 324 subscribes to the UP (re)selection notification from the network for the application service associated with the PDU session through the "UP (re)selection notification" service procedure (part 1) of the NEF. Step 1200 is optional and depends on the requirements of the application function 324.

[0261] In step 1202, traffic transmission between UE 102 and UP-A 326A may continue.

[0262] In step 1204, the application function 324 may notify the network of the application relocation via the "Application (Re) Location Notification" service process of the NEF 314. Steps 1200 and 1204 may be independent of each other. The notification of the network may include the application function 324 sending a notification message to one or more network nodes, which in turn may provide a notification to the core network function that the application function 324 is inaccessible.

[0263] When necessary or desired, SMF 310 may modify the end-to-end UP path based on application relocation and local policies.

[0264] In process 1206, SMF 310 modifies the end-to-end UP path that requires UP reselection. In step 128, SMF 310 reselects UP-B 326B and traffic steering (via N6 interface) for the PDU session. If the SSC mode of the PDU session is 2, UP-B 326B is selected to replace UP-A 326A. If the SSC mode of the PDU session is 3, SMF 310 inserts a branch UPF or UL CLUPF into the UP path so that UP-A 326A and UP-B 326B are two branches of the UP path.

[0265] In step 1210, SMF 310 notifies the application function 324 of the UP reselection through the "UP (re)selection notification" service procedure (part 2) of NEF. If step 1200 does not exist, or if the application function 324 has already been notified about the UP (re)selection with the same content, step 1210 is optional.

[0266] In step 1212, the SMF 310 modifies the end-to-end UP path based on the UP reselection decision. This can be done using any of a number of different methods. The details of this method can be standardized, such as described in steps 8-11 of clause 4.3.5.X.2 of the current standard. In step 1212, the N3 connection can be modified, the branch UPF or UL CL UPF (if any) can be configured to redirect application traffic to UP-B 326B, and the N6 interface (traffic redirection) at the anchor UPF of UP-B is also configured. Traffic redirection at the branch UPF or UL CL UPF can be based on the destination IP address, destination port number, source IP address, or any combination thereof.

[0267] In step 1214, SMF 310 reconfigures traffic redirection without UP reselection. SMF 310 reconfigures the N6 interface at the anchor UPF of UP-A 326A to redirect application traffic to the new application location.

[0268] In step 1216, traffic transmission between UE 102 and UP-B 326B may continue.

[0269] In step 1218, if step 1206 occurs and the SSC mode of the PDU session is 2, the SMF 310 releases the PDU session resources associated with the UP-A 326A.

[0270] Reference Fig. 12B , in an alternative embodiment, from Fig. 12AStep 1200 may be performed after step 1204. In step 1220, traffic transmission between UE 102 and UP-A 326A may continue.

[0271] In step 1222, the application function 324 notifies the network of the application relocation through the "Application (Re) Location Notification" service process of the NEF 314. Steps 1200 and 1222 may be independent of each other.

[0272] In step 1224, the application function 324 subscribes to UP (re)selection notification from the network of application services related to the PDU session through the "UP (re)selection notification" service procedure (part 1) of the NEF 314. Step 1224 is optional and depends on the requirements of the application function 324.

[0273] In step 1226, SMF 310 performs end-to-end UP path reselection according to application relocation and local policy, which includes at least one of UP reselection and application location reselection.

[0274] In step 1228, the SMF 310 reselects the end-to-end UP path for the PDU session. If UP reselection is required, the SMF 310 reselects UP-B 326B for the PDU session. If the SSC mode of the PDU session is 2, UP-B 326B is selected to replace UP-A 326A. If the SSC mode of the PDU session is 3, the SMF 310 inserts a branch UPF or UL CL UPF into the UP path so that UP-A 326A and UP-B 326B are two branches of the UP path.

[0275] In step 1230, SMF 310 notifies the application function 324 of the end-to-end UP path reselection via the "UP (re)selection notification" service procedure (part 2) of NEF 314. The notification indicates the anchor UPF location and the new application location. This step is a pre-notification step. If step 1224 is not present or if step 1224 does not indicate the need for UP (re)selection pre-notification, it is optional.

[0276] In step 1232, the SMF 310 modifies the end-to-end UP path according to the decision of step 1228. In the case where UP-B 326B is selected for the PDU session, the SMF 310 modifies the end-to-end UP path as described in steps 8-11 in clause 4.3.5.X.2 of the current standard. In step 1232, the N3 connection is modified, the branch UPF or UL CL UPF (if any) is configured to redirect the application traffic to UP-B 326B, and the N6 interface (i.e., traffic redirection) is also configured at the anchor UPF of UP-B 326B. Traffic redirection at the branch UPF or UL CL UPF can be based on the destination IP address, the destination port number, the source IP address, or any combination thereof.

[0277] If UP reselection is not required, in step 1234, SMF 310 reconfigures the N6 interface at the anchor UPF of UP-A 326A to redirect the application traffic to the new application location.

[0278] In step 1236, SMF 310 notifies application function 324 of the end-to-end UP path reselection via the "UP (re)selection notification" service procedure (part 2) of NEF 314. Step 1236 is a post-notification step. If step 1224 does not exist or if step 1224 does not indicate a post-notification UP (re)selection requirement, it is optional.

[0279] In step 1216, traffic transmission between UE 102 and UP-B 326B may continue.

[0280] In step 1240, if the SSC mode of the PDU session is 2 and UP-B is selected for the PDU session in step 1228, the SMF 310 releases the PDU session resources associated with UP-A 326A.

[0281] Fig.13 is a signaling diagram illustrating an embodiment of an Application (Re)Location Notification Service procedure.

[0282] In step 1300, the NEF 310 receives an application (re)location notification request (application identifier, application location information, time validity condition, spatial validity condition, service filter, requester information) message from the application function 324. The application location information indicates the (new) application location and the status of the (new) application location. The application location is specified using an IP address. The time validity condition indicates when the notified application (re)location is to be performed. An invalid time validity condition means that the application (re)location is to be performed immediately. The spatial validity condition indicates that the application (re)location is only applicable to services associated with UEs located within the specified location. An invalid spatial validity condition means that the notified application (re)location is to be applied regardless of the UE location.

[0283] A service filter instructs the application to (re)select applicable services, which may belong to an ongoing PDU session or a future PDU session. An invalid service filter means that the application (re)selects all services that are applicable to the application associated with the application.

[0284] The service filter may explicitly indicate whether the service includes at least one of ongoing services and future services. The service filter may be described using an IP address associated with the service. It may also be described using a UE ID identified by both the application function and the network. The requester information includes a requester identifier.

[0285] NEF 314 notifies the selected CP function, i.e. SMF 310 or PCF 314, of the application (re)location. The notification includes the application (re)location notification service transaction identifier, the application identifier, the (new) application location, the identifier of the selected anchor UPF suitable for each of the (new) application locations, as well as time and space validity conditions, and service filters. Depending on the nature of the location information in the space validity conditions, NEF 314 may need to convert the location information into information understandable to the CP function. The service filter can be a conversion service filter described using a PDU session identifier. NEF 314 determines the anchor UPF suitable for selection based on the service steering capability between the UPF and the notified application location, which is provided by the management plane.

[0286] In process 1302, the notification relates to the case where the affected service belongs only to an ongoing PDU session. In step 1304, NEF 314 identifies the PDU session associated with the affected service and the SMF 310 that manages the PDU session, and sends the notification to SMF 310. NEF 314 identifies SMF 310 by interacting with UDM 320. In step 1306, SMF confirms receipt of the notification of NEF.

[0287] In process 1308, the notification may indicate that the affected service belongs to a future PDU session (and possibly also to an ongoing PDU session). In step 1310, the NEF 314 identifies the PCF 314 responsible for the operator policy of the PDU session and sends the notification to the PCF 314. The NEF 314 identifies the PCF 314 by interacting with at least one of the NRF 318 and the UDM 320. In step 1312, the PCF 314 confirms receipt of the notification to the NEF 314. In step 1314, the PCF 314 generates or updates a UP management policy based on the notification. If the affected service belongs to an ongoing PDU session, in step 1314, the PCF 314 identifies the SMF 310 of the service and notifies the SMF 310 of the policy change. In step 1318, the SMF 310 obtains a policy update from the PCF 314.

[0288] In step 1320, the NEF 314 sends an application (re)location notification response (result code) message to the application function 324. The result code indicates the acceptance or rejection of the request.

[0289] Fig.14 is a signaling diagram illustrating an embodiment of a UP (re)selection notification subscription service.

[0290] In step 1402, NEF 314 receives a UP (re)select notification subscription request ([transaction identifier] or [application identifier, time validity condition, space validity condition, service filter], notification type, requester information]) message from application function 324.

[0291] Alternative A [Transaction Identifier]: The subscription request corresponds to an existing application (re)location notification service transaction. The transaction identifier of the existing application (re)location notification service transaction, indicating that the subscription request applies to any UP (re)selection affected by the existing application (re)location notification service transaction. The NEF 314 may perform simplified authentication and validation by verifying the transaction identifier.

[0292] Alternative B [Application Identifier, Temporal Validity Condition, Spatial Validity Condition, Service Filter, Requester Information]: The subscription request is independent of the existing Application (Re) Location Notification Service Transaction. The temporal validity condition indicates when the subscription may be valid. Invalidation of the temporal validity condition means that the subscription is effective immediately. The spatial validity condition indicates that the subscription is only valid for services for UEs located within the specified location. Invalidation of the spatial validity condition means that the subscription becomes valid without regard to the UE location. The service filter indicates the services to which the subscription can be applied, which may belong to an ongoing PDU session or a future PDU session. Invalidation of the service filter means that the subscription applies to all services associated with the application. The service filter may explicitly indicate whether the service includes at least one of ongoing and future services. The service filter may be described using an IP address associated with the service. It may also be described using a UE ID that is recognized by both the application function and the network. The notification type indicates that pre-notification, post-notification, or both pre-notification and post-notification are requested. Pre-notification means that the notification is sent before the end-to-end UP path is configured; post-notification means that the notification is sent after the end-to-end path is configured. The requester information may include: a requester identifier, a requester IP address, and a requester port number.

[0293] NEF 314 requests the selected CP function, i.e., SMF 310 or PCF 314, to set up a UP (re)selection notification. The request may include a UP (re)selection notification subscription service transaction identifier, an NEF identifier, and subscription information in the request message in addition to the requester information. Depending on the nature of the location information in the spatial validity condition, NEF 314 may need to convert the location information into information understandable to the CP function. The service filter may be a converted service filter described using a PDU session identifier.

[0294] In process 1404, the affected service belongs only to the ongoing PDU session. In step 1406, NEF 314 identifies the PDU associated with the affected service and SMF 310 manages the PDU session, and sends the request to the identified SMF 310. In step 1408, SMF 310 responds to NEF 314, indicating the receipt of the request. NEF 314 identifies SMF 310 through interaction with UDM 320.

[0295] In process 1410, the affected service belongs to a future PDU session (as well as an ongoing PDU session). In step 1412, NEF 314 identifies the PCF 314 responsible for the operator policy of the PDU session associated with the affected service and sends the request to the identified PCF 314. In step 1414, PCF 314 responds to NEF 314, indicating the receipt of the request. NEF 314 identifies PCF 314 by interacting with at least one of NRF 318 and UDM 320. In step 1416, PCF 314 generates or updates UP management policy according to the request. If the affected service belongs to an ongoing PDU session, in step 1418, PCF 314 identifies the service of SMF 310 and notifies SMF 310 of the policy table update. In step 1420, SMF 310 obtains the policy update from PCF 314.

[0296] In step 1422, the NEF 314 sends a UP (re)select subscription response (result code) message to the application function 324. The result code indicates the acceptance or rejection of the request.

[0297] After performing end-to-end UP (re)selection for the affected services, in step 1424, SMF 310 notifies NEF 314 of the UP (re)selection. The notification may include information such as UP (re)selection notification subscription service transaction identifier, notification type, PDU session location, anchor UPF location, and application location. In some embodiments, the PDU session location may be one of the anchor UPF address or UE address of the PDU session. In some embodiments, these addresses are IP addresses. The application information may be in the form of an IP address or another such identifier.

[0298] In step 1426, NEF 314 sends UP (re)select information to application function 324 using the requester IP address and the requester port number.

[0299] In step 1428, the application function 324 responds to the NEF 314 to confirm the delivery of the notification. If the notification type is pre-notification, the response indicates whether the network should continue with the end-to-end path configuration.

[0300] In the case of pre-notification, the application function 324 can perform the necessary steps of the application (re)location or application state (re)location process, which may include releasing resources and data structures, etc. If the application function 324 wants to cancel the application (re)location, the application function 324 notifies the network using a response message. If the notification type is post-notification, the application function 324 knows that the end-to-end UP path is ready for use and can start steering DL traffic to the path.

[0301] In step 1430 , NEF 314 responds to SMF 310 to confirm delivery of the notification. The response includes the information received from application function 324 in step 1428 .

[0302] In some embodiments, application functionality may affect traffic routing.

[0303] Information about the UE whose traffic is to be routed.

[0304] The information used to identify the UE 102 may be a fixed identifier or a dynamic identifier.

[0305] Fixed identifier

[0306] SUPI, PEI described in clause 5.9 of TS23.501: Since edge computing applications may be located in untrusted domains, these identifiers should not be disclosed to third-party edge computing applications.

[0307] MSISDN: Can be used for third-party edge computing

[0308] External identifier: can be assigned by the operator or edge computing application

[0309] Dynamic Identifiers

[0310] Temporary identifier: allocated during the UE mobility registration procedure

[0311] IP address: Assigned during the session establishment process

[0312] The above two identifiers can be used to identify UE 102 with an active PDU session. However, these identifiers may be changed due to UE mobility or UPF reselection. In addition, if the PDU session is of non-IP type, the IP address is not applicable. Therefore, these dynamic identifiers may not be suitable for edge computing applications.

[0313] Proposal 1: An external identifier or MSISDN is used to identify the UE whose traffic is to be routed.

[0314] 2 Identifier for UE group

[0315] In some scenarios, the service routing update may be applied to a group of UEs. If there are a large number of UEs and the UE identifier is included in the message sent from the edge computing application to the CN, the message should be large. Some alternative approaches should be proposed. Some possible approaches are given below.

[0316] Geographical regions: The coverage of a PLMN can be divided into zones, each with a zone identifier (ZID). Operators can inform edge computing applications of the mapping between geographic locations and ZIDs. There is no need to standardize ZIDs.

[0317] IP prefix: A range of IP addresses can be assigned to a group of UEs for a given application. IP ranges can be reserved to indicate UE groups. However, this solution is not suitable for non-IP traffic types.

[0318] Domain network name (DNN): Each edge computing application can have a unique name identified by CN. DNN can indicate the UEs that can access the DNN.

[0319] Application identifier (AID): If a DN provides multiple applications, each application may have an application identifier. The application identifier may be represented by the application server port of the IP service.

[0320] A combination of any of the above attributes may be used to identify a UE group.

[0321] Proposal 2: The combination of DNN, AID and ZID can be used to identify a group of UEs.

[0322] 3. Information about where to route the traffic: This can be either (or both) the DNN of the local data network and the IP address of the application server.

[0323] Proposal 3: The IP address of the DNN or application server of the local data network can be used to indicate the routing destination.

[0324] 4. Potential location of the application regarding where the traffic routing should be applied: The potential location of the application can be the DNN of the local data network hosting the application server.

[0325] Alternatively, the IP address of the application server may be used. The network management entity may configure the capabilities of the CP regarding the transport link between the UPF and the application server. There is a separate contribution to clarify this issue.

[0326] Proposal 4: The IP address of the DNN or application server of the local data network can be used to indicate the potential location of the application for traffic routing.

[0327] 5. Information used to identify the traffic to be routed

[0328] Once the UE 102 is identified, additional information may be used to identify traffic to be routed.

[0329] DN provides 1 application: If DN provides only one application, then DNN can be used to identify PDU session. DN provides multiple applications: Each application should have an application identifier (AID). For IP services, AID can be the port number of the application server.

[0330] Proposal 5: If a DN provides one edge computing application, then the DNN can be used to identify the PDU session. If a DN provides multiple applications, then each DNN and AID is used to identify the PDU session.

[0331] The application function request may be routed to the SMF via another control function such as the NEF or PCF.

[0332] a. In EPC, the Rx interface between PCRF and application functions is used to support third-party applications:

[0333] Example: IMS and public safety application functions.

[0334] Security: These applications are considered to be in the 3GPP trusted domain. There are no major security issues.

[0335] The information received through the Rx interface is used by the PCRF. This means that the PCRF processes the received information to make policy decisions.

[0336] b. Edge computing application security in 5G CN: Edge computing application control functions may be located in untrusted domains. Therefore,

[0337] Requests from application control functions. Currently agreed NEF functions include authentication / authorization functions, but not PCF. For edge computing applications, information from the application control function can be used by the SMF for possible reselection of the UPF; the PCF does not process this information. Therefore, the application control function should not send its requests to the PCF.

[0338] Proposal 6: NEF is used as an interface between the application control function and the CN CP function.

[0339] Application functions can send requests via NEF to influence SMF routing decisions for PDU session traffic. This may affect UPF selection and allow user traffic to be routed to the data network local access.

[0340] Such a request may contain at least:

[0341] In some implementations, the request may include information identifying the traffic to be routed.

[0342] If a DN provides multiple applications, the DNN and AID (Application Identifier) ​​are used to identify the PDU session.

[0343] In some implementations, the port number of the application server can be used as the AID. Information about where to route the traffic. The DNN of the local data network or the IP address of the application server can be used to indicate the routing destination. The potential location of the application to which the traffic routing should be applied. The DNN of the local data network or the IP address of the application server can be used to indicate the potential location of the application for traffic routing. When the application function is the only application function hosted in the local DN, or if there is no chance of confusion, the DNN can identify the traffic; otherwise, a combination of the DNN and application identifier or traffic filtering information can be used to identify the application traffic.

[0344] Note 1: The mapping between the application identifier and the service filtering information (eg, the IP address of the application function receiving the service) can be configured in the NEF.

[0345] - In some implementations, the request may include information about where to route the traffic, such as the DNN (eg, if all traffic for a PDU session is routed to an application function) or the IP address of the application function.

[0346] - In some implementations, the request may include the potential location of the application to which the traffic routing should be applied. The potential location of the AF may be indicated using the IP address that handles the AF traffic, which the NEF (or the AF if trusted by the operator, as described in 6.2.X) maps to a specified PDU session anchored to the local DN.

[0347] NOTE 2: The IP address used to identify the instance handling the AF service may be different from the IP address of the same AF instance used by the UE to interact with it.

[0348] In some implementations, the request may include information about the UEs whose traffic will be routed. Individual UEs may be identified using external identifiers or MSISDNs. Groups of UEs may be identified by the DNN, which have active PDU sessions, and possibly application identifiers or traffic filtering information. Additionally, a region identifier may be included to restrict the group of UEs to a particular geographic region.

[0349] Note 3: The regional identifier can be mapped to a geographical area. The mapping is configured in the NEF and AF. The external identifier or MSISDN is used to identify individual UEs. DNN, AID (Application Identifier) ​​and ZID (Zone Identifier) ​​or any combination of them can be used to identify a group of UEs

[0350] In some implementations, the request may include information about when (a time indication) the traffic routing is to be applied.

[0351] It is assumed that the application function 324 issuing such a request belongs to the PLMN serving the UE 102. The application function 324 may issue the request on behalf of other applications not owned by the PLMN serving the UE 102.

[0352] SMF 310 may take into account the following information based on local policy:

[0353] (Re)selection of UPF for PDU session.

[0354] Activate mechanisms for traffic multi-homing or UL Classifier (UL CL) implementation. Such mechanisms are defined in subclause 5.3.5.

[0355] Definition. It may include providing traffic forwarding (e.g. burst) rules to the UPF.

[0356] Notify UP path (re)selection function.

[0357] According to a particular implementation of the present invention, a method and system for traffic routing are provided, wherein a spatial validity condition is added as part of the information provided by the AF.

[0358] AF 324 can provide information to one or more nodes or functions within the CN to influence UP path (re)selection decisions, including for edge computing scenarios. However, it is usually considered whether the information provided by the AF is the same as the information used in the CN for UP path (re)selection, in other words, whether information mapping / processing is required. The following table compares the advantages and disadvantages when mapping / processing is required and not required.

[0359]

[0360]

[0361] Based on the information provided in the above table, some embodiments include one or both of the following two alternatives for the impact of AF on service routing:

[0362] (1) In the case where AF 324 interacts with core network functions via NEF 314, the information provided by AF 324 and the information used in the core network may be different. In such an embodiment, NEF 314 may be configured to perform information processing / mapping.

[0363] (2) In the case where AF 324 interacts directly with the core network function, AF 324 can implement the information processing function of NEF and provide information to the CN function in a format that can be used in the core network.

[0364] In some applications, such as MTC applications including event monitoring applications or crowd sensing applications, it may be necessary to route UL data associated with the application to the same application location for collection, processing, and decision making. For example, data may be routed to the same application location in order to process the data, identify any data correlations, perform information aggregation, and make decisions or output results to allow operators or third parties to review and take action. In this case, the impact of AF on traffic routing can be subject to spatial validity checks, for example, when applying traffic routing, the location of the UE satisfies the spatial constraints.

[0365] Therefore, according to some embodiments, spatial validity conditions are included in the information provided by the AF to the CN, which is independent of the conditions affecting UP (re)selection.

[0366] According to some embodiments, the interaction between the CP and the application environment can be defined or adjusted as a policy in order to benefit from a unified policy framework. In some embodiments, the interaction between the CP and the application environment results in policy generation or policy update. The policy is a UP management policy, which includes a service routing policy. The PCF-based approach allows the PCF to maintain a global view of UP management, thereby solving the global consistency optimization in UP management.

[0367] The AF may send requests to influence SMF routing decisions for services for one or more PDU sessions. In some implementations, the AF sends requests to the PCF to influence these SMF routing decisions. This may influence the UPF selection process and allow user services to be routed to local access to a data network (DN). Those skilled in the art will appreciate that, in this document, reference is made to the routing of services, and local access to a DN may be understood to include the transmission of services to a local access point that may provide access to the DN in question. The local access point may be a local access point to a CN (or a segment of a CN), or it may be a local access point to a DN. Topologically, the local access acts as a connection to the DN.

[0368] In some implementations, the AF may be responsible for, or act as a decision-maker for, the (re)selection or relocation of applications within a local DN. In some implementations, such an AF may receive notifications about events related to PDU sessions (and in some embodiments, may receive information associated with applications having real-time PDU sessions, or applications having authorization to initiate PDU sessions through or with the AF).

[0369] In some implementations, the AF may send (re)selection or relocation requests associated with applications hosted by the DN independently of each other. Assuming that the AF issuing such a request belongs to the network (e.g. PLMN) serving the UE. The AF may then issue the request on behalf of other applications that are not owned or hosted by the network (e.g. PLMN) serving the UE.

[0370] If the AF is within the CN's trust domain, it can interact directly with the PCF. If the AF is outside the trust domain, it can interact with the PCF via the NEF, and the NEF can in turn interact with the PCF and act as an AF within the trust domain on behalf of the actual AF outside the trust domain. In some embodiments, the NEF can act as an AF on behalf of the actual AF residing within the trust domain.

[0371] In the scenario where the AF interacts with the PCF via the NEF, the information provided by the AF and the information used in the 5G core (5GC) network may have different formats or be different in nature (e.g., contain different information elements). In some implementations, the NEF may be configured to perform information conversion / mapping. In the case where the AF interacts directly with the PCF, the AF may provide information available to the 5GC without information conversion.

[0372] A request to influence the SMF routing decision for services for a PDU session may be sent by the AF. The application function may send an application location notification message to the PCF. The message may include at least:

[0373] Information used to identify the service to be routed. For example, DNN and application identifier or service filtering information can be used to identify the service to be routed.

[0374] Identify the service. In some implementations, the service may be identified in the AN request of the DNN. The DNN may be used to identify the service of the PDU session, as well as the application identifier to indicate the specific service of the PDU session. In the case of IP services, in some embodiments, service filtering information (e.g., may include source and destination addresses, and

[0375] The IP 5-tuple of the port numbers at each of the source and destination, and the protocol being used). In some implementations, the slice information (e.g., S-NSSAI) can be part of the service filtering information or a separate element in the AN request.

[0376] If the AF interacts directly with the PCF, it can indicate the dynamic network access identity.

[0377] The AF may include a routing profile containing a list of DNAIs, each of which may include local access to a DN, and N6 service routing parameters associated with each DNAI. If the AF interacts with the PCF via the NEF, it may indicate at least one of the DNN and the application address in its communication. In one embodiment, the N6 service routing parameters may be configured in the UPF to support a service steering mechanism or implementation in a local DN.

[0378] The potential location of the AF can be used to determine where the service routing should be applied. For example, the potential location of the AF can be used for UPF selection. If the AF interacts directly with the PCF, information related to the potential location of the AF (in absolute terms or topological terms) can be provided by the DNAI in the above routing configuration file. If the AF interacts with the PCF via the NEF, information about the potential location of the AF can be provided by the host address of the application.

[0379] Information about the UEs whose traffic is to be routed. This may correspond to a single UE, all UEs, a group of UEs, a subset of connected UEs, or another such grouping. A UE or group of UEs may be identified using any one or a combination of an external identifier, an external group identifier, an MSISDN, an IP address, or an IP address prefix.

[0380] Time validity information is used to indicate when the service route is applied. In some implementations, the lack of time validity information may

[0381] Meaning that the traffic routing should be applied immediately. It should be understood that if the time validity information is omitted, other default conditions may be applied.

[0382] Spatial validity information, indicating any location-based criteria (eg, the geographical location where the UE should be located) that should be used to determine whether to apply traffic routing. If this information is missing, default conditions may be applied.

[0383] In some implementations, the AF may interact with the PCF via the NEF. In this case, the NEF may be configured to convert the "information about potential locations of applications where business routing should be applied" and "information about where to route the application" in the message into a routing profile, and provide the PCF with the routing profile or an indication of the routing profile. If the routing profiles can be sorted and put into an index list, only the index needs to be provided.

[0384] In some implementations, the PCF may authorize a request received from the AF and determine a service redirection policy based on the request based on information received (e.g., from the AF or NEF), which may be predefined operator policies, and input from other entities (e.g., user subscription, user quota, user's current RAT, network load status, time, UE location, APN, etc., which may be received from other network entities such as CSM entities, HSS, service engineering functions, or from any number of control and management plane entities). The service redirection policy may indicate an appropriate service redirection profile from a set of profiles. Each profile may specify a UPF and N6 service routing parameters that provide service redirection. This may implicitly indicate a unique DNAI to be configured in the UPF.

[0385] In implementation, PCF can provide business steering strategies to SMF. SMF can take this information into account according to local policies, taking into account at least one of the following:

[0386] (Re)select the UPF for the PDU session. The SMF may perform a service steering profile selection when (re)selecting the UP path. Because a service steering profile may be implicitly mapped to a unique DNAI (via the N6 service routing parameter in the profile), service steering profile selection may imply mapping the UE location (TAI / Cell-Id) to the DNAI in addition to the UPF selection.

[0387] Activate mechanisms for service multi-homing or UL Classifier (UL CL) enforcement. This may include providing service forwarding to the UPF.

[0388] (e.g., burst) rules; and

[0389] Configure N6 service routing in the anchor UPF according to the selected service steering profile.

[0390] refer to Fig.15 In an embodiment of the application (re)location notification process, connection information (including connection quality, such as number of hops, performance, such as delay, delay jitter, throughput or attributes, such as supported protocols and protocol parameters including protocol headers) between a DNAI (e.g., DNAI-1 or DNAI-2) and each application host can be configured in NEF 314 by a management plane entity, such as a network manager, a slice manager, or a service manager. Alternatively, the connection information can be provided to NEF 314 by AF 324. In some embodiments, the connection information of the DNAI with the application host can also be referred to as routing requirements or routing profiles. In other embodiments, the connection information can be part of a routing profile.

[0391] If the AF 324 is not in a trust domain (e.g., not within the CN or in a network trusted by the CN), the AF 324 may interact with the PCF 316 via the NEF 314. In this case, the AF 324 may provide the potential host location of the application (or a set of locations associated with the application) to the NEF 314 in a message such as an application location notification message. The NEF 314 may select a suitable DNAI associated with the application based on the above information and the connection information. In some implementations, the NEF 314 may also perform the selection based on the QoS requirements associated with the application toward an end-to-end connection (permanently or based on a specific session). The QoS requirements may be provided by the AF 324 along with other data such as an application location notification message, or may be sent separately. The NEF 314 may indicate the selected DNAI and corresponding connection information (part or all of the selected) to the PCF 316. In some implementations, the connection information (or routing profile, or routing requirements) indicated by the NEF 314 may be configured in the PCF 316 through a management plane function such as a network manager, a slice manager, or a service manager. In this case, the NEF may only need to indicate the connection identifier (or routing requirement identifier, or routing profile identifier) ​​to the PCF. Based on the provided connection identifier, the PCF 316 can identify the details from its local configuration. In some implementations, the PCF 316 can obtain the connection information (or routing profile, or routing requirement profile) from the NEF in advance. In some implementations, the NEF 314 obtains the connection information (or routing profile, or routing requirement profile) from the AF 324.

[0392] In the case where the management plane function is used to configure the CP function, for example, a configuration change to be applied to the NEF 314, the configuration may be changed after receiving a request sent by the AF 324. In some implementations, the management plane function may utilize an alternate path to configure the CP function. Where traditionally the management plane function would configure the CP function through an "element management" system in the management plane, in an embodiment of the present invention, the configuration information may be sent to the CP function through the NEF 314. In this scenario, the management plane function may be considered to act as an AF sending messages to the NEF. This allows the NEF 314 to forward configuration information or instructions without using the element management system interface.

[0393] A DNAI may be associated with one or more UPFs 304. The association may be based on the service area of ​​the UPF 304 or the service area of ​​the DNAI. For example, a UPF 304 may be associated with a DNAI located within the service area of ​​the UPF 304. In other examples, a UPF 304 located within the service area of ​​the DNAI is associated with the DNAI. It should be understood that the service area may be defined based on a geographic area, or may be determined by a topological function associated with a mobile network area. In some embodiments, the association of the UPF 304 and the DNAI may be based on virtualization. In this case, the DNAI may be associated with a virtualized environment or platform (in some embodiments, the DNAI itself may form an environment or platform). In such an embodiment, the instantiation of a virtual UPF in the virtualization associated with the DNAI is associated with the DNAI. A UPF 304 may be associated with one or more DNAIs.

[0394] Since the association between UPF 304 and DNAI may be predefined, when NEF 314 sends an indication of a suitable DNAI to PCF 316, it implicitly indicates a suitable UPF 304. In some scenarios, selecting a DNAI may result in implicitly selecting a subset of available UPFs 304.

[0395] A service redirection profile may be defined between the DNAI and each UPF 304 associated therewith. The service redirection profile may be used to describe service redirection behavior (including at least one of service redirection performance, such as delay, throughput, maximum allowed PDU session, etc., and

[0396] The routing parameters include the protocol header of the UPF traffic towards the DNAI. The profile may be configured in the PCF 306 by a management plane entity such as a network manager, a slice manager, or a service manager. In some embodiments, the traffic steering profile may be configured in the UDM 320 (Unified Data Management) or DSF (Data Storage Function - e.g., UDR 322), and the PCF 316 needs to obtain it by indicating the DNAI and the UPF 304 to the UDM 320 or DSF (e.g., UDR 322).

[0397] Based on the routing profile, PCF 316 may select a traffic steering profile (e.g., those that provide matching QoS performance or required protocol support). The selected profile (sometimes referred to as an appropriate traffic steering profile, or a selected appropriate traffic steering profile) or an indication of the selected profile may be sent by the PCF to the SMF. The SMF may execute or begin implementing the received traffic steering policy during session establishment or session modification (or in response to session establishment or session modification). If a traffic steering profile is also configured in the SMF, in some embodiments, the PCF will only need to indicate a traffic steering profile identifier. If a traffic steering profile is not configured in the SMF, the PCF 316 may need to provide the contents of the traffic steering profile to the SMF. In some embodiments, the SMF 310 is indicated by the traffic steering profile identifier sent by the PCF 316, and the indicated SMF 310 may obtain the traffic steering profile contents from a third CP function, such as the UDM 320 or the DSF (e.g., the UDR 322).

[0398] AF 324 may send a request to subscribe to UP path (re)selection notifications from SMF. The subscription may be for at least one of pre-notification and post-notification. In the case of subscribing to pre-notification, SMF 310 sends notifications before performing UP path (re)selection. In the case of subscribing to post-notification, SMF 310 sends notifications after UP path (re)selection is completed.

[0399] The AF 324 request to subscribe to the UP path (re)selection notification from the SMF may contain at least:

[0400] In an implementation, service identification information associated with the subscription may be provided. In an implementation, if the AF is the only AF hosted in the local DN, the DNN may identify the service; otherwise, a combination of the DNN and service filtering information may be used to identify the application service. In an implementation, the DNN may identify the service based on at least one of: an AF request, an application identifier, and service filtering information. In an example, the DNN may be used to identify the service of a PDU session, and the application identifier may be used to indicate a specific service of the PDU session. In the case of IP services, in some embodiments, service filtering information (e.g., an IP 5-tuple as described above) may be included.

[0401] Information about UEs whose services are related to the subscription. This may correspond to a single UE, all UEs and groups of UEs identified using an external identifier, external group identifier, MSISDN, IP address or IP address prefix.

[0402] Information about when (temporal validity conditions) the subscription should apply. Absence of this information may mean that the subscription should take effect immediately. Information about any spatial validity conditions (geographic location where the UE should be located) to determine if the subscription applies. Absence

[0403] Lack of this information probably means using the default configuration.

[0404] In some embodiments, the PCF 316 can authorize requests received from the AF and provide or select a UP path (re)selection event notification policy based on information received from the AF (or NEF), the operator's policies and input from other entities (e.g., user subscription, user's quota, user's current RAT, network load status, time of day, UE location, APN, etc.).

[0405] In some embodiments, PCF 316 may provide UP path (re)selection event notification policy to SMF 310. SMF 310 may consider this information based on local policy to notify AF 324 to (re)select UP path (change of traffic steering).

[0406] UP (re)selection of notification subscriptions may occur in a chain, for example, when the AF subscribes to the NEF, which in turn subscribes to at least one of the SMF and PCF. In the middle of such a subscription chain (e.g., the NEF in the example above), the CP function will send notifications along the chain (in some examples, this may be a relayed received notification). The CP function may maintain its role in the subscription chain, with a mapping between the subscription context in the previous CP function and the next CP function in the chain. Before relaying the notification, the CP function may process the notification and may enhance or enrich the information in the notification, reduce or simplify the information in the notification, or translate / convert the information in the notification.

[0407] The SMF 310 may notify the subscriber network function of the UP (re)selection notification (and the subscription identifier in the UP (re)selection notification policy provided by the PCF). In other embodiments where such notification is not required or where the subscriber network function can obtain the information through other functions, the SMF 310 may be configured not to send the notification message.

[0408] In some implementations, the subscriber network function identifier may indicate a network address associated with the subscriber network function. In some implementations, the SMF interacts with the subscriber network function directly using the subscriber network function identifier (e.g., via IP routing in the case where the identifier is an IP address). In some implementations, the SMF maps the subscriber network function identifier to some routing information (e.g., tunnel information) and uses the notification to interact with the AF. In some implementations, the SMF maintains this mapping through, for example, configuration from a management plane function; in some embodiments, the SMF obtains the mapping by interacting with a third CP function, such as an NRF or UDM, by providing the subscriber network function identifier to the third CP function and responsively obtaining the mapping.

[0409] In the case where the AF 324 is in a trusted domain (i.e., when the AF interacts directly with the PCF):

[0410] In some embodiments, the subscriber network function to which the SMF 310 sends the notification is the AF 324, and the notification contains the PDU

[0411] In some embodiments, the UPF identifier indicates the address of UPF 304. In some embodiments, the subscriber network function to which SMF 310 sends the notification is PCF 316, and the notification indicates the selected anchor UPF for the session.

[0412] The selected traffic steering profile (e.g., via a traffic steering profile identifier). The PCF 316 then identifies the corresponding DNAI and indicates the DNAI (along with the subscription identifier in the UP (re)selection notification request message) that the PCF 316 is performing information conversion on to the subscriber AF 324. In some embodiments, the DNAI is in the format of a network address.

[0413] In the case where the AF 324 is not in a trusted domain (i.e., when the AF interacts with the PCF via the NEF):

[0414] In some embodiments, the subscriber network function to which the SMF sends the notification is the NEF, and the notification indicates the

[0415] The NEF may determine the address of the UPF to be exposed and the corresponding application host, and may send the information to the subscriber AF (in some embodiments, this may be done together with the subscription identifier in the UP (re)selection notification request message received from the AF). In this case, the NEF may be considered to be performing at least one of information conversion and information enrichment.

[0416] In some embodiments, the subscriber network function to which the SMF sends the notification is the PCF, and the notification indicates the selected business

[0417] The PCF may then identify the corresponding DNAI and provide an indication of the DNAI to the subscriber NEF (along with the subscription identifier), which may then determine the address of the DNAI to be exposed and the corresponding application host, and notify the subscriber AF of this information (along with the subscription identifier in the UP (re)selection notification request message received from the AF) - the PCF, and in some embodiments, the NEF may be considered to perform at least one of information conversion and information enrichment.

[0418] The AF can send the above two types of requests independently. In some implementations, it is assumed that the AF that issues such a request belongs to the PLMN serving the UE. The AF can issue requests on behalf of other AFs that are not owned by the PLMN serving the UE. The core network of the 5G network can use the network exposure function to expose network information and capabilities to allow the AF to interact with the CNF to affect UP path management and service routing directly or through the NEF.

[0419] In the case where the AF interacts with the CNF via the NEF, the information provided by the AF and the information used in the CN may be formatted or organized differently. In this case, the NEF may be configured to perform information processing / mapping.

[0420] In the case where the AF interacts directly with the CNF, the AF can provide information available to the CNF without processing / mapping. The information provided by the AF is converted by the PCF into an application-affected UP management policy including N6-related service routing rules.

[0421] This is then routed to the SMF. The SMF may take this information into account based on local policy:

[0422] (Re)Select the UPF for the PDU session.

[0423] Activate mechanisms for traffic multi-homing or UL Classifier (UL CL) enforcement. This may include, for example, providing the UPF with

[0424] Provides traffic forwarding (eg, burst) rules.

[0425] Notify the application function to (re)select the UP path.

[0426] The AF may request notification of location information about the UE.

[0427] In some embodiments, a system and method for routing application traffic between a PDU session anchor and a traffic processing AF supporting edge computing is provided.

[0428] When an edge computing application includes mobility functionality (e.g., the ability to move around via edge computing resources, typically tracking the UE associated with the application), the network address of the application in the PDU header may be different from the address of the hosting application location. This is because application relocation is a network behavior that is not necessarily known to the UE. Because the PDU header cannot be used to enable routing (through the N6 interface) in this case, it is equivalent to an unstructured PDU in the UL. Beyond this, the use of unstructured PDUs may be application-dependent and may occur in any edge computing application. Therefore, in some embodiments, edge computing application services are treated as unstructured PDUs to have a unified edge computing framework.

[0429] In some embodiments, the local DN may be responsible for routing application traffic between the PDU session anchor and the traffic processing AF. Specifically, the local DN may implement the N6 interface to ensure session and service continuity in the presence of UE / application mobility. In some embodiments, the local DN provides N6-related traffic routing information to the core network for configuration in the PDU session anchor, i.e., the anchor UPF for the PDU session associated with the edge computing application.

[0430] Edge computing enables operator and third-party services to be hosted in the local data network, close (at least one of physically and logically (topologically)) to the UE's attachment (R)AN. The close location of edge computing services allows efficient service delivery because service traffic is limited to the link between the UE attachment point (e.g., access node) and the edge computing resources. This results in lower end-to-end latency for traffic between applications and UEs. In addition, with the reduction of cross-network service traffic, the entire transport network may experience reduced load.

[0431] In some embodiments, a method is provided in which a UE requests a dedicated PDU session for a service associated with an edge computing application. In some implementations, the UE may send a request to the SMF to select whether the dedicated PDU session can be used for a single edge computing application or shared by multiple edge computing applications. In some implementations, the UE may send the request to the SMF during the PDU session establishment process.

[0432] The 5G CN function can select a UPF close to the UE and perform service redirection from the UPF to the local data network via the N6 interface. The selection can be based on the UE's subscription data, location, policy or other relevant service rules.

[0433] Due to user or AF mobility, service or session continuity may need to be provided based on service or 5G network requirements.

[0434] The local data network is responsible for the correct implementation of the N6 interface to ensure service or session continuity in the presence of at least one of UE mobility and AF mobility, and to provide N6-related traffic routing information to the network.

[0435] The 5G core network can adopt network functions that allow network information and capabilities to be exposed to edge computing AF.

[0436] It should be noted that depending on the operator deployment, some AFs may be allowed to interact directly with the control plane network functions they need to interact with, while other AFs need to use an external exposure framework via the NEF.

[0437] In some embodiments, edge computing-enabled functionality may include, for example:

[0438] Local routing: The core network function can select UPF to route user services to the local data network and use N6 related

[0439] Configure UPF with service routing information.

[0440] Traffic steering: The core network function can select traffic to be routed to application functions in the local data network.

[0441] Session and service continuity to enable UE and AF mobility.

[0442] User plane selection and reselection, for example, based on input from the AF.

[0443] Network capability exposure: Many core network functions can exchange information (e.g., information about the capabilities of the function) with the AF through the NEF.

[0444] QoS and charging: PCF provides QoS control and charging rules for services routed to the local data network.

[0445] The AF can send requests to influence the SMF routing decisions for PDU session traffic. This may affect UPF (re)selection and allow user traffic to be routed to local access to the data network.

[0446] In some embodiments, a request to influence an SMF routing decision for PDU session traffic may include some or all of the following:

[0447] Information used to identify the service to be routed. It can be identified by DNN, application identifier or service filtering information.

[0448] Other business.

[0449] Information about where to route traffic, such as DNN (e.g. if all traffic for a PDU session is routed to the application

[0450] program) and at least one of an application address.

[0451] Potential locations of applications to which service routing should be applied. Potential locations of applications that handle AF for UPF (re)selection. Service routing information related to N6 to be configured in UPF. This information may include, for example, N6 in the local DN

[0452] The end address of the interface and the protocol parameters for the N6 interface.

[0453] Information about the UEs whose traffic is to be routed. A single UE is identified using a UE identifier, such as an external identifier or MSISDN, all UEs or a selected group of UEs.

[0454] Information about when (time indication) the traffic routing is applied.

[0455] In the above discussion, it is assumed that the AF making such a request belongs to the PLMN serving the UE. The AF may make the request on behalf of other applications that do not reside in the PLMN serving the UE.

[0456] In some embodiments, the SMF may take this information into account based on local policy:

[0457] (Re)Select the UPF for the PDU session.

[0458] Activate mechanisms for traffic multi-homing or UL Classifier (UL CL) enforcement. This may include, for example, providing traffic forwarding (eg, breakout) rules to the UPF.

[0459] Notify AF to (re)select the UP path.

[0460] In some embodiments, the AF may request to be notified about the location information of the UE. The notification may be any or all of the following: one-time response to the AF notification request, or periodically in response to a change of state. A change of state may be, for example, the UE arriving at or leaving a geographical location that satisfies or does not satisfy the spatial validity condition.

[0461] In an embodiment, (1) the NEF is configured with information that allows mapping between application identifiers and the IP addresses of the applications. This configuration can be performed by a management plane component, such as a network manager, a slice manager, or a service manager.

[0462] In an embodiment, (2) the NEF is configured with information that allows mapping between region identifiers and geographic regions. This configuration may be done by a management component, such as a network manager. In some embodiments, it may be done by a third party function such as an application function or application server. This may require interaction between the NEF and the third party for configuration. This may be used to provide custom partitioning (as opposed to uniform partitioning in the case of management plane configuration).

[0463] In an embodiment, (3) the NEF converts the UE location information (eg, area identifier or uncoded area information) received from the application into information (eg, ID) identifying the AN serving the geographical area.

[0464] In an embodiment, (4) the NEF provides the converted information to a selected CPF, such as an SMF or a PCF.

[0465] In an embodiment, (5) AF implements NEF functionality. This can be considered as NEF embedded in AF. In this case, the interaction between NEF and CPF occurs between CPF and AF, and the interaction between NEF and AF becomes the internal logic of AF. In the illustration, this can be described as drawing boxes around NEF and AF.

[0466] In one implementation, a method for connecting a UE to a network is provided. The method includes the UE providing a DNN and an application identifier in a session request; the SMF obtains the DNN and application identifier from the PCF operator policy affected by the application using the UE location. The operator policy can be indexed in the PCF by using one of the DNN, application identifier, UE identifier, location, or any or all combinations selected. In some implementations, the policy can be associated with a spatial validity condition. In an implementation, based on the policy, the SMF has sufficient information to allow selection of a UP path (e.g., an anchor UPF). The SMF can set up the UP path and configure service redirection at the anchor UPF (e.g., a service destined for an application's IP address is routed to a specific location in a local DN). The SMF can configure service redirection because it configures a mapping between an application identifier and an application IP address.

[0467] In one implementation, the NEF is configured with information for implementing a mapping between an application identifier and an address associated with the application, such as an IP address. This configuration can be done by a management plane component, such as a network manager, a slice manager, or a service manager.

[0468] In one implementation, the NEF is configured with information for implementing the mapping between region identifiers and geographic regions. This configuration may be done by a management component, such as a network manager. In some embodiments, it may be done by third-party functions, such as application functions and application servers. This may require interaction between the NEF and the third party for configuration. This allows for custom partitioning (as opposed to uniform partitioning in the case of management plane configuration).

[0469] In one implementation, the NEF converts the UE location information (e.g., area identifier or uncoded area information) received from the application into indicative information (e.g., ID) indicating the AN serving the geographic area. The NEF may provide the converted information to the selected CPF, such as SMF or PCF.

[0470] In some embodiments, the AF implements the NEF function, and the interaction between the NEF and the CPF occurs between the CPF and the AF, and the interaction between the NEF and the AF becomes the internal logic of the AF.

[0471] In one implementation, a system and method are provided for maintaining a valid UP path for an AF that requires an UP path. In an embodiment, the system and method provide AF-affected SSC and UP path management performed between the AF and the CN CP to maintain a valid UP path for the AF that requires an UP path. For this embodiment, the following are assumed:

[0472] The AF that handles the traffic from / to the UE is deployed in the operator's local DN.

[0473] The AF is responsible for (re)selecting or relocating the AF within the local DN. The AF communicates directly or through the NEF with the control plane network function.

[0474] Can interact.

[0475] The NEF (or the AF itself when the AF interacts directly with the CN CP) determines a list of suitable UPFs that provide

[0476] Identify valid UP paths for potential AF locations and provide this information to the SMF.

[0477] It may also be assumed that the NEF can authenticate and verify information received from the application function.

[0478] Fig.161600-1608, where the AF 324 may participate directly rather than via the NEF 314 in the case where the operator trusts the AF 324.

[0479] In step 1600, the AF 324 sends an AF (re)location notification (which includes an application identifier, AF location information, temporal validity conditions, spatial validity conditions, and service filters) to the NEF 314.

[0480] In step 1602, NEF 314 (or AF 324) selects a serving PCF 314 using NRF 318. Fig.15 In the illustrated embodiment, the selected serving PCF is PCF 311. In some embodiments (not shown), NEF 314 provides the local DN name, edge computing application identifier, spatial validity conditions (e.g., serving access node identifier, geographic location or region) to NRF 318, and based on all or any combination of this information, NRF 318 replies to NEF 314 with the serving PCF. This information may be provided by AF 324, or NEF 314 may derive the information based on input provided by AF 324. It should be understood that the information provided by NEF 314 to NRF 318 may be provided by AF 324. The information may be provided in a message such as an AF (re)location notification, or may be determined or derived by NEF 314 from information provided by AF 324.

[0481] Next, in step 1604, NEF 314 (or AF 324) processes the notification and sends a UP management policy update request to PCF 314. PCF 314 then generates or updates the UP management policy according to the request in step 1606. If the policy generation / update affects an ongoing PDU session and the serving SMF 310 of the PDU session has subscribed to policy update notifications, PCF 314 will notify SMF 310 of the policy update.

[0482] In step 1608, PCF 314 responds to NEF 314 (or AF 314) to confirm receipt of the request. In the case where PCF 314 responds to NEF 314 instead of AF 324, NEF 314 confirms the AF (re)location notification to AF 324 in step 1610.

[0483] Fig.171704, 1706, and 1708.

[0484] The method starts with a UP (re)selection notification process 1700. In step 1702 of the process, the AF 324 sends a UP (re)selection notification subscription request (which includes a PDU session or application identifier, a time validity condition, a space validity condition, and a service filter) to the NEF 314, indicating whether to request at least one of the notification before and after the UP (re)selection. As described above, this step is optional and may not be required in an embodiment where the AF 324 is trusted by the operator.

[0485] In step 1704, NEF 314 (or AF 324 if it is trusted by the operator) interacts with NRF 318 to select a PCF. Fig.16 In the illustrated embodiment, the selected PCF is PCF 314. In some embodiments, NEF 314 provides the local DN name, edge computing application identifier, spatial validity conditions (e.g., service access node identifier, geographic location or region) to NRF 318, and NRF 318 uses the service PCF to reply to NEF 314 based on all or any combination of this information. This information can be provided by AF 324, or NEF 314 can derive information based on input provided by AF 324. Similar to the above case, the information provided by NEF 314 can be received by AF 324 in a (re)select notification subscription request. In other embodiments, NRF 318 can determine or derive the information based on information received from NEF 314. In step 1706, NEF 314 (or AF 324) processes the request and sends a UP (re)select notification policy update request to PCF 314.

[0486] In step 1708, PCF 314 generates or updates the UP (re)selection notification policy according to the received request. If the policy generation / update affects an ongoing PDU session and the service SMF 310 of the PDU session has subscribed to policy update notifications, PCF 314 may send a notification message about the policy update to SMF 310.

[0487] In step 1710, PCF 314 responds to NEF 314 (or AF 324) to confirm receipt of the request. In embodiments where AF 324 does not interact directly with CN, NEF 314 may send confirmation of UP (re)selection notification subscription to AF 324 in step 1712.

[0488] After completing the UP (re)selection notification subscription process 1600, the UP (re)selection notification delivery process 1714 may be performed. The steps of process 1714 are performed when UP (re)selection occurs or a UP (re)selection notification policy update is performed.

[0489] In step 1716, the SMF 310 sends a UP (re)selection notification to the NEF 314, which serves as a notification to the subscriber that the UP (re)selection has occurred. The notification occurs at least one of before and after the UP (re)selection based on the type of notification requested. It indicates the PDU session location, which may include at least one of the location of the PDU session anchor and the IP address of the UE 102.

[0490] The early notification allows the AF 324 to prepare for the necessary steps related to UP (re)selection (eg, AF 324 mobility). The late notification allows the AF 324 to configure the local DN for routing traffic from the AF 324.

[0491] In step 1718, in response to receiving the UP (re)select notification, NEF 314 processes the notification and sends the UP (re)select notification to AF 324. AF 324 may then indicate the PDU session location and the corresponding application location. This step 1718 is optional and is performed only when AF 324 uses NEF 314 in some embodiments. Without using NEF 314, AF 324 and PCF 316 may interact directly with each other and AF 324 may implement functions that NEF 314 performs in other ways (e.g., functions related to the present process). If step 1718 is performed, then in step 1720, AF 324 confirms the transmission of the notification to NEF 314.

[0492] In step 1722, NEF 314 (or AF 324) confirms the transmission of the notification to SMF 310.

[0493] In one implementation, the "UP Management Policy Update" service is a service for the PCF 316 to receive UP Management Policy Update requests. The request may include an application identifier, an identifier of an anchor UFP selected for each application location, a time validity condition, a spatial validity condition, a service filter, and N6 service routing information. The output of this service is the result of the delivery request.

[0494] During this service, when PCF 316 receives a UP management policy update request, PCF 316 generates or updates the UP management policy accordingly and confirms the receipt of the request to the requester. If the policy generation / update affects an ongoing PDU session and the service SMF 310 of the PDU session has subscribed to policy update notifications, PCF 316 will notify SMF 310 of the policy update.

[0495] In another implementation, the "UP (re)selection notification policy update" service is a service for the PCF to receive a UP (re)selection notification policy update request. The request may include an application identifier, a time validity condition, a spatial validity condition, a service filter, and a notification type. The output of the service is the result of the delivery request.

[0496] During this service, when PCF 316 receives a UP (re)selection notification policy update request, it can generate or update the UP (re)selection notification policy accordingly, and confirm the receipt of the request to the requester. If the policy generation / update affects an ongoing PDU session, and the service SMF 310 of the PDU session has subscribed to policy update notifications, PCF 316 can notify SMF 310 of the policy update.

[0497] In implementation, the "AF (re)location notification" service is a service for NEF 314 to receive (re)location notifications about AF 324. The input notification may include application identifier, AF location information, time validity conditions, spatial validity conditions, service filtering and N6 service routing information. The output of the service is the delivery result of the AF (re)location notification.

[0498] During this service, when NEF 314 receives an AF (re)location notification, it processes the notification and requests PCF 316 to update the UP management policy and confirm the AF (re)location notification to the requester.

[0499] In one implementation, the "UP (re)selection notification subscription" service is a subscription service for NEF 314 to receive UP (re)selection notifications for UP (re)selection event notifications for a specified service. The input subscription may include an application identifier, a time validity condition, a spatial validity condition, a service filter, and a notification type. The output of the service is the result of the UP (re)selection notification subscription.

[0500] During this service, when NEF 314 receives a UP (re)select notification subscription, it can request PCF 316 to update the UP (re)select notification policy and confirm the subscription to the requester. When NEF 314 receives a UP (re)select notification, it identifies the location of the corresponding business processing AF 324 and notifies the subscriber of the UP (re)select notification and the business processing AF location.

[0501] In one implementation, the "UP (re)selection notification" service is a local policy of the SMF 310 indicating a subscription to the UP (re)selection event notification UP (re)selection notification for an ongoing PDU session. The input to the service is the UP (re)selection notification policy, which may include a PDU session identifier, a time validity condition, a space validity condition, a notification type, and subscription information. The subscription information indicates the subscriber NF. The output of the service is the UP (re)selection notification (which may include subscription information and PDU session location information). The subscription information is used to identify an entry of a subscription context in the subscriber NF.

[0502] During this process, when SMF 310 detects a local policy indicating a subscription for UP (re)selection notifications for UP (re)selection event notifications for an ongoing PDU session, it registers the subscription indicated by the policy. When SMF 310 (re)selects a UPF for a PDU session, it notifies the subscriber of the UP selection notification. In the case of a subscription pre-notification, SMF 310 sends the notification before performing UPF (re)selection. In this case, the response to the notification may include N6-related service routing information. SMF 310 notifies NEF 314, which notifies AF 324; AF 324 responds to NEF 314, and then NEF 314 responds to SMF 310. N6-related service routing information may be included in the response sent by AF 324 to NEF 314. NEF 314 may process it before sending it to SMF 310. The processing may include supplementing it with missing information blocks, which are N6 protocol specific, and protocol header compilation. The SMF 310 then configures the anchor UPF to support or use the N6 interface with the service processing AF, which may be AF 324 or a different AF, based on the N6 related service routing information received when performing UPF (re)selection.

[0503] In the case of late subscription notification, SMF 310 sends a notification when UPF (re)selection is complete. In one implementation, a method for PDU session establishment requested by UE 102 is provided. In the case of roaming, AMF 308 can determine whether to establish a PDU session in local breakout (LBO) or home routing. In the case of LBO, the process is the same as in the non-roaming case, except that any or all of SMF 310, UPF 304 and PCF 316 can be located in the access network.

[0504] Fig.18A and 18B An embodiment showing a UE-requested PDU session establishment procedure for non-roaming and roaming with local burst is presented. The procedure assumes that the UE 102 has registered with the AMF 308 and, therefore, the AMF 308 has retrieved the user subscription data from the UDM 320.

[0505] To establish a new PDU session, the UE 102 generates a new PDU session ID. The UE 102 initiates the UE requested PDU session establishment procedure by sending a NAS message (S-NSSAI, DNN, application identifier, PDU session ID, N1SM information (note that in some embodiments, the application identifier can be embedded in the SM information)) including a PDU session establishment request in the N1 SM information to the AMF 308 at step 1800. The PDU session establishment request may include the PDU type, SSC mode, and protocol configuration options.

[0506] When the DNN points to a local DN, the NAS message may include an application identifier corresponding to the edge computing application hosted in the local DN. The presence of the application identifier indicates that it is a request for a PDU session dedicated to the edge computing application.

[0507] The NAS message sent by UE 102 is encapsulated by AN 308 in an N2 message, which should include user location information and access technology type information.

[0508] The SM information may include an SM PDU DN request container, which contains information of the PDU session authorized by the external DN.

[0509] In step 1802, the AMF 308 determines a message corresponding to a request for a new PDU session based on a PDU session ID that is not used for any existing PDU session of the UE. The AMF 308 selects the SMF 310.

[0510] In step 1804, AMF 308 sends an SM request to SMF 310. The SM request contains a subscriber permanent ID, DNN, S-NSSAI, PDU session ID, AMF ID, N1 SM information, user location information, and access technology type. The AMF ID uniquely identifies the AMF 308 serving the UE 102. The N1 SM information contains the PDU session establishment request received from the UE 102.

[0511] In step 1806, SMF 310 sends a subscription data request (Subscriber Permanent ID, DNN) to UDM 320. This step is optional and may be performed if SMF 310 has not yet retrieved the SM subscription data associated with the UE associated with the DNN, for which SMF 310 requests the subscription data.

[0512] If step 1806 is performed, then in step 1808, UDM 320 sends a subscription data response to SMF 310. The subscription data includes authorized PDU types, authorized SSC modes, and a default QoS profile.

[0513] SMF 310 checks whether the UE request complies with the user subscription and local policy. If it does not comply, SMF 310 rejects the UE request through NAS SM signaling (including the relevant SM rejection cause) relayed by AMF 308, and SMF 310 indicates to AMF308 that the PDU session ID will be considered released and skip the remaining procedures.

[0514] Step 1810 is PDU session authentication / authorization, which is from SMF 310 to DN 306 via UPF 304. If SMF 310 needs to authorize / authenticate the establishment of the PDU session, SMF 310 selects UPF 304 and triggers PDU session establishment authentication / authorization. If PDU session establishment authentication / authorization fails, SMF 310 terminates the PDU session establishment process and indicates rejection to UE 102.

[0515] If dynamic policy and charging control (PCC) is deployed, then in step 1812, SMF 310 performs PCF selection. In step 1814, SMF 310 may initiate a PDU-CAN session establishment to PCF 316 to obtain the default PCC rules for the PDU session. It should be noted that in this particular embodiment, the purpose of step 1810 is to receive PCC rules before selecting UPF 304. If PCC rules are not required as input to UPF selection, step 1810 may be skipped.

[0516] In step 1816, the SMF 310 selects the SSC mode for the PDU session. If step 1710 is not performed, the SMF 310 may also select the UPF 304 during this step. In case the PDU type is IPv4 or IPv6, the SMF 310 may allocate an IP address / prefix for the PDU session.

[0517] If dynamic PCC is deployed in step 1814 and PDU-CAN session establishment is not performed, SMF 310 may initiate PDU-CAN session establishment to PCF 316 to obtain the default PCC rules for the PDU session in step 1818. Otherwise, if dynamic PCC is deployed and the PDU type is IPv4 or IPv6, SMF initiates PDU-CAN session modification and provides the allocated UE IP address / prefix to PCF 316.

[0518] In step 1820, if the PDU session request is for an edge computing application and if the AF 324 has subscribed to such previous notifications related to PDU sessions, the SMF 310 notifies the AF 324 of the UP path selection. The notification indicates the PDU session anchor.

[0519] If step 1810 is not performed, the SMF initiates the N4 session establishment process using the selected UPF 304, otherwise it uses Fig.17 The selected UPF 304 shown starts the N4 session modification process. Specifically, in step 1822, the SMF sends an N4 session establishment / modification request to the UPF 304 and provides the packet detection, enforcement and reporting rules to be installed on the UPF 304 for the PDU session. If the CN tunnel information is allocated by the SMF 310, the CN tunnel information is provided to the UPF 304 in this step. Then, in step 1824, the UPF 304 confirms by sending an N4 session establishment / modification response. If the CN tunnel information is allocated by the UPF 304, the CN tunnel information is provided to the SMF 310 in this step 1824.

[0520] In step 1826, SMF 310 sends SM request confirmation (N2 SM information (PDU session ID, QoS profile, CN tunnel information), N1 SM information (PDU session establishment accept (authorized QoS rules, SSC mode))) to AMF 308.

[0521] The N2 SM information carries information that the AMF 308 can provide to the (R)AN 302. The CN tunnel information can correspond to the core network address of the N3 tunnel corresponding to the PDU session. The QoS profile can provide the (R)AN 302 with a mapping between QoS parameters and QoS flow identifiers. The PDU session ID can be used by (R)AN signaling including the UE 102 to indicate to the UE 102 the association between (R)AN resources and the PDU session of the UE 102. The N1 SM information can include a PDU session establishment accept provided by the AMF to the UE 102. Multiple authorized QoS rules can be included in the PDU session establishment accept within the N1 SM information and the N2 SM information. The SM request confirmation can also include information that allows the AMF 308 to know or determine which UE 102 is the target of the SMF 310 request, and to determine which access to use for the UE 102.

[0522] It should be noted that the access information may be provided / used to enable the case where the UE is simultaneously connected via 3GPP and non-3GPP accesses.

[0523] In step 1828, the AMF 308 sends an N2 PDU Session Request (N2 SM Information, PDU Session Establishment Accept) to the (R)AN 302. The AMF 308 sends the PDU Session Establishment Accept and the N2 SM Information received from the SMF 310 in the N2 PDU Session Request to the (R)AN 302.

[0524] In step 1830, the (R)AN 302 may initiate AN-specific signaling exchanges with the UE 102 related to the information received from the SMF 310. For example, in the case of a 3GPP RAN, an RRC connection reconfiguration may occur for the PDU session request received in step 1822, utilizing the necessary RAN resources associated with the authorized QoS rules established by the UE 102.

[0525] The (R)AN 302 may also allocate (R)AN tunnel information for the PDU session. The (R)AN 302 may forward the NAS message (PDU Session Establishment Accept) provided in step 1824 to the UE 102. The (R)AN 302 may provide the NAS message to the UE 102 when the necessary (R)AN resources are established and the allocation of the (R)AN tunnel information is successful.

[0526] In step 1832, the (R)AN 302 sends an N2 PDU Session Request Ack ((R)AN Tunnel Information) to the AMF 308. The (R)AN Tunnel Information may correspond to the access network address of the N3 tunnel corresponding to the PDU session.

[0527] In step 1834, AMF 308 may send an SM request (N2 SM information) to SMF 310. More specifically, AMF 308 forwards the N2 SM information received from (R)AN 302 to SMF 310.

[0528] In some implementations, the UE 102 may notify the CN function that it has successfully established the PDU session. In some implementations, the UE 102 sends a NAS PDU Session Establishment Complete message to indicate that the UE 102 has successfully established the PDU session. In some implementations, the indication of the successful establishment of the session in the (R) AN 302 in step 1828 serves as a notification.

[0529] If the N4 session for the PDU session has not been established, SMF 310 initiates the N4 session establishment procedure with UPF 304 in step 1836. Otherwise, SMF 310 initiates the N4 session modification procedure with UPF 304. SMF 310 provides AN tunnel information and CN tunnel information. If SMF 310 selects CN tunnel information in step 1718, only CN tunnel information needs to be provided.

[0530] In step 1838, UPF 304 sends an N4 session establishment / modification response to SMF 310. After this step, AMF 308 can forward notifications of relevant events to SMF 310, for example, when (R) AN tunnel information changes or AMF 308 is relocated. In some embodiments, SMF 310 explicitly subscribes to these events. In other embodiments, the subscription is implicit. In optional step 1842, SMF 310 forwards the IPv6 address configuration to UE 102 via UPF 304. Specifically, in the case where the PDU type is IPv6, SMF 310 generates an IPv6 router advertisement and sends it to UE 102 via N4 and UPF. It should be understood that in some embodiments, after step 1838, SMF can send an SM request confirmation (as shown in 1840) to AMF 308. This can be a response to SM request message 1724.

[0531] In step 1844, if the PDU session request is for an edge computing application and if the AF 324 has a subscription for such late notifications related to the PDU session, the SMF 310 sends a UPF selection notification (late notification) message to the AF 324 notifying the AF 324 of the UP path selection. The notification indicates the PDU session anchor. The AMF 308 may store the association of the PDU session ID and the SMF ID for the lifetime of the PDU session.

[0532] In one embodiment, a process is provided for AF-affected SSC and UP path management in an edge computing scenario. The process is between the AF and the CN CP to maintain a valid UP path for the AF that needs it. For this process, it is assumed that the local data network hosting the edge computing application is responsible for the correct implementation of the N6 interface to ensure service or session continuity in the presence of at least one of UE mobility and AF mobility. In this case, the UP path reselection can be transparent to the UE 5.

[0533] In one implementation, the PDU Session Anchor reconfiguration is due to application relocation. In this case, application relocation does not affect the UPF selection decision of the SMF, and the SMF 10 only needs to reconfigure the N6 service routing at the PDU Session Anchor to ensure that UL services are delivered to the new service processing AF location and recognize DL services from the new service processing AF location.

[0534] Fig.19 is a signaling diagram illustrating an embodiment of a PDU session anchor reconfiguration due to application relocation. Fig.19 As shown, in step 1900, UE 102 has a PDU session established with UPF1 304A as a PDU session anchor. In step 1902, SMF 310 receives a trigger to update the N6 service routing configuration at UPF1 304A. This can be triggered by, for example, application relocation, policy change, etc. In step 1904, if AF 324 has subscribed to such a previous notification, SMF 310 notifies AF 324 of the UP path reselection. The notification indicates UPF1 304A as the PDU session anchor. Next, in step 1906, SMF 310 reconfigures the N6 service routing at UPF1 304A. In step 1908, if AF 324 has subscribed to such a later notification, SMF 310 notifies AF 324 of the UP path reselection. The notification indicates UPF1 304A as the new PDU session anchor. In some embodiments, AF 324 subscribes only to pre-notifications, so that step 1908 is not performed. In some embodiments, AF 324 subscribes only to post-notifications, so that step 1904 is not performed. In other embodiments, AF 324 subscribes to pre- and post-notifications, so that both steps 1904 and 1908 are performed.

[0535] In other implementations, PDU session anchor relocation is targeted at PDU sessions dedicated to edge computing applications. In this case, the services carried by the PDU session are only associated with edge computing applications. If the SMF decides to reselect the PDU session anchor of the PDU session, it moves all services associated with the PDU session to the new PDU session anchor and then releases the old PDU session anchor.

[0536] Fig. 20 1 is a signaling diagram illustrating an embodiment of a PDU session anchor relocation method for a PDU session dedicated to an edge computing application. Fig. 20 As shown, in step 2000, UE 102 has a PDU session established with UPF1 304A as a PDU session anchor. The PDU session is dedicated to services associated with edge computing applications. In step 2002, SMF 310 receives a trigger to reselect UPF2 304B as a PDU session anchor. This can be triggered by, for example, application relocation, UE mobility, policy changes, etc. In step 2004, if AF 324 has subscribed to such a previous notification, SMF 310 notifies AF324 of the UP path reselection. The notification indicates UPF2 304B as the new PDU session anchor. In step 2006, SMF 310 reconfigures the UP path with UPF2 304B as a PDU session anchor, including N6 service routing configuration at UPF2 304B. In step 2008, if AF 324 has subscribed to such a late notification, SMF 310 notifies AF 324 of the UP path reselection. The notification indicates that the new PDU session anchor is UPF2 304B. In some embodiments, AF 324 subscribes only to the early notification, so that step 2008 is not performed. In some embodiments, AF 324 subscribes only to the late notification, so that step 2004 is not performed. In other embodiments, AF 324 subscribes to both the early and late notifications, so that both steps 2004 and 2008 are performed. In step 210, SMF 310 releases the PDU session resources with UPF1 304A.

[0537] In another implementation, PDU session anchor relocation is used for PDU sessions shared by multiple edge computing applications. In this case, the PDU session carries services associated with multiple edge computing applications. If the SMF 310 is triggered to select a PDU session anchor for one edge computing application, it configures the UPF as an uplink classifier UL (CL) so that the services associated with the edge computing application are forwarded from the UL CL to the new PDU session anchor, while other services are forwarded to the old PDU session anchor.

[0538] Fig.21 is a signaling diagram illustrating an embodiment of a PDU session anchor relocation method for a PDU session shared by multiple edge computing applications. Fig.21As shown, in step 2100, UE 102 has a PDU session established with UPF1 304A as the PDU session anchor for services associated with edge computing applications. In step 2102, SMF 310 decides to reselect UPF2 304B as the PDU session anchor for services associated with edge computing applications. This can be triggered by, for example, application relocation, UE mobility, policy changes, etc. In step 2104, if AF 324 has subscribed to such a previous notification, SMF 310 notifies AF 324 of the UP path reselection. The notification indicates UPF2 304B as the new PDU session anchor for services associated with edge computing applications. In step 2106, SMF 310 configures UPF2 304B as the new PDU session anchor for services associated with edge computing applications via N4. In step 2108, SMF 310 configures UPF as UL CL 304C for PDU session via N4, and establishes two branches from UL CL 304C to UPF1 304A and UPF2 304B. SMF 310 provides necessary UL service forwarding rules to UL CL 304C. Then, in step 2110, SMF 310 instructs (R)AN 302 to update N3. In step 2112, if AF 324 has subscribed to such late notification, SMF 310 notifies AF 324 of UP path reselection. The notification indicates UPF2 302B as a new PDU session anchor for services associated with edge computing applications. In some embodiments, AF 324 only subscribes to early notifications, so that step 2112 is not performed. In some embodiments, AF 324 only subscribes to late notifications, so that step 2104 is not performed. In other embodiments, AF 324 subscribes to both pre- and post-notifications so that both steps 2104 and 2112 are performed.

[0539] In some cases, the network address (e.g., IP address) of the AF 324 (edge ​​computing application) known to the UE 102 does not indicate the actual location where the AF 324 is hosted (e.g., the IP address may not point to the server that instantiated the AF). This may occur, for example, due to AF mobility and may be more common in virtualized environments. As a result, the IP address of the AF 324 may not work in all uplink (UL) communications from the UE 102.

[0540] In some embodiments, joint management of CN-UP and local DN can be adopted. NEF (CP function in CN) determines the interconnection between UPF and the physical host of AF (i.e., edge computing application). The NEF can determine the interconnection based on AF information provided by the MEC controller and pre-configured information of the topology between the UPF and the AF host. The NEF compiles the protocol parameters for the interconnection between the UPF and the AF host. The compilation can be based on the protocol information provided by the MEC controller and at least one of the UE and session information provided by other CPFs. The NEF instructs the PCF to generate policies based on management decisions. Management decisions are based on each session / session group, each UE / UE group, or each application / service.

[0541] The MEC controller manages the service function linking within the local DN and manages / configures the AF host for the interface with the UPF based on at least one of the UPF and UE information provided by the CN-CP. The management is based on each session / session group, each UE / UE group or each application / service.

[0542] SMF (CP function in CN) manages and configures the path and protocol between RAN and anchor UPF, and configures and anchors UPF for the interface including AF host according to the policy provided by PCF, where the policy includes protocol parameters and routing destination. SMF can also provide information related to at least one of the anchor UPF and UE to the MEC controller (directly or via NEF). This management is based on each session.

[0543] Reference Fig. 22 , a simplified network diagram is provided to illustrate segment management. CN-CP 328 manages CN-UP 326 and MEC controller 324 manages MEC in local DN 306. NEF 314 manages the link between CN-UP 326 and local DN 306. Those skilled in the art will understand that the link managed by NEF 314 can be understood as a logical link between the network functions in CN-UP 326 and local DN 306.

[0544] UE102 can discover MEC applications by sending a discovery request to the CP function. The request may include a local DN name, which requests the discovery of MEC applications hosted within the specified local DN. In some implementations, the lack of a local DN name indicates a request to discover all MEC applications. The CP function responds to the UE with a discovery result. The discovery result includes a list of <application identifier, [application address]>, where [] indicates that the information is optional. In some embodiments, the discovery results are limited to those MEC applications available to UE 102 or those MEC applications that UE 102 is authorized to use. The application address used by UE 102 is used to communicate with the upper layer (e.g., TCP layer) of the MEC application. The MEC application information can be maintained by NRF 318 or stored in UDM 320 or SMF310. The CP function can be any relevant CP function, including, for example, AMF 308, NEF 314, SMF 310, and NRF 318. The CP function needs to interact with the NRF 318 or UDM 320 or SMF 310 to obtain the requested MEC application information before replying to the UE 102. The CP function may also be the NRF 318 or UDM 320 or SMF 310. In an embodiment where the CP function is the AMF 308, the discovery process may be integrated with the registration process, i.e., in the registration complete message (to the UE 102), the AMF 308 may include the discovery result.

[0545] The CP function may notify UE 102 of changes in the discovery results, such as changes in the application address, via a NAS message. UE 102 may submit a request for a dedicated PDU session to handle services associated with the edge computing application. Such a dedicated PDU session may be used for a single edge computing application or shared by multiple edge computing applications.

[0546] In some implementations, the UE's request may specify whether the dedicated PDU session is for a single edge computing application or shared by multiple edge computing applications. In some implementations, if the UE 102 requests to use a single edge computing application, the UE 102 may indicate the application to the SMF 310 during the PDU session establishment process. The SMF 310 may indicate the address of the application to the UE 102 during the session establishment acceptance step.

[0547] Joint management solves the addressing problem in UL communications. Although not required, using joint management for DL ​​communications joint management allows the UE's IP address to be decoupled from the anchor UPF, i.e. transparent UPF reselection. Anchor UPF reselection may be due to UE mobility, AF mobility, load, etc. The UE's IP address does not need to change as the anchor UPF changes.

[0548] Fig.23is a message flow diagram illustrating a representative process for third-party authentication / authorization via NEF 314. Third-party authentication / authorization for PDU session establishment is optionally triggered by SMF 310 during the PDU session establishment process and performed via NEF 314.

[0549] Those skilled in the art will appreciate that with reference to this figure and other figures of the present application, a network function that triggers a process may be discussed. This should be understood to include a network function that sends a request or notification to another network function, as well as a network function that initiates an internal process that may result in a request or notification being sent to another network function. With respect to a function that triggers a process, the understanding of the term "trigger" should not be limited to the meaning that the state of a function or another such feature is compared to a threshold, and in response to the comparison, a process is invoked.

[0550] In step 2302, the SMF sends a request for third-party authentication / authorization to the NEF 314. As part of the request, the SMF 310 may provide the NEF 314 with an SM PDU AF request container in a third-party authentication / authorization request message. The request message may include at least one of a DNN, an S-NSSAI, and an application identifier. As previously described, the application identifier may be provided by the UE 102 as part of the PDU session establishment request.

[0551] In step 2304, the NEF 314 uses the information received in step 2302 to select the AF 324. In step 2306, the NEF 314 relays the SM PDU AF request container received from the SMF 310 to the selected AF 324 using an authentication / authorization request message. The request message may also include an application identifier.

[0552] The authentication / authorization process 2308 occurs between the UE 102 and the AF 324 using messages via the NEF 314, the SMF 310, and the NAS transport. In step 2308a, the AF sends an authentication / authorization request to the NEF 314. In step 2308b, in response to the authentication / authorization request, the NEF 314 sends an NEF transport (authentication message) to the SMF 310, wherein the authentication message includes the authentication / authorization request message received from the AF 324 for the UE 102 in step 2308a. In step 2308c, in response to receiving the NEF transport (authentication message), the SMF 310 sends a NAS SM transport (authentication message) to the AMF 314. In step 2308d, the AMF 324 then forwards the NAS SM transport (authentication message) to the UE 102 via the (R)AN 302. In step 2308e, the UE 102 responds by sending a NAS SM transport (authentication message) to the AMF 308 via the (R)AN 302, where the authentication message is intended for the AF 324. In step 2308f, the AMF 308 sends the NAS SM transport (authentication message) to the SMF 310. In response to receiving the NAS SM transport (authentication message) in step 2308g, the SMF 310 sends the SMF transport (authentication message) to the NEF 314. In step 2308h, in response to receiving the SMF transport (authentication message), the NEF 314 sends an authentication / authorization response to the AF 324. It should be understood that alternative procedures including different steps may also be suitable for use.

[0553] In step 2310, AF 324 based on the authentication message of UE 102 ends authentication / authorization and sends an authentication / authorization response message to NEF 314 to confirm the successful authentication / authorization or failure of the PDU session. AF 324 may provide an SM PDU AF response container to NEF 314 to indicate the successful authentication / authorization or failure. The SM PDU AF response container may include an identifier of the application that UE 102 is authorized to use the PDU session.

[0554] In step 2312, NEF 314 sends a third-party authentication / authorization response message to SMF 310 containing an SM PDU AF response container.

[0555] Fig.24 is a call flow diagram illustrating a representative process for PDU session establishment authentication / authorization.

[0556] In step 2402, SMF 310 selects UPF 304. In step 2404, SMF 310 sends an SM PDU DN request container in an N4 data forwarding message to the selected UPF 304. In some cases, this is referred to as SMF 310 "triggering" the PDU session establishment process. In an embodiment, SMF 310 provides service steering configuration information to the selected UPF 304 (for example, it can be a detailed configuration message or an identifier pointing to pre-stored configuration information accessible to the UPF). The service steering configuration information can be part of the N4 data forwarding message, or can be sent to UPF 304 as a separate message. In step 2406, UPF 304 relays the SM PDU DN request container received from SMF 310 to DN 306.

[0557] An authentication / authorization process 2408 occurs and messages transmitted via N4 and NAS are shown including steps 2408a through 2408h between UE 102 and DN 306. It should be appreciated that alternative procedures including different steps may also be suitable for use.

[0558] In step 2410, the DN confirms the successful authentication / authorization of the PDU session. The DN may provide a SM PDU DN response container to the UPF to indicate the successful authentication / authorization.

[0559] In step 2412, UPF 304 returns the N4 data forwarding message to SMF 310 containing the SM PDU DN response container.

[0560] Fig.25A 324 and 5G core network (5GC) elements. These processes can be used to maintain or configure an effective user plane path for traffic flows associated with applications that require end-to-end user plane path efficiency.

[0561] At a first step 2500, the AF 324 may send an AF request message to the NEF 314. It is contemplated that the request message may include a plurality of fields, such as: request identifier; application network identifier; application external identifier; service filtering; temporal validity condition; spatial validity condition; request type; and request content. The AF request message may also include information indicating a current or future session to which the request may apply. In some such embodiments, a UE identifier, a set of UE identifiers, an identifier of a set of UEs, or other such information may be included within the AF request.

[0562] The request identifier may be used to uniquely identify the AF request message, thus enabling the AF 324 to modify or delete the AF request message or to associate the AF request message with future AF request messages. The request identifier may be generated by the AF 324 itself or by the NEF 314. In embodiments where the AF 324 generates the request identifier, it may be included in the AF request message sent to the NEF 314, which may record the request identifier for future use. In embodiments where the NEF 314 generates the request identifier, it may be transmitted to the AF 324 in an AF request response message, which will be described in more detail below.

[0563] The application network identifier may be used to indicate a network where the application is located. In this regard, the network where the application is located may be a virtual network, a physical network, a domain network, etc. The application network identifier may be in the form of a network name, such as a domain name or a virtual network name.

[0564] The application external identifier can be used to identify the application associated with the AF request.

[0565] The service filter may be used to select the service to which the user plane path is applied. In a specific embodiment, the service filter may have any valid combination of one or more of the following forms:

[0566] A UE identifier, such as a UE external identifier or a Mobile Station ISDN (MSISDN), for example, used to indicate future services for a specific UE or non-IP services for a specific UE;

[0567] IP address / prefix, e.g., used to indicate the IP traffic associated with the ongoing PDU session;

[0568] AF request identifier, for example, used to indicate a service filter defined in a previous AF request;

[0569] The ANY_UE indicator is used to indicate a service of any UE, for example.

[0570] The time validity condition is an optional parameter that can be used to indicate the time period during which the AF request function is valid. The time validity condition can include a set of time elements, such as: start time; end time; and frequency, where the frequency can indicate, for example, daily, weekly, monthly, non-repeating, etc.

[0571] The spatial validity condition is an optional parameter that can be used to indicate the area in which the AF request message is valid. For example, the spatial validity condition can be used to limit the validity of the AF request message to the current location of the UE. The spatial validity condition can be in the form of one or more zone or domain identifiers. The zone or domain can refer to a geographic area or a network area or domain. The geographic area can be defined according to geographic boundaries (and can be combined with a time validity condition) to apply to any electronic device (e.g., UE) within the defined boundaries (or a specified set of devices within the boundaries), or it can be defined according to the topology of the network (e.g., by specifying a request message that applies to any connection by virtue of a set of access nodes or other such network nodes or functions) instead of a boundary based on geographic coordinates. As described above, the spatial validity condition can be combined with other validity conditions (e.g., time validity or the specification of the UE or multiple UEs to which the request applies) so that the request can be applied to any session in the time window, where the UE in the specified set of UEs is connected in a spatial area defined by a geographic boundary, or defined by a network topology constraint (e.g., all sessions in which the UE has been connected to at least one of a set of access nodes in the wireless access network). In an embodiment where the AF provides spatial validity conditions based on geographic location, a network function within a 3GPP-compliant network may be used to map the geographic boundary definition to a set of network access nodes or other network functions corresponding to the geographic boundary.

[0572] For example, the request type parameter can be used to indicate whether the AF request message is an "application location notification", "UP management event subscription request" or "UE grouping request". If necessary, other request types can be defined and indicated by using the request type parameter. In another alternative, the request type parameter can be used to indicate a combination of two or more request types. In this case, the fields required for these request types must be present in the message format.

[0573] The request content may be used to provide additional information related to the AF request. If desired, the request content may also be used alone or in combination with a request type parameter to provide information required to indicate and support at least one of two or more request types. In a specific embodiment, the additional information may depend on the request type. For example, where the request type parameter indicates that the AF request is an application location notification, the request content may include any one or more of the following: a potential location of the application; and a corresponding N6 point-to-point tunnel requirement for the UP path. The potential location of the application may be in the form of a transport address (e.g., server name, IP address, etc.) within the application network. The N6 point-to-point tunnel requirement may indicate the type of tunnel (e.g., no tunnel, IP tunnel, IP / UDP tunnel, Ethernet tunnel, etc.) and related tunnel protocol parameters (e.g., at least one of the tunnel endpoint address / identifier and the port number of the application location). The absence of a specific N6 point-to-point tunnel requirement may be used to indicate that a set of default tunnel requirements may be used.

[0574] In some embodiments, the request content field may also include an event / notification type parameter so that a given request type can be used in conjunction with two or more types of events. For example, in an AF request message having a request type parameter indicating a "UP management event subscription" request, the event / notification type parameter may indicate whether the request is for an early notification or a late notification, or both. In other embodiments, the event / notification type parameter may indicate, for example, an anchor UPF change event, a service steering change event, a QoS change event, etc. In some embodiments, the AF may respond to different event / notification type parameters to perform corresponding different actions in the local DN, for example, performing tunnel configuration, completing application relocation, or adjusting QoS provisioning.

[0575] In some embodiments, the request content field may also include a group identifier parameter. For example, in an AF request message with a request type parameter indicating a "UE grouping" request, the group identifier parameter is a group ID indicating the UE group defined by the service filter field in the AF request. In some embodiments, the group identifier parameter is not present, and the NEF is responsible for allocating a group identifier for the UE group and providing it to the AF using a response message. The AF may use the group ID to construct a service filter for subsequent AF requests.

[0576] In response to the AF request message, the NEF 314 may perform (at 2502) an authentication / authorization process between the AF 324, the authentication server function (AUSF) 312, and the user data repository (UDR) 322 or the unified data management (UDM) 320 function. In some embodiments, the term UDR 322 may also be understood to indicate a unified data repository that provides unified data storage for user data and application-related data, such as policy requirements provided by the AF (e.g., in the form of AF requests).

[0577] In some embodiments, the AF 324 can register itself (using its own identity) and the applications managed with the network (e.g., application identifier or application external identifier). The registration can also indicate the application network identifier (or DNN). The registration can be done by a management plane function, such as a service manager, a network manager, a domain manager, etc. The management function can assign security certificates to the AF and can store the registration data and security certificates in a unified data management (UDM) 320 or UDR 322.

[0578] During the authentication / authorization process at step 2503, the NEF 314 may send at least one of the AF identity information, the application external identifier (or application identifier), and the application network identifier (or DNN) to the AUSF 312, which may then interact with the UDM 320 (or UDR 322) for authentication and authorization. For example, if this information has not been provided in the AF request message, the NEF 314 may also need to interact with the AF to obtain the AF identity information. Alternatively, the NEF 314 may provide the AF identifier to the AUSF, and the AUSF may then obtain the AF identity information from the AF.

[0579] The AUSF 312 may use the AF identifier to discover the AF address through the Network Function (NF) Repository Function (NRF) to communicate with the AF. Alternatively, the NEF may provide the AF address to the AUSF, which the NEF may obtain in step 2500 as part of its communication with the AF. In other embodiments, other AF address discovery methods may be used.

[0580] After completing the authentication / authorization process, the NEF may return (at 2504) an AF request response message including a result code to the AF. The result code may indicate the result of the authentication / authorization process. If the result is a failure, the NEF 314 may terminate the AF request process after step 2504. Otherwise, the NEF 314 may proceed to step 2506 and select a policy control function (PCF) 316 using the NRF 318. In some embodiments, the PCF 316 may be selected based on the service area of ​​the PCF. For example, a PCF having a service area that covers at least one of the local DN and overlaps spatial validity in the AF request may be selected in this step. In some embodiments, the PCF 316 may be selected based on the service area of ​​the local DN. For example, all PCFs within the service area of ​​the local DN may be selected. In another example, the PCF 316 may be selected based on the intersection of the service area of ​​the PCF and the service area of ​​the local DN. In some embodiments, an application external identifier (or application identifier) ​​may be used for PCF selection. In some embodiments, PCF 316 may be pre-configured in NEF 314, in which case PCF selection step 2506 may be omitted.

[0581] At step 2508, NEF 314 may process the AF request message and send a policy update request message to PCF 316. The policy update request message may include any one or more of the following parameters: request identifier; DNN; application identifier; service filter; time validity condition; space validity condition; request type; and request content.

[0582] The request identifier may be used to uniquely identify the policy update request message, thereby enabling the NEF 314 to modify or delete the policy update request message, or to associate the policy update request message with future policy update request messages. The request identifier may be generated by the NEF 314 itself or by the PCF 316. In embodiments where the NEF 314 generates the request identifier, it may be included in a policy update request message sent to the PCF 316, which may record the request identifier for future use. In embodiments where the PCF 316 generates the request identifier, it may be transmitted to the NEF 314 in a policy update request response message, which will be described below. Preferably, the NEF 314 maintains a mapping between the policy update request identifier and the AF request identifier received by the NEF in step 2500.

[0583] The DNN may be mapped from the application network identifier received by the NEF in step 2500. The mapping may be pre-configured in the NEF 314. The application network identifier may also be used to identify related control information, such as S-NSSAI associated with the application.

[0584] The application identifier may be mapped from the application external identifier received by the NEF in step 2500 and used by the UE 102 within the 5GC to identify control information (e.g., single network slice selection assistance information (S-NSSAI) policy) to which the application relates. The mapping between the application external identifier and the application identifier may be pre-configured in the NEF 314.

[0585] The service filter field of the policy update request message may contain a policy update request identifier, which may be generated based on, or converted from, the AF request identifier (if any) in the service filter field of the AF request message received by the NEF. The service filter field may also contain a UE group identifier. The UE group referenced by the identifier may be created or defined based on a previous UE grouping request by the AF, and group membership is maintained within the UDM 320 (e.g., UDR 322). The UE group may be application specific.

[0586] The spatial validity condition may be in the form of a RAN node identifier or a cell identifier, and any spatial validity condition may be mapped from the spatial validity condition of the AF request message received by the NEF in step 2500. The mapping between the spatial validity condition of the AF request message and the spatial validity condition of the policy update request message may be pre-configured in the NEF.

[0587] In the case where the AF request is an application location notification, the request content container may include a routing profile ID and a corresponding N6 point-to-point tunnel requirement. The routing profile ID may be mapped from information (e.g., application network identifier, application external identifier, and potential location of the application) contained in the AF request message received by the NEF in step 2500. The mapping may be pre-configured in the NEF by the management plane (MP) directly or through a network function (NF), such as PCF 316, UDM 320, or DSF (e.g., UDR 322).

[0588] It will be appreciated that pre-configuration of mappings, etc. (whether pre-configuration performed in this step or other steps described in this disclosure) may be accomplished by a management plane function, such as a network manager, slice manager, or service manager.

[0589] When the management plane function performs pre-configuration, it can use the element management system to install the pre-configuration information in the target network function. In some embodiments, the management plane function can act as an application function and perform pre-configuration through PCF 316 or NEF 314.

[0590] In some embodiments, the pre-configuration is not performed directly on the target NF, but on a third NF such as UDM 320 or DSF. The target NF may obtain the pre-configuration information from the third NF actively (e.g., periodically or when needed) or passively (e.g., upon receiving a notification from the third NF). Those skilled in the art will appreciate that in some embodiments, the DSF may be pre-configured by UDR 322.

[0591] In some embodiments, when a first NF (e.g., PCF) and a second NF (e.g., NEF) are to be preconfigured with the same information (e.g., routing profile), the preconfiguration may be performed only for the first NF, and the second NF may then obtain the preconfiguration information from the first NF.

[0592] In response to the policy update request message, PCF 316 may generate (at 2510) one or more UP management policies based on the information contained in the policy update request message. Depending on the policy request type, the generated UP management policy may include at least one of a service steering policy, a UP management event notification policy, and a UE grouping policy.

[0593] If the service filter field of the received policy update request message contains a policy update request identifier, those policy update request identifiers can be converted into corresponding service filters. The request message may also contain a UE group identifier, which can be converted into a service filter (or can be used in conjunction with other data to create a service filter). For the conversion, the PCF can interact with the UDR to obtain the relevant policy data. The conversion can be performed before the PCF provides the policy data to the UDR. Alternatively, the conversion can be performed after the policy is sent to the SMF. Performing the conversion later allows any updates / modifications in the service filters (e.g., indicated by the policy update request identifier) ​​or UE group members to be reflected in those policy update requests when the SMF obtains the policy.

[0594] The traffic steering policy may include any one or more of the following: DNN, application identifier, traffic filter, traffic steering profile ID, routing profile ID, time validity condition, space validity condition, N6 point-to-point tunnel requirement, and policy update request identifier. The traffic steering profile ID may be mapped from the routing profile ID in the policy update request (at step 2508).

[0595] The UP management event notification policy may include any one or more of the following: DNN, application identifier, service filter, time validity condition, space validity condition, event type, notification type, event notification receiver identifier (e.g., NEF or AF or PCF) and policy update request identifier.

[0596] The UE grouping policy may include any one or more of the following: DNN, application identifier, UE filter and policy update request identifier. In this case, the service filter in the policy update request (and AF request) may be used as a UE filter, and mapping / conversion may be performed on at least one of the NEF and PCF of the UE filter as described above.

[0597] Once the UP management policy (or equivalently, UP management policy data) is generated, the PCF may select a UDR and provide (at 2512) the corresponding UP management policy data to the selected UDR. The UDR may be selected using the DNN and application identifier. If desired, UE information in the service filter may also be used for UDR selection. The UDR may notify any other PCFs that have subscribed to policy data change events. Alternatively, this may be based on an overlap of any one or more of the DNN, application identifier, and spatial validity conditions (as required) and the PCF's service areas.

[0598] Once the policy data has been provided to the UDR, the PCF returns (at 2514) a policy update response message to the NEF (or AF) to acknowledge receipt of the policy update request.

[0599] The PCF 316 may also notify (at 2516) any SMF 310 that has subscribed to notification of policy update events. Alternatively, the PCF 316 may identify the target SMF based on the spatial validity condition (if any) and the overlap of the service area of ​​the SMF, and notify the identified SMF. Upon receiving the notification from the PCF 316, the subscribing SMF 310 may obtain the UP management policy, identify the PDU sessions to which the policy applies, and apply the policy to those PDU sessions.

[0600] In order to determine whether the SMF 310 has subscribed to notification of policy update events, the SMF 310 may send PDU session attributes (e.g., at least one of the following: application, DNN, UE's IP address, UE identifier, and UE location information) to the PCF 316, and the PCF 316 may check the PDU session attributes against the updated policy. The PCF 316 may provide the SMF 310 with the updated policy that the PDU session is eligible for based on the information available to it. The SMF 310 may also use the PDU session attributes that the PCF 310 does not have to check the PDU session against the updated policy. Therefore, there is no need to provide the SMF 310 with information for checking the PDU session by the PCF 316. For example, if the time validity condition is checked by the PCF 316, the SMF 310 does not need to check it, so the policy provided to the SMF will not be included. In an embodiment where the PCF does not check the PDU session attributes, all information may be provided to the SMF.

[0601] If necessary, the spatial validity conditions can be verified by the PCF (in this case, the SMF needs to notify the PCF of the UE location for spatial validity condition check) and trigger a policy update. In this case, at least one of the service steering policy and the UP management event notification policy does not include those conditions, because if the policy is exited, it is always spatially valid.

[0602] If necessary, the PCF can verify the time validity condition (in this case, the PCF periodically performs time validity condition checks) and trigger a policy update. In this case, at least one of the business steering policy and the UP management event notification policy does not include those conditions, because if the policy exits, it is always valid in time.

[0603] The SMF may maintain policies for individual PDU sessions. In this case, the policy may not include service filter information, and the PCF session may indicate a binding between the PDU session and the policy (e.g., the PCF checks the PDU session against the policy, and if a match is found, the PCF notifies the SMF to obtain the policy). The policy may contain service filter information. In this case, the SMF may check the service filter to determine whether to apply it to the PDU session or to a portion of the service associated with the PDU session. In both cases, the SMF subscription for policy updates may be general or PDU session specific.

[0604] A PDU session can be governed by multiple service steering policies. The SMF selects the service steering policy to be applied. In some embodiments, the SMF first selects the service steering policy, then identifies the UPF that supports the service steering specified in the policy (e.g., through the service steering profile ID) and performs UPF selection and service steering profile selection. The SMF provides the selected UPF with an identifier of the selected service steering profile. The UPF uses the service steering profile identifier to identify the service steering parameters in its local configuration.

[0605] In some embodiments, based on the N6 point-to-point tunnel requirements in the traffic steering policy, the SMF calculates the N6 point-to-point tunnel information and configures it into the PDU session anchor. The N6 point-to-point tunnel information may include a traffic forwarding template (TFT) for mapping the N6 tunnel to the UP path of the DL packet and the packet processing instructions for the UL packet (e.g., the tunnel protocol header to be applied).

[0606] exist Fig.25A In the example of , a PCF may be selected (at 2506) based on a PCF service area that overlaps with a spatial validity condition in the AF request. Fig.25B An alternative embodiment is shown in which a PCF is selected based on a DNN and an application identifier. Fig.25C Another alternative embodiment is described in which the PCF is selected by the UDM (or UDR) instead of the NEF.

[0607] like Fig.25B As can be seen, the call flow (also called message flow) process is roughly similar to Fig.25A process, except that in this case, step 2512 is omitted and step 2506 (PCF selection) is replaced by an alternative step (2518), in which the NEF 314 (or AF 324) can map the application network identifier to the DNN and map the application external identifier to the application identifier, and provide the resulting DNN and application identifier information to the NRF 318 to select the PCF 316. UE information in the service filter can also be used for PCF selection. The application identifier can be used within the 5GC and the control information (e.g., S-NSSAI, policy) involved in identifying the application by the UE. In some embodiments, multiple PCFs are selected and the NEF (or AF) sends a policy update request to all selected PCFs. In some embodiments, the NEF 314 (or AF 324) performs PCF selection by selecting a PCF agent (which is a network function) and sends the policy update request to the PCF agent, which then sends it to all PCFs it is serving or delegating. In some embodiments, the mapping can be pre-configured in the NEF (or AF). In some embodiments, the selection of the PCF may be pre-configured in the NEF (or AF), in which case the PCF selection step may be omitted.

[0608] Reference Fig.25C In the illustrated alternative embodiment, AF 324 and NEF 314 interact to perform steps 2500, 2502, and 2504, as described in reference Figure 3A as described above. Next (at 2520), the NEF 314 (or AF 324) may map the application network identifier to the DNN and the application external identifier to the application identifier, and use the resulting DNN and application identifier information to select the UDM 320. The UE information in the service filter may also be used for UDM selection. The application identifier may be used within the 5GC and used by the UE 102 to identify control information (e.g., S-NSSAI, policy) related to the application. In some embodiments, the mapping may be pre-configured in the NEF (or AF). In some embodiments, the selection of the UDM may be pre-configured in the NEF, in which case the UDM selection step 2520 may be omitted.

[0609] At step 2522, NEF 314 may process the AF request message and send an application data update request message to UDM 320. The application data update request message may include any one or more of the following parameters: request identifier; DNN; application identifier; service filter; time validity condition; space validity condition; request type; and request content.

[0610] The request identifier may be used to uniquely identify the application data update request, thereby enabling the NEF to modify or delete the application data update request, or to associate the application data update request with a future policy update request. The request identifier may be generated by the NEF 314 itself or by the UDM 320 (or UDR 322). In embodiments where the NEF 314 generates the request identifier, it may be included in an application data update request message sent to the UDM 320 (or UDR 322), which may record the request identifier for future use. In embodiments where the UDM (or UDR) generates the request identifier, it may be transmitted to the NEF 314 in an application data update response message, which will be described in more detail below. Preferably, the NEF 314 maintains a mapping between the application data update request identifier and the AF request identifier received by the NEF 314 in step 2500.

[0611] The DNN may be mapped from the application network identifier received by the NEF in step 2500. The mapping may be pre-configured in the NEF.

[0612] The application identifier may be mapped from the application external identifier received by the NEF in step 2500 and used in the 5GC and by the UE to identify control information related to the application (e.g., single network slice selection assistance information (S-NSSAI) policy). The mapping between the application external identifier and the application identifier may be pre-configured in the NEF.

[0613] The service filter field of the policy update request message may contain a policy update request identifier, which may be generated based on the AF request identifier (if any) in the service filter field of the AF request message received by the NEF.

[0614] The spatial validity condition may be in the form of a RAN node identifier or a cell identifier, and any spatial validity condition may be mapped from the spatial validity condition of the AF request message received by the NEF in step 2500. The mapping between the spatial validity conditions of the AF request message, and the mapping between the spatial validity conditions of the policy update request message may be pre-configured in the NEF.

[0615] In step 2524 , UDM 320 (or UDR) may return an application data update response message to NEF 314 .

[0616] Next, the UDM 320 (or UDR) may identify any PCF that has subscribed to the application data update notification. Alternatively, the UDM 320 (or UDR) may identify any PCF that has a service area that includes the local DN or intersects with the service area of ​​the local DN. The UDM 320 (or UDR) may then send (at 2526) a corresponding application data change notification message to each identified PCF 316. Based on the information contained in the received application data change notification message, the PCF 314 may generate a policy and forward a corresponding policy update notification to the subscribing SMF 310, as described above in steps 2510 and 2516. In some embodiments, the application data change notification is a simple signal and does not include the change details, and the PCF needs to interact with the UDM (or UDR) to obtain the details of the change and generate a policy accordingly.

[0617] It should be noted that Fig.25C In the example of , since the UDM 320 is used to select the PCF 314, the UDM 320 (or UDR) selection and notification steps described above at 2512 and 2514 can be omitted.

[0618] As can be appreciated, an application function 324 trusted by the operator can interact directly with the PCF 316. In this case, the AF 324 can also perform the role of the NEF in the process. Fig.26 Shows the corresponding Fig.25A An example call flow diagram of the example in which Fig.25A Steps 2500, 2502, and 2504 are not performed or are performed by AF 324, and steps 2506, 2508, and 2514 are replaced by steps 2600, 2602, and 2604, which are performed by AF 324, but are otherwise identical to steps 2506, 2508, and 2514. It should be understood that for Fig.25B , 25C Similar variations exist for the embodiments of 27A-28B, which are not described in detail in this specification for the sake of brevity.

[0619] Fig.27A324. It is a call flow diagram (also referred to as a message flow diagram) illustrating a UP path management process to AF 324. It is understood that the application function trusted by the operator can interact directly with PCF 316. In this case, AF 324 can play the role of NEF 314 in the process. The UP management event notification process can be performed at least one of before and after the UP management event is initiated in the user plane, depending on the type of notification.

[0620] For purposes of this procedure, the AF may subscribe (at 2700) to UP management event notifications from the SMF 314 using any suitable procedure, e.g., as described above, or as set forth in an applicable 3GPP technical standard.

[0621] In a first step (at 2702), the SMF 310 may apply the operator policy and identify (at 2704) each NEF (or AF) that requests a corresponding policy update notification.

[0622] The SMF 310 may then send (at 2706) a UP management event notification message to (or each) the identified NEF (or AF). The UP management event notification message may include one or more of the following parameters: policy update request identifier (or application data update request identifier); service filter; event type; notification type; and event notification content.

[0623] The policy update request identifier (or application data update request identifier) ​​may be obtained by the SMF from within the operator policy.

[0624] The service filter may indicate a service related to the UP management event, which is part of the service specified by the service filter field in the policy update request. The absence of a service filter in the UP management event notification message may be used to indicate that the UP management event is related to all services specified by the service filter in the policy update request. The service filter may include any suitable combination of: a UE identifier, such as a UE external identifier or an MSISSDN; and an IP address / prefix.

[0625] The notification type may be used to indicate whether the UP management event notification is a pre-notification or a post-notification.

[0626] The event notification content can be used to provide additional information related to the UP management event. The event notification content can include any one or more of the following: service filter; application location; anchor UPF location; and N6 point-to-point tunnel information. The application location can take the form of a routing profile ID or DNAI or a service steering profile ID. The anchor UPF location can take the form of a network address, which can depend on the tunnel type. For example, for an IP tunnel, it takes the form of an IP address; for an Ethernet tunnel, it takes the form of an Ethernet address. In some embodiments, the anchor UPF location information can be used to support N6 point-to-point tunnels in local DNs. N6 point-to-point tunnel information can be provided to be configured at the application location in order to bind DL services to N6 point-to-point tunnels to ensure correct DL packet delivery. N6 point-to-point tunnel information can include at least one of a tunnel endpoint address / identifier and a port number on the anchor UPF side. The form of the tunnel endpoint address / identifier can depend on the tunnel type. For example, for an IP tunnel, the tunnel endpoint address / identifier is preferably in the form of an IP address; and for an Ethernet tunnel, it is preferably in the form of an Ethernet address. In a specific embodiment, the specific information provided in the event notification content can depend on the type of event referenced by the UP management event notification. For example, in the case of a QoS change event, the event notification content may include a new "QoS rule." In another example, if the event type is a service steering change, the event notification content may include application location, anchor UPF location, and N6 point-to-point tunnel information.

[0627] Based on the received UP management event notification message, NEF 314 may send (at 2708) a corresponding UP management event notification message to AF 324. The UP management event notification message sent to AF 324 may include any one or more of the following: an AF request identifier; an event type; a notification type; and event notification content. The AF request identifier may be included in the above reference. Figures 25A-25B and 26. The event notification content can be mapped from the event notification content of the UP management event notification message received by the NEF from the SMF (step 2706). For example, the application location can be converted from the form of a routing profile ID or DNAI or a business steering profile ID to the form of a network address indicating the location where the application is deployed.

[0628] After receiving the UP Management Event Notification message from NEF 310, AF 324 may send (at 2710) a confirmation message to NEF 314. The confirmation may include the N6 point-to-point tunnel information to be configured in anchor UPF 304.

[0629] NEF 314 may then send (at 2712) an acknowledgement of the original UP management event notification message to SMF 310. In embodiments where the AF provides N6 point-to-point tunnel information to NEF 314, this information may be included in the acknowledgement message sent to SMF 310.

[0630] Upon receiving the confirmation message from the NEF 314, the SMF 310 may configure (at 2714) the N6 point-to-point tunnel information in the anchor UPF.

[0631] As described above, the operator's trusted application functions can interact directly with SMF 310. In this case, AF 324 can also Fig.27A Therefore, steps 2708 and 2710 will not be executed, and steps 2706 and 2712 are performed by AF 324.

[0632] Fig.27B is a call flow diagram (also referred to as a message flow diagram) illustrating an alternative process for UP path management notification to AF 324. Fig.27A As shown in the embodiment, the UP management event notification process can be executed at least one of before the UP management event is started and after it is completed in the user plane, depending on the type of notification.

[0633] For the purpose of this process, PCF 316 may subscribe (at 2716) to UP management event notifications from SMF 310 using any suitable process, for example, as described above, or as described in the applicable 3GPP technical standards. Similarly, AF may subscribe (at 2718) to UP management event notifications from PCF 316.

[0634] In a first step (at 2702), the SMF 310 may apply the operator policy and identify (at 2720) each PCF 316 that requests a corresponding policy update notification.

[0635] SMF 310 may send (at 2722) a UP management event notification message to the (or each) identified PCF 316. The UP management event notification message may be as described above with reference to Fig.27A formatted as described.

[0636] Based on the received UP management event notification message, PCF 316 may send (at 2724) a corresponding UP management event notification message to NEF 314. Before sending the message, it may convert the service steering profile ID or DNAI in the message into a service steering profile ID. The UP management event notification message sent to NEF 314 may include any one or more of the following: AF request identifier; event type; notification type; and event notification content. The AF request identifier may be included in the above reference. Figures 25A-25B The policy update request identifier in the policy update request message described in 2706 and 26 may be mapped. The event notification content may be mapped from the event notification content of the UP management event notification message received by the NEF from the SMF (step 2706). For example, the application location may be converted in the form of a routing profile ID to the form of a network address indicating the location where the application is deployed. The NEF 314 may forward (at 2726) the received UP management event notification message to the AF 324.

[0637] In some embodiments, the UP management event notification message sent to NEF 314 or PCF 316 may also include a content format field that provides information about how to construct data to allow network functions to correctly interpret the information in the event notification content. For example, the event notification content can be used to contain different types of information depending on the receiver function (e.g., routing profile ID, business steering profile ID, or event DNAI). In this case, the content format field can be used to indicate the appropriate format that will be used to read the information in the event notification content field. The content format field can be set by the PCF when creating a policy, or based on the content of the UP management event notification from the SMF (at step 2722).

[0638] After receiving the UP Management Event Notification message from the NEF 314, the AF 324 may send (at 2728) a confirmation message to the NEF 314. The confirmation may include the N6 point-to-point tunnel information to be configured in the anchor UPF 304.

[0639] NEF 314 may send (at 2730) an acknowledgement of the original UP Management Event Notification message to PCF 316. In embodiments where AF 324 provides N6 point-to-point tunnel information to NEF 314, this information may be included in the acknowledgement message sent to PCF 316.

[0640] Upon receiving the confirmation message from NEF 314 , PCF 316 may forward (at 2732 ) the confirmation message to SMF 310 .

[0641] Upon receiving the confirmation message from the PCF 316, the SMF 310 may configure (at 2714) the N6 point-to-point tunnel information in the anchor UPF 304.

[0642] As described above, the operator's trusted application functions can interact directly with PCF 316. In this case, AF 324 can also Fig.27B Therefore, steps 2726 and 2728 will not be executed, and steps 2725 and 2730 will be executed by AF 324.

[0643] Fig.28A and 28B A call flow diagram (also called a message flow diagram) is shown for a UE-requested PDU session establishment procedure for a non-roaming scenario. Fig.28A and 28B The process assumes that UE 102 is already registered with AMF 308, so AMF 308 has retrieved user subscription data from UDM 320.

[0644] In the first step (at 2800), the UE 102 initiates a UE requested PDU session establishment procedure by generating and sending a NAS message to the AMF 308. The NAS message may include S-NSSAI, DNN, application identifier, PDU session ID, and N1 SM information, and may contain a PDU session establishment request within the N1 SM information. The PDU session establishment request may include a PDU type, SSC mode, and protocol configuration options. The application identifier may be used to describe the UR 23 as described in clause A.3.1.3.3 of TS23.501.

[0645] The NAS message may include an application identifier corresponding to an edge computing application. This may occur when the DNN points to a local DN. The presence of the application identifier indicates that it is a request for a PDU session whose use is intended or dedicated to the edge computing application.

[0646] The NAS message sent by UE 102 may be encapsulated by the AN in an N2 message, which may also include user location information and access technology type information.

[0647] The SM information may include an SM PDU DN request container, which contains information of the PDU session authorized by the external DN.

[0648] Based on the information provided in the NAS message, the AMF 308 may determine a message corresponding to a request for a new PDU session based on a PDU session ID that is not used for any existing UE's PDU session. The AMF may then select (at 2802) an SMF for the PDU session.

[0649] In the next step (at 2804), the AMF 308 may send an SM request message to the selected SMF 310. The request message may include parameters such as: subscriber permanent ID, DNN, application identifier, S-NSSAI, PDU session ID, AMF ID, N1 SM information, user location information, and access technology type. The AMF ID uniquely identifies the AMF 308 serving the UE. The N1 SM information contains the PDU session establishment request received from the UE 102.

[0650] Based on the information provided in the SM request message, the SMF 310 may perform one or more checks to determine whether the UE request complies with the user subscription and local policies. This may include sending (at 2806) a subscription data request to the UDM 320 and receiving (at 2808) a subscription data response providing information of the user subscription. The subscription data may include authorized PDU types, authorized SSC modes, default QoS profiles, and subscription-defined group information (e.g., group identifiers). If the SMF 310 has not yet retrieved the SM-related subscription data for the UE 102 associated with the DNN, the SMF 310 may also request the subscription data from the UDM 320.

[0651] If the UE request does not comply with the user subscription and local policy, the SMF 310 may reject the UE request via NAS SM signaling to indicate to the AMF 308 that the PDU Session ID is to be considered released and the procedure terminated.

[0652] In embodiments where the SMF 310 needs to authorize / authenticate the establishment of a PDU session via a third party, the SMF may trigger an applicable third party PDU session establishment authentication / authorization process 2810. The third party triggered PDU session establishment process 2810 may include the SMF 310 sending a request to a third party authentication service, which may reside within the DN. The process 2810 may be via a UPF or NEF, as described elsewhere in this disclosure. If the PDU session establishment authentication / authorization fails, the SMF 310 may terminate the PDU session establishment process and indicate a rejection to the UE 102.

[0653] In an embodiment where a dynamic PCC is deployed, the SMF 310 may perform PCF selection (at 2812). The SMF 310 may also initiate a PDU-CAN session establishment (2814) with the PCF 316 to obtain the default PCC rules for the PDU session. In an embodiment where a dynamic PCC is deployed and the DNN points to a local DN, the SMF 310 may provide the DNN and the application identifier to the PCF 316. Additional information may be provided to the PCF 316 to implement more detailed policy decisions. For example, UE information (e.g., location information, UE identifier, subscription-defined group information, etc.) or service information (e.g., UE's IP address) may be provided so that the PCF may respond only to policies customized to specific UE or service requirements. If necessary, other PDU session related information may be provided. The PCF may use this information to obtain relevant policy data from the UDR for policy decisions. This may trigger a notification that the PCF subscribes to at least one of the policy data associated with the DN and the application program from the UDR. The PCC rules may include UP path management event notification policies. The PCC rule may include information of the N6 tunnel associated with the DN (e.g., at least one of the address and port number of the tunnel end in the DN). It is understood that the purpose of this step is to receive the PCC rule before selecting the UPF. If the PCC rule is not required as an input for the UPF selection, this step may be omitted.

[0654] The SMF 310 may select (at 2816) the UPF 304 and SSC mode for the PDU session. In embodiments where the PDU type is IPv4 or IPv6, the SMF 310 may allocate an IP address / prefix for the PDU session. For unstructured PDU types, the SMF 310 may allocate an IPv6 prefix (based on UDP / IPv6) for the PDU session and N6 point-to-point tunnel. If a service steering policy is provided, the SMF 310 may also select a service steering profile or policy in this step.

[0655] In an embodiment where a dynamic PCC is deployed in step 2514 and a PDU-CAN session establishment is not performed, the SMF 310 may initiate (at 2818) a PDU-CAN session establishment to the PCF 316 to obtain the default PCC rules for the PDU session. If the DNN points to a local DN, the SMF 310 may also provide the DNN and application identifier (if available) to the PCF 316 in addition to the UE information (e.g., UE identifier, subscription-defined group information). Otherwise, if a dynamic PCC is deployed and the PDU type is IPv4 or IPv6, the SMF 310 may initiate a PDU-CAN session modification and provide the PCF 316 with the allocated UE's IP address / prefix. If a dynamic PCC is deployed, then for unstructured PDU types, the SMF 310 may provide the PCF with the IPv6 prefix to be allocated for the PDU session.

[0656] In the next step (2820), the SMF 310 may select a traffic steering profile or policy.

[0657] In an embodiment that provides a UP path management event notification policy, the SMF may notify (at 622) the AF (or NEF) about the UP path selection. If the traffic steering policy indicates that dynamic configuration of N6 tunnel information between the SMF 310 and the AF 324 is required, the negotiation may also be performed together with the UP path selection notification. The notification may include N6 tunnel information related to the UPF (e.g., at least one of the address and port number of the UPF) and an indication that this is a previous notification.

[0658] In step 2824, the SMF 310 may send an N4 session establishment / modification request to the UPF 304 and provide the packet detection, enforcement, and reporting rules for the PDU session to be installed on the UPF 304. In an embodiment where the PDU session authentication process is not performed (at 2810), the N4 session establishment / modification request message may be used to initiate an N4 session establishment process with the selected UPF 308, otherwise it may be used to initiate an N4 session modification process with the selected UPF 308. If the CN tunnel information is allocated by the SMF, the applicable CN tunnel information is provided to the UPF 308 in this step. If the N6 tunnel is to be supported, the applicable N6 tunnel information is provided to the UPF 304 in this step. It should be understood that the N6 tunnel information does not necessarily have to be provided to the UPF 304 in this step.

[0659] The UPF may confirm the N4 session establishment / modification request message by sending (at 2826) an N4 session establishment / modification response message to the SMF. If the CN tunnel information is allocated by the UPF 308, the CN tunnel information used in this step may also be provided to the SMF 310.

[0660] In step 2828, SMF 310 may return an SM request confirmation message to AMF 308. The SM request confirmation message may include, for example, the following parameters: N2 SM information (e.g., PDU session ID, QoS profile, and CN tunnel information); N1SM information (e.g., PDU session establishment acceptance (including authorized QoS rules, and SSC mode)). The N2 SM information may carry information that the AMF needs to provide to the (R)AN. The CN tunnel information may correspond to the core network address of the N3 tunnel corresponding to the PDU session. The QoS configuration document may provide the AN with a mapping between QoS parameters and QoS flow identifiers. The PDU session ID may indicate to the UE the association between AN resources and the UE's PDU session via AN signaling using the UE. The N1 SM information may include a PDU session establishment acceptance message that the AMF needs to provide to the UE. Multiple authorized QoS rules may be included in the PDU session establishment acceptance message within the N1 SM information and the N2 SM information.

[0661] The SM Request Confirmation message may also contain information that allows the AMF to identify which UE is the target of the SMF request and to determine which access to use for the UE. The access information may be used to handle situations where the UE is connected simultaneously via 3GPP and non-3GPP accesses.

[0662] Now refer to Fig.28B In step 2830, the AMF may send an N2 PDU session request message to the (R)AN 302. The N2 PDU session request message may include, for example, the following parameters: N2 SM information; and PDU session establishment acceptance.

[0663] In response to the N2 PDU SESSION REQUEST message, the (R)AN 302 may initiate (at 2832) a specific signaling exchange with the UE 102 to establish resources for the PDU session. For example, in the case of a 3GPP RAN, an RRC connection reconfiguration may be performed if the UE 102 establishes the necessary RAN resources associated with the authorized QoS rules for the PDU session. A node within the (R)AN may also allocate (R)AN tunnel information for the PDU session. If the necessary RAN resources are established and the allocation of the (R)AN tunnel information is successful, the (R)AN node may forward a NAS message (including a PDU SESSION ESTABLISHMENT ACCEPT) to the UE.

[0664] After establishing resources for the PDU session, the (R)AN node 302 may send (at 2834) an N2 PDU session request confirm message to the AMF 308. The N2 PDU session request confirm message may also include (R)AN tunnel information corresponding to the access network address of the N3 tunnel for the PDU session. After the AMF 304 receives the N2 PDU session request confirm message, the UE 102 may be able to start sending (at 2836) uplink data for the PDU session to the UPF 304.

[0665] In the next step (2838), the AMF 308 may forward the N2 SM information received from the (R)AN to the SMF 310 using an SM request message including the N2 SM information.

[0666] Next, the SMF 310 may send (at 2840) an N4 session modification request to the UPF 304 to provide the AN tunnel information and (optionally) the CN tunnel information for the N4 session associated with the new PDU session. In the case where the N4 session for the new PDU session has not yet been established, the SMF 310 may initiate an N4 session establishment procedure with the UPF 304 to establish an N4 session including the AN tunnel information and (optionally) the CN tunnel information. Otherwise, the SMF 310 may initiate an N4 session modification procedure with the UPF 304 to add the AN tunnel information and (optionally) the CN tunnel information to the existing N4 session. It should be noted that if the SMF 310 selected the CN tunnel information in step 2816, only the CN tunnel information needs to be provided.

[0667] After receiving the N4 Session Establishment / Modification Response from the UPF (at 2842), the SMF 310 may notify (at 2844) the AF 324 (or NEF 314) about the UP path selection if a UP path management event notification policy is provided and a need for late notification is indicated. The notification may include N6 tunnel information related to the UPF (e.g., at least one of the address and port number of the UPF) and an indication that this is a late notification. If the N6 tunnel is to be used, this step may indicate to the AF that the N6 tunnel is ready for use. Subsequently, the AMF may forward the relevant events to the SMF at handover, such as when the (R)AN tunnel information changes or the AMF is relocated.

[0668] The SMF 310 then returns (at 2846) an SM Request Acknowledgement to the AMF 308 before generating and sending (at 2848) an IP Router Advertisement to the UE 102 via the N4 session and the UPF 304. This step provides the IP configuration information so that downlink data can be sent to the UE (at 2850).

[0669] During the lifetime of a PDU Session, the AMF 308 stores the association of the PDU Session ID and the SMF ID.

[0670] Fig.29A and 29B A call flow diagram illustrating the procedure for UE-requested PDU session establishment for roaming with local burst is shown. Fig.29A and 29B The process and Fig.28A and 28B , except that in the case of roaming with local breakout, SMF 310, UPF 304 and PCF 316 are all located in the access network. This means that the above steps 2820, 2822 and 2844 are not performed.

[0671] Fig.30 is a flow chart illustrating a switching process according to an exemplary embodiment of the present invention. It will be well understood that in the flow chart shown, different entities are responsible for performing different steps. It should be further understood that this represents the interaction of multiple independent methods, each of which is performed on a different node or function. A variation of the method will not necessarily require a change in another method. In addition, in the case of sending a message to a second function with reference to a first function, it should be understood that this means that the second function performs the step of receiving the message sent by the first function.

[0672] In the first step (3000), the AF may subscribe to notifications of UE mobility events for certain specific services associated with an application. UE mobility events may include, for example, the UE moving out of the service area of ​​the current local DN.

[0673] Subsequently, the AMF may detect the UE mobility event (at 3002) and send a corresponding notification to the AF (at 3004). Alternatively, the AMF may notify the SMF, which in turn notifies the AF. The notification may be sent via the NEF (e.g., when the AF is not trusted) or directly to the AF (e.g., when the AF is in a trusted domain). The notification may include the local DN of the target that the UE is entering (where the application is also deployed).

[0674] Upon receiving the notification, the AF may identify (at 3006) a second AF associated with the application in the target DN and notify the second AF of the application identifier, service filter (indicating the affected application services), and application context information. The AF may optionally notify the second AF of the AMF notification identifier (carried in the AMF notification).

[0675] The second AF may then send a request (at 3012) to the 5GC (e.g., SMF) to trigger PDU session establishment or resumption after the UE enters the target's local DN. The request sent to the 5GC (e.g., SMF) for PDU session establishment or resumption may include at least one of an AMF notification identifier and a service filter so that the 5GC can resume the correct PDU session or notify the UE to establish a PDU session for a suitable service.

[0676] Once a UE mobility event has occurred, the AMF may send a corresponding notification to the SMF (at 3008), and the SMF may respond by deactivating or releasing (at 3010) the PDU session associated with the application.

[0677] In some cases, the same AF may be associated with the application in the current and target DNs. In this case, the "AF" and "second AF" referenced above are actually the same entity. Therefore, the interaction between the two AFs in step 3006 becomes an internal process, and step 3012 may be performed by a response message from the first AF to the AMF or SMF.

[0678] Understandably, Fig.30 The process allows the UE's application session to be preserved because the application context is transferred to the second AF that controls the application in the target DN.

[0679] In some embodiments, the AF is an application server. In other embodiments, the AF is not an application server, but operates to configure the application context into the application server to restore / preserve the application session.

[0680] In some embodiments, the AF is an SDN controller that operates to configure forwarding rules in the transport network to ensure that packets are delivered to the correct UPF.

[0681] In some embodiments, the application is a video streaming application, and the application context information describes how (from where) to resume the interrupted video stream. In some embodiments, the application is a game application, and the application context information describes how (from where) to rebuild or resume the game context.

[0682] DNAI is an identifier pointing to a node or function that provides DN access to user plane services. The node or function that UP sends services to DN can direct the services to DNAI. In some embodiments, DNAI can be a network element such as a router, which is strategically deployed by the operator. In other embodiments, DNAI can be a gateway function that provides access to a data center where a virtual UPF is instantiated. Application location refers to the network element (e.g., server, data center) where the application is deployed. Multiple applications can be deployed in the same location.

[0683] It should be understood that when an application communicates with a UE over a 3GPP compatible network, the program location can be mapped or associated with a DNAI. In some embodiments, the association can be part of a routing profile (e.g., stored or specifically stated in a routing profile). In other embodiments, the association is outside the routing profile and may be stored in a locally accessible table or in a functional reference point within the network. In some embodiments, the routing profile describes routing parameters associated with the routing of application location services. This can take the form of one or a combination of the destination address and destination port number at the application location. These embodiments are examples of situations where the association can be outside the routing profile. Those skilled in the art will understand that in some embodiments, the routing profile can be application location specific. This allows services to be directed to a DNAI and forwarded from there to the application. Applications can be instantiated in different DNs. Within the same DN, applications can be instantiated in multiple locations, and each application location can be associated with multiple DNAIs. In implementations where a routing profile is specific to each application location, the routing profile may indicate a transport address, such as an IP address and port number, or a network address, such as an Ethernet address, associated with the application location, and other traffic routing parameters to be used by a DNAI associated with the application location to route traffic to the application location.

[0684] In some embodiments, the routing profile and the association between the routing profile (or the corresponding application location) and the DNAI can be configured to the NEF through another network function (e.g., AF) that coordinates with the NEF, or through a management plane function such as a network manager, a slice manager, a service manager, etc. In an embodiment where the AF is within a trusted domain, the routing profile and the association between the routing profile and the DNAI can be configured to the AF itself.

[0685] Because DNAI identifies a data network access point, and each DN can support multiple different applications and UPFs, DNAI can be associated with multiple different UPFs. A service steering profile is typically associated with a DNAI and then applied to each UPF associated with the DNAI. In some embodiments, the PCF may be configured with information about the DNAI and a service steering profile. In some embodiments, the association between the service steering profile and the UPF may be configured into the SMF. In another embodiment, the service steering profile may be configured into the UPF and the SMF. The above configuration may be performed by management plane functions, such as a network manager, a slice manager, a service manager, and the like. Other network functions, including SMF, NEF, or PCF, may also play a role in the configuration of the UPF and the service steering profile. In implementations where the service steering profile is specific to each DNAI, the service steering profile may indicate a transport address, such as an IP address and a port number, or a network address such as an Ethernet address associated with the DNAI, as well as other service routing parameters to be used to route services to the DNAI and used by the UPF associated with the DNAI. The service steering profile may also indicate the DNAI itself by an identifier.

[0686] Fig.31 3100 is a logic block diagram illustrating an example relationship between application locations, DNAIs, and UPFs. A set of four UPFs are shown, UPF1 3102, UPF2 3104, UPF3 3106, and UPF4 3108. A set of two application locations, AS1 3120 and AS2 3126, are shown. Access to AS1 3120 can be through DNAI 1 3110 or DNAI 2 3114. Access to AS2 3126 is through DNAI 2 3114. Traffic from UPF1 3120 and UPF2 3104 to AS1 3120 is restricted by Traffic Steering Profile 1 3112 and Routing Profile 1 3122. Traffic from UPF2 3104, UPF3 3106, and UPF4 3108 to AS2 3126 is restricted by Traffic Steering Profile 2 3116 and Routing Profile 2 3124. Therefore, traffic from UPF2 3104 may be subject to different traffic steering profiles based on the target application location.

[0687] Routing profile 1 3122 corresponds to application location AS1 3120, which is associated with DNAI1 3110 and DNAI2 3114. Routing profile 2 3124 corresponds to application location AS2 1326, which is associated with DNAI2 3114.

[0688] The association between UPF and DNAI may imply that UPF may support traffic steering for DNAI using information specified in a traffic steering profile associated with DNAI. For example, UPF2 3104 is associated with DNAI1 3110 and DNAI2 3112. Therefore, UPF2 3104 is able to steer traffic for both DNAIs.

[0689] The information mapping configured in NEF, PCF, and SMF is as follows:

[0690] @NEF: Application location ←→ routing configuration file

[0691] @PCF: routing profile ←→ DNAI;

[0692] DNAI←→Business Steering Configuration File

[0693] @SMF: Business Steering Profile ←→ UPF

[0694] The PCF does not necessarily need to know the contents of the routing configuration file, and similarly, the SMF does not necessarily need to know the contents of the service steering configuration file.

[0695] exist Fig.31 In the illustrated embodiment, there is a minimum set of information available for each different type of network function. The AF should have access to the application location (e.g., based on the transport address or network address of the application location). The DNAI should have access to the routing profile associated with the application location associated with it. The UPF should have access to the service steering profile of the DNAI associated with it. The configuration of these nodes and functions so that they are provided with this information, or providing access to this information, can be performed by any one of a number of different management plane functions, such as at least one of a network manager, a slice manager, a service manager, and an AF. For example, the AF can provide the necessary information to the DNAI, and the management planning function provides the necessary information to the NEF, PCF, SMF, and UPF.

[0696] The N6 tunnel information that may be provided by the SMF is used by the UPF to establish the N6 tunnel and to determine the processing to be applied to the UL packets sent through the N6 tunnel. The N6 tunnel information may include tunnel types, such as IP tunnels, Ethernet tunnels, IPv6 / UDP tunnels, etc. It may include information about tunnel endpoint identifiers or addresses, port numbers, and other tunnel protocol parameters. The service steering parameters may be obtained using a service steering profile ID (which itself may be obtained from, for example, a function of the SMF). The service steering parameters may be obtained from a local configuration. If the service steering parameters are not pre-configured locally in the UPF, the UPF may obtain them from, for example, a function of the SMF. If the SMF provides service steering parameters to the UPF, the SMF may not provide the service steering profile ID to the UPF. The packets sent through the N6 tunnel may be encapsulated, and the service steering information may be embedded in an outer header. The outer header may also include an identifier of the processing to be applied to the UL packets.

[0697] As will be appreciated, the manner in which services in the UP are routed and processed can be configured by the CP function. For service routing affected by applications, the configuration process can begin with the AF performing a request process to send an application location notification to the network. The AF can provide the application location (e.g., in the transport address) and N6 tunnel information (if any) to the NEF. The NEF can map the application location received from the AF to a routing profile. The NEF can then send the routing profile ID and the N6 tunnel information to the PCF. The PCF can map the routing profile ID to at least one DNAI. The routing profile ID can also be mapped to a service steering profile, for example, by mapping at least one DNAI. Based on these mappings, a service steering policy can be generated. The service steering policy will typically specify one or more service steering profile IDs, routing profile IDs, and N6 tunnel information. The service steering policy may also contain other information, such as validity conditions.

[0698] For non-IP services, N6 tunnel information is usually required. For IP services, it can be optional. If N6 tunnel is not used when processing IP services, the service routing parameters in the service steering profile and routing profile can together describe how to route the service end-to-end through N6.

[0699] Now discuss an example of the impact of applying an application on service routing during the session establishment process (or session modification process). The process may start with the PCF sending a service steering policy to the SMF. The SMP may then map the service steering profile ID (typically included in the service steering policy, but optionally provided with the policy) to the UPF. The PCF may then perform the UPF / service steering selection process and provide the selected service steering profile ID and N6 tunnel information (carried by the policy) to the UPF selected for the PDU session. The SMF may compile / process the N6 tunnel information before sending it to the UPF, for example, generating a tunnel header for the UPF to apply to UL packets. The SMF may also generate a service forwarding template. The UPF may use the TFT to map the N6 tunnel to a path in the UP for DL ​​services.

[0700] The SMF may send notifications of any N6 tunnel changes to the NEF (e.g., N6 tunnel endpoint changes due to UPF reselection). The SMF may also send notifications to the NEF to inform the NEF of service steering changes, which may include changes in at least one of the DNAI mapping and the routing profile ID. The NEF may map the DNAI to a transport address and map the routing profile ID to a service address of the corresponding application location. The NEF may then provide information associated with the N6 tunnel changes and service steering changes (after information mapping) to the AF.

[0701] Based on the foregoing description, it can be understood that the embodiments of the present invention can provide:

[0702] A method for managing protocol data unit session data traffic on a network, the method comprising a control plane entity available on the network:

[0703] Receive an application system (AS) location notification based on an application program interface (API) from an AS controller, the

[0704] The AS location notification of the API identifies the AS location and data traffic to be associated with the identified AS location; and, sends the AS location notification to locate the AS.

[0705] In some embodiments, before the control plane entity sends the AS location notification, the method further comprises the control plane entity authenticating the AS controller.

[0706] In some embodiments, authenticating the AS controller includes sending an authentication request to an authentication server function (AUSF) available on the network; and, receiving an authentication response from the AUSF indicating an authentication result in response to the authentication request.

[0707] In some embodiments, the AS location notification comprises an AS relocation notification that changes an existing location of a PDU session.

[0708] In some embodiments, the AS location notification comprises an AS location notification that establishes the location of a future PDU session.

[0709] In some embodiments, the AS relocation notification is sent to a session management function (SMF) to configure traffic redirection of data traffic for the relocated AS.

[0710] In some embodiments, the AS location notification is sent to a policy control function (PCF) to generate a user plane (UP) selection policy and a traffic steering policy for data traffic.

[0711] A method for managing protocol data unit (PDU) session data traffic exchanged with a user equipment (UE) connected to a network, the method comprising a control plane entity available on the network:

[0712] receiving a PDU session request from the UE;

[0713] Verifying the UE context and authorizing the session request based on the user subscription data, and if authorized, the method further comprises:

[0714] Select and establish a user plane (UP) path for the requested PDU session;

[0715] Send a PDU session request response to the UE.

[0716] In some embodiments, the PDU session request includes a session ID.

[0717] In some embodiments, the PDU session request includes a preferred SSC mode for the requested PDU session.

[0718] In some embodiments, the PDU session request includes an application identifier indicating that the PDU session request is specific to an application associated with the application identifier.

[0719] A method for connecting a UE to a network, comprising a session management function available on the network:

[0720] receiving a PDU session request from the UE;

[0721] Selecting an end-to-end user plane (UP) path for a PDU session;

[0722] Notify the application functions available on the network of the selected end-to-end UP path;

[0723] A request to establish a PDU session connection for the UE corresponding to the selected end-to-end UP path is sent to an access node (AN).

[0724] In some embodiments, the AN includes a serving AN that receives a PDU session request from the UE and forwards the PDU session request to the SMF.

[0725] In some embodiments, the PDU Session Request indicates an anchor User Plane Function (UPF) location and an application location of an application function.

[0726] An electronic device, comprising:

[0727] Network interface;

[0728] processor;

[0729] A memory for storing instructions which, when executed by a processor, cause the electronic device to perform the methods described herein.

[0730] A method for managing protocol data unit session data traffic on a network, the method comprising a network exposure function (NEF) available on the network:

[0731] Select the Policy Control Function (PCF) available on the network;

[0732] Sending a user plane (UP) selection notification policy update request to the PCF; and

[0733] Receive UP selection notification policy update response.

[0734] In some embodiments, selecting a policy control function (PCF) available on the network is based on receipt of a UP selection notification subscription request, and wherein the method further comprises:

[0735] Send UP opt-in notification subscription response.

[0736] In some embodiments, a UP selects a notification subscription request received from an application function (AF) available on a network, and wherein a UP selects a notification subscription response is sent to the AF.

[0737] A method for managing a network, the method comprising exchanging user plane management information between an application function entity supporting one or more applications and a slice management function entity configured to manage service flows in corresponding slices of the network.

[0738] A slice management function entity for managing service flows in corresponding slices of a network, the slice management function entity being configured to exchange user plane management information with an application function entity supporting one or more applications of the network.

[0739] An application function entity supporting one or more applications in a network, wherein the application function entity is configured to exchange user plane management information with a slice management function entity, and the slice management function entity is configured to manage service flows in relevant slices of the network.

[0740] In some embodiments, the user plane management information includes one or both of the following:

[0741] Operator policy information or events; and

[0742] The business requirements of the application supported by the application functional entity.

[0743] A method for establishing a PDU session performed by a network entity executed on a processing unit of a network node of a communication network, comprising the network entity performing the following steps:

[0744] receiving, from the UE, a session request including an application identifier;

[0745] Send authentication / authorization requests to the Network Exposure Function (NEF) on behalf of the UE;

[0746] Receive an authentication / authorization response from the NEF; and

[0747] Authorize the PDU session based on the authentication / authorization response.

[0748] In some embodiments, the network entity includes session management functionality.

[0749] In some embodiments, the network entity sends the authentication / authorization request to the third party entity through the NEF.

[0750] In some embodiments, the network entity receives an authentication / authorization response from the third party entity via the NEF.

[0751] A network node, for establishing a PDU session on a communication network, the network node comprising:

[0752] A processor for enabling a network node to:

[0753] receiving, from the UE, a session request including an application identifier;

[0754] Send authentication / authorization requests to the Network Exposure Function (NEF) on behalf of the UE;

[0755] Receive an authentication / authorization response from the NEF; and

[0756] Authorize the PDU session based on the authentication / authorization response.

[0757] In some embodiments, a network node is enabled to act as a session management function.

[0758] In some embodiments, the network node sends the authentication / authorization request to the third party entity through the NEF.

[0759] In some embodiments, the network node receives an authentication / authorization response from a third party entity via the NEF.

[0760] A method for establishing a PDU session performed by a network entity executed on a processing unit of a network node of a communication network, comprising the network entity performing the following steps:

[0761] receiving a session request from a UE;

[0762] If the session request does not contain an application identifier, detect the application service related to the session request and send it to the control plane entity.

[0763] Sending a notification indicating application service detection and requesting application service redirection reselection; and

[0764] If the session request includes an application identifier, the PDU session is intended for use with the application identifier.

[0765] Notifications of associated application services.

[0766] In some embodiments, the network entity includes session management functionality.

[0767] In some embodiments, if the session request includes an application identifier, the method further includes:

[0768] Send authentication / authorization requests to third-party entities through NEF.

[0769] In some embodiments, if the session request includes an application identifier, the method further includes: receiving, by the NEF, an authentication / authorization response from a third-party entity.

[0770] A network node, for establishing a PDU session on a communication network, comprising:

[0771] A processor for enabling a network node to:

[0772] receiving a session request from a UE;

[0773] If the session request does not include an application identifier, the network node may be operable to detect application traffic associated with the session request and

[0774] sending a notification to the control plane entity indicating application traffic detection and requesting reselection of application traffic redirection; and if the session request includes an application identifier, the network node may be operable to send to the control plane entity a PDU session intended for use

[0775] Notification of application services associated with an application identifier.

[0776] In some embodiments, a network node is enabled to act as a session management function.

[0777] In some embodiments, if the session request includes an application identifier, the network node may also be operable to send an authentication / authorization request to the third party entity through the NEF.

[0778] In some embodiments, if the session request includes an application identifier, the network node may also be operable to receive an authentication / authorization response from the third party entity through the NEF.

[0779] A method for establishing a PDU session performed by a network entity on a processing unit of a network node of a communication network, comprising the network entity performing the following steps:

[0780] receiving, from the UE, a session request including an application identifier;

[0781] Obtaining the PCC rules associated with the application identifier; and

[0782] Configure an application service processing policy for the PDU session according to the obtained PCC rules.

[0783] In some embodiments, the network entity includes session management functionality.

[0784] A network node, for establishing a PDU session on a communication network, comprising:

[0785] A processor for enabling a network node to:

[0786] receiving, from the UE, a session request including an application identifier;

[0787] Obtaining the PCC rules associated with the application identifier; and

[0788] Configure an application service processing policy for the PDU session according to the obtained PCC rules.

[0789] In some embodiments, a network node can act as a session management function.

[0790] A method for establishing a PDU session performed by a network entity on a processing unit of a network node of a communication network, comprising the network entity performing the following steps:

[0791] receiving a third-party authentication / authorization request including an application identifier from a session management entity;

[0792] Selecting an Application Function (AF) based on a third-party authentication / authorization request; and

[0793] Send a third-party authentication / authorization request to the selected AF.

[0794] In some embodiments, the network entity includes a network exposure function (NEF).

[0795] In some embodiments, the session management entity comprises a session management function (SMF).

[0796] In some embodiments, the method further comprises:

[0797] Receive an authentication / authorization response from the selected AF.

[0798] In some embodiments, the method further comprises:

[0799] Send the authentication / authorization response to the session management entity.

[0800] In some embodiments, the AF is external to the session management entity and direct communication of the AF with the session management entity is not operable.

[0801] In some embodiments, the network entity and the session management entity are core network functions, and wherein the selected AF is external to the core network.

[0802] It should be understood that one or more steps of the embodiment method provided herein can be performed by corresponding units or modules. For example, a signal can be sent by a sending unit or a sending module. A signal can be received by a receiving unit or a receiving module. A signal can be processed by a processing unit or a processing module. Other steps can be performed by modules or functional elements specific to those steps. Each unit / module can be implemented as dedicated hardware, software executed on a hardware platform consisting of general hardware or a combination thereof. For example, one or more units / modules can be implemented as integrated circuits, such as field programmable gate arrays (FPGA) or application-specific integrated circuits (ASIC). It should be understood that in the case where the module is software, they can be stored in a memory and retrieved by a processor in whole or in part as needed, individually or together, to be processed in a single or multiple instances when needed. The module itself can include instructions for further deployment and instantiation.

[0803] Although the present invention has been described with reference to specific features and embodiments of the present invention, it is apparent that various modifications and combinations thereof may be made without departing from the present invention. Therefore, the specification and drawings should be viewed simply as an illustration of the present invention as defined by the appended claims, and any and all modifications, variations, combinations or equivalents falling within the scope of the present invention are contemplated.

Claims

1. A session management method, comprising: The policy control function obtains the potential location of the application and the tunnel requirements of the tunnel between the user plane function and the data network; The policy control function sends a service steering policy to the session management function, where the service steering policy is used to configure a session anchor point, the service steering policy includes the tunnel requirement, and the service steering policy indicates a potential location of an application associated with the tunnel requirement.

2. The method according to claim 1, wherein: The tunnel requirements indicate the type of the tunnel and / or protocol parameters of the tunnel.

3. The method according to claim 2, wherein: The protocol parameters include: one or more of a tunnel endpoint address, a tunnel endpoint identifier, and a port number of the application location.

4. The method according to any one of claims 1 to 3, wherein: The session management function is a session management function that has subscribed to policy update event notifications.

5. The method according to any one of claims 1 to 3, wherein: The policy control function obtains the potential location of the application and the tunnel requirements of the tunnel between the corresponding user plane function and the data network, including: The policy control function receives a request message from an application function, the request message including the potential location and the tunnel requirement.

6. The method according to claim 5, wherein: The request message also includes a space validity condition, and the method further includes: The policy control function verifies the spatial validity condition according to the location information of the terminal device; The policy control function sends a service redirection policy to the session management function, including: The policy control function sends the service redirection policy to the session management function according to the verification result of the space validity condition.

7. The method according to claim 6, wherein: The policy control function receives a request message from the application function, including: The policy control function sends a subscription message to a data repository, wherein the subscription message is used to subscribe to notifications of information associated with the request message; The policy control function receives information associated with the request message from a data repository.

8. A method for session management, comprising: The session management function receives a service steering policy from the policy control function, the service steering policy including tunnel requirements for a tunnel between the user plane function and the data network; The session management function determines tunnel information of the tunnel according to the tunnel requirement; The session management function configures the tunnel information to a session anchor point.

9. The method according to claim 8, wherein: The tunnel requirements indicate the type of the tunnel and / or protocol parameters of the tunnel.

10. The method according to claim 8, wherein: The tunnel information includes: A traffic forwarding template and a data packet processing instruction for an uplink data packet, wherein the traffic forwarding template is used to map the tunnel to a user plane path of a downlink message.

11. The method according to any one of claims 8 to 10, wherein: The method further comprises: The session management function receives a subscription request for user plane management event notification from an application function; The session management function sends a user plane management event notification message to the application function, where the user plane management event notification message includes event notification content related to the user plane management event, and the event notification content includes the tunnel information.

12. The method according to claim 11, wherein: The event notification content also includes one or more of an application location and a traffic filter including a UE identifier.

13. The method according to claim 11, wherein: The user plane management event notification message further includes a notification type indicating the user plane management event notification, where the notification type includes an advance notification and / or a delayed notification.

14. A session management method, characterized in that: include: The policy control function obtains the potential location of the application and the tunnel requirements of the tunnel between the user plane function and the data network; The policy control function sends a service steering policy to the session management function, where the service steering policy is used to configure a session anchor point, the service steering policy includes the tunnel requirement, and the service steering policy indicates a potential location of an application associated with the tunnel requirement; The session management function determines tunnel information of the tunnel according to the tunnel requirement; The session management function configures the tunnel information to a session anchor point.

15. The method according to claim 14, characterized in that The tunnel requirements indicate the type of the tunnel and / or protocol parameters of the tunnel.

16. The method according to claim 15, wherein: The protocol parameters include: one or more of a tunnel endpoint address, a tunnel endpoint identifier, and a port number of the application location.

17. The method according to any one of claims 14 to 16, wherein: The session management function is a session management function that has subscribed to policy update event notifications.

18. The method according to any one of claims 14 to 16, wherein: The policy control function obtains the potential location of the application and the tunnel requirements of the tunnel between the corresponding user plane function and the data network, including: The policy control function receives a request message from an application function, the request message including the potential location and the tunnel requirement.

19. The method according to claim 18, wherein: The request message also includes a space validity condition, and the method further includes: The policy control function verifies the spatial validity condition according to the location information of the terminal device; The policy control function sends a service redirection policy to the session management function, including: The policy control function sends the service redirection policy to the session management function according to the verification result of the space validity condition.

20. The method according to claim 19, wherein: The policy control function receives a request message from the application function, including: The policy control function sends a subscription message to a data repository, wherein the subscription message is used to subscribe to notifications of information associated with the request message; The policy control function receives information associated with the request message from a data repository.

21. A communication device, characterized in that: include: A processor, wherein the processor is configured to execute instructions stored in a memory so that the method according to any one of claims 1 to 7 is implemented.

22. A communication device, characterized in that: include: A processor, wherein the processor is configured to execute instructions stored in a memory so that the method according to any one of claims 8 to 13 is implemented.

23. A communication system, characterized in that: The system comprises at least one processor, wherein the at least one processor is used to execute instructions stored in a memory to implement a policy control function and a session management function, wherein The policy control function is configured to perform the following steps: Capture potential locations of applications and tunnel requirements for tunnels between user plane functions and the data network; Sending a service redirection policy to a session management function, the service redirection policy being used to configure a session anchor point, the service redirection policy including the tunnel requirement, the service redirection policy indicating a potential location of an application associated with the tunnel requirement; The session management function is configured to perform the following steps: receiving a traffic steering policy from the policy control function, the traffic steering policy comprising a tunnel requirement for a tunnel between a user plane function and a data network; determining tunnel information of the tunnel according to the tunnel requirement; The tunnel information is configured to the session anchor.

Images