Preserving session context in a communication network

Abstract

A wireless transmit / receive unit (WTRU) may send a registration request message to a network node requesting to register with the network and informing the network node that the WTRU may store context information associated with communications between the WTRU and the network when the WTRU becomes unavailable to the network. The network node may indicate in a registration accept message that the network supports storing the context information when the WTRU becomes unavailable to the network. Based on a determination that the WTRU will become unavailable to the network, the WTRU may send a message to the network indicating a request to store the context information. The message may include a notification of the period for which the WTRU will be unavailable.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 275,084, filed November 3, 2021, entitled "Enhancements for Interactions between the Session Management and Mobility Management Layers," the contents of which are incorporated herein by reference in their entirety. [Background technology]

[0002] For example, in wireless communication systems, such as systems operating in accordance with the 3rd Generation Partnership Project (3GPP) New Radio (NR) standard, events may occur that require the removal of mobility management context in a wireless transmit / receive unit (WTRU), such as a user equipment (UE), but also cause the removal of session management context. For example, the mobility management context of the WTRU may be cleared when there is an operating system (OS) update, a modem reset, or a deregistration request initiated by the network. However, such events may also cause the removal of the session management context and application layer information of the WTRU. This can lead to inefficiencies. Summary of the Invention

[0003] Described herein are methods, apparatus, and systems for preserving session context in a communication network when an event triggers the deletion of such context. A wireless transmit / receive unit (WTRU) may send a registration request message to a network node requesting to register with the network. The registration request message may include a notification that the WTRU can preserve context information associated with communications between the WTRU and the network when the WTRU becomes unavailable to the network. The WTRU may receive a registration accept message from the network node indicating that the network supports preservation of context information when the WTRU becomes unavailable to the network. Based on a determination that the WTRU will become unavailable to the network, the WTRU may send a first message to the network indicating a request to preserve the context information. The first message may include a notification of a period of time during which the WTRU will be unavailable. After the period expires, the WTRU may send a second message to the network indicating that the WTRU is again available to the network.

[0004] This Summary is provided to introduce a selection of concepts in a simplified form, which are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Moreover, the claimed subject matter is not limited to limitations that solve any or all of the disadvantages noted anywhere in this disclosure. [Brief explanation of the drawings]

[0005] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which: [Figure 1] FIG. 1 illustrates an exemplary communication system. [Figure 2]FIG. 1 illustrates an exemplary control plane between network entities. [Figure 3] FIG. 1 illustrates an exemplary registration management (RM) state model in a UE. [Figure 4] FIG. 1 illustrates an exemplary registration management (RM) state mode in AMF. [Figure 5] FIG. 1 illustrates exemplary connection management (CM) state transitions in a UE. [Figure 6] FIG. 1 illustrates exemplary connection management (CM) state transitions in AMF. [Figure 7] FIG. 1 illustrates an exemplary control plane protocol stack between a UE and an SMF. [Figure 8] FIG. 1 illustrates an exemplary UE-initiated deregistration method. [Figure 9] FIG. 1 illustrates an exemplary network-initiated deregistration method. [Figure 10] FIG. 1 illustrates an exemplary user plane protocol stack. [Figure 11A] A diagram illustrating an exemplary UE-requested PDU session establishment method for non-roaming and roaming with local breakout. [Figure 11B] A diagram illustrating an exemplary UE-requested PDU session establishment method for non-roaming and roaming with local breakout. [Figure 11C] A diagram illustrating an exemplary UE-requested PDU session establishment method for non-roaming and roaming with local breakout. [Figure 11D] A diagram illustrating an exemplary UE-requested PDU session establishment method for non-roaming and roaming with local breakout. [Figure 12a] FIG. 1 illustrates an exemplary UE or network requested PDU session modification (non-roaming and roaming with local breakout) method. [Figure 12b]FIG. 1 illustrates an exemplary UE or network requested PDU session modification (non-roaming and roaming with local breakout) method. [Figure 12c] FIG. 1 illustrates an exemplary UE or network requested PDU session modification (non-roaming and roaming with local breakout) method. [Figure 13] FIG. 1 illustrates an exemplary context saving and restoration method. [Figure 14] FIG. 1 illustrates an exemplary extended RM state model for UE and AMF. [Figure 15A] FIG. 1 illustrates another exemplary communication system. [Figure 15B] FIG. 1 illustrates an exemplary Radio Access Network (RAN) and core network. [Figure 15C] FIG. 1 illustrates an exemplary Radio Access Network (RAN) and core network. [Figure 15D] FIG. 1 illustrates an exemplary Radio Access Network (RAN) and core network. [Figure 15E] FIG. 1 illustrates another exemplary communication system. [Figure 15F] 1 is a block diagram of an exemplary apparatus or device, such as a wireless transmit / receive unit (WTRU); [Figure 15G] FIG. 1 illustrates an exemplary computing system. DETAILED DESCRIPTION OF THE INVENTION

[0006] A list of acronyms that may be used herein is provided in Table 1 below. In an NR (i.e., 5G) system, the N1 interface between the UE and the access and mobility management function (AMF) uses the non-access stratum (NAS) mobility management (MM) protocol (NAS-MM). As used herein, the terms "NAS-MM" and "NAS" (e.g., NAS without a suffix) may be used interchangeably. The N1 NAS signaling connection is used for both registration and connection management (RM / CM) and for UE messages and procedures related to session management (SM).

[0007] The UE also uses the N1 interface to communicate with other core network functions other than the AMF. When the UE uses the N1 interface to communicate with core network functions other than the AMF, messages exchanged between the UE and the other network functions are carried over the NAS-MM protocol.

[0008] There are several cases of protocols between the UE and core network functions (except AMF) that need to be transported over the N1 interface via the NAS-MM protocol. Other core network functions that the UE communicates with over the N1 interface are the Session Management Function (SMF), Short Message Service Function (SMSF), Policy Control Function (PCF), and Location Management Function (LMF). Figure 1 shows examples of these various network functions.

[0009] The NAS-MM protocol is used to perform procedures between the UE and the AMF. Procedures performed between the UE and the AMF may affect the UE's Registration Management (RM) and Connection Management (CM) state machines. The NAS-MM protocol is also used to send messages to the AMF, which the AMF forwards to other network functions, such as the SMF, SMSF, PCF, or LMF. The NAS-MM protocol is illustrated in Figure 2. The 5G NAS-MM protocol is specified in 3GPP TS 24.501, Non-Access-Stratum (NAS) Protocol for 5G System (5GS); Stage 3.

[0010] The NAS-MM context is information stored in the UE and the AMF necessary to maintain the N1 connection between the UE and the AMF. The NAS-MM context may include NAS security credentials and a 5G globally unique temporary identifier (GUTI).

[0011] The UE and AMF maintain separate registration management (RM) states for the UE. The RM states are RM-DEREGISTERED and RM-REGISTERED. In the RM-DEREGISTERED state, the UE is not registered with the network. The UE context in the AMF does not hold valid location or routing information for the UE, so the UE is not reachable by the AMF. The UE may be considered unavailable. However, some parts of the UE context may still be stored in the UE and AMF, for example, to avoid performing authentication procedures during every registration procedure.

[0012] In the RM-DEREGISTERED state, the UE attempts to register with the network. If the registration is accepted, the UE moves to the RM-REGISTERED state. In the RM-REGISTERED state, the UE is registered with the network and can receive services that require registration to the network. In the RM-REGISTERED state, the UE can perform registration updates and send service requests. If the UE performs a deregistration procedure or the registration request is rejected, the UE moves to or remains in the RM-DEREGISTERED state. The RM states in the UE are shown in Figure 3. The RM states in the AMF are shown in Figure 4.

[0013] The 5G MM substate of the RM-REGISTED state is sometimes referred to as the 5G MM-REGISTERED state. The RM-DEREGISTED state is sometimes referred to as the 5G MM-DEREGISTERED state. The 5G MM-REGISTERED state and the substates of the 5G MM-DEREGISTERED state are described in 3GPP TS 24.501.

[0014] Connection Management (CM) involves establishing and releasing a NAS signaling connection between the UE and the AMF over the N1 interface. Two CM states are used to reflect the UE's NAS signaling connection with the AMF. The two states are CM-IDLE and CM-CONNECTED. A UE may have two N1 connections to the same AMF: one connection via 3GPP access and another via non-3GPP access. A separate CM state is maintained for each access.

[0015] A UE in CM-IDLE state does not have an established NAS signaling connection with the AMF via N1. A UE in CM-CONNECTED state has an NAS signaling connection with the AMF via N1. The NAS signaling connection uses a Radio Resource Control (RRC) connection between the UE and the Next Generation (NG) Radio Access Network (RAN) and an NG Application Protocol (AP) UE association between the Access Network (AN) and the AMF for 3GPP access. The CM states in the UE are shown in Figure 5. The CM states in the AMF are shown in Figure 6.

[0016] The Non-Access Stratum (NAS) Session Management (SM) protocol (NAS-SM) is used to carry session management messages between the UE and the Session Management Function (SMF). NAS-SM messages pass through the AMF but are not interpreted by the AMF. This is shown in Figure 7.

[0017] An SM context is created when a UE establishes a Protocol Data Unit (PDU) session. During the PDU session establishment procedure, the AMF invokes the SMF's Nsmf_PDUSession_CreateSMContext request service operation to request that the SMF create an SM context for the UE's requested PDU session. The SMF sends an Nsmf_PDUSession_CreateSMContext response to the AMF. The response includes an SM context identifier (ID) and an N1 message container. The SM context ID identifies the PDU session context stored in the SMF for the UE's PDU session. The N1 message container is a NAS-SM message sent to the UE over NAS-MM messaging.

[0018] The SM context stored in the SMF is listed in Table 6.1.6.2.39-1 of 3GPP TS 29.502, 5G Systems; Session Management Services; Stage 3. The SM context includes a PDU Session ID, a Data Network Name (DNN), a Single Network Slice Selection Assistance Information (S-NSSAI), and an Internet Protocol (IP) address. The information in the SM context is associated with a PDU session.

[0019] The UE, AMF, RAN, PCF, or SMF can initiate the release of a PDU session. The UE sends a PDU session release request to the SMF via the N1 interface. In the N1 message, the UE identifies the PDU session using the PDU session ID. The AMF forwards the N1 message to the SMF by invoking the Nsmf_PDUSession_UpdateSMContext service operation. The SMF then sends a Nsmf_PDUSession_UpdateSMContext response to the AMF. The response includes an N2 SM resource release request and an N1 SM container. The N1 SM container includes a PDU session release command. The N2 SM resource release request is sent by the AMF to the RAN, and the N1 SM container is a NAS-SM message sent by the AMF to the UE via the N1 interface. The Nsmf_PDUSession_UpdateSMContext response includes an N1 SM container containing a PDU session release command and an N2 SM resource release request, which indicates to the AMF, UE, and RAN, respectively, that any context associated with the PDU session may be deleted.

[0020] The AMF can invoke the Nsmf_PDUSession_ReleaseSMContext service operation to request the release of the PDU session and trigger the deletion of the SM context in the UE, SMF, RAN, PCF, and AMF. The PCF can initiate the SM policy-related termination procedure as defined in clause 4.16.6 of 3GPP TS 23.502, Procedures for the 5G System (5 GS), Stage 2, to request the release of the PDU session and trigger the deletion of the SM context in the UE, SMF, RAN, PCF, and AMF. The RAN can send an N2 message to request the release of the PDU session and trigger the deletion of the SM context in the UE, SMF, RAN, PCF, and AMF.

[0021] Figure 8 shows the deregistration procedure initiated by the UE. Note that when the UE sends a deregistration request to the network, the AMF invokes the Nsmf_PDUSession_ReleaseSMContext request service operation with any SMF with which the UE has an established PDU session. This service call causes the UE's SM context to be deleted in the SMF, User Plane Function (UPF), and Unified Data Management (UDM). This is shown in Figure 8, which shows the AMF sending the Nsmf_PDUSession_ReleaseSMContext request in step 2.

[0022] Figure 9 shows a network initiated deregistration procedure. In the network initiated deregistration procedure, the AMF also invokes the Nsmf_PDUSession_ReleaseSMContext request service operation with any SMF with which the UE has an established PDU session. This service call causes the UE's SM context to be deleted in the SMF, UPF, and UDM. This is shown in Figure 9.

[0023] The 3GPP 5G Core Network Architecture (5GC) supports the PDU connection service, which provides the exchange of PDUs between a UE and a data network identified by a DNN. The PDU connection service is supported via a PDU session established upon request from the UE. PDU sessions are established (upon UE request), modified (upon UE and 5GC request), and released (upon UE and 5GC request) using NAS SM signaling exchanged over the N1 interface between the UE and SMF via the AMF. Upon request from an application server (AS), the 5GC can trigger a specific application in the UE. Upon receiving the trigger message, the UE passes it to the identified application in the UE. The identified application in the UE can establish a PDU session to a specific DNN.

[0024] A PDU session can be associated with an S-NSSAI and a DNN. In a PDU session establishment request sent to the network, the UE provides a PDU session identifier. The PDU session ID is unique per UE and is an identifier used to uniquely identify one of the UE's PDU sessions. The PDU session ID is stored in the UDM to support handover between 3GPP and non-3GPP accesses when different Public Land Mobile Networks (PLMNs) are used for these two accesses.

[0025] Each PDU session supports a single PDU session type, i.e., the exchange of a single type of PDU requested by the UE when the PDU session is established. The following PDU session types are defined: IPv4, IPv6, IPv4v6, Ethernet, and unstructured.

[0026] A UE may establish multiple PDU sessions for the same data network or different data networks simultaneously via 3GPP and non-3GPP access networks. A UE may establish multiple PDU sessions for the same data network (DN) and be served by different UPF terminations N6. A UE with multiple established PDU sessions may be served by different SMFs. The SMF serving a PDU session (e.g., anchor) does not change during the lifetime of the PDU session. Figure 10 shows the protocol stack for user plane transport related to a PDU session.

[0027] 3GPP 5G networks can support several Session and Service Continuity (SSC) modes: SSC Mode 1, SSC Mode 2, and SSC Mode 3. In SSC Mode 1, the network preserves the connectivity service provided to the UE. For PDU sessions of IPv4, IPv6, or IPv4v6 type, the IP address is preserved. The UPF, which acts as the PDU session anchor when the PDU session is established, is maintained regardless of the access technology (e.g., access type and cell) that the UE continuously uses to access the network. For PDU sessions of IPv4, IPv6, or IPv4v6 type, IP continuity is supported regardless of UE mobility events. SSC Mode 1 can be applied to any PDU session type and any access type.

[0028] In SSC Mode 2, the network can release the connectivity service delivered to the UE and release the corresponding PDU session(s). In case of IPv4, IPv6 or IPv4v6 type, the release of the PDU session induces the release of the IP address(es) assigned to the UE. If the SSC Mode 2 PDU session has a single PDU session anchor, the network can trigger the release of the PDU session and instruct the UE to immediately establish a new PDU session to the same data network.

[0029] The trigger conditions depend on operator policies, e.g., requests from Application Functions (AFs), based on load conditions, etc. When a new PDU session is established, a new UPF can be selected to act as the PDU session anchor. Alternatively, if an SSC Mode 2 PDU session has multiple PDU session anchors (e.g., in the case of a multi-homed PDU session or if a UL CL is applied to an SSC Mode 2 PDU session), additional PDU session anchors may be released or allocated. SSC Mode 2 can be applied to any PDU session type and any access type.

[0030] In SSC mode 3, a connection is established via a new PDU session anchor point before the previous connection is terminated to allow for better service continuity. For IPv4 or IPv6 or IPv4v6 types, IP addresses are not preserved in this mode when the PDU session anchor changes.

[0031] For SSC Mode 3 PDU sessions, the network allows the UE to establish connectivity via a new PDU session anchor to the same data network before the connectivity between the UE and the previous PDU session anchor is released. When a trigger condition applies, the network decides whether to select a PDU session anchor UPF that is suitable for the UE's new condition (e.g., point of attachment to the network).

[0032] In Release 16, SSC Mode 3 only applies to IP PDU session type and any access type. After a new IP address / prefix is ​​allocated, the old IP address / prefix is ​​maintained for a certain time indicated to the UE via NAS signaling or via Router Advertisement, and then released. If an SSC Mode 3 PDU session has multiple PDU session anchors, additional PDU session anchors may be released or assigned.

[0033] The application layer context is information stored in the UE and used by the UE application to communicate with the network server. The application layer context is also stored in the network server that hosts the network application that communicates with the UE application.

[0034] The UE application context includes an IP address, a port number, security credentials, a user identity, and an application identifier.

[0035] The Data Network Name (DNN) in 5G systems is equivalent to the Access Point Name (APN) in LTE, see 3GPP TS 23.501, System Architecture for the 5G System (5GS); Stage 2; both identifiers have equivalent meanings between their respective systems and carry similar information.

[0036] DNNs can be used, for example, to: First, select the SMF and UPF(s) for the PDU session. Second, select the N6 interface(s) for the PDU session. Third, it determines the policy that applies to this PDU session.

[0037] A wildcard DNN is a value that can be used in the DNN field of the subscribed DNN list of the session management subscription data defined in clause 5.2.3.3 of TS 23.502. A wildcard DNN can be used with an S-NSSAI for an operator to allow a subscriber to access any data network supported within the network slice associated with the S-NSSAI.

[0038] 5GC supports the PDU connection service. The PDU connection service is supported via a PDU session established upon request from the UE. The subscription information for each S-NSSAI may include a subscribed DNN list and one default DNN. When the UE does not provide a DNN in the NAS message containing the PDU session establishment request for a given S-NSSAI, the serving AMF determines the DNN for the requested PDU session by selecting the default DNN for this S-NSSAI if a default DNN exists in the UE's subscription information. Otherwise, the serving AMF selects a locally configured DNN for this S-NSSAI.

[0039] It is expected that the URSP in the UE is always up to date using the procedures defined in TS 23.502, clause 4.16.12.2, and therefore the DNN requested by the UE is up to date.

[0040] To cover not only the case where the UE operates using a local configuration, but also other cases where an operator policy can be used to replace the "latest" UE-requested DNN with another DNN that is only used internally within the network, during the UE registration procedure the PCF can indicate to the AMF the operator policy to be used during PDU session establishment for DNN replacement of UE-requested DNNs. The PCF can indicate a policy for DNN replacement of UE-requested DNNs that are not supported by the network and / or can indicate a list of UE-requested DNNs per S-NSSAI valid for the serving network that are subject to replacement (details are described in TS 23.503).

[0041] If the DNN provided by the UE is not supported by the network and the AMF is unable to select an SMF by querying the NRF, the AMF shall reject the NAS message containing the PDU session establishment request from the UE with a cause indicating that the DNN is not supported, unless the PCF provides a policy to perform DNN substitution for the unsupported DNN.

[0042] If a DNN requested by the UE is indicated for substitution, or if a DNN provided by the UE is not supported by the network and the PCF has provided a policy for performing DNN substitution for a UE-requested DNN that is not supported by the network, the AMF shall interact with the PCF to perform the DNN substitution. During the PDU session establishment procedure, as a result of the DNN substitution, the PCF provides a list of selected DNNs for substitution applicable to the S-NSSAI requested by the UE during PDU session establishment. The AMF uses the selected DNN in a query to the NRF for SMF selection and provides both the requested DNN and the selected DNN to the selected SMF. Note that when DNN substitution is performed in the network, interaction between the AMF and the PCF is required.

[0043] AMF selection is a procedure performed by a 5G-AN (e.g., a base station). This procedure is used to select an AMF instance that serves a UE. AMF selection is also a procedure that can be performed by an AMF. If the AMF determines that the AMF is not a suitable AMF to serve the UE, the AMF may perform a procedure to select another AMF to serve the UE. For example, this may occur when the UE attempts to register with a different network slice.

[0044] When the 5G-AN performs AMF selection, it takes into account the slice requested by the UE and other information such as local operator policies, UE properties (e.g., RAT type), etc.

[0045] The AMF allocates a 5G Globally Unique Temporary Identifier (5G-GUTI) to the UE, which is common for both 3GPP and non-3GPP access. The same 5G-GUTI can be used to access 3GPP and non-3GPP access security contexts within the AMF for a given UE. The AMF can re-allocate a new 5G-GUTI to the UE at any time.

[0046] 5G-GUTI is constructed as follows: <5G-GUTI>:= <guami><5G-TMSI> Here, GUAMI identifies one or more AMF(s).

[0047] The globally unique AMF ID (GUAMI) is constructed as follows: <guami> := <mcc> <mnc><AMF Region ID><AMF Set ID><AMF Pointer>

[0048] 5G-S-TMSI is a shortened form of GUTI to enable more efficient radio signaling procedures (e.g., during paging and service requests) and is defined as follows: <5G-S-TMSI>:=<AMF Set ID><AMF Pointer> <5G-TMSI>

[0049] The UE Route Selection Policy (URSP) contains a prioritized list of URSP rules. See 3GPP TS 23.503 Policy and Charging Control Framework for the 5G system (5GS); Stage 2, and Table 2 below. The structure of the URSP rules is described in Tables 3 and 4 below.

[0050] The Route Selection Descriptor (RSD) contains one or more of the following components: - Session and Service Continuity (SSC) Mode: Indicates that the traffic of the matching application is routed over PDU sessions that support the included SSC mode. - Network Slice Selection: Indicates that the traffic of the matching application is to be routed through a PDU session that supports one of the included S-NSSAIs. - DNN Selection: Indicates that the traffic of the matching application is routed through a PDU session that supports one of the included DNNs. If a DNN is used in the traffic descriptor, the corresponding RSD of the rule shall not include a DNN Selection component. - PDU Session Type Selection: Indicates that the traffic of the matching application is routed through a PDU session that supports the included PDU session type. - Non-seamless offload notification: Indicates that the traffic of the matching application is offloaded to a non-3GPP access outside the PDU session if the rule applies. If this component is present in the RSD, no other components are included in the RSD. - Access Type Preference: This indicates the access type (3GPP or non-3GPP) if the UE needs to establish a PDU session when the rule applies.

[0051] One URSP rule with a "match all" traffic descriptor is used to route traffic of an application that does not match any other URSP rule and is evaluated with the lowest priority in the rule priority. The RSD in this URSP rule contains at most one value for each route selection component. However, it should be noted that TS 23.503 states that "If the UE fails to establish a PDU session with any of the route selection descriptors, the UE shall try other URSP rules in the order of rule priority that have matching traffic descriptors, except for the URSP rule with a "match all" traffic descriptor, if any. In this case, the UE shall not use the UE local configuration."

[0052] Route selection validation criteria, or simply validation criteria, are defined in TS 23.503. Route selection validation criteria consist of a list of attributes whose configured values ​​must be satisfied for an RSD in a URSP to be valid. Table 4 shows a list of route selection validation criteria, including time window and location criteria.

[0053] With respect to time windows, the route selection descriptor is not considered valid unless the UE is within the time window. With location criteria, the route selection descriptor is not considered valid unless the UE's location matches the location criteria.

[0054] Furthermore, when the route selection descriptor includes a time window or location criteria, PDU sessions are considered to match only if the PDU sessions are associated with the same time window or location criteria validity condition. However, UE support for validation criteria in URSP rules is optional. If a non-supporting UE receives validation criteria, it ignores the validation criteria part of the RSD and uses the rest of the RSD.

[0055] The UE may be provisioned with URSP rules by the PCF of the HPLMN. When the UE is roaming, the PCF in the HPLMN may update the URSP rules in the UE. In addition, the UE may also be pre-configured (e.g., by an operator) with URSP rules. If both PCF-provisioned and pre-configured URSP rules exist, only the PCF-provisioned URSP rules are used by the UE.

[0056] For each newly detected application, the UE shall evaluate the URSP rules in the order of rule priority to determine whether the application matches the traffic descriptor of any URSP rule. When a URSP rule is determined to be applicable to a given application, the UE shall select an RSD within this URSP rule in the order of route selection descriptor priority information name.

[0057] If a valid RSD is found, the UE determines whether an existing PDU session exists that matches all components in the selected RSD. If a matching PDU session exists, the UE associates the application with the existing PDU session and, for example, routes the traffic of the detected application over this PDU session. If none of the existing PDU sessions match, the UE attempts to establish a new PDU session using the values ​​specified by the selected RSD. If the PDU session establishment request is accepted, the UE associates the application with this new PDU session.

[0058] An RSD of a URSP rule is considered valid if the following conditions are met: - if any S-NSSAI(s) are present, the S-NSSAI(s) are within the allowed NSSAI(s); and - If any DNN exists and the DNN is an LADN DNN, the UE shall ensure that this LADN is in its area of ​​availability.

[0059] The V-PCF can retrieve ANDSP and URSP from the H-PCF via N24 / Npcf. When the UE is roaming and has valid rules from both the HPLMN and the VPLMN, the UE gives priority to the valid ANDSP rule from the VPLMN.

[0060] The URSP rules are used to associate application traffic with existing or new PDU sessions. If the application cannot be associated with any PDU session, the UE can inform the application that the association of the application to the PDU session failed. Note that the UE can periodically check whether the PDU sessions are in use. If they are not in use, the UE can initiate a PDU session release.

[0061] For each new application flow that needs to be established, the UE evaluates the URSP rules in the order of rule priority, and then the UE triggers PDU session establishment or uses an existing PDU session for the flow. The location attribute is a URSP rule constraint that must be valid for the URSP rule to be applicable. That is, when the route selection descriptor includes a time window or location criteria, the traffic flow is considered to match only if the UE's location meets the location criteria validity condition. In addition, TS 23.503 describes that the UE (re)evaluates the validity of URSP rules in a timely manner when certain conditions are met. For example, the URSP is updated by the PCF in the following cases: The UE moves from EPC to 5GC. Changes to permitted or constituted NSSAIs LADN DNN availability changes The UE registers via 3GPP or non-3GPP access. The UE establishes a connection to the WLAN access.

[0062] According to 3GPP TS 24.526, User Equipment (UE) Policies for 5G Systems (5GS); Stage 3, the UE may reevaluate the URSP rules to check whether a change in association of an application to a PDU session is required when: The UE performs periodic URSP rule re-evaluation based on the UE implementation. The UE NAS layer indicates that an existing PDU session used to route application traffic based on URSP rules is to be released. · URSP is updated by PCF. The UE NAS layer indicates that the UE will perform an inter-system change from S1 mode to N1 mode. The UE NAS layer indicates that the UE has successfully registered in N1 mode via 3GPP or non-3GPP access. The UE establishes or releases a connection to a WLAN access, and the transmission of application PDUs via non-3GPP accesses outside a PDU session becomes available / unavailable. The permitted NSSAI is changed; or LADN information is changed.

[0063] If the re-evaluation leads to a change in the association of applications to PDU sessions, the UE may implement such changes immediately or when the UE returns to 5GMM-IDLE mode. The URSP handling layer may request the UE NAS layer to release existing PDU sessions after the re-evaluation.

[0064] 11A-11D are copied from 3GPP TS 23.502 showing the PDU session establishment process in the non-roaming and roaming with local breakout cases. This procedure is used by the UE to establish a new PDU session.

[0065] The UE or network requested PDU session modification procedure (non-roaming and roaming with local breakout scenarios) is depicted in Figures 12a-c, which are copied from 3GPP TS 23.502. The procedure is used by the UE or the network to modify the PDU session.

[0066] The term UE may refer to a mobile phone, a mobile computer, a mobile broadband adapter, a connected vehicle, a connected device, etc. that can connect to a cellular network. A UE may have a Mobile Termination (MT) portion that provides a cellular radio interface and a Terminal Equipment (TE) portion that provides services to a user and typically does not provide functionality specific to the cellular radio interface portion. For example, the TE may provide a control GUI. The TE and MT portions of a UE can communicate via AT commands. Some example AT commands are defined in 3GPP TS 27.007.

[0067] The UE may also have a SIM that stores user authentication information and network identification information. It should be understood that the ideas herein apply equally to devices that do not have a SIM for storing user authentication information and network identification information. Instead, the device may store user authentication information and network identification information in other forms of non-volatile memory. Thus, all ideas herein described as applying to a UE can apply equally to any device.

[0068] There are events that require 5G Mobility Management (MM) context deletion, but also cause 5G Session Management (SM) context deletion (and therefore application layer). For example, when there is an OS update, a modem reset, or a deregistration request initiated by the network with a "re-registration request", the UE's 5G MM context must be cleared. However, these events also cause the 5G SM context and application layer information to be deleted. There are also situations in which the UE needs to deregister from the network and re-register with the network.

[0069] In a first example, when a UE is connected to the network for emergency services and higher layers indicate that emergency services are no longer needed, the UE may perform a UE-initiated deregistration procedure followed by re-registration to regain normal service. The UE-initiated deregistration procedure is described in section 4.2.2.3.2 of 3GPP TS 23.502.

[0070] In a second example, the network (e.g., AMF) can send a deregistration request to the UE along with a re-registration request notification. The AMF can be triggered to send this message by the O&M system. The purpose of the O&M request may be to register the UE with a new AMF or simply to reset the MM context of the UE, but current 5G system designs require that both the MM and SM contexts be deleted when the deregistration procedure is performed. The network-initiated deregistration procedure is described in Section 4.2.2.3.3 of TS 23.502.

[0071] In a third example, the network (e.g., AMF) can initiate a network-initiated deregistration if it detects that the UE's registered PLMN is not authorized to operate in the UE's current location. In this case, the AMF includes the country in which the UE is located in the deregistration request. Note that this deregistration procedure deletes the UE's SM context. However, the SM context may be anchored to an H-SMF instance that is authorized to operate in the UE's current location. The network-initiated deregistration procedure is described in TS 23.502, clause 4.2.2.3.3.

[0072] In the three examples listed above, the deletion and recreation of the NAS-MM context may be sufficient, but the NAS-SM context is also deleted. Deletion of the NAS-SM context, including the UE's IP address(es), will often result in the deletion of at least some application layer context. For example, in the three examples listed above, a change of IP address will typically cause applications hosted by the UE to re-establish application layer connections and recreate or update application layer contexts. Of course, the re-establishment or recreation of application layer contexts occurs only after the UE has re-established the PDU session and a new NAS-SM context has been created.

[0073] The 5G system enhancements described herein may enable the UE and network to delete the NAS-MM context without deleting the NAS-SM context. Specifically, the network may be able to identify whether the UE is capable of preserving the NAS-SM context during a NAS-MM reset. The network and UE may be able to identify which portions of the NAS-SM context need to be preserved during a NAS-MM reset. The network and UE may be able to initiate a NAS-MM reset procedure such that the identified portions of the NAS-SM context are preserved during a NAS-MM reset. The network and UE may be able to store the NAS-SM context during a NAS-MM reset. The network and UE may be able to initiate NAS-SM context restoration and NAS-MM context creation, and the UE may be able to notify the UE-hosted application that the NAS-SM context and connectivity have been restored, which may then notify the network application server that connectivity has been restored.

[0074] Described herein are methods, apparatus, and systems for preserving and re-establishing or restoring a 5G SM context, and therefore an application layer context, when an event triggers deletion and re-establishment of the 5G MM context. Figure 13 shows an example method for preserving and re-establishing or restoring a 5G SM context. The method of Figure 13 may enable a WTRU, such as a UE, and the network to perform a NAS-MM reset without performing a NAS-SM reset.

[0075] In step 1, a WTRU, such as a UE, may perform initial registration with the network. For example, the WTRU may send a registration request message to a network node requesting to register with the network. The registration request message may include a notification that the WTRU is capable of preserving context information associated with communications between the WTRU and the network when the WTRU becomes unavailable to the network. For example, the WTRU (e.g., a UE) may indicate to the network that it is capable of preserving NAS-SM context while performing a NAS-MM reset. As described further below, the WTRU may send this information to the network so that the network knows that it can initiate a NAS-MM reset procedure such that the NAS-SM context is preserved in the WTRU and the network. The WTRU may also send this information to the network so that the network knows it is advantageous to select an SMF for serving the WTRU that is capable of preserving the WTRU's NAS-SM context when there is a NAS-MM reset.

[0076] The WTRU may receive a registration accept message from the network node. The registration accept message may include a notification that the network supports preservation of context information when the WTRU becomes unavailable to the network.

[0077] In step 2, the WTRU hosted application may start. As described below, the WTRU hosted application may indicate to the network that it would like to receive a notification or alert when WTRU connectivity is about to be interrupted. Note that WTRU connectivity is interrupted when there is a NAS-MM reset.

[0078] In step 3, the WTRU may determine to establish a PDU session for application traffic. The WTRU may request establishment of a PDU session by employing the procedures shown in Figures 11A-11D. In the PDU session establishment procedure, the WTRU may indicate to the network that the NAS-SM context for the PDU session should be preserved when there is a NAS-SM context reset. For example, the WTRU may send a request to establish a PDU session to the network (e.g., in step 1 of Figure 11A). The request to establish a PDU session includes a notification that context information for the PDU session is requested to be preserved when the WTRU becomes unavailable.

[0079] In step 4, as described more fully below, the WTRU may send a message to the network indicating a request to save context information based on a determination that the WTRU will be unavailable to the network. The message may include a notification of the period of time for which the WTRU will be unavailable. For example, the WTRU may notify the AMF that a NAS-MM context reset is desired, or the AMF may notify the WTRU that a NAS-MM context reset is desired. As described more fully below, such an indication or notification may occur as part of an N1 Reset Request message or a UE-initiated Deregistration Request message. The WTRU may prepare for the NAS-MM context reset by notifying the WTRU host application of a pending NAS-MM reset. The AMF may prepare for the NAS-MM context reset by notifying the SMF of a pending NAS-MM reset, as described further below.

[0080] In step 5, the WTRU or the network may initiate a NAS-MM reset. Four examples of how a NAS-MM reset may be initiated are described below. In a first example, the WTRU may initiate a NAS-MM reset by initiating a WTRU (e.g., UE) initiated deregistration procedure. In a second example, the AMF may initiate a NAS-MM reset by initiating a network initiated deregistration procedure. In a third example, the WTRU may initiate a NAS-MM reset by initiating a new N1 reset procedure. In a fourth example, the AMF may initiate a NAS-MM reset using a new N1 reset procedure.

[0081] In step 6, the NAS-SM context may be stored in the WTRU (e.g., UE), SMF, PCF, UPF, and / or UDM / UDR. This is further described below. As mentioned above, the SM context is listed in Table 6.1.6.2.39-1 of TS 29.502. The SM context may include a PDU session ID, DNN, S-NSSAI, and IP address. The information in the SM context is associated with the PDU session.

[0082] In step 7, after a period of time during which the WTRU has been unavailable, the WTRU may send a message to the network indicating that the WTRU is again available to the network. For example, the WTRU may initiate NAS-SM context recovery and creation of a new NAS-MM context by sending a second registration request to the network.

[0083] In step 8, the WTRU may notify the application hosted by the WTRU that connectivity has been restored, as described below. In other words, the application hosted by the WTRU may be notified when a new NAS-MM context is created and the NAS-SM context associated with the application hosted by the WTRU is restored.

[0084] In step 9, as described below, the application hosted by the WTRU may notify the AS / AF that the connectivity of the application hosted by the WTRU and its NAS-SM context have been restored.

[0085] When a WTRU (e.g., a UE) sends a NAS-MM registration message to the network, the message is carried within an RRC message to an NG-RAN node. The NG-RAN node selects an AMF and sends the NAS-MM registration message to the AMF. The UE may include a notification in the RRC portion of the message to indicate to the NG-RAN node that the UE supports and can use a feature that allows the UE's NAS-SM context to be maintained in the UE and the network while the UE's NAS-MM context is reset / deleted in the UE and the network. This feature may be referred to herein as a "persistent NAS-SM context" feature, and the notification may be referred to herein as a "persistent NAS-SM context support notification." The persistent NAS-SM context support notification may be used by the NG-RAN node to determine that the NG-RAN should select an AMF that supports the persistent NAS-SM context feature.

[0086] The UE may further include a persistent NAS-SM context support indication in the NAS-MM registration message. This persistent NAS-SM context support indication in the NAS-MM registration message may indicate to the AMF that the UE supports the persistent NAS-SM context feature and that the UE may want to use the feature. The AMF may use this information when performing SMF selection to ensure that the AMF selects an SMF that supports the feature. The AMF may send a registration accept message to the UE. The registration accept message may include an indication that the AMF supports the persistent NAS-SM context feature and that the UE may attempt to use the feature.

[0087] The AMF sends a registration accept message to the NG-RAN node, which forwards the message to the UE in an RRC message. The NG-RAN may include in the RRC part of the message a notification of whether the NG-RAN node selected an AMF that supports the persistent NAS-SM context feature.

[0088] The UE may host critical applications whose functionality and / or reliability depend on the UE's SM context being preserved during NAS-MM reset. Therefore, the UE may only wish to connect to networks that support the NAS-SM context preservation feature. The NG-RAN may broadcast a notification in the system information indicating to the UE that the NG-RAN node can select an AMF that supports the NAS-SM context feature.

[0089] In a scenario where the UE registers to the network via non-3GPP access, the UE may send a persistent NAS-SM context support notification to TWAP, TNGF, or N3IWF so that the TWAP, TNGF, or N3IWF can take the notification into account during AMF selection.

[0090] As described above, the persistent NAS-SM context support notification may be sent to the AMF in the NAS-MM registration request message. If the AMF determines that the feature cannot be supported but a different AMF can support the feature, the AMF may perform an AMF selection procedure with the NRF, provide the notification to the NRF, and determine a new AMF to serve the UE.

[0091] The UE may provide a separate persistent NAS-SM context support indication to the AMF for each S-NSSAI in the requested S-NSSAI. In other words, the UE may indicate whether it wants to use the features for each slice it requests on a slice-by-slice basis.

[0092] The UE may receive configuration information from the AMF in the registration response indicating whether the persistent NAS-SM context feature is supported for each slice of the allowed NSSAI.

[0093] Alternatively, the UE may store a configuration for each slice of the configured NSSAI. The configuration information may include an indication of whether each slice supports the persistent NAS-SM context feature. The UE may receive a persistent NAS-SM context support indication for each slice of the configured NSSAI when the UE receives the configured NSSAI in a registration accept or configuration update message.

[0094] An application on a UE may require or prefer that its SM context be preserved when the UE's MM context is reset, for example, an application may require or prefer that its IP address be preserved when the UE's MM context is reset.

[0095] When an application generates uplink traffic, the URSP rule can be used to determine that the application traffic should use a PDU session whose SM context will be preserved when the UE's MM context is reset. For example, the RSD portion of the URSP rule can include a persistent NAS-SM context selection notification. The presence of the notification in the RSD can serve as a notification to the UE that the associated traffic should be associated with a PDU session whose SM context will be preserved when the UE's MM context is reset.

[0096] Alternatively, the application may provide the activate NAS-SM context preservation notification to the ME part of the UE as part of the traffic descriptor. When the activate NAS-SM context preservation notification is part of the traffic descriptor, the UE may only select an existing PDU session for the traffic if the feature is enabled for the PDU session; otherwise, the UE will attempt to establish a new PDU session for the traffic and enable the feature for the new PDU session.

[0097] If the application provides an activate NAS-SM context preservation notification to the ME part of the UE as part of the traffic descriptor, the notification can be sent by the TE to the ME via an AT command. For example, the notification can be provided when the +CGDCONT AT command is used. The +CGDCONT AT command, defined in 3GPP TS 24.007, AT Command Set for User Equipment (UE), is used to specify PDU session parameters.

[0098] The UE may determine that there is no existing PDU session that supports the application traffic needs. The UE then sends a PDU session establishment request to the AMF. The PDU session establishment request includes an activate NAS-SM context preservation notification. The activate NAS-SM context preservation notification may be included in the NAS-MM part of the message so that the AMF can use the activate NAS-SM context preservation notification during SMF selection, thus ensuring that the AMF selects an SMF that supports the feature. The NAS-SM context preservation notification may also be part of the N1 SM container (e.g., in the NAS-SM part of the message), so that the SMF knows that the feature should be enabled for the PDU session.

[0099] Alternatively, the system may be designed such that only one SMF serves PDU sessions whose context needs to be preserved during a NAS-MM reset. In this scenario, the activate NAS-SM context preservation notification does not need to be included in the NAS-SM part of the PDU session establishment request message.

[0100] Alternatively, as previously described, the UE may be configured with a persistent NAS-SM context support notification for the S-NSSAI associated with the PDU establishment request. The persistent NAS-SM context support notification may be interpreted by the UE as a notification that the feature may be enabled for the PDU session of the slice, or the notification may be interpreted by the UE as a notification that the feature is associated with all PDU sessions of the slice. If the notification is interpreted by the UE as a notification that the feature is associated with all PDU sessions of the slice, the UE does not need to provide the notification during PDU session establishment. The UE and the network function will understand that the feature is enabled for the PDU session because the notification is included in the configuration information associated with the slice.

[0101] The PDU Session Establishment Accept message may indicate to the UE whether features are enabled for the PDU session. For example, the SMF may include a NAS-SM context preservation enablement notification in the PDU Session Establishment Accept message sent to the UE, and the UE may maintain a list of PDU sessions for which the NAS-SM context is configured for preservation during a NAS-MM reset event. The SMF may also include a NAS-SM context preservation timer to indicate to the UE how long the NAS-SM context will be preserved after a NAS-MM reset event.

[0102] The SMF may also send a NAS-SM context preservation enablement notification to the AMF when the SMF invokes the Namf_Communication_N1N2MessageTransfer service operation. The reason for sending the NAS-SM context preservation enablement notification to the AMF is that it serves as a notification to the AMF that the UE has PDU sessions whose NAS-SM context needs to be maintained during a NAS-MM reset and that it is possible to reset the UE's NAS-MM context without resetting the UE's NAS-SM context. As a result of this notification, the AMF can store, in the UE context that the AMF maintains for the UE, which PDU sessions are configured for NAS-SM context preservation when a NAS-MM reset event occurs. Then, the UE does not need to specify the PDU sessions whose NAS-SM context should be preserved during deregistration. In addition to the NAS-SM context preservation enablement indicator, the SMF may also provide a timer value for how long the NAS-SM context should be preserved. The timer value may be transmitted to both the AMF and the UE.

[0103] The NAS-SM context save activation notification can be sent by the TE to the ME via an AT command. For example, the indication may be provided when the AT command +CGDCONT=? is used. The AT command +CGDCONT=? defined in TS 27.007 is used to check or read PDU session parameters.

[0104] The persistent NAS-SM context feature can be considered an extension or improvement of SSC mode 1. When SSC mode 1 is used, the UE's IP address is preserved regardless of UE mobility events. When the persistent NAS-SM context feature is enabled, the UE's SM context, including the UE's IP address, is preserved even when there is a NAS-MM reset.

[0105] A fourth SSC mode may be considered. SSC mode 4 may also be characterized by the fact that the UE's IP address is preserved regardless of UE mobility events. However, SSC mode 4 may also be characterized by the fact that SM contexts associated with PDU sessions may be preserved during a NAS-MM reset, whereas SM contexts associated with SSC mode 1 PDU sessions are not preserved during a NAS-MM reset.

[0106] If the persistent NAS-SM context feature is associated with SSC mode 4, the UE may send a NAS-SM context preservation activation notification to the network by setting the requested SSC mode in the PDU session establishment request to 4, and the network may send a NAS-SM context preservation activation notification to the UE by setting the allowed SSC mode in the PDU session establishment accept message to 4. Table 5 below shows an example of how SSC mode 4 may be encoded and therefore indicate to the network that the activate NAS-SM context preservation notification should be enabled.

[0107] It may also be desirable to use the persistent NAS-SM context feature with SSC modes 1 and 2. While the use of SSC modes 2 and 3 implies that UE applications using PDU sessions do not require IP addresses to be preserved, enabling the persistent NAS-SM context feature may still be advantageous. Using the persistent NAS-SM context feature with any SSC mode may still be advantageous, as using the feature allows the UE and network to reduce the amount of interaction required between the UE and the network to re-establish a PDU session. Table 6 below also indicates whether the UE requests the feature to be enabled and shows an example of how the SSC mode coding may be extended to indicate whether the network has enabled the feature.

[0108] The UE may have a PDU session established with the persistent NAS-SM context feature enabled. An event may occur in the UE, and the UE may determine that the event requires the UE to reset its NAS-MM context. Resetting the NAS-MM context may be initiated by sending a deregistration request to the network. However, the UE may determine that the NAS-SM context may be preserved while the UE is in the RM-DEREGISTERED state. In the deregistration request, the UE may indicate to the network that the NAS-SM context should be preserved while the UE is in the RM-DEREGISTERED state. The AMF then notifies the SMF(s) associated with the PDU session(s) whose context needs to be preserved and can help the SMF adjust the retention timer between the UE and the SMF. The UE-initiated deregistration procedure is shown in Figure 8 and can be extended as follows:

[0109] The deregistration request in step 1 may be extended so that the UE can indicate to the AMF that the UE's NAS-SM context should be preserved while the UE is in the RM-DEREGISTERED state. The request can identify which PDU session's NAS-SM context needs to be preserved by including the PDU session ID of each PDU session for which the NAS-SM context needs to be preserved. For each PDU session for which the context needs to be preserved, the UE can include an N1 SM container. The N1 SM container may include an indication that the UE wants the NAS-SM context to be maintained and a time value indicating how long the UE requests the SMF to preserve the UE's NAS-SM context. In current 5G system designs, the UE cannot indicate to the network that the deregistration type is "re-registration required." The deregistration request in step 1 may be further extended to allow the UE to indicate to the network that the deregistration type is "re-registration required." The advantage of this allowing the UE to indicate to the network that re-registration is required is that it allows the UE to indicate to the network that it plans to re-register when, for example, the UE only needs to perform a NAS-MM reset.

[0110] Alternatively or additionally, the UE deregistration request in step 1 may be extended to allow the UE to indicate its mobility status, expected re-registration parameters (e.g., immediate vs. timed vs. event-based), and expected re-registration cause (e.g., emergency service release, O&M request). The mobility status may be used by the network to determine whether the same UPF can serve the UE upon re-registration. Similarly, other predictive information may be included in the deregistration request that may be used by the network to determine how to configure context storage and re-establishment parameters, buffering in the UPF, etc.

[0111] Alternatively or additionally, it may not be necessary to explicitly indicate to the AMF that the UE's NAS-SM context should be preserved while the UE is RM-DEREGISTERED. Rather, the AMF may assume that the UE's NAS-SM context should be preserved while the UE is RM-DEREGISTERED whenever the UE sets the Deregistration-Type IE in the Deregistration Request to "Re-registration Required". A drawback of this alternative would be that the NAS-SM context may be preserved in the network even if the UE prefers that it not be preserved.

[0112] Previously, it was explained that whenever the NAS-SM context preservation enable indicator is provided by the SMF to the AMF in the Namf_Communication_N1N2MessageTransfer service operation of the PDU session establishment procedure, the AMF may update the UE context it maintains. If the AMF maintains a list of PDU sessions for which the NAS-SM context should be preserved, the UE only needs to perform a deregistration request to the AMF. In addition, the AMF may also be provided with a timer value for how long to preserve the NAS-SM context for the UE, and upon receiving a deregistration request from the UE, the AMF starts the timer. If the UE does not re-register before the timer expires, the AMF deletes the remaining NAS-SM contexts preserved for the UE.

[0113] The call of the Nsmf_PDUSession_ReleaseSMContext request in step 2 may be extended such that the AMF sends both the SM context ID and the N1 SM container sent by the UE in step 1 to the SMF. The SMF can use the content of the N1 SM container to recognize that the UE will move to the RM-DEREGISTED state and that the NAS-SM context should be preserved. The N1 SM container may include a retention expiration timer. Alternatively, step 2 may call Nsmf_PDUSession_UpdateSMContext, which may enable the establishment of a forwarding tunnel between UPFs controlled by different SMFs. The procedure of Figure 8 may be extended such that step 3 is skipped, or step 3 may be extended such that the SMF informs the UPF that the UE will move to the RM-DEREGISTED state and that the NAS-SM context should be preserved. The benefit of the UE moving to RM-DEREGISTED state and informing the UPF that the NAS-SM context should be preserved is that the UPF knows to buffer or discard any DL packets received for the PDU session. The SMF can indicate to the UPF whether packets should be buffered or discarded.

[0114] The call of the Nsmf_PDUSession_ReleaseSMContext response in step 4 may be extended so that the SMF may provide the SM context storage ID and the SM context storage expiry timer to the AMF and the N1 SM container. The N1 SM container may also include the SM context storage ID and the SM context storage expiry time. The SM context storage ID is an identifier of the SM context. The SM context storage ID may identify the storage location where the SM context is stored. For example, the storage location may be associated with the SMF, UDSF, or UDM / UDR. The SM context storage expiry time may be stored with the SM context. The SMF can use the time value that the UE included in the N1 SM container to derive the SM context storage expiry time to be sent to the UE and the N1 SM container.

[0115] The procedure of Figure 8 may be extended such that step 5a is skipped, or step 5a may be extended such that the SMF informs the PCF that the UE will move to RM-DEREGISTED state and that the NAS-SM context should be preserved.

[0116] The procedure of Figure 8 may be extended so that steps 5b-c are skipped, or steps 5b-c may be extended so that instead of unsubscribing from the UDM or indicating to the UDM that the UDM should remove the association it had stored between the SMF identity and the associated DNN and PDU session Id, the SMF sends the SM context to the UDM and requests that the UDM store the SM context.

[0117] The procedure of Figure 8 may be extended such that step 7 is extended so that the deregistration accept sent by the AMF to the UE includes an N1 SM container sent by the SMF to the AMF. The N1 container may indicate to the UE which parts of the NAS-SM context are preserved (e.g., whether the UE's IP address is preserved during NAS-MM reset, whether QoS rules for some flows are maintained, etc.). Multiple N1 SM containers may be sent to the UE (e.g., one N1 SM container may be sent to the UE for each PDU session, and an N1 SM container may be sent by the SMF hosting the PDU session).

[0118] The UE may display a graphical user interface (GUI) that allows a user to initiate a NAS-MM reset. The GUI may further allow a user to select which UE applications should preserve their context during the NAS-MM reset. The UE may then determine that any PDU session(s) associated with the selected UE application(s) should have their SM context preserved during the NAS-MM reset, and the UE may then include PDU session IDs of the PDU sessions associated with the selected UE applications in a UE-initiated deregistration request.

[0119] An event may occur in the network, and the network may determine that the event requires the UE to reset its NAS-MM context by sending a deregistration request to the UE, but that the NAS-SM context may be preserved while the UE is in RM-DEREGISTERED state. The network may indicate to the UE in the deregistration request that the NAS-SM context should be preserved while the UE is in RM-DEREGISTERED state, and may further indicate how long the NAS-SM context will be preserved before the PDU session is re-established (e.g., registration and re-establishment by a timer). The AMF may then notify the SMF(s) associated with the PDU session(s) whose context needs to be preserved and help to adjust the preservation timers between the UE and the SMF. The notification from the AMF may further indicate how long the NAS-SM context will be preserved before the PDU session is re-established (e.g., registration and re-establishment by a timer). A network-initiated deregistration procedure is shown in Figure 9 and may be extended as follows:

[0120] In step 2, the event may trigger the AMF to send a deregistration request to the UE. The deregistration request may be extended so that the AMF may indicate to the UE that the UE's NAS-SM context should be preserved while the UE is RM-DEREGISTERED. The request may identify which PDU session's NAS-SM context needs to be preserved by including the PDU session ID of each PDU session whose NAS-SM context needs to be preserved. For each PDU session whose context needs to be preserved, the AMF may include an N1 SM container. The N1 SM container may include an indication that the network wants the NAS-SM context to be maintained and a time value indicating how long the UE should preserve the UE's NAS-SM context.

[0121] The deregistration request may also include a timer-based deregistration, which may indicate to the UE that it should deregister before the timer expires. The advantage of providing such a timer, compared to requesting that the UE deregister immediately, is that the ME portion of the UE can send a deregistration alert notification to applications hosted by the TE portion of the ME. Applications that receive the alert can then save their associated application layer context and send alerts to any application servers with which they communicate. The alert to the application server may be sent via the user plane and may indicate a time window when the UE application may be unavailable. An AT command may be used to send the alert notification from the ME portion of the UE to applications hosted on the TE portion of the UE.

[0122] Alternatively, there may be no need to explicitly indicate to the UE that its NAS-SM context should be preserved while it is RM-DEREGISTERED. Rather, the UE can assume that its NAS-SM context should be preserved while it is RM-DEREGISTERED whenever the AMF sets the Deregistration-Type IE in the Deregistration Request to "Re-registration Required". A drawback of this alternative would be that the NAS-SM context may be preserved in the network even when the AMF prefers that the NAS-SM context not be preserved.

[0123] The procedure of Figure 9 may be extended so that steps 3 and 3a are skipped, or steps 3 and 3a may be extended so that instead of unsubscribing from the UDM or indicating to the UDM that the UDM should remove the stored association between the SMF identity and the associated DNN and PDU session Id, the SMF sends the SM context to the UDM and requests that the UDM store the SM context.

[0124] Step 4 of the procedure of Figure 9 may be extended in the same manner as steps 2 to 5 of the UE-initiated deregistration procedure described above.

[0125] Steps 5 and 5a of the procedure of Figure 9 may be extended in the same way as steps 6 and 6a of the UE initiated deregistration procedure described above.

[0126] Step 6 of the procedure in Figure 9 may be extended when the UE sends a deregistration accept message to indicate to the network whether the UE will store the SM context for each PDU session. For example, the deregistration accept message may include a notification for each PDU session for which the UE will store its SM context while the UE is in the RM-DEREGISTERED state. The message may further indicate to the AMF how long the UE will store the SM context.

[0127] Alternatively, the procedure of Figure 9 may be extended so that the AMF does not request the SMF, UDM, and PCF to store the SM context until after the AMF receives the deregistration accept message. The advantage of this approach is that if the UE indicates that it will not store some or all of the SM contexts of the PDU session SM contexts that the AMF requested the UE to store in the deregistration request in step 2, the AMF can avoid performing the operations required to ask the UDM, PCF, and SMF to store the SM contexts.

[0128] The UE may display a graphical user interface (GUI) that allows the user to be notified when network-initiated registration is requested by the network. The GUI may further allow the user to select which UE applications should preserve their context during NAS-MM reset. The UE may then determine that any PDU session(s) associated with the selected UE application(s) should have their SM context preserved during NAS-MM reset, and the UE may then include the PDU session IDs of the PDU sessions associated with the selected UE applications in the deregistration accept message.

[0129] In a different example, the user may have used the GUI to configure which applications need or prefer to have their NAS-SM context preserved during a NAS-MM reset. The UE can then use this information to determine to indicate to the network in a PDU session establishment request that associated PDU sessions need to have their NAS-SM context preserved during a NAS-MM reset.

[0130] As shown in Figures 3 and 4, the NAS-MM context of the UE is reset in the UE and the AMF when the UE moves to the RM-DEREGISTERED state. Therefore, the methods described herein can be applied to how the NAS-SM state of the UE is preserved even when the UE is in the RM-DEREGISTERED state.

[0131] An alternative approach is to not change the UE and AMF's handling of the UE NAS-MM and NAS-SM contexts when the UE is in the RM-DEREGISTERED state, but instead create a new sub-state or mode of operation within the RM-REGISTERED state. This new state or mode of operation may be called RM-REGISTERED-PAUSE and may be entered upon a NAS request from the network to the UE or from the AMF to the UE. The request may be called an N1 reset request, and may be sent by the AMF to the UE or by the UE to the AMF, and may cause the UE to reset its NAS-MM context. Figure 14 shows how the AMF and UE RM state models may be extended to support the RM-REGISTERED-PAUSE state.

[0132] As shown in Figure 14, the UE and AMF can enter the RM-REGISTERED-PAUSE state from the RM-REGISTERED state upon completion of the N1 reset procedure. The UE and AMF can enter the RM-REGISTERED state from the RM-REGISTERED-PAUSED state upon completion of the registration procedure. The UE and AMF can enter the RM-DEREGISTERED state from the RM-REGISTERED-PAUSED state when the SM context storage expiration timer expires.

[0133] In the RM-REGISTERED-PAUSED state, the UE's NAS-MM context may be reset and the UE's NAS-SM context may be preserved. The AMF may consider the UE unreachable in the RM-REGISTERED-PAUSED state.

[0134] To return to the RM-REGISTERED state (e.g., to send or receive data), the UE can initiate a registration procedure while in the RM-REGISTERED-PAUSE state. The UE can return to the RM-REGISTERED state upon completion of an accepted registration procedure. The UE may enter the RM-DEREGISTERED state upon expiration of the SM context storage expiration timer.

[0135] The SM context storage expiration timer may be started when the UE enters RM-REGSITERED-PAUSE state. The UE may enter RM-DEREGISTERED state if the timer expires, as long as there is no ongoing registration procedure. The UE may stop the timer when a registration procedure is initiated (e.g., when the UE is in 5GMM-REGISTERED.ATTEMPTING-REGISTRTION-UPDATE state). Time expiration may mean that the timer reaches a value of 0 or the SM context storage expiration timer value received from the network.

[0136] The RM-REGISTERED-PAUSE state may be considered a sub-state of the 5GMM-REGISTEED state. Alternative names for the RM-REGISTERED-PAUSE state may be 5GMM-REGISTERED-PAUSE or 5GMM-REGISTERED-RESETING-MM-CONTEXT.

[0137] When the UE is in the RM-REGISTERED-PAUSE state, the AMF and the UE should consider the UE to be in the CM-IDLE state because the UE's N1 connection is not active.

[0138] Note that the UE may be sent multiple SM context storage expiration timers (e.g., one for each PDU session). The UE may maintain a separate timer for each received SM context storage expiration timer value. The UE may delete the NAS-SM context associated with a PDU session when the SM context storage expiration timer associated with that PDU session expires. The UE may stop all timers when the registration procedure is initiated (e.g., when the UE is in 5GMM-REGISTERED.ATTEMPTING-REGISTRTION-UPDATE state). When all timers expire, the UE can enter the RM-DEREGISTERED state.

[0139] The UE may have a PDU session established with the persistent NAS-SM context feature enabled. An event may occur in the UE, and the UE may determine that the event requires the UE to reset its NAS-MM context by sending an N1 reset request to the network. The request may indicate that the UE will enter CM-IDLE and RM-REGISTERED-PAUSED states, that the UE's MM context should be reset, and that the UE's NAS-SM context may be preserved while the UE is in the RM-REGISTERED-PAUSED state. The AMF may then notify the SMF(s) associated with the PDU session(s) whose context needs to be preserved and help coordinate the retention timers between the UE and the SMF.

[0140] The N1 reset request may indicate to the AMF that the UE's NAS-SM context should be preserved while the UE is in RM-REGISTERED-PAUSED. The request may identify which PDU session's NAS-SM context needs to be preserved by including the PDU session ID of each PDU session whose NAS-SM context needs to be preserved. For each PDU session whose context needs to be preserved, the UE may include an N1 SM container. The N1 SM container may include an indication that the UE wants the NAS-SM context to be maintained and a time value indicating how long the UE requests the SMF to preserve the UE's NAS-SM context.

[0141] Receipt of the N1 reset request may cause the AMF to invoke the Nsmf_PDUSession_ReleaseSMContext request. As previously described, the Nsmf_PDUSession_ReleaseSMContext request may be extended so that the AMF sends both the SM context ID and the N1 SM container that the UE sent to the SMF. Using the content of the N1 SM container, the SMF can recognize that the UE will move to RM-REGISTERED-PAUSED state and that the NAS-SM context should be preserved.

[0142] The SMF call for Nsmf_PDUSession_ReleaseSMContext response may be extended so that the SMF can provide the SM context storage ID and the SM context storage expiry timer to the AMF and the N1 SM container. The N1 SM container may also include an SM context storage ID and an SM context storage expiry time. The SM context storage ID is an identifier of the SM context. The SM context storage ID can identify the storage location where the SM context is stored. For example, the storage location can be associated with the SMF, UDSF, or UDM / UDR. The SM context storage expiry time can be stored with the SM context. The SMF can use the time value that the UE included in the N1 SM container to derive the SM context storage expiry time to be sent to the UE and the N1 SM container.

[0143] The AMF may send an N1 reset accept message to the UE containing the N1 SM container sent by the SMF to the AMF.

[0144] An event may occur in the network, and the network may determine that the event requires the UE to reset its NAS-MM context by sending an N1 reset request to the UE, but that the NAS-SM context may be preserved while the UE's NAS-MM context is reset. The network may indicate to the UE in the N1 reset request that the NAS-SM context should be preserved while the UE is in RM-REGISTERED-PAUSE state. The AMF may then notify the SMF(s) associated with the PDU session(s) whose context needs to be preserved and help coordinate the preservation timers between the UE and the SMFs.

[0145] When an event triggers the AMF to send an N1 Reset Request to the UE, the N1 Reset Request can be extended so that the AMF can indicate to the UE that the UE's NAS-SM context should be preserved while the UE is in RM-REGISTERED-PAUSE. The request can identify which PDU session's NAS-SM context needs to be preserved by including the PDU session ID of each PDU session whose NAS-SM context needs to be preserved. For each PDU session whose context needs to be preserved, the AMF can include an N1 SM container. The N1 SM container can include an indication that the network wants the NAS-SM context to be maintained and a time value indicating how long the UE should preserve the UE's NAS-SM context.

[0146] The N1 reset request may also include a timer reset. The timer reset may indicate to the UE that it should enter RM-REGISETERED-PAUSE state and reset the NAS-MM context before the timer expires. The advantage of providing such a timer, compared to requesting that the UE immediately enter RM-REGISETERED-PAUSE state, is that the ME portion of the UE can send a pause alert notification to applications hosted by the TE portion of the ME. Applications that receive the alert can then save their associated application layer context and send the alert to any application servers with which they communicate. The alert to the application server may be sent via the user plane and may indicate a time window when the UE application may be unavailable. An AT command may be used to send the alert notification from the ME portion of the UE to applications hosted on the TE portion of the UE.

[0147] The UE may send an N1 reset accept message to the AMF, and the message may indicate whether the UE will preserve the SM context for each PDU session. For example, the accept message may include a notification for each PDU session for which the UE will preserve its SM context while the UE is in the RM-REGISETERED-PAUSE state. The message may also indicate to the AMF how long the UE will preserve the SM context.

[0148] As explained above, a network function, such as the AMF or UDM, can initiate a procedure to initiate a reset of the UE's NAS-MM context in the UE and the AMF. The trigger for the network function to initiate this procedure may be that the AMF needs to perform a network-initiated deregistration procedure due to an O&M request or to have the UE reconnect to a different network node, a different network, a different AMF, etc.

[0149] As explained above, the UE may initiate a procedure to initiate a reset of the UE's NAS-MM context in the UE and in the AMF. The trigger for the UE to initiate this procedure may be that the UE is connected to the network for emergency services and wishes to change the connection to a non-emergency connection, the trigger for the UE to initiate this procedure may be that the UE's configuration has changed and the configuration change requires a NAS-MM reset, or the trigger for the UE to initiate this procedure may be that the UE is installing a software update and the NAS-MM context needs to be reset and the UE cannot maintain its connection while the software update is being installed.

[0150] When the UE enters the RM-DEREGISTERED state, the UE may store or maintain the NAS-SM context for any PDU sessions for which the persistent NAS-SM context feature is enabled. The UE may determine that the persistent NAS-SM context feature is enabled based on negotiation with the network, as previously described in the descriptions of the extensions to the PDU session establishment, UE-initiated deregistration, and network-initiated deregistration procedures. As previously described, the amount of time the UE stores the NAS-SM context for each PDU session may be determined by a timer. In other words, the UE may delete the NAS-SM context if the UE detects that the timer has expired.

[0151] When the UE enters the RM-DEREGISTERED state, the SMF, UDM, PCF, and AMF may store or maintain the NAS-SM context for any PDU sessions for which the persistent NAS-SM context feature is enabled. The AMF, SMF, and UE may determine that the persistent NAS-SM context feature is enabled based on negotiation with the network, as previously described in the descriptions of the extensions to the PDU session establishment, UE-initiated deregistration, and network-initiated deregistration procedures.

[0152] As previously explained, the amount of time that the AMF, SMF, PCF, or UDM stores the NAS-SM context for each PDU session may be determined by a timer. In other words, the AMF, SMF, PCF, or UDM may delete the NAS-SM context if the AMF, SMF, PCF, or UDM detects that the timer has expired.

[0153] After resetting its NAS-MM context, the UE can send a registration request to the network to move to the RM-REGISTERED state, which may mean the UE transitioning from the RM-DEREGISTERED state to the RM-REGISTERED state, as previously described, or it may mean the UE transitioning from the RM-REGISTERED-PAUED state to the RM-REGISTERED state.

[0154] When the UE attempts to move from the RM-DEREGISTERED state to the RM-REGISTERED state, the UE sends a registration request to the network. The registration type may indicate that the UE is performing initial registration. The current 5G system design is such that the UE is not allowed to include the "list of PDU sessions to be activated" information element when performing initial registration. The registration procedure may be extended so that the "list of PDU sessions to be activated" information element can be sent by the UE to the network when performing initial registration.

[0155] The presence of the "List of PDU sessions to be activated" in the initial registration request may serve as a notification to the network that the UE wishes to re-establish the NAS-SM context that was stored in the UE while it was in RM-DEREGISTED state. The "List of PDU sessions to be activated" is conveyed to the network in the NAS PDU Session Status IE.

[0156] When the UE attempts to move from RM-REGISTERED-PAUSE state to RM-REGISTERED state, the UE sends a registration request to the network. The registration type may indicate that the UE is performing a mobility registration update, or a new registration type may be defined to explicitly indicate that the purpose of the registration request is to move to RM-REGISTERED state and restore the NAS-SM context. A "list of PDU sessions to be activated" may be included in the request to indicate which PDU session contexts should be restored.

[0157] Alternatively, the UE may send an explicit notification in a new IE to the network to indicate that the UE wants to re-establish the NAS-SM context that was stored in the UE while it was in the RM-DEREGISTED state.

[0158] Note that when the UE sends an initial or mobility registration request to the RAN, the UE provides a 5G-GUTI in the RRC portion of the message. The 5G-GUTI is associated with the AMF to which the UE last registered. It is likely that the RAN will select the same AMF that provided the 5G-GUTI to serve the UE, but this is not guaranteed. If the RAN selects a different AMF to serve the UE, re-establishment of the NAS-SM context can still proceed because the NAS-SM was stored in the UDM and SMF(s).

[0159] Note that the 5G-GUTI may be considered part of the NAS-MM context, but may be saved while the rest of the NAS-MM context is cleared. The advantage of saving the 5G-GUTI is that it can be used to assist the RAN in determining which AMF should serve the UE.

[0160] The AMF may indicate to the UE in the registration accept message that the SM context of some PDU sessions could not be restored. For example, this may occur if the UE is unable to register to a slice. In other words, this may occur if the slice associated with the PDU session is not in the UE's allowed NSSAI. If the NAS-SM context cannot be restored, the UE deletes the NAS-SM context. The AMF indicates to the UE that the SM context of a PDU session cannot be restored by including the PDU session ID in the registration accept message.

[0161] Once the context is restored, the UE may notify any applications it hosts that the SM context has been restored. For example, the notification may make the applications aware that they have network connectivity again, and the notification may trigger the applications to use the restored PDU session with the SM context restored. As a result, an application layer message may be sent to the network server to inform the server that the application has network connectivity and is available or reachable with the restored SM context (e.g., IP address).

[0162] Before a NAS-MM reset is performed, the UE may notify any applications it hosts that the NAS-MM context is about to be reset. The applications hosted by the UE may then notify the application server that the applications are about to enter a period during which the applications will not be reachable. The notification may indicate a timer value to the application server to indicate how long the application server can expect the UE applications to preserve application layer context.

[0163] The NAS-SM context preservation features described herein may be subject to validity criteria that specify conditions for feature applicability. The validity criteria may consist of one or more of a validity area criteria, a time criteria, or an access technology-related criteria such as an access technology type. For example, the validity area criteria may include one or more of a 3GPP location type, e.g., a public land mobile network (PLMN), a tracking area code (TAC), a location area code (LAC), a cell identifier, a wireless local access network (WLAN) location type, e.g., a service set identifier (SSID), a homogeneous extended SSID (HESSID), a basic SSID (BSSID), or a geographic location type in the form of a latitude, longitude, or radius, e.g., as defined in TS 23.032. The time criteria may include one or more of a time start, a time stop, a date start, a date stop, and a day of the week. The access technology standard may include one or more of 3GPP RATs (Radio Access Technologies), such as one or more of a UTRAN RAT (Universal Mobile Telecommunications Service Terrestrial Radio Access Network RAT), an EUTRAN (Evolved UTRAN) RAT, an NR RAT, a WLAN RAT, etc.

[0164] The UE may receive the validity criteria in a PDU session accept message or a registration accept message. When the validity criteria are received in a registration accept message, the validity criteria may be applied to any PDU session associated with the UE. When the validity criteria are received in a PDU session accept message, the validity criteria may be applied only to the PDU session associated with the PDU session accept message.

[0165] The validity criteria may be used by the UE to determine when it is acceptable to perform a NAS-MM reset while maintaining the NAS-SM context. For example, the UE may determine that performing a NAS-MM reset while preserving the NAS-SM context is acceptable only when the current state of the UE matches the validity criteria.

[0166] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications network technologies, including radio access, core transport networks, and service capabilities, including work on codecs, security, and quality of service. Recent Radio Access Technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), LTE-Advanced, and New Radio (NR), also known as "5G." 3GPP NR standard development is expected to continue and include the definition of next-generation radio access technologies (new RATs), which are expected to include new flexible radio access provisions below 7 GHz and new ultra-mobile broadband radio access provisions above 7 GHz. Flexible radio access is expected to consist of new, non-backward-compatible radio access in new spectrum below 7 GHz, including different operating modes that can be multiplexed together in the same spectrum to address a wide range of 3GPP NR use cases with divergent requirements. Ultra Mobile Broadband is expected to include cmWave and mmWave spectrum, providing opportunities for ultra mobile broadband access for indoor applications and hotspots, for example. In particular, Ultra Mobile Broadband is expected to share a common design framework with sub-7 GHz Flexible Wireless Access, with centimeter wave and millimeter wave specific design optimizations.

[0167] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rates, latency, and mobility. The use cases include the following general categories: enhanced mobile broadband (eMBB), ultra-reliable low latency communications (URLLC), massive machine type communications (mMTC), network operations (e.g., network slicing, routing, migration, and interworking, energy conservation), and enhanced vehicle-to-everything (eV2X) communications, which may include any of vehicle-to-vehicle communication (V2V), vehicle-to-infrastructure communication (V2I), vehicle-to-network communication (V2N), vehicle-to-pedestrian communication (V2P), and vehicle communication with other entities. Specific services and applications in these categories include, for example, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based office, first responder connectivity, automotive e-calling, disaster alerts, real-time gaming, multi-party video calling, autonomous driving, augmented reality, haptic internet, virtual reality, home automation, robotics, and aerial drones, to name a few. All of these use cases and more are contemplated herein.

[0168] 15A illustrates an example communications system 100 in which the systems, methods, and apparatus described and claimed herein may be used. The communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g, which may be generally or collectively referred to as a WTRU 102 or multiple WTRUs 102. The communications system 100 may also include a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and network services 113. The network services 113 may include, for example, a V2X server, a V2X function, a ProSe server, a ProSe function, an IoT service, video streaming, and / or edge computing.

[0169] It will be understood that the concepts disclosed herein may be used with any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102 may be any type of apparatus or device configured to operate and / or communicate in a wireless environment. In the example of FIG. 15A, each of the WTRUs 102 is illustrated in FIGS. 15A-E as a handheld wireless communication device. In the wide variety of use cases contemplated for wireless communication, it will be understood that each WTRU may include, or be included in, any type of apparatus or device configured to transmit and / or receive wireless signals, including, by way of example only, a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a mobile phone, a personal digital assistant (PDA), a smartphone, a laptop computer, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, a household appliance, a wearable device such as a smart watch or smart clothing, a medical or e-health device, a robot, an industrial device, a drone, a vehicle such as an automobile, bus, or truck, or an airplane.

[0170] The communications system 100 may also include a base station 114a and a base station 114b. In the example of FIG. 15A, each base station 114a and 114b is illustrated as a single element. In practice, the base stations 114a and 114b may include any number of interconnected base stations and / or network elements. The base station 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, and 102c to facilitate access to one or more communications networks, such as the core networks 106 / 107 / 109, the Internet 110, the network services 113, and / or other networks 112. Similarly, the base station 114b may be any type of device configured to interface wired and / or wirelessly with at least one of the remote radio heads (RRHs) 118a, 118b, the transmission and reception points (TRPs) 119a, 119b, and / or the roadside units (RSUs) 120a and 120b to facilitate access to one or more communication networks, such as the core networks 106 / 107 / 109, the Internet 110, the other networks 112, and / or the network services 113. The RRHs 118a, 118b may be any type of device configured to interface wirelessly with at least one of the WTRUs 102, e.g., the WTRU 102c, to facilitate access to one or more communication networks, such as the core networks 106 / 107 / 109, the Internet 110, the network services 113, and / or the other networks 112.

[0171] The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core networks 106 / 107 / 109, the Internet 110, the network services 113, and / or other networks 112. The RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks, such as the core networks 106 / 107 / 109, the Internet 110, the other networks 112, and / or the network services 113. As an example, the base stations 114a, 114b may be a Base Transceiver Station (BTS), Node-B, eNode-B, Home Node-B, Home eNodeB, Next Generation Node-B (gNode B), satellite, site controller, access point (AP), wireless router, etc.

[0172] The base station 114a may be part of the RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as a Base Station Controller (BSC), a Radio Network Controller (RNC), a relay node, etc. Similarly, the base station 114b may be part of the RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as a BSC, an RNC, a relay node, etc. The base station 114a may be configured to transmit and / or receive wireless signals within a particular geographic area, which may be referred to as a cell (not shown). Similarly, the base station 114b may be configured to transmit and / or receive wired and / or wireless signals within a particular geographic area, which may be referred to as a cell (not shown). A cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, for example, the base station 114a may include three transceivers, e.g., one transceiver for each sector of the cell. The base station 114a may employ Multiple-Input Multiple Output (MIMO) technology and thus may utilize multiple transceivers, for example, for each sector of the cell.

[0173] The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c, and 102g over air interfaces 115 / 116 / 117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interfaces 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0174] The base station 114b may communicate with one or more of the RRHs 118a and 118b, the TRPs 119a and 119b, and / or the RSUs 120a and 120b via a wired or air interface 115b / 116b / 117b, which may be any suitable wired (e.g., cable, optical fiber, etc.) or wireless communication link (e.g., RF, microwave, IR, UV, visible light, centimeter wave, millimeter wave, etc.). The air interface 115b / 116b / 117b may be established using any suitable RAT.

[0175] The RRHs 118a, 118b, the TRPs 119a, 119b, and / or the RSUs 120a, 120b may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f over the air interface 115c / 116c / 117c, which may be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, centimeter wave, millimeter wave, etc.). The air interface 115c / 116c / 117c may be established using any suitable RAT.

[0176] The WTRUs 102 may communicate with each other via a direct air interface 115d / 116d / 117d, such as sidelink communication, which may be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, centimeter wave, millimeter wave, etc.). The air interface 115d / 116d / 117d may be established using any suitable RAT.

[0177] The communications system 100 may be a multiple-access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and so on. For example, the base station 114a in the RAN 103 / 104 / 105 and the RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a, 120b and WTRUs 102c, 102d, 102e, and 102f in the RANs 103b / 104b / 105b may implement a radio technology such as Universal Mobile Telecommunications System (UMTS), Terrestrial Radio Access (UTRA), etc., which may establish the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively, using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+), which may include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

[0178] The base station 114a and the WTRUs 102a, 102b, 102c, and 102g in the RANs 103 / 104 / 105, or the RRHs 118a and 118b, TRPs 119a and 119b, and / or RSUs 120b and 120b and the WTRUs 102c, 102d in the RANs 103b / 104b / 105b, may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interfaces 115 / 116 / 117 or 115c / 116c / 117c, respectively, using, for example, Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A). The air interface 115 / 116 / 117 or 115c / 116c / 117c may implement 3GPP NR technology. LTE and LTE-A technologies may include LTE D2D and / or V2X technologies and interfaces (such as sidelink communications). Similarly, 3GPP NR technology may include NR V2X technologies and interfaces (such as sidelink communications).

[0179] The base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, and 102g, or the RRHs 118a and 118b, TRPs 119a and 119b, and / or RSUs 120a and 120b and the WTRUs 102c, 102d, 102e, and 102f in the RAN 103b / 104b / 105b, may be compliant with IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1x, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GMC), or any other standard. Radio technologies such as Global System for Mobile Communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), and GSM EDGE (GERAN) may be implemented.

[0180] 15A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business, home, vehicle, train, airborne, satellite, factory, campus, etc. The base station 114c and the WTRU 102, e.g., the WTRU 102e, may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). Similarly, the base station 114c and the WTRU 102, e.g., the WTRU 102d, may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). The base station 114c and the WTRU 102, e.g., the WTRU 102e, may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a picocell or femtocell. 15A, the base station 114c may have a direct connection to the Internet 110. Thus, the base station 114c may not need to access the Internet 110 through the core network 106 / 107 / 109.

[0181] The RANs 103 / 104 / 105 and / or RANs 103b / 104b / 105b may communicate with a core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, messaging, authorization and authentication, application, and / or Voice Over Internet Protocol (VoIP) services to one or more of the WTRUs 102. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, etc., and / or may perform high-level security functions, such as user authentication.

[0182] 15A, it will be understood that the RANs 103 / 104 / 105 and / or RANs 103b / 104b / 105b and / or the core networks 106 / 107 / 109 may communicate directly or indirectly with other RANs employing the same RAT as the RANs 103 / 104 / 105 and / or RANs 103b / 104b / 105b, or a different RAT. For example, in addition to being connected to the RANs 103 / 104 / 105 and / or RANs 103b / 104b / 105b, which may utilize E-UTRA radio technology, the core networks 106 / 107 / 109 may also communicate with another RAN (not shown) using GSM or NR radio technology.

[0183] The core network 106 / 107 / 109 may also serve as a gateway for the WTRU 102 to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network providing Plain Old Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols such as the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and internet protocol (IP) in the TCP / IP Internet protocol suite. The other networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include any type of packet data network (e.g., an IEEE 802.3 Ethernet network) or another core network connected to one or more RANs, which may employ the same RAT as RANs 103 / 104 / 105 and / or RANs 103b / 104b / 105b, or a different RAT.

[0184] Some or all of the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f in the communications system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102g shown in FIG. 15A may be configured to communicate with a base station 114a, which may employ a cellular-based wireless technology, and a base station 114c, which may employ IEEE 802.11 wireless technology.

[0185] Although not shown in Figure 15A, it will be understood that the user equipment may have a wired connection to a gateway. The gateway may be a residential gateway (RG). The RG may provide connectivity to the core network 106 / 107 / 109. It will be understood that many of the ideas contained herein may apply equally to UEs, that is, WTRUs and UEs that use a wired connection to connect to a network. For example, ideas applied to air interfaces 115, 116, 117, and 115c / 116c / 117c may apply equally to a wired connection.

[0186] Figure 15B is a system diagram of an example RAN 103 and core network 106. As described above, the RAN 103 may communicate with the WTRUs 102a, 102b, and 102c over the air interface 115 using UTRA radio technology. The RAN 103 may also communicate with the core network 106. As shown in Figure 15B, the RAN 103 may include Node-Bs 140a, 140b, and 140c, each of which may include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 115. The Node-Bs 140a, 140b, and 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a and 142b. It will be understood that the RAN 103 may include any number of Node-Bs and radio network controllers (RNCs).

[0187] As shown in FIG. 15B, Node-Bs 140a and 140b can communicate with RNC 142a. Additionally, Node-B 140c can communicate with RNC 142b. Node-Bs 140a, 140b, and 140c can communicate with their respective RNCs 142a and 142b via an Iub interface. RNCs 142a and 142b can communicate with each other via an Iur interface. Each of RNCs 142a and 142b can be configured to control its respective Node-B 140a, 140b, and 140c to which it is connected. Additionally, each of RNCs 142a and 142b can be configured to perform or support other functions such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0188] The core network 106 shown in Figure 15B may include a media gateway (MGW) 144, a Mobile Switching Center (MSC) 146, a Serving GPRS Support Node (SGSN) 148, and / or a Gateway GPRS Support Node (GGSN) 150. Although each of the foregoing elements is illustrated as part of the core network 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0189] The RNC 142a in the RAN 103 may be connected to an MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to an MGW 144. The MSC 146 and MGW 144 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional landline communication devices.

[0190] The RNC 142a in the RAN 103 may also be connected to an SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to a GGSN 150. The SGSN 148 and GGSN 150 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and IP-enabled devices.

[0191] The core network 106 may also be connected to other networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0192] 15C is a system diagram of an example RAN 104 and core network 107. As described above, the RAN 104 may communicate with the WTRUs 102a, 102b, and 102c over the air interface 116 using E-UTRA radio technology. The RAN 104 may also communicate with the core network 107.

[0193] The RAN 104 may include eNode-Bs 160a, 160b, and 160c, although it is understood that the RAN 104 may include any number of eNode-Bs. The eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. For example, the eNode-Bs 160a, 160b, and 160c may implement MIMO techniques. Thus, the eNode-B 160a may transmit wireless signals to, and receive wireless signals from, the WTRU 102a, for example, using multiple antennas.

[0194] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling, etc. on the uplink and / or downlink. As shown in FIG. 15C, the eNode-Bs 160a, 160b, and 160c may communicate with one another via an X2 interface.

[0195] The core network 107 shown in Figure 15C may include a Mobility Management Gateway (MME) 162, a Serving Gateway 164, and a Packet Data Network (PDN) Gateway 166. Although each of the foregoing elements is illustrated as part of the core network 107, it will be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0196] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, and 102c, etc. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0197] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, and 102c. The serving gateway 164 may also perform other functions, such as anchoring the user plane during inter-eNodeB handover, triggering paging when downlink data is available for the WTRUs 102a, 102b, and 102c, and managing and storing the context of the WTRUs 102a, 102b, and 102c.

[0198] The serving gateway 164 may also be connected to a PDN gateway 166, which may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0199] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional landline communication devices. For example, the core network 107 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to the network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0200] 15D is a system diagram of an example RAN 105 and core network 109. The RAN 105 may communicate with the WTRUs 102a and 102b over an air interface 117 using NR radio technology. The RAN 105 may also communicate with the core network 109. A Non-3GPP Interworking Function (N3IWF) 199 may communicate with the WTRU 102c over an air interface 198 using non-3GPP radio technology. The N3IWF 199 may also communicate with the core network 109.

[0201] The RAN 105 may include g Node-Bs 180a and 180b. It will be understood that the RAN 105 may include any number of g Node-Bs. The g Node-Bs 180a and 180b may each include one or more transceivers for communicating with the WTRUs 102a and 102b over the air interface 117. When an integrated access and backhaul connection is used, the same air interface may be used between the WTRUs and the g Node-Bs, which may be the core network 109 via one or more gNBs. The g Node-Bs 180a and 180b may implement MIMO, MU-MIMO, and / or digital beamforming techniques. Thus, the g Node-B 180a may, for example, transmit wireless signals to and receive wireless signals from the WTRU 102a using multiple antennas. It will be understood that the RAN 105 may use other types of base stations, such as eNode-Bs. It should also be understood that the RAN 105 may employ more than one type of base station. For example, the RAN may use eNode-B and gNode-B.

[0202] The N3IWF 199 may include a non-3GPP access point 180c. It will be appreciated that the N3IWF 199 may include any number of non-3GPP access points. The non-3GPP access point 180c may include one or more transceivers for communicating with the WTRU 102c over the air interface 198. The non-3GPP access point 180c may communicate with the WTRU 102c over the air interface 198 using an 802.11 protocol.

[0203] Each of the eNode-Bs 180a and 180b may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling, etc. on the uplink and / or downlink. As shown in FIG. 15D, the gNode-Bs 180a and 180b may communicate with each other, for example, via an Xn interface.

[0204] The core network 109 shown in FIG. 15D may be a 5G core network (5GC). The core network 109 may provide multiple communication services to customers interconnected by a radio access network. The core network 109 includes several entities that perform core network functions. As used herein, the terms "core network entity" or "network function" refer to any entity that performs one or more functions of a core network. It is understood that such a core network entity may be a device configured for wireless or network communication, or a logical entity implemented in the form of computer-executable instructions (software) stored in a memory of, and executed by, a processor of, a computer system, such as the system 90 shown in FIG. 15G.

[0205] In the example of Figure 15D, the 5G core network 109 may include an access and mobility management function (AMF) 172, a Session Management Function (SMF) 174, User Plane Functions (UPF) 176a and 176b, a User Data Management Function (UDM) 197, an Authentication Server Function (AUSF) 190, a Network Exposure Function (NEF) 196, a Policy Control Function (PCF) 184, a Non-3GPP Interworking Function (N3IWF) 199, and a User Data Repository (UDR) 178. While each of the foregoing elements is illustrated as part of the 5G core network 109, it will be understood that any of these elements may be owned and / or operated by an entity other than the core network operator. It is also understood that the 5G core network may consist of additional elements, not all of these elements, and may consist of multiple instances of each of these elements. Although Figure 15D shows the network functions connecting directly to each other, it should be understood that they may communicate through a routing agent, such as a diameter routing agent or message bus.

[0206] In the example of Figure 15D, connectivity between network functions is achieved through a set of interfaces or reference points. It is understood that network functions may be modeled, described, or implemented as a set of services that are invoked or called by other network functions or services. Invocation of network function services may be achieved through direct connections between network functions, messaging exchanges on a message bus, software function calls, etc.

[0207] The AMF 172 may be connected to the RAN 105 via the N2 interface and may function as a control node. For example, the AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, and access authorization. The AMF may be responsible for forwarding user plane tunnel configuration information to the RAN 105 via the N2 interface. The AMF 172 may receive user plane tunnel configuration information from the SMF via the N11 interface. The AMF 172 may generally route and forward NAS packets to and from the WTRUs 102a, 102b, and 102c via the N1 interface. The N1 interface is not shown in FIG. 15D.

[0208] The SMF 174 may be connected to the AMF 172 via an N11 interface. Similarly, the SMF may be connected to the PCF 184 via an N7 interface and to the UPFs 176a and 176b via an N4 interface. The SMF 174 may function as a control node. For example, the SMF 174 may be responsible for session management, IP address allocation for the WTRUs 102a, 102b, and 102c, management and configuration of traffic steering rules in the UPFs 176a and 176b, and generation of downlink data notifications to the AMF 172.

[0209] The UPF 176a and UPF 176b may provide the WTRUs 102a, 102b, and 102c with access to a packet data network (PDN), such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, and 102c and other devices. The UPF 176a and UPF 176b may also provide the WTRUs 102a, 102b, and 102c with access to other types of packet data networks. For example, the other network 112 may be an Ethernet network or any type of network that exchanges packets of data. The UPF 176a and UPF 176b may receive traffic steering rules from the SMF 174 via the N4 interface. The UPF 176a and UPF 176b may provide access to a packet data network by connecting the packet data network with the N6 interface or by connecting to each other or other UPFs via the N9 interface. In addition to providing access to the packet data network, the UPF 176 may be responsible for packet routing and forwarding, policy rule enforcement, quality of service handling for user plane traffic, and downlink packet buffering.

[0210] The AMF 172 may also be connected to the N3IWF 199, for example, via an N2 interface. The N3IWF facilitates connectivity between the WTRU 102c and the 5G core network 170, for example, via an air interface technology not defined by 3GPP. The AMF may interact with the N3IWF 199 in the same or similar manner as it interacts with the RAN 105.

[0211] The PCF 184 may be connected to the SMF 174 via an N7 interface, to the AMF 172 via an N15 interface, and to an Application Function (AF) 188 via an N5 interface. The N15 and N5 interfaces are not shown in FIG. 15D . The PCF 184 may provide policy rules to control plane nodes such as the AMF 172 and SMF 174, allowing the control plane nodes to enforce these rules. The PCF 184 may send policies to the AMF 172 for the WTRUs 102a, 102b, and 102c so that the AMF can deliver the policies to the WTRUs 102a, 102b, and 102c via the N1 interface. The policies may then be enforced or applied at the WTRUs 102a, 102b, and 102c.

[0212] The UDR 178 may function as a repository for authentication credentials and subscription information. The UDR may connect to a network function so that the network function can add to, read, and modify data residing in the repository. For example, the UDR 178 may connect to the PCF 184 via an N36 interface. Similarly, the UDR 178 may connect to the NEF 196 via an N37 interface, and the UDR 178 may connect to the UDM 197 via an N35 interface.

[0213] The UDM 197 may act as an interface between the UDR 178 and other network functions. The UDM 197 may authorize the network functions for access by the UDR 178. For example, the UDM 197 may connect to the AMF 172 via an N8 interface, and the UDM 197 may connect to the SMF 174 via an N10 interface. Similarly, the UDM 197 may connect to the AUSF 190 via an N13 interface. The UDR 178 and the UDM 197 may be tightly integrated.

[0214] The AUSF 190 performs authentication related operations and connects to the UDM 178 via the N13 interface and to the AMF 172 via the N12 interface.

[0215] The NEF 196 exposes capabilities and services in the 5G core network 109 to the Application Function (AF) 188. The exposure may occur over an N33 API interface. The NEF may connect to the AF 188 via the N33 interface and may connect to other network functions to expose capabilities and services of the 5G core network 109.

[0216] The application functions 188 may interact with network functions within the 5G core network 109. The interaction between the application functions 188 and the network functions may be via a direct interface or may occur via the NEF 196. The application functions 188 may be considered part of the 5G core network 109 or may be external to the 5G core network 109 and deployed by companies that have business relationships with the mobile network operators.

[0217] Network slicing is a mechanism used by mobile network operators to support one or more "virtual" core networks behind the operator's air interface. This involves "slicing" the core network into one or more virtual networks to support different RANs or different service types running across a single RAN. Network slicing enables operators to create customized networks to provide optimized solutions for different market scenarios with diverse requirements, for example, in the areas of functionality, performance, and isolation.

[0218] 3GPP is designing the 5G core network to support network slicing. Network slicing is a useful tool that network operators can use to support a diverse set of 5G use cases (e.g., massive IoT, critical communications, V2X, and enhanced mobile broadband) that have very different and sometimes extreme requirements. Without network slicing technology, the network architecture is likely not flexible and scalable enough to efficiently support the needs of a wider range of use cases, as each use case has its own specific set of performance, scalability, and availability requirements. Furthermore, it should make the introduction of new network services more efficient.

[0219] Referring again to FIG. 15D , in a network slicing scenario, the WTRU 102a, 102b, or 102c may connect to the AMF 172 via an N1 interface. The AMF may be logically part of one or more slices. The AMF may coordinate the WTRU 102a, 102b, or 102c's connectivity or communication with one or more UPFs 176a and 176b, SMF 174, and other network functions. Each of the UPFs 176a and 176b, SMF 174, and other network functions may be part of the same slice or different slices. When they are part of different slices, they may be isolated from each other in the sense that they may utilize different computing resources, security credentials, etc.

[0220] The core network 109 may facilitate communications with other networks. For example, the core network 109 may include or communicate with an IP gateway, such as an IP Multimedia Subsystem (IMS) server that acts as an interface between the 5G core network 109 and the PSTN 108. For example, the core network 109 may include or communicate with a short message service (SMS) service center that facilitates communications via short message service. For example, the 5G core network 109 may facilitate the exchange of non-IP data packets between the WTRUs 102a, 102b, and 102c and the server or application function 188. Additionally, the core network 170 may provide the WTRUs 102a, 102b, and 102c with access to the network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0221] The core network entities described herein and shown in Figure 15A, Figure 15C, Figure 15D, or Figure 15E are identified by the names given to those entities in certain existing 3GPP specifications, although it is understood that those future entities and functions may be identified by other names and that certain entities or functions may be combined in future specifications published by 3GPP, including future 3GPP NR specifications. Thus, it is understood that the specific network entities and functions described and illustrated in Figures 15A-E are provided by way of example only, and that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communications system, whether currently defined or defined in the future.

[0222] 15E illustrates an example communication system 111 in which the systems, methods, and apparatus described herein may be used. The communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, and F, a base station gNB 121, a V2X server 124, and roadside units (RSUs) 123a and 123b. In practice, the concepts presented herein may apply to any number of WTRUs, base stations gNBs, V2X networks, and / or other network elements. One or more, or all, of WTRUs A, B, C, D, E, and F may be outside the coverage area of ​​the access network 131. WTRUs A, B, and C form a V2X group in which WTRU A is the group lead and WTRUs B and C are group members.

[0223] WTRUs A, B, C, D, E, and F may communicate with each other over Uu interface 129 via gNB 121 when they are within access network coverage 131. In the example of FIG. 15E, WTRUs B and F are shown within access network coverage 131. WTRUs A, B, C, D, E, and F may communicate directly with each other over a sidelink interface (e.g., PC5 or NR PC5), such as interface 125a, 125b, or 128, regardless of whether they are under or outside access network coverage 131. For example, in the example of FIG. 15E, WTRU D, which is outside access network coverage 131, communicates with WTRU F, which is within coverage 131.

[0224] WTRUs A, B, C, D, E, and F may communicate with RSU 123a or 123b via vehicle-to-network communications (V2N) 133 or sidelink interface 125b. WTRUs A, B, C, D, E, and F may communicate to V2X server 124 via vehicle-to-infrastructure communications (V2I) interface 127. WTRUs A, B, C, D, E, and F may communicate to another UE via vehicle-to-person communications (V2P) interface 128.

[0225] Figure 15F is a block diagram of an example apparatus or device WTRU 102 that may be configured for wireless communication and operation in accordance with the systems, methods, and apparatus described herein, such as the WTRU 102 of Figures 15A-15E. As shown in Figure 15F, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicators 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be understood that the WTRU 102 may include any sub-combination of the foregoing elements. Additionally, the base stations 114a and 114b and / or nodes that they may represent, such as, but not limited to, a transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home Node-B, an evolved home Node-B (eNodeB), a home evolved Node-B (HeNB), a home evolved Node-B gateway, a next generation Node-B (gNode-B), and a proxy node, among others, may include some or all of the elements illustrated in FIG. 15F and described herein.

[0226] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 15F depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0227] The transmit / receive element 122 of the UE may be configured to transmit or receive signals to or from a base station (e.g., base station 114a in FIG. 15A) over air interface 115 / 116 / 117, or to transmit or receive signals to or from another UE over air interface 115d / 116d / 117d. For example, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. The transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. The transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless or wired signals.

[0228] 15F as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

[0229] The transceiver 120 may be configured to modulate signals transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As mentioned above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, e.g., NR and IEEE 802.11 or NR and E-UTRA, or to communicate with the same RAT via multiple beams to different RRHs, TRPs, RSUs, or nodes.

[0230] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. Additionally, the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may store a subscriber identity module (SID) or a subscriber identity card (PIN). The processor 118 may include a SIM card, a memory stick, a secure digital (SD) memory card, etc. The processor 118 may access information from and store data in memory that is not physically located on the WTRU 102, such as on a server hosted on a cloud or edge computing platform or a home computer (not shown).

[0231] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control the power to other components within the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, etc.

[0232] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or instead of information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 115 / 116 / 117 and / or determine its location based on the timing of signals being received from two or more nearby base stations. It will be understood that the WTRU 102 may obtain location information by any suitable location-determination method.

[0233] The processor 118 may further be coupled to other peripherals 138 and may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as an accelerometer, a biometric (e.g., fingerprint) sensor, an electronic compass, a satellite transceiver, a digital camera (for photos or videos), a universal serial bus (USB) port or other interconnection interface, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, etc.

[0234] The WTRU 102 may be included in other apparatus or devices, such as a sensor, a domestic appliance, a wearable device such as a smart watch or smart clothing, a medical or e-health device, a robot, industrial equipment, a drone, a vehicle such as an automobile, truck, train, or airplane, etc. The WTRU 102 may connect to other components, modules, or systems of such an apparatus or device via one or more interconnection interfaces, such as an interconnection interface that may include one of the peripherals 138.

[0235] FIG. 15G is a block diagram of an exemplary computing system 90 in which one or more devices of the communication networks illustrated in FIGS. 15A, 15C, 15D, and 15E may be embodied, such as particular nodes or functional entities in the RAN 103 / 104 / 105, the core network 106 / 107 / 109, the PSTN 108, the Internet 110, other networks 112, or network services 113. The computing system 90 may include a computer or server and may be controlled primarily by computer-readable instructions. The computer-readable instructions may be in the form of software, located anywhere or by any means by which such software is stored or accessed. Such computer-readable instructions may be executed within a processor 91 to cause the computing system 90 to perform tasks. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal coding, data processing, power control, input / output processing, and / or any other function that enables the computing system 90 to operate in a communications network. The coprocessor 81 is any processor different from the main processor 91 and may perform additional functions or assist the processor 91. The processor 91 and / or the coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

[0236] In operation, processor 91 fetches, decodes, and executes instructions and sends information to other resources via the computing system's main data transfer path, system bus 80. Such a system bus connects components within computing system 90 and defines a medium for data exchange. System bus 80 typically includes data lines for transmitting data, address lines for transmitting addresses, and control lines for transmitting interrupts and operating the system bus. An example of such a system bus 80 is a Peripheral Component Interconnect (PCI) bus.

[0237] The memories coupled to the system bus 80 include random access memory (RAM) 82 and read-only memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROM 93 generally contains stored data that cannot be easily modified. Data stored in RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 may be controlled by a memory controller 92. The memory controller 92 may provide an address translation function that converts virtual addresses to physical addresses when instructions are executed. The memory controller 92 may also provide a memory protection function that separates processes within the system and separates system processes from user processes. Thus, a program executing in the first mode can only access memory mapped by its own process virtual address space and cannot access memory in another process's virtual address space unless memory sharing between processes is configured.

[0238] Additionally, computing system 90 may include a peripheral controller 83 responsible for communicating instructions from processor 91 to peripheral devices, such as a printer 94 , a keyboard 84 , a mouse 95 , and a disk drive 85 .

[0239] The display 86, controlled by the display controller 96, is used to display visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). The display 86 may be implemented as a CRT-based video display, an LCD-based flat-panel display, a gas plasma-based flat-panel display, or a touch panel. The display controller 96 contains the electronic components necessary to generate the video signal that is sent to the display 86.

[0240] Additionally, computing system 90 may include communications circuitry, such as, for example, a wireless or wired network adapter 97, that may be used to connect computing system 90 to external communications networks or devices, such as RAN 103 / 104 / 105, core networks 106 / 107 / 109, PSTN 108, Internet 110, WTRU 102, or other networks 112 of Figures 15A-1E, allowing computing system 90 to communicate with other nodes or functional entities of those networks. The communications circuitry may be used alone or in combination with processor 91 to perform the transmitting and receiving steps of particular apparatuses, nodes, or functional entities described herein.

[0241] It is understood that any or all of the devices, systems, methods, and processes described herein may be embodied in the form of computer-executable instructions (e.g., program code) stored on a computer-readable storage medium, which instructions, when executed by a processor, such as processor 118 or 91, cause the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any of the steps, operations, or functions described herein may be implemented in the form of such computer-executable instructions executed on a processor of a device or computing system configured for wireless and / or wired network communication. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storage of information, although such computer-readable storage media do not include signals. Computer-readable storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium that can be used to store the desired information and that can be accessed by a computing system.

[0242] [Table 1]

[0243] [Table 2]

[0244] [Table 3]

[0245] [Table 4]

[0246] Table 5

[0247] Table 6 < / mnc> < / mcc> < / guami> < / guami>

Claims

1. 1. A method implemented by a wireless transmit / receive unit (WTRU) for communication with a network, comprising: sending, by the WTRU to a network node, a registration request message requesting registration with the network, the registration request message including a notification that the WTRU may store context information associated with the communication between the WTRU and the network when the WTRU becomes unavailable to the network; receiving, by the WTRU, a registration accept message from the network node, the registration accept message including an indication that the network supports the preservation of context information when the WTRU becomes unavailable to the network; transmitting, by the WTRU to the network based on a determination that the WTRU will become unavailable to the network, a first message indicating a request to store the context information, the first message including a notification of a period of time during which the WTRU will be unavailable; and after the period expires, sending a second message to the network indicating that the WTRU is available to the network.

2. Modem reset, Operating system updates, Software updates, a network-initiated deregistration request, a deregistration request initiated by the WTRU; a network-initiated N1 reset request; an N1 reset request initiated by the WTRU, or 10. The method of claim 1, further comprising: determining that the WTRU becomes unavailable to a network due to one or more of:

3. The method of claim 1 , wherein the context information comprises Non-Access Stratum (NAS) Session Management (SM) context information.

4. The context information is Protocol Data Unit (PDU) session identifier, Data Network Name (DNN), Single Network Slice Assistance Information (S-NSSAI), or Internet Protocol (IP) address 10. The method of claim 1, comprising one or more of:

5. the first message indicating the request to store the context information; an N1 Reset Request message, or WTRU-initiated deregistration request message The method of claim 1 , comprising one of:

6. 10. The method of claim 1, wherein the second message indicating the WTRU's availability to the network comprises a second registration request message.

7. 10. The method of claim 1, further comprising: transmitting a request to the network to establish a protocol data unit (PDU) session, wherein the request to establish the PDU session includes a notification that the context information for the PDU session is required to be preserved when the WTRU becomes unavailable.

8. The method of claim 1 , further comprising: storing the context information in the WTRU before the WTRU becomes unavailable.

9. 1. A wireless transmit / receive unit (WTRU) comprising a processor and a memory storing instructions that, when executed by the processor, cause the WTRU to: sending a registration request message to a network node requesting to register with the network, the registration request message including a notification that the WTRU may store context information associated with communications between the WTRU and the network when the WTRU becomes unavailable to the network; receiving a registration accept message from the network node, the registration accept message including an indication that the network supports the preservation of context information when the WTRU becomes unavailable to the network; transmitting a first message to the network indicating a request to store the context information based on a determination that the WTRU will become unavailable to the network, the first message including a notification of a period of time during which the WTRU will be unavailable; sending a second message to the network after the period has expired indicating that the WTRU is available to the network; and A wireless transmit / receive unit (WTRU) that performs the following:

10. The instructions, when executed by the processor, Modem reset, Operating system updates, Software updates, a network-initiated deregistration request, a deregistration request initiated by the WTRU; a network-initiated N1 reset request; an N1 reset request initiated by the WTRU, or Change from RM-REGISTERED state to RM-DEREGISTERED state The WTRU of claim 9 , further comprising causing the WTRN to determine that the network becomes unavailable due to one or more of:

11. The WTRU of claim 9 , wherein the context information includes Non-Access Stratum (NAS) Session Management (SM) context information.

12. The context information is Protocol Data Unit (PDU) session identifier, Data Network Name (DNN), Single Network Slice Assistance Information (S-NSSAI), or Internet Protocol (IP) address 10. The WTRU of claim 9, comprising one or more of:

13. the first message indicating the request to store the context information; an N1 Reset Request message, or WTRU-initiated deregistration request message The WTRU of claim 9 , comprising one of:

14. the second message indicating the WTRU's availability to the network comprises a second registration request message. The WTRU of claim 9.

15. The instructions, when executed by the processor, 10. The WTRU of claim 9, further configured to cause the WTRU to transmit a request to the network to establish a protocol data unit (PDU) session, the request to establish the PDU session including a notification that the context information associated with the PDU session is requested to be preserved when the WTRU becomes unavailable.

16. The WTRU of claim 9 , wherein the instructions, when executed by the processor, further comprise causing the WTRU to store within the WTRU the context information before the WTRU became unavailable.

Images