CN111771394B - System and method for UE context and PDU session context management - Google Patents

Abstract

Systems and methods are provided for grouping of UEs such that UEs may share a UE group context or share a PDU session context or both. In this way, network resource usage with respect to UE context and PDU session context management may be mitigated.

Description

System and method for UE context and PDU session context management

Cross reference to related applications

This application claims priority to U.S. non-provisional application serial No. 15/898,442, filed 2018, 2, month 17, the contents of which are incorporated herein by reference.

Technical Field

The present invention relates generally to the field of communication networks, and particular embodiments or aspects relate to management of UE context and PDU session context.

Background

Based on the LTE network architecture, when a User Equipment (UE) is turned on and attached to the network, a Mobility Management Entity (MME) creates a UE context. The MME allocates to the UE a unique short temporary identity called SAE temporary Mobile subscriber identity (S-TMSI), which identifies the UE context in the MME. The UE context holds subscriber subscription information downloaded from a Home Subscriber Server (HSS). The local storage of subscription data in the MME allows procedures such as bearer establishment to be performed faster, since it does not need to consult the HSS every time. In addition, the UE context also maintains dynamic information such as the established bearer list and terminal capabilities. As will be readily appreciated, this UE context information is also used by the base station, e.g. an evolved NodeB (eNB) associated or connected with the UE, e.g. an eNB UE context, which is an information block in the eNB associated with one active UE.

In addition, the UE receives a service through a Protocol Data Unit (PDU) session, which is a logical connection between the UE and the data network. The UE requests the establishment of a PDU session, so in the current context the UE has an associated UE context and PDU session context, which must be stored and managed by the communication network in order to provide the UE with the required functionality.

Third Generation partnership project (3) of 2016 12 months, 14.0.0, entitled "architecture study of Next Generation System", no. TR 23.799 ^rd Generation Partnership Project,3 GPP) technical report (hereinafter TR 23.799) represents one approach to system architecture design for next Generation mobile networks, also referred to as fifth Generation (5 th Generation) (mobile networks) ^th generation, 5G) network. In proposed "next generation" (NG) networks, such as 5G wireless communication networks, additional flexibility and functionality is available. Furthermore, as the Internet of Things (IoT) brings connectivity to a new family of devices, more connectivity to the network is proposed. Furthermore, in NG networks, a supporting UE may establish multiple PDU sessions to the same data network. Therefore, there is a need to manage network resource usage, such as storage, computation, and signaling.

Accordingly, there may be a need for a system and method for managing UE context or PDU session context or both that is not constrained by one or more limitations of the prior art.

This background information is intended to provide information that may be relevant to the present invention. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present invention.

Disclosure of Invention

It is an object of the present invention to obviate or mitigate at least one disadvantage of the prior art.

According to one aspect of the present invention, a method for selecting a network open function (NEF) in a communication network is provided. The method comprises the following steps: an Application Function (AF) acquires information on a UE and information on a NEF set including one or more NEFs, selects the NEF based on the acquired information and enforces the selected NEF to serve the UE.

According to one aspect of the invention, there is provided a network function comprising a network interface for receiving data from and sending data to a network function connected to a network and to a processor. The network function also includes a non-transitory memory for storing instructions that, when executed by the processor, cause the network function to be configured to: acquiring information on the UE and information on a NEF set including one or more NEFs, selecting a NEF based on the acquired information, and enforcing the selected NEF to serve the UE.

In some embodiments, the selected NEF is different from a source NEF serving the UE prior to selection of the selected NEF. However, it is readily understood that in the absence of improved NEF selection, the selected NEF may actually be the same NEF as the source NEF. According to an embodiment, an Application Function (AF) provides information to a common API framework (CAPIF) core function, where the information may be used for NEF selection. In some embodiments, the CAPIF core functionality may provide a list of suitable NEFs from which the AF may select a NEF. It will be readily appreciated that one or more of the above may be included in an embodiment.

In some embodiments, obtaining information comprises: the AF receives a UE context of the UE. In some embodiments, the information about the NEF includes one or more of: public Land Mobile Network (PLMN) Identifier (ID), dynamic Neural Network (DNN), data Network Access Identifier (DNAI); application ID, AF service identification; single network slice selection assistance information (S-NSSAI), network slice instance ID (NSI-ID), UE group ID including internal group ID, external group ID, international Mobile Subscriber Identity (IMSI) group ID, UE ID, AF IP address, AF Fully Qualified Domain Name (FQDN), user Plane Function (UPF) IP address, FQDN, access Management Function (AMF) ID, AMF IP address, AMF FQDN, session Management Function (SMF) ID, SMF IP address, and SMF qdn. In some embodiments, enforcing the NEF includes: the AF subscribes to the event open service of the selected NEF and sends an impact traffic routing request to the selected NEF. In some embodiments, prior to selecting, the method comprises: the AF subscribes to the event open service of the source NEF and sends an impact traffic routing request to the source NEF. In some embodiments, after selecting, the method comprises: the AF cancels the event open service of the feed NEF and the AF cancels the impact traffic routing request with the feed NEF. It will be appreciated that suitable network functions may be configured to perform the further method steps described above. It will be readily appreciated that one or more of the above may be included in one embodiment.

According to one aspect of the present invention, a method for selecting a network open function (NEF) in a communication network is provided. The method comprises the following steps: upon receiving a trigger, the NEF is selected to serve the UE, the trigger resulting from one or more of UE mobility, load balancing, NEF relocation, denial of service attack, reselection request, and enforcing transmission of the UE context of the UE to the selected NEF.

According to one aspect of the invention, there is provided a network function comprising a network interface for receiving data from and sending data to a network function connected to a network and to a processor. The network function also includes a non-transitory memory for storing instructions that, when executed by the processor, cause the network function to be configured to: selecting a NEF to serve the UE upon receiving a trigger, the trigger resulting from one or more of UE mobility, load balancing, NEF relocation, denial of service attack, reselection request, and enforcing transmission of the UE context of the UE to the selected NEF.

According to some embodiments, the selecting is performed by a Session Management Function (SMF). According to some embodiments, the transmission is between the selected NEF and a source NEF serving the UE prior to the selection. It will be readily appreciated that one or more of the above may be included in one embodiment.

According to some embodiments, the selecting is performed by a common API framework (CAPIF) core function. According to some embodiments, the transmission is between the selected NEF and the UDR. It will be readily appreciated that one or more of the above may be included in an embodiment.

According to one aspect of the present invention, a method for network open function (NEF) relocation in a communication network is provided. The method comprises the following steps: the NEF receives the UE context of the UE, and the NEF subscribes to services of the control plane network function based on the received UE context of the UE.

According to one aspect of the invention, there is provided a network function comprising a network interface for receiving data from and sending data to a network function connected to a network and to a processor. The network function further comprises a non-transitory memory for storing instructions that, when executed by the processor, cause the network function to be configured to: a UE context of the UE is received, and a service of a control plane network function is subscribed based on the received UE context of the UE.

In some embodiments, the services subscribed to the control plane network function include one or more of: an event opening service of a NEF subscription Session Management Function (SMF), an event opening service of a NEF subscription Access Management Function (AMF), an event opening service of a NEF subscription Unified Data Management (UDM) function, and an event opening service of a NEF subscription Policy Control Function (PCF). According to some embodiments, the UE context of the UE is received from a source NEF or a Unified Data Repository (UDR) serving the UE. In some embodiments, the NEF is selected by an Application Function (AF) or a Session Management Function (SMF) or a generic API framework (CAPIF) core function to serve the UE as the source NEF upon selection. It will be appreciated that suitable network functions may be configured to perform the further method steps described above. It will be readily appreciated that one or more of the above may be included in an embodiment.

According to an aspect of the present invention, a method for managing a User Equipment (UE) in a communication network is provided. The method comprises the following steps: the network function receives a request from a UE, the UE belonging to a UE group, and the network function generates a UE group context.

According to one aspect of the invention, there is provided a network function comprising a network interface for receiving data from and sending data to a network function connected to a network and to a processor. The network function further comprises a non-transitory memory for storing instructions that, when executed by the processor, cause the network function to be configured to: a request is received from a UE, the UE belonging to a UE group, and a UE group context is generated.

According to some embodiments, the UE group context comprises a UE group identity. According to an embodiment, a UE group context includes one or more Protocol Data Unit (PDU) session contexts and their PDU session identifications. According to an embodiment, a UE group context includes one or more shared Protocol Data Unit (PDU) session contexts and their identifications. According to an embodiment, the UE group context includes a list of UE IDs that are members of the UE group. It will be readily appreciated that one or more of the above may be included in one embodiment.

According to an aspect of the present invention, a method for managing a User Equipment (UE) in a communication network is provided. The method comprises the following steps: the network function receives a request comprising data indicative of a group of UEs, and the network function sends a notification, the notification being based on the request and the data.

According to one aspect of the invention, there is provided a network function comprising a network interface for receiving data from and sending data to a network function connected to a network and to a processor. The network function further comprises a non-transitory memory for storing instructions that, when executed by the processor, cause the network function to be configured to: a request including data indicating a group of UEs is received, and a notification is sent, the notification based on the request and the data.

According to some embodiments, the data comprises a Protocol Data Unit (PDU) session identification. According to some embodiments, the data comprises a shared Protocol Data Unit (PDU) session identification. According to some embodiments, the request comprises a request to modify a shared PDU session, and wherein the notification comprises a rejection. In accordance with some embodiments, the request comprises a network open function (NEF) relocation request, and wherein the notification comprises data indicating a UE group context, and wherein the UE group context comprises one or more of a UE group identity, a Protocol Data Unit (PDU) session identity, and a shared PDU session identity. It will be readily appreciated that one or more of the above may be included in an embodiment.

According to one aspect of the present invention, a method for selecting or reselecting a network open function (NEF) in a communication network is provided. The method comprises the following steps: a target application function (T-AF) receives UE context, and the T-AF subscribes to an event open service of a source NEF, and sends an influence traffic routing request to the source NEF. The method further comprises the following steps: after determining the target NEF, the T-AF subscribes to the event open service of the target NEF, and sends an influence traffic routing request to the target NEF.

According to one aspect of the invention, there is provided a network function comprising a network interface for receiving data from and sending data to a network function connected to a network, a processor and a non-transitory memory for storing instructions. The instructions, when executed by a processor, cause a network function to be configured to: receiving the UE context, subscribing to the event open service of the source NEF and sending an impact traffic routing request to the source NEF. The instructions, when executed by a processor, cause a network function to be configured to: and after determining the target NEF, subscribing to the event open service of the target NEF, and sending an influence traffic routing request to the target NEF.

According to some embodiments, the method further comprises: the T-AF cancels the event open service of the feed NEF and the T-AF cancels the impact traffic routing request with the feed NEF. It will be appreciated that suitable network functions may be configured to perform the further method steps described above. It will be readily appreciated that one or more of the above may be included in one embodiment.

According to one aspect of the present invention, a method for selecting or reselecting a network open function (NEF) in a communication network is provided. The method comprises the following steps: the target NEF receives the UE context transfer request, the target NEF subscribes to the services of the control plane network function, and the target NEF sends a UE context transfer response.

According to one aspect of the invention, there is provided a network function comprising a network interface for receiving data from and sending data to a network function connected to a network, a processor and a non-transitory memory for storing instructions. The instructions, when executed by a processor, cause a network function to be configured to: the UE context transfer request is received, the service of the control plane network function is subscribed to, and a UE context transfer response is sent.

According to some embodiments, subscribing to the control plane network function comprises: subscribing the target NEF to one or more of an event openness service of a Session Management Function (SMF), subscribing the target NEF to an event openness service of an Access Management Function (AMF), subscribing the target NEF to an event openness service of a Unified Data Management (UDM) function, and subscribing the target NEF to an event openness service of a Policy Control Function (PCF). It will be appreciated that suitable network functions may be configured to perform the further method steps described above. It will be readily appreciated that one or more of the above may be included in an embodiment.

The embodiments are described above in connection with aspects of the invention in which they may be implemented. Those skilled in the art will appreciate that embodiments may be practiced in conjunction with the aspects described above, but that aspects may also be practiced in conjunction with other embodiments of this aspect. When the embodiments are mutually exclusive or incompatible with each other, it will be apparent to those skilled in the art. Some embodiments may be described with respect to one aspect, but may be applicable to other aspects as well, as will be apparent to those skilled in the art.

Some aspects and embodiments of the present invention may reduce network resource usage with respect to UE context and PDU session context management.

Drawings

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:

fig. 1 illustrates a method for UE context and PDU session context management according to an embodiment of the present invention.

Fig. 2 is a method for UE context and PDU session context management according to an embodiment of the present invention.

Fig. 3 is a diagram illustrating an embodiment of interactions between a management plane, a control plane, and a user plane of a network.

Fig. 4 illustrates a method for establishing a UE group context according to an embodiment of the present invention.

Fig. 5 illustrates a method of UE group context creation triggered by a network management function according to an embodiment of the present invention.

Fig. 6 illustrates a procedure in which a UE registers (R) AN according to AN embodiment of the present invention.

Fig. 7 illustrates UE requested PDU session setup for non-roaming and local breakout roaming according to an embodiment of the present invention.

Fig. 8 illustrates a UE or network requested PDU session modification for non-roaming and local breakout roaming according to an embodiment of the present invention.

Fig. 9 illustrates a PDU session tunnel model according to the related art.

Fig. 10 illustrates a shared tunnel for the frequency hopping concept according to an embodiment of the present invention.

Fig. 11 illustrates a hybrid PDU session tunnel according to an embodiment of the present invention.

Fig. 12 shows a NEF reselection method according to an embodiment of the present invention.

Fig. 13 illustrates a model for selecting or reselecting an Application Function (AF) and a NEF according to an embodiment of the present invention.

Fig. 14 shows a method of AF selection or reselection of a NEF according to an embodiment of the present invention.

Fig. 15 illustrates a method of CP selecting or reselecting a NEF according to an embodiment of the present invention.

Fig. 16 shows a NEF relocation method according to an embodiment of the present invention.

FIG. 17 is a block diagram of an electronic device within a computing and communication environment that may be used to implement devices and methods according to representative embodiments of the present invention.

Fig. 18 illustrates a method of NEF selection or reselection according to an embodiment of the present invention.

Detailed Description

The present disclosure relates to systems and methods for UE context and PDU session management. It has been observed that as applications including IoT devices increase, the demand for communication network resources will be great in order to provide the required level of service for such increases in demand (e.g., storage and signaling required by the network) to manage the UE context and PDU session context data for these UEs or electronic devices. Furthermore, it has been observed that a particular group of UEs or electronic devices may have the same capabilities and subscribed services. Accordingly, systems and methods for grouping of UEs are provided such that UEs may share a UE group context or a PDU session context or both. In this way, network resource usage with respect to UE context and PDU session context management may be mitigated. It is readily understood that while it is contemplated that the term "group" may be used to define a plurality of UEs sharing the same context, other terms may be used at least as well, such as a set of UEs or a set of UEs.

According to an embodiment, the UE requests to establish a new PDU session. A Control Plane (CP) function, such as a Session Management Function (SMF), may evaluate the request and determine whether the requested new PDU session is to be mapped to a new PDU session or to an existing shared PDU session. The mapping may be performed where the SMF may map a PDU session ID generated by the UE when the UE requests a PDU session to a new PDU session or to an existing PDU session to be shared between several UEs.

According to an embodiment, by sharing a PDU session for a group of UEs, if a Control Plane (CP) Network Function (NF) needs to send one or more control messages or modifications to multiple PDU sessions that are exactly all mapped to the shared PDU session, only a single control message needs to be sent to modify the shared PDU session, rather than sending a control message to each PDU session associated with the shared PDU session or with a UE in the group of UEs. For example, a control plane function, such as a Policy Control Function (PCF), a Session Management Function (SMF), an Access Management Function (AMF), or a network open function (NEF), need only send one control message instead of multiple control messages to modify a shared PDU session context, each control message for modifying a PDU session context of a single UE context. In this way, according to embodiments, network resource usage for managing UE and PDU sessions may be reduced, e.g. reducing required storage, computation and signaling. Such a reduction in network usage can also be considered as a reduction in the internal operation of the UP and CP functions when modifying the parameters of a large number of UE and PDU sessions.

According to an embodiment, a method for UE context and PDU session context management is provided. Referring to fig. 1, the network function receives 101 a request from a UE that is a member of a UE group, and then generates 102 a UE group context indicating the UE group. For example, the UE context may include data indicating a UE group Identity (ID), one or more PDU session identities (which may include a PDU session identity and a shared PDU session identity), and a list of UE IDs that are members of the UE group. In some embodiments, the UE group context may include data indicating quality of service (QoS) or charging policy or both to be applied to a PDU session or shared PDU session for the UEs in the UE group. According to AN embodiment, the Network Function may be AN Access Management Function (AMF), a Session Management Function (SMF), a Network open Function (NEF), a Policy Control Function (PCF), a User Plane Function (UPF), a (Radio) Access Network (R) AN node, a Unified Data Repository (UDR), a Unified Data Management (UDM), a Network Slice Selection Function (NSSF), a NF repository Function (NF retrieval Function, NRF), or other Network functions.

According to an embodiment, a method for UE context and PDU session context management is provided. Referring to fig. 2, a Network Function (NF) receives 201 a request comprising data indicating a group of UEs, and then sends 202 a notification, wherein the notification is based on the request and the data. For example, the data may include information indicating a group of UEs, and the request indicates a modification of services for UEs included in the group of UEs. The information indicating the UE group may be considered part of a UE group context, and the UE group context may include data indicating one or more UE group Identifications (IDs), one or more PDU session identifications, one or more shared PDU session identifications, and a list of UE IDs that are members of the UE group. In some embodiments, the UE group context may include data indicating a quality of service (QoS) or a charging policy, or both, to be applied to a PDU session or a shared PDU session of a member UE in the UE group. Depending on the embodiment, the network function may be AN AMF, SMF, NEF, PCF, UPF, (R) AN, UDR, UDM, NSSF, NRF, or other network function.

To provide context for the present application that relates to interaction between a UE and a communication network, fig. 3 is provided to illustrate a network architecture 300 in which the resources of an operator network 302 are divided into a set of logical planes, a User Plane (UP) 304, a Control Plane (CP) 306, and a Management Plane (MP) 308. The UP 304 is typically focused on packet transmission, but certain functions including packet filtering and traffic shaping may be performed in the UP 304, although this is typically performed based on instructions from network functions in the CP 306. Functions in MP308 receive input from network functions within customer domain 310 regarding policies that should be enforced by network control functions in control plane 306. If carrier network 302 supports network slicing, functions within MP308 may be responsible for slice design and creation. It should be understood that a single MP308 may be used to provide management functions for multiple network slices, each with different control and user planes. The functions within MP308 may communicate with each other to ensure that potentially different policies of multiple customers are combined together in the appropriate instruction set.

The UP 304 may also be referred to as a data plane. It carries traffic between the ED399 and external data networks (not shown) or functions within the operator's network. The UP 302 is generally comprised of a User Plane Function (UPF) 314. As is readily understood in certain situations, the ED may be a User Equipment (UE). In some instances, the UPF 314 may be specific to a particular UE, it may be specific to a particular service (in some embodiments, it may be both user and service specific), and in other instances, it may be a general function that serves multiple users and services. The UPFs 314 are connected to each other to allow data plane traffic to be sent. As will be readily appreciated, there are one or more (R) AN nodes located between the UE and the UPF, which may provide, at least in part, AN interconnection therebetween.

The control plane 306 may be comprised of a Control Plane Function (CPF) 316. In a 3GPP compliant network, some control plane functions 316A have functions defined by the standard, while other control plane functions 316B may be outside the specifications of the relevant standard. This may effectively result in the control plane 306 being divided into a standard-compliant control plane segment 306A and a non-standard-compliant control plane segment 306B. In the 3GPP compliant control plane segment 306A, there may be network functions 316A such as AMF, SMF, NEF, authorization and security functions (AUSF), etc., and in some embodiments, there may be more than one instance of any or all of the functions. In the non-standard-compliant control plane segment 306B, a network function 316B, such as performing the function of a software-defined network (SDN) controller or other such controller, including a service-oriented virtual network auto-creation operation (SONAC-Op) controller, may be instantiated. The control plane function 316 may be connected to other CPFs, as shown by function 316A, but this is not required, as shown by CPF 316B. The ED399 may also communicate with the CPF.

The management plane 308 may be divided into a standard-compliant portion 308A and a non-standard-compliant portion 308B, just as the CP 306 is divided. Within MP308, network functions and nodes 318 may communicate with each other and with network functions or nodes 312 within customer domain 310. The management plane entities 318A (within the standardized portion 308A) and 318B (within the non-standard compliant portion 308B) may be mechanisms for establishing policies and enforcing policies based on available resources and requirements received from the customer 312 (and possibly a plurality of different customers). Network Management Function (NMF) 318 may be responsible for accounting and billing functions, and for element management, they may provide services required by an Operation Support System (OSS) and a Business Support Subsystem (BSS). In addition to standardized functions, non-standardized network functions 318B may include network function virtualization management and organization (NFV-MANO) systems and service-oriented virtual network auto-creation-composition (SONAC-Com) controllers.

The NMFs 318 may receive external inputs from the customer nodes 312 and may communicate with each other. The NMF 318 may also communicate with the CPF 316 over any MP-CP connection 320 to provide instructions regarding policies enforced by the CPF 316. Changes in resources below the network 302 are also communicated by the NMF 318 to the CPF 316. In CP 306, the CPFs communicate with each other and with ED 399. The CPF 316 also communicates with the UPF 314 and one or more (R) AN nodes, and through this communication, they can receive information such as traffic load on the link and processing load at the network function. In conjunction with policy information received from the NMF 318, the CPF 316 may send commands to the UPF 314 over a CP-UP (also referred to as UP-CP) connection 322 to manage the behavior of the UPF 314. The UPF 314 receives configuration information from the CPF 318 and processes UP traffic according to the received configuration information. Load information, which may include both processing and network connection (or link) loading, may be collected by the UPF 314 and provided to the CPF 316.

In some embodiments, the customer network function 312 may have a connection to the CPF 316. The CPF with which the client network function 312 communicates may be a 3 GPP-compliant CPF 316A or a non-3 GPP-compliant CPF 316B. In an alternative embodiment, the client network function 312 may utilize functions within the management plane 308 to relay messages to functions in the control plane 306. Within the customer domain 310, there may be an optional control plane 324 with customer control plane functions 326 and 328. When such a customer control plane 324 is present, the functions 326 and 328 may have logical communication links with either or both of the ED399 and the customer network function 312. Customer control plane functions 326 and 328 may have connections to functions within control plane 306. (3 GPP compliant function 316A or non-3GPP compliant function 316B).

According to an embodiment, the UE group context is created in a control plane function, which may include AMF, SMF, PCF, UDM, UDR, NEF, NSSF, NRF, and Application Function (AF). The UE group context is also created in the user plane functions, which may include (radio) access network ((R) AN) nodes, access Nodes (ANs), and UPFs. It is readily understood that while the term UE group context is used to define a plurality of UEs sharing the same context, other terms may be used at least equally to define the same features, such as UE sharing context, UE set context, etc.

According to embodiments, the UE group context may be created in advance, e.g. by pre-configuring the UDM or UDR, or the required information about the UE group context is utilized by the Network Management Function (NMF). For example, the UE group context may include information related to one or more of: UE group Identification (ID), member UE ID list, PDU session group ID, quality of service (QoS), charging policy, or other characteristics of the UE group context associated with each member UE. According to an embodiment, upon receiving a request (e.g. from AF, UE or NMF), a UE group context may be created by the control plane function and the user plane function.

According to an embodiment, a plurality of different UEs are defined as members of a particular UE group, and the UE group may have an associated UE group ID. According to an embodiment, the UE group context may be created by the AMF. In this case, the AMF may create a UE group context in the AMF when a first UE in the specific UE group registers with the communication network. According to some embodiments, when a first UE in a particular UE group requests a PDU session, there is an associated PDU session context. In the case that the PDU session context can be shared, the SMF creates a UE group context in the SMF, e.g., as a shared PDU session context. The SMF also requests the (R) AN and the UPF to establish a UE group context and/or a shared PDU session context. According to some embodiments, when the AF sends a first request for a UE group to the NEF, a UE group context is created in the NEF. In some embodiments, a UE group context is created in the NEF when a first control plane function (e.g., AMF, SMF, or PCF) subscribes to the NEF for a notification service of related events or actions related to a particular UE group. This may provide a reduction of the required signaling when UE group context is created and stored in the NEF.

According to some embodiments, the NEF is pre-configured to serve a specific UE group, and the AF may send a request to the NEF to initiate the NEF sending a request to establish a UE group context. For example, referring to fig. 4, the AF 425 sends 401 an AF request, wherein the request carries information of member UEs of a specific group of UEs. The request may include a transaction ID representing the request and information including one or more of: an external group identity for identifying a group of UEs, an external UE ID list or a GPSI (general Public user identity: generic Public description Identifier), a packet filter set or Packet Flow Description (PFD) (e.g. application server IP address or IP prefix) for identifying downlink traffic for one or some or all UEs in a group of UEs, a port number, qoS information (e.g. maximum bit rate per UE, maximum aggregated bit rate for all UEs, packet delay budget, packet error rate), DNAI (data network access identity).

NEF 424 then establishes a UE group context for the particular UE group. The authentication and authorization process 402 is initiated between AF 425, NEF 424, AUSF 423, and UDM 422 or UDR or both. During process 402, the UDM or UDR may assign an internal group ID that is mapped to an external group ID. The UDM or UDR notifies NEF 424 of the internal group ID. After completing the authentication and authorization procedure 402, NEF 424 sends 403 an AF request response, which may indicate that the control plane is establishing the UE group context.

NEF 424 then selects 404UDM/UDR 422 to establish the UE group context. NEF 424 sends 405 an application data update request to UDM/UDR 422 indicating the UE group context. NEF 424 may provide some or all of the information received from AF 425, such as packet filter set or PFD, and QoS requirement information to the UDR.

The UDM and/or UDR may send a response message 406 to the NEF. If the parameter is not sent in process 402, the response message may include the internal group ID.

UDM/UDR 422 sends message 407 to PCF 421 indicating an application data change notification of the UE group context. The message 407 may include an internal group ID, an application ID, a PFD or a packet filter set for Uplink (UL) and Downlink (DL) directions, authorized QoS parameters of the member UEs (such as Maximum Bit Rate (MBR), maximum Flow Bit Rate (MFBR), guaranteed Flow Bit Rate (GFBR), session-Aggregated Maximum Bit Rate (AMBR), packet delay budget (packet ay, PDB)), and a charging policy for a group of UEs (e.g., a group-of-UEs-AMBR) (e.g., UE-group-based charging, where charging is applied to all UEs in the group of UEs as a whole, rather than a single UE).

If message 407 carries only a data change notification and an internal group ID, PCF 421 may send a request to the UDM and/or UDR to provide data for the internal group ID. The PCF 421 may generate new UE-related policies and UE group-related policies in step 408 by using information provided by the UDM/UDR 422. PCF 421 then forwards 409 a policy update notification to SMF 420 that currently serves the UEs of the UE group, where the policy update notification indicates the UE group context. PCF 421 may also send other messages (not shown in fig. 4) to other network entities, such as AMFs (which currently serve UEs in the UE group) to update access and mobility policies, and to UEs (not shown in fig. 4) for UE routing policies (URSPs). The CP function may create a UE group context after receiving the UE group information from the PCF. PCF 421 may also send a notification message to the NSSF that includes the internal group ID and the member UEs of the internal group. When the CP function is later selected, the NSSF may use the UE group information to ensure that all UEs in the UE group that are currently associated with AN (R) AN node in the same service area of the AMF or the same service area of the SMF are served using the same SMF or AMF.

The messages exchanged between NFs in figure 4 and other figures present in this application may instead be implemented by using existing or new service-based interface services of NFs, according to some embodiments.

Fig. 5 illustrates a method of UE group context creation triggered by a network management function according to an embodiment of the present invention. The Network Management Function (NMF) 508 sends 511 a message to the UDM (or UDR) 506 as an internal UE group creation/modification/deletion request. The message may include a list of UE IDs (e.g., permanent Equipment Identity (PEI), user permanent identity (SUPI), IMSI, GPSI) or network slice information (e.g., S-NSSAI, NSSAI), device owner identity, application identity, and other information that filters the UE. The message may include a default CP network function for serving the group of UEs. UDM (or UDR) 506 acknowledges receipt of the message by sending a response 512 to NMF 508. The UDM (or UDR) 506 creates 513 a UE group context in the UDM (or UDR) 506, represented by a unique UE group ID (e.g. an internal group ID). The UE group context may be stored in the UDM or UDR, or in both the UDM and UDR. The UE context may include the UE IDs of the UEs in the group, as well as other relevant information from the service subscription information. The UDM (or UDR) 506 sends 514 a message to the PCF 504 as a UE group policy creation/modification/deletion request. The message may include a UE group ID, UE IDs of the UE group, service subscription information. PCF 504 creates a UE group context. The UE group context may include a UE group ID, a UE ID, and UE group policies such as QoS policies, charging policies, network slice selection policies, UE traffic routing policies (e.g., UE routing policies (URSPs)). PCF 504 sends 515 a message to UDM 506 as a UE group policy creation/modification/deletion request to acknowledge receipt of the message. The UDM 506 may request 516 other CP functions to create/modify/delete UE group contexts.

Optionally, in some embodiments, for UE group context creation, the UDM 506 may use network function information provided by the NMF508 to identify the CPF 502. Alternatively, the UDM may discover the CP function by retrieving information from a Network Repository Function (NRF). The CPF may register itself to the UDM if a UE group context has been created in the CPF 502. The UDM may provide UE group updates to the CPF 502 via modification/deletion messages.

According to an embodiment, once the CPF is selected to serve a particular UE group, the UDM may inform the NRF which CP functions to select to serve the UE group. The message from UDM to NRF may include a UE group ID, an application ID and a UE ID. Information about the UE group, as well as other information available in the UE ID, application ID, and NRF (e.g., network slice information), may be used for CP NF selection, such as AMF, SMF, and PCF, so that the same set of CP NFs may be selected to serve all UEs in the UE group in a certain geographic area or in the same registration area managed by a particular AMF. In some embodiments, the UE group information (e.g., including UE group ID, UE ID of the UE group, application ID) may be preconfigured in the NRF by NMF 508.

With further reference to fig. 5, the cpf 502 sends 517 a message to the UDM 506 as a UE group create/modify/delete response to the received message. CPF 502 may send 518 a message to PCF 504 as a UE group policy creation/modification/deletion request. According to an embodiment, for a new UE group, the CPF requests the PCF to send a UE group policy. The policy may include a policy that applies to all UEs in the group of UEs, and/or a policy that applies to a single UE. The CPF also registers itself with the PCF to obtain policy updates. According to an embodiment, for an existing group of UEs, if the PCF does not send policy updates to the CPF, the CPF may request the PCF to send an updated policy. According to an embodiment, if a group of UEs is deleted, the CPF may request the PCF to remove their subscription from the PCF's policy update service. The PCF 504 sends 519 a message to the CPF 502 as a UE group policy creation/modification/deletion request to acknowledge receipt of the message.

According to some embodiments, the UE group context includes information indicating a UE group ID, a list of UE IDs for each UE that is a member of the UE group, and a list of PDU session group IDs. In this embodiment, the UE may have a specific PDU session ID associated with it, where the PDU session ID is mapped to a PDU session group ID. The PDU session group ID identifies a PDU session shared among several UEs assigned to the UE group ID. Since all UEs within a group do not necessarily share the same PDU session with a particular PDU session group ID, there may be multiple PDU session group IDs associated with a particular UE group context. According to an embodiment, the PDU session context, which may be associated with a particular UE, may include information indicating PDU session information and a mapping between PDU session IDs and associated UE group IDs and PDU session group IDs.

According to some embodiments, the UE group context includes information indicating a list of UE IDs for each UE that is a member of the UE group, and UE group related information, which may include one or more of quality of service, charging policies, and other UE group related information. The UE group context may also include information indicating a shared PDU session context, which may be identified by a shared PDU session ID generated by the SMF. In these embodiments, each UE has a UE context that includes a PDU session context and a shared PDU session context. In addition, the shared PDU session context includes a mapping of PDU session IDs generated by the UEs to UE group IDs and shared PDU session IDs. According to these embodiments, the configuration of UE group context and shared PDU session context may be applied to UEs with enhanced mobile broadband (eMBB) applications and large-scale IoT (MIoT) applications, such as smart phones or other wireless devices. In some cases, these applications may occur simultaneously.

According to some embodiments, the UE group context comprises information indicating individual UE contexts that have been allocated to UEs of the UE group, and UE group related information, which may comprise one or more of quality of service, charging policy and other UE group related information. The UE group context may also include information indicating a shared PDU session context, which may be identified by a shared PDU session ID generated by the SMF. According to these embodiments, the configuration of the UE group context may be applied to UEs related to one or more applications, such as a large-scale IoT (MIoT) application.

According to an embodiment, the UE context may include a PDU session pointer to a memory of the non-shared PDU session and the shared PDU session. The PDU session pointers for multiple UE contexts may point to the same memory that shares the PDU session. (R) AN, UPF, AMF, SMF, and other functions have a mapping of UE generated PDU session IDs and SMF generated PDU session IDs. The (R) AN, UPF, AMF, and other functions may use the SMF address (e.g., IP address or FQDN) and the shared PDU session ID to locate data for the shared PDU session. The SMF uses the shared PDU session ID to locate the context data of the shared PDU session.

According to AN embodiment, one or more of the following parameters may be stored in the PDU session context of the UE context at the SMF, AMF, UPF and (R) AN. The type of PDU session may be stored in a PDU session context, such as a non-shared PDU session or a shared PDU session. The PDU session ID may also be present in the PDU session context, e.g., for non-shared PDU sessions, the PDU session ID may be UE generated. For a shared PDU session, the PDU session ID may be UE generated and SMF generated. The PDU session pointer may be stored in the PDU session context. For unshared PDU sessions, the PDU session pointer can point to a separate memory of the PDU data structure. For a shared PDU session, the PDU session pointer may point to a common memory of the PDU data structure. For example, the UE group ID and the shared PDU session ID may uniquely identify a mapping between the UE generated session ID and the SMF generated shared PDU session ID. An example of a pointer may be a UE generated PDU session ID, which maps to < UE group ID, SMF generated PDU session ID >. The UP connection type may be stored in a PDU session context, where the UP connection may be shared or unshared. According to some embodiments, the PDU session context may comprise additional information elements, such as SMF ID (or SMF address) or AMF ID (or AMF address), depending on the network functionality.

In addition to a single UE context, AMF, SMF, (R) AN and UPF, as well as other network functions, may have a UE group context. The UE group context may include information elements including one or more of a UE group ID, a UE member, a shared PDU session ID, a serving SMF ID (or address), a serving AMF ID (or address), an S-NSSAI, and an UP connection type. The UE group ID may be unique within the PLMN or within a network slice. The UE member may be a UE ID list of the UE group. The shared PDU session ID may be an ID generated by the serving SMF and it may be unique within one UE group. The serving SMF may have an SMF ID (or address) and the serving AMF may have an AMF ID (or address). The S-NSSAI may represent network slice information and the UP connection type may be shared or unshared.

According to embodiments, in (R) AN, UPF, AMF, SMF and other network functions, UE information may be stored in separate UE context or in UE group context or in separate UE context and UE group context. If the UE has an unshared PDU session, the UE information may be stored in a separate UE context. If the UE belongs to a UE group, the UE information may be stored in a UE group context. The UE group context may include a single UE context profile for all UEs in the group. Alternatively, the UE context profile may have a pointer to the UE group context profile.

According to some embodiments, it is more efficient to have a single UE group context in the UP and CP functionality when all UEs in the UE group have only shared PDU sessions. The UE group context contains all the individual UE information. The UE group ID may be used to send a message to all UEs in the UE group when the 5G CP or UP function wants to make a change to all UEs in the UE group. The UE group context includes UE contexts of all member UEs. The UE group context may include: a UE group ID, which may be unique within one PLMN or unique within a network slice instance; a UE member, which may be a member UE ID list; a UE context for each UE member, which may include a security context in addition to the shared PDU session context; a shared PDU session context, which may define a PDU session shared among UEs in a UE group; policies applied to shared PDU sessions, such as policies for individual UEs and groups of UEs.

According to an embodiment, when a control plane function or a user plane function is to send a message or signal for a UE group, the message or signal may include information indicating a UE group ID and a shared PDU session ID. In this way, by sending a single message, the operation of multiple UEs and their associated PDU sessions can be modified, thereby reducing the signaling required to make these changes to the network operation.

However, in some embodiments, if a particular UE requests modification of its associated PDU session, and the PDU session is a shared PDU session, i.e. multiple UEs are using the same PDU session, the control network may reject the requested modification. For example, if a UE requests a change in certain control parameters of a PDU session, such as Allocation and Retention Priority (ARP), maximum bit rate packet delay, or other control parameters that may cause a change in the PDU session that may affect other UEs, the control network will reject the requested modification.

According to an embodiment, the shared PDU session ID is generated by a control plane function (e.g., SMF) that may be associated with multiple specific PDU sessions being used by multiple UEs and without change with respect to the UE. For example, the UE may request establishment of a new PDU session with a UE generated PDU session ID. The control plane function (e.g., SM) may associate or map the UE-generated PDU session ID with the SMF-generated PDU session ID (e.g., shared PDU session ID). It should be appreciated that the shared PDU session ID may be unique within a particular SMF, unique within multiple SMFs associated with a communication network, or unique within a network slice instance, or unique to a PLMN network. Further, it should be understood that while the embodiments have been discussed with respect to SMF, SMF may be replaced by another control plane function, such as AMF, PCF, UDM, NEF, etc.

Fig. 6 illustrates a procedure in which a UE registers (R) AN according to AN embodiment of the present invention. According to an embodiment, the procedure shown in fig. 6 provides a method of creating a UE group context in the AMF when a first UE in the UE group is registered with the CN. When the UE performs initial attachment, the UE may send the device class to the (R) AN, and the (R) AN may inform the AMF of the UE device class. It should be understood that the device class may also be referred to as a UE device class. The UDM provides UE group IDs and UE ID membership. The PCF provides UE group policies. The AMF may request (R) the AN to create a UE group context that stores access and mobility policies for the UE group.

Referring to fig. 6, the method includes the UE sending a message 621 to the (R) AN 604 as a registration request. The message may include (AN parameter, registration management-non-access stratum (RM-NAS) registration request (registration type, SUPI or 5G globally unique temporary identity, 5G-GUTI), security parameter, NSSAI, UE 5GCN capability, PDU session status, PDU session to be reactivated, UE device class, trace request (follow request), and mobile originated only connection (MICO) mode preference)). In the case of a 5G-RAN, the AN parameters may include, for example, SUPI or 5G-GUTI, selected network and NSSAI, UE device class. In the case of NG-RAN, the AN parameters may also include AN establishment cause. The establishment cause provides a reason for requesting establishment of an RRC connection. The registration type indicates whether the UE wants to perform "initial registration" (i.e., the UE is in RM-deregistered state), "mobility registration update" (i.e., the UE is in registration state and initiates a registration procedure due to mobility), or "periodic registration update" (i.e., the UE is in registration state and initiates a registration procedure due to the expiration of a periodic update timer). The UE may perform an initial registration (i.e., the UE is in RM-deregistered state) for a PLMN for which the UE does not already have a 5G-GUTI, and the UE includes its SUPI in the registration attempt. In other cases, a 5G-GUTI is included, which indicates the last serving AMF. If the UE has been registered in a PLMN via a non-3GPP access, where the PLMN is different from the new PLMN of the 3GPP access (i.e., is not a registered PLMN or an equivalent PLMN of the registered PLMN), the UE may not provide the 5G-GUTI allocated by the AMF through the 3GPP access during the registration procedure of the non-3GPP access. Furthermore, if the UE is already registered via a 3GPP access in a PLMN (i.e., registered PLMN) that is different from the new PLMN of the non-3GPP access (i.e., not the registered PLMN or an equivalent PLMN of the registered PLMN), the UE will not provide the 5G-GUTI allocated by the AMF through the non-3GPP access during the registration procedure of the 3GPP access. The security parameters are used for authentication and integrity protection. NSSAI denotes network slice selection assistance information. The PDU session status indicates a previously established PDU session in the UE. Including the PDU session to be reactivated, which indicates the PDU session that the UE intends to activate. The trace request is included when the UE has pending uplink signaling and the UE does not include a PDU session to be reactivated. The UE device class may be optional and it indicates the capability of the UE-assisted (R) AN to select the preconfigured AMF. The UE device class is also used to assist the AMF in selecting a pre-configured SMF function or NSSF function.

If either SUPI or 5G-GUTI is included not indicating a valid AMF, then the (R) AN selects AMF 622 based on the (Radio) access network technology (R) AT and NSSAI and/or UE device class, if available. The process of (R) AN selecting AMF may be performed as known. If the (R) AN is unable to select AN appropriate AMF, it forwards the registration request to the AMF that has been configured in the (R) AN to perform AMF selection. In some embodiments, the NMF may pre-configure (R) the UE group information in the AN 604 with the following information: UE group ID, UE ID of the UE group, network slice information (e.g., S-NSSAI), and default or pre-configured AMF dedicated to serving the UE group. If (R) AN 604 receives information from the UE in message 621 matching the UE group information, then (R) AN 604 may select a preconfigured AMF to serve UE 602.

(R) the AN 604 sends 623 a message as a registration request to the new AMF 606. The message may include (N2 parameter, RM-NAS registration request (registration type, user permanent identity or 5G-GUTI, security parameters, NSSAI and MICO mode preferences, UE device class)). When using 5G-RAN, the N2 parameters include location information, cell identity and RAT type related to the cell where the UE is camped. When using NG-RAN, the N2 parameter also includes an establishment cause. The message in 623 may include UE group information (such as a UE group ID). If the registration type indicated by the UE is a periodic registration update, the steps 624 to 637 mentioned below may be omitted.

In some embodiments, the new AMF 606 sends 624 a message to the old AMF 608 as a UE context transfer request. The message may be a Namf _ Communication _ UE _ Context _ Transfer (complete registration request). If the UE's 5G-GUTI is included in the registration request and the serving AMF has changed since the last registration, the new AMF may invoke a Namf _ Communication _ UE contexttransfer service operation on the old AMF including the full registration request IE, which may be integrity protected, to request the UE's SUPI and MM context. The old AMF uses the integrity protected full registration request IE to verify whether the context transfer service operation invocation corresponds to the requested UE. The old AMF also transmits event subscription information for each client NF of the UE to the new AMF. Subsequently, the old AMF 608 sends 625 a UE context transfer response, which may be a response to a Namf _ Communication _ UEContextTransfer, which may include (SUPI, MM context, SMF information). The old AMF may respond to the new AMF by including SUPI and MM context of the UE to make a Namf _ Communication _ UEContextTransfer call. If the old AMF maintains information on the active PDU session, the old AMF includes SMF information including an SMF identification and a PDU session identification. If the old AMF maintains information about an active N2AP UE Association to a non-3GPP interworking function (N3 GPP interworking function, N3 IWF) binding to a Transport Network Layer Association (N2 AP UE-Transport Network Layer Association, N2AP UE-TNLA), the old AMF includes information about the N2AP UE-TNLA binding.

In some embodiments, the new AMF 606 sends 626 an identification request to the UE 602. If the SUPI is neither provided by the UE nor retrieved from the old AMF, an identity request procedure is initiated by the AMF sending an identity request message to the UE. The UE 602 may send 627 an identity response to the new AMF, where the identity response may include SUPI. In some embodiments, AMF 606 may decide to invoke AUSF 628, where AMF may select AUSF based on SUPI as is known. The AUSF may initiate authentication 629 of the UE. If network slicing is used, the AMF may decide whether the registration request needs to be rerouted. The AMF may also initiate NAS security functions.

In some embodiments, the new AMF 606 sends 630 a message to the old AMF 608, where the message is Namf _ Communication _ registration completed notify (). If the AMF has changed, the new AMF informs the old AMF that the registration of the UE in the new AMF is completed by calling a Namf _ Communication _ registration completed service operation. If the authentication/security procedure fails, registration should be rejected and the new AMF calls the Namf _ Communication _ registration CompleteNotification service operation to the old AMF using the reject indication reason code. The old AMF continues as if the UE context transfer service operation was never received. In some embodiments, the new AMF 606 sends 631 an identity request to the UE 602. If the PEI is neither provided by the UE nor retrieved from the old AMF, an identity request procedure is initiated by the AMF sending an identity request message to the UE to retrieve the PEI.

In some embodiments, the new AMF 606 selects 633UDM 616 based on SUPI or UE device class or both. If AMF 606 knows that the UE belongs to the UE group, AMF 606 may select the same UDM 616 serving other UEs in the same UE group. If the AMF has changed since the last registration, or if the UE provides SUPI that does not reference the active context in the AMF, or if the UE is registered to the same AMF, it is already registered to a non-3GPP access (i.e., the UE is registered through the non-3GPP access and initiates the registration process to add the 3GPP access), the new AMF 606 calls 634a Nudm Nuitu ContextManagementRegistration service operation to UDM 616. If there is no subscription context for the UE in the AMF, a "subscription data retrieval indication" is included. The new AMF provides the UDM with its access type serving the UE and sets the access type to "3GPP access". The UDM stores the associated access type together with the serving AMF. For other UEs in the UE group, the AMF does not need to obtain UE context information if the UE group subscription does not change. If the "subscription data retrieval" indication is included in step 634a, the UDM invokes the 634b numdm _subscribedataugueupdatenotifyservice operation to provide the subscription data from the UDM. After obtaining mobility related subscription data from the UDM, the new AMF creates an MM context for the UE. The subscription data may include UE device class and UE group information. The UE group information includes a UE group ID, a UE ID (e.g., SUPI) of the UE group. The UE group ID indicates that UEs of the same UE group ID have the same network control policy, e.g., access, mobility, qoS policy. If the UE group context does not exist, the AMF creates a UE group context for the UE group. When UDM 616 stores the associated access type with the serving AMF, the UDM will be caused to initiate 634cnudm_uecontextmanagement _removenotifyto the old AMF 608 (if present) corresponding to the 3GPP access, as indicated by step 634 a. The old AMF removes the MM context of the UE. If the service NF removal reason indicated by the UDM is "initial registration", the old AMF invokes a Namf _ EventExposure _ Notify service operation to all associated SMFs of the UE to inform the UE to deregister from the old AMF. Upon acquiring this notification, the SMF will release the PDU session.

In some embodiments, the new AMF 606 selects a PCF in 635 based on SUPI. If AMF 606 knows that the UE belongs to the UE group, AMF 606 may select the same PCF 610 that has been selected (or pre-configured) to serve the UE in the UE group. New AMF 606 sends 636 a message to PCF 610, where the message is Npcf _ PolicyControl _ PolicyCreate (SUPI). If the AMF has not obtained the access and mobility policies of the UE, or if the access and mobility policies in the AMF are no longer valid, the AMF requests the PCF to apply the operator policy for the UE by creating a policy control session with the PCF through an Npcf _ PolicyControl _ PolicyCreate service operation. In the roaming case, interaction between the home PCF (H-PCF) and the roaming PCF (V-PCF) is required to provide access and mobility policies. The PCF sends a response to the new AMF, where the response is Npcf _ PolicyControl _ PolicyCreate (access and mobility policy data). The PCF operates in response to the Npcf _ PolicyControl _ PolicyCreate service and provides access and mobility policy data for the UE to the AMF.

In some embodiments, the new AMF sends a message 637 to the SMF, where the message is Namf _ EventExposure _ Notify (). The AMF calls Namf _ EventExporure _ Notify in one or more cases: 1) If the AMF changes, the new AMF notifies each SMF of the new AMF of the serving UE by notifying the UE of a UE reachability state including a PDU session state associated with each SMF from the UE. In the case where the AMF has changed, it is assumed that the old AMF provides usable SMF information. Checking the PDU session status based on the PDU session status provided by the new AMF, and in a Namf _ EventExposure _ Notify service operation, the SMF either reactivates the PDU session to complete the user plane setup without sending AN MM NAS service acceptance (R) from the AMF to the AN, or releases any network resources related to the PDU session indicated by the UE as not established; 2) If the UE is in the MICO mode and the AMF has notified the SMF that the UE cannot arrive and the SMF does not need to send a DL data notification to the AMF, the AMF notifies the SMF that the UE can arrive; 3) If the AMF has notified the SMF UE that it is reachable only for regulatory priority services and the UE enters the allowed area, the AMF notifies the SMF that the UE is reachable. According to an embodiment, the AMF will also inform any other NFs subscribing to UE reachability that the UE is reachable. According to an embodiment, if the SMF has subscribed to the UE location change notification through the Namf _ EventExposure _ Subscribe service operation, and if the AMF detects that the UE has moved out of the area of interest subscribed by the SMF serving the UE, the AMF invokes the Namf _ EventExposure _ Notify service operation to Notify the SMF of the UE's new location information. According to an embodiment, the SMF may decide to trigger, e.g. a new intermediate UPF insertion or UPF relocation. According to an embodiment, steps 640 and 641 may be omitted if the registration type indicated by the UE is a periodic registration update.

According to an embodiment, the new AMF sends 638 an N2 request to the N3IWF 618. The AMF may decide to modify the N2AP UE-TNLA binding for the N3 IWF. This is done in case the AMF changes and the old AMF has an existing N2AP UE-TNLA binding for the N3IWF for the UE. The N3IWF 618 may send 639N2 response to the new AMF 606.

In some embodiments, old AMF 608 sends 640Npcf _PolicyControl _PolicyDelete () to PCF 610. If the old AMF previously requested to establish a UE context in the PCF, the old AMF terminates the UE context in the PCF by calling an Npcf _ PolicyControl _ PolicyDelete service operation. PCF 610 may send an Npcf _ PolicyControl _ policydelte () response to old AMF 608.

According to an embodiment, the new AMF 606 sends 641 a registration accept message to the UE 602. The message may include (5G-GUTI, registration area, mobility restrictions, PDU session status, NSSAI, periodic registration update timer, LADN information and accepted MICO mode, UE group information (e.g., UE group ID, application ID)). The AMF sends a registration accept message to the UE indicating that the registration has been accepted. If AMF allocates a new 5G-GUTI, then 5G-GUTI is included. The mobility restriction included in the mobility restriction case is applicable to the UE. The AMF indicates the established PDU session to the UE in the PDU session state. The UE locally removes any internal resources related to the PDU session that was not marked as established in the received PDU session state and that the UE has requested PDU session establishment without receiving an SMF response. If the PDU session status information is in the registration request, the AMF will indicate the PDU session status to the UE. NSSAI includes permissible S-NSSAI. If the UE subscription data includes subscribed LADN identification information, the AMF may include, in the registration accept message, LADN information for LADNs available within a registration area determined by the AMF for the UE. If the UE includes the MICO mode in the request, the AMF responds whether the MICO mode should be used. When a trace request is included, the AMF cannot immediately release the signaling connection after the registration procedure is completed.

In some embodiments, the AMF 606 sends 642 a message to the (R) AN 604 to establish the UE context. The message includes the UE device class, 5G GUTI, S-NSSAI, UE group context information (UE group ID, UE ID of UE group, application ID, UE group access and mobility policy), security information. If the UE group context has been created by the shared PDU session provisioning procedure, the (R) AN associates the UE with the group UE context. The UE group context may contain a preconfigured N3 shared tunnel. If the UE group context does not exist, the AMF may send UE group context information, including UE group access and mobility policies, to the (R) AN. The AMF may include a UE list (including the SUPI of the UE) of the same UE group ID. The AMF may also include security information of the (R) AN. The (R) AN 604 sends a 643 response message to the AMF 606. If the UE group context does not exist, (R) the AN may create a DL Tunnel Endpoint Identifier (TEID) and send (R) AN tunnel information to the AMF.

In some embodiments, the UE 602 sends 644 a registration complete message to the AMF 606. The UE sends a registration complete message to the AMF to confirm whether a new 5G-GUTI is allocated. When the "PDU session to be reactivated" is not included in the registration request, the AMF releases the signaling connection with the UE. When the trace request is included in the registration request, the AMF cannot immediately release the signaling connection after the registration procedure is completed.

Fig. 7 illustrates UE requested PDU session setup for non-roaming and local breakout roaming according to an embodiment of the present invention. According to an embodiment, a method of creating a UE group context in SMF and UPF functions is provided. In these embodiments, the shared PDU session is not preconfigured. The UE sends a request to the SMF to establish a PDU session after successful registration. Upon receiving a PDU session setup request from a first UE of the UE group ID, the AMF and the SMF create a shared PDU session context. Fig. 7 illustrates a method for establishing a new PDU session and switching an existing PDU session between a 3GPP access and a non-3GPP access. In case of roaming, the AMF determines whether to establish a PDU session in Local Breakout (LBO) or home route. In the LBO case, the procedure is the same as the non-roaming case, but the SMF, UPF and PCF are located within the visited network.

With further reference to fig. 7, assume that the UE has registered with the AMF, and therefore the AMF has retrieved user subscription data from the UDM. The UE 702 sends 721 a PDU session setup request to the AMF 706. The UE may send a NAS message that includes (S-NSSAI, DNN, PDU session ID, request type, N1 SM information, UE device class, UE group information (UE group ID, application ID)). UE group information (UE group ID, application ID) may be included if the UE knows its UE group ID and application ID. To establish a new PDU session, the UE generates a new PDU session ID. The UE initiates the UE-requested PDU session setup procedure by sending a NAS message containing the PDU session setup request within the N1 SM message. The PDU session setup request may include a PDU type, a Session and Service Continuity (SSC) mode, a protocol configuration option. The request type indicates "initial request" if the PDU session setup is a request to establish a new PDU session, and indicates "existing PDU session" if the request relates to an existing PDU session between a 3GPP access and a non-3GPP access. The request type indicates "emergency request" if the PDU session setup is a request to establish a PDU session for emergency bearer services. The request type indicates "existing emergency PDU session" if the request relates to an existing PDU session for emergency services between the 3GPP access and the non-3GPP access. The NAS message sent by the UE may be encapsulated by the AN in AN N2message for the AMF, which should include user location information and access technology type information. The N1 SM information may contain an SM PDU DN request container that contains information of PDU session grants by the external DN. The AMF receives the NAS SM message (established in step 721) and user location information (e.g., cell ID in case of RAN) from the AN. When the UE is outside the available area of the LADN, the UE should not trigger the PDU session establishment of the PDU session corresponding to the LADN. The UE device class is optional. The UE may provide a UE device class, which may also be referred to as a device class, so that the AMF may select the SMF and appropriate methods to allocate IP addresses/IP prefixes, policies, qoS, UP management procedures. If a device class is sent from the UE, for some device classes, one or more of the following information may be omitted: DNN, S-NSSAI, PDU Session ID. The device class may be omitted if the AMF knows the device classes already provided by the UE or UDM.

According to an embodiment, the AMF 706 determines that the message corresponds to a request for a new PDU session based on the request type indication "initial request" and the PDU session ID of any existing PDU session not used for the UE. If the NAS message does not contain an S-NSSAI, the AMF may determine the default S-NSSAI for the requested PDU session either according to the UE subscription (if it contains only one default S-NSSAI) or based on operator policy. AMF selects 722SMF. The AMF stores an association of PDU session IDs and SMF IDs. The request type indicates "existing PDU session" and the case where AMF does not recognize PDU session ID or subscription context from UDM does not contain SMF ID corresponding to DNN constitutes an error case. If the request type indicates "emergency request" or "existing emergency PDU session", the AMF selects the SMF considering the type of request. Based on one or more of the S-NSSAI, the device class, and the UE group ID, the AMF selects an SMF to serve the UE. The AMF 706 may select the same SMF that has been pre-configured in the AMF or in the NRF or that has been selected for serving other UEs in the group of UEs.

According to an embodiment, AMF 706 sends 723 nsmf _pdusesion _createsmcontextrequest, which may include (SUPI, DNN, S-NSSAI, PDU session ID, AMF ID, request type, device class, UE group ID, existing shared PDU session ID, N1 SMF information (PDU session setup request), user location information, access technology type, PEI, PCF ID, UE group information (e.g., UE)), to SMF 710. The PCF ID is the ID of the PCF that AMF 706 has selected for the serving UE or all UEs in the serving UE group. The AMF ID uniquely identifies the AMF serving the UE. The AMF forwards the PDU session ID together with N1 SM information containing a PDU session setup request received from the UE. The device class may be optional. The SMF may retrieve the device class when accessing the UDM later. Based on one or more of the S-NSSAI, the device class, and the DNN, the AMF may select a UE group ID and include an existing shared PDU session ID for the UE group. The UE group ID indicates that the UE belongs to the UE group. If the SMF has obtained UE subscription data, session management, qoS, and charging policies for the UE group ID, the SMF may not need to access the UDM or PCF to obtain the UE information.

In some embodiments, if an SMF is not already registered and subscription data is not available, then SMF 710 registers 724a-724b with UDM 714, retrieves the subscription data and subscribes to be notified when the subscription data is modified. If the request type indicates "existing PDU session", the SMF determines that the request is due to a handover between the 3GPP access and the non-3GPP access. The SMF identifies an existing PDU session based on the PDU session ID. The subscription data includes an authorized PDU type, an authorized SSC pattern, a default 5G QoS identification (5G QoS identifier, 5qi)/ARP, a subscribed session-AMBR, a UE group ID, a UE group AMBR. The SMF checks if the UE request complies with the user subscription and local policy. If the DNN corresponds to a LADN, the SMF verifies whether the UE is located within the LADN service area based on the UE location report from the AMF. If this is not the case, the SMF rejects the UE request via NAS SM signaling by using an Nsmf _ subscription _ CreateSMResponse response AMF including the relevant SM reject reason. The SMF indicates to the AMF that the PDU session ID is to be considered released, it is de-registered from the UDM, and the rest of the method is skipped. The UE group AMBR is the maximum bit rate of the aggregation of UE group IDs. The set AMBR is enforced by (R) AN and UPF. If the UE belongs to a UE group and the SMF already has subscription data for the UE group ID, the SMF does not need to perform this registration with the UDM. If the UE is the first UE in the UE group, the SMF obtains the UE subscription data, UE group data, from the UDM and stores this information in the UE group shared session context. The SMF may create a shared PDU session ID as part of the UE group shared PDU session context. The SMF stores a mapping between the shared PDU session ID and the UE generated PDU session ID.

According to some embodiments, UDM 714 may notify SMF 710 of PCF 712 that has been selected by AMF 706 to serve the UE.

According to an embodiment, if the SMF needs to perform secondary authorization/authentication 725 during the DN-AAA server establishment of the PDU session, the SMF selects the UPF and triggers PDU session establishment authentication/authorization. If the PDU session setup authentication/authorization fails, the SMF terminates the PDU session setup procedure and indicates a rejection to the UE. The secondary authorization/authentication may be applied to a single UE of the same UE group ID.

According to an embodiment, if dynamic Policy Control and Charging (PCC) is deployed, SMF 710 performs PCF selection 726a. The SMF may choose the same PCF that may be defined in message 723 by the AMF 706 or in step 724 by the UDM 714. If a dynamic PCC is not deployed, then SMF may apply local policies. The SMF may select the PCF using one or both of the UE group ID and the device class. SMF 710 may invoke the 726b npcf _smpolicycontrol _getoperation to establish a PDU-CAN session with PCF 712 and obtain default PCC rules for the PDU session. If the request type indicates "existing PDU session", the SMF may Notify the event previously subscribed to by the PCF by invoking the Nsmf _ EventExposure _ Notify operation, and the PCF may update the policy information in the SMF by invoking the Npcf _ SMPolicyControl _ UpdateNotify operation. The PCF may provide the SMF with an authorized session-AMBR and an authorized 5QI/ARP. If the UE belongs to the UE group and the UE is the first UE requesting PDU session establishment, the SMF establishes a PDU-CAN shared session with the PCF and obtains a default PCC rule of the PDU shared session. The PCC rules include rules for individual UEs and rules for groups of UEs. PCF 712 subscribes to IP allocation/release events (and may subscribe to other events) in SMF 710 by invoking the 726c nsmf _eventexposure _subscribeoperation. The purpose of steps 726a-726c is to receive PCC rules before selecting a UPF. These steps may be skipped if PCC rules are not needed as input for the UPF selection. For unstructured PDU sessions, the PCF may subscribe to an IP allocation/release event for the N6 UPD/IP interface.

According to an embodiment, if the request type indicates "initial request", the SMF selects the SSC pattern for the PDU session. If step 725 is not performed, SMF 710 also selects 727UPF. In case of PDU type IPv4 or IPv6, the SMF allocates an IP address/prefix for the PDU session. For unstructured PDU types, the SMF may assign IPv6 prefixes for PDU sessions and N6 point-to-point tunnels (user datagram protocol (UDP)/IPv 6 based). If the request type indicates "emergency request" or "existing emergency PDU session", the SMF selects a UPF according to the request type. For a first UE requesting a UE group ID for PDU session establishment, the SMF may assign an IP address or IP prefix for the PDU session and the N6 IP/UDP point-to-point tunnel. SMF may also assign flow labels for N6 IP/UDP tunnels. For other UEs requesting the same UE group ID for the PDU, the SMF may assign a new IP address or IP prefix for the PDU session and the N6 IP/UDP point-to-point tunnel. Alternatively, the SMF may use the same IP address/IP prefix for the N6 IP/UDP tunnel, but assign another flow label for the N6 IP/UDP tunnel for each UE's PDU session. The SMF may select the shared UL and DL UP connections based on UE mobility information, qoS and charging policies, and lawful interception requirements received from the AMF. The following combinations of N3 and N9 and N6 tunnels are possible, but not limited to: 1) Sharing UL and DL N3 and N9 tunnels; 2) Sharing UL N3 and N9 tunnels, and not sharing DL N3 and N9 tunnels; 3) With or without sharing the N6 tunnel.

According to some embodiments, SMF 710 may select the same UPF 708 to serve a UE in the UE group. If AN intermediate UPF (I-UPF) (not shown in fig. 7) is required to provide a connection between the (R) AN 704 and a PDU Session Anchor (PSA) UPF, the SMF 710 may select the same I-UPF to serve the UE in the service area of the I-UPF or the UE in the service area of the PSA UPF 708.

According to an embodiment, SMF 710 may invoke a 728a nsmf _eventexposurenotify service operation to report some event to a previously subscribed PCF. If the request type is "initial request" and dynamic PCC is deployed and the PDU type is IPv4 or IPv6, the SMF informs the PCF (which has previously subscribed) of the allocated UE IP address/prefix. The PCF may provide the SMF with an authorized session-AMBR and an authorized 5QI/ARP. For a group of UEs, the SMF may inform the PCF of the IP address or IP prefix of the UE and/or the IP address/IP prefix of the N6 IP/UDP tunnel. The PCF has a mapping of IP prefixes or IP addresses of UEs in the same UE group. PCF 712 may provide updated policies to SMF by invoking the 728b npcf _smpolicycontrol _updatenotifyservice operation. For a UE group, if the PCF already provides PCC rules for the SMF for individual UEs and UE groups, this step may be skipped. The PCF may send a message to the SMF using the UE group ID to modify the PCC rules for all UEs in the same UE group.

According to an embodiment, if the request type indicates "initial request" and step 725 is not performed, the SMF initiates an N4 session establishment procedure with the selected UPF, otherwise it initiates an N4 session modification procedure with the selected UPF. SMF 710 sends 729a N4 session establishment/modification request to the UPF 708 and provides packet detection, enforcement and reporting rules to be installed on the UPF 708 for the PDU session. If the SMF assigns CN tunnel information, the CN tunnel information is provided to the UPF in this step. If the UE belongs to the UE group, CN tunnel information may have been established for the UE group ID. The SMF sends an N4 session modification request to the UPF. The message includes a UE group ID, a shared PDU session ID, a UL TEID, a DL TEID. If the UE belongs to the UE group and no CN tunnel is established, the SMF sends an N4 session establishment to the UPF. The message includes the UE group ID, the UE list in the UE group (e.g., indicated by SUPI), and the PCC rules for individual UEs and UE groups. If the SMF knows the existing shared DL N3 tunnel, the SMF may include a DL TEID. Otherwise, the (R) AN may generate a new DL TEID at a later point. The SMF may include a UL TEID. The UL TEID may belong to an existing shared N3 tunnel or a new non-shared N3 tunnel. The UPF 708 acknowledges by sending 729b N4 session establishment/modification response. If the UPF assigns CN tunnel information, the CN tunnel information is provided to the SMF in this step.

According to some embodiments, SMF 710 may assign the same Tunnel Endpoint ID (TEID) to shared N3 and N9 tunnels in the UL. If (R) AN allocates DL N3 TEID, then SMF may allocate DL N9 TEID with the same TEID as DL N3 TEID. The (R) AN 704 and the UPF 708 may perform packet aggregation to transmit aggregated PDUs in the UL and DL N3 and N9 shared tunnels.

According to some embodiments, if the UE's PDU session has unshared N3 and N9 tunnels, SMF 710 may assign the same TEID for unshared UL N3 and UL N9 tunnels. (R) AN 704 may assign a TEID for the DL N3 tunnel and SMF may use the same DL N3 TEID for DL N9 TEID.

According to an embodiment, SMF 710 sends a 731nsmf _pdusesion _createsmresponse to AMF 706, which may include (cause, N2 SM information (PDU session ID, qoS profile, CN tunnel information, S-NSSAI, session-AMBR, UE group ID, group-QoS profile, PDU shared session ID, DL TEID), N1 SM information (PDU session setup accept (granted QoS rule, SSC mode, S-NSSAI, assigned IPv4 address, session-AMBR))). The information that the N2 SM information carrying AMF should forward to the (R) AN may include a mapping between one or more CN tunnel information corresponding to a core network address of AN N3 tunnel corresponding to the PDU session, qoS profile provided to the (R) AN QoS parameters, and QoS flow identification. The (R) AN may be provided with a plurality of QoS profiles, AN association between AN resources of the UE and the PDU session may be indicated to the UE by AN signaling with the UE using a PDU session ID, the S-NSSAI corresponds to the PDU session, the N1 SM information includes a PDU session setup accept that the AMF should provide to the UE, and a plurality of authorized QoS rules may be included in the PDU session setup accept within the N1 SM information and within the N2 SM information, the SM response also includes the PDU session ID and information allowing the AMF to know which target UE and determine which access to use for the UE. It should be appreciated that the access information is used to handle the case where the UE is connected through both 3GPP and non-3GPP accesses. In case of a successful PDU session setup, the SMF shall subscribe to the UE location report, providing reporting criteria (e.g. UE location of the area available for the LADN with respect to the LADN). If the UE PDU session belongs to a PDU sharing session, the SMF includes a UE group ID and/or a PDU sharing session ID. If the UE is the first UE in a group of UEs requesting PDU session establishment, the SMF also includes a group QoS profile. For other UEs with the same UE group ID and PDU sharing session ID, the group QoS profile may also include DL TEIDs if sharing N3 tunnels. The DL TEID is the TEID of the existing shared N3 tunnel. Additionally, for some device classes, the SMF may not send one or more of the following to the UE in a NAS message: authorized QoS rules, SSC pattern, S-NSSAI, assigned IPv4 address, session-AMBR.

According to AN embodiment, AMF 706 sends a 731N2 PDU session request, which may include (N2 SM info, NAS message (PDU session ID, PDU session setup accept)) to (R) AN 704. The AMF sends AN NAS message containing the PDU session ID and PDU session setup accept for the UE to the (R) AN, and AN N2 SM information Nsmf _ PDU usage _ CreateSMContext response within the N2 PDU session request received from the SMF in step 730. The (R) AN 704 may issue 732 AN-specific signaling exchanges with the UE 702 that are related to information received from the SMF. For example, in the case of a 3GPP RAN, RRC connection reconfiguration may be performed with the UE establishing the necessary RAN resources related to the authorized QoS rules of the PDU session request received in step 730. The (R) AN also assigns (R) AN N3 tunneling information for the PDU session. In the case of dual connectivity, the primary RAN node may assign some (zero or more) QoS Flow Identifications (QFIs) to be established to the primary RAN node and other QFIs to the secondary RAN node. The RAN tunnel information includes tunnel endpoints for each involved RAN node, and QFIs assigned to each tunnel endpoint. The QFI may be assigned to either the primary RAN node or the secondary RAN node, but not both. The (R) AN forwards the NAS message (PDU session ID, N1 SM info (PDU session setup accept)) provided in step 730 to the UE. The (R) AN may provide the NAS message to the UE if necessary RAN resources are established and the allocation of the (R) AN tunneling information is successful.

According to AN embodiment, (R) AN 704 sends 733 nn 2 PDU session response, which may include (PDU session ID, cause, N2 SM information (PDU session ID, (R) AN tunnel information, qoS profile accept/reject list)) to AMF 706. (R) the AN tunnel information corresponds to AN access network address of the N3 tunnel corresponding to the PDU session. The UE may be assigned a separate N3 tunnel or a shared N3 tunnel. If the SMF does not indicate a shared DL TEID in step 730, the (R) AN may include the DL TEID in the (R) AN tunnel information. The N2 SM information may be omitted if the UE belongs to the UE group ID and the (R) AN shared N3 tunnel for the UE group has already been established.

According to an embodiment, AMF 706 sends a 734nsmf _pdusesion _updatesmcontextrequest (N2 SM message) to SMF 710. The AMF forwards the N2 SM message received from the (R) AN to the SMF. This step may be skipped if the UE PDU session belongs to the PDU shared session ID and the SMF already has (R) AN N3 shared tunnel information. If the N4 session of this PDU session is not already established, the SMF initiates the N4 session establishment procedure with the UPF. Otherwise, the SMF initiates an N4 session modification procedure with the UPF. The SMF provides AN and CN tunnel information. The CN tunnel information needs to be provided only when the SMF selects the CN tunnel information. If the PDU session establishment request is due to mobility between 3GPP and non-3GPP accesses, the downlink data path is switched to the target access in this step. This step and step 735b may be skipped if the UE PDU session belongs to a PDU sharing session and the SMF has notified the (R) AN N3 shared tunnel information to the UPF. UPF 708 provides a 735b N4 session establishment/modification response to the SMF.

According to some embodiments, SMF 710 may assign the same Tunnel Endpoint ID (TEID) to shared N3 and N9 tunnels in the UL. If (R) AN allocates DL N3 TEID, then SMF may allocate DL N9 TEID with the same TEID as DL N3 TEID. The (R) AN 704 and the UPF 708 may perform packet aggregation to transmit aggregated PDUs in the UL and DL N3 and N9 shared tunnels.

According to some embodiments, if the UE's PDU session has unshared N3 and N9 tunnels, SMF 710 may assign the same TEID for unshared UL N3 and UL N9 tunnels. (R) AN 704 may assign a TEID for the DL N3 tunnel and SMF may use the same DL N3 TEID for DL N9 TEID.

According to an embodiment, SMF 710 sends a 736nsmf _pdusesion _updatesmcontextresponse (cause) to AMF 706. After this step, the AMF forwards the relevant event to the SMF, e.g. at handover in case of (R) AN tunnel information change or AMF relocation. Further, if step 734 is skipped, step 736 is also skipped. In some embodiments, in the case of PDU type IPv6, SMF 710 generates and sends an IPv6 router advertisement to UE 702 via UPF 708.

According to an embodiment, if the PDU session setup request is due to a handover between a 3GPP access and a non-3GPP access, i.e. the request type is set to "existing PDU session", SMF 710 performs a step to release 738 the user plane on the source access (3 GPP or non-3GPP access). If the SMF identification is not included in the DNN subscription context, nor has it been stored in the SMF (if previously registered or provided in steps 724a-724b by the UDM), SMF 710 invokes a 739Nudm _UEContextmanagement _Updateservice operation, which includes the SMF address, DNN, and PDU session ID. The UDM stores the SMF identity, SMF address and associated DNN and PDU session IDs.

According to an embodiment, if the PDU session establishment is unsuccessful during the procedure, the SMF informs the AMF. Once the AMF associates the SMF with the PDU session ID, the SMF automatically subscribes to notifications of incoming N1 signaling associated with that PDU session ID. These notifications automatically provide any user location information and access type associated with N1 signaling received by the AMF from the (R) AN.

Fig. 8 illustrates a UE or network requested PDU session modification for non-roaming and local breakout roaming according to an embodiment of the present invention. The UE 802 initiates the PDU session modification procedure by sending 821a PDU session modification request to the AMF 806 as a NAS message, which may include an (N1 SM info (PDU session modification request), PDU session ID) message. Depending on the access type, if the UE is in CM-IDLE mode, the SM-NAS message is preceded by a service request procedure. The N1 message is forwarded by the (R) AN to the 5G core and indicates user location information. AMF 806 calls 821b nsmf _pdusesion _updatesmcontext (PDU session ID), which is sent to SMF 808.PCF 814 invokes the 821c npcf _smpolicycontrol _updatenotifyservice operation to inform SMF 808 to initiate a policy modification procedure, which requires signaling to the UE and/or AN, either at a policy decision or at AN AF request. Note that for a UE group, the PCF may use a shared PDU session ID or UE group ID to modify the PCC rules for multiple UEs and/or multiple PDU sessions. UDM 812 updates 821d SMF 808's subscription data through numdm _ SubscriberData _ UpdateNotification (SUPI, subscription data). The SMF updates the subscription data and confirms the UDM by returning a confirmation with the output (SUPI). Note that for a UE group, the UDM may use the UE group ID to update the subscription data for multiple UEs. The SMF may use the UE group ID when acknowledging the UDM request. SMF 808 may decide to modify the PDU session. The process may also be triggered based on locally configured policies. If the SMF receives the trigger 821e in steps 821a through 821d, the SMF initiates a PDU session modification requested by the SMF. If notification control is configured for Guaranteed Bit Rate (GBR) flows, the QoS target of the flow cannot be met when the (R) AN decides. (R) AN 804 sends 821f N2message (PDU session ID, N2 SM information) to AMF 806. The N2 SM information includes QFI, user location information, and notifications indicating that QoS goals cannot be met. AMF 806 calls 821g Nsmf _PDSession_UpdateSMContext (N2 SM info), which is sent to SMF 808.

According to an embodiment, SMF 808 may need to report some subscription event to PCF 814 by invoking the 822a nsmf @ eventexposure @ notify service operation. The PCF may provide the SMF with new policy information by calling the 822b npcf _smpolicycontrol _updatenotifyservice operation. This step can be skipped if the PDU session modification procedure is triggered in the previous step. If no dynamic PCC is deployed, SMF may apply local policies to decide whether to change the QoS profile. For shared PDU sessions, the SMF uses the UE group ID and/or shared PDU session ID to report a subscription event to the PCF.

According to an embodiment, steps 823 to 827 are not invoked when only an action at the UPF (e.g., gating) is required for PDU session modification.

According to an embodiment, for UE-initiated modification, SMF 808 responds 823a AMF 806 with Nsmf _ PDU usage _ update smcontext (N2 SM info (PDU session ID, qoS profile, session-AMBR), N1 SM info (PDU session modification command (PDU session ID, qoS rule, session-AMBR))). The N2 SM information carries the information that the AMF should provide to the (R) AN. It includes added, deleted or modified QoS profiles. The N1 SM container carries the PDU session modification command that the AMF will provide to the UE. For network-initiated modifications, SMF 808 invokes 823b the Namf _ Communication _ N1N2MessageTransfer (N2 SM information (shared PDU session ID, qoS profile, session-AMBR, shared QoS profile, shared session AMBR), N1 SM container (PDU session modification command (PDU session ID, qoS rule, session-AMBR)) sent to AMF 806). If the UE is in the CM-IDLE state and asynchronous Communication (ATC) is activated, the AMF updates and stores the UE context based on Namf _ Communication _ N1N2MessageTransfer and steps 824, 825, 826, and 827 may be skipped. When the UE is reachable, e.g., when the UE enters CM-CONNECTED state, the AMF forwards the N1 message to synchronize the UE context with the UE. For a shared PDU session, the SMF may include a shared PDU session ID and a shared QoS profile, a shared session AMBR. The PDU session ID may be omitted. For some classes of equipment, the N1 SM container may be omitted.

According to AN embodiment, the AMF 806 may send 824N2 PDU session request (N2 SM info, NAS message (PDU session ID, N1 SM info (PDU session modify command))) message to the (R) AN 804. The (R) AN 804 may issue 825 AN-specific signaling exchange with the UE 802 that is related to information received from the SMF. For example, in the case of a 3GPP RAN, RRC connection reconfiguration may be performed in the event that the UE modifies necessary RAN resources related to the PDU session. The UE acknowledges the PDU session modification command by sending a NAS message (PDU session ID, N1 SM info (PDU session modification command Ack)) message. For shared PDU sessions, (R) AN uses the shared PDU session ID to identify the PDU session of the affected UE and applies the change to the PDU sessions of all UEs.

According to AN embodiment, the (R) AN 804 may acknowledge the N2 PDU session request by sending 826N2 PDU session Ack (QFI, RAN tunnel information, NAS message, user location information) message to the AMF 806. In the case of dual connectivity, if one or more QFIs are added to the PDU session, the master RAN node may assign one of these QFIs to a RAN node that did not previously participate in the PDU session, when the RAN tunneling information includes the new N3 tunneling endpoint of the QFI assigned to the new RAN node. Accordingly, if one or more QFIs are removed from the PDU session, the RAN node may no longer be engaged in the PDU session and remove the corresponding tunnel endpoint from the RAN tunneling information. The AMF 806 forwards 827 the N2 SM information and N1 SM information (PDU session modification command Ack) received from the AN to the SMF 808 via AN Nsmf _ PDU usage _ UpdateSMContext service operation. SMF 808 may update the N4 session of the UPF to which the PDU session modification relates by sending an 828a N4 session modification request (N4 session ID) message to UPF 810. UPF 810 may then send an 828b N4 session modification response to SMF 808. For a shared PDU session, the SMF may update a shared PDU session context using a shared PDU session ID, which applies new PCC rules to the PDU sessions of multiple UEs. The affected UPF during PDU session modification depends on the modified QoS parameters and deployment. For example, in case of a session AMBR change of a PDU session with an uplink classifier (UL CL), only the UL CL is involved.

According to an embodiment, if SMF interacts with PCF in step 821c or 822a, SMF 808 informs PCF 814 of 829 the PCC decision may be enforced by invoking a Nsmf _ EventExposure _ Notify service operation. The SMF may notify entities that have subscribed to user location information related to PDU session change.

Fig. 9 illustrates a PDU session tunnel model according to the related art. The current 3GPP system 3G/4G/5G employs a per PDU Session tunnel (per PDU Session tunnel) between (R) AN 902 and UP 904. Each PDU session has two dedicated tunnels in UL 910, 920 and DL 912, 922. When the UE moves to a new (R) AN node, UL and DL tunnels are reallocated.

Fig. 10 illustrates a shared tunnel for the frequency hopping concept according to an embodiment of the present invention. To avoid signaling overhead, the frequency hopping concept proposes that UP tunnels, such as UL shared tunnel 1010 and DL shared tunnel 1020, may be preconfigured. The UE may be associated with a preconfigured tunnel when the UE attaches to the network.

However, if the UE ID is required for UPF, traffic routing and charging is represented by TEID. When using shared tunnels, the UE ID may be carried in the tunnel header. This may increase the tunnel overhead. In addition, the UPF may need to know the UE location to forward the DL packet. In the frequency hopping concept, the (R) AN can send a message to the UPF in the UL tunnel to inform the UPF of the new UE location. However, in 5G, UE location update is performed in the CP. Thus, this may require signaling for UE location update from (R) AN to AMF, then from AMF to SMF, then from SMF to UPF.

Fig. 11 illustrates a hybrid PDU session tunnel according to an embodiment of the present invention. Depending on the embodiment, the UL and DL tunnel models may be different. For example, the UL tunnel may be a shared tunnel 1110, while the DL tunnel is a per-PDU session tunnel, such as DL PDU session tunnel 1120 and DL PDU session tunnel 1122. This configuration may be applicable to all UPFs that do not require a UE ID to forward UL packets to the application server. The DL tunnel is not shared so that UE mobility can be easily handled through existing solutions already provided in the 3GPP system. According to embodiments, mobility UEs are desired to be supported, and a hybrid PDU session tunnel may provide UL traffic to many UEs of the same application server using a pre-configured shared UP connection, and a DL UP connection may be dedicated to each UE to support mobility.

According to embodiments, the NEF may be preconfigured by network management functions to serve one or more UE groups, one or more network slice instances, one or more applications, one or more Local Area Data Networks (LADNs), and one or more Data Networks (DNs). The NEF may register itself to the NF Repository Function (NRF). The NEF may be selected or reselected by a CP network function, such as the AMF or SMF or UDM or PCF or NEF itself. The selection or reselection of the NEF may be determined by one or more of: DNN, LADN, network slice information (e.g., S-NSSAI), UE ID, UE location, UE group identification, (e.g., internal group ID, external group ID), UE group subscription information, SMF service area, UPF service area, AS location (e.g., DNAI) and geographic area identification, application ID.

In order to discover which AMF and SMF functions serve a particular UE, the NEF may need to access the UDM or UDR. According to an embodiment, the NEF may send the notification message received from the AF to the serving UDM, PCF, AMF or SMF for the group of UEs, instead of sending a separate message for each UE. When the UE registers to the network, the AMF accesses the UE subscription information in the UDM and/or UDR and knows the UE group ID and the preconfigured NEF. If it is the first UE in the UE group, the AMF may subscribe to an event notification service of the NEF for a specific event (e.g., mobility information of the UE group). The AMF may register the AMF with the UDM to serve the UE group. When a UE requests establishment of a PDU session, the AMF selects an SMF to serve the UE and/or a group of UEs including the UE. The SMF accesses the UDM to obtain UE subscription information as well as information about the UE group ID and NEF functions serving the UE or UE group. The SMF may subscribe to the event notification service of the NEF for some events such as AF requests for DNAI reselection. The SMF may register the SMF with the UDM as serving the group of UEs.

According to embodiments, in some cases, a particular NEF may not be the best NEF for a UE group serving a particular UE or UE due to UE mobility, and/or application server mobility, or denial-of-service (DoS) attacks, or load balancing, or NEF maintenance, among other reasons, and therefore may need to be reselected for the UE group. For example, in the case of a vehicle-to-all (V2X), the UE or the entire group of UEs indicates the IoT device associated with a particular vehicle and that vehicle is traveling. In this case, the NEF may be used to send control or data messages from the AF or Application Server (AS) of the V2X application to all UEs in the UE group of a particular UE or IoT device. When the vehicle is traveling, it may be desirable to reselect the NEF so that the NEF is positioned at a more appropriate location along the path of travel of the vehicle. In this example, the control plane function (e.g., SMF) may determine that a NEF needs to be reselected and continue to reselect a more appropriate NEF. As another example, the NEF that needs to reselect to serve the group of UEs may be the result of load balancing. Those skilled in the art will readily appreciate other situations where NEF reselection may be required.

Fig. 12 shows an example of a selection or reselection procedure for a NEF serving a group of UEs. In this example, SMF 1223 determines 1201 that a reselection NEF is required and also selects a target NEF 1225, e.g., a NEF located at a more suitable position along the movement path. SMF 1223 then sends 1202NEF relocation request to source NEF 1224. Source NEF 1224 sends 1203UE group context transfer to target NEF 1225, and target NEF 1225 sends 1204 an acknowledgement of the UE group context transfer to source NEF 1224. The source NEF 1224 then sends 1205 an update NEF request to the AF 1226, and the AF 1226 then sends 1206 a response to the update NEF request to the source NEF 1224. The source NEF 1224 sends 1207 an update UE group context request to the UDM 1221. UDM 1221 sends 1208 a UE group context modification request to PCF 1220 and subsequently receives 1209 a response to the UE group context modification request from PCF 1220. UDM 1221 sends 1210 a UE group context modification request to AMF 1222 and subsequently receives 1211 a response to the UE group context modification request from AMF 1222. In addition, UDM 1221 sends 1212 an update UE group context response to source NEF 1224, and source NEF 1224 then sends 1213 NEF relocation response to SMF 1223. It should be noted that since the source NEF has already sent the UE group context transfer to the target NEF, the AF, SMF, PCF, and AMF do not need to correspond to the target NEF, since the target NEF has already been informed of the transfer.

With further reference to fig. 12, while the UDM is shown sending UE group context modification requests to the PCF and AMF, it will be readily appreciated that the source NEF may send one or both of these UE group modification requests and subsequently receive a corresponding response.

In current V2X queuing solutions, for example, when multiple UEs are traveling in the same vehicle, the application server selects a particular UE as a leader of the multiple UEs in the vehicle. In this configuration, a UE leader receives messages on behalf of multiple UEs, and forwards these messages to the multiple UEs using a device to device (D2D) link (e.g., a PC5 side link in LTE). According to an embodiment, an Application Server (AS) is capable of communicating directly with each UE within a group of UEs when multiple UEs have been allocated to the group of UEs. However, for handover scenarios, such as a UE group defined to include multiple UEs traveling in the same vehicle, handover may be performed by transferring a UE group context from the source RAN to the target RAN. In this embodiment, in the RAN or AN, all individual UEs are handed over to a target RAN (T-RAN), where a source RAN (source RAN, S-RAN) delivers a UE group context to the T-RAN, which requests path switching of all UEs by using the UE group context, which may identify a shared PDU session or a non-shared PDU session or both. At path switch, all UEs in the UE group will communicate through the T-RAN. Since all UEs in the UE group may access the same Data Network (DN), the handover delay associated with the transmission of all UEs is substantially the same or less by transmitting the UE group context than each UE-individual handover. However, it will be readily appreciated that the signaling overhead required for all UEs in the handover group will be significantly reduced when transmitting the UE group context rather than transmitting each UE individually.

Fig. 13 illustrates a case where a single UE exists in a UE group according to an embodiment of the present invention. The UE 1310 in the vehicle is moving from AN area served by the S- (R) AN 1301 to another area served by the T- (R) AN 1302. During mobility, the UE 1310 may be served by different SMFs (Source SMF (S-SMF) 1304 and Target SMF (Target SMF, T-SMF) 1305) and UPFs (Source UPF (S-UPF) 1306 and Target UPF (T-UPF) 1307). The T-SMF 1305 may select the T-UPF 1307 to connect the UP path between the T- (R) AN 1302 and the Target DNAI (Target DNAI, T-DNAI) 1308. The S-DNAI 1311 provides UP access to the application server 1 or Source AS (S-AS) 1312. The T-DNAI 1308 provides UP access to the application server 2 or a Target AS (Target AS, T-AS) 1309. The operation of the AS is coordinated by a Mobile Edge Computing (MEC) orchestrator 1340. The MEC orchestrator 1340 may exchange control messages with the CN 1315 via AFs, such as Source AF (S-AF) 1320 and Target AF (T-AF) 1321. Each AF may be configured by the MEC orchestrator 1340 to interact with certain NEFs, e.g., S-AF 1320 interacts with S-NEF 1313, and T-AF 1321 interacts with T-NEF 1314.

According to an embodiment, the application server and AF may be part of a Mobile Edge Computing (MEC) platform. The AF is a voice binding interface providing a control link to the CN of the mobile network. DNAI represents the user plane access point for applications in the MEC platform. There may be multiple local ases geographically close to the UE location. The AF may support one or more ASs. The NEF may be configured to be associated with one or more AFs, and/or with one or more DNAIs, and/or with one or more applications, and/or with one of more DNNs, and/or with one or more groups of UEs, and/or with one or more geographical area IDs, and/or with one or more UPFs, and/or with one or more registration areas, and/or with one or more LADNs, and/or with one or more AMFs, and/or with one or more SMFs, and/or with one or more PCFs, and/or with one or more UDSFs (unstructured data storage functions), and/or with one or more UDM functions, and/or with one or more UDR functions.

According to the scenario shown in FIG. 13, NEFs such as T-NEF 1314 may be selected by AFs such as T-AF 1321 based on the information obtained. Fig. 14 may be taken as an example. In this approach, the T-AF 1450 may acquire UE-related information in various ways, for example, by communicating with one or more functions such as S-AF 1460. Based on the UE related information, the T-AF 1450 may replace the S-AF 1460 in the subscription of the event open service of the S-NEF 1420 and in the transmission of AF requests related to the impact on traffic routing, e.g. by a procedure comprising steps 1402 to 1405. To perform the selection of the T-NEF 1430 (as in step 1406), the T-AF 1450 may obtain the NEF's information in various ways, such as CAPIF (common API framework) functions 1440, NRFs, or CP NF that stores the NEF information locally, such as AMF and SMF. The selected T-NEF 1430 will replace the S-NEF 1420 to further cooperate with the T-AF 1450, e.g. in subscription to event open services or in transmission of AF requests related to impact on traffic routing or both, e.g. by a procedure comprising steps 1407 to 1410. Fig. 14 illustrates a method of selecting or reselecting a NEF according to an embodiment of the present invention. The NEF is used to exchange CP messages between the CN CP function and the AF, such as messages related to influencing traffic routing requests, or messages related to subscribing to event open services. The NEF may also be used to transport data packets between the UE and the AF or AS. The method in fig. 14 may be applied to a single UE or a group of UEs. For example, the AF may acquire a UE context when applied to a single UE, and may acquire a UE group context when applied to a UE group.

In step 1401, the S-AF 1460 transmits the UE context to the T-AF 1450. The UE context stored in the AF contains all information related to the UE, e.g. external UE ID, external group ID, GPSI, S-NSSAI, S-NEF ID, UE location information, current subscription service in the NEF, e.g. S-NEF 1420, transaction ID indicating AF impact request sent to S-NEF 1420. It should be understood that in some cases step 1401 includes transmission of a UE group context.

In the case of a UE group context, the UE group context may include the UE ID in the UE group, the UE as a leader (or group owner or group leader), the location of all UEs in the UE group. For example, a UE group context may include one or more UE group identifications, one or more Protocol Data Unit (PDU) session contexts, and their PDU session identifications, one or more shared Protocol Data Unit (PDU) session contexts and their identifications, and a list of UE IDs that are members of the UE group.

In step 1402, T-AF 1450 may Subscribe to event open services of S-NEF 1420 for the UE or UEs in the group of UEs, e.g., as described in 3gpp TS 23.502, 4.15.3.2.3, and by using the Nnef _ EventExposure _ Subscribe service in clause 5.2.6.2.2.

In step 1403, T-AF 1450 may send an impact traffic routing request to S-NEF 1420 for the UE or UEs in the group of UEs, e.g., as described in 3gpp TS 23.502, clause 4.3.6.2, and by using the Npcf _ PolicyAuthorization _ Create service in clause 5.2.5.3.2.

In step 1404, the S-AF 1460 may unsubscribe from the event open service of the S-NEF 1420 for the UE or UEs in the group of UEs, e.g., by using the Nnef _ EventExposure _ Delete service as described in 3gpp TS 23.502, clause 5.2.6.2.3.

In step 1405, the S-AF 1460 may cancel the AF-affected traffic routing request in S-NEF 1420 for the UE or UEs in the group of UEs, as described in 3gpp TS 23.502, clause 5.2.5.3.4, by using the Npcf _ PolicyAuthorization _ Delete service.

In step 1406, the T-AF 1450 may decide to select a new NEF. The NEF information may be stored in a CAPIF (generic API framework) core function 1440. The NEF may provide its configuration information to the CAPIF core functionality by using the procedures described in, for example, the 3gpp TS 23.222 clause 8.3 release services API, published in 2018, month 1. For example, the NEF may be configured to serve the entire PLMN network or certain portions of the PLMN. The NEF may be selected based on one or more of the following information: PLMN ID, DNN, DNAI; an application represented by an application ID, AF-service-identity; some network slice instances represented by S-NSSAI or NSI-ID (network slice instance ID); UE group IDs, e.g., internal group ID, external group ID, IMSI group ID; a UE ID; AF, such as AF ID, AF IP address, AF FQDN; a UPF address (UPF IP address or FQDN); AMF, such as AMF ID, AMF IP address, AMF FQDN; SMF, e.g., SMF ID, SMF IP address, SMF FQDN. For example, the T-AF 1450 decides to select a new NEF based on the following conditions, which may include: PLMN =101, dnn = "internet", AF-service-identity = "V2X application-1", S-NSSAI =100. Assuming that T-NEF 1430 is configured to serve V2X with PLMN =101, dnn = "internet", AF-service-identity = "V2X application-1", S-NSSAI =100, T-NEF 1430 is the new NEF selected by T-AF 1450.

The NEF configuration information may also be stored in the NRF or locally in the CP NF such as AMF and SMF.

In step 1407, upon selection of T-NEF 1430, T-AF 1450 may Subscribe to the event open service of T-NEF 1430, e.g., as described in TS 23.502 clause 4.15.3.2.3, and by using the Nnef _ EventExposure _ Subscribe service in clause 5.2.6.2.2.

In step 1408, the T-AF 1450 may send an impact traffic routing request to the T-NEF 1430, e.g., as described in 3gpp TS 23.502, clause 4.3.6.2, and by using the Npcf _ PolicyAuthorization _ Create service in clause 5.2.5.3.2.

In step 1409, T-AF 1450 may unsubscribe from the event open service of S-NEF 1420, e.g., the Nnef _ EventExposure _ Delete service as described in 3gpp TS 23.502, clause 5.2.6.2.3.

In step 1410, the T-AF 1450 may cancel the AF-affected traffic routing request in S-NEF 1420, e.g., by using the Npcf _ PolicyAuthorization _ Delete service, as described in TS 23.502 clause 5.2.5.3.4.

In steps 1402 to 1405, 1407 to 1410, the S-NEF 1420 and the T-NEF 1430 may need to perform a subscription or unsubscribe to a network open service of the CP function 1410, such as UDM, AMF, SMF, PCF, etc.

The above procedure allows the T-AF 1450 to subscribe to the current service S-NEF 1430, according to an embodiment.

In some embodiments, T-AF 1450 may not need to subscribe to or send a request to S-NEF 1420. In this case, steps 1402 and 1403 are skipped. The T-AF 1450 subscribes to the event open service of the T-NEF 1430 in steps 1404 and 1405. In this case, steps 1409 and 1410 are also skipped.

In some embodiments, the same AF may serve the application servers (S-AS and T-AS). The S-AF 1460 need not perform the transfer of the UE context information to the T-AF 1450. Steps 1401 to 1405 are skipped. Since S-AF and T-AF are the same, steps 1406 to 1410 are performed with S-AF replacing T-AF.

Fig. 15 illustrates another NEF reselection embodiment, wherein a control plane network function (e.g., SMF) may trigger reselection of the NEF. The process may include the following steps.

In step 1501, a number of triggers may require a reselection of the NEF. For example, the trigger may be the result of one or more of the following: UE mobility event, when the UE moves to a new location served by a new (R) AN node, the AMF 1530 informs the SMF 1540 of the new UE location during the handover procedure; applying a mobility event in which an Application Server (AS) may relocate to a new data center or another computing machine in the same data center, the AF may send an AF impact traffic routing to SMF 1540 through PCF 1510; and load balancing among NEFs, maintenance and relocation of S-NEFs within a data center, denial of service (DoS) attacks, network Management functions (e.g., operations, administration, and Management, OAM) functions) may notify SMF 1540. For example, if the current NEF is highly loaded, the NEF may notify the CP NF (e.g., SMF) to request NEF reselection.

In step 1502, the CP NF (e.g., SMF 1540) decides to select another NEF to serve the UE or the UE's PDU session based on the trigger from step 1501. The SMF may interact with NRF or CAPIF core functionality to identify the appropriate NEF. The CP, e.g., SMF, may provide one or more of the following information to the NRF or CAPIF core functionality: mobile network information, e.g., PLMN ID, DNN; network slice information, e.g., represented by S-NSSAI or NSI-ID; application information, such as AF-service-ID, application ID, external application ID, internal application ID, DNAI information (e.g. DNAI ID); UE information such as internal group ID, IMSI group ID, external group ID, UE ID (e.g., SUPI, GPSI); UE location information such as serving (R) AN node ID, (R) AN IP address, or FQDN; CP network function information (e.g. network function ID or IP address or FQDN) serving AMF, SMF, PCF, UDM information; and UPF information such as UPF ID or its IP address or FQDN.

In some embodiments, S-NEF 1550 may initiate NEF reselection itself. In this method, in step 1502, S-NEF 1550 may interact directly with the NRF or CAPIF core functionality to identify the T-NEF. The NEF may have locally stored information to select another NEF.

In some embodiments, the NRF or CAPIF core function may provide the requested CP NF with a list of possible NEFs that may serve the UE or PDU session, as well as attributes of the NEFs. Attributes of the NEF may include one or more of the following information: mobile network information, e.g., PLMN ID, DNN; network slice information, e.g., represented by S-NSSAI or NSI-ID; application information, such as AF-service-ID, application ID, external application ID, internal application ID, DNAI information (e.g., DNAI ID); UE information such as internal group ID, IMSI group ID, external group ID, UE ID (e.g., SUPI, GPSI); UE location information such as serving (R) AN node ID, (R) AN IP address, or FQDN; CP network function information (e.g. network function ID or IP address or FQDN) serving AMF, SMF, PCF, UDM information; and UPF information: UPF ID or its IP address or FQDN. The NRF or CAPIF core functionality may return a list of NEFs that match the information provided by SMF 1540 and, optionally, return load information for the NEFs. The load information may be the percentage of NEF resources being used.

In step 1503, if the CP NF (e.g., SMF 1540) sends a request for a NEF relocation, e.g., a NEF relocation request, to the S-NEF. The request may include one or more of the following: CP NF ID (e.g., SMF ID, SMF IP address, or FQDN); information of T-NEF 1560 (e.g., T-NEF ID or IP address or FQDN); start time of NEF relocation (immediate or predetermined time and date); information for identifying the UE: SUPI, GPSI and/or internal group ID, or internal transaction ID associated with previous request from AF 1570; information for identifying a PDU session of the UE, such as a Packet Flow Description (PFD); position information: such as a geographic area ID; and information for identifying the application: such as application ID, AF-service-identity, DNAI.

In some embodiments, all operations of S-NEF 1550 may be passed to T-NEF 1560. In step 1503, the CP function (e.g., SMF 1540) may provide a CP NF ID (e.g., SMF ID, SMF IP address, or FQDN) to S-NEF 1550; information of the T-NEF 1560 (e.g., T-NEF ID or IP address or FQDN); start time (immediate or predetermined time and date) of NEF relocation.

According to some embodiments, the CP NF (e.g., SMF 1540) may send the NEF Relocation request using the services of the NEF, i.e., the Nnef _ UEContext _ Relocation service described herein.

In step 1504, the S-NEF 1550 sends a request for transmitting a UE context, e.g., a UE context (or UE group context) transmission request, to the T-NEF 1560. The request may include one or more of the following information: S-NEF ID; start time of NEF reselection: immediate or predetermined time; UE context information, which may include UE related information, AF related information, information on a subscription service of the CP NF, and information on a user plane. According to an embodiment, the UE related information may comprise one or more of the following: UE ID (SUPI, GPSI, IP address/prefix); SUPI to GPSI parameter mapping; an external group ID; mapping of external group ID and IMSI group ID. According to an embodiment, the AF-related information may comprise one or more of the following: AF-service-identification (e.g., edge computing application); whether the AF is authorized; parameter mapping (e.g., edge computing application) of AF-service-identity and 5G core network (5G core, 5GC) information (DNN, S-NSSAI); parameter mapping (edge calculation) of AF-service-identity and DNAI list and routing profile ID; mapping an external application identifier to a known parameter of a corresponding application identifier at a Packet Flow Description Function (PFDF) (PFD management); and (3) AF request: mapping (edge calculation) of AF transaction internal ID and AF transaction ID in AF request; AF subscription for event monitoring (e.g. event open service of CN): "NEF records association of event triggers and requester identities"; and trigger a quota or rate of submission (e.g., short Message Service (SMS) over NAS applications). According to an embodiment, the information about subscribed services of the CP NF may include one or more CP NF IDs to which the S-NEF subscribes: SMF ID, PCF ID, UDM ID, AMF ID, or others; the NEF stores the AF notification report information received from the AF and maps it to NEF notification report information for the PCF (e.g., edge computing application); PCF subscription (e.g., in an edge computing application) for NEF notification of AF requests; an event subscription for the NEF monitoring the opening of events; event filters (e.g., batch subscription services); AMF events, including bulk subscriptions for many UEs (e.g., event open services); and UDM events (e.g., event open services). According to an embodiment, the information about the user plane may include one or more of: the UPF provides the UE with an UP connection for IoT messaging between AFs/ASs and provides PDU session context for the UE using S-NEF for communication with AF or AS.

According to some embodiments, S-NEF 1550 may use the Nnef UEContext Create described in this document to send UE information from S-NEF 1550 to T-NEF 1560.

According to some embodiments, the NEF may store the UE context in a local storage medium. Alternatively, the NEF may store the UE context in an external storage function, e.g. UDSF (unstructured data storage function), UDR. If the UE context is stored in an external storage function, S-NEF 1550 retrieves the UE context from the storage function and sends it to T-NEF 1560. Optionally, S-NEF 1550 may inform T-NEF 1560 of the location of the UE context, which may include network storage function address or ID (e.g., UDSF IP address, UDSF ID, UDR IP address), UE information (UE ID (GPSI, SUPI, external UE identity)). In the case of a UE group, S-NEF 1550 may include an internal group ID or an external group ID.

According to some embodiments, S-NEF 1550 may also inform CP functions (e.g., UDM, SMF, AMF, and PCF) of the location of the NEF' S UE context. This step is not shown in fig. 15. In the event of a DoS attack on S-NEF 1550, SMF 1540 may send a NEF relocation request directly to T-NEF 1560. The request may include a storage location of the NEF UE context for retrieval by the T-NEF 1560. In some cases, such as DoS attack scenarios, NEF failure, and some other scenarios, steps 1504, 1512, 1513, 1514, 1515 may be skipped.

According to an embodiment, T-NEF 1560 may then subscribe to the services of the CP NF.

In step 1505, T-NEF 1560 may Subscribe to the event open service of SMF 1540, for example, by using the "Nsmf _ EventExposure _ Subscribe" service, as described in 3gpp TS 23.502, clause 5.2.8.3.

In step 1506, the T-NEF 1560 may subscribe to the event open service of the AMF 1530, for example, by using the "Namf _ EventExposure _ UnSubscribe" service, as described in 3GPP TS 23.502 clause 5.2.2.3.

In step 1507, the T-NEF 1560 may Subscribe to the event open service of the UDM 1520, for example by using the "numm _ SDM _ Subscribe" service, as described in 3gpp TS 23.502, clause 5.2.3.5.

In step 1508, the T-NEF 1560 may Subscribe to the event exposure service of PCF 1510, e.g., by using the "Npcf _ Policy Authorization _ Subscribe" service, as described in 3gpp TS 23.502, clause 5.2.5.3.

In step 1509, after completing all subscribed services, T-NEF 1560 sends a UE context (or UE group context) transfer response, for example, to S-NEF 1550 to confirm that T-NEF is ready to serve AF 1570. T-NEF 1550 may use the Nnef _ UEContext _ Create described in this document to send a UE context transfer response from T-NEF 1560 to T-NEF 1550.

In step 1510a, S-NEF 1550 may send a message to AF 1570 requesting the AF to update NEF information, e.g., an update NEF request, so that AF 1570 will communicate with the new T-NEF 1560. The message may include an identification of the T-NEF 1560, such as an IP address or NEF ID, and a reason code indicating the reason for changing the NEF.

In step 1510b, AF 1570 may send an acknowledgement to S-NEF 1550, e.g., an update NEF response, confirming receipt of the new NEF information. AF 1570 uses T-NEF 1560 to communicate with CN NF. If S-NEF 1550 receives any notification messages from other CP functions related to the UE or PDU session that have been delivered to T-NEF 1560, S-NEF 1550 will not forward these messages to AF 1570. This is to avoid forwarding the same notification messages from S-NEF 1550 and T-NEF 1560 to AF 1570.

In some embodiments, steps 1510a and 1510b may be implemented by a service using AF, naf _ UEContext _ Update described in this document.

In the case of a DoS attack, NEF failure or maintenance, or some other scenario, T-NEF 1560, rather than S-NEF 1550, sends a message to the AF in step 1510 a. The message may include the identification of the S-NEF and T-NEF 1560, such as IP addresses or NEF IDs, a reason code indicating the reason for changing NEF (e.g., doS attacks, NEF failures, NEF maintenance, load balancing, better packet delays), and a transaction ID used by the AF 1570 to send AF impact traffic routing requests to the CN in advance. In this case, AF 1570 sends an update NEF response to T-NEF 1560, not to S-NEF 1550.

In step 1511, S-NEF 1550 may send a message, such as a NEF relocation response, to the CP, such as SMF. This is to confirm that the newly selected T-NEF 1560 is ready to exchange CP messages or UP data packets with the AF 1570 or application server.

According to some embodiments, S-NEF 1550 may use a service of the NEF, i.e., the Nnef _ UEContext _ Relocation service described herein, to send a NEF Relocation response to SMF 1540.

Subsequently, S-NEF 1550 may unsubscribe from the services of CP NF.

In step 1512, the T-NEF 1560 may UnSubscribe from event open services for SMF 1540, for example, by using the "Nsmf _ EventExposure _ unsubscript" service, as described in 3gpp TS 23.502 clause 5.2.8.3.

In step 1513, the S-NEF 1560 may UnSubscribe from the event open service of the AMF 1530, for example, by using the "Namf _ EventExposure _ unsubscript" service, as described in 3gpp TS 23.502, clause 5.2.2.3.

In step 1514, the T-NEF 1560 may UnSubscribe from the event open service of UDM 1520, for example, by using the "Nudm _ SDM _ unsubscript" service, as described in 3gpp TS 23.502, clause 5.2.3.5.

In step 1515, the T-NEF 1560 may UnSubscribe from the event open service of PCF 1510, e.g., by using the "Npcf _ Policy Authorization _ unsubscripte" service, as described in 3gpp TS 23.502, clause 5.2.5.3.

In fig. 14 and 15, the UE context may be transmitted or updated in the AF. By using a service-based interface, the AF may provide the following services to support UE context transfer and update between the two AF functions. The service of the AF related to the UE context (which may be named Naf UEContext, for example) may include UE context creation in the AF (which may be named Naf UEContext Create, for example), UE context Update (which may be named Naf UEContext Update, for example), UE context Release (which may be named Naf UEContext Release, for example), and obtaining the UE context from the AF (which may be named Naf UEContext Get, for example).

According to an embodiment, UE context creation enables the creation of a new UE context in the AF. The required inputs may include UE ID (e.g., GPSI, IMSI). The selectable inputs may include one or more of: UE location information, notification subscription of PDU session state change, PEI, GPSI, AN type, NEF ID, UE related information (UE ID (SUPI, GPSI, IP address/prefix)), whether AF is authorized, transaction ID (each corresponding to AN AF request), AF subscription for event monitoring (event open), information on subscription services of CP NF; S-NEF subscribes to CP NF ID of its service: SMF ID, PCF ID, UDM ID, AMF ID and others and event filters (for bulk subscriptions). The required output from the UE context creation function is a result indication, e.g. successful or unsuccessful, and in some embodiments the optional output may be a cause.

According to an embodiment, the UE context update function may enable updating of an existing UE context in the AF. The input may include a UE ID (e.g., GPSI, IMSI). The input may optionally include one or more of the following: UE location information, notification subscription of PDU session state change, PEI, GPSI, AN type, NEF ID, UE related information (UE ID (SUPI, GPSI, IP address/prefix)), whether AF is authorized, transaction ID (each corresponding to AN AF request), AF subscription for event monitoring (event open), information on subscription services of CP NF; S-NEF subscribes to CP NF ID of its service: SMF ID, PCF ID, UDM ID, AMF ID, and others; and event filters (bulk subscriptions). The required output from the UE context update function is a result indication, e.g. successful or unsuccessful, and in some embodiments the optional output may be a cause or an external UE ID or both.

According to an embodiment, the UE context release in the AF function may release the existing UE context in the AF. The required inputs may include UE IDs (e.g., GPSI, IMSI, external UE ID). The required output from the UE context release function is an outcome indication, e.g. successful or unsuccessful, and in some embodiments the optional output may be a cause or an external UE ID or both.

According to an embodiment, said obtaining the UE context from the AF function may enable the client function to obtain the UE context in the AF. The required inputs may include UE ID (e.g., GPSI, IMSI). The required output from obtaining the UE context from the AF function is a result indication, e.g. successful or unsuccessful, and the UE context stored in the AF. In some embodiments, the optional output may be a reason (e.g., UE context does not exist, UE context is not allowed to be transmitted out of AF, UE ID (e.g., external UE ID, GPSI).

According to an embodiment, a service of the NEF related to the UE context (e.g. the name of the service may be Nnef _ UEContext) includes UE context creation in the NEF (e.g. it may be named as Nnef _ UEContext _ Create), UE context Update in the NEF (e.g. it may be named as Nnef _ UEContext _ Update), UE context Release in the NEF (e.g. it may be named as Nnef _ UEContext _ Release), UE context Relocation (e.g. it may be named as Nnef _ UEContext _ Relocation) and obtaining the UE context from the NEF (e.g. it may be named as Nnef _ UEContext _ Get).

According to an embodiment, UE context creation in the NEF function may create a new UE context in the NEF. The required inputs may include the UE ID (e.g., SUPI, GPSI, IMSI, 5G-GUTI). The selectable inputs may include one or more of: UE related information: IP address/prefix, UE location (e.g., RAN address), SUPI to GPSI parameter mapping, internal group ID, external group ID and IMSI group ID mapping, external group ID and internal group ID mapping, packet Flow Description (PFD); AF-related information: AF-service-identity, whether AF is authorized, parameter mapping of AF-service-identity and 5GC information (DNN, S-NSSAI), parameter mapping of AF-service-identity and list of DNAI and routing profile IDs, parameter mapping of external application identity to corresponding application identity known at PFDF (PFD management); and (3) AF request: mapping (edge calculation) of AF transaction internal ID and AF transaction ID in AF request; AF subscription for event monitoring (event open): "NEF records association of event triggers and requester identities"; trigger submission quota or rate (SMS over NAS); information about subscription services of the CP NF; information on the user plane and PDU session context of the UE communicating with the AF or AS using S-NEF. According to an embodiment, the information about the subscription service of the CP NF may include one or more of: S-NEF subscribes to CP NF ID of its service: SMF ID, PCF ID, UDM ID, AMF ID, and others; the NEF stores the AF notification report information received from the AF and maps it to NEF notification report information for the PCF (edge calculation); PCF subscription (edge calculation) for NEF notification of AF request; an event subscription for the NEF monitoring the opening of events; event filters (bulk subscriptions); AMF events, including batch subscriptions for many UEs (event open); and UDM events (event open). According to an embodiment, the information about the user plane may include that the UPF provides the UE with a UP connection for IoT messaging between AFs/ASs. The required output from UE context creation in the NEF function is an outcome indication, e.g. successful or unsuccessful, and in some embodiments the optional output may be a cause.

According to an embodiment, UE context update in the NEF function may update the existing UE context in the NEF. The required inputs may include UE ID (e.g., GPSI, IMSI). The selectable inputs may include one or more of: UE related information: IP address/prefix, UE location (e.g., RAN address), SUPI to GPSI parameter mapping, external group ID, mapping of external group ID and IMSI group ID, packet Flow Description (PFD); AF-related information: AF-service-identity, whether AF is authorized, parameter mapping of AF-service-identity and 5GC information (DNN, S-NSSAI), parameter mapping of AF-service-identity and list of DNAI and routing profile IDs, parameter mapping of external application identity to corresponding application identity known at PFDF (PFD management); and (3) AF request: mapping (edge calculation) of AF transaction internal ID and AF transaction ID in AF request; AF subscription for event monitoring (event open): "NEF records association of event triggers and requestor identifications"; trigger submission quota or rate (SMS over NAS); information about subscription services of the CP NF; information on the user plane and PDU session context of the UE communicating with the AF or AS using S-NEF. According to an embodiment, the information about the subscription service of the CP NF may include one or more of: S-NEF subscribes to CP NF ID of its service: SMF ID, PCF ID, UDM ID, AMF ID, and others; the NEF stores the AF notification report information received from the AF and maps it to NEF notification report information for the PCF (edge calculation); PCF subscription (edge calculation) for NEF notification of AF request; an event subscription for the NEF monitoring the event opening; event filters (bulk subscriptions); AMF events, including batch subscriptions for many UEs (event open); and UDM events (event open). According to an embodiment, the information about the user plane may include that the UPF provides the UE with a UP connection for IoT messaging between AFs/ASs. The required output from UE context creation in the NEF function is an outcome indication, e.g. successful or unsuccessful, and in some embodiments the optional output may be a cause.

According to an embodiment, UE context release in NEF functionality may release existing UE context in NEF. The required input may include one or more of the following information: UE ID (e.g., SUPI, GPSI, IMSI), internal group ID, external group ID, AF-service-identity, network slice information (e.g., S-NSSAI or NSI ID), location information (e.g., geographical area ID), CP functionality information (e.g., PCF ID, SMF ID). The required output from UE context release in the NEF function is an outcome indication, e.g. successful or unsuccessful, and in some embodiments the optional output may be a cause or an external UE ID or both.

According to an embodiment, the UE context relocation function may enable the client function to request relocation of an existing UE context in a NEF to another NEF. The required input may include one or more of the following information: information identifying the CP NF requesting UE context relocation (e.g., SMF ID, SMF IP address, or FQDN); information of the T-NEF 1560 (e.g., T-NEF ID, or IP address, or FQDN); start time (immediate or predetermined time and date) of NEF relocation; information for identifying a network slice, such as S-NSSAI, NSI-ID; information for identifying the UE, such as one or more of SUPI, GPSI, internal and external group ID, IMSI group ID; information identifying the AF request, such as an internal transaction ID associated with a previous request from AF 1570; information for identifying a PDU session of the UE, such as a Packet Flow Description (PFD); location information (e.g., geographic area ID, UPF service area, registration area, LADN service area, SMF service area, AMF service area); and information for identifying the application (e.g., DNN, application ID, AF-service-identity, DNAI). The input may optionally include a cause (e.g., maintenance, doS attacks, load balancing). The required output from the UE context relocation function is an outcome indication, e.g. successful or unsuccessful, and in some embodiments the optional output may include a reason (e.g. UE context is not present, relocation of UE context is not allowed). For example, if one UE context is to be relocated, the client function may provide the UE ID. The client function may provide an internal group ID if UE contexts of all UEs in one UE group are to be transmitted. The client function may provide an AF-service-identity or an application ID if the UE context of all UEs uses one application.

According to an embodiment, said obtaining UE context from the NEF function may enable the client function to obtain UE context in the NEF. The required input may include one or more of the following information: information identifying the CP NF requesting UE context relocation (e.g., SMF ID, SMF IP address, or FQDN); information for identifying a network slice, such as S-NSSAI, NSI-ID; information for identifying the UE, such as one or more of SUPI, GPSI, internal group ID, external group ID, and IMSI group ID; information identifying the AF request, such as an internal transaction ID associated with a previous request from AF 1570; information for identifying a PDU session of the UE, such as a Packet Flow Description (PFD); location information (e.g., geographic area ID, UPF service area, registration area, LADN service area, SMF service area, AMF service area); and information for identifying the application (e.g., DNN, application ID, AF-service-identity, DNAI). The optional input may include a reason. The required output from obtaining the UE context from the NEF function is a result indication, e.g. success or unsuccessful, and the UE context stored in the NEF. In some embodiments, the optional output may be a reason (e.g., UE context is not present, UE context is not allowed to be transferred from NEF), UE ID (e.g., SUPI, GPSI).

The NEF may provide relocation services to other functions. This service may be named Nnef _ Relocation. The client function may request that the source NEF be replaced by another target NEF. The target NEF obtains all UE context data from the source NEF or a separate storage function (e.g. UDR or UDSF). The client function may send one or more of the following information to the target NEF: source NEF ID (or IP address, FQDN); UE information, such as UE ID (e.g., SUPI, GPSI, internal group ID, external group ID); storing function information (e.g., source NEF ID, source NEF IP address, UDR ID or UDR IP address, UDSF IP address); reasons (e.g., maintenance, doS attacks, load balancing). The target may send a result to the client function, which may include one or more of the following information: result indication (successful, unsuccessful); cause (e.g., UDR data query error). To implement the NEF relocation request, the target NEF may access all UE context data from a provided source (e.g., source NEF or storage function) that holds the UE context data. More details in this regard are explained by way of example in fig. 16.

The CAPIF core function may provide notification of CAPIF events. A CAPIF event may be a NEF instance out of service (e.g., due to network maintenance, hardware bugs, software bugs, doS attacks), an NEF instance being added, a NEF being replaced by another NEF.

The AF may subscribe to CAPIF event notifications. When subscribing to a CAPIF event, the AF may provide its AF ID, which may include a PLMN ID, DNN, LADN, network slice information (e.g., S-NSSAI, NSI-ID), UE group (e.g., external group ID), application information (e.g., AF-service-ID, application ID), location information (e.g., geographical area ID), UE information (e.g., GPSI, external UE ID, IMSI), NEF information (e.g., NEF ID, or API ID), to the event filter. When the condition of the CAPIF event matches the event filter, CAPIF will send a CAPIF notification to the subscribing AF.

The NEF UE context for certain services (e.g. URLLC) may be stored in a separate storage function, such as UDSF. The NEF responsible for supporting UE connections may inform the CAPIF core functionality of the NEF about the location of the UE context, e.g. ID, IP address or FQDN of UDSF. If one NEF instance for some reason goes out of service, the CAPIF or AF may select another UE. CAPIF may provide the location of the UE context for the newly selected NEF instance, so that the newly selected NEF is ready to fulfill the AF request without any interruption.

Fig. 16 shows a NEF relocation method according to an embodiment of the present invention.

In step 1601, the S-NEF1650 stores the UE context, the PDU session context, or both, in the UDR 1645, e.g. by using the services of the UDR 1645. A service, which may be referred to as Nudr _ UDM _ Create, is used the first time a UE context, a PDU session context, or both are created. If a UE context, a PDU session context, or both, has been created, the S-NEF1650 may Update the UE context, the PDU session context, or both, using a service that may be referred to as Nudr _ UDM _ Update.

In step 1602, the CAPIF core function 1665 decides to reselect another T-NEF 1660 to replace the S-NEF 1650. Reselection of the S-NEF1650 may be required in certain scenarios, such as DoS attacks, NEF failures, NEF maintenance. In these scenarios, a network Management function, such as an Operation Administration Management (OAM) function, may notify CAPIF core function 1665 of the unavailability of S-NEF 1650. Optionally, S-NEF1650 may inform CAPIF core functionality of its status (e.g., doS attack, NEF failure, NEF maintenance). This step is not shown in fig. 16.

The S-NEF1650 may also notify the CAPIF core function 1665 of its unavailability by sending a request, which may be referred to as a "Service API upnp hash" request, for example, as described in clause 8.4 of 3gpp TS 23.222 published in month 1 2018. This step is not shown in fig. 16.

In step 1603, the CAPIF core function 1665 may use the NEF _ Relocation service to send a Relocation request to the T-NEF 1660.

In step 1604, if the UE context is stored in the storing function, the T-NEF 1660 may obtain the UE context, e.g., the UE context previously stored by the S-NEF1650, the PDU session context, or both, by using a service of UDR 1645, which may be referred to as a Nudr _ UDM _ Query service.

In step 1605, the T-NEF 1660 may subscribe to an open event notification service of a CP function, such as PCF 1610, UDM 1620, AMF 1630 or SMF 1640, for example, as described previously with reference to fig. 15.

In step 1606, T-NEF 1660 may send a response, for example by using the NEF _ Recoverion response to CAPIF core function 1665 of step 1603.

In step 1607a, the CAPIF core function 1665 may send a message, e.g. an event notification, to the subscribed AF 1670 to inform the unavailability of the S-NEF1650 and information replacing the T-NEF 1660, e.g. the ID or IP address of the T-NEF 1660.

In step 1607b, the AF 1670 may send a message, such as an event notification acknowledgement, to the CAPIF core function 1665 in response to the message of step 1607 a.

In step 1608, T-NEF 1660 may unsubscribe from the open event notification service subscribed to the CP function, e.g., the previous PCF 1610, UDM 1620, AMF 1630 or SMF 1640, on behalf of S-NEF 1650.

In step 1609, S-NEF1650 may optionally unsubscribe from the open event notification service to which S-NEF1650 subscribes to CP functions, such as the previous PCF 1610, UDM 1620, AMF 1630, or SMF 1640.

The method as shown in fig. 16 may have several advantages. First, AF 1670 does not need to resend all AF impact traffic routing and subscription requests for the network open event notification service in case S-NEF1650 stops service. This will help to reduce service interruption times when the CN CP function and the AF cannot exchange control messages.

Fig. 17 is a block diagram of an Electronic Device (ED) 1701 illustrated within the computing and communication environment 1700 that may be used to implement the devices and methods disclosed herein. In some embodiments, the electronic device may be an element of a communication network infrastructure, such as a base station (e.g., a NodeB, evolved Node B (eNodeB, or eNB), next generation NodeB (sometimes referred to as a gdnodeb or gNB), home Subscriber Server (HSS), gateway (GW) such as a Packet Gateway (PGW) or Serving Gateway (SGW) within a Core Network (CN) or Public Land Mobile Network (PLMN), or various other nodes or functions, in other embodiments, the electronic device may be a device that connects to the network infrastructure over a wireless interface, such as a mobile phone, smart phone, or other such device that may be classified as a User Equipment (UE), the ED 1701 may be a machine-type communication (MTC) device (also known as a machine-to-machine (M2M) device), or another such device that may be categorized as a UE, although not providing direct service to users, in some references, the ED may also be referred to as a mobile device, reflecting the terminology of the device connected to the mobile network, whether the device itself is designed for mobility or has mobility, a particular device may utilize all or only a subset of the components shown, and the level of integration may vary from device to device. Such as a Central Processing Unit (CPU) and may also include a dedicated processor, such as a Graphics Processing Unit (GPU) or other such processor, memory 1703, a network interface 1706, and a bus 1707 for connecting the components of the ED 1701. The ED 1701 may optionally also include components such as a mass storage device 1704, a video adapter 1705, and an I/O interface 1708 (shown in phantom).

The memory 1703 may include any type of non-transitory system memory readable by the processor 1702, 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, the memory 1703 may include more than one type of memory, such as ROM for use at start-up and DRAM for program and data storage for use in executing programs. The bus 1707 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.

The electronic device 1701 may also include one or more network interfaces 1706, which may include at least one of a wired network interface and a wireless network interface. As shown in fig. 17, the network interface 1706 may include a wired network interface for connecting to a network 1712 and may also include a wireless access network interface 1711 for connecting to other devices over wireless links. When the ED 1701 is a network infrastructure element, the radio access network interface 1711 may be omitted for nodes or functions that are elements of the PLMN, rather than those at the radio edge (e.g., eNB). When the ED 1701 is an infrastructure at the wireless edge of the network, wired and wireless network interfaces may be included. When the ED 1701 is a wirelessly connected device (e.g., user equipment), a wireless access network interface 1711 may be present and may be supplemented by other wireless interfaces, such as a WiFi network interface. The network interface 1706 allows the electronic device 1701 to communicate with remote entities such as devices connected to a network 1712.

Mass storage 1704 may include any type of non-transitory storage device configured to store data, programs, and other information and to make the data, programs, and other information accessible via bus 1707. Mass storage 1704 may include, for example, one or more of a solid state drive, hard disk drive, magnetic disk drive, or optical disk drive. In some embodiments, the mass storage 1704 may be remote from the electronic device 1701 and may be accessed using a network interface such as the interface 1706. In the illustrated embodiment, mass storage 1704 is different from storage 1703 in which it is included, and may typically perform higher latency compatible storage tasks, but may typically provide little or no volatility. In some embodiments, mass storage 1704 may be integrated with heterogeneous storage 1703.

An optional video adapter 1705 and I/O interface 1708 (shown in dashed lines) provide an interface to couple the electronic device 1701 to external input and output devices. Examples of input and output devices include: a display 1709 coupled to the video adapter 1705; and I/O devices 1710 coupled to the I/O interface 1708, such as a touch screen. Other devices may be coupled to the electronic device 1701 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 interface external devices. Those skilled in the art will appreciate that in embodiments where the ED 1701 is part of a data center, the I/O interface 1708 and the video adapter 1705 may be virtualized and provided through the network interface 1706.

In some embodiments, the electronic device 1701 may be a standalone device, while in other embodiments, the electronic device 1701 may reside within a data center. As understood in the art, a data center is a collection of computing resources (typically in the form of servers) that can be used as a collective computing and storage resource. Within a data center, multiple servers may be connected together to provide a pool of computing resources upon which a virtualized entity may be instantiated. Data centers may be interconnected with one another to form a network consisting of a pool of computing and storage resources connected to one another by connection resources. The connection resources may take the form of physical connections such as ethernet or optical communication links, and may also include wireless communication channels in some cases. If two different data centers are connected by a plurality of different communication channels, the links may be grouped together using any of a variety of techniques including the formation of a Link Aggregation Group (LAG). It should be understood that any or all of the computing, storage, and connection resources (as well as other resources within the network) may be divided among different subnetworks, and in some cases may be in the form of resource slices. Different network slices may be created if resources in multiple connected data centers or other node sets are sliced.

According to an embodiment, a method for managing a User Equipment (UE) in a communication network is provided. The method includes a network function receiving a request from a UE, the UE belonging to a UE group, and the network function generating a UE group context for the UE group.

According to some embodiments, the UE group context comprises a UE group identity. According to some embodiments, the UE group context includes one or more Protocol Data Unit (PDU) session identities. According to some embodiments, the UE group context comprises one or more shared Protocol Data Unit (PDU) session identities. According to some embodiments, the UE group context comprises a list of UE IDs that are members of the UE group.

According to an embodiment, a method for managing a User Equipment (UE) in a communication network is provided. The network function is included to receive a request comprising data indicative of a group of UEs, and the network function sends a notification, the notification being based on the request and the data.

According to some embodiments, the data comprises a UE group identity. According to some embodiments, the data comprises one or more Protocol Data Unit (PDU) session identifications. According to some embodiments, the data comprises one or more shared Protocol Data Unit (PDU) session identifications. According to some embodiments, the request comprises a request to modify a shared PDU session, and wherein the notification comprises a rejection. In accordance with some embodiments, the request comprises a network open function (NEF) relocation request, and wherein the notification comprises data indicating a UE group context, and wherein the UE group context comprises one or more of a UE group identity, a Protocol Data Unit (PDU) session identity, and a shared PDU session identity.

According to an embodiment, there is provided a network function comprising a network interface for receiving data from and sending data to a network function connected to a network, a processor and a non-transitory memory for storing instructions which, when executed by the processor, cause the network function to be configured to perform one or more of the methods defined above.

According to an embodiment, when the UE is moving, the V2X application server may be relocated to meet the packet delay requirements. It is proposed to specify criteria for selecting the NEF to support domain management and to minimize the delay of transmitting control and possibly data packets through the NEF.

Since the NEF is the interface for exchanging control messages between the AF and CN network functions, it is important to ensure that the NEF is correctly selected to minimize the delay of control messages and possible data packets sent over the NEF. For example, in V2X applications, many control messages sent from the AS/AF to the UE are location-dependent. If the location information of the UE is not quickly sent to the AF, the AF/AS may send an incorrect control message to the UE. Therefore, it is important to study the existing NEF selection mechanism and to identify possible improvement issues.

According to an embodiment, a basic NEF selection solution mechanism is provided. The AF may discover NEF instances using the CAPIF framework. In SA WG2 conference #125, SA WG2 agrees to support CAPIF [2]. Therefore, it is believed that SA2 should work in parallel on NEF discovery in 5 GC.

This solution solves the critical problem #8 (supporting edge calculation). When the vehicle is traveling a long distance, a V2X Application Server (V2X AS) may be relocated with the V2X UE in the vehicle to ensure low packet delay requirements. Figure 13 shows the network functions and possible relocation of V2X AS and trajectory of the UE. The MEC orchestrator coordinates the operation of the V2X AS. CP messages between the MEC orchestrator and the CN are exchanged through the AF and the NEF. NEF may be required as specified in TS 23.501, clause 5.6.7 "applied function flow impact". The UP connection between the UE and the V2X AS is provided by the (R) AN node, the UPF, and the DNAI. To support UE mobility, the following steps may be performed: 1) the mobile UE is now served by a different RAN node, 2) the UPF and CP NF can be reselected, 3) the V2X AS can be relocated. 5GC provides a method for CN and AF to negotiate DNAI, 4) NEF can be (re) selected.

In addition to NEF selection, other selection or reselection procedures have been specified (for (R) AN, AMF, UPF, DNAI) or are under investigation (in the case of SMF). The UE can be handed over between RAN nodes as described in TS 23.502[9] clause 4.9. Reselection of UPF and DNAI has been specified in TS 23.501, clause 5.6.7, "application function traffic routing impact" and clause 5.13 "support edge calculation". The AMF may be reallocated as described in TS 23.502, clause 9, 4.2.2.2.3, "registration with AMF reallocation". Relocation of some CP functions can be studied separately. For example, relocation of SMFs and UP is being studied in SID release 16, "SMF and UPF enhanced topology research in 5G networks" (ETSUN) [11 ].

Currently, NEF selection is not specified explicitly in TS 23.501 and TS 23.502. In any event, the AF may use the CAPIF service to discover NEF instances according to a common API framework (CAPIF) [10] supported by 5G systems (5G systems, 5GS). Multiple NEF instances may be allocated to serve one or more applications to mitigate potential denial of service (DoS) attacks and improve domain management and signaling efficiency. The AF may select the NEF to send a request to the CN and subscribe to network open events. NEF reselection may be required to reduce packet delay of control messages and load balancing, if needed.

One NEF instance may be configured to serve one or more applications, one or more network slice instances, one or more DNs, one or more geographic areas, one or more DNAIs, one or more UE groups. The NEF configuration information may be stored in the CAPIF core function, NRF or AF.

During mobility, V2X UEs may be served by different CN functionality sets in different administrative domains. If the V2X application knows the trajectory of the vehicle, the V2X application may select different NEF instances, each for one administrative domain, to send AF impact traffic routing requests and subscribe to CN event exposure services. These procedures may be performed by the AF at any time to ensure that the control link between the AF and the CN is ready to serve the UE whenever the UE enters the administrative domain.

When the V2X UE is no longer in the administrative domain, the AF may cancel the AF impact traffic routing request and unsubscribe from the CN open event at the NEF.

During the lifetime of a PDU session of a V2X application, the NEF may be (re-) selected to support control messages exchanged between the CN function and the AF. Fig. 18 provides a high level process for NEF (re) selection. The AF is currently served by the source NEF (S-NEF). The AF may want to connect to another target NEF (T-NEF).

This process is illustrated in fig. 18, according to an embodiment of the present invention.

In step 1801, if the AF has not found a T-NEF, the AF discovers the set of T-NEFs by using service API discovery of the CAPIF core function as described in 3GPP TS 23.222 clause 8.7[10 ]. The AF may send the following query information for NEF discovery: DNN, S-NSSAI, external group ID and application information (geographical area ID, AF-service-ID, DNAI).

In step 1802, the AF may subscribe to an event open service provided by the T-NEF. The AF may send an event subscription to the CN using the Nnef _ EventExposure _ Subscribe provided by the T-NEF.

In step 1803, the AF may send an affect traffic routing request to the T-NEF by using the Npcf _ PolicyAuthorization _ Create service described in clause 5.2.5.3.2 as part of the AF affect traffic routing process in clause 4.3.6.2 of the TS 23.502. The T-NEF may perform a PCF discovery procedure to identify the serving PCF.

In step 1804, the AF may unsubscribe from the event open service of S-NEF by using the Nnef _ EventExposure _ Delete service described in clause 5.2.6.2.3 of TS 23.502. The S-NEF may cancel the network open service provided by the UDM, AMF and PCF.

In step 1805, the AF may cancel the AF-affecting traffic routing request previously sent to the S-NEF by using the Npcf _ PolicyAuthorization _ Delete service as described in clause 5.2.5.3.4 of the TS 23.502.

The process in fig. 18 uses some existing services of the NEF. The only change required is information specifying that the NEF (re) selects to provide to the CAPIF core functionality for NEFs in TS 23.501 and TS 23.502, including: DNN, S-NSSAI, external group ID and application information (geographical area ID, AF-service-identity, DNAI).

Additional work on NEF discovery may be specified in the CAPIF framework.

While the invention has been described with reference to specific features and embodiments thereof, it will be apparent that various modifications and combinations thereof may be made without departing from the invention. Accordingly, the specification and figures are to be regarded in a simplified manner as being illustrative of the invention defined by the appended claims and are intended to cover any and all modifications, variations, combinations, or equivalents that fall within the scope of the invention.

Claims (38)

1. A method of communication, comprising:

the application function obtains information about one or more network open functions from a network function repository function, wherein the information about one or more network open functions comprises one or more of the following information: network slice information, an application identification and an application function identification representing one or more applications; and

the application function selects a network open function from the one or more network open functions based on the obtained information.

2. The method of claim 1, further comprising:

the application function enforces the selected network open function to serve the user equipment, wherein the selected network open function is different from a source network open function serving the user equipment prior to selection of the selected network open function.

3. The method according to claim 1 or 2, wherein the network slice information is represented by one of single network slice selection assistance information S-NSSAI or network slice instance identification NSI-ID.

4. The method of claim 1 or 2, further comprising:

the application function subscribes to an event open service of the selected network open function,

and the application function sends a request for influencing the traffic routing to the selected network open function.

5. The method of claim 1 or 2, wherein prior to the selecting, the method further comprises:

the application function subscribes to an event opening service of a source network opening function; and

and the application function sends a request for influencing flow routing to the source network open function.

6. The method of claim 5, wherein after the selecting, the method further comprises:

the application function cancels the event open service subscribed to the source network open function; and

the application function cancels the traffic-affecting routing request with the source network open function.

7. The method of claim 1 or 2, wherein the information about one or more network open functions further comprises: user equipment information comprising one or more of the following: an internal group ID representing a UE group, an international mobile subscriber identity IMSI group ID representing a UE group, an external group ID representing a UE group and one or more user equipment IDs.

8. A method of communication, comprising:

a network function repository function stores information about one or more network open functions;

the network functions repository function provides the information on one or more network open functions for selecting a network open function from the one or more network open functions to an application function, wherein the information on one or more network open functions comprises one or more of the following information: network slice information, application identification representing one or more applications, and application function identification.

9. The method of claim 8, further comprising:

the network function repository function obtains a registration of the one or more network open functions.

10. The method according to claim 8 or 9, wherein the network slice information is represented by one of single network slice selection assistance information S-NSSAI or network slice instance identification NSI-ID.

11. The method of claim 8 or 9, wherein the information about one or more network open functions further comprises: user equipment information comprising one or more of the following information: an internal group ID representing a group of UEs, an international mobile subscriber identity IMSI group ID representing a group of UEs, an external group ID representing a group of UEs and one or more user equipment IDs.

12. A method of communication, comprising:

a network function repository function stores information about one or more network open functions;

the application function obtains the information on one or more network open functions from the network function repository function, wherein the information on one or more network open functions comprises one or more of the following information: network slice information, an application identification and an application function identification representing one or more applications; and

the application function selects a network open function from the one or more network open functions based on the obtained information.

13. The method of claim 12, further comprising:

the application function enforces the selected network open function to serve the user equipment, wherein the selected network open function is different from a source network open function serving the user equipment prior to selection of the selected network open function.

14. The method according to claim 12 or 13, wherein the network slice information is represented by one of single network slice selection assistance information S-NSSAI or network slice instance identification NSI-ID.

15. The method according to claim 12 or 13, wherein the method further comprises:

the application function subscribes to an event open service of the selected network open function,

and the application function sends a request for influencing the flow routing to the selected network open function.

16. The method of claim 12 or 13, wherein prior to the selecting, the method further comprises:

the application function subscribes to an event opening service of a source network opening function; and

and the application function sends a request for influencing traffic routing to the source network open function.

17. The method of claim 16, wherein after the selecting, the method further comprises:

the application function cancels the subscription of the event open service of the source network open function; and

the application function cancels the traffic-affecting routing request with the source network open function.

18. The method of claim 12 or 13, further comprising:

the network functions repository function obtains a registration of the one or more network open functions.

19. The method of claim 12 or 13, wherein the information about one or more network open functions further comprises: user equipment information comprising one or more of the following information: an internal group ID representing a UE group, an international mobile subscriber identity IMSI group ID representing a UE group, an external group ID representing a UE group and one or more user equipment IDs.

20. A communication device is applied to application functions and comprises a sending unit, a receiving unit and a processing unit;

the processing unit is configured to obtain information about one or more network open functions from a network function repository function, wherein the information about one or more network open functions includes one or more of the following information: network slice information, an application identification and an application function identification representing one or more applications; and

the processing unit is further configured to select a network open function from the one or more network open functions based on the obtained information.

21. The apparatus of claim 20, wherein the processing unit is configured to force the selected network open function to serve a user equipment, wherein the selected network open function is different from a source network open function serving a user equipment prior to selection of the selected network open function.

22. The apparatus according to claim 20 or 21, wherein the network slice information is represented by one of single network slice selection assistance information S-NSSAI or network slice instance identification NSI-ID.

23. The apparatus according to claim 20 or 21, the processing unit is further configured to subscribe to an event opening service of the selected network opening function; the sending unit is used for sending a request for influencing traffic routing to the selected network open function.

24. The apparatus of claim 20 or 21, wherein

The processing unit is also used for subscribing the event opening service of the source network opening function;

the sending unit is further configured to send a request for influencing traffic routing to the source network openness function.

25. The apparatus of claim 24, wherein, after the selecting,

the processing unit is further configured to cancel an event opening service subscribing to the source network opening function; and canceling the influence traffic routing request with the source network open function.

26. The apparatus of claim 20 or 21, wherein the information about one or more network open functions further comprises: user equipment information comprising one or more of the following: an internal group ID representing a UE group, an international mobile subscriber identity IMSI group ID representing a UE group, an external group ID representing a UE group and one or more user equipment IDs.

27. A communication device is applied to the function of a network function repository and comprises a processing unit and a sending unit;

the processing unit is used for storing information about one or more network open functions;

the sending unit is configured to provide, to an application function, the information on one or more network open functions for selecting a network open function from the one or more network open functions, wherein the information on one or more network open functions includes one or more of the following information: network slice information, application identification representing one or more applications, and application function identification.

28. The apparatus of claim 27, further comprising:

the processing unit obtains a registration of the one or more network open functions.

29. The apparatus according to claim 27 or 28, wherein the network slice information is represented by one of single network slice selection assistance information S-NSSAI or network slice instance identification NSI-ID.

30. The apparatus of claim 27 or 28, wherein the information about one or more network open functions further comprises: user equipment information comprising one or more of the following: an internal group ID representing a UE group, an international mobile subscriber identity IMSI group ID representing a UE group, an external group ID representing a UE group and one or more user equipment IDs.

31. A communication system comprising an application function and a network function repository function, wherein,

the network function repository function is for storing information about one or more network open functions;

the application function is configured to obtain the information on one or more network open functions from the network function repository function, wherein the information on one or more network open functions includes one or more of the following information: network slice information, an application identification and an application function identification representing one or more applications; and

the application function is further configured to select a network open function from the one or more network open functions based on the obtained information.

32. The communication system of claim 31, wherein the application function is further configured to force the selected network open function to serve the user equipment, wherein the selected network open function is different from a source network open function serving the user equipment prior to selection of the selected network open function.

33. The communication system according to claim 31 or 32, wherein the network slice information is represented by one of single network slice selection assistance information S-NSSAI or network slice instance identification NSI-ID.

34. The communication system according to claim 31 or 32, wherein the application function is further configured to subscribe to an event exposure service of the selected network exposure function, the application function being further configured to send an impact traffic routing request to the selected network exposure function.

35. The communication system of claim 31 or 32, wherein the application function is further configured to: prior to the selection of the network open function,

an event opening service subscribing the source network opening function; and

and sending a request for influencing traffic routing to the source network open function.

36. The communication system of claim 35, wherein the application function is further to: after the selection of the network open function,

canceling an event opening service subscribing the source network opening function; and

canceling the affected traffic routing request with the source network open function.

37. The communication system of claim 31 or 32, wherein the network function repository function is further to:

obtaining registration of the one or more network open functions.

38. A non-transitory computer-readable medium storing computer instructions that, when executed by one or more processors, cause the one or more processors to perform the method of any one of claims 1-7, claims 8-11, and claims 12-19.

Images