Storing session context in a communication network

Abstract

When an event triggers the deletion of a session context, the present invention provides a method, apparatus, and system for saving such a context in a communication network. [Solution] In a communication system, when a user device (UE) becomes unavailable to the radio access network (RAN), the AMF (Automated Mobile Function) notifies the AMF via a deregistration request message that the UE can save context information associated with the communication between the UE and the RAN. When the AMF becomes unavailable to the network, it indicates in a deregistration acceptance message that the network supports saving context information. Based on the determination that the UE will become unavailable to the network, the UE sends a message to the RAN indicating a request to save the context information. The message includes notification of the period during which the UE 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 on November 3, 2021, entitled "Enhancements for Interactions between the Session Management and Mobility Management Layers", the content of which is hereby incorporated by reference in its entirety.

Background Art

[0002] For example, in a wireless communication system such as a system operating according to the new radio (NR) standard of the 3rd Generation Partnership Project (3GPP), there is a need to delete the mobility management context in a wireless transmission / reception unit (WTRU) such as a user equipment (UE), but events may occur that also cause the deletion of the session management context. For example, when there is an operating system (OS) update, a modem reset, or a deregistration request initiated by the network, the mobility management context of the WTRU can be cleared. However, such events may also delete the session management context and application layer information of the WTRU. This can lead to inefficiencies.

Summary of the Invention

[0003] This specification describes methods, apparatus, and systems for preserving a session context in a communication network when an event triggers its deletion. A radio transmit / receive unit (WTRU) may send a registration request message to a network node requesting registration with the network. The registration request message may include a notification that the WTRU may 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 acceptance message from a network node indicating that the network supports preserving context information when the WTRU becomes unavailable to the network. Based on the 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 the period during which the WTRU will be unavailable. After this period has ended, 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 is further described below in “Modes for Carrying Out the Invention.” This summary is not intended to identify any major or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to any limitations that resolve any or all of the defects described in any part of this disclosure. [Brief explanation of the drawing]

[0005] A more detailed understanding can be gained from the following description, which is provided as an example along with the attached drawings. [Figure 1] This is a diagram illustrating an exemplary communication system. [Figure 2]This figure shows an exemplary control plane between network entities. [Figure 3] This diagram shows an exemplary registration management (RM) state model in UE. [Figure 4] This diagram shows an example of a registration management (RM) state mode in AMF. [Figure 5] This diagram shows an example of connection management (CM) state transitions in a UE. [Figure 6] This diagram shows an example of connection management (CM) state transitions in AMF. [Figure 7] This diagram shows an exemplary control plane protocol stack between the UE and SMF. [Figure 8] This diagram illustrates a deregistration method initiated by an exemplary UE. [Figure 9] This diagram illustrates a deregistration method initiated by an exemplary network. [Figure 10] This is a diagram illustrating an exemplary user-plane protocol stack. [Figure 11A] This figure shows a method for establishing a PDU session as required by an exemplary UE for non-roaming and roaming with local breakout. [Figure 11B] This figure shows a method for establishing a PDU session as required by an exemplary UE for non-roaming and roaming with local breakout. [Figure 11C] This figure shows a method for establishing a PDU session as required by an exemplary UE for non-roaming and roaming with local breakout. [Figure 11D] This figure shows a method for establishing a PDU session as required by an exemplary UE for non-roaming and roaming with local breakout. [Figure 12a] This figure illustrates an exemplary method for PDU session modification (non-roaming and roaming with local breakout) required by a UE or network. [Figure 12b]This figure illustrates an exemplary method for PDU session modification (non-roaming and roaming with local breakout) required by a UE or network. [Figure 12c] This figure illustrates an exemplary method for PDU session modification (non-roaming and roaming with local breakout) required by a UE or network. [Figure 13] This figure illustrates an example of a context saving and recovery method. [Figure 14] This figure shows an exemplary extended RM state model for UE and AMF. [Figure 15A] This diagram shows another example of a communication system. [Figure 15B] This diagram shows an exemplary Radio Access Network (RAN) and core network. [Figure 15C] This diagram shows an exemplary Radio Access Network (RAN) and core network. [Figure 15D] This diagram shows an exemplary Radio Access Network (RAN) and core network. [Figure 15E] This diagram shows another example of a communication system. [Figure 15F] This is a block diagram of an exemplary device or apparatus, such as a wireless transmit / receive unit (WTRU). [Figure 15G] This is a diagram illustrating an exemplary computing system. [Modes for carrying out the invention]

[0006] A list of acronyms that can be used in this specification is shown in Table 1 below. In an NR (i.e., 5G) system, the N1 interface between a UE and an access and mobility management function (AMF) uses the non-access stratum (NAS) mobility management (MM) protocol (NAS-MM). As used in this specification, the terms "NAS-MM" and "NAS" (e.g., NAS without a suffix) can be used interchangeably. The N1 NAS signaling connection is used for both registration management and connection management (RM / CM), as well as 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 other core network functions other than the AMF, the messages exchanged between the UE and the other network functions are carried over the NAS-MM protocol.

[0008] There are multiple cases of protocols between the UE and core network functions (excluding the AMF) that need to be transported over the N1 interface via the NAS-MM protocol. Other core network functions that the UE communicates with via the N1 interface are the session management function (SMF), the short message service function (SMSF), the policy control function (PCF), and the location management function (LMF). Figure 1 shows examples of these various network functions.

[0009] The NAS-MM protocol is used to execute procedures between the UE and the AMF. The procedures executed between the UE and the AMF can 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 that 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 defined in 3GPP TS 24.501, Non-Access-Stratum (NAS) protocol for the 5G System (5GS); Stage 3.

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

[0011] The UE and the AMF maintain the registration management (RM) state for the UE separately. The RM states are RM-DEREGISTERED and RM-REGISTERED. In the RM-DEREGISTERED state, the UE is not registered with the network. Since the UE context in the AMF does not hold valid location or routing information for the UE, 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 the AMF, for example, to avoid executing the authentication procedure during all registration procedures.

[0012] In the RM-DEREGISTERED state, the UE attempts to register with the network. If 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 with the network. In the RM-REGISTERED state, the UE can perform registration renewals and send service requests. If the UE performs a deregistration procedure or if the registration request is rejected, the UE moves to the RM-DEREGISTERED state 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 RM-REGISTED state in the 5G MM substate is sometimes called the 5G MM-REGISTERED state. The RM-DEREGISTED state is sometimes called the 5G MM-DEREGISTERED state. The 5G MM-REGISTERED state and its substates are described in 3GPP TS 24.501.

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

[0015] A UE in the CM-IDLE state does not have a NAS signaling connection established with the AMF via N1. A UE in the CM-CONNECTED state has a 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 state in the UE is shown in Figure 5. The CM state in the AMF is shown in Figure 6.

[0016] The Non-Access Layer (NAS) Session Management (SM) protocol (NAS-SM) is used to transport 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 illustrated 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 calls 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 the NAS-SM message sent to the UE over NAS-MM messaging.

[0018] The SM contexts stored in the SMF are 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 the PDU session ID, data network name (DNN), single network slice selection assistance information (S-NSSAI), and Internet Protocol (IP) address. The information within the SM context is associated with the 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 calling the Nsmf_PDUSession_UpdateSMContext service operation. The SMF then sends an 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 contains the 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 indicating to the AMF, UE, and RAN, respectively, that any context associated with the PDU session may be deleted.

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

[0021] Figure 8 illustrates 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 using any SMF on which the UE has an established PDU session. This service call causes the UE's SM context to be removed in the SMF, User Plane Functions (UPF), and Unified Data Management (UDM). This is illustrated in Figure 8, showing the AMF sending the Nsmf_PDUSession_ReleaseSMContext request in step 2.

[0022] Figure 9 illustrates the network-initiated deregistration procedure. During the network-initiated deregistration procedure, the AMF also invokes the Nsmf_PDUSession_ReleaseSMContext request service operation using any SMF where the UE has an established PDU session. This service call causes the UE's SM context to be removed within the SMF, UPF, and UDM. This is illustrated in Figure 9.

[0023] The 3GPP 5G Core Network Architecture (5GC) supports the PDU Connectivity Service, a service that provides the exchange of PDUs between the UE and a data network identified by the DNN. The PDU Connectivity Service is supported via PDU sessions established upon request from the UE. PDU sessions are established (at the request of the UE), modified (at the request of the UE and 5GC), and released (at the request of the UE and 5GC) 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 within the UE. Upon receiving that trigger message, the UE passes it to the identified application within the UE. The identified application within the UE may then establish a PDU session to a specific DNN.

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

[0025] Each PDU session supports a single PDU session type, for example, the exchange of a single type of PDU requested by the UE when establishing a PDU session. The following PDU session types are defined: IPv4, IPv6, IPv4v6, Ethernet, and Unstructured.

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

[0027] 3GPP 5G networks can support several session and service continuity (SSC) modes, namely SSC Mode 1, SSC Mode 2, and SSC Mode 3. In SSC Mode 1, the network preserves the connectivity services provided to the UE. For IPv4, IPv6, or IPv4v6 type PDU sessions, 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 has been using to access the network. For IPv4, IPv6, or IPv4v6 type PDU sessions, 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). For IPv4, IPv6, or IPv4v6 types, releasing the PDU session triggers the release of the IP address(s) that were assigned to the UE. If the PDU session in SSC mode 2 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] Trigger conditions depend on operator policies, such as requests from application functions (AFs), and are based on load conditions. When a new PDU session is established, a new UPF can be selected to act as the PDU session anchor. Otherwise, if a PDU session in SSC Mode 2 has multiple PDU session anchors (e.g., a multi-homed PDU session, or if UL CL is applied to a PDU session in SSC Mode 2), 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, to enable better service continuity, a connection is established via a new PDU session anchor point before the previous connection terminates. For IPv4, IPv6, or IPv4v6 types, the IP address is not preserved in this mode when the PDU session anchor changes.

[0031] In the case of a PDU session in SSC mode 3, the network allows the UE to establish connectivity via a new PDU session anchor to the same data network before connectivity between the UE and the previous PDU session anchor is released. When a trigger condition is applied, the network decides whether to select a PDU session anchor UPF that is suitable for the new conditions of the UE (e.g., a point of connection to the network).

[0032] In release 16, SSC mode 3 applies only to IP PDU session types and any access types. After a new IP address / prefix is ​​assigned, the old IP address / prefix is ​​maintained for a certain period of time indicated to the UE via NAS signaling or Router Advertisement, and then released. If a PDU session in SSC mode 3 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 communicating with the UE application.

[0034] The UE application context includes the IP address, port number, security certificate, user identification information, and application identifier.

[0035] In 5G systems, the Data Network Name (DNN) 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 and carry similar information between their respective systems.

[0036] DNNs can be used, for example, in the following applications: First, select the SMF and UPF(s) Secondly, select the N6 interface(s) for the PDU session. Thirdly, determine the policy to apply to this PDU session.

[0037] Wildcard DNNs are values ​​that can be used in the DNN field of the join DNN list of session management join data, as defined in Section 5.2.3.3 of TS 23.502. Wildcard DNNs may be used with S-NSSAI for operators 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 PDU sessions established upon request from the UE. The enrollment information for each S-NSSAI may include a list of enrollment DNNs 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 one exists in the UE's enrollment information. Otherwise, the Serving AMF selects a locally configured DNN for this S-NSSAI.

[0039] The URSP within the UE is always up-to-date using the procedure defined in section 4.16.12.2 of TS 23.502, and therefore, the DNN requested by the UE is expected to be up-to-date.

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

[0041] If the DNN provided by the UE is not supported by the network and the AMF cannot select an SMF by querying the NRF, the AMF shall reject the NAS message from the UE, including a PDU session establishment request, along with a reason indicating that the DNN is not supported, unless the PCF provides a policy to perform DNN replacement 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 provides a policy for performing DNN substitution of the 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 DNN substitution, the PCF provides a list of DNNs selected for substitution applicable to the S-NSSAI requested by the UE at the time of PDU session establishment. The AMF uses the selected DNNs in the query to the NRF for SMF selection and provides both the requested DNN and the selected DNNs to the selected SMF. Note that interaction between the AMF and the PCF is required when DNN substitution is performed within the network.

[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 to serve a UE. AMF selection can also be performed by an AMF. An AMF may perform a procedure to select another AMF to serve a UE if it determines that its current AMF is not suitable for serving the UE. This can happen, for example, when a UE attempts to register with a different network slice.

[0044] When 5G-AN performs AMF selection, it considers the slice requested by the UE, as well as other information such as the local operator policy and the UE's properties (e.g., RAT type).

[0045] The AMF assigns a globally unique temporary identifier (5G-GUTI) to a UE common to both 3GPP and non-3GPP access. The same 5G-GUTI can be used to access the 3GPP and non-3GPP access security contexts within the AMF for a given UE. The AMF can reassign a new 5G-GUTI to a UE at any time.

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

[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 an abbreviated form of GUTI for enabling 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's Route Selection Policy (URSP) includes 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] A route selection descriptor (RSD) includes one or more of the following components: - Session and Service Continuity (SSC) Mode: Indicates that traffic for matching applications is routed through a PDU session that supports the included SSC mode. - Network slice selection: Indicates that traffic for matching applications will be routed through a PDU session that supports one of the included S-NSSAIs. - DNN Selection: Indicates that traffic for matching applications will be 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 contain the DNN selection component. - PDU Session Type Selection: Indicates that traffic for matching applications will be routed through PDU sessions that support the included PDU session type. - Non-seamless offload notification: Indicates that, if the rule applies, traffic from the matching application will be offloaded to non-3GPP access outside the PDU session. If this component is present in the RSD, other components will not be included in the RSD. - Access Type Preference: This indicates the access type (3GPP or non-3GPP) when the UE needs to establish a PDU session when the rule applies.

[0051] A single URSP rule with a "match all" traffic descriptor is used to route traffic for an application that does not match any other URSP rules and is evaluated as having the lowest priority in the rule priority order. The RSD in this URSP rule contains at most one value for each route selection component. However, note that TS 23.503 states that "if the UE fails to establish a PDU session with any of the route selection descriptors, the UE will 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 exist. 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 met for the RSD within 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, a route selection descriptor is not considered valid unless the UE is within the time window. Using location criteria, a route selection descriptor is not considered valid unless the UE's location matches the location criteria.

[0054] Furthermore, when a route selection descriptor includes a time window or location criterion, a PDU session is considered a match only if the PDU session is associated with the same time window or location criterion validity condition. However, UE support for validation criteria in URSP rules is optional. If a UE that does not support validation criteria receives one, it ignores the validation criteria portion of the RSD and uses the remainder of the RSD.

[0055] UEs can have URSP rules provisioned by the PCF in the HPLMN. When a UE is roaming, the PCF in the HPLMN can update the URSP rules in the UE. In addition, UEs can also be pre-configured with URSP rules (e.g., by the operator). If both URSP rules provisioned by the PCF and pre-configured URSP rules exist, only the URSP rules provisioned by the PCF will be used by the UE.

[0056] For each newly detected application, the UE evaluates the URSP rules in order of rule priority and determines whether the application matches the traffic descriptor of any given URSP rule. If it is determined that a URSP rule is applicable to the given application, the UE selects the RSD within that URSP rule in 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 within the selected RSD. If a matching PDU session exists, the UE associates the application with the existing PDU session and, for example, routes the application's traffic discovered on that 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] The RSD of the URSP rule is considered valid if the following conditions are met: - If any S-NSSAI(s) exist, it must be within an authorized NSSAI, and, - If any DNN exists and the DNN is an LADN DNN, the UE is that this LADN is an area of ​​availability.

[0059] V-PCF can extract ANDSP and URSP from H-PCF via N24 / Npcf. When a UE is roaming and has valid rules from both HPLMN and VPLMN, the UE prioritizes valid ANDSP rules from VPLMN.

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

[0061] For each new application flow that needs to be established, the UE evaluates the URSP rules in order of rule priority, and then the UE either triggers a PDU session establishment or uses an existing PDU session for the flow. Location attributes are URSP rule constraints that must be valid for a URSP rule to be applicable. That is, when a route selection descriptor includes a time window or location criterion, a traffic flow is considered to match only if the UE's location matches the location criterion validity condition. In addition, TS 23.503 states that the UE will (re)evaluate the validity of URSP rules in a timely manner when certain conditions are met. For example, URSP is updated by the PCF in the following cases: • UE moves from EPC to 5GC. • Modification of permitted or configured NSSAI • Changes in LADN DNN availability • 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) Policy for 5G Systems (5GS); Stage 3, a UE may re-evaluate URSP rules to check whether a change in the association of an application with a PDU session is necessary in the following cases: • The UE performs periodic URSP rule re-evaluation based on the UE implementation. • The UE NAS layer indicates that existing PDU sessions used to route application traffic based on URSP rules are released. • URSP is updated by PCF. • The UE NAS layer indicates that the UE is performing a system-to-system change from S1 mode to N1 mode. • The UE NAS layer indicates that the UE has successfully registered in N1 mode via 3GPP access or non-3GPP access. • The UE establishes or releases a connection to the WLAN access, and the transmission of application PDUs via non-3GPP access outside of the PDU session becomes available / unavailable. • The permitted NSSAI is modified. LADN information will be changed.

[0063] If re-evaluation would result in a change in the application's association with a PDU session, the UE may implement such a change 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 re-evaluation.

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

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

[0066] The term UE can refer to a mobile phone, mobile computer, mobile broadband adapter, connected vehicle, or connected device that can connect to a cellular network. A UE may have an MT (Mobile Termination) portion that provides a cellular radio interface and a TE (Terminal Equipment) portion that provides services to the user and does not typically provide functions 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 examples of AT commands are defined in 3GPP TS 27.007.

[0067] UEs may also have SIMs for storing user authentication information and network identification information. It should be understood that the ideas herein apply equally to devices that do not have SIMs for storing user authentication information and network identification information. Instead, devices may store user authentication information and network identification information in other forms of non-volatile memory. Therefore, all ideas herein described as applicable to UEs are equally applicable to any device.

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

[0069] In the first example, when a UE is connected to the network for emergency services and the higher layer indicates 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 the second example, the network (e.g., AMF) can send a deregistration request to the UE along with a reregistration request notification. The AMF may be triggered by the O&M system to send this message. The purpose of the O&M request may be solely to register the UE with a new AMF or to reset the UE's MM context, but current 5G system designs require that both the MM and SM contexts be deleted when the deregistration procedure is performed. Network-initiated deregistration procedures are described in section 4.2.2.3.3 of TS 23.502.

[0071] In a third example, if the network (e.g., AMF) detects that the UE's registered PLMN is not authorized to operate at the current UE location, it can initiate a network-initiated deregistration. In this case, the AMF includes the country where the UE is located in the deregistration request. Note that this deregistration procedure removes the UE's SM context. However, the SM context can be fixed to an H-SMF instance authorized to operate at the UE's current location. Network-initiated deregistration procedures are described in section 4.2.2.3.3 of TS 23.502.

[0072] In the three examples listed above, deleting and recreating the NAS-MM context may suffice, but the NAS-SM context will also be deleted. Deleting the NAS-SM context, which includes the UE's IP address(s), often results in the deletion of at least some application layer contexts. For example, in the three examples listed above, changing the IP address typically requires the UE-hosted application to re-establish an application layer connection and recreate or update the application layer context. Of course, the re-establishment or recreation of the application layer context only occurs after the UE has re-established the PDU session and a new NAS-SM context has been created.

[0073] The 5G system extensions 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 can save the NAS-SM context during a NAS-MM reset. The network and UE may be able to identify which parts of the NAS-SM context need to be saved during a NAS-MM reset. The network and UE may be able to initiate a NAS-MM reset procedure so that the identified parts of the NAS-SM context are saved during the 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 UE-hosted applications that the NAS-SM context and connectivity have been restored, and as a result, UE-hosted applications may notify network application servers that connectivity has been restored.

[0074] This specification describes methods, apparatus, and systems for saving, re-establishing, or recovering a 5G SM context, and therefore an application layer context, when an event triggers the deletion and re-establishment of the 5G MM context. Figure 13 shows an exemplary method for saving, re-establishing, or recovering a 5G SM context. The method in Figure 13 can enable a WTRU and network, such as a UE, to perform a NAS-MM reset without performing a NAS-SM reset.

[0075] In Step 1, a WTRU, such as a UE, can perform initial registration with the network. For example, a WTRU can 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 save context information associated with communication between the WTRU and the network when the WTRU becomes unavailable to the network. For example, a WTRU (e.g., a UE) can indicate to the network that it can save the NAS-SM context while performing a NAS-MM reset. As will be further explained below, the WTRU can send this information to the network, and as a result the network will know that it can initiate the NAS-MM reset procedure so that the NAS-SM context is saved in the WTRU and on the network. The WTRU can also send this information to the network, and as a result the network will know that it is advantageous to select an SMF to serve the WTRU, which can save the WTRU's NAS-SM context when a NAS-MM reset occurs.

[0076] A WTRU can receive registration acceptance messages from network nodes. These messages may include a notification that the network supports saving context information when the WTRU becomes unavailable to the network.

[0077] In Step 2, applications hosted by the WTRU can be started. As described below, applications hosted by the WTRU can indicate to the network that they want to receive notifications or warnings 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 decide to establish a PDU session for application traffic. The WTRU may request the establishment of a PDU session by employing the procedure shown in Figures 11A to 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 a NAS-SM context reset occurs. For example, the WTRU may send a request to the network to establish a PDU session (for example, in step 1 of Figure 11A). The request to establish a PDU session includes a notification that context information about the PDU session should be preserved when the WTRU becomes unavailable.

[0079] In step 4, as will be described in more detail below, the WTRU may send a message to the network indicating a request to save context information based on the determination that the WTRU will be unavailable to the network. The message may include a notification of the period during 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 will be described in more detail below, such notification may be made as part of an N1 reset request message or a deregistration request message initiated by the UE. The WTRU may prepare for a NAS-MM context reset by notifying the WTRU host application of a pending NAS-MM reset. The AMF may prepare for a NAS-MM context reset by notifying the SMF of a pending NAS-SM reset. This will be described further below.

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

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

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

[0083] In step 8, the WTRU can 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 can 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., UE) sends a NAS-MM registration message to the network, the message is carried to the NG-RAN node within an RRC message. 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 can use a feature that it supports, which allows the UE's NAS-MM context to be reset / deleted in the UE and the network, while the UE's NAS-SM context is maintained in the UE and the network. This feature may be referred to herein as the “persistent NAS-SM context” feature, and the notification may be referred to herein as the “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 notification in the NAS-MM registration message. This persistent NAS-SM context support notification in the NAS-MM registration message may indicate to the AMF that the UE supports persistent NAS-SM context features and that the UE may wish to use those features. The AMF can use this information when performing SMF selection to ensure that the AMF selects an SMF that supports the features. The AMF may send a registration acceptance message to the UE. The registration acceptance message may include a notification that the AMF supports persistent NAS-SM context features and that the UE may attempt to use those features.

[0087] The AMF sends a registration acceptance 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 portion of the message a notification of whether the NG-RAN node has selected an AMF that supports persistent NAS-SM context features.

[0088] A UE may host critical applications whose functionality and / or reliability depend on the UE's SM context preserved during a NAS-MM reset. Therefore, a UE may only wish to connect to a network that supports the NAS-SM context preservation feature. The NG-RAN can broadcast a notification within its system information indicating to the UE that an AMF supporting the NAS-SM context feature is available for selection by an NG-RAN node.

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

[0090] As mentioned above, persistent NAS-SM context support notifications may be sent to the AMF within the NAS-MM registration request message. If the AMF determines that it cannot support the feature but another AMF can, the AMF can use the NRF to perform an AMF selection procedure, provide a notification to the NRF, and determine a new AMF to provide service to the UE.

[0091] The UE may provide the AMF with a separate persistent NAS-SM context support notification 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 that it requests slice by slice.

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

[0093] Alternatively, the UE may store the configuration for each slice of the configured NSSAI. The configuration information may include a notification of whether each slice supports persistent NAS-SM context features. When the UE receives a configured NSSAI in a registration acceptance or configuration update message, it may receive a persistent NAS-SM context support notification for each slice of the configured NSSAI.

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

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

[0096] Alternatively, the application may provide the Activated NAS-SM Context Preservation Notice to the ME portion of the UE as part of the traffic descriptor. When the Activated NAS-SM Context Preservation Notice is part of the traffic descriptor, the UE may select only existing PDU sessions 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 attempt to enable the feature for the new PDU session.

[0097] If an application provides an activated NAS-SM context save notification to the ME portion of the UE as part of the traffic descriptor, the notification may be sent to the ME by the TE via an AT command. For example, the notification may be provided when the +CGDCONT AT command is used. The +CGDCONT AT command, defined in 3GPP TS 24.007, the AT command set for user equipment (UE), is used to specify PDU session parameters.

[0098] The UE may determine that there are no existing PDU sessions to support 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 Notice. The Activate NAS-SM Context Preservation Notice may also be included in the NAS-MM portion of the message so that the AMF can use it during SMF selection, thus ensuring that the AMF selects an SMF that supports the feature. The NAS-SM Context Preservation Notice may also be part of the N1 SM container (e.g., the NAS-SM portion 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 so that only those belonging to a particular SMF serve PDU sessions whose context needs to be preserved during a NAS-SM reset. In this scenario, the activated NAS-SM context preservation notification does not need to be included in the NAS-SM portion of the PDU session establishment request message.

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

[0101] A PDU session establishment acceptance message can indicate to the UE whether a feature is enabled for a PDU session. For example, an SMF may include a NAS-SM context preservation enable notification within the PDU session establishment acceptance message sent to the UE, allowing the UE to maintain a list of PDU sessions 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 can also send a NAS-SM context preservation enable notification to the AMF when the SMF invokes the Namf_Communication_N1N2MessageTransfer service operation. The reason for sending the NAS-SM context preservation enable notification to the AMF is that it serves as notification to the AMF that the UE has PDU sessions whose NAS-SM context needs to be preserved 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 which PDU sessions are configured for NAS-SM context preservation in the UE context that the AMF maintains for the UE when a NAS-MM reset event occurs. The UE then does not need to specify which PDU sessions should be preserved during unregistration of its NAS-SM context. In addition to the NAS-SM context preservation enable indicator, the SMF can also provide a timer value for how long the NAS-SM context should be preserved. The timer value may be sent to both the AMF and the UE.

[0103] The NAS-SM context preservation enable notification may be sent by the TE to the ME via an AT command. For example, the display may be provided when the AT command +CGDCONT=? is used. The AT command +CGDCONT=?, as 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 a NAS-MM reset occurs.

[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 the SM context associated with the PDU session may be preserved during a NAS-MM reset, whereas the SM context associated with the PDU session in SSC mode 1 is not preserved during a NAS-MM reset.

[0106] If a persistent NAS-SM context feature is associated with SSC mode 4, the UE can 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 can send a NAS-SM context preservation enable notification to the UE by setting the permitted SSC mode in the PDU session establishment acceptance message to 4. Table 5 below shows an example of how SSC mode 4 is encoded and thus can indicate to the network that an activated NAS-SM context preservation notification should be enabled.

[0107] Furthermore, it may 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 the IP address 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 because using the feature allows the UE and network to reduce the amount of interaction required between the UE and the network to re-establish the PDU session. Table 6 below also shows whether the UE requests that the feature be enabled and provides an example of how SSC mode coding can be extended to indicate whether the network has enabled the feature.

[0108] A 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 requests the UE to reset its NAS-SM context. Resetting the NAS-SM context can be initiated by sending a deregistration request to the network. However, this is only if the UE determines that the NAS-SM context can 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 can then notify the SMF(s) associated with the PDU session whose context needs to be preserved, and help the SMF(s) coordinate the preservation timer between the UE and the SMF(s). A deregistration procedure initiated by the UE is shown in Figure 8 and can be extended as follows:

[0109] Step 1 deregistration request can be extended to allow the UE to 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 sessions' NAS-SM contexts need to be preserved by including the PDU session ID for 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 a notification that the UE desires 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 the current 5G system design, the UE cannot indicate to the network that the deregistration type is "re-registration required". Step 1 deregistration request can be further extended to allow the UE to indicate to the network that the deregistration type is "re-registration required". The advantage of allowing the UE to indicate to the network that re-registration is necessary is that, for example, if the UE simply needs to perform a NAS-MM reset, it can indicate to the network that it is planning to re-register.

[0110] Alternatively or additionally, the UE deregistration request in Step 1 may be extended to allow the UE to indicate 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). Mobility status may be used by the network to determine whether the same UPF can service the UE upon re-registration. Similarly, other predictive information may be included in the deregistration request that the network may use to determine how to configure context memory and re-establishment parameters, buffering in the UPF, etc.

[0111] As an alternative or addition, 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 can assume that whenever the UE sets the deregistration type IE in the deregistration request to "re-registration required," the UE's NAS-SM context should be preserved while the UE is RM-DEREGISTERED. The drawback of this alternative is that the NAS-SM context may be preserved on the network even if the UE does not want it to be preserved.

[0112] Previously, in the Namf_Communication_N1N2MessageTransfer service operation of the PDU session establishment procedure, it was explained that whenever the NAS-SM context preservation enable indicator is provided to the AMF by the SMF, 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 submit 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 any remaining NAS-SM contexts preserved for the UE.

[0113] The call to the Nsmf_PDUSession_ReleaseSMContext request in step 2 may be extended so 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 contents of the N1 SM container to recognize that the UE is going to enter the RM-DEREGISTED state and that the NAS-SM context should be preserved. The N1 SM container may contain a preserve expiration timer. Alternatively, step 2 may call Nsmf_PDUSession_UpdateSMContext, which may allow the establishment of a transfer tunnel between UPFs controlled by different SMFs. The procedure in Figure 8 may be extended so that step 3 is skipped, or step 3 may be extended so that the SMF notifies the UPF that the UE is going to enter the RM-DEREGISTED state and that the NAS-SM context should be preserved. The advantage of the UE notifying the UPF that it is moving to the RM-DEREGISTED state and that the NAS-SM context should be preserved is that the UPF knows whether to buffer or discard any DL packets received for the PDU session. The SMF can then indicate to the UPF whether a packet should be buffered or discarded.

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

[0115] The procedure in Figure 8 may be extended so that step 5a is skipped, or step 5a may be extended so that the UE moves to the RM-DEREGISTED state and the SMF notifies the PCF that the NAS-SM context should be preserved.

[0116] The procedure in Figure 8 may be extended so that steps 5b-c are skipped, or steps 5b-c may be extended so that instead of unjoining from the UDM or indicating to the UDM that it should remove the association it had stored between the SMF identity information 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 in Figure 8 may be extended so that step 7 is extended so that the deregistration acceptance 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 a NAS-MM reset, whether QoS rules for certain flows are maintained, etc.). Multiple N1 SM containers may be sent to the UE (e.g., an 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 can display a graphical user interface (GUI) that allows the user to initiate a NAS-MM reset. The GUI can further allow the user to select which UE applications should have their contexts preserved during the NAS-MM reset. The UE can then determine which PDU sessions associated with the selected UE application(s) should have their SM contexts preserved during the NAS-MM reset, and then include the PDU session IDs of the PDU sessions associated with the selected UE application(s) in the deregistration request initiated by the UE.

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

[0120] In step 2, the event can trigger the AMF to send a deregistration request to the UE. The deregistration 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 RM-DEREGISTERED. The request can identify which PDU sessions' NAS-SM contexts need 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 may include a notification 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] A deregistration request may also include a timer-based deregistration. A timer-based deregistration may indicate to the UE that it should deregister before the timer expires. The advantage of providing such a timer is that, compared to requiring the UE to deregister immediately, the ME portion of the UE can send a deregistration warning notice to applications hosted by the TE portion of the ME. Applications receiving the warning can then save their associated application layer context and send the warning to any application server with which they communicate. Warnings to application servers may be sent via the user plane and may indicate a time window when the UE application may be unavailable. AT commands may be used to send warning notices from the ME portion of the UE to applications hosted on the TE portion of the UE.

[0122] Alternatively, it may not be necessary to explicitly indicate to the UE that its NAS-SM context should be preserved while the UE is RM-DEREGISTERED. Rather, the UE can assume that whenever the AMF sets the deregistration type IE in the deregistration request to "re-registration required," its NAS-SM context should be preserved while the UE is RM-DEREGISTERED. The drawback of this alternative is that the NAS-SM context may be preserved on the network even if the AMF does not want it to be preserved.

[0123] The procedure in 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 unjoining from the UDM or indicating to the UDM that the UDM should remove the association it had stored between the SMF identity information 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 in Figure 9 can be extended in the same way as steps 2-5 of the deregistration procedure initiated by the UE described above.

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

[0126] Step 6 of the procedure in Figure 9 may be extended to indicate to the network whether the UE will preserve the SM context for each PDU session when the UE sends a deregistration acceptance message. For example, the deregistration acceptance message could include a per-PDU session notification that the UE will preserve 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 preserve the SM context.

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

[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 have their contexts preserved during a NAS-MM reset. The UE can then determine that any PDU sessions associated with the selected UE application(s) should have their SM contexts preserved during a NAS-MM reset, and then the UE can include the PDU session IDs of the PDU sessions associated with the selected UE application(s) in the unregistration acceptance message.

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

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

[0131] An alternative approach is to not change the processing of the UE NAS-MM and NAS-SM contexts of the UE and AMF when the UE is in the RM-DEREGISTERED state, but instead create a new substate or operating mode within the RM-REGISTERED state. This new state or operating mode may be called RM-REGISTERED-PAUSE and may be entered when a NAS request is made from the network to the UE, or from the AMF to the UE. The request may also 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 RM state models of the AMF and UE may be extended to support the RM-REGISTERED-PAUSE state.

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

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

[0134] To return to the RM-REGISTERED state (for example, to send or receive data), the UE can initiate a registration procedure while in the RM-REGISTERED-PAUSE state. Once the accepted registration procedure is complete, the UE can return to the RM-REGISTERED state. The UE may enter the RM-DEREGISTERED state when the SM context memory expiration timer expires.

[0135] The SM context storage expiration timer may be started when the UE enters the RM-REGSITERED-PAUSE state. The UE may enter the RM-DEREGISTERD state if the timer expires, provided there are no ongoing registration procedures. The UE may stop the timer when a registration procedure is initiated (for example, when the UE is in the 5GMM-REGISTERED.ATTEMPTING-REGISTRTION-UPDATE state). Expiration of time may mean 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 can be considered a substate 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 UE should be considered to be in the CM-IDLE state because the UE's N1 connection is not active.

[0138] It should be noted that the UE may send multiple SM context memory expiration timers (e.g., a timer for each PDU session). The UE may maintain a separate timer for each received SM context memory expiration timer value. When the SM context memory expiration timer associated with a PDU session expires, the UE may delete the NAS-SM context associated with that PDU session. The UE may stop all timers when the registration procedure is initiated (e.g., when the UE is in the 5GMM-REGISTERED.ATTEMPTING-REGISTRTION-UPDATE state). Once all timers have expired, the UE may enter the RM-DEREGISTERED state.

[0139] A 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 requests the UE to reset its NAS-MM context by sending an N1 reset request to the network. The request may indicate that the UE is entering the 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 can then notify the SMF(s) associated with the PDU session whose context needs to be preserved and help coordinate the preservation timers between the UE and the SMFs.

[0140] An 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 state. The request can identify which PDU sessions' NAS-SM contexts need 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 a notification that the UE desires 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] Receiving an 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 to include both the SM context ID and the N1 SM container that the UE sent to the SMF. Using the contents of the N1 SM container, the SMF can recognize that the UE will move to the RM-REGISTERED-PAUSED state and that the NAS-SM context should be preserved.

[0142] The SMF call in the Nsmf_PDUSession_ReleaseSMContext response may be extended to allow the SMF to provide the SM context storage ID and SM context storage expiration timer to the AMF and N1 SM container. The N1 SM container may also include the SM context storage ID and SM context storage expiration time. The SM context storage ID is an identifier for the SM context. The SM context storage ID can 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 expiration time may be stored with the SM context. The SMF can use the time value that the UE has included in the N1 SM container to derive the SM context storage expiration time that will be sent to the UE and N1 SM container.

[0143] The AMF can send an N1 reset acceptance message to the UE that includes the N1 SM container sent to the AMF by the SMF.

[0144] An event may occur on the network, and the network may determine that the event requests the UE to reset its NAS-MM context by sending an N1 reset request, but that the NAS-SM context may be preserved while the UE's NAS-MM context is being 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 the RM-REGISTERED-PAUSE state. The AMF can then notify the SMF(s) associated with the PDU session 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 and sends an N1 reset request to the UE, the AMF can extend the N1 reset request so that it can indicate to the UE that the UE's NAS-SM context should be preserved while the UE is in RM-REGISTERED-PAUSE state. The request can identify which PDU sessions' NAS-SM contexts need 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 may include a notification that the network wants the NAS-SM context to be maintained and a time value indicating how long the UE should preserve its NAS-SM context.

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

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

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

[0149] As explained earlier, a UE can initiate a procedure to reset the UE's NAS-MM context in the UE and AMF. The trigger for the UE to initiate this procedure may be that the UE was connected to the network for emergency service and wishes to change that connection to a non-emergency connection; the trigger for the UE to initiate this procedure may be that the UE's configuration has been 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 that requires a NAS-MM context 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 can store or maintain the NAS-SM context for any PDU session for which the persistent NAS-SM context feature is enabled. The UE can determine that the persistent NAS-SM context feature is enabled based on negotiation with the network, as previously described in the descriptions of PDU session establishment, UE-initiated deregistration, and extensions to network-initiated deregistration procedures. As previously described, the amount of time the UE stores the NAS-SM context for each PDU session can be determined by a timer. In other words, the UE can delete the NAS-SM context when it detects that the timer has expired.

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

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

[0153] After resetting the NAS-MM context, the UE can send a registration request to the network to move to the RM-REGISTERED state. This may mean that the UE transitions from the RM-DEREGISTERED state to the RM-REGISTERED state, or that the UE transitions from the RM-REGISTERED-PAUED state to the RM-REGISTERED state, as mentioned above.

[0154] When a 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 does not allow the UE to include a “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 to the network by the UE when performing initial registration.

[0155] The presence of a "list of PDU sessions to be activated" in the initial registration request can serve as a notification to the network that the UE wishes to re-establish the NAS-SM context stored within the UE while it was in the RM-DEREGISTED state. The "list of PDU sessions to be activated" is communicated to the network in the NAS PDU session status IE.

[0156] When a UE attempts to move from the RM-REGISTERED-PAUSE state to the RM-REGISTERED state, the UE sends a registration request to the network. A new registration type may be defined to indicate that the UE is performing a mobility registration update, or to explicitly indicate that the purpose of the registration request is to move to the 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 to the network in the new IE to indicate that it 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 a 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 that the UE last registered with. While it is likely, this is not guaranteed, that the RAN will select the same AMF for which the 5G-GUTI was provided to serve the UE. If the RAN selects a different AMF to serve the UE, the re-establishment of the NAS-SM context can still proceed, as the NAS-SM was stored in the UDM and SMF(s).

[0159] It should be noted that while 5G-GUTI can be considered part of the NAS-MM context, it can be preserved while the rest of the NAS-MM context is cleared. The advantage of preserving 5G-GUTI is that it can be used to help the RAN determine which AMF should serve the UE.

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

[0161] Once the context is restored, the UE may notify any application it hosts that the SM context has been restored. For example, the notification could alert the application that it has network connectivity again, or it could trigger the application to use the restored PDU session with the SM context recovered. As a result, application layer messages may be sent to the network server to notify 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. Applications hosted by the UE may then notify the application server that the application is about to enter a period during which it will be unreachable. The notification may also provide the application server with a timer value to indicate how long the application server can expect the UE application to preserve its application layer context.

[0163] The NAS-SM context preservation features described herein may be subject to validity criteria that specify conditions for the applicability of the features. The validity criteria may consist of one or more of the following: validity area criteria, time criteria, or access technology-related criteria such as access technology type. For example, the validity area criteria may include one or more of the following: 3GPP location types, e.g., PLMN (public land mobile network), TAC (tracking area code), LAC (location area code), cell identifier, WLAN (wireless local access network) location types, e.g., SSID (service set identifier), HESSID (homogeneous extended SSID), BSSID (basic SSID), or geographic location types in the form of latitude, longitude, or radius, as defined in TS 23.032, for example. The time criteria may include one or more of the following: time start, time stop, date start, date stop, and day of the week. Access technology standards may include one or more of the 3GPP RATs (radio access technologies), such as UTRAN RAT (universal mobile telecommunications service terrestrial radio access network RAT), EUTRAN (evolved UTRAN) RAT, NR RAT, and WLAN RAT.

[0164] A UE can receive validity criteria in a PDU session acceptance message or a registration acceptance message. When validity criteria are received in a registration acceptance message, they can be applied to any PDU session associated with the UE. When validity criteria are received in a PDU session acceptance message, they can only be applied to the PDU session associated with the PDU session acceptance message.

[0165] The validity criteria can 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 UE's current state 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 standards, and New Radio (NR), also referred to as "5G." 3GPP NR standard development is expected to continue and include the definition of next-generation radio access technology (New RAT), which is expected to include the provision of new flexible radio access below 7 GHz and new ultra-mobile broadband radio access above 7 GHz. Flexible radio access is expected to consist of new non-backward compatible radio access in the new spectrum below 7 GHz and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide range of 3GPP NR use cases with branching requirements. Ultra-mobile broadband is expected to include cmWave and mmWave spectra, for example, providing opportunities for ultra-mobile broadband access for indoor applications and hotspots. In particular, ultra-mobile broadband is expected to share a common design framework with flexible radio access below 7 GHz, utilizing centimeter-wave and millimeter-wave specific design optimizations.

[0167] 3GPP identifies a variety of use cases that NR is expected to support, resulting in diverse user experience requirements for data transfer speed, latency, and mobility. Common use cases include 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 saving), and enhanced vehicle-to-everything (eV2X) communications, which may include any of the following: vehicle-to-vehicle communication (V2V), vehicle-to-infrastructure communication (V2I), vehicle-to-network communication (V2N), vehicle-to-pedestrian communication (V2P), and vehicle-to-everything communication with other entities. Specific services and applications in these categories include, to name a few, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first-person connectivity, automotive e-calls, disaster alerts, real-time gaming, multi-person video conferencing, autonomous driving, augmented reality, haptic internet, virtual reality, home automation, robotics, and aerial drones. All of these use cases are contemplated herein.

[0168] Figure 15A illustrates an exemplary communication system 100 in which the systems, methods, and apparatus described and claimed herein may be used. The communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g, which may be referred to WTRUs 102 or a plurality of WTRUs 102 in general or collectively. The communication system 100 may also include radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105b, core networks 106 / 107 / 109, a public switched telephone network (PSTN) 108, the internet 110, other networks 112, and network services 113, 113. Network services 113 may include, for example, a V2X server, V2X functionality, a ProSe server, ProSe functionality, IoT services, 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 WTRU 102 may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. In the example in Figure 15A, each WTRU 102 is illustrated in Figures 15A-E as a handheld wireless communication device. In the wide variety of use cases intended for wireless communication, each WTRU may include, or may include, any type of device or apparatus configured to transmit and / or receive wireless signals, including, but are not limited to, user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptop computers, tablets, netbooks, notebooks, personal computers, wireless sensors, household electrical appliances, wearable devices such as smartwatches or smart clothing, medical or e-health devices, robots, industrial equipment, drones, vehicles such as automobiles, buses or trucks, or airplanes.

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

[0171] TRP119a, 119b may be any type of device configured to wirelessly interface with at least one of WTRU102d to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, network services 113, and / or other networks 112. RSU120a, 120b may be any type of device configured to wirelessly interface with at least one of WTRU102e or 102f to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, other networks 112, and / or network services 113. For example, base stations 114a and 114b may be base transceiver stations (BTS), node-B, enode-B, home node-B, home enode-B, next generation node-B (gNode-B), satellite, site controller, access point (AP), wireless router, etc.

[0172] Base station 114a may be part of 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), and relay nodes. Similarly, base station 114b may be part of RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as a BSC, RNC, and relay nodes. Base station 114a may be configured to transmit and / or receive radio signals within a specific geographic area, which may be referred to as a cell (not shown). Similarly, base station 114b may be configured to transmit and / or receive wired and / or radio signals within a specific geographic area, which may also be referred to as a cell (not shown). A cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, for example, base station 114a may include three transceivers, for example, one transceiver for each sector of the cell. The base station 114a may use Multiple-Input Multiple Output (MIMO) technology, and therefore, for example, may utilize multiple transceivers for each sector of a cell.

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

[0174] Base station 114b may communicate with one or more of the RRH 118a and 118b, TRP 119a and 119b, and / or RSU 120a and 120b via wired or air interfaces 115b / 116b / 117b, which may be any suitable wired (e.g., cable, optical fiber, etc.) or radio communication link (e.g., RF, microwave, IR, UV, visible light, centimeter wave, millimeter wave, etc.). Air interfaces 115b / 116b / 117b may be established using any suitable RAT.

[0175] RRH118a, 118b, TRP119a, 119b, and / or RSU120a, 120b may communicate with one or more WTRU102c, 102d, 102e, 102f via air interface 115c / 116c / 117c, which may be any suitable radio communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, centimeter wave, millimeter wave, etc.). Air interface 115c / 116c / 117c may be established using any suitable RAT.

[0176] The WTRU102s can communicate with each other via direct air interfaces 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 interfaces 115d / 116d / 117d may be established using any suitable RAT.

[0177] The communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, base stations 114a in RAN103 / 104 / 105, and WTRU102a, 102b, 102c, or RRH118a, 118b, TRP119a, 119b, and / or RSU120a, 120b, and WTRU102c, 102d, 102e, and 102f in RAN103b / 104b / 105b may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) and Terrestrial Radio Access (UTRA), which may establish air interfaces 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 Advanced HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

[0178] Base stations 114a in RAN103 / 104 / 105, and WTRU102a, 102b, 102c, and 102g, or RRH118a and 118b, TRP119a and 119b, and / or RSU120b and 120b, and WTRU102c and 102d in RAN103b / 104b / 105b, may implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish air interfaces 115 / 116 / 117 or 115c / 116c / 117c, respectively, using, for example, Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A). Air interfaces 115 / 116 / 117 or 115c / 116c / 117c may implement 3GPP NR technology. LTE and LTE-A technology may include LTE D2D and / or V2X technology, as well as interfaces (such as sidelink communication). Similarly, 3GPP NR technology may include NR V2X technology and interfaces (such as sidelink communication).

[0179] Base stations 114a in RAN103 / 104 / 105, and WTRU102a, 102b, 102c, and 102g, or RRH118a and 118b, TRP119a and 119b, and / or RSU120a and 120b, and WTRU102c, 102d, 102e, and 102f in RAN103b / 104b / 105b, are IEEE 802.16 (e.g., WiMAX (Worldwide Interoperability for Microwave Access), 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 Telephone). Wireless technologies such as GSM communications, Enhanced Data rates for GSM Evolution (EDGE), and GSM EDGE (GERAN) can be implemented.

[0180] The base station 114c in Figure 15A may be, for example, a wireless router, home node B, home e-node B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as offices, homes, vehicles, trains, airborne, satellite, factories, and campuses. The base station 114c and WTRU102, for example WTRU102e, can implement wireless technologies such as IEEE 802.11 to establish a Wireless Local Area Network (WLAN). Similarly, the base station 114c and WTRU102, for example WTRU102d, can implement wireless technologies such as IEEE 802.15 to establish a Wireless Personal Area Network (WPAN). The base station 114c and WTRU102, for example WTRU102e, can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish picocells or femtocells. As shown in Figure 15A, base station 114c may have a direct connection to the internet 110. Therefore, base station 114c may not need to access the internet 110 via the core network 106 / 107 / 109.

[0181] RAN103 / 104 / 105 and / or RAN103b / 104b / 105b may communicate with core networks 106 / 107 / 109, which may be any type of network configured to provide voice, data, messaging, authorization and authentication, applications, and / or Voice Over Internet Protocol (VoIP) services to one or more of WTRU102. For example, core networks 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 implement high-level security functions such as user authentication.

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

[0183] Core networks 106 / 107 / 109 may also function as gateways for WTRU 102 to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include circuit-switched telephone networks providing Plain Old Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using 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. Other networks 112 may include wired and / or wireless 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 RAN 103 / 104 / 105 and / or a different RAT as RAN 103b / 104b / 105b.

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

[0185] Although not shown in Figure 15A, it will be understood that user equipment may have a wired connection to the 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 can be equally applied to UEs, which are WTRUs and UEs that use wired connections to connect to the network. For example, ideas that apply to wireless interfaces 115, 116, 117, and 115c / 116c / 117c can be equally applied to wired connections.

[0186] Figure 15B is a system diagram of an exemplary RAN103 and core network 106. As described above, RAN103 can communicate with WTRU102a, 102b, and 102c via air interface 115 using UTRA radio technology. RAN103 can also communicate with core network 106. As shown in Figure 15B, RAN103 may include nodes-B140a, 140b, and 140c, each of which may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via air interface 115. Nodes-B140a, 140b, and 140c may each be associated with a specific cell (not shown) within RAN103. RAN103 may also include RNC142a, 142b. It is understood that RAN103 may include any number of node B and radio network controllers (RNCs).

[0187] As shown in Figure 15B, nodes B140a and B140b can communicate with RNC142a. Furthermore, node B140c can communicate with RNC142b. Nodes B140a, B140b, and B140c can communicate with their respective RNC142a and B142b via the Iub interface. RNC142a and B142b can communicate with each other via the Iur interface. Each of RNC142a and B142b may be configured to control their respective nodes B140a, B140b, and B140c to which it is connected. In addition, each of RNC142a and B142b may be configured to perform or support other functions such as external loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, and data encryption.

[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 aforementioned 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] RNC142a in RAN103 may be connected to MSC146 in core network 106 via IuCS interface. MSC146 may be connected to MGW144. MSC146 and MGW144 may provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional terrestrial line communication devices.

[0190] RNC142a within RAN103 may also be connected to SGSN148 in core network 106 via an IuPS interface. SGSN148 may be connected to GGSN150. SGSN148 and GGSN150 may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 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] Figure 15C is a system diagram of an exemplary RAN 104 and core network 107. As described above, RAN 104 can communicate with WTRU 102a, 102b, and 102c via the air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with core network 107.

[0193] RAN104 may include e-nodes-B160a, 160b, and 160c, but it is understood that RAN104 may include any number of e-nodes-B. Each of e-nodes-B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. For example, e-nodes-B160a, 160b, and 160c may perform MIMO technology. Thus, e-node-B160a may, for example, use multiple antennas to transmit a wireless signal to WTRU102a and receive a wireless signal from WTRU102a.

[0194] Each of the e-nodes B160a, 160b, and 160c may be associated with a specific 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 Figure 15C, the e-nodes B160a, 160b, and 160c may communicate with each other via the 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 aforementioned 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 MME162 can be connected via the S1 interface to each of the e-nodes B160a, 160b, and 160c within RAN104 and can function as a control node. For example, the MME162 may perform roles such as authenticating users for WTRU102a, 102b, and 102c, bearer activation / deactivation, and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 may also provide control plane functionality for exchanges between RAN104 and other RANs (not shown) using other radio technologies such as GSM or WCDMA.

[0197] The serving gateway 164 may be connected to each of the e-nodes B160a, 160b, and 160c in RAN104 via the S1 interface. The serving gateway 164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The serving gateway 164 may also perform other functions, such as anchoring the user plane during e-node B handover, triggering paging when downlink data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

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

[0199] The core network 107 can facilitate communication with other networks. For example, the core network 107 can provide WTRU 102a, 102b, and 102c with access to a circuit-switched network such as PSTN 108, thereby facilitating communication between WTRU 102a, 102b, and 102c and conventional fixed-line 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 functions as an interface between the core network 107 and PSTN 108. In addition, the core network 107 can provide WTRU 102a, 102b, and 102c with access to network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

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

[0201] RAN105 may include g-nodes-B180a and 180b. It will be understood that RAN105 may include any number of g-nodes-B. Each of g-nodes-B180a and 180b may include one or more transceivers for communicating with WTRU102a and 102b via air interface 117. When integrated access and backhaul connectivity is used, the same air interface may be used between the WTRU and the g-nodes-B, and this air interface may be the core network 109 via one or more gNBs. g-nodes-B180a and 180b may implement MIMO, MU-MIMO, and / or digital beamforming technologies. Thus, g-node-B180a may, for example, use multiple antennas to transmit wireless signals to and receive wireless signals from WTRU102a. It should be understood that RAN105 may use other types of base stations, such as e-nodes-B. It should also be understood that RAN105 may employ more than one type of base station. For example, RAN may use e-node-B and g-node-B.

[0202] N3IWF199 may include non-3GPP access points 180c. It will be understood that N3IWF199 may include any number of non-3GPP access points. Non-3GPP access points 180c may include one or more transceivers for communicating with WTRU102c via air interface 198. Non-3GPP access points 180c may communicate with WTRU102c via air interface 198 using the 802.11 protocol.

[0203] Each of the e-nodes B180a and B180b may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling, etc., in the uplink and / or downlink. As shown in Figure 15D, the g-nodes B180a and B180b may communicate with each other, for example, via the Xn interface.

[0204] The core network 109 shown in Figure 15D may be a 5G core network (5GC). The core network 109 may provide numerous communication services to customers interconnected by a radio access network. The core network 109 includes several entities that perform the functions of the core network. As used herein, the terms “core network entity” or “network function” refer to any entity that performs one or more functions of the core network. Such core network entities may be devices configured for radio or network communications, or logical entities implemented in the form of computer executable instructions (software) stored in the memory of a computer system such as system 90 shown in Figure 15G and executed on its processors.

[0205] In the example in 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. Although each of the aforementioned 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 entities other than the core network operator. Furthermore, it should be understood that a 5G core network may not consist of all of these elements, but may include additional elements, and may consist of multiple examples of each of these elements. Figure 15D shows network functions directly connected to each other, but it should be understood that they may communicate via routing agents such as a diameter routing agent or a message bus.

[0206] In the example in 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 invocations, and so on.

[0207] AMF172 can be connected to RAN105 via the N2 interface and can function as a control node. For example, AMF172 can perform registration management, connection management, reachability management, access authentication, and access authorization roles. AMF can forward user plane tunnel configuration information to RAN105 via the N2 interface. AMF172 can receive user plane tunnel configuration information from SMF via the N11 interface. Generally, AMF172 can route and forward NAS packets to and from WTRU 102a, 102b, and 102c via the N1 interface. The N1 interface is not shown in Figure 15D.

[0208] SMF174 can be connected to AMF172 via the N11 interface. Similarly, SMF can be connected to PCF184 via the N7 interface and to UPF176a and 176b via the N4 interface. SMF174 can function as a control node. For example, SMF174 may be responsible for session management, IP address assignment for WTRU102a, 102b, and 102c, management and configuration of traffic steering rules in UPF176a and UPF176b, and generation of downlink data notifications to AMF172.

[0209] UPF176a and UPF176b may provide WTRU102a, 102b, and 102c with access to a packet data network (PDN), such as the Internet 110, to facilitate communication between WTRU102a, 102b, and 102c and other devices. UPF176a and UPF176b may also provide WTRU102a, 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 data packets. UPF176a and UPF176b may receive traffic steering rules from SMF174 via the N4 interface. UPF176a and UPF176b may provide access to a packet data network by connecting it to the N6 interface or by connecting it to each other or to other UPFs via the N9 interface. In addition to providing access to the packet data network, UPF176 can play a role in packet routing and forwarding, enforcement of policy rules, quality of service for user plane traffic, and downlink packet buffering.

[0210] AMF172 can also be connected to N3IWF199, for example, via the N2 interface. N3IWF facilitates connectivity between WTRU102c and the 5G core network 170, for example, via radio interface technology not defined by 3GPP. AMF can interact with N3IWF199 in the same or similar manner as it interacts with RAN105.

[0211] PCF184 may be connected to SMF174 via the N7 interface, to AMF172 via the N15 interface, and to Application Function (AF) 188 via the N5 interface. The N15 and N5 interfaces are not shown in Figure 15D. PCF184 may also provide policy rules to control plane nodes such as AMF172 and SMF174, enabling the control plane nodes to enforce these rules. PCF184 may send policies to AMF172 for WTRU102a, 102b, and 102c so that AMF can deliver the policies to WTRU102a, 102b, and 102c via the N1 interface. The policies can then be enforced or applied in WTRU102a, 102b, and 102c.

[0212] UDR178 can function as a repository for authentication certificates and membership information. UDR may connect to network functions, which can then append to, read, and modify data in the repository. For example, UDR178 may connect to PCF184 via the N36 interface. Similarly, UDR178 may connect to NEF196 via the N37 interface, and UDR178 may connect to UDM197 via the N35 interface.

[0213] UDM197 can function as an interface between UDR178 and other network functions. UDM197 can authorize network functions for access to UDR178. For example, UDM197 may connect to AMF172 via the N8 interface, or to SMF174 via the N10 interface. Similarly, UDM197 may connect to AUSF190 via the N13 interface. UDR178 and UDM197 can be tightly integrated.

[0214] The AUSF190 performs authentication-related operations and connects to the UDM178 via the N13 interface and to the AMF172 via the N12 interface.

[0215] NEF196 exposes the capabilities and services of the 5G core network 109 to the application function (AF) 188. Exposure may occur via the N33 API interface. The NEF may connect to AF188 via the N33 interface, or it may connect to other network functions to expose the capabilities and services of the 5G core network 109.

[0216] The application function 188 may interact with network functions within the 5G core network 109. The interaction between the application function 188 and the network functions may occur via a direct interface or via the NEF 196. The application function 188 may be considered part of the 5G core network 109, or it may be outside the 5G core network 109 and deployed by a company that has a business relationship with a mobile network operator.

[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 allows operators to create customized networks that provide optimized solutions for different market scenarios requiring 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., large-scale IoT, critical communications, V2X, and enhanced mobile broadband) that have highly varied and sometimes extreme requirements. Without network slicing technology, the network architecture is likely to lack sufficient flexibility and scalability 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 deployment of new network services more efficient.

[0219] Referring again to Figure 15D, in the network slicing scenario, WTRU102a, 102b, or 102c may be connected to AMF172 via the N1 interface. The AMF may be logically part of one or more slices. The AMF may coordinate the connection or communication of WTRU102a, 102b, or 102c with one or more UPF176a and 176b, SMF174, and other network functions. Each of the UPF176a and 176b, SMF174, 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 have access to different computing resources, security certificates, etc.

[0220] The core network 109 may facilitate communication 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 functions 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 communication via the Short Message Service. For example, the 5G core network 109 may facilitate the exchange of non-IP data packets between WTRUs 102a, 102b, and 102c and the server or application function 188. In addition, the core network 170 may provide access to network 112 to WTRUs 102a, 102b, and 102c, and network 112 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 Figures 15A, 15C, 15D, or 15E are identified by the names given to those entities in certain existing 3GPP specifications, but future entities and functions may be identified by other names, and it is understood 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 only as examples, and the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether currently defined or hereafter defined.

[0222] Figure 15E illustrates an exemplary communication system 111 in which the systems, methods, and apparatus described herein may be used. The communication system 111 may include radio transmit / receive units (WTRUs) A, B, C, D, E, 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 station gNBs, V2X networks, and / or other network elements. One or more, or all, WTRUs A, B, C, D, E, and F may be outside the scope of access network coverage 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 can communicate with each other via the Uu interface 129 through the gNB 121 if they are within access network coverage 131. In the example in Figure 15E, WTRUs B and F are shown within access network coverage 131. WTRUs A, B, C, D, E, and F may also communicate directly with each other via sidelink interfaces such as interfaces 125a, 125b, or 128 (e.g., PC5 or NR PC5), regardless of whether they are under or outside access network coverage 131. For example, in the example in Figure 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 communication (V2N) 133 or side-link interface 125b. WTRUs A, B, C, D, E, and F may communicate with V2X server 124 via vehicle-to-infrastructure communication (V2I) interface 127. WTRUs A, B, C, D, E, and F may communicate with another UE via vehicle-to-human communication (V2P) interface 128.

[0225] Figure 15F is a block diagram of an exemplary apparatus or device WTRU102 that may be configured for wireless communication and operation by the systems, methods, and apparatus described herein, such as WTRU102 in Figures 15A to 15E. As shown in Figure 15F, the exemplary WTRU102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and other peripherals 138. It is understood that WTRU102 may include any partial combination of the aforementioned elements. Furthermore, base stations 114a and 114b, and / or, but not limited to, nodes that base stations 114a and 114b may represent, such as transceiver stations (BTS), node-B, site controllers, access points (AP), home node-B, evolved home node-B (eNodeB), home evolved node-B (HeNB), home evolved node-B gateway, next-generation node-B (gnode-B), and proxy nodes, are illustrated in Figure 15F and may include some or all of the elements described herein.

[0226] The processor 118 may be a general-purpose processor, a dedicated 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 functions that enable WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 which may be coupled to a transmit / receive element 122. Although Figure 15F shows the processor 118 and transceiver 120 as separate components, it will be understood that the processor 118 and 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 a signal to or receive a signal from a base station (e.g., base station 114a in Figure 15A) via air interfaces 115 / 116 / 117, or to transmit a signal to or receive a signal from another UE via air interfaces 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 optical signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of radio or wired signals.

[0228] In addition, although the transmit / receive element 122 is illustrated as a single element in Figure 15F, 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., multiplex antennas) for transmitting and receiving wireless signals via the air interfaces 115 / 116 / 117.

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

[0230] The processor 118 of the WTRU102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad / indicator 128 (for example, a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and may receive user input data from them. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. In addition, the processor 118 may access information from any suitable type of memory, such as non-removable memory 130 and / or removable memory 132, and may store data in such memory. 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. Removable memory 132 may include a subscriber identity module. This may include modules, SIM cards, memory sticks, secure digital (SD) memory cards, etc. The processor 118 may access information from 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), and store data in that memory.

[0231] The processor 118 may receive power from the power supply 134 and be configured to distribute and / or control power to other components within the WTRU 102. The power supply 134 may be any suitable device for supplying power to the WTRU 102. For example, the power supply 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 the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interfaces 115 / 116 / 117 and / or determine its location based on the timing of signals received from two or more nearby base stations. It is understood that the WTRU 102 may obtain location information by any preferred location determination method.

[0233] The processor 118 may be further coupled to other peripherals 138 and may include one or more software modules and / or hardware modules that provide additional features, functions, 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 photography or video), 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, or a video game player module.

[0234] WTRU102 may be included in sensors, household electrical appliances, wearable devices such as smartwatches or smart clothing, medical or e-health devices, robots, industrial equipment, drones, automobiles, trucks, trains or other vehicles, or other devices such as airplanes. WTRU102 may be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces, such as an interconnect interface which may include one of the peripheral devices 138.

[0235] Figure 15G is a block diagram of an exemplary computing system 90 in which one or more devices from the communication networks illustrated in Figures 15A, 15C, 15D, and 15E may be embodied, such as specific nodes or functional entities in RAN 103 / 104 / 105, core networks 106 / 107 / 109, PSTN 108, the Internet 110, other networks 112, or network services 113. The computing system 90 may include a computer or a server and may be controlled primarily by computer-readable instructions. Computer-readable instructions may be in the form of software, in any location, 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 dedicated 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 functions that enable the computing system 90 to operate on a communication network. The coprocessor 81 is any processor distinct from the main processor 91 and may perform additional functions or assist the processor 91. The processor 91 and / or coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

[0236] During operation, the processor 91 fetches, decodes, and executes instructions, and transmits information to other resources via the main data transfer path of the computing system, the system bus 80. Such a system bus connects components within the computing system 90 and defines a medium for data exchange. The 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 the Peripheral Component Interconnect (PCI) bus.

[0237] The memory coupled to the system bus 80 includes random access memory (RAM) 82 and read-only memory (ROM) 93. Such memory includes circuitry that enables 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 modified by the processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. When an instruction is executed, the memory controller 92 can provide address translation functionality that translates virtual addresses to physical addresses. The memory controller 92 can also provide memory protection functionality that isolates processes within the system and separates system processes from user processes. Thus, a program running in the first mode can only access memory mapped by its own process virtual address space and cannot access memory in the virtual address space of another process unless inter-process memory sharing is configured.

[0238] In addition, the computing system 90 may include a peripheral device controller 83 that plays a role in communicating commands from the 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 includes the electronic components necessary to generate the video signal transmitted to the display 86.

[0240] Furthermore, the computing system 90 may include communication circuits, such as a wireless or wired network adapter 97, which can be used to connect the computing system 90 to an external communication network or device, such as RAN 103 / 104 / 105, core networks 106 / 107 / 109, PSTN 108, the Internet 110, WTRU 102, or other networks 112 in Figure 15A-1E, enabling the computing system 90 to communicate with other nodes or functional entities in those networks. The communication circuits may be used alone or in combination with the processor 91 to perform the transmission and reception steps of the specific devices, nodes, or functional entities described herein.

[0241] Any or all of the apparatus, 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, and it is understood that when such instructions are executed by a processor, such as processor 118 or 91, the processor will carry out 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 that are executed on a processor of an apparatus or computing system configured for wireless and / or wired network communication. Computer-readable storage mediums include volatile and non-volatile, removable and non-removable media that are implemented by any non-temporary (e.g., tangible or physical) method or technique for storing information, but such computer-readable storage mediums do not contain signals. Computer-readable storage media include RAM, ROM, EEPROM, flash memory, or other memory technologies; CD-ROM, digital versatile disks (DVDs), or other optical disk storage; magnetic cassettes, magnetic tapes, magnetic disk storage devices, or other magnetic storage devices; or any other tangible or physical media that can be used to store desired information and 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. A method implemented by a wireless transmit / receive unit (WTRU) for communication with a network, Sending a registration request message to a network node by the WTRU, which requests the network node to register with the network, wherein the registration request message includes a notification that the WTRU can store context information associated with the communication between the WTRU and the network when the WTRU becomes unavailable to the network. The WTRU receives a registration acceptance message from the network node, the registration acceptance message includes a notification that the network supports the storage of context information when the WTRU becomes unavailable to the network. Based on the determination that the WTRU will become unavailable to the network, the WTRU transmits a first message to the network indicating a request to save the context information, wherein the first message includes a notification of the period during which the WTRU will be unavailable. A method comprising sending a second message to the network after the aforementioned period has ended, indicating that the WTRU is available to the network.

2. Modem reset, Operating system update, Software update, Deregistration requests initiated by the network, Deregistration requests initiated by WTRU, N1 reset request initiated by the network, An N1 reset request initiated by the WTRU, or Change from RM-REGISTERED state to RM-DEREGISTERED state The method according to claim 1, further comprising determining that the WTRU becomes unavailable to the network due to any one or more of the following.

3. The method according to claim 1, wherein the context information includes non-access tier (NAS) session management (SM) context information.

4. The aforementioned context information, Protocol Data Unit (PDU) session identifier, Data Network Name (DNN), Single network slice support information (S-NSSAI), or Internet Protocol (IP) address The method according to claim 1, comprising one or more of the following.

5. The first message indicating the request to save the context information is N1 reset request message, or Deregistration request message initiated by WTRU The method according to claim 1, comprising one of the following.

6. The method according to claim 1, wherein the second message indicating that the WTRU is available to the network includes a second registration request message.

7. The method according to claim 1, further comprising sending a request to the network for establishing a protocol data unit (PDU) session, the request for establishing the PDU session being requested to preserve the context information relating to the PDU session when the WTRU becomes unavailable.

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

9. A wireless transmit / receive unit (WTRU) comprising a processor and a memory for storing instructions, wherein when an instruction is executed by the processor, the WTRU receives Sending a registration request message to a network node requesting it to register with the network, wherein the registration request message includes 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 a registration acceptance message from the network node, wherein the registration acceptance message includes a notification that the network will support the storage of context information when the WTRU becomes unavailable to the network. Sending a first message to the network indicating a request to save the context information, based on a determination that the WTRU will become unavailable to the network, wherein the first message includes a notification of the period during which the WTRU will be unavailable. After the aforementioned period has ended, a second message is sent to the network indicating that the WTRU is available to the network, A wireless transmitter / receiver unit (WTRU) that performs operations including those mentioned above.

10. When the aforementioned instruction is executed by the processor, Modem reset, Operating system update, Software update, Deregistration requests initiated by the network, Deregistration requests initiated by WTRU, N1 reset request initiated by the network, An N1 reset request initiated by the WTRU, or Change from RM-REGISTERED state to RM-DEREGISTERED state The WTRU according to claim 9, further comprising causing the WTRU to determine that the WTRN becomes unavailable due to any one or more of the above.

11. The WTRU according to claim 9, wherein the context information includes non-access layer (NAS) session management (SM) context information.

12. The aforementioned context information, Protocol Data Unit (PDU) session identifier, Data Network Name (DNN), Single network slice support information (S-NSSAI), or Internet Protocol (IP) address The WTRU according to claim 9, comprising one or more of the following.

13. The first message indicating the request to save the context information is N1 reset request message, or Deregistration request message initiated by WTRU The WTRU according to claim 9, comprising one of the above.

14. The WTRU according to claim 9, wherein the second message indicating that the WTRU is available to the network includes a second registration request message.

15. The WTRU according to claim 9, wherein, when the instruction is executed by the processor, the WTRU further transmits a request to the network for establishing a protocol data unit (PDU) session, the request for establishing the PDU session includes a notification that the request is to preserve the context information associated with the PDU session when the WTRU becomes unavailable.

16. The WTRU according to claim 9, further comprising causing the WTRU to store the context information in the WTRU before the WTRU becomes unavailable when the instruction is executed by the processor.

Images