Method and system for handling offloaded session management

Abstract

A session management function receives, from a wireless device, a first message including delay information for offload handling of data for an application. The session management function sends, to the wireless device, a second message including offload information based on the delay information.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit of U.S. Provisional Application No. 62 / 990,766, filed March 17, 2020, the entire contents of which are hereby incorporated by reference. Attached Figure Description

[0003] Examples of several embodiments of the various implementations of the invention are described herein with reference to the figures.

[0004] Figure 1 A diagram illustrating an example 5G system architecture according to an embodiment of this disclosure.

[0005] Figure 2 A diagram illustrating an example 5G system architecture according to an embodiment of this disclosure.

[0006] Figure 3 This is a system diagram of an example wireless device and network node in a 5G system according to an embodiment of the present disclosure.

[0007] Figure 4 A system diagram of an example wireless device according to an embodiment of the present disclosure.

[0008] Figure 5A and Figure 5B Two registration management status models in UE 100 and AMF 155 are described, representing aspects of the embodiments according to this disclosure.

[0009] Figure 6A and Figure 6B Two connection management state models in UE 100 and AMF 155 are described, representing aspects of the embodiments according to this disclosure.

[0010] Figure 7 A diagram for classifying and labeling traffic according to aspects of the embodiments of this disclosure.

[0011] Figure 8 Example call diagram for aspects of the implementation according to this disclosure.

[0012] Figure 9 Example call diagram for aspects of the implementation according to this disclosure.

[0013] Figure 10 Example call diagram for aspects of the implementation according to this disclosure.

[0014] Figure 11 Example call diagram for aspects of the implementation according to this disclosure.

[0015] Figure 12Example call diagram for aspects of the implementation according to this disclosure.

[0016] Figure 13 Example call diagram for aspects of the implementation according to this disclosure.

[0017] Figure 14 An exemplary radio resource control (RRC) state transition aspect according to an embodiment of this disclosure.

[0018] Figure 15 This illustrates a service-based architecture for a 5G network regarding the interaction between the control plane (CP) and the user plane (UP).

[0019] Figure 16 An implementation scheme for a system including an application server controller is shown.

[0020] Figure 17 This illustrates segmented management between the cellular network domain and the mobile edge computing (MEC) domain.

[0021] Figure 18A This is an example call graph for MEC discovery.

[0022] Figure 18B An example is shown of how the AS controller can influence the traffic routing of application data within the core network.

[0023] Figure 19 An example is shown where the AS controller affects the traffic routing of application data by causing a reconfiguration of the user plane within the core network.

[0024] Figure 20 An example of calculating uninstallation options is shown.

[0025] Figure 21 An example call diagram for unloading determination is shown according to an exemplary embodiment of this disclosure.

[0026] Figure 22 An example call diagram for unloading determination is shown according to an exemplary embodiment of this disclosure.

[0027] Figure 23 An exemplary flowchart of this disclosure is shown.

[0028] Figure 24 An exemplary flowchart of this disclosure is shown.

[0029] Figure 25 An exemplary flowchart of this disclosure is shown. Detailed Implementation

[0030] Exemplary embodiments of the present invention enable enhanced features and functionalities to be implemented in 4G / 5G systems. Embodiments of the technology disclosed herein can be used in the fields of 4G / 5G systems and network slicing for communication systems. More specifically, embodiments of the technology disclosed herein can relate to 5G core networks and 5G systems for network slicing in communication systems. Throughout this disclosure, UEs, wireless devices, and mobile devices are used interchangeably.

[0031] The following abbreviations are used throughout this disclosure:

[0032] 5G (5th generation mobile network)

[0033] 5GC 5G Core Network

[0034] 5GS 5G System

[0035] 5G-AN5G Access Network

[0036] 5QI 5G QoS Indicator

[0037] ACK confirmation

[0038] AF application functions

[0039] AMF access and mobility management functions

[0040] AN access network

[0041] CDR Fee Data Records

[0042] CCNF Public Control Network Functions

[0043] CIoT Cellular IoT

[0044] CN Core Network

[0045] CP control plane

[0046] DDN downlink data notification

[0047] DL downlink

[0048] DN Data Network

[0049] DNN data network name

[0050] DRX discontinuous reception

[0051] F-TEID fully compliant TEID

[0052] gNB Next Generation Node B

[0053] GPSI General Public Subscription Identifier

[0054] GTP GPRS Tunneling Protocol

[0055] GUTI Globally Unique Temporary Identifier

[0056] HPLMN Local Public Land Mobile Network

[0057] IMSI International Mobile User Identity

[0058] LADN Local Area Data Network

[0059] LI legitimate interception

[0060] MEI mobile device identifier

[0061] MICO only initiates connections via mobile.

[0062] MME Mobility Management Entity

[0063] MO Mobile initiated

[0064] MSISDN Mobile Subscriber ISDN

[0065] MT movement termination

[0066] N3IWF Non-3GPP Interoperability Function

[0067] NAI Network Access Identifier

[0068] NAS Non-Access Layer

[0069] NAS-MM Non-Access Stratum Mobility Management

[0070] NAS-SM Non-Access Stratum Session Management

[0071] NB-IoT Narrowband IoT

[0072] NEF Network Exposure Function

[0073] NF Network Functions

[0074] NGAP Next Generation Application Protocol

[0075] NR New Radio

[0076] NRF Network Repository Functionality

[0077] NSI network slicing example

[0078] NSSAI Network Slice Selection Auxiliary Information

[0079] NSSF Network Slice Selection Function

[0080] OCS Online Billing System

[0081] OFCS Offline Billing System

[0082] PCF strategy control function

[0083] PDU (Packet / Protocol Data Unit)

[0084] PEI Permanent Device Identifier

[0085] PLMN Public Land Mobile Network

[0086] PRACH Physical Random Access Channel

[0087] PLMN Public Land Mobile Network

[0088] PSAPDU Session Anchor

[0089] RAN Radio Access Network

[0090] QFIQoS stream identity

[0091] RM Registration Management

[0092] S1-APS1 Application Protocol

[0093] SBA Service-Based Architecture

[0094] SEA Safety Anchor Function

[0095] SCM Security Context Management

[0096] SI System Information

[0097] SIB System Information Block

[0098] SMF Session Management Function

[0099] SMS / FSMS function

[0100] S-NSSAI Single Network Slice Selection Auxiliary Information

[0101] SSC Session and Service Continuity

[0102] SUCI Service User Relevance ID

[0103] SUPI subscriber permanent identifier

[0104] TEID tunnel endpoint identifier

[0105] UDM Unified Data Management

[0106] UER Unified Data Storage

[0107] UDR User Data Storage

[0108] UE User Equipment

[0109] UL uplink

[0110] UL CL Uplink Classifier

[0111] UPF User Plane Functions

[0112] VPLMN access to public terrestrial mobile networks

[0113] Example Figure 1 and Figure 2 A 5G system including an access network and a 5G core network is depicted. An example 5G access network may include an access network connected to the 5G core network. The access network may include NG-RAN 105 and / or non-3GPP AN 165. An example 5G core network may connect to one or more 5G access networks, 5G-AN and / or NG-RAN. The 5G core network may include, as shown in the example... Figure 1 and examples Figure 2 The functional elements or network functions in the system, wherein the interface can be used for communication between functional elements and / or network elements.

[0114] In one example, a network function can be a processing function within a network, which may have functional behaviors and / or interfaces. Network functions can be implemented as network elements on dedicated hardware and / or such as... Figure 3 and Figure 4 The network nodes depicted are either implemented as software instances running on dedicated hardware and / or shared hardware, or as virtual functions instantiated on a suitable platform.

[0115] In one example, the Access and Mobility Management (AMF) function AMF 155 may include the following functions (some of the functions of AMF 155 may be supported in a single instance of AMF 155): termination of the RAN 105 CP interface (N2), termination of NAS (N1), NAS encryption and integrity protection, registration management, connection management, reachability management, mobility management, lawful interception (for AMF155 events and interfaces with the LI system), providing transport for session management, SM messages between UE 100 and SMF 160, transparent proxy for routing SM messages, access authentication, access authorization, providing transport for SMS messages between UE 100 and SMSF, security anchor function, SEA, interaction with AMFF 150 and UE 100, receiving intermediate keys established as a result of the UE 100 authentication process, receiving security context management (SCM) keys from the SEA for deriving access network-specific keys, etc.

[0116] In one example, AMF 155 can support non-3GPP access networks via the N2 interface with N3IWF 170, support NAS signaling with UE 100 via N3IWF 170, support authentication, mobility management, and separate security context states for UE 100 connected via non-3GPP access 165 or simultaneously via 3GPP access 105 and non-3GPP access 165, support effective coordination of RM contexts via 3GPP access 105 and non-3GPP access 165, support CM management context for UE 100 for connectivity via non-3GPP access, and so on.

[0117] In one example, an AMF 155 area may include one or more AMF 155 sets. An AMF 155 set may include some AMF 155s serving a given area and / or network slice. In one example, multiple AMF 155 sets may be each AMF 155 area and / or network slice. An application identifier may be an identifier that can be mapped to a specific application traffic detection rule. A configured NSSAI may be an NSSAI that can be provided in UE 100. For DNN, the DN 115 Access Identifier (DNAI) may be an identifier for user plane access to DN 115. Initial registration may be related to UE 100 registration in RM-DEREGISTERED (RM-Deregister) states 500 and 520. An N2AP UE 100 association may be a logical association between a 5G AN node and an AMF 155 based on UE 100. An N2AP UE-TNLA combination may be a combination between an N2AP UE 100 association and a TNL association for a specific transport network layer, for a given UE 100.

[0118] In one example, the session management function SMF 160 may include one or more of the following functions (one or more of the SMF 160 functions may be supported in a single instance of SMF 160): session management (e.g., session establishment, modification, and release, including tunnel maintenance between UPF 110 and AN 105 nodes), UE 100 IP address allocation and management (including optional authorization), selection and control of UP functions, configuring traffic redirection at UPF 110 to route traffic to the appropriate destination, terminating the interface for policy control functions, controlling policy enforcement and a portion of QoS, lawful interception (for SM events and interfaces with LI systems), terminating the SM portion of NAS messages, downlink data notification, initiating AN-specific SM information, sending via N2 to (R)AN 105 via AMF 155, determining the SSC mode of the session, roaming functions, handling local execution to apply QoS SLA (VPLMN), charge data collection and charge interface (VPLMN), lawful interception (in VPLMN, for SM events and interfaces with LI systems), and support for external DN. The interaction of DN 115 is used to transmit signaling for PDU session authorization / authentication by external DN 115, etc.

[0119] In one example, the user plane function UPF 110 may include one or more of the following functions (some of the UPF 110 functions may be supported in a single instance of UPF 110): anchor points for movement within / between RATs (if applicable), external PDU session points interconnected to DN 115, packet routing and forwarding, packet inspection and user plane portion of policy rule enforcement, lawful interception (UP collection), traffic usage reporting, uplink classifier for routed traffic flows supporting data networks, branch points supporting multihomed PDU sessions, QoS processing in the user plane, uplink traffic authentication (SDF to QoS flow mapping), transport level packet marking in uplink and downlink, downlink packet buffering, downlink data notification triggering, etc.

[0120] In one example, UE 100 IP address management may include the allocation and release of UE 100 IP addresses and / or the updating of allocated IP addresses. UE 100 may set the requested PDU type during the PDU session establishment procedure based on its IP stack capabilities and / or configuration. In one example, SMF 160 may select the PDU type for the PDU session. In one example, if SMF 160 receives a request to set the PDU type to IP, SMF 160 may select the PDU type as IPv4 or IPv6 based on DNN configuration and / or operator policies. In one example, SMF 160 may provide a reason value to UE 100 to indicate whether other IP versions are supported on the DNN. In one example, if SMF 160 receives a request for the PDU type to be IPv4 or IPv6, and the requested IP version is supported by the DNN, SMF 160 may select the requested PDU type.

[0121] In the example implementation, the 5GC element and UE 100 can support the following mechanism: During the PDU session establishment procedure, the SMF 160 can send an IP address to the UE 100 via SM NAS signaling. Once the PDU session can be established, IPv4 address allocation and / or IPv4 parameter configuration can be used via DHCPv4. If IPv6 is supported, IPv6 prefix allocation can be supported via stateless IPv6 autoconfiguration. In one example, the 5GC network element can support IPv6 parameter configuration via stateless DHCPv6.

[0122] 5GC can support the allocation of static IPv4 addresses and / or static IPv6 prefixes based on subscription information in UDM 140 and / or on configurations on a per subscriber, per DNN basis.

[0123] The User Plane Function (UPF 110) can handle the user plane path of a PDU session. The UPF 110, which provides an interface to the data network, can support the PDU session anchoring function.

[0124] In one example, the policy control function PCF 135 can support a unified policy framework to control network behavior, provide policy rules for control plane functions to enforce policy rules, implement a front-end for accessing subscription information related to policy decisions in the User Data Repository (UDR), and so on.

[0125] The Network Exposure Function (NEF 125) can provide a means to securely expose services and capabilities provided by 3GPP network functions, switch between information exchanged with AF 145 and information exchanged with internal network functions, receive information from other network functions, and so on.

[0126] In the example, the Network Repository feature NRF 130 can support service discovery functionality that can receive NF discovery requests from NF instances, provide NF instances with information about discovered NF instances (to be discovered), and maintain information about available NF instances and the services they support, etc.

[0127] In the example, NSSF 120 can select a set of network slice instances serving UE 100 to determine the allowed NSSAI. In one example, NSSF 120 can determine the set of AMF 155 to be used to serve UE 100, and / or determine the list of candidate AMF 155s by querying NRF 130 based on configuration.

[0128] In one example, the data stored in the UDR may include at least user subscription data, including at least subscription identifiers, security credentials, access and mobility-related subscription data, session-related subscription data, policy data, and so on.

[0129] In one example, the AUSF 150 can support authentication server functionality (AUSF 150).

[0130] In one example, Application Function (AF) AF 145 can interact with the 3GPP core network to provide services. In another example, based on operator deployment, an Application Function may be trusted by the operator to interact directly with the relevant network function. Application Functions that the operator does not allow to directly access network functions can interact with the relevant network function using an external exposure framework (e.g., via NEF 125).

[0131] In one example, the control plane interface between (R)AN 105 and the 5G core can support connecting various types of ANs (e.g., 3GPP RAN 105, N3IWF 170 for untrusted access 165) to the 5GC via control plane protocols. In one example, the N2 AP protocol can be used for both 3GPP access 105 and non-3GPP access 165. In one example, the control plane interface between (R)AN 105 and the 5G core can support decoupling between AMF 155 and other functions (such as SMF 160) that may need to control services supported by the AN (e.g., control of UP resources in AN 105 for PDU sessions).

[0132] In one example, 5GC can provide policy information from PCF 135 to UE 100. In one example, policy information may include: access network discovery and selection policy, UE 100 routing selection policy (URSP), SSC mode selection policy (SSCMSP), network slice selection policy (NSSP), DNN selection policy, non-seamless offloading policy, etc.

[0133] In one example, such as in Figure 5A and Figure 5B As described, the Registration Management (RM) can be used to register or deregister UE / User 100 in the network and establish user contexts in the network. Connection Management can be used to establish and release signaling connections between UE 100 and AMF155.

[0134] In one example, UE 100 may register on the network to receive services that require registration. In another example, UE 100 may periodically update its registration on the network to maintain reachability (periodic registration update), or update it while on the move (e.g., mobile registration update), or update its capabilities or renegotiate protocol parameters.

[0135] In one example, as shown in the example Figure 8 and Figure 9 The initial registration procedure described may involve performing network access control functions (e.g., user authentication and access authorization based on subscription profiles in UDM 140). Example Figure 9 yes Figure 8 The initial registration procedure described herein continues. Due to the initial registration procedure, the identity of service AMF 155 can be registered in UDM 140.

[0136] In one example, the registration management RM program can be applied to both 3GPP Access 105 and non-3GPP Access 165.

[0137] Example Figure 5A The RM state of UE 100 as observed by UE 100 and AMF 155 can be depicted. In an example implementation, two RM states reflecting the registration status of UE 100 in the selected PLMN can be employed in UE 100 and AMF 155: RM-DEREGISTERED 500 and RM-REGISTERED 510. In one example, in RM-DEREGISTERED state 500, UE 100 may not be registered in the network. The UE 100 context in AMF 155 may not maintain valid location or routing information for UE 100, therefore UE 100 may not be reachable via AMF 155. In the example, the UE 100 context may be stored in both UE 100 and AMF 155. In the example, in RM-REGISTERED state 510, UE 100 may register with the network. In RM-REGISTERED state 510, UE 100 may receive services that may require registration on the network.

[0138] In the example implementation, two RM states that reflect the registration status of UE 100 in the selected PLMN can be adopted for UE 100 in AMF 155: RM-DEREGISTERED 520 and RM-REGISTERED 530.

[0139] As shown in the example Figure 6A and Figure 6B As depicted, the connection management CM may include establishing and releasing a signaling connection between UE 100 and AMF 155 via the N1 interface. This signaling connection can be used to implement NAS signaling exchange between UE 100 and the core network. The signaling connection between UE 100 and AMF 155 may include both the AN signaling connection between UE 100 and (R)AN 105 (e.g., an RRC connection via 3GPP access) and the N2 connection between AN and AMF 155 for UE 100. In one example, the signaling connection may be an N1 signaling connection. In another example, the signaling connection may be an N1 NAS signaling connection.

[0140] As shown in the example Figure 6A and Figure 6B As described, for the NAS signaling connection between UE 100 and AMF 155, two CM states can be used: CM-IDLE (600, 620) and CM-CONNECTED (610, 630). UE 100 in CM-IDLE 600 state can be in RM-REGISTERED 510 state and may not have a NAS signaling connection established with AMF 155 via N1. UE 100 in CM-IDLE 600 state can be in RRC idle state. UE 100 can perform cell selection, cell reselection, PLMN selection, etc. UE 100 in CM-CONNECTED 610 state can have a NAS signaling connection with AMF 155 via N1. In one example, UE 100 in CM-CONNECTED 610 state can be in RRC connected state. A UE 100 in the CM-CONNTECTED 610 state may be in an RRC inactive state. In one example, the CM state in the AMF and the CM state in the UE may differ. This may be the case when a local state change occurs without explicit signaling procedures (e.g., UE context release procedures) between the UE and the AMF. In one example, the RRC state in the UE (e.g., radio device) and the RRC state in the base station (e.g., gNB, eNB) may differ. This may be the case when a local state change occurs without explicit signaling procedures (e.g., RRC release procedures) between the UE and the base station.

[0141] In one exemplary implementation, for UE 100 at AMF 155, two CM states can be adopted, namely CM-IDLE 620 and CM-CONNECTED 630.

[0142] In one example, the RRC inactivity state can be applied to NG-RAN (e.g., it can be applied to NR and E-UTRA connected to a 5G CN). Based on network configuration, AMF 155 can provide auxiliary information to NG RAN 105 to assist NG RAN 105 in determining whether UE 100 can be sent to the RRC inactivity state. When UE 100 is in CM-CONNECTED 610 in the RRC inactivity state, UE 100 can continue the RRC connection as a response to RAN 105 paging due to uplink data pending, mobile-initiated signaling procedures, etc., to notify the network that it has left the RAN 105 notification area, etc.

[0143] In one example, NAS signaling connection management may include establishing and releasing NAS signaling connections. The NAS signaling connection establishment function can be provided by UE 100 and AMF 155 to establish a NAS signaling connection for UE 100 in CM-IDLE 600 state. The procedure for releasing the NAS signaling connection can be initiated by the 5G(R)AN 105 node or AMF 155.

[0144] In one example, reachability management for UE 100 can detect whether UE 100 is reachable and can provide the UE 100 location (e.g., access node) to the network to reach UE 100. Reachability management can be accomplished by paging UE 100 and UE 100 location tracking. UE 100 location tracking can include both UE 100 registration area tracking and UE 100 reachability tracking. During registration and registration update procedures, UE 100 and AMF 155 can negotiate UE 100 reachability characteristics in CM-IDLE 600, 620 states.

[0145] In one example, for CM-IDLE 600 and 620 states, two UE 100 reachability categories can be negotiated between UE 100 and AMF 155. 1) When UE 100 is in CM-IDLE 600 mode, UE 100 reachability allows the mobile device to terminate data. 2) Mobile-Initiated Connection Only (MICO) mode. 5GC can support PDU connection services, which provide PDU exchange between UE 100 and the data network identified by the DNN. PDU connection services can be supported via PDU sessions established at the request of UE 100.

[0146] In one example, a PDU session can support one or more PDU session types. A PDU session can be established, modified (e.g., based on a request from UE 100), and / or released (e.g., based on a request from both UE 100 and 5GC) using NAS SM signaling exchanged via N1 between UE 100 and SMF 160. Upon request from the application server, 5GC can trigger a specific application within UE 100. When a trigger is received, UE 100 can send it to the identified application within UE 100. The identified application within UE 100 can establish a PDU session for a specific DNN.

[0147] In one example, the 5G QoS model can support, as shown in the example. Figure 7 The framework described herein is based on QoS flows. The 5G QoS model can simultaneously support QoS flows that require guaranteed flow bit rates and QoS flows that do not require guaranteed flow bit rates. In one example, the 5G QoS model can support reflection QoS. The QoS model may include flow mapping or packet marking at UPF 110 (CN_UP) 110, AN105, and / or UE 100. In one example, packets can arrive at and / or be assigned to the application / service layer 730 of UE 100, UPF 110 (CN_UP) 110, and / or AF 145.

[0148] In one example, a QoS flow can be a granularity of QoS differentiation within a PDU session. QoS flow IDs and QFIs can be used to identify QoS flows in a 5G system. In one example, user plane traffic with the same QFI within a PDU session can receive the same traffic forwarding processing. The QFI can be carried in the encapsulation header on N3 and / or N9 (e.g., without changing the end-to-end packet header). In one example, the QFI can be applied to PDUs with different types of payloads. The QFI can be unique within a PDU session.

[0149] In one example, the QoS parameters of a QoS flow can be provided as a QoS profile to (R)AN 105 via N2 during PDU session establishment, QoS flow establishment, or each time the user plane is activated using NG-RAN. In another example, each PDU session may require default QoS rules. SMF 160 can assign a QFI to the QoS flow and can derive QoS parameters from information provided by PCF 135. In one example, SMF 160 can provide the (R)AN 105 with a QFI and a QoS profile containing the QoS parameters of the QoS flow.

[0150] In one example, a 5G QoS stream can be the granularity used for QoS forwarding processing in a 5G system. Traffic mapped to the same 5G QoS stream can receive the same forwarding processing (e.g., scheduling policies, queue management policies, rate setting policies, RLC configuration, etc.). In one example, providing different QoS forwarding processing might require separate 5G QoS streams.

[0151] In one example, the 5G QoS indicator can be a scalar that can be used as a reference for specific QoS forwarding behaviors (e.g., packet loss rate, packet delay budget) to be provided to the 5G QoS flow. In this example, the 5G QoS indicator can be implemented in the access network by 5QI reference node-specific parameters (e.g., scheduling weight, admission threshold, queue management threshold, link layer protocol configuration, etc.) that control QoS forwarding processing.

[0152] In the example, edge computing can provide computing and storage resources with sufficient connectivity near the device that generates traffic.

[0153] In the example, 5GC supports edge computing and enables operators and third-party services to be hosted close to the UE's attached access point. The 5G core network can select a UPF 110 close to UE 100 and can perform traffic redirection from UPF 110 to the local data network via the N6 interface. In one example, selection and traffic redirection can be based on UE 100's subscription data, UE 100's location, information from application function AF 145, policies, other relevant traffic rules, etc. In one example, the 5G core network can expose network information and capabilities to edge computing application functions. Edge computing functionality support may include: local routing, where the 5G core network can select UPF 110 to route user traffic to the local data network; traffic redirection, where the 5G core network can select traffic to be routed to applications in the local data network; session and service continuity for UE100 and application mobility; user plane selection and reselection, for example, based on input from application functions; network capability openness, where the 5G core network and application functions can provide information to each other via NEf 125; QoS and charging, where PCF 135 can provide QoS control and charging rules for traffic routed to the local data network; support for LAN data networks, where the 5G core network can provide support for connectivity to LADN in specific areas where applications are deployed; and so on.

[0154] An example 5G system could be a 3GPP system including a 5G access network 105, a 5G core network, and a UE 100. The permitted NSSAI could be an NSSAI provided by the serving PLMN during, for example, the registration process, indicating the network-permitted NSSAI for UE 100 within the serving PLMN of the currently registered area.

[0155] In one example, a PDU connectivity service can provide PDU exchange between UE 100 and the data network. A PDU session can be an association between UE 100 and data network DN 115 that provides PDU connectivity services. The association type can be IP, Ethernet, and / or unstructured.

[0156] The user plane connection to the data network established via the network slice instance may include the following: executing the RM procedure to select the AMF 155 that supports the required network slice, and the number of one or more PDU sessions established to the required data network via the network slice instance.

[0157] In one example, the network slice set of UE 100 can be changed at any time when UE 100 can register on the network, and can be initiated by the network or UE 100.

[0158] In one example, periodic registration updates could be UE 100 re-registering when the periodic registration timer expires. The requested NSSAI could be an NSSAI that UE 100 can provide to the network.

[0159] In one example, a service-based interface can represent a set of services that can be provided / exposed by a given NF.

[0160] In one example, service continuity can be an uninterrupted user experience of the service, including situations where the IP address and / or anchor point can change. In another example, session continuity can refer to the continuity of a PDU session. For IP-type PDU sessions, session continuity can imply that the IP address is retained throughout the lifetime of the PDU session. The uplink classifier can be a UPF110 function, designed to redirect uplink traffic to the data network DN 115 based on filter rules provided by SMF 160.

[0161] In one example, a 5G system architecture can support data connectivity and services, enabling deployments using technologies such as network function virtualization and / or software-defined networking. The 5G system architecture can leverage service-based interactions between identified control plane (CP) network functions. In a 5G system architecture, user plane (UP) functions can be decoupled from control plane functions. If needed, the 5G system can enable network functions to interact directly with other NFs.

[0162] In one example, a 5G system can reduce the dependency between the access network (AN) and the core network (CN). The architecture may include an aggregated access-agnostic core network with a common AN-CN interface, which can integrate different 3GPP and non-3GPP access types.

[0163] In one example, a 5G system can support a unified authentication framework, stateless network-native architectures (NFs) with separate compute and storage resources, open capabilities, and simultaneous access to both local and centralized services. To support low-latency services and access to local data networks, UP (Upload and Activation) functionality can be deployed close to the access network.

[0164] In one example, a 5G system can support roaming within a visited PLMN using home routing traffic and / or local breakout traffic. The example 5G architecture can be service-based, and the interaction between network functions can be represented in two ways. (1) As a service-based representation (in the example...) Figure 1 (2) As a reference point representation, it shows the interaction between NF services in any two network functions described by a point-to-point reference point (e.g., N11).

[0165] In one example, a network slice may include core network control plane and user plane network functions, 5G radio access network; N3IWF functions for non-3GPP access networks, etc. Network slices can differ for the supported features and network function implementations. Operators can deploy multiple network slice instances that deliver the same features but are used for different groups of UEs, for example, when they deliver different committed services and / or because they can be dedicated to a customer. The NSSF 120 can store mapping information between slice instance IDs and NF IDs (or NF addresses).

[0166] In the example, UE 100 can be served simultaneously by one or more network slice instances via 5G-AN. In the example, UE 100 can be served by k network slices at a time (e.g., k=8, 16, etc.). Logically, the AMF 155 instance serving UE 100 can belong to the network slice instance serving UE 100.

[0167] In one example, each PLMN may have a PDU session belonging to a specific network slice instance. In another example, different network slice instances may not share PDU sessions. Different slices may have slice-specific PDU sessions using the same DNN.

[0168] S-NSSAI (Single Network Slice Selection Auxiliary Information) identifies network slices. S-NSSAI may include: Slice / Service Type (SST), which may refer to the expected network slice behavior in terms of characteristics and services; and / or Slice Differentiator (SD). The Slice Differentiator may be optional information that supplements the Slice / Service Type to allow further differentiation to select a network slice instance from multiple potential network slice instances conforming to the indicated Slice / Service Type. In one example, the same network slice instance employing different S-NSSAIs can be selected. The CN portion of the network slice instance serving UE 100 may be selected by the CN.

[0169] In one example, subscription data may include the S-NSSAI of the network slice subscribed by UE 100. One or more S-NSSAIs may be marked as the default S-NSSAI. In one example, k S-NSSAIs may be marked as the default S-NSSAI (e.g., k=8, 16, etc.). In one example, UE 100 may subscribe to more than 8 S-NSSAIs.

[0170] In one example, UE 100 can be configured by an HPLMN, each PLMN being configured with an NSSAI. After successfully completing the UE's registration procedure, UE 100 can obtain the allowed NSSAI for this PLMN from AMF 155, which may include one or more S-NSSAIs.

[0171] In one example, the PLMN's allowed NSSAI can take precedence over the configured NSSAI. UE 100 can use the S-NSSAI corresponding to the network slice used in the serving PLMN for subsequent network slice selection procedures within the allowed NSSAI.

[0172] In one example, establishing a user plane connection to a data network via a network slice instance may include: executing an RM procedure to select an AMF 155 that supports the desired network slice, the number of one or more PDU sessions established to the desired data network via the network slice instance, and so on.

[0173] In one example, when UE 100 registers with the PLMN, if UE 100 has a configured NSSAI or an allowed NSSAI for the PLMN, UE 100 can provide the requested NSSAI (which includes the S-NSSAI corresponding to the slice UE 100 is attempting to register for), a temporary user ID (if a temporary user ID is assigned to the UE), etc., to the network and NAS layers in the RRC. The requested NSSAI can be a configured NSSAI, an allowed NSSAI, etc.

[0174] In one example, when UE 100 registers with the PLMN, if UE 100 does not have a configured NSSAI or an allowed NSSAI for the PLMN, then RAN 105 can route NAS signaling from UE 100 to the default AMF 155 / route NAS signaling from the default AMF to the UE.

[0175] In one example, based on local policies, subscription changes, and / or UE 100 mobility, the network can change the set of permitted network slices to which UE 100 is registered. In one example, the network can perform the change during the registration process or use an RM procedure (which can trigger the registration process) to notify UE 100 of the change in supported network slices. The network can provide UE 100 with the new list of permitted NSSAI and tracking areas.

[0176] In one example, during the registration process in the PLMN, if the network determines that UE100 should be served by a different AMF 155 based on network slicing, the AMF 155 that first receives the registration request can redirect the registration request to another AMF 155 via RAN 105 or via direct signaling between the initial AMF 155 and the target AMF 155.

[0177] In one example, a network operator can provide a Network Slice Selection Policy (NSSP) to UE 100. An NSSP may include one or more NSSP rules.

[0178] In one example, if UE 100 has one or more PDU sessions established corresponding to a specific S-NSSAI, UE 100 can route application user data within a single PDU session unless other conditions in UE 100 prevent the use of the PDU session. If the application provides a Data Navigate (DNN), UE 100 can consider the DNN to determine which PDU session to use. In one example, if UE 100 does not have a PDU session established with a specific S-NSSAI, UE 100 can request a new PDU session corresponding to the S-NSSAI and with a DNN that can be provided by the application. In one example, for RAN 105 to select appropriate resources to support network slices in RAN 105, RAN 105 can know the network slice used by UE 100.

[0179] In the example, when UE 100 triggers the establishment of a PDU session, AMF 155 can select SMF 160 from the network slice instance based on S-NSSAI, DNN, and / or other information (e.g., UE 100 subscriptions and local operator policies). The selected SMF160 can then establish a PDU session based on S-NSSAI and DNN.

[0180] In one example, to support network control privacy of slice information for slices accessible to UE 100, UE 100 may exclude NSSAI from NAS signaling when UE 100 is aware of or configured to allow privacy considerations to apply to NSSAI, unless UE 100 has a NAS security context and UE 100 may exclude NSSAI from unprotected RRC signaling.

[0181] In one example, for roaming scenarios, network slice-specific network functions (NFs) can be selected in both the VPLMN and HPLMN based on the S-NSSAI provided by the UE 100 during PDU connection establishment. If a standardized S-NSSAI is used, each PLMN can select slice-specific NF instances based on the provided S-NSSAI. In one example, the VPLMN can map the HPLMN's S-NSSAI to the VPLMN's S-NSSAI based on a roaming protocol (e.g., including the default S-NSSAI mapped to the VPLMN). In one example, slice-specific NF instances can be selected in the VPLMN based on the VPLMN's S-NSSAI. In one example, any slice-specific NF instance in the HPLMN can be selected based on the HPLMN's S-NSSAI.

[0182] As shown in the example Figure 8 and Figure 9 As described, the UE 100 can perform a registration procedure to obtain authorization for receiving services, to enable mobile tracking, to achieve accessibility, and so on.

[0183] In one example, UE 100 may send AN message 805 to (R)AN 105 (including AN parameters, RM-NAS registration request (registration type, SUCI or SUPI or 5G-GUTI, last accessed TAI (if available), security parameters, requested NSSAI, mapping of the requested NSSAI, UE 100 5GC capability, PDU session status, PDU session to be reactivated, follow-up requests, MICO mode preference, etc.) etc.). In one example, in the case of NG-RAN, AN parameters may include, for example, SUCI or SUPI or 5G-GUTI, selected PLMN ID, and requested NSSAI, etc. In one example, AN parameters may include establishment reason. The establishment reason can provide the reason for requesting to establish an RRC connection. In one example, the registration type could indicate whether UE 100 is performing initial registration (i.e., UE 100 is in RM-DEREGISTERED state), mobile registration update (e.g., UE 100 is in RM-REGISTERED state and initiates a registration process due to mobility), periodic registration update (e.g., UE 100 is in RM-REGISTERED state and may initiate a registration process due to the expiration of a periodic registration update timer), or emergency registration (e.g., UE 100 is in a limited service state). In one example, if UE 100 performs initial registration with a PLMN that does not yet have a 5G-GUTI (i.e., UE 100 is in RM-DEREGISTERED state), UE 100 can include its SUCI or SUPI in the registration request. The SUCI can be included if the home network has provided a public key to protect the SUPI in the UE. If UE100 receives a UE 100 configuration update command indicating that UE 100 needs to re-register and that the 5G-GUTI is invalid, UE 100 can perform initial registration and may include a SUPI in the registration request message. For emergency registration, if UE 100 does not have a valid 5G-GUTI available, a SUPI may be included; when UE 100 has neither a SUPI nor a valid 5G-GUTI, a PEI may be included. In other cases, a 5G-GUTI may be included, and it may indicate the last serving AMF 155. If UE 100 has already registered via non-3GPP access in a new PLMN different from the 3GPP access (e.g., not the registered PLMN or an equivalent PLMN of the registered PLMN), UE 100 may provide the 5G-GUTI assigned by AMF 155 without 3GPP access during the registration procedure via non-3GPP access.If UE 100 has already registered in a PLMN (e.g., a registered PLMN) that is different from a non-3GPP access PLMN (e.g., not a registered PLMN or an equivalent PLMN of a registered PLMN), then during the registration procedure via 3GPP access, UE 100 may not provide the 5G-GUTI assigned by AMF 155 via non-3GPP access. UE 100 may provide UE usage settings based on its configuration. In the case of initial registration or mobile registration update, UE 100 may include a mapping of requested NSSAIs, which may be a mapping of each S-NSSAI in the requested NSSAI of the HPLMN to the S-NSSAI in the configured NSSAI, to ensure that the network can verify whether the S-NSSAI in the requested NSSAI is allowed based on the subscribed S-NSSAI. If available, the previously accessed TAI may be included to help AMF 155 generate the UE's registration area. In one example, security parameters may be used for authentication and integrity protection. The requested NSSAI may instruct network slice selection auxiliary information. The PDU session status can indicate previously established PDU sessions in the UE. When UE 100 is connected to two AMF 155s belonging to different PLMNs via 3GPP access and non-3GPP access, the PDU session status can indicate the PDU sessions already established in the UE for the current PLMN. It may include PDU sessions awaiting reactivation to indicate that UE 100 may intend to activate a PDU session for its UP connection. When UE 100 is outside the availability area of ​​the LADN, the PDU session corresponding to the LADN may not be included in the PDU sessions awaiting reactivation. When UE 100 may have pending uplink signaling, and UE 100 may not include PDU sessions awaiting reactivation, it may include follow-up requests, or the registration type may indicate that UE 100 may need to perform emergency registration.

[0184] In one example, if including SUPI or 5G-GUTI does not indicate a valid AMF 155, then (R)AN 105 may select AMF 155 808 based on (R)AT and the requested NSSAI (if available). If UE 100 is in CM-CONNECTED state, then (R)AN 105 may forward the registration request message to AMF 155 based on the UE's N2 connection. If (R)AN 105 can choose not to select an appropriate AMF 155, it may forward the registration request to an AMF 155 that is configured in (R)AN 105 to perform AMF 155 selection 808.

[0185] In one example, (R)AN 105 can send an N2 message 810 to the new AMF 155 (including: N2 parameters, RM-NAS registration request (registration type, SUPI or 5G-GUTI, last accessed TAI (if available), security parameters, requested NSSAI, mapping of the requested NSSAI, UE 100 5GC capability, PDU session status, PDU session to be reactivated, follow-up requests, and MICO mode preferences), etc.). In one example, when using NG-RAN, the N2 parameters may include the selected PLMN ID, location information, cell identity, and RAT type related to the cell where UE 100 resides. In one example, when using NG-RAN, the N2 parameters may include the establishment reason.

[0186] In one example, the new AMF 155 can send a Namf_Communication_UEContextTransfer (full registration request) 815 to the old AMF 155. In another example, if the UE's 5G-GUTI is included in the registration request and the serving AMF 155 has changed since the last registration procedure, the new AMF 155 can invoke the Namf_Communication_UEContextTransfer service operation 815 on the old AMF 155 (including an integrity-protected full registration request IE) to request the UE's SUPI and MM context. The old AMF 155 can use the integrity-protected full registration request IE to verify that the context transfer service operation call corresponds to the requesting UE 100. In one example, the old AMF 155 can transfer event subscription information for the UE for each NF consumer to the new AMF 155. In another example, if UE 100 identifies itself with a PEI, the SUPI request can be skipped.

[0187] In one example, the old AMF 155 can send a Namf_Communication_UEContextTransfer response 815 (SUPI, MM context, SMF 160 information, PCF ID) to the new AMF 155. In another example, the old AMF 155 can respond to the Namf_Communication_UEContextTransfer call with the new AMF 155 including the UE's SUPI and MM context. In one example, if the old AMF 155 maintains information about established PDU sessions, it can include SMF 160 information, including S-NSSAI, SMF 160 identity, and PDU session ID. In another example, if the old AMF 155 maintains information about active NGAP UE-TNLA to the N3IWF, it can include information about NGAP UE-TNLA bindings.

[0188] In one example, if the SUCI is not provided by UE 100 or retrieved from the legacy AMF 155, the identity request procedure 820 can be initiated by the AMF 155 sending an identity request message to the UE 100 that requests the SUCI.

[0189] In one example, UE 100 can respond with an identity response message 820 that includes the SUCI. UE 100 can derive the SUCI using the public key of the provided HPLMN.

[0190] In one example, the AMF 155 may decide to initiate UE 100 authentication 825 by calling AUSF 150. The AMF 155 may select AUSF 150 based on SUPI or SUCI. In one example, if the AMF 155 is configured to support emergency registration for unauthenticated SUPI and emergency registration of the registration type indicated by UE 100, the AMF 155 may skip authentication and security settings, or the AMF 155 may accept that authentication may fail and continue the registration procedure.

[0191] In one example, authentication 830 can be performed by the Nudm_UEAuthenticate_Get operation. AUSF 150 can discover UDM 140. If AMF 155 provides SUCI to AUSF 150, AUSF 150 can return SUPI to AMF 155 after successful authentication. In one example, if network slicing is used, AMF 155 can decide whether to reroute the registration request if the initial AMF 155 references AMF 155. In one example, AMF 155 can initiate NAS security functions. In one example, upon completing NAS security function settings, AMF 155 can initiate NGAP procedures so that 5G-AN can use them to protect procedures with the UE. In one example, 5G-AN can store a security context and can acknowledge it to AMF 155. 5G-AN can use the security context to protect messages exchanged with the UE.

[0192] In one example, the new AMF 155 can send a Namf_Communication_RegistrationCompleteNotify 835 to the old AMF 155. If the AMF 155 has changed, the new AMF 155 can notify the old AMF 155 that UE100 can complete its registration in the new AMF 155 by calling the Namf_Communication_RegistrationCompleteNotify service operation. If the authentication / security procedure fails, registration can be refused, and the new AMF 155 can call the Namf_Communication_RegistrationCompleteNotify service operation, with the refusal indication reason code directed to the old AMF 155. The old AMF 155 can continue as if it never received the UE 100 context transport service operation. If one or more of the S-NSSAIs used in the old registration area may not be serviced in the target registration area, the new AMF 155 can determine which PDU sessions may not be supported in the new registration area. The new AMF 155 can call the Namf_Communication_RegistrationCompleteNotify service operation to the old AMF 155, including the rejected PDU session ID and the reason for rejection (e.g., S-NSSAI becomes unavailable). The new AMF 155 can modify the PDU session state accordingly. The old AMF 155 can notify the corresponding SMF 160 to release the UE's SM context locally by calling the Nsmf_PDUSession_ReleaseSMContext service operation.

[0193] In one example, the new AMF 155 can send an Identity Request / Response 840 (e.g., PEI) to UE 100. If the PEI is not provided by UE 100 or retrieved from the old AMF 155, the Identity Request procedure can be initiated by sending an Identity Request message to UE 100 via AMF 155 to retrieve the PEI. Unless UE 100 performs emergency registration, the PEI may be transmitted encrypted and may not be authenticated. For emergency registration, UE 100 may have already included the PEI in the registration request.

[0194] In one example, the new AMF 155 can initiate an ME identity check 845 by calling the N5g-eir_EquipmentIdentityCheck_Get service operation 845.

[0195] In one example, based on SUPI, the new AMF 155 can be selected as a 905 UDM 140. The UDM 140 can be selected as a UDR instance. In another example, the AMF 155 can be selected as a UDM 140.

[0196] In one example, if AMF 155 has changed since the last registration procedure, or if UE 100 provides a SUPI that may not reference a valid context in AMF 155, or if UE 100 is registered to the same AMF 155 but has already registered to a non-3GPP access (e.g., UE 100 registered via a non-3GPP access and can initiate a registration procedure to add 3GPP access), the new AMF 155 can register with UDM 140 using Nudm_UECM_Registration 910 and can subscribe to be notified by UDM 140 when AMF 155 registration can be cancelled. UDM 140 can store the AMF155 identifier associated with the access type and may not delete the AMF 155 identifier associated with another access type. UDM 140 can store information provided by Nudr_UDM_Update during registration in the UDR. In one example, AMF 155 can retrieve access and mobile subscription data and SMF 160 select subscription data using Nudm_SDM_Get 915. UDM 140 can retrieve this information (access and mobile subscription data) from the UDR via Nudr_UDM_Query. After receiving a successful response, AMF 155 can subscribe to be notified when the requested data can be modified using Nudm_SDM_Subscribe 920. UDM 140 can subscribe to the UDR via Nudr_UDM_Subscribe. If GPSI is available in the UE 100 subscription data, it can be provided from UDM140 to AMF 155 in the subscription data. In one example, a new AMF 155 can provide its access type for serving UE 100 to UDM 140, and this access type can be set to 3GPP access. UDM 140 can store the associated access type in the UDR along with the serving AMF 155 via Nudr_UDM_Update. The new AMF 155 can create an MM context for UE 100 after obtaining mobile subscription data from UDM 140. In one example, when UDM 140 stores the associated access type along with the serving AMF 155, UDM 140 can initiate Nudm_UECM_DeregistrationNotification 921 to the old AMF 155 corresponding to the 3GPP access. The old AMF 155 can then remove the UE's MM context. If the reason for the service NF deletion indicated by UDM 140 is initial registration, the old AMF 155 can call the Namf_EventExposure_Notify service operation to all associated SMFs 160 of UE 100 to notify UE 100 to deregister from the old AMF 155.SMF 160 can release the PDU session upon receiving this notification. In one example, the older AMF 155 can use Nudm_SDM_unsubscribe922 to unsubscribe from UDM 140 for subscription data.

[0197] In one example, if AMF 155 decides to initiate PCF 135 communication, for example, if AMF 155 has not yet obtained the access and mobility policy of UE 100, or if the access and mobility policy in AMF 155 is no longer valid, AMF 155 can choose 925 PCF 135. If the new AMF 155 receives a PCF ID from the old AMF 155 and successfully contacts the PCF 135 identified by the PCF ID, then AMF 155 can choose the (V-)PCF identified by the PCF ID. If the PCF 135 identified by the PCF ID may not be used (e.g., there is no response from PCF 135), or if no PCF ID is received from the old AMF 155, then AMF 155 can choose 925 PCF 135.

[0198] In one example, the new AMF 155 can perform policy association establishment 930 during the registration process. If the new AMF 155 contacts the PCF 135 identified by a (V-)PCF ID received during movement between AMFs 155, the new AMF 155 can include the PCF-ID in the Npcf_AMPolicyControl Get operation. If the AMF 155 notifies the PCF 135 of movement restrictions (e.g., UE 100 location) for adjustment, or if the PCF 135 updates its own movement restrictions due to certain conditions (e.g., application in use, time and date), the PCF 135 can provide the updated movement restrictions to the AMF 155.

[0199] In one example, PCF 135 can invoke Namf_EventExposure_Subscribe service operation 935 for UE 100 event subscription.

[0200] In one example, AMF 155 can send Nsmf_PDUSession_UpdateSMContext936 to SMF 160. In another example, if the PDU session to be reactivated is included in the registration request, AMF 155 can invoke Nsmf_PDUSession_UpdateSMContext. AMF 155 can send the Nsmf_PDUSession_UpdateSMContext request to the SMF 160 associated with the PDU session to activate the user plane connection of the PDU session. SMF 160 can decide to trigger, for example, intermediate UPF 110 insertion, removal, or PSA modification. In the case of performing intermediate UPF 110 insertion, removal, or relocation for a PDU session not included in the PDU session to be reactivated, the procedure can be executed without N11 and N2 interaction to update the N3 user plane between (R)AN 105 and 5GC. AMF 155 can invoke the Nsmf_PDUSession_ReleaseSMContext service operation to SMF 160 when any PDU session state indicates that it is being released at UE 100. AMF 155 can invoke the Nsmf_PDUSession_ReleaseSMContext service operation to SMF 160 to release any network resources associated with the PDU session.

[0201] In one example, the new AMF 155 can send an N2 AMF 155 Mobility Request 940 to the N3IWF. If the AMF 155 has changed, the new AMF 155 can create an NGAP UE 100 association for the N3IWF connected to UE 100. In one example, the N3IWF can respond to the new AMF 155 with an N2 AMF 155 Mobility Response 940.

[0202] In one example, the new AMF 155 can send a Registration Acceptance 955 to UE 100 (including: 5G-GUTI, registration area, mobility restrictions, PDU session state, allowed NSSAI, [mapped NSSAI], periodic registration update timer, LADN information and accepted MICO mode, indication of IMS voice support via PS session, emergency service support indicator, etc.). In one example, the AMF 155 can send a Registration Acceptance message to UE 100 indicating that the registration request has been accepted. If the AMF 155 has assigned a new 5G-GUTI, it can include the 5G-GUTI. If the AMF 155 has assigned a new registration area, it can send the registration area to UE 100 via the Registration Acceptance message 955. If the registration acceptance message does not include the registration area, UE 100 may consider the old registration area valid. In one example, mobility restrictions can be included if mobility restrictions are applicable to UE 100 and the registration type may not be emergency registration. AMF 155 can indicate the established PDU session to UE 100 in the PDU session state. UE 100 can locally remove any internal resources associated with a PDU session not marked as established in the received PDU session state. In one example, when UE 100 is connected to two AMF 155s belonging to different PLMNs via 3GPP access and non-3GPP access, UE 100 can locally remove any internal resources associated with the current PLMN's PDU session that are not marked as established in the received PDU session state. If PDU session state information is in the registration request, AMF 155 can indicate the PDU session state to the UE. The mapping of allowed NSSAIs can be a mapping of each S-NSSAI in the allowed NSSAIs of the HPLMN to an S-NSSAI in the configured NSSAIs. AMF 155 can include LADN information of the LADN in the registration acceptance message 955, the LADN being available in the registration area determined by AMF 155 for the UE. If UE 100 includes MICO mode in its request, AMF 155 can respond to whether MICO mode can be used. AMF 155 can set an indication to support IMS voice via PS session. In one example, to set the indication to support IMS voice via PS session, AMF 155 can execute a UE / RAN radio information and compatibility request procedure to check the compatibility of UE 100 and RAN radio capabilities related to IMS voice via PS. In one example, an emergency service support indicator can notify UE 100 to support emergency services; for example, UE 100 can request emergency services via a PDU session. In one example, a handover restriction list and UE-AMBR can be provided to the NG-RAN by AMF 155.

[0203] In one example, UE 100 may send a Registration Complete 960 message to the new AMF 155. In another example, UE 100 may send a Registration Complete 960 message to AMF 155 to confirm that a new 5G-GUTI can be allocated. In one example, when information about the PDU session to be reactivated is not included in the registration request, AMF 155 may release the signaling connection with UE 100. In another example, when a subsequent request is included in the registration request, AMF 155 may not release the signaling connection after the registration procedure is completed. In yet another example, if AMF 155 is aware that some signaling is pending in AMF 155 or between UE 100 and 5GC, AMF 155 may not release the signaling connection after the registration procedure is completed.

[0204] As shown in the example Figure 10 and Figure 11 As described, a service request procedure (e.g., a service request procedure triggered by UE 100) can be used by UE 100 in CM-IDLE state to request the establishment of a secure connection to AMF 155. Figure 11 It describes the service request procedure. Figure 10 The following diagram continues. The service request procedure can be used to activate user plane connectivity for established PDU sessions. The service request procedure can be triggered by UE 100 or 5GC, and can be used when UE 100 is in CM-IDLE and / or CM-CONNECTED, and can allow selective activation of user plane connectivity for some established PDU sessions.

[0205] In one example, UE 100 in CM IDLE state can initiate a service request procedure to send uplink signaling messages, user data, etc., in response to a network paging request, and so on. In one example, after receiving a service request message, AMF 155 can perform authentication. In one example, after establishing a signaling connection to AMF 155, UE 100 or the network can send signaling messages such as PDU session establishment from UE 100 to SMF 160 via AMF 155.

[0206] In one example, for any service request, the AMF 155 can respond with a service accept message to synchronize the PDU session state between UE 100 and the network. If the service request may not be accepted by the network, the AMF 155 can respond to UE 100 with a service deny message. The service deny message may include an instruction or reason code requesting UE 100 to perform a registration update procedure. In one example, for a service request arising from user data, if user plane connection activation may fail, the network can take further action. (Example...) Figure 10 and Figure 11 In this context, more than one UPF may be involved, such as the old UPF 110-2 and PDU session anchor PSA UPF 110-3.

[0207] In one example, UE 100 may send an AN message to (R)AN 105, which includes AN parameters, mobility management, MM NAS service request 1005 (e.g., a list of PDU sessions to be activated, a list of allowed PDU sessions, security parameters, PDU session status, etc.), etc. In one example, when UE 100 can reactivate a PDU session, UE 100 may provide a list of PDU sessions to be activated. When the service request may be a response to a paging or NAS notification, the list of allowed PDU sessions may be provided by UE 100, and may identify the access that can be transmitted to or the PDU session that can be associated with said access. In one example, for the NG-RAN case, AN parameters may include the selected PLMNID and establishment reason. The establishment reason may provide the reason for requesting to establish an RRC connection. UE 100 may send a NAS service request message to RAN 105 for AMF 155 encapsulated in an RRC message.

[0208] In one example, if a service request can be triggered for user data, UE 100 can use a list of PDU sessions to be activated to identify the PDU sessions for which an UP connection will be activated in the NAS service request message. If a service request can be triggered by signaling, UE 100 may not be able to identify any PDU sessions. If this procedure can be triggered by a paging response, and / or UE 100 can simultaneously have user data to be transmitted, UE 100 can use a list of PDU sessions to be activated to identify the PDU sessions for which its UP connection can be activated in the MM NAS service request message.

[0209] In one example, if a service request for 3GPP access can be triggered in response to a paging indicating non-3GPP access, the NAS service request message can identify a list of PDU sessions associated with non-3GPP access that can be reactivated via 3GPP in the list of allowed PDU sessions. In one example, the PDU session status can indicate the PDU sessions available in UE 100. In one example, when UE 100 is outside the availability area of ​​the LADN, UE 100 may not trigger a service request procedure for the PDU session corresponding to the LADN. If a service request can be triggered for other reasons, UE 100 may not be able to identify such PDU sessions in the list of PDU sessions to be activated.

[0210] In one example, (R)AN 105 can send an N2 message 1010 (e.g., a service request) to AMF 155, including N2 parameters, MM NAS service requests, etc. If AMF 155 may not be able to process the service request, it can reject the N2 message. In one example, if NG-RAN is available, the N2 parameters may include 5G-GUTI, the selected PLMN ID, location information, RAT type, establishment reason, etc. In one example, the 5G-GUTI can be obtained in the RRC procedure, and (R)AN 105 can select AMF 155 based on the 5G-GUTI. In one example, the location information and RAT type may relate to the cell where UE 100 can camp. In one example, based on the PDU session state, AMF 155 can initiate a PDU session release procedure in the network for PDU sessions whose PDU session IDs can be indicated as unavailable by UE 100.

[0211] In one example, if a service request is not sent with integrity protection or integrity protection verification fails, the AMF 155 can initiate NAS authentication / security procedure 1015.

[0212] In one example, if UE 100 triggers a service request to establish a signaling connection, then after the signaling connection is successfully established, UE 100 and the network can exchange NAS signaling.

[0213] In one example, AMF 155 can send a PDU session update context request 1020 to SMF 160, such as an Nsmf_PDUSession_UpdateSMContext request that includes the PDU session ID, reason, UE 100 location information, access type, etc.

[0214] In one example, if UE 100 can identify a PDU session to be activated in the NAS service request message, the Nsmf_PDUSession_UpdateSMContext request can be invoked by AMF 155. In another example, the Nsmf_PDUSession_UpdateSMContext request can be triggered by SMF 160, where the PDU session identified by UE 100 can be associated with a different PDU session ID than the one that triggered the procedure. In yet another example, the Nsmf_PDUSession_UpdateSMContext request can be triggered by SMF 160, where the current UE 100 location is outside the valid area of ​​the N2 information provided by SMF 160 during the network-triggered service request procedure. AMF 155 may choose not to send the N2 information provided by SMF 160 during the network-triggered service request procedure.

[0215] In one example, AMF 155 can identify the PDU session to be activated and can send an Nsmf_PDUSession_UpdateSMContext request to the SMF 160 associated with the PDU session, where the reason is set to indicate the establishment of user plane resources for the PDU session.

[0216] In one example, if the procedure can be triggered in response to a paging indicating non-3GPP access, and the list of allowed PDU sessions provided by UE100 may not include PDU sessions that have been paged for UE100, then AMF 155 may notify SMF 160 that the user plane of the PDU session may not be reactivated. The service request procedure may succeed without reactivating the user plane of any PDU session, and AMF 155 may notify UE100.

[0217] In one example, if the PDU session ID corresponds to an LADN, and SMF 160 determines that UE 100 may be outside the availability zone of the LADN based on the UE 100 location reported from AMF 155, then SMF 160 may decide (based on local policy) to maintain the PDU session, may refuse to activate the user plane connection for the PDU session, and may notify AMF 155. In another example, if the procedure can be triggered by a network-triggered service request, then SMF 160 may instruct the UPF 110 initiating the data notification to abandon downlink data for the PDU session and / or not provide additional data notification messages. SMF 160 may respond to AMF 155 with an appropriate rejection reason and may stop user plane activation of the PDU session.

[0218] In one example, if the PDU session ID corresponds to an LADN, and the SMF 160 determines that UE 100 may be outside the availability zone of the LADN based on the UE 100 location reported from the AMF 155, then the SMF 160 may decide (based on local policy) to release the PDU session. The SMF 160 can release the PDU session locally and can notify the AMF 155 that the PDU session can be released. The SMF 160 can respond to the AMF 155 with an appropriate rejection reason and can stop user plane activation of the PDU session.

[0219] In one example, if SMF 160 can accept UP activation for a PDU session, then based on the location information received from AMF 155, SMF 160 can check the UPF 110 selection criteria (e.g., slice isolation requirements, slice coexistence requirements, UPF 110 dynamic load, relative static capacity of UPF 110 among UPFs supporting the same DNN, UPF 110 location available at SMF 160, UE 100 location information, UPF 110 capabilities, and the functionalities required for a specific UE 100 session). In one example, the appropriate UPF 110 can be determined by matching the functionalities and characteristics required by UE 100, DNN, PDU session type (e.g., IPv4, IPv6, Ethernet type, or unstructured type), and (if applicable) static IP address / prefix, SSC mode selected for the PDU session, UE 100 subscription profile in UDM 140, including DNAI in PCC rules, local operator policies, S-NSSAI, and other factors by the UE. The UE 100 may select (the access technology used, the logical topology of UPF 110, etc.) and may determine to perform one or more of the following: continue using the current UPF; if the UE 100 has moved out of the service area of ​​the UPF 110 previously connected to (R)AN 105 while maintaining the UPF acting as the PDU session anchor, a new intermediate UPF 110 may be selected (or an intermediate UPF 110 may be added / removed); a PDU session re-establishment may be triggered to perform the relocation / reassignment of the UPF 110 acting as the PDU session anchor, for example, if the UE 100 has moved out of the service area of ​​the anchor UPF 110 connected to RAN 105.

[0220] In one example, SMF 160 can send an N4 session establishment request 1030 to UPF 110 (e.g., a new intermediate UPF 110). In one example, if SMF 160 can choose to use the new UPF 110 as the intermediate UPF 110-2 for a PDU session, or if SMF 160 can choose to insert an intermediate UPF 110 for a PDU session that may not have an intermediate UPF 110-2, an N4 session establishment request 1030 message can be sent to the new UPF 110, thereby providing packet inspection, data forwarding, enforcement, and reporting rules to be installed on the new intermediate UPF. The PDU session anchor addressing information (on N9) for this PDU session can be provided to the intermediate UPF 110-2.

[0221] In one example, if SMF 160 selects the new UPF 110 to replace the old (intermediate) UPF 110-2, SMF 160 may include a data forwarding indication. The data forwarding indication may tell UPF 110 that a second tunnel endpoint may be reserved for buffered DL data from the old I-UPF.

[0222] In one example, the new (intermediate) UPF 110 can send an N4 session establishment response message 1030 to the SMF 160. If the UPF 110 can allocate CN tunnel information, it can provide the SMF 160 with the DL CN tunnel information of the UPF 110 used as a PDU session anchor, as well as the UL CN tunnel information (e.g., CN N3 tunnel information). If a data forwarding indication is received, the new (intermediate) UPF 110, acting as an N3 endpoint, can send the DL CN tunnel information of the old (intermediate) UPF 110-2 to the SMF 160. The SMF 160 can start a timer to release resources in the old intermediate UPF 110-2.

[0223] In one example, if SMF 160 can select a new intermediate UPF 110 for the PDU session, or can remove the old I-UPF 110-2, then SMF 160 can send an N4 session modification request message 1035 to the PDU session anchor PSA UPF 110-3, thereby providing data forwarding instructions and DL tunnel information from the new intermediate UPF 110.

[0224] In one example, if a new intermediate UPF 110 can be added to the PDU session, then (PSA) UPF 110-3 can begin sending DL data to the new I-UPF 110, as indicated by the DL tunnel information.

[0225] In one example, if the service request can be triggered by the network, and the SMF 160 can remove the old I-UPF 110-2 without replacing it with a new I-UPF 110, then the SMF 160 can include a data forwarding indication in the request. This data forwarding indication can tell the (PSA) UPF 110-3 that a second tunnel endpoint can be reserved for buffered DL data from the old I-UPF 110-2. In this case, the PSA UPF 110-3 can begin buffering DL data that it may simultaneously receive from the N6 interface.

[0226] In one example, PSA UPF 110-3 (PSA) can send an N4 session modification response 1035 to SMF 160. In another example, if a data forwarding indication is received, PSA UPF 110-3 can become an N3 endpoint and can send CN DL tunnel information for the old (intermediate) UPF 110-2 to SMF 160. SMF 160 can start a timer to release any resources in the old intermediate UPF 110-2.

[0227] In one example, the SMF 160 can send an N4 session modification request 1045 to the old UPF 110-2 (e.g., this may include the new UPF 110 address, the new UPF 110 DL tunnel ID, etc.). In another example, if the service request can be triggered by the network, and / or the SMF 160 can remove the old (intermediate) UPF 110-2, then the SMF 160 can send an N4 session modification request message to the old (intermediate) UPF 110-2 and can provide DL tunnel information for buffered DL data. If the SMF 160 can allocate a new I-UPF 110, the DL tunnel information comes from the new (intermediate) UPF 110 that can be used as the N3 endpoint. If the SMF 160 can not allocate a new I-UPF 110, the DL tunnel information can come from the new UPF 110 (PSA) 110-3 used as the N3 endpoint. The SMF 160 can start a timer to monitor the forwarding tunnel. In one example, the old (intermediate) UPF 110-2 can send an N4 session modification response message to the SMF160.

[0228] In one example, if I-UPF 110-2 can be relocated and a forwarding tunnel is established to the new I-UPF 110, then the old (intermediate) UPF 110-2 can forward its buffered data to the new (intermediate) UPF 110, which will serve as the N3 endpoint. In another example, if the old I-UPF 110-2 may be removed, and the new I-UPF 110 may not be allocated for a PDU session, and a forwarding tunnel may be established to UPF 110(PSA) 110-3, then the old (intermediate) UPF 110-2 can forward its buffered data to UPF 110(PSA) 110-3, which will serve as the N3 endpoint.

[0229] In one example, upon receiving an Nsmf_PDUSession_UpdateSMContext request with a reason (including, for example, the establishment of user plane resources), SMF 160 may send an N11 message 1060 to AMF 155, such as an Nsmf_PDUSession_UpdateSMContext response (including an N1 SM container (PDU session ID, PDU session re-establishment indication), N2 SM information (PDU session ID, QoS profile, CN N3 tunnel information, S-NSSAI), and a reason). SMF 160 may determine whether a UPF 110 reallocation can be performed based on UE 100 location information, UPF 110 service area, and operator policies. In one example, for a PDU session that can be determined to be served by the current UPF 110 (e.g., a PDU session anchor or intermediate UPF) serving SMF 160, SMF 160 may generate N2 SM information and may send an Nsmf_PDUSession_UpdateSMContext response 1060 to AMF 155 to establish a user plane. The N2 SM information may contain information that AMF 155 can provide to RAN 105. In one example, for a PDU session that SMF 160 determines requires UPF 110 to relocate the PDU session anchor UPF, SMF 160 can refuse to activate the UP for the PDU session by sending an Nsmf_PDUSession_UpdateSMContext response containing an N1 SM container to UE 100 via AMF 155. The N1 SM container may include the corresponding PDU session ID and a PDU session re-establishment indication.

[0230] Upon receiving a Namf_EventExposure_Notify from AMF 155 to SMF 160 indicating that UE 100 is reachable, if SMF 160 may have pending DL data, SMF 160 may invoke the Namf_Communication_N1N2MessageTransfer service operation to AMF 155 to establish a user plane for a PDU session. In one example, in the case of DL data, SMF 160 may continue sending DL data notifications to AMF 155.

[0231] In one example, if the PDU session corresponds to an LADN and UE 100 may be outside the availability zone of the LADN, or if AMF 155 can notify SMF 160 that UE 100 is reachable for regulated priority services and the PDU session to be activated may not be used for regulated priority services; or if SMF 160 may decide to perform PSA UPF 110-3 relocation for the requested PDU session, then SMF 160 can send a message to AMF 155 to refuse the UP activation of the PDU session by including a reason in the Nsmf_PDUSession_UpdateSMContext response.

[0232] In one example, AMF 155 may send an N2 request message 1065 to (R)AN 105 (e.g., N2 SM information received from SMF 160, security context, AMF 155 signaling connection ID, handover restriction list, MM NAS service acceptance, and a list of recommended cell / TA / NG-RAN node identifiers). In one example, RAN 105 may store the security context, AMF 155 signaling connection ID, QoS information of the QoS flow for the PDU session that can be activated, and the N3 tunnel ID in the UE 100 RAN 105 context. In one example, the MM NAS service acceptance may include the PDU session state in AMF 155. If SMF 160 may refuse to activate the UP of the PDU session, the MM NAS service acceptance may include the PDU session ID and the reason why the user plane resource may not be activated (e.g., LADN is unavailable). The release of the local PDU session during the session request procedure can be indicated to UE 100 via the session state.

[0233] In one example, if there is a number of PDU sessions that may involve multiple SMF 160s, the AMF 155 may not wait for responses from all SMF 160s before it can send N2 SM information to the UE 100. The AMF 155 may wait for all responses from the SMF 160s before it can send an MM NAS service accept message to the UE 100.

[0234] In one example, if a procedure can be triggered for PDU session user plane activation, the AMF 155 may include at least one N2 SM information from the SMF 160. The AMF 155 may send additional N2 SM information from the SMF 160 in a separate N2 message (e.g., an N2 tunnel setup request, if present). Alternatively, if multiple SMFs 160s may be involved, the AMF 155 may send an N2 request message to the (R)AN 105 after receiving all Nsmf_PDUSession_UpdateSMContext response service operations from all SMFs 160s associated with the UE 100. In this case, the N2 request message may include the N2 SM information received in each Nsmf_PDUSession_UpdateSMContext response and the PDU session ID, enabling the AMF 155 to associate the response with the relevant SMF 160.

[0235] In one example, if the RAN 105 (e.g., NG RAN) node can provide a list of recommended cell / TA / NG-RAN node identifiers during the AN release procedure, the AMF 155 can include information from that list in the N2 request. RAN 105 can use this information to allocate RAN 105 notification areas when it may decide to enable RRC inactivity for UE 100.

[0236] If AMF 155 can receive from SMF 160 during the PDU session establishment procedure an indication that UE 100 may be using a PDU session related to a latency-sensitive service for any PDU session established for UE 100, and AMF 155 has received from UE 100 an indication that CM-CONNECTED can be supported in an RRC inactivity state, then AMF 155 may include the UE's RRC inactivity auxiliary information. In one example, AMF 155 based on network configuration may include the UE's RRC inactivity auxiliary information.

[0237] In one example, (R)AN 105 can send a message to UE 100 to perform an RRC connection reconfiguration 1070 with UE 100, depending on the QoS information of all QoS flows of the PDU session for which the UP connection can be activated, as well as the data radio bearer. In one example, user plane security can be established.

[0238] In one example, if the N2 request may include an MM NAS service acceptance message, then RAN 105 can forward the MM NAS service acceptance to UE 100. UE 100 can locally delete the context of a PDU session that may not be available in 5GC.

[0239] In one example, if N1 SM information can be transmitted to UE 100 and indicates that some PDU sessions can be re-established, then UE 100 can initiate PDU session re-establishment for PDU sessions that can be re-established after the service request procedure may be completed.

[0240] In one example, after the user plane radio resources can be configured, uplink data from UE 100 can be forwarded to RAN 105. RAN 105 (e.g., NG-RAN) can then send the uplink data to the provided UPF 110 address and tunnel ID.

[0241] In one example, (R)AN 105 may send an N2 request acknowledgment 1105 to AMF 155 (e.g., N2 SM information including: AN tunnel information, a list of accepted QoS flows for PDU sessions with UP connections active, and a list of rejected QoS flows for PDU sessions with UP connections active)). In one example, the N2 request message may include N2 SM information, such as AN tunnel information. RAN 105 may respond to the N2 SM information with a separate N2 message (e.g., an N2 tunnel setup response). In one example, if multiple N2 SM information items are included in the N2 request message, the N2 request acknowledgment may include multiple N2 SM information items and information that enables AMF 155 to associate the response with the relevant SMF 160.

[0242] In one example, AMF 155 can send an Nsmf_PDUSession_UpdateSMContext request 1110 (N2 SM information (AN tunnel information), RAT type) per PDU session to SMF 160. If AMF 155 can receive N2 SM information (one or more) from RAN 105, AMF 155 can forward the N2 SM information to the relevant SMF 160. If the UE 100 timezone may have changed compared to the last reported UE 100 timezone, AMF 155 can include the UE 100 timezone IE in the Nsmf_PDUSession_UpdateSMContext request message.

[0243] In one example, if a dynamic PCC is deployed, the SMF 160 can notify the PCF 135 of new location information (if subscribed) by invoking an event exposure notification operation (e.g., the Nsmf_EventExposure_Notify service operation). The PCF 135 can provide updated policies by invoking a policy control update notification message 1115 (e.g., the Npcf_SMPolicyControl_UpdateNotify operation).

[0244] In one example, if SMF 160 can select a new I-UPF 110 to act as the intermediate I-UPF 110 for the PDU session, then SMF 160 can initiate an N4 session modification procedure 1120 to the new I-UPF 110 and can provide AN tunneling information. Downlink data from the new I-UPF 110 can be forwarded to RAN 105 and UE 100. In one example, UPF 110 can send an N4 session modification response 1120 to SMF 160. In another example, SMF 160 can send an Nsmf_PDUSession_UpdateSMContext response 1140 to AMF 155.

[0245] In one example, if a forwarding tunnel to the new I-UPF 110 can be established, and if the timer set for the forwarding tunnel, SMF 160, may expire, SMF 160 can send an N4 session modification request 1145 to the new (intermediate) UPF 110, which serves as the N3 termination point, to release the forwarding tunnel. In one example, the new (intermediate) UPF 110 can send an N4 session modification response 1145 to SMF 160. In one example, SMF 160 can send an N4 session modification request 1150 or an N4 session release request to PSA UPF 110-3. In one example, if SMF 160 can continue to use the old UPF 110-2, SMF 160 can send an N4 session modification request 1155, thereby providing AN tunnel information. In one example, if SMF 160 can select a new UPF 110 as the intermediate UPF 110, and the old UPF 110-2 may not be PSA UPF 110-3, then SMF 160 can initiate resource release after the timer expires by sending an N4 session release request (release reason) to the old intermediate UPF 110-2.

[0246] In one example, the legacy intermediate UPF 110-2 can send an N4 session modification response or an N4 session release response 1155 to the SMF 160. The legacy UPF 110-2 can use the N4 session modification response or N4 session release response message to acknowledge the modification or release of the resource. The AMF 155 can invoke the Namf_EventExposure_Notify service operation to notify NFs that may have subscribed to the event of the move-related event upon the completion of this procedure. In one example, if SMF 160 has subscribed to UE 100 moving into or out of its region of interest and if the UE's current location indicates that it may be moving into or out of its subscribed region of interest, or if SMF 160 has subscribed to LADN DNN and if UE 100 may be moving into or out of an area where LADN is available, or if UE 100 may be in MICO mode and AMF 155 has notified UE 100 that SMF 160 is unreachable and SMF 160 may not send DL data notifications to AMF 155, and AMF 155 can notify SMF 160 that UE 100 is reachable, then AMF 155 can call Namf_EventExposure_Notify on SMF 160. Alternatively, if SMF 160 has subscribed to UE 100's reachability status, then AMF 155 can notify UE 100 of its reachability.

[0247] exist Figure 12 and Figure 13The document describes an example PDU session establishment procedure. In one exemplary implementation, when a PDU session establishment procedure is available, UE 100 may send a NAS message 1205 (or an SM NAS message) to AMF 155. This NAS message includes NSSAI, S-NSSAI (e.g., requested S-NSSAI, allowed S-NSSAI, subscribed S-NSSAI, etc.), DNN, PDU session ID, request type, old PDU session ID, N1 SM container (PDU session establishment request), etc. In one example, UE 100 may generate a new PDU session ID to establish a new PDU session. In one example, when emergency service may be required and an emergency PDU session may not yet be established, UE 100 may initiate a UE 100-requested PDU session establishment procedure, where the request type indicates an emergency request. In one example, UE 100 may initiate a UE 100-requested PDU session establishment procedure by transmitting a NAS message containing a PDU session establishment request within the N1 SM container. PDU session establishment requests may include PDU type, SSC mode, protocol configuration options, etc. In one example, if the PDU session establishment is a request to establish a new PDU session, the request type may indicate an initial request, and if the request involves an existing PDU session between 3GPP access and non-3GPP access or an existing PDN connection in an EPC, the request type may indicate an existing PDU session. In one example, if the PDU session establishment could be a request to establish a PDU session for emergency services, the request type may indicate an emergency request. If the request involves an existing PDU session for emergency services between 3GPP access and non-3GPP access, the request type may indicate an existing emergency PDU session. In one example, a NAS message sent by UE 100 may be encapsulated in an AN within an N2 message sent to AMF 155, which may include user location information and access technology type information. In one example, a PDU session establishment request message may contain an SM PDU DN request container containing information about external DN authorization for the PDU session. In one example, if the procedure can be triggered for SSC Mode 3 operation, then UE 100 can include the old PDU session ID in the NAS message, which can indicate the PDU session ID of the ongoing PDU session to be released. The old PDU session ID can be an optional parameter that can be included in this case. In one example, AMF155 can receive NAS messages (e.g., NAS SM messages) and user location information (e.g., cell ID in the case of RAN 105) from AN.In one example, when UE 100 is outside the availability zone of LADN, UE 100 may not trigger the establishment of a PDU session corresponding to the LADN PDU session.

[0248] In one example, AMF 155 can determine whether a NAS message or an SM NAS message corresponds to a request for a new PDU session based on the request type indicating an initial request and the PDU session ID not being used for any existing PDU session of UE 100. If the NAS message does not contain an S-NSSAI, AMF 155 can determine the default S-NSSAI for the requested PDU session based on UE 100 subscriptions (if it can contain only one default S-NSSAI) or based on operator policies. In one example, AMF 155 can perform SMF 160 selection 1210 and select SMF 160. If the request type indicates an initial request or the request can be attributed to a handover from EPS, AMF 155 can store the S-NSSAI association, the PDU session ID, and the SMF 160 ID. In one example, if the request type is an initial request, and if the old PDU session ID indicating an existing PDU session can be included in the message, the AMF 155 can select the SMF 160 and can store the association between the new PDU session ID and the selected SMF 160 ID.

[0249] In one example, AMF 155 can send N11 message 1215 to SMF 160, such as Nsmf_PDUSession_CreateSMContext request (including: SUPI or PEI, DNN, S-NSSAI, PDU session ID, AMF 155 ID, request type, N1 SM container (PDU session establishment request), user location information, access type, PEI, GPSI), or Nsmf_PDUSession_UpdateSMContext request (SUPI, DNN, S-NSSAI, PDU session ID, AMF 155 ID, request type, N1 SM container (PDU session establishment request), user location information, access type, RAT type, PEI). In one example, if AMF 155 may not be associated with SMF 160 of the PDU session ID provided by UE 100 (e.g., when the request type indicates an initial request), AMF 155 can invoke the Nsmf_PDUSession_CreateSMContext request. However, if AMF 155 is already associated with SMF 160 of the PDU session ID provided by UE 100 (e.g., when the request type indicates an existing PDU session), AMF 155 can invoke the Nsmf_PDUSession_UpdateSMContext request. In one example, the AMF 155 ID can be the UE's GUAMI, which uniquely identifies the AMF 155 serving UE 100. AMF 155 can forward the PDU session ID along with the N1 SM container containing the PDU session establishment request received from UE 100. When UE 100 has registered for emergency services but does not provide SUPI, AMF 155 can provide PEI instead of SUPI. If UE 100 has registered for emergency services but has not yet been certified, AMF 155 can indicate that SUPI has not yet been certified.

[0250] In one example, if the request type may not indicate an urgent request or an existing urgent PDU session, and if SMF 160 has not yet registered and subscription data may be unavailable, SMF 160 may register with UDM 140 and may retrieve subscription data 1225 and be notified when subscription data can be modified. In one example, if the request type may indicate an existing PDU session or an existing urgent PDU session, SMF 160 may determine that the request is attributable to a handover between 3GPP access and non-3GPP access, or to a handover from EPS. SMF 160 may identify an existing PDU session based on the PDU session ID. SMF 160 may update an existing SM context instead of creating a new SM context, and may provide an updated representation of the SM context to AMF 155 in the response. If the request type may be an initial request, and if the old PDU session ID can be included in the Nsmf_PDUSession_CreateSMContext request, SMF 160 may identify the existing PDU session to be released based on the old PDU session ID.

[0251] In one example, SMF 160 can send N11 message response 1220 to AMF 155, such as a PDU session creation / update response, Nsmf_PDUSession_CreateSMContext response 1220 (reason, SM context ID or N1 SM container (PDU session rejected (reason))) or Nsmf_PDUSession_UpdateSMContext response.

[0252] In one example, if SMF 160 can perform secondary authorization / authentication 1230 during the establishment of a PDU session by the DN-AAA server, then SMF 160 can choose UPF 110 and can trigger PDU session establishment authentication / authorization.

[0253] In one example, if the request type indicates an initial request, the SMF 160 can select the SSC mode for the PDU session. The SMF 160 can select one or more UPFs as needed. In the case of an IPv4 or IPv6 PDU, the SMF 160 can assign an IP address / prefix to the PDU session. In the case of an IPv6 PDU, the SMF 160 can assign an interface identifier to the UE 100 so that the UE 100 can construct its link-local address. For unstructured PDU types, the SMF 160 can assign an IPv6 prefix to the PDU session and the N6 point-to-point tunnel (based on UDP / IPv6).

[0254] In one example, if a dynamic PCC is deployed, the SMF 160 can perform PCF 135 selection 1235. If the request type indicates an existing PDU session or an existing emergency PDU session, the SMF 160 can use PCF 135 already selected for the PDU session. If a dynamic PCC is not deployed, the SMF 160 can apply a local policy.

[0255] In one example, SMF 160 can execute Session Management Policy Establishment Procedure 1240 to establish a PDU session with PCF 135 and obtain the default PCC rules for the PDU session. GPSI can be included if available at SMF 160. If the request type in 1215 indicates an existing PDU session, SMF 160 can notify of events previously subscribed to by PCF 135 via the Session Management Policy Modification Procedure, and PCF 135 can update the policy information in SMF 160. PCF 135 can provide SMF 160 with an authorized session—AMBR—and authorized 5QI and ARP. PCF 135 can subscribe to IP allocation / release events in SMF 160 (and can subscribe to other events).

[0256] In one example, PCF 135, based on the Emergency DNN, can set the ARP of the PCC rule to a value that can be reserved for emergency services.

[0257] In one example, if the request type in 1215 indicates an initial request, the SMF 160 can select the SSC mode for the PDU session. The SMF 160 can select one or more UPFs in 1245 as needed. In the case of an IPv4 or IPv6 PDU, the SMF 160 can assign an IP address / prefix to the PDU session. In the case of an IPv6 PDU, the SMF 160 can assign an interface identifier to the UE 100 so that the UE 100 can construct its link-local address. For unstructured PDU types, the SMF 160 can assign an IPv6 prefix (e.g., based on UDP / IPv6) to the PDU session and the N6 point-to-point tunnel. In one example, for a PDU session of the Ethernet PDU type, the SMF 160 cannot assign either a MAC address or an IP address to the UE 100 for this PDU session.

[0258] In one example, if the request type in 1215 is an existing PDU session, then SMF 160 can maintain the same IP address / prefix that can be assigned to UE 100 in the source network.

[0259] In one example, if the request type in 1215 indicates an existing PDU session involving movement between 3GPP access and non-3GPP access, then SMF 160 can maintain the SSC mode of the PDU session, such as the current PDU session anchor and IP address. In one example, SMF 160 can trigger, for example, the insertion of a new intermediate UPF 110 or the allocation of a new UPF 110. In one example, if the request type indicates an urgent request, then SMF 160 can select 1245 UPF 110 and can select SSC mode 1.

[0260] In one example, the SMF 160 can execute a session management policy modification procedure 1250 to report certain events to a previously subscribed PCF 135. If the request type is an initial request, a dynamic PCC is deployed, and the PDU type is IPv4 or IPv6, the SMF 160 can notify the (previously subscribed) PCF 135 of the UE's assigned IP address / prefix.

[0261] In one example, the PCF 135 can provide updated policies to the SMF 160. The PCF 135 can provide the SMF 160 with authorized sessions - AMBR and authorized 5QI and ARP.

[0262] In one example, if the request type indicates an initial request, the SMF 160 can initiate an N4 session establishment procedure 1255 with the selected UPF 110. The SMF 160 can also initiate an N4 session modification procedure with the selected UPF 110. In one example, the SMF 160 can send an N4 session establishment / modification request 1255 to the UPF 110 and can provide packet detection, execution, reporting rules, etc., to be installed on the UPF 110 for this PDU session. If CN tunneling information is allocated by the SMF 160, it can be provided to the UPF 110. If this PDU session requires selective user plane deactivation, the SMF 160 can determine an inactivity timer and provide it to the UPF 110. In one example, the UPF 110 can acknowledge this by sending an N4 session establishment / modification response 1255. If CN tunneling information is allocated by the UPF, it can be provided to the SMF 160. In one example, if multiple UPFs are selected for a PDU session, then SMF 160 can initiate an N4 session creation / modification procedure 1255 with each UPF 110 of the PDU session.

[0263] In one example, SMF 160 can send a Namf_Communication_N1N2MessageTransfer 1305 message to AMF 155 (including PDU session ID, access type, N2 SM information (PDU session ID, QFI, QoS profile, CN tunnel information, S-NSSAI, session-AMBR, PDU session type, etc.) and N1 SM container (PDU session establishment acceptance (QoS rules, selected SSC mode, S-NSSAI, assigned IPv4 address, interface identifier, session-AMBR, selected PDU session type, etc.))). In cases where multiple UPFs are used for a PDU session, the CN tunnel information may include tunnel information related to the UPF110 terminating N3. In one example, the N2 SM message may carry information that the AMF 155 can forward to the (R)AN 105 (e.g., CN tunnel information corresponding to the core network address of the N3 tunnel corresponding to the PDU session, one or more QoS profiles and corresponding QFIs may be provided to the (R)AN 105, the PDU session ID may indicate the association between AN resources and the PDU session for UE100 via AN signaling with UE100, etc.). In one example, the PDU session may be associated with S-NSSAI and DNN. In one example, the N1 SM container may contain PDU session establishment acceptance that the AMF 155 can provide to UE100. In one example, multiple QoS rules and QoS profiles may be included in the PDU session establishment acceptance within the N1 SM and the N2 SM message. In one example, Namf_Communication_N1N2MessageTransfer 1305 may also include the PDU session ID and information that allows the AMF 155 to know which access is used for UE100.

[0264] In one example, AMF 155 may send an N2 PDU session request 1310 to (R)AN 105 (including N2 SM information, NAS messages (PDU session ID, N1 SM container (PDU session establishment acceptance, etc.))). In another example, AMF 155 may send a NAS message 1310 to (R)AN 105, which may include a PDU session ID and a PDU session establishment acceptance for UE 100, as well as the N2 SM information received from SMF 160 within the N2 PDU session request 1310.

[0265] In one example, (R)AN 105 can issue an AN-specific signaling exchange 1315 with UE 100, which can be related to information received from SMF 160. In one example, in the case of 3GPP RAN 105, an RRC connection reconfiguration procedure can be performed with UE 100 to establish the necessary RAN 105 resources related to the QoS rules of PDU session request 1310. In one example, (R)AN 105 can allocate (R)AN 105 N3 tunnel information for the PDU session. In the case of dual connectivity, the primary RAN 105 node can allocate some (zero or more) QFIs to be configured to the primary RAN 105 node and allocate other QFIs to the secondary RAN 105 node. The AN tunnel information can include the tunnel endpoints of each involved RAN 105 node and the QFIs allocated to each tunnel endpoint. The QFIs can be allocated to either the primary RAN 105 node or the secondary RAN 105 node. In one example, (R)AN 105 can forward NAS message 1310 (PDU session ID, N1 SM container (PDU session establishment accepted)) to UE 100. If the necessary RAN 105 resources are established and (R)AN 105 tunnel information is successfully allocated, (R)AN 105 can provide the NAS message to UE 100.

[0266] In one example, the N2 PDU session response 1320 may include the PDU session ID, reason, N2 SM information (PDU session ID, AN tunnel information, list of accepted / rejected QFIs), etc. In one example, the AN tunnel information may correspond to the access network address of the N3 tunnel corresponding to the PDU session.

[0267] In one example, AMF 155 can forward N2 SM information received from (R)AN 105 to SMF 160 via Nsmf_PDUSession_UpdateSMContext request 1330 (which includes N2 SM information, request type, etc.). In one example, if the list of rejected QFIs is included in the N2 SM information, SMF 160 can release the QoS profile associated with the rejected QFIs.

[0268] In one example, SMF 160 can initiate an N4 session modification procedure 1335 with UPF 110. SMF 160 can provide UPF 110 with AN tunnel information and corresponding forwarding rules. In one example, UPF 110 can provide an N4 session modification response 1335 to SMF 160.

[0269] In one example, SMF 160 can send an Nsmf_PDUSession_UpdateSMContext response 1340 (reason) to AMF 155. In another example, SMF 160 can subscribe to UE 100 mobility event notifications (e.g., location reports, UE 100 moving into or out of the region of interest) from AMF 155 after this step by invoking the Namf_EventExposure_Subscribe service operation. For LADN, SMF 160 can subscribe to UE 100 moving into or out of the LADN service area event notification by providing the LADN DNN as an indicator of the region of interest. AMF 155 can forward relevant events subscribed to by SMF 160.

[0270] In one example, SMF 160 can send Nsmf_PDUSession_SMContextStatusNotify (Release) 1345 to AMF 155. In another example, if, during this procedure, the PDU session establishment fails at any time, SMF 160 can notify AMF 155 by invoking Nsmf_PDUSession_SMContextStatusNotify (Release) 1345. SMF 160 can release any N4 sessions created, any PDU session addresses (if assigned) (e.g., IP addresses), and can release the association with PCF 135.

[0271] In one example, with the PDU type being IPv6, the SMF 160 can generate an IPv6 router advertisement 1350, which can then be sent to the UE 100 via the N4 and UPF 110.

[0272] In one example, if a PDU session might not be established, the SMF 160 can use Nudm_SDM_Unsubscribe(SUPI, DNN, S-NSSAI) to unsubscribe from the modifications made by the 1360 to the corresponding (SUPI, DNN, S-NSSAI) session management subscription data when the SMF 160 no longer processes the PDU session for the UE 100. In another example, if a PDU session might not be established, the SMF 160 can use Nudm_UECM_Deregistration(SUPI, DNN, PDU session ID) to unregister from the 1360 for a given PDU session.

[0273] Figure 15This diagram illustrates a service-based architecture for a 5G network involving the interaction of the control plane (CP) and user plane (UP). The illustration depicts the logical connections between nodes and functions, and these connections should not be interpreted as direct physical connections. Radio devices can form radio access network (RAN) connections with base stations that connect to user plane (UP) functions (UPFs) via network interfaces that provide defined interfaces, such as the N3 interface. The UPF can provide logical connections to the data network (DN) via network interfaces such as the N6 interface. The RAN connection between the radio device and the base station can be referred to as the data radio bearer (DRB).

[0274] A DN can be a data network used to provide operator services, third-party services such as the Internet, IP Multimedia Subsystem (IMS), Augmented Reality (AR), and Virtual Reality (VR). In some implementations, a DN can represent an edge computing network or resource, such as a Mobile Edge Computing (MEC) network.

[0275] The wireless device also connects to the AMF via a logical N1 connection. The AMF can handle authentication and authorization of access requests, as well as mobility management functions. The AMF can perform other roles and functions. From a service-based perspective, the AMF can communicate with other core network control plane functions through a service-based interface represented as Namf.

[0276] SMF (Service-Based Function) is a network function that is responsible for allocating and managing IP addresses assigned to wireless devices, as well as selecting UPFs (User-Defined Functions) for traffic associated with specific sessions of wireless devices. Multiple SMFs typically exist in a network, each associated with a corresponding group of wireless devices, base stations, or UPFs. From a service-based perspective, SMFs can communicate with other core network functions through a service-based interface, represented as Nsmf. SMFs can also connect to UPFs through logical interfaces such as network interface N4.

[0277] The Authentication Server Function (AUSF) can provide authentication services to other network functions via a service-based NAUSF interface. Network Exposure Functions (NEFs) can be deployed within a network to allow servers, functions, and other entities (such as those outside the trust domain (carrier network)) to expose services and capabilities within the network. In one such example, the NEF can act as a proxy between an external Application Server (AS) outside the illustrated network and network functions such as PCF, SMF, UDM, and AMF. The external AS can provide information that can be used in parameter settings associated with data sessions. The NEF can communicate with other network functions via a service-based NNEF network interface. The NEF can have interfaces to non-3GPP functions.

[0278] Network repository functions (NRFs) provide network service discovery capabilities. An NRF may be specific to its associated Public Land Mobile Network (PLMN) or network operator. Service discovery allows network functions and wireless devices connected to the network to determine where and how to access existing network functions.

[0279] The PCF can communicate with other network functions through a service-based NPCF interface and can be used to provide policies and rules to other network functions, including those within the control plane. The enforcement and application of these policies and rules may not be the responsibility of the PCF. The responsibility for the PCF to transmit policies to the function it serves can be the responsibility of the AMF or SMF. In one such example, the PCF could transmit policies associated with session management to the SMF. This can be used to allow for a unified policy framework that can be used to manage network behavior.

[0280] The UDM can provide a service-based Nudm interface to communicate with other network functions. The UDM can provide data storage facilities to other network functions. A unified data store allows for a consistent view of network information, ensuring that the most relevant information is available from a single resource to different network functions. This can make it easier to implement other network functions, as they may not need to determine where specific types of data are stored within the network. The UDM can connect to the UDR using an interface such as Nudr. The PCF can be associated with the UDM.

[0281] The PCF can have a direct interface to the UDR, or it can connect to the UDR using a Nudr interface. The UDM can receive requests to retrieve content stored in the UDR, or requests to store content in the UDR. The UDM can handle functions such as credential processing, location management, and subscription management. The UDR can also support authentication credential processing, user identification processing, access authorization, registration / mobility management, subscription management, and Short Message Service (SMS) management. The UDR can be responsible for storing data provided by the UDM. The stored data is associated with policy profile information (which may be provided by the PCF) that manages access permissions to the stored data. In some implementations, the UDR can store policy data as well as user subscription data, which may include any or all of subscription identifiers, security credentials, access and mobility-related subscription data, and session-related data.

[0282] Application Functions (AFs) can represent non-data plane (also known as non-user plane) functions of applications deployed within network operator domains and 3GPP-compliant networks. AFs reside within internal Application Servers (ASs). AFs can interact with other core network functions via service-based Naf interfaces and can access network capability exposure information, as well as provide application information used in decisions such as traffic routing. AFs can also interact with functions such as the PCF to provide application-specific input to policy and policy enforcement decisions. In many cases, AFs may not provide network services to other network functions. AFs can often be considered consumers or users of services provided by other network functions. Applications (application servers) outside the trust domain (operator network) can perform many of the same functions as AFs by using NEFs.

[0283] Wireless devices can communicate with network functions in the Core Network Control Plane (CN-UP) and Core Network User Plane (CN-CP). UPF and Data Network (DN) are part of CN-UP. DN may be outside the Core Network Domain (Cellular Network Domain). (See diagram) Figure 15 In this configuration, the base station is located on the CP-UP side. The base station can provide connectivity for both the CN-CP and CN-UP. The AMF, SMF, AUSF, NEF, NRF, PCF, and UDM can be functions residing within CN-CP 328 and are commonly referred to as control plane functions. If the AF resides in the trusted domain, it can communicate directly with other functions within the CN-CP via the service-based Naf interface. If the AF resides outside the trusted domain, the AM can communicate indirectly with other functions within the CN-CP via the NEF.

[0284] Figures 16 to 20 This involves edge computing. Edge computing (also known as mobile edge computing or MEC) is an evolution of cloud computing that moves application hosting from centralized data centers to the network edge. The network edge is closer to the end user and closer to the data generated by the end user's applications. Edge computing can be considered one of the key pillars for meeting the demanding critical performance indicators of 5G, particularly low latency and bandwidth efficiency. 5G networks are likely to be a key future target environment for MEC deployment. Applications using high data volumes and / or requiring short response times (e.g., virtual reality (VR) games, real-time facial recognition, video surveillance, etc.) may be particularly well-suited for edge computing.

[0285] As will be discussed in more detail below, 5G systems can support edge computing by allowing MEC systems and 5G systems to collaborate and interact for traffic routing and policy control purposes. In the example, an application can operate as an MEC system with an MEC controller and multiple application servers. The MEC controller can be an application function (AF) that interacts with network functions of the 5G system (e.g., Network Exposure Function (NEF), Policy Charging Function (PCF), Session Management Function (SMF), etc.) to influence traffic routing between the application and the wireless device. The wireless device can obtain application-related MEC services by connecting to the MEC system via the 5G system. The 5G system and the MEC system can collaborate to facilitate connections from the wireless device to one or more suitable application servers. One or more application servers can be a central application server, located, for example, in a data center and accessible via the Internet. One or more application servers can be edge application servers located, for example, at the network edge. Edge application servers may be closer to the wireless device. The location of the edge application servers (relative to the central application server) can make them more suitable for certain tasks. For example, in some scenarios, wireless devices may be able to offload computing tasks to edge application servers, where the central application server is too far away for computing offloading.

[0286] Figure 16 An implementation scheme of a system including an application server controller is shown. Wireless devices connect to the core network via a base station. The wireless devices can connect to the core network control plane (CN-CP) via interface N1 and / or interface N2. The wireless devices can connect to the core network user plane (CN-UP) via interface N3.

[0287] CN-UP may include one or more User Plane Functions (UPFs). One or more of these UPFs may be used to connect wireless devices to an Application Server (AS) network. An AS network may include multiple application servers. These application servers may have different locations, such as geographical distribution. For example, there may be a central application server within the AS network and / or one or more application servers located at different edges of the AS network. The AS network may be controlled by an AS controller. The AS controller may be implemented as an Application Function (AF) connected to the core network (e.g., CN CP). The AS controller may also be referred to as an MEC controller and / or an AF controller. The AS controller may be responsible for managing ASs and for locating, relocating, selecting, or reselecting ASs within the AS network. Part of the management performed by the AS controller may involve influencing traffic routing within the core network.

[0288] Figure 17This illustrates segmented management between the cellular network domain and the mobile edge computing (MEC) domain. The Core Network Control Plane (CN-CP) and the Core Network User Plane (CN-UP) can belong to the cellular network domain. A CN-UP can include multiple UPFs, such as UPF {A}, UPF {B}, UPF {C}, UPF {D}, and UPF {E}. The CN-CP can manage the CN-UP. The AS controller and one or more data networks (DNs) can belong to the MEC domain. A DN can be referred to as a data center. As shown, the AS controller can manage multiple application servers, such as application server #1 and application server #2. Application servers can be hosted on different DNs, such as local DN #1 and local DN #2. Optionally, the NEF can manage the link between the cellular network domain and the MEC domain. Although shown separately, the NEF can belong to the CN-CP.

[0289] In the example, the location of the application server can be indicated by a DN Access Identifier (DNAI). A DNAI can be interpreted as an index pointing to a specific access to one or more DNs. DNAI values ​​can be defined by the operator based on core network deployment and / or configuration characteristics. The AS controller can use DNAIs (e.g., DNAI-1, DNAI-2, DNAI-3) to interact with the CN-CP. In this diagram, DNAI-1 can indicate one or more areas of the CN-UP corresponding to application server #1. The areas of the CN-UP corresponding to application server #1 can include UPF {A} and UPF {B}. In this diagram, DNAI-2 can indicate one or more areas of the CN-UP corresponding to application server #2. The areas of the CN-UP corresponding to application server #2 can include UPF {D}. DNAI-3 can also indicate the areas of the CN-UP corresponding to application server #2, and it includes UPF {E}. UPF {C} may not correspond to a specific application server.

[0290] In the example, the operator can internally define a region associated with a specific DNAI. The operator can define regions arbitrarily. As an example, all UPFs linked to a specific application server can share a DNAI (similar to DNAI-1 in the diagram). As an example, a DNAI corresponds to a set of UPFs, and multiple DNAIs can correspond to specific application servers (similar to DNAI-2 and DNAI-3 in the diagram).

[0291] In the example, if the wireless device is in the first area, the CN-CP can determine to route the wireless device's application-related traffic to local DN #1 via UPF{B}. This can be based on the determination that the route via UPF{B} is more efficient than other possible routes. If the wireless device moves to a second area, the AS controller and / or core network can determine to reroute the wireless device's application-related traffic to local DN #1 via UPF{D}. DNAI enables cellular network domains and / or MEC domains to map specific application servers to specific areas and vice versa. For example, DNAI enables a cellular network domain to manage traffic between wireless devices and one or more application servers. As an example, DNAI may be known to the AS controller and can be used to facilitate AS management by the AS controller. Using DNAI, the AS controller can communicate with the CN-CP to influence, for example, the routing of application-related traffic.

[0292] Figure 18A This is an example call diagram for MEC discovery. A wireless device can discover MEC applications by sending an MEC discovery request to the CN-CP function. As an example, the request may include the data network name (DNN) of the local DN, requesting the discovery of MEC applications hosted within the specified local DN. In some implementations, the absence of a local DN name may indicate a request to discover all MEC applications. For example, the request may include an application identifier. The CN-CP function can determine the discovery result. This discovery may be based on registration data of MEC applications hosted by various data networks. The CN-CP function may cross-reference a specific MEC application to a specific data network and vice versa. The CN-CP can respond to the wireless device with the discovery result. The discovery result may include a list of one or more application identifiers and / or one or more application addresses (e.g., corresponding to a specific DN). In some implementations, the discovery result may be limited to those MEC applications available to the wireless device. In some implementations, the discovery result may be limited to those MEC applications that the wireless device is authorized to use. One or more application addresses may be used by the wireless device to communicate with upper layers (such as the TCP layer) of the MEC application.

[0293] In the example, the discovery request procedure for the MEC application can be integrated with the registration procedure between the wireless device and a CN-CP function (e.g., AMF). The MEC application's discovery request procedure can also be integrated with the session establishment procedure between the wireless device and a CN-CP function (e.g., SMF). The CN-CP function can notify the wireless device of changes in discovery results, such as application address changes, via NAS messages. The wireless device can request a dedicated PDU session to handle traffic associated with the MEC application. This dedicated PDU session can be used for a single edge computing application or shared by multiple edge computing applications.

[0294] Figure 18B This example illustrates how the AS controller can influence traffic routing for application data within the core network. The AS controller can send an AF request to the PCF. In this example, the AF can send the AF request message to the PCF via the NEF. If the AF request message is sent via the NEF, the NEF can map the external identifier provided by the AF to an internal identifier known to the 5G system (e.g., UE ID, SUPI, etc.). In this example, the AF can also send the AF request message directly to the PCF. For example, if the AF is in a trusted domain and / or deployed by the core network operator, the AF request can be sent directly to the PCF.

[0295] An AF request may include any information suitable for influencing traffic routing. Depending on the implementation and / or capabilities of the AS controller, an AF request may contain a range of information. For example, an AF request may include a general request from the core network to attempt to optimize the user plane configuration, specific information that the core network can use to facilitate user plane configuration, and / or specific instructions for configuring the user plane. An AF request may include traffic descriptors (IP filters and / or application identifiers) describing the application traffic covered by the AF request message. An AF request may include the location of one or more applications and / or application servers, such as a list of DNAIs. An AF request may include identifiers of the target radio devices, such as General Public Subscription Identifiers (GPSIs) or User Equipment (UE) group identifiers. An AF request may include N6 routing information indicating how the traffic should be forwarded via the N6 interface, such as the target IP address (and / or port) in the DN to which the application traffic is requested to be tunneled. An AF request may include spatial and temporal validity conditions indicating one or more time intervals and / or geographic areas at the time and / or location where the AF request message will be applied.

[0296] Based on the AF request message, the PCF can create Policy and Charge Control (PCC) rules and / or other relevant information, such as the requested Session and Service Continuity (SSC) mode, local UPF information, or any other relevant information. The PCF can send a Session Management Policy Update message to the SMF. The Session Management Policy Update message can indicate the PCC rules and / or relevant information. The SMF can then take action based on this information. In the example, this is done by configuring or reconfiguring the user plane. In the example, the SMF can insert an Uplink Classifier (UL CL) UPF into the user plane based on this information. In the example, the SMF can use an SSC mode 2 or 3 procedure to trigger the relocation of the PDU Session Anchor (PSA) UPF. As shown, the SMF can send a Session Management Policy Update response to the PCF. This response can be sent before or after the user plane reconfiguration. In the example, the response can include confirmation that the Session Management Policy Update message has been received. In the example, the response can inform the PCF about whether and / or how the user plane has been reconfigured.

[0297] An AF request can instruct the SMF to notify the AF when a UPF-related event occurs. For example, the SMF can notify the AF when to insert the ULCL UPF into the user plane, when an SSC mode 2 or mode 3 procedure is triggered, and / or when the PSA UPF is repositioned. The AF can request notification before and / or after the event occurs. Based on this notification, the AF can take application-layer actions, such as repositioning the application state to handle UE IP address changes.

[0298] Figure 19 An example is shown where an AS controller influences traffic routing for application data by causing a reconfiguration of the user plane within the core network. As described above, the AS controller can be implemented as an AF. The application, or an aspect thereof, can be accessed in three different data networks. The data networks can include a central network, a first local data network, and a second local data network. The central network has DNAI=0 and includes a central application server. In this example, the central application server is accessible via the Internet. The first local data network has DNAI=1 and includes a first edge application server. The second local data network has DNAI=2 and includes a second edge application server. The first local data network is associated with one or more UPFs including UPF{1}. The second local data network is associated with one or more UPFs including UPF{2}.

[0299] Initially (before the AF request), the user plane path between the wireless device and the application is via a central UPF (dotted line in the diagram) associated with a central network. The location of the central UPF may be remote from the location of the wireless device. Based on the AF request, the SMF can insert a local UPF within the user plane path of the wireless device. In the example, the AF request message may indicate the DNAI of the requested area (DNAI=1). Based on the DNAI indicated by the AF request message, the SMG can select a UPF associated with the first local data network (i.e., UPF {1}).

[0300] Following an AF request, the SMF can reconfigure the user plane paths. Specifically, the wireless device can have user plane paths to an edge application server within the first local area data network and to a central application server (solid lines in the figure). Because the first edge application server is closer to the wireless device than the central application server, it should be understood that the communication latency associated with the first edge application server may be less than the communication latency associated with the central application server. Therefore, in some scenarios, the new user plane path (i.e., the path requested by the AS controller) can reduce the latency associated with computational offloading of certain application-related tasks.

[0301] In existing technologies, 5G (3GPP) systems can support edge computing by allowing MEC systems and 5G systems to collaborate and interact to route traffic. The MEC system can instruct user plane paths to change from a central application server to a local application server. The MEC system can redirect user plane paths from a central User Plane Function (UPF) to a local UPF. In some scenarios, user plane path latency can be reduced by redirecting user plane paths to application servers closer to the wireless device's location. Reduced latency can also provide the wireless device with the opportunity to offload processing tasks to application servers. By offloading processing tasks, the wireless device can potentially reduce its computational burden and / or save resources. Existing technologies may not be efficient in determining whether a wireless device should offload computation for an application. This application may be a latency-sensitive application. In an example, the wireless device may determine to offload application processing to a network node (an application that offloads all computation to the MEC). The wireless device may send data that is not processed by the wireless device's application. Sending data that is not processed by the application may introduce further latency compared to sending data processed by the application. The latency reduction achieved by offloading computation to the network node (MEC) can be less than the additional latency introduced to send unprocessed data and receive processed results from the network node. For wireless devices serving in an MEC environment, improved session management is needed to control computation offloading decisions regarding latency in order to improve resource utilization efficiency, battery utilization, and ensure the quality of service for the wireless device.

[0302] Exemplary implementations support the exchange of delay information to make decisions regarding the offloading of application data. The SMF can receive a first message from the wireless device. The first message may include delay information regarding the offloading of application data. Based on this delay information, the SMF can send offloading information to the wireless device. The decision on whether to perform offloading can be based on whether the delay associated with offloading is suitable for the wireless device.

[0303] In the example, latency information may include a latency value. This latency value may be provided to the SMF by the wireless device. Offload information may indicate whether the network can support the offload associated with the latency value. For example, the latency value may indicate an acceptable amount of time for the wireless device to wait for offload processing. The SMF may determine the amount of time based on one or more of the following: (a) the time associated with data transmission to the application server, (b) the time associated with processing by the application server, and (c) the time associated with data transmission from the application server to the wireless device. If the amount of time associated with offload processing is less than the latency value, the offload information may indicate that offload processing is supported. If the amount of time associated with offload processing is greater than the latency value, the offload information may indicate that offload processing is not supported.

[0304] In the example, latency information may include a request for a latency value. Offload information may indicate the latency value. Based on the latency value, the wireless device may determine whether offload processing is appropriate. For example, the latency value may indicate the amount of time the wireless device needs to wait for offload processing. SMF may determine the latency value based on the amount of time, which includes one or more of the following: (a) the time associated with data transmission to the application server, (b) the time associated with processing by the application server, and (c) the time associated with data transmission from the application server to the wireless device. If the latency value is acceptable to the wireless device, the wireless device may determine to request offload processing.

[0305] The amount of time associated with offloading processing can be based on one or more of the following: (a) the time associated with data transmission to the application server, (b) the time associated with processing by the application server, and (c) the time associated with data transmission from the application server to the wireless device. As described herein, the time associated with transmission (latency) can have components, such as transmission time between the wireless device and the base station, transmission time within the network (e.g., between the base station and the UPF and / or the application server), etc. The SMF can be well-positioned to make determinations and / or estimates about each specific latency component. For example, in determining and / or estimating latency (or a particular latency component), the SMF can be positioned better than the wireless device or the application server (central or edge) to create and / or obtain information that influences offloading decisions (e.g., better positioned to obtain information from other network elements such as the base station, UPF, etc.).

[0306] The Offload Flow Mechanism (SMF) can provide offload information early in the process, such as during registration, service requests, and / or session establishment and / or modification procedures. As described herein, the SMF can select one or more specific UPFs for the wireless device. The selected UPF can be chosen to provide connectivity between the wireless device and a specific application server (e.g., a non-centrally located server supporting edge computing for the wireless device). The SMF can have (or obtain) information affecting latency from various network elements. Therefore, the SMF can decompose the latency associated with the offload process into any number of latency components and determine, measure, derive, or estimate the corresponding values ​​of the latency components. By sharing offload information with the wireless device, the SMF can facilitate efficient and opportunistic use of edge computing. In the example, the SMF is able to provide offload information even before the connection to the application server (central or edge) is introduced.

[0307] In the example, the wireless device can send session control messages (e.g., PDU session establishment request messages, PDU session modification request messages, etc.) to the SMF. The session control messages can request latency information from the application. The wireless device can receive session control response messages from the SMF. The session control response messages can include latency information based on the request. The latency information can include latency values. In the example, the latency value can be a total latency value comprising multiple component latency values. Each component latency value can correspond to a communication latency associated with a segment of the user plane path between the wireless device and the application server and / or a processing latency associated with a specific network entity, such as the processing latency in the application server. The wireless device can determine whether to perform local computation or offload (computation offload) based on the latency information. In the example, if a first latency value indicated by the latency information is greater than a second latency value associated with local computation, the wireless device can choose to perform / perform local computation. In the example, if the first latency value is less than the second latency value, the wireless device can choose to perform offload. If the wireless device chooses to perform local computation, it can send data processed by the application to the application server. If the wireless device chooses to perform offload, it can send data not processed by the application. In the example, latency information can be periodically sent to the wireless device. This improved session management allows the wireless device to efficiently determine appropriate computation options (e.g., offloading and local computation) for latency-sensitive applications.

[0308] In the example, latency information can be transmitted to the wireless device when the determined / measured latency is outside the (minimum, maximum) interval or above a threshold. This latency information can be transmitted to the wireless device by a centralized network entity, such as a data analysis function like an NWDAF node. The latency information can be a prediction of path latency. For example, NWDAF can provide a prediction of latency information, allowing the wireless device to determine whether to offload the task to the network or process the data locally upon receiving the latency information.

[0309] In the example, a wireless device can request the network to establish a PDU session for an application and can provide the network with the required latency value for the PDU session. In the example, if the network determines that computation offloading can be performed within the amount of time indicated by the required latency value, the wireless device can determine to offload computation to the network. The network (e.g., SMF) can determine whether the required latency value is acceptable for the PDU session. The network can determine whether it can provide the required latency value for the PDU session. The network can send a result based on this determination. In the example, the result can indicate whether the network can satisfy the required latency value. In the example, the result can include satisfied or unsatisfied. Based on the result, the wireless device can choose to perform offloading or local computation. The wireless device can choose to perform offloading in response to an indication that the network can return a processed result within the amount of time indicated by the required latency value. The wireless device can choose to perform offloading in response to a result indicating satisfied. The wireless device can choose to perform local computation in response to a result indicating unsatisfied. This improved session management enables the wireless device to efficiently determine appropriate computation options (e.g., offloading, local computation) for the application.

[0310] Figure 20 An example of compute offloading options is shown. The application can run on a wireless device and can request the wireless device to perform tasks. The wireless device can determine to offload the tasks to an application server associated with the application. The application server can be an edge application server. The application server can be located in a data network. The data network can be a local area network. The data network can be a cloud computing data center. The wireless device can send raw data and / or processing tasks to the application server.

[0311] An application running on a wireless device can obtain raw data from the wireless device. This raw data can be referred to as unprocessed data. The raw data can be collected and / or generated by the wireless device. In this exemplary diagram, the wireless device is shown as a vehicle. For example, the vehicle is running a vehicle-to-everything (V2X) autonomous driving application. The application can have the wireless device take photos of the front, right, left, and rear of the vehicle. These photos can be raw data. The application can process the raw data to obtain a result. This result can be referred to as processed data. In this example, the result could be the driving direction.

[0312] If the wireless device performs the processing locally (local computation option, without offload), the total execution time T[no_offload] is equal to the amount of time T[local] spent on the wireless device performing the processing locally. This processing may be necessary for V2X autonomous driving applications to determine the driving direction (result) based on photos (raw data). If the vehicle's computing power is limited, this can lead to significant latency.

[0313] A wireless device can offload processing to an application server instead of performing it locally. By performing raw data processing on the application server, the wireless device can potentially save computing power, increase processing speed, and / or reduce power consumption. For the offload option, the wireless device can transmit raw data (e.g., a photo) to the application server and request offload. This may introduce a transmission latency T[tx]. The application server can process the raw data remotely, resulting in an additional processing latency T[remote]. The application server can then transmit the processed result (e.g., driving direction) back to the wireless device. This may introduce a reception latency T[rx]. For the offload option, the total execution time T[offload] can be equal to the sum of the application server's processing latency T[remote] and the transmission / reception latency T[tx] + T[rx] associated with transmissions to and from the application server.

[0314] Transmission / reception delay T[tx]+T[rx] can be affected by many factors, such as the amount of raw data, the condition of the data delivery path (e.g., radio quality), the availability of network resources, the capabilities of the wireless device, etc.

[0315] This diagram illustrates an example of computation offloading options, where the wireless device performs all the processing required to obtain results from the raw data, or performs no processing at all. However, it should be understood that processing can be broken down into processing tasks, and a portion of a processing task can be performed locally while the remainder is offloaded. For example, raw data can be preprocessed before being transmitted to an application server. Similarly, data received from an application server can be post-processed to obtain results.

[0316] Figure 21 A call diagram of a session handler for a compute offloading decision according to an exemplary embodiment of this disclosure is shown. The diagram illustrates a wireless device, RAN, UPF, and several core network control plane application functions (AMF, SMF, PCF, and UDR). The wireless device can choose between local compute and / or offloading. Local compute can be the application compute of the wireless device, processing the application. Offloading (e.g., compute offloading) can be the application compute of a network node, processing the application. The network node can be an application server. The application server can belong to a mobile edge computing (MEC).

[0317] The wireless device can compare a first execution latency associated with local computation with a second execution latency associated with offloading. The wireless device can derive the first execution latency based on internal interactions with the application layer of the wireless device. In the example, the second execution latency may include processing time at the application server and transmission / reception latency of raw and processed data to and from the application server. The wireless device may not be aware of the second execution latency. The wireless device may need to query the network, including the application server, for the second execution latency. In the example, the wireless device may query the network (e.g., SMF) for the second execution latency during the PDU session establishment procedure. The wireless device may be authorized to use offloading.

[0318] A wireless device can send session control messages to the SMF. Session control messages can trigger a session establishment procedure to establish a PDU session for at least one application. Session control messages can also trigger a session modification procedure to modify the PDU session. Session control messages can be session establishment request messages or session modification request messages. In the example, a session control message may include a PDU session identifier, a request for delay information, etc. The session control message may also include the application's DNN and / or the application's S-NSSAI. The PDU session identifier can indicate a PDU session and can be used by the SMF to identify the PDU session. The request for delay information can indicate a second request to perform a delay. The DNN can be the application's data network name. The S-NSSAI can be the slice name associated with the application.

[0319] In the example, the SMF can receive session control messages. If the session control message includes a delay information request, the SMF can check the authorization of the delay information request for the wireless device. The SMF can determine whether the request is authorized based on the wireless device's subscription information, local policies, etc. If the wireless device / PDU session is authorized to request delay information, the SMF can determine the delay information based on the request. In the example, the SMF can establish a policy association with the PCF. The SMF can receive QoS parameters of the wireless device based on DNN, S-NSSAI, etc. QoS parameters can include at least one of the following: 5G QoS Identifier (5QI), application and reservation priorities, QoS attributes, stream bit rate, maximum packet loss rate, aggregate bit rate, etc.

[0320] As shown in the figure, the SMF can coordinate with the RAN, AMF, and / or UPF to determine delay information. Delay information can be determined by querying the delay information database. Delay information may include delay values. The SMF can send a request for delay information and can receive a response including, for example, a delay value. Delay values ​​can be expressed as, for example, seconds, milliseconds, microseconds, nanoseconds, bits per second (bps), gigabits per second (Gbps), or megabits per second (Mbps).

[0321] The latency value can be referred to as the total latency value and can include multiple component latency values. As an example, the total latency value can include the sum of the offload processing latency value and / or at least one communication latency value. The offload processing latency value can be the amount of time an application server takes to execute one or more offload processing tasks. The SMF can determine the offload processing latency value based on a UPF selection process. For example, a specific UPF (or combination of UPFs) can be associated with a specific application server having a specific amount of available processing capacity. The offload processing latency value can be based on the amount of processing capacity available at the application server.

[0322] Communication delay values ​​may be referred to as transmission delay values, transmission / reception delay values, and / or Tx / Rx delay values. At least one communication delay value in the total delay value may include the round-trip transmission time (e.g., composed of) from the wireless device to the application server and back to the wireless device. At least one communication delay value may include twice the transmission time from the wireless device to the application server, or twice the transmission time from the application server to the wireless device. It should be understood that in scenarios where communication speeds are asymmetrical in different directions, the round-trip transmission time may be a more accurate indicator. At least one communication delay value may include component communication delay values ​​corresponding to a specific segment of the user plane path between the wireless device and the application server. For example, a first component communication delay value may correspond to a segment between the wireless device and the RAN, a second component communication delay value may correspond to a segment between the RAN and the UPF, and a third component communication delay value may correspond to a segment between the UPF and the application server. If multiple UPFs exist within the user plane path, the third component communication delay value may be further subdivided into sub-components corresponding to pairs of UPFs.

[0323] In the example, the SMF can send a message to the AMF requesting a first component communication delay value corresponding to the transmission time and / or reception time between the radio device and the RAN. The RAN can be, for example, a base station to which the radio device is connected. The AMF can send a message to the RAN requesting the first component communication delay value. This message may include QoS parameters of the PDU session, DNN, S-NSSAI, the capabilities of the radio device, the request for the first component communication delay value, etc. The RAN can determine the first component communication delay value based on the QoS parameters, DNN, S-NSSAI, the resource status of the base station, the radio quality of the radio device, propagation delay, the capabilities of the radio device, etc. The RAN can determine the first component communication delay value based on the round-trip time between the radio device and the RAN. The first component communication delay value may be equal to the sum of the transmission time from the RAN to the radio device and / or the transmission time from the radio device to the RAN. In response to this determination, the RAN can send a message including the first component communication delay value to the AMF and / or the SMF. In the example, the SMF can receive a message including the first component communication delay value. The SMF can use the first component communication delay value to determine at least one communication delay value and / or a total delay value. In some implementations, based on the assumption that the communication delay values ​​of other components are smaller and / or negligible compared to the communication delay value of the first component, the SMF may assume that at least one communication delay value and / or the total delay value is equal to the communication delay value of the first component.

[0324] The Service Provider (SMF) can select a serving UPF for a PDU session. The SMF can select a serving UPF for a PDU session based on a request for latency information. The SMF can select a serving UPF based on at least one of the following: DNN, S-NSSAI, the location of the radio device, and the request for latency information. In the example, if the radio device is located inside DNAI-X, the SMF can select a UPF associated with DNAI-X (e.g., UPF 1). The association information between DNAI-X and UPF 1 can be configured by the AF using the AF's influence on traffic routing. If the SMF selects a UPF, the SMF can determine a second component communication latency value (corresponding to the amount of time required to transmit and / or receive data between the base station and the UPF via N3), a third component communication latency value (corresponding to the amount of time required to transmit and / or receive data between the UPF and the application server via N6), or their sum (corresponding to the amount of time required to transmit and / or receive data between the base station and the application server via N3+N6).

[0325] In the example, the SMF can send a session control response message for a PDU session to the wireless device based on a request for latency information. This message includes latency information, including a latency value (e.g., a total latency value). In the example, the wireless device can receive a session control response message for a PDU session from the SMF, which also includes latency information, including a latency value. The wireless device can choose whether to perform offloaded local computation based on the latency information. The wireless device can determine whether to apply local computation or offload based on the latency value, local processing latency, the amount of raw data (e.g., unprocessed data), the remaining battery power of the wireless device, etc.

[0326] In the example, the latency value can represent the amount of time required to execute one or more processing tasks. In response to a first latency value corresponding to offloading being less than or equal to a second latency value corresponding to local calculation, the wireless device can determine to select offloading. In the example, the latency value can be represented as a data rate (e.g., bits per second). In response to a first latency value corresponding to offloading being greater than or equal to a second latency value corresponding to local calculation, the wireless device can determine to select offloading. In the example, the first latency value corresponding to offloading could be 10 Gbps, and the second latency value corresponding to local calculation could be 5 Gbps. In this case, the wireless device can determine to select offloading.

[0327] In the example, the wireless device can compare a first execution latency and a second execution latency. The second execution latency is based on a latency value. In the example, the second execution latency is a latency value. In response to the second execution latency being shorter than / lower than the first execution latency, the wireless device can choose to offload. In the example, in response to a latency value equal to or greater than / longer than / higher than a locally computed latency value, the wireless device can determine to select local computation. In the example, the wireless device can compare a first execution latency and a second execution latency. In response to the second execution latency being longer than / greater than / higher than the first execution latency, the wireless device can select local computation.

[0328] If the wireless device chooses local computation, it can process the raw data to obtain a result and send the processed data to the base station. The processed data can then be processed by the wireless device's application. If the wireless device chooses offloading, it can send unprocessed data (raw or partially processed data) to the application server via the base station. The wireless device can receive the processed result in response to sending the unprocessed data.

[0329] In the example, the wireless device or SMF can initiate a session modification procedure in response to application uninstallation. Session modification can be based on the need to modify the QoS of the PDU session after application uninstallation. If uninstallation is selected, the wireless device may need to send more packet data than locally computed. In the example, the wireless device can request increased QoS from the SMF. The SMF can indicate the increased QoS to the wireless device by sending a Session Modification Request message.

[0330] This improved session management allows wireless devices to determine appropriate computation options (e.g., offload, local computation) by querying a second execution latency.

[0331] Figure 22 A call diagram of a session handler for a computation offloading decision according to an exemplary embodiment of this disclosure is shown. As will be discussed in more detail below, the wireless device can operate according to the application and can determine whether to process data locally or offload processing to an application server. The wireless device can determine a latency value that will cause the wireless device to select an offloading option. The latency value can be based on the capabilities of the wireless device (e.g., the amount of time required to perform the local computation task and / or the bit rate associated with the local computation). The wireless device can provide the determined latency value to a network (e.g., an SMF), and the network can determine whether the network is able to provide a better latency value (e.g., lower latency or higher bit rate) than the latency value that the wireless device can obtain using local computation. The network can indicate whether it is able or unable to provide a better latency value. The wireless device can then choose between local computation and offloading based on this indication.

[0332] This diagram illustrates a wireless device, RAN, UPF, and several core network control plane application functions (AMF, SMF, PCF, and UDR). The wireless device can choose between local computation and / or offloading. Local computation can be the wireless device's application computation of the application's processing. Offloading (e.g., computation offloading) can be a network node's application computation of the application's processing. The network node can be an application server. The application server can belong to a mobile edge computing (MEC). In this exemplary embodiment, the wireless device can determine a desired latency value for a second execution latency associated with offloading. The desired latency value is used by the MEC. The wireless device can request the desired latency value from the network, while the PDU session handler and the network can provide a result indicating the desired latency value. This result can indicate whether the latency value required for the PDU session is acceptable. This result can indicate whether the network satisfies the desired latency value. The wireless device can determine whether to choose offloading or local computation. The wireless device can choose offloading in response to a result indicating acceptance or satisfaction. The wireless device can choose local computation in response to a result indicating non-acceptance / unacceptability or non-satisfaction.

[0333] A wireless device can send session control messages to the SMF. Session control messages can trigger a session establishment procedure to establish a PDU session for at least one application. Session control messages can also trigger a session modification procedure to modify a PDU session. Session control messages can be session establishment request messages or session modification request messages. In the example, a session control message may include a PDU session identifier, a desired latency value, etc. The session control message may also include the application's DNN and / or the application's S-NSSAI. The PDU session identifier can indicate a PDU session and can be used by the SMF to identify the PDU session. The desired latency value can indicate a threshold latency value for offloading. The DNN can be the application's data network name. The S-NSSAI can be the slice name associated with the application.

[0334] In the example, the SMF can receive session control messages. If the session control message includes the desired latency value, the SMF can check whether the wireless device is authorized to offload. The SMF can determine whether offloading is authorized based on the wireless device's subscription information, local policies, etc. If offloading is authorized for the wireless device and / or PDU session, the SMF can allocate more resources to the PDU session.

[0335] SMF can establish policy associations with PCF. SMF can receive QoS parameters from wireless devices based on DNN, S-NSSAI, etc. QoS parameters can include at least one of the following: 5G QoS Identifier (5QI), application and reservation priorities, QoS attributes, stream bit rate, maximum packet loss rate, aggregate bit rate, etc. If the received QoS is insufficient for the required latency value, SMF can relax the QoS parameters. If the received QoS is still insufficient for the required latency value, SMF can increase the QoS level.

[0336] As shown in the figure, the SMF can coordinate with the RAN, AMF, and / or UPF to determine whether the desired delay value is acceptable / satisfiable. The SMF can coordinate with the RAN, AMF, and / or UPF to determine whether the desired delay value is acceptable / satisfiable by querying available delay values. Available delay values ​​can be the total delay value comprising multiple component delay values, each corresponding to a segment of the user plane path between the wireless device and the application server. Available delay values ​​can be referred to as communication delay values, transmit / receive delay values, and / or Tx / Rx delay values. Available delay values ​​can be expressed as data rates, such as bits per second (bps), gigabits per second (Gbps), or megabits per second (Mbps). The delay value can correspond to a round trip (transmit and receive) or can correspond to a single branch of a round trip (transmit or receive), indicating 10 Mbps.

[0337] In the example, the SMF can send a message to the AMF requesting a component delay value corresponding to the transmission time and / or reception time between the radio device and the RAN. The RAN can be, for example, a base station to which the radio device is connected. The AMF can send a message to the RAN requesting a second delay value. This message may include QoS parameters of the PDU session, DNN, S-NSSAI, the capabilities of the radio device, the request for the second delay value, etc. The RAN can determine the second delay value based on QoS parameters, DNN, S-NSSAI, the resource status of the base station, the radio quality of the radio device, propagation delay, the capabilities of the radio device, etc. The RAN can determine the second delay value based on the round-trip time between the radio device and the RAN. The second delay value may be equal to the sum of the transmission time from the RAN to the radio device and the transmission time from the radio device to the RAN. In response to this determination, the RAN can send a message including the second delay value to the AMF and / or the SMF. In the example, the SMF can receive the message including the second delay value. The SMF can use the second delay value to determine the total delay value. In some implementations, based on the assumption that a third delay value and / or a fourth delay value are smaller than the second delay value, the SMF may assume that the total delay value is equal to the second delay value. If the total latency value is longer than / greater than / higher than the required latency value, the SMF can determine that the required latency value is unacceptable / unsatisfactory to the network. If the SMF determines that the required latency value is unacceptable / unsatisfactory to the network, the result can indicate "Not Satisfactory" or "Not Acceptable". If the total latency value is equal to or shorter than / less than / lower than the required latency value, the SMF can determine that the required latency value is acceptable / satisfactory to the network. If the SMF determines that the required latency value is acceptable / satisfactory to the network, the result can indicate "Satisfactory" or "Acceptable".

[0338] In the example, the latency value, required latency value, second latency value, available latency value, and total latency value can be represented as data rate. In this case, the determining equation with longer / larger / higher latency can be interchanged with shorter / lower / smaller latency (and vice versa).

[0339] The Service Provider (SMF) can select a serving UPF for a PDU session. The SMF can select a serving UPF for a PDU session based on a desired latency value. The SMF can select a serving UPF based on at least one of the following: DNN, S-NSSAI, the location of the radio device, the desired latency value, etc. If the desired latency value indicates that the shortest path is preferred, the SMF can select a UPF located at the edge of the radio device. If the SMF selects a UPF, the SMF can determine a third (transmission / reception) latency value. The third latency value may correspond to the time period required to transmit and / or receive data between the UPF and the application server (e.g., N6) or between the base station and the application function (e.g., N3+N6).

[0340] SMF can determine the available delay value based on the second and third delay values. In the example, the available delay value can be the sum of the second and third delay values. In the example, the third delay value can be considered zero because it is relatively shorter than the second delay value. In the example, the delay value, the second delay value, and the third delay value can all be one-way delays.

[0341] In the example, the SMF can send a session control response message for a PDU session to the wireless device based on the desired latency value and the available latency value. This message includes a result. The result is based on a comparison between the desired latency value and the available latency value. In this example, the result can indicate "accepted" or "not accepted." The result can also indicate "satisfied" or "not satisfied."

[0342] In the example, the wireless device can receive a session control response message for the PDU session from the SMF, which includes a result. Based on this result, the wireless device can choose whether to perform offloaded local computation. The wireless device can determine whether to apply local computation or offload based on the result, local processing latency, the amount of raw data (e.g., unprocessed data), the remaining battery power of the wireless device, etc. The wireless device can choose to offload in response to a result indicating "accepted / satisfied". The wireless device can choose to perform local computation in response to a result indicating "not accepted / not satisfied".

[0343] If the wireless device chooses local computation, it can send the processed data to the base station. The processed data can then be processed by the wireless device's application. If the wireless device chooses offloading, it can send unprocessed data (raw data) to the application server via the base station. The wireless device can receive the processed result in response to sending the unprocessed data.

[0344] In the example, the wireless device or SMF can initiate a session modification procedure in response to application uninstallation. Session modification can be based on the need to modify the QoS of the PDU session after application uninstallation. If uninstallation is selected, the wireless device may need to send more packet data than locally computed. In the example, the wireless device can request increased QoS from the SMF. The SMF can indicate the increased QoS to the wireless device by sending a Session Modification Request message.

[0345] This improved session management allows wireless devices to determine appropriate computation options (e.g., offloading, local computation) by requesting the desired latency value. By providing the desired latency value, the network (e.g., SMF) can increase the QoS level, thus enabling the MEC to provide session processing regarding latency.

[0346] Figure 23A call diagram of a wireless device according to an exemplary embodiment of this disclosure is shown. The wireless device may send session control messages to a network. For example, the wireless device may include one or more of a delay information request or a desired delay value. The wireless device may receive session control response messages from the network. For example, the session control response message may include one or more of delay information or an indication of whether the desired delay value can be obtained. The wireless device may obtain raw data associated with an application. The wireless device may determine, based on the session control response message, whether to offload the processing of the raw data or process the raw data locally. If the wireless device determines to offload the processing of the raw data, the wireless device may optionally partially process the raw data. If the wireless device determines to offload the processing of the raw data, the wireless device may transmit the unprocessed raw data (i.e., the raw data or the partially processed data) to the application server associated with the application. If the wireless device determines to process the raw data locally, the wireless device may process the raw data locally and transmit the processed data to the application server associated with the application.

[0347] Figure 24 A call diagram of a wireless device according to an exemplary embodiment of the present disclosure is shown. In the example, the wireless device may send a session control message to the SMF requesting latency information. The session control message may include the request for latency information. The wireless device may receive a session control response message in response to sending the session control message. The session control response message may include latency information. The wireless device may determine whether to choose offload or local computation based on the latency information. If the wireless device chooses offload, it may send data that has not been processed by the wireless device's application. If the wireless device chooses local computation, it may send data that has been processed by the wireless device's application.

[0348] Figure 25 A call diagram of an SMF according to an exemplary embodiment of this disclosure is shown. In the example, the SMF can receive a session control message including a delay information request from a radio device. The SMF can determine the delay information based on this request. The SMF can cooperate with the RAN and UPF to query the delay information. Based on this determination, the SMF can send a session control response message including the delay information.

[0349] A wireless device can send a session control message to the Session Management Function (SMF) to request the establishment of a Packet Data Unit (PDU) session for an application. The session control message may include a PDU session identifier indicating the PDU session and a request for latency information. The wireless device can receive a session control response message from the SMF, which includes latency information for the PDU session. The session control response message may include latency information based on the request. The wireless device can choose to perform offload or local computation on the PDU session based on the latency information. In response to selecting offload, the wireless device can send data that has not been processed by the wireless device's first application. In response to not selecting offload, the wireless device can choose local computation. In response to selecting local computation, the wireless device can send data that has not been processed by the wireless device's first application.

[0350] Local computing can be the first application computation performed by a wireless device, handling the application's processing. Offloading can be the second application computation performed by a network node, handling the application's processing. Mobile edge computing (MEC) can include network nodes.

[0351] The delay in the delay information can occur between the first application on the wireless device and the second application on the network node. The wireless device can be authorized to uninstall the second application. This application can be a latency-sensitive application.

[0352] In the example, the delay in the delay information can be between the base station and the wireless device. The delay in the delay information can also be between the user plane function (UPF) and the wireless device.

[0353] A wireless device can send a Session Modification Request (SMR) message to the SMF to request modifications to the application's Quality of Service (QoS) requirements. The wireless device can send the SMR message based on opt-out.

[0354] Session control messages can be PDU session establishment request messages or PDU session modification request messages. PDU session modification request messages can trigger session modifications.

[0355] The delay information includes a delay value. Selecting to uninstall can be further based on the delay value being less than or greater than a locally calculated second delay value.

[0356] Selecting local computation can be based on a latency value that is greater than or less than a second latency value for local computation. The second latency value is the processing latency value for local computation.

[0357] In the example, the Session Management Function (SMF) can receive a Session Control Message from the radio device, requesting the establishment of a Packet Data Unit (PDU) session for the application. The Session Control Message may include a PDU session identifier indicating the PDU session and a request for delay information. The SMF can determine the delay value of the PDU session based on this request. The SMF can send an SMF Session Control Response Message to the radio device based on this request. The Session Control Response Message may include the PDU session identifier and delay information including the delay value. Based on this request, the SMF can send a second request for a second delay value to the base station via the Access and Mobility Management Function (AMF). The SMF can receive a second delay value from the base station based on the second request. The delay value may be a second delay value.

[0358] The SMF can select the User Plane Function (UPF) for the PDU session based on this request. The SMF can send a setup request message to the UPF. The SMF can receive a setup response message from the UPF. The setup response message may include a third delay value. The third delay value can be the delay value between the base station and the UPF, or the delay value between the base station and the secondary application of the network node.

[0359] The delay value can be the sum of the second delay value and the third delay value.

[0360] In the example, the wireless device may send a session control message to the Session Management Function (SMF) requesting the establishment of a Packet Data Unit (PDU) session for an application. The session control message may include a PDU session identifier indicating the PDU session and a desired delay value. The wireless device may receive a session control response message from the SMF, including the desired delay value. This result may indicate at least one of satisfaction or non-satisfaction. Based on this result, the wireless device may choose to perform offload or local computation on the PDU session. In response to selecting offload, the wireless device may send data not processed by the wireless device's first application. In response to selecting local computation, the wireless device may send data processed by the wireless device's first application.

[0361] Local computing can be the first application of a wireless device computing the processing of that application. Offloading can be the second application of a network node computing the processing of that application. Mobile edge computing (MEC) can include network nodes. The required latency value can be between the first application of the wireless device and the second application of the network node. The required latency value can be a threshold latency value. The required latency value may be between the base station and the wireless device. The required latency value may be between the user plane function (UPF) and the wireless device.

[0362] The wireless device can send a Session Modification Request (SMR) message to the SMF based on this result, requesting modification of the application's Quality of Service (QoS) requirements. Sending the SMR message can be based on opt-out.

[0363] Choosing to unload can be based on the result of the indication being met. Choosing to compute locally can be based on the result of the indication not being met.

[0364] In the example, the Session Management Function (SMF) can receive a session control message from the radio device requesting the establishment of a Packet Data Unit (PDU) session for the application. The session control message may include a PDU session identifier indicating the PDU session and a desired latency value. The SMF can determine whether the desired latency value for the PDU session is met based on this value. Based on this determination, the SMF can send a session control response message to the radio device, including the determination result. This result may indicate whether the latency was met or not.

[0365] The SMF can send a second request for a second delay value for a PDU session to the base station via the Access and Mobility Management Function (AMF) based on the desired delay value. The SMF can receive the second delay value from the base station based on the second request. If the second delay value is equal to or less than the desired delay value, the result indicates that the request has been fulfilled. If the second delay value is greater than or longer than the desired delay value, the result indicates that the request has not been fulfilled.

[0366] The SMF can select the User Plane Function (UPF) of a PDU session based on the desired delay value. The SMF can send a setup request message to the UPF. The SMF can receive a setup response message from the UPF. The setup response message may include a third delay value. The third delay value can be the delay value between the base station and the UPF. The third delay value can also be the delay value between the base station and a second application of the network node. If the sum of the second and third delay values ​​is equal to or less than the desired delay value, the result is indicated as satisfied. If the sum of the second and third delay values ​​is greater than the desired delay value, the result is indicated as not satisfied.

[0367] In this specification, "a" (a and an) and similar phrases will be interpreted as "at least one" and "one or more". In this specification, the term "may" is interpreted, for example, "may". In other words, the term "may" indicates that the phrase following the term "may" is an example of one suitable possibility among many suitable possibilities that may or may not be used in one or more embodiments in various implementations. If A and B are sets, and every element of A is also an element of B, then A is called a subset of B. In this specification, only non-empty sets and subsets are considered. For example, possible subsets of B = {cell1, cell2} are: {cell1}, {cell2}, and {cell1, cell2}.

[0368] In this specification, a parameter (information element: IE) may include one or more objects, and each of those objects may include one or more other objects. For example, if parameter (IE) N includes parameter (IE) M, and parameter (IE) M includes parameter (IE) K, and parameter (IE) K includes parameter (information element) J, then, for example, N includes K, and N includes J. In an exemplary embodiment, when one or more messages include multiple parameters, this means that a parameter among the multiple parameters is present in at least one of the one or more messages, but not necessarily in each of the one or more messages.

[0369] Many elements described in the disclosed embodiments can be implemented as modules. A module is defined herein as a separable element that performs a defined function and has a defined interface to other elements. Modules described in this disclosure can be implemented as hardware, software combined with hardware, firmware, wet hardware (i.e., hardware with biological elements), or a combination thereof, all of which may be behaviorally equivalent. For example, a module can be implemented as software routines written in a computer language configured to be executed by a hardware machine (e.g., C, C++, Fortran, Java, Basic, Matlab, etc.) or a modeling / simulation program (e.g., Simulink, Stateflow, GNU Octave, or LabVIEW MathScript). Alternatively, it is possible to implement modules using physical hardware incorporating discrete or programmable analog, digital, and / or quantum hardware. Examples of programmable hardware include: computers; microcontrollers; microprocessors; application-specific integrated circuits (ASICs); field-programmable gate arrays (FPGAs); and complex programmable logic devices (CPLDs). Computers, microcontrollers, and microprocessors are programmed using languages ​​such as assembly, C, and C++. FPGAs, ASICs, and CPLDs are frequently programmed using hardware description languages ​​(HDLs), such as VHSIC Hardware Description Language (VHDL) or Verilog. These languages ​​configure connections between relatively few internal hardware modules on a programmable device. Finally, it is important to emphasize that the above techniques are often used in combination to achieve the result of functional modules.

[0370] Exemplary embodiments of the present invention can be implemented using various physical and / or virtual network elements, software-defined networks, and virtual network functions.

[0371] The disclosure of this patent document incorporates copyrighted material. The copyright holder does not object to anyone making an exact copy of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office's patent documents or records for limited purposes required by law, but otherwise reserves all copyright rights.

[0372] Although various embodiments have been described above, it should be understood that they are presented by way of example rather than limitation. It will be apparent to those skilled in the art that various changes in form and detail may be made without departing from the spirit and scope of this disclosure. Indeed, after reading the above description, it will be apparent to those skilled in the art how to implement alternative embodiments. Therefore, the current embodiments should not be limited to any of the exemplary embodiments described above. In particular, it should be noted that, for illustrative purposes, the above explanation has focused on examples using 5G AN. However, those skilled in the art will recognize that embodiments of the invention can also be implemented in systems including one or more legacy systems or LTE. The disclosed methods and systems can be implemented in wireless or wired systems. Features of the various embodiments proposed in this invention can be combined. One or more features (methods or systems) of one embodiment can be implemented in other embodiments. A limited number of example combinations are shown to indicate to those skilled in the art the possibility of combining features in various embodiments to create enhanced transmission and reception systems and methods.

[0373] Furthermore, it should be understood that any diagrams highlighting features and benefits are presented for illustrative purposes only. The disclosed architecture is flexible and configurable enough that it can be utilized in ways other than those shown. For example, the actions listed in any flowchart can be reordered or optionally used in certain implementations.

[0374] Furthermore, the purpose of this abstract is to enable the U.S. Patent and Trademark Office and the general public, especially scientists, engineers, and practitioners unfamiliar with patent or legal terminology, to quickly determine the nature and substance of the technical disclosure of this application through a cursory examination. This abstract is not intended to limit the scope in any way.

[0375] Finally, the applicant's intention is that only claims including the phrases "apparatus for..." or "steps for..." should be interpreted according to 35 USC 112. Claims that do not explicitly include the phrases "apparatus for..." or "steps for..." should not be interpreted according to 35 USC 112.

Claims

1. A session management method for handling uninstallation, comprising: The Session Management Function (SMF) receives a first message from the wireless device, the first message including a latency value for data used in the application, the latency value indicating the processing time at the wireless device; as well as Based on the fact that the amount of time associated with the offloading process of the data is less than the delay value, the SMF sends a second message to the wireless device, the second message indicating that the offloading of the data is supported.

2. The method of claim 1, wherein the first message includes a session identifier.

3. The method of claim 1, wherein the first message includes a session control message.

4. The method of claim 1, wherein the first message includes a request to establish a session.

5. The method of claim 1, wherein the first message includes a request to modify the session.

6. The method of claim 1, wherein the first message includes a data network name (DNN).

7. The method of claim 1, wherein the first message includes Single Network Slice Selection Assistance Information (S-NSSAI).

8. The method of claim 2, wherein the session is associated with the application, and the session identifier is an identifier of the session.

9. The method of claim 1, wherein the second message includes a session control response message.

10. The method of claim 1, wherein the second message comprises one or more of the following: Session establishment and message acceptance; and The session has been modified to accept messages.

11. The method of claim 1, wherein the second message indicates a request for unload processing.

12. The method of claim 11, wherein the amount of time includes the processing time at the application server.

13. The method of claim 11, wherein the time quantity includes a first transmission time associated with data transmission between the wireless device and the base station, the first transmission time being associated with one or more of the following: Data transmission from the wireless device to the base station; and Data transmission from the base station to the wireless device.

14. The method of claim 13, further comprising sending a request to one or more of the base station and the access and mobility management functions for information on the transmission time of the first message.

15. The method of claim 14, wherein the request for information on the transmission time of the first message includes one or more of the following: One or more service quality parameters; The data network name is DNN; and Single network slice selection auxiliary information S-NSSAI.

16. The method of claim 11, wherein the time quantity includes a second transmission time associated with data transmission between the base station and the application server associated with the application, the second transmission time being associated with one or more of the following: Data transmission from the base station to the application server associated with the application; and Data transmission from the application server associated with the application to the base station.

17. The method of claim 16, further comprising sending a query to the user plane function for information about the second transmission time.

18. The method of claim 17, wherein the user plane function is determined based on the first message.

19. The method of claim 11, wherein the time quantity includes transmission latency associated with data transmission between the wireless device and the application server associated with the application.

20. The method of claim 1, further comprising the process by which the SMF determines that the wireless device is authorized to offload the data.

21. The method of claim 20, further comprising obtaining subscription information of the wireless device from the SMF, wherein determining that the wireless device is authorized is based on the subscription information.

22. The method of claim 1, further comprising determining the User Plane Function (UPF) by the SMF and based on the delay value.

23. A session management function comprising one or more processors and a memory storing instructions, the instructions, when executed by the one or more processors, causing the session management function to perform the method according to any one of claims 1 to 22.

24. A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform the method as described in any one of claims 1 to 22.

25. A method for processing uninstallation, comprising: A first message is sent from the wireless device to the Session Management Function (SMF), the first message including a latency value for the data used in the application, the latency value indicating the processing time at the wireless device; as well as Based on the fact that the amount of time associated with the offloading process of the data is less than the delay value, the wireless device receives a second message from the SMF, the second message indicating that the offloading of the data is supported.

26. The method of claim 25, wherein: The first message includes a session identifier and a request to establish a session; The second message includes a session establishment acceptance message.

27. The method of claim 25, wherein: The first message includes a session identifier and a request to modify the session; The second message includes a session modification acceptance message.

28. The method of any one of claims 25 to 27, wherein: The first message indicates a request for unloading processing; and The second message includes a delay value indicating the amount of time associated with the unloading process of the data.

29. The method according to any one of claims 25 to 27, wherein: The second message indicates whether the amount of time associated with the unloading process of the data is less than the delay value.

30. The method of any one of claims 25 to 27, further comprising the processing by which the wireless device determines, based on the second message, whether to uninstall the data of the application.

31. The method of any one of claims 25 to 27, further comprising: The wireless device determines the processing of the data used to uninstall the application; as well as The wireless device transmits at least partially unprocessed data for the application.

32. A wireless device comprising one or more processors and a memory storing instructions, the instructions, when executed by the one or more processors, causing the wireless device to perform the method as claimed in any one of claims 25 to 31.

33. A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform the method as described in any one of claims 25 to 31.

34. A session management system for handling uninstallation, comprising: A session management function includes one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the session management function to function. Receive a first message, the first message including a delay value for the application's data, the delay value indicating the processing time at the wireless device; and Based on the fact that the amount of time associated with the unloading process of the data is less than the delay value, a second message is sent, the second message indicating that the unloading of the data is supported; as well as A wireless device, comprising: one or more processors and a memory storing instructions, the instructions causing the wireless device, when executed by the one or more processors: Send the first message; and Receive the second message.

Images