Retention of session context in communication network

Abstract

The invention relates to reservation of session context in a communication network. A wireless transmit / receive unit (WTRU) may send a registration request message to a network node that requests registration with a network and indicates that the WTRU can retain contextual information associated with communication between the WTRU and the network when the WTRU becomes unavailable to the network. When the WTRU becomes unavailable to the network, the network node may indicate in a registration accept message that the network supports retention of the contextual information. Based on a determination that the WTRU will become unavailable to the network, the WTRU may send a message to the network indicating a request to retain the contextual information. The message may include an indication of a time period during which the WTRU will not be available.

Description

[0001] This application is a divisional application of the invention patent application with the application date of November 3, 2022, application number 202280080897.6, and invention name “Retention of Session Context in a Communication Network”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] 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 contents of which are incorporated herein by reference in their entirety. Background Art

[0004] In a wireless communication system, such as, for example, in a system operating according to the 3rd Generation Partnership Project (3GPP) New Radio (NR) standard, it may occur that a mobility management context in a wireless transmit / receive unit (WTRU), such as a user equipment (UE), needs to be deleted, but the event also results in the deletion of a session management context. For example, when there is an operating system (OS) update, a modem reset, or a network-initiated deregistration request, the mobility management context of the WTRU may be cleared. However, such events may also result in the deletion of the session management context and application layer information of the WTRU. This may result in inefficiencies. Summary of the invention

[0005] Methods, apparatus, and systems for retaining session contexts in a communication network when an event triggers the deletion of such contexts are described herein. A wireless 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 an indication that the WTRU is able to retain context information associated with communications between the WTRU and the network when the WTRU becomes unavailable to the network. When the WTRU becomes unavailable to the network, the WTRU may receive a registration acceptance message from the network node, the registration acceptance message indicating that the network supports the retention of the context information. Based on a determination that the WTRU will become unavailable to the network, the WTRU may send a first message to the network indicating a request to retain the context information. The first message may include an indication of a time period during which the WTRU will be unavailable. After the time period has ended, the WTRU sends a second message to the network indicating that the WTRU is available to the network again.

[0006] The purpose of providing this summary is to introduce selected concepts in a simplified form, which are further described in the following detailed description. This summary is neither intended to identify the key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. In addition, the claimed subject matter is not limited to limitations that address any or all disadvantages noted in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A more detailed understanding may be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which:

[0008] Figure 1 An exemplary communication system is shown;

[0009] Figure 2 An exemplary control plane between network entities is shown;

[0010] Figure 3 An exemplary Registration Management (RM) state model in a UE is shown;

[0011] Figure 4 An exemplary Registration Management (RM) state mode in the AMF is shown;

[0012] Figure 5 shows an exemplary connection management (CM) state transition in a UE;

[0013] Figure 6 shows an exemplary connection management (CM) state transition in AMF;

[0014] Figure 7 An exemplary control plane protocol stack between the UE and the SMF is shown;

[0015] Figure 8 An exemplary UE-initiated deregistration method is shown;

[0016] Fig. 9 An exemplary network initiated logout method is shown;

[0017] Fig.10 An exemplary user plane protocol stack is shown;

[0018] FIG. 11A to FIG. 11D An exemplary UE requested PDU session establishment method for non-roaming and roaming with local breakout is shown;

[0019] Figures 12a to 12c An exemplary UE or network requested PDU session modification (non-roaming and roaming with local breakout) method is shown;

[0020] Fig.13 An exemplary context preservation and restoration method is shown;

[0021] Fig.14 An exemplary enhanced RM state model for UE and AMF is shown;

[0022] Fig.15A Another exemplary communication system is shown.

[0023] FIG. 15B to FIG. 15D An exemplary radio access network (RAN) and core network are shown;

[0024] Fig.15E Another exemplary communication system is shown;

[0025] Fig.15F is a block diagram of an exemplary apparatus or device, such as a wireless transmit / receive unit (WTRU); and

[0026] Figure 15G An exemplary computing system is shown. DETAILED DESCRIPTION

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

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

[0029] There are various scenarios where protocols between the UE and core network functions (excluding the AMF) need to be transferred over the N1 interface via the NAS-MM protocol. Other core network functions with which the UE communicates 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 Examples of these various network functions are shown.

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

[0031] The NAS-MM context is information stored in the UE and AMF required to maintain the N1 connection between the UE and the AMF. The NAS-MM context may include NAS security credentials and a 5G Globally Unique Temporary Identifier (GUTI).

[0032] The UE and AMF respectively maintain the Registration Management (RM) state of the UE. The RM states are RM-DEREGISTERED and RM-REGISTERED. In the RM-DEREGISTERED state: the UE is not registered with the network. The UE context in the AMF does not save the valid location or routing information of the UE, so the UE is unreachable to the AMF. The UE can be considered unavailable. However, some parts of the UE context may still be stored in the UE and AMF, for example, to avoid running the authentication process during each registration process.

[0033] In the RM-DEREGISTERED state, the UE will attempt to register with the network. Once the registration is accepted, the UE will enter 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 updates and send service requests. If the UE performs a deregistration procedure or the registration request is rejected, the UE will enter or remain in the RM-DEREGISTERED state. Figure 3 The RM state in the UE is shown. Figure 4 Shows the RM status in AMF.

[0034] The 5G MM substate of the RM-REGISTERED state may also be referred to as the 5G MM-REGISTERED state. The RM-DEREGISTED state may also be referred to as the 5G MM-DEREGISTERED state. The 5G MM-REGISTERED state and the substates of the 5G MM-DEREGISTERED state are described in 3GPP TS24.501.

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

[0036] A UE in CM-IDLE state does not have a NAS signaling connection established with the AMF via N1. A UE in 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 a NG application protocol (AP) UE association between the access network (AN) and the AMF for 3GPP access. Figure 5 Shows the CM status in the UE. Figure 6 Shows the CM status in AMF.

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

[0038] When the UE establishes a protocol data unit (PDU) session, an SM context is created. During the PDU session establishment process, the AMF calls the SMF's Nsmf_PDUSession_CreateSMContext request service operation to request the SMF to create an SM context for the PDU session requested by the UE. The SMF will send a Nsmf_PDUSession_CreateSMContext response to the AMF. The response includes an SM context identifier (ID) and an N1 message container. The SM context ID identifies the PDU session context stored in the SMF for the UE's PDU session. The N1 message container is a NAS-SM message sent to the UE on top of the NAS-MM message.

[0039] The SM context stored in the SMF is listed in Table 6.1.6.2.39-1 of 3GPP TS29.502 (5G System; Session Management Service; 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 in the SM context is associated with the PDU session.

[0040] The release of a PDU session may be initiated by the UE, AMF, RAN, PCF or SMF. The UE sends a PDU session release request to the SMF via the N1 interface. In the N1 message, the UE will identify the PDU session using the PDU session ID. The AMF will forward the N1 message to the SMF by calling the Nsmf_PDUSession_UpdateSMContext service operation. The SMF will then send a Nsmf_PDUSession_UpdateSMContext response to the AMF. The response will include an N2 SM resource release request and an N1 SM container. The N1 SM container includes a PDU session release command. The N2 SM resource release request is sent by the AMF to the RAN, and the N1 SM container is a NAS-SM message sent by the AMF to the UE via the N1 interface. The Nsmf_PDUSession_UpdateSMContext response includes an N1 SM container (which includes a PDU session release command) and an N2 SM resource release request (which indicates to the AMF, UE and RAN, respectively, that any context associated with the PDU session can be deleted).

[0041] The AMF may call the Nsmf_PDUSession_ReleaseSMContext service operation to request the release of the PDU session and cause the deletion of the SM context in the UE, SMF, RAN, PCF, and AMF. The PCF may initiate the SM Policy Association Termination procedure as defined in clause 4.16.6 of 3GPP TS23.502 (Procedures for 5G System (5GS), Stage 2) to request the release of the PDU session and cause the deletion of the SM context in the UE, SMF, RAN, PCF, and AMF. The RAN may send an N2 message to request the release of the PDU session and cause the deletion of the SM context in the UE, SMF, RAN, PCF, and AMF.

[0042] Figure 8 Figure 1 shows the deregistration process initiated by the UE. Note that when the UE sends a deregistration request to the network, the AMF will call the Nsmf_PDUSession_ReleaseSMContext request service operation of any SMF for which the UE has established a PDU session. This service call will cause the UE's SM context to be deleted in the SMF, User Plane Function (UPF) and Unified Data Management (UDM). This is in Figure 8 As shown in the figure, the AMF sends a Nsmf_PDUSession_ReleaseSMContext request in step 2.

[0043] Fig. 9The network initiated deregistration procedure is shown in Figure 1. During the network initiated deregistration procedure, the AMF will also call the Nsmf_PDUSession_ReleaseSMContext request service operation of any SMF for which the UE has established a PDU session. This service call will cause the UE's SM context to be deleted in the SMF, UPF and UDM. This is shown in Figure 1. Fig. 9 Shown in.

[0044] The 3GPP 5G Core Network Architecture (5GC) supports PDU Connection Service, which is a service that provides PDU exchange between the UE and the data network identified by the DNN. The PDU Connection Service is supported via PDU sessions established based on requests from the UE. PDU sessions are established (based on UE request), modified (based on UE and 5GC requests), and released (based on UE and 5GC requests) using NAS SM signaling exchanged through the N1 interface between the UE and SMF via the AMF. Based on a request from the Application Server (AS), the 5GC is able to trigger a specific application in the UE. When receiving this trigger message, the UE passes it to the application identified in the UE. The application identified in the UE can establish a PDU session to a specific DNN.

[0045] A PDU Session is associated to the S-NSSAI and the DNN. In the PDU Session Establishment Request sent to the network, the UE shall provide a PDU Session Identifier. The PDU Session ID is unique per UE and is an identifier used to uniquely identify one of the UE's PDU Sessions. When different Public Land Mobile Networks (PLMNs) are used for 3GPP access and non-3GPP access, the PDU Session ID is stored in the UDM to support switching between the two accesses.

[0046] Each PDU Session supports a single PDU Session Type, ie supports the exchange of a single type of PDUs requested by the UE at the establishment of the PDU Session. The following PDU Session Types are defined: IPv4, IPv6, IPv4v6, Ethernet and Unstructured.

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

[0048] 3GPP 5G networks may support several Session and Service Continuity (SSC) modes - SSC Mode 1, SSC Mode 2, and SSC Mode 3. With SSC Mode 1, the network retains the connection services provided to the UE. For the case of PDU sessions of type IPv4 or IPv6 or IPv4v6, the IP address is retained. The UPF, which acts as the PDU session anchor when the PDU session is established, is maintained regardless of the access technology (e.g., access type and cell) that the UE continuously uses to access the network. In the case of PDU sessions of type IPv4 or IPv6 or IPv4v6, IP continuity is supported regardless of the UE mobility event. SSC Mode 1 is applicable to any PDU session type and any access type.

[0049] In SSC mode 2, the network may release the connection service delivered to the UE and release the corresponding PDU session. For IPv4 or IPv6 or IPv4v6 type cases, the release of the PDU session causes the release of the IP address already allocated to the UE. If the PDU session of SSC mode 2 has a single PDU session anchor, the network may trigger the release of the PDU session and command the UE to immediately establish a new PDU session to the same data network.

[0050] The triggering condition depends on the operator policy, for example, a request from an application function (AF), based on load status, etc. When a new PDU session is established, a new UPF that acts as a PDU session anchor may be selected. Otherwise, if a PDU session of SSC Mode 2 has multiple PDU session anchors (for example, in the case of a multi-homed PDU session or in the case where UL CL is applied to a PDU session of SSC Mode 2), an additional PDU session anchor may be released or allocated. SSC Mode 2 is applicable to any PDU session type and any access type.

[0051] For SSC Mode 3, the connection through the new PDU Session Anchor is established before the previous connection is terminated to allow better service continuity. For the case of IPv4 or IPv6 or IPv4v6 type, the IP address is not retained in this mode when the PDU Session Anchor changes.

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

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

[0054] 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 hosting the network application that communicates with the UE application.

[0055] The UE application context includes the IP address, port number, security credentials, user identity and application identifier.

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

[0057] For example, DNNs can be used to:

[0058] ●First, select SMF and UPF for the PDU session.

[0059] ●Second, select the N6 interface for the PDU session.

[0060] ●Third, determine the policy to be applied to the PDU session.

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

[0062] 5GC supports PDU connection service. PDU connection service is supported via PDU sessions established based on requests from UE. The subscription information of each S-NSSAI may contain a list of subscribed DNNs and a default DNN. When the UE does not provide a DNN in the NAS message containing a PDU session establishment request for a given S-NSSAI, if the default DNN exists in the UE's subscription information, the serving AMF determines the DNN for the requested PDU session by selecting the default DNN for the S-NSSAI; otherwise, the serving AMF selects a locally configured DNN for the S-NSSAI.

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

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

[0065] If the DNN offered 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 containing the PDU Session Establishment Request from the UE with a cause indicating that the DNN is not supported, unless the PCF provides a strategy to perform DNN replacement for the unsupported DNN.

[0066] If the DNN requested by the UE is indicated for replacement, or the DNN provided by the UE is not supported by the network, and the PCF provides a policy for performing DNN replacement on the DNN requested by the UE that is not supported by the network, the AMF will interact with the PCF to perform DNN replacement. During the PDU session establishment process and as a result of DNN replacement, the PCF provides a list of selected DNNs for replacement, which is applicable to the S-NSSAI requested by the UE when the PDU session is established. The AMF uses the selected DNN in the query for the NRF selected by the SMF, and provides the requested and selected DNN to the selected SMF. It should be noted that when DNN replacement is performed in the network, interaction between the AMF and the PCF is required.

[0067] AMF selection is a process performed by the 5G-AN (e.g., base station). The process is used to select an AMF instance to serve the UE. AMF selection is also a process that can be performed by the AMF. When the AMF determines that it is not the appropriate AMF to serve the UE, the AMF may perform a process to select another AMF to serve the UE. For example, this may occur if the UE attempts to register to a different network slice.

[0068] When the 5G-AN performs AMF selection, the 5G-AN considers what slice the UE has requested and other information such as local operator policies, attributes of the UE (e.g., RAT type), etc.

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

[0070] 5G-GUTI is structured as:

[0071] <5G-GUTI>:= <guami><5G-TMSI>

[0072] The GUAMI identifies one or more AMFs.

[0073] The Globally Unique AMF ID (GUAMI) is constructed as:

[0074] <guami> :＝ <mcc> <mnc><AMF Region ID><AMF Set ID><AMF Pointer>

[0075] 5G-S-TMSI is a shortened form of GUTI to enable more efficient radio signaling procedures (e.g., during paging and service requests) and is defined as:

[0076] <5G-S-TMSI>:=<AMF Set ID><AMF Pointer> <5G-TMSI>

[0077] The UE Routing Policy (URSP) includes a prioritized list of URSP rules. See 3GPP TS 23.503 (Policy and Charging Control Framework for 5G System (5GS); Stage 2) and Table 2 below. The structure of the URSP rules is described in Tables 3 and 4 below.

[0078] A routing descriptor (RSD) contains one or more of the following components:

[0079] - Session and Service Continuity (SSC) Mode: Indicates that traffic for matching applications will be routed via PDU sessions that support the included SSC mode.

[0080] -Network Slice Selection: Indicates that traffic for matching applications will be routed via the supported S-

[0081] The PDU session is routed for any of the NSSAIs.

[0082] - DNN Selection: Indicates that traffic for the matching application will be routed via a PDU session supporting any of the included DNNs. When DNNs are used in a traffic descriptor, the corresponding RSD of the rule will not include a DNN selection component.

[0083] - PDU Session Type Selection: Indicates that traffic for matching applications will be routed via PDU sessions that support the included PDU Session Type.

[0084] -Non-seamless offload indication: indicates that when this rule is applied, the traffic of the matching application will be offloaded to a non-3GPP access outside the PDU session. If this component is present in the RSD,

[0085] Then no other components will be included in the RSD.

[0086] - Access type preference: If the UE needs to establish a PDU session when this rule is applied, this indicates the access type (3GPP or non-3GPP).

[0087] One URSP rule with a "match all" traffic descriptor is used to route traffic for applications that do not match any other URSP rule and shall be evaluated with the lowest priority in the rule priorities. The RSD in this URSP rule shall contain at most one value for each routing component. However, it is to be noted that TS23.503 states that "If the UE fails to establish a PDU Session with any routing descriptor, it tries other URSP rules in the order of rule priority with matching traffic descriptors, except the URSP rule with a "match all" traffic descriptor (if any). In this case, the UE shall not use the UE local configuration.".

[0088] The routing validation criteria or simply validation criteria are defined in TS23.503. The routing validation criteria include a list of attributes whose configuration values ​​must be satisfied in order for the RSD in the URSP to be valid. Table 4 shows a list of routing validation criteria including time window and location criteria.

[0089] With respect to the time window, the routing descriptor is not considered valid unless the UE is within the time window. With the location criterion, the routing descriptor is not considered valid unless the location of the UE matches the location criterion.

[0090] Furthermore, when the routing descriptor includes a time window or location criteria, a PDU session is considered matched only if it is associated with the same time window or location criteria validity condition. However, UE support for the validation criteria in the URSP rules is optional. If a non-supporting UE receives the validation criteria, it ignores the validation criteria part of the RSD and uses the remainder of the RSD.

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

[0092] 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 URSP rule. When a URSP rule is determined to be applicable for a given application, the UE shall select an RSD within that URSP rule in the order of the routing descriptor priority information name.

[0093] When a valid RSD is found, the UE determines whether there is an existing PDU session that matches all the components in the selected RSD. When a matching PDU session exists, the UE associates the application to the existing PDU session, for example, routing the traffic of the detected application on the PDU session. If none of the existing PDU sessions matches, 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 the new PDU session.

[0094] The RSD of the URSP rules is considered valid if the following conditions are met:

[0095] - if any S-NSSAI is present, the S-NSSAI is among the allowed NSSAIs; and

[0096] - If there is any DNN and that DNN is a LADN DNN, then the UE is in the available area of ​​that LADN.

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

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

[0099] 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 triggers PDU session establishment or uses an existing PDU session for that flow. The location attribute is a URSP rule constraint that needs to be valid for the URSP rule to be applicable. That is, when the routing descriptor includes a time window or location criteria, the traffic is considered matched only when the UE's location matches the location criteria validity condition. In addition, TS23.503 describes that the UE (re)evaluates the validity of the URSP rules in a timely manner when certain conditions are met, for example, when the URSP is updated by the PCF in the following cases:

[0100] UE moves from EPC to 5GC;

[0101] ● Changes to allowed NSSAI or configured NSSAI;

[0102] Changes in LADN DNN availability;

[0103] ●UE registers via 3GPP access or non-3GPP access;

[0104] ●UE establishes a connection to the WLAN access.

[0105] According to 3GPP TS 24.526 (User Equipment (UE) Policies for 5G System (5GS); Stage 3), the UE may re-evaluate the URSP rules to check whether an associated change needs to be applied to the PDU session when:

[0106] ●UE performs periodic URSP rule re-evaluation based on UE specific implementation;

[0107] The UE NAS layer indicates that the existing PDU session used for traffic of the application routed based on the URSP rules is released;

[0108] URSP is updated by PCF;

[0109] ● The UE NAS layer instructs the UE to perform an inter-system change from S1 mode to N1 mode;

[0110] ●UE NAS layer indicates that the UE is successfully registered in N1 mode via 3GPP access or non-3GPP access;

[0111] The UE establishes or releases a connection to the WLAN access and the transmission of PDUs for applications via non-3GPP access outside of a PDU session becomes available / unavailable;

[0112] ● the permitted NSSAI is changed; or

[0113] ●LADN information is changed.

[0114] If the re-evaluation results in a change in the association of an application with a PDU Session, the UE may implement such a change immediately or when the UE returns to 5G MM-IDLE mode. After the re-evaluation, the URSP processing layer may request the UE NAS layer to release the existing PDU Session.

[0115] FIG. 11A to FIG. 11D It is copied from 3GPP TS 23.502, which shows the PDU Session Establishment procedure in non-roaming and roaming with local breakout. The UE uses this procedure to establish a new PDU Session.

[0116] Figures 12a to 12c The PDU session modification procedure requested by the UE or the network (non-roaming and roaming with local breakout scenarios) is described in FIG. Figures 12a to 12c Copied from 3GPP TS23.502. This procedure is used by the UE or the network to modify a PDU session.

[0117] The term UE may refer to a mobile phone, a mobile computer, a mobile broadband adapter, a connected vehicle, a connected device, etc. that can be connected to a cellular network. A UE may have an MT (mobile terminal) portion that provides a cellular radio interface and a TE (terminal equipment) portion that provides services to the user and generally does not provide features specific to the cellular radio interface portion. For example, the TE may provide a control GUI. The TE and MT portions of the UE may communicate via AT commands. Some examples of AT commands are defined in 3GPP TS27.007.

[0118] The UE may also have a SIM that stores user credentials and network identities. It should be understood that the concepts in this document are equally applicable to devices that do not have a SIM to store user credentials and network identities. The device may alternatively store user credentials and network identities in other forms of non-volatile memory. Therefore, all concepts described in this document as applicable to a UE are equally applicable to any device.

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

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

[0121] In a second example, the network (e.g., AMF) may send a deregistration request with a notification that reregistration is required to the UE. The AMF may be triggered by the O&M system to send this message. Although the purpose of the O&M request may be only to force the UE to register with a new AMF or reset the UE's MM context, the current 5G system design requires that both the MM and SM contexts are deleted when the deregistration procedure is performed. The network-initiated deregistration procedure is described in clause 4.2.2.3.3 of TS 23.502.

[0122] In a third example, if the network (e.g., AMF) detects that the UE's registered PLMN is not allowed to operate in the current UE location, the network (e.g., AMF) may initiate a network-initiated deregistration. In this case, the AMF will include the country where the UE is located in the deregistration request. Note that this deregistration process will result in the UE's SM context being deleted. However, the SM context may be anchored to an H-SMF instance that is allowed to operate in the UE's current location. The network-initiated deregistration process is described in clause 4.2.2.3.3 of TS23.502.

[0123] In the three examples listed above, although the deletion and re-creation of the NAS-MM context may be sufficient, the NAS-SM context will also be deleted. The deletion of the NAS-SM context including the UE's IP address will generally result in the deletion of at least some application layer contexts. For example, in the three examples listed above, the change of the IP address will generally result in the application hosted by the UE re-establishing the application layer connection and re-creating or updating the application layer context. Of course, the re-establishment or re-creation of the application layer context will only occur after the UE re-establishes the PDU session and a new NAS-SM context is created.

[0124] The 5G system enhancements described herein may allow the UE and the 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 retain the NAS-SM context during the NAS-MM reset; the network and the UE may be able to identify which NAS-SM contexts need to be retained during the NAS-MM reset; the network and the UE may be able to initiate a NAS-MM reset process so that the identified NAS-SM context is retained during the NAS-MM reset; the network and the UE may be able to store the NAS-SM context during the NAS-MM reset; the network and the UE may be able to initiate NAS-SM context recovery and NAS-MM context creation; and the UE may be able to notify the UE-hosted application that the NAS-SM context and connection have been restored, so that the UE-hosted application can notify the network application server that the connection has been restored.

[0125] Described herein are methods, apparatus, and systems for retaining and re-establishing or restoring 5G SM context and, thereby, retaining and re-establishing or restoring application layer context when an event triggers deletion and re-establishment of a 5G MM context. Fig.13 An exemplary method for retaining and re-establishing or recovering a 5G SM context is shown. Fig.13 The method may enable a WTRU (such as a UE) and a network to perform a NAS-MM reset without performing a NAS-SM reset.

[0126] In step 1, a WTRU (such as a UE) may perform an initial registration with a network. For example, the WTRU may send a registration request message to a network node requesting registration with the network. The registration request message may include an indication that the WTRU is able to retain context information associated with communications between the WTRU and the network when the WTRU becomes unavailable to the network. For example, the WTRU (e.g., UE) may indicate to the network that it is able to retain the NAS-SM context while performing a NAS-MM reset. As further described below, the WTRU may send this information to the network so that the network knows that the network may initiate a NAS-MM reset procedure so that the NAS-SM context is retained in the WTRU and the network. The WTRU may also send this information to the network so that the network knows that it is advantageous to select an SMF to serve the WTRU that is able to retain the NAS-SM context of the WTRU in the presence of a NAS-MM reset.

[0127] The WTRU may receive a Registration Accept message from a network node. The Registration Accept message may include an indication that the network supports retention of context information when the WTRU becomes unavailable to the network.

[0128] In step 2, the WTRU hosted application may start. As described below, when the WTRU connection is about to be disconnected, the WTRU hosted application may indicate to the network that it wants to receive notifications or alerts. Note that when there is a NAS-MM reset, the WTRU connection will be disconnected.

[0129] In step 3, the WTRU may determine to establish a PDU session for application traffic. The WTRU may use FIG. 11A to FIG. 11D During the PDU session establishment procedure, the WTRU may indicate to the network that the NAS-SM context for the PDU session should be retained when there is a NAS-SM context reset. For example, the WTRU may send to the network (e.g., Fig.11A The request to establish a PDU session includes an indication of requesting to retain context information of the PDU session when the WTRU becomes unavailable.

[0130] In step 4, as described more fully below, the WTRU may send a message to the network indicating a request to retain context information based on a determination that the WTRU will become unavailable to the network. The message may include an indication of the time period for which the WTRU will be unavailable. For example, the WTRU may notify the AMF of an expected NAS-MM context reset, or the AMF may notify the WTRU of an expected NAS-MM context reset. As described more fully below, such notification or indication may be made as part of an N1 Reset Request message or a UE-initiated Deregistration Request message. The WTRU may prepare for a NAS-MM context reset by notifying an application hosted by the WTRU 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 further described below.

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

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

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

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

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

[0136] When a WTRU (e.g., UE) sends a NAS-MM Registration message to the network, the message is carried in an RRC message to the NG-RAN node. The NG-RAN node will select an AMF and send a NAS-MM Registration message to the AMF. The UE may include an indication in the RRC part of the message to indicate to the NG-RAN node that the UE supports and can use a feature that allows the UE's NAS-MM context to be reset / deleted in the UE and the network while maintaining the UE's NAS-SM context in the UE and the network. This feature may be referred to herein as the "persistent NAS-SM context" feature, and the indication may be referred to herein as the "indication of support for persistent NAS-SM context". The NG-RAN node may use the indication of support for persistent NAS-SM context to determine that the NG-RAN should select an AMF that supports the persistent NAS-SM context feature.

[0137] The UE may also include an indication of support for persistent NAS-SM context in the NAS-MM Registration message. The indication of support for persistent NAS-SM context in the NAS-MM Registration message may indicate to the AMF that the UE supports the persistent NAS-SM context feature and that the UE may desire to use this feature. The AMF may use this information when performing SMF selection to ensure that the AMF selects an SMF that supports this feature. The AMF may send a Registration Accept message to the UE. The Registration Accept message may include an indication that the AMF supports the persistent NAS-SM context feature and that the UE may attempt to use this feature.

[0138] The AMF sends a Registration Accept message to the NG-RAN node, and the NG-RAN node forwards the message to the UE in an RRC message. The NG-RAN may include in the RRC part of the message an indication of whether the NG-RAN node has selected an AMF that supports the persistent NAS-SM context feature.

[0139] The UE may host critical applications whose functionality and / or reliability depends on the UE's SM context being preserved during a NAS-MM reset. Therefore, the UE may only desire to connect to a network that supports the NAS-SM context preservation feature. The NG-RAN may broadcast an indication in system information that indicates to the UE that the NG-RAN node is able to select an AMF that supports the NAS-SM context feature.

[0140] In a scenario where the UE registers to the network via non-3GPP access, the UE may send an indication to the TWAP, TNGF or N3IWF that it supports persistent NAS-SM context so that the TWAP, TNGF or N3IWF may consider the indication during AMF selection.

[0141] As discussed above, an indication of support for persistent NAS-SM context may be sent to the AMF in the NAS-MM Registration Request message. If the AMF determines that it cannot support this feature, but a different AMF can support this feature, the AMF may perform an AMF selection procedure on the NRF, provide an indication to the NRF, and determine a new AMF to serve the UE.

[0142] The UE may provide a separate indication to the AMF of support for persistent NAS-SM context for each of the requested S-NSSAIs. In other words, the UE may indicate whether it desires to use this feature for each slice it requests on a per-slice basis.

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

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

[0145] When the MM context of the UE is reset, the application on the UE may require or prefer to retain its SM context. For example, when the MM context of the UE is reset, the application may require or prefer to retain its IP address.

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

[0147] Alternatively, the application may provide the UE's ME part with an activated NAS-SM context retention indication as part of the traffic descriptor. When the activated NAS-SM context retention indication is part of the traffic descriptor, the UE may only select an existing PDU Session for the traffic if the feature is enabled for that PDU Session, otherwise the UE will attempt to establish a new PDU Session for the traffic and will attempt to enable the feature for the new PDU Session.

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

[0149] The UE may determine that no existing PDU Session supports the requirements of the application traffic. The UE will then send a PDU Session Establishment Request to the AMF. The PDU Session Establishment Request will include an activated NAS-SM context retention indication. The activated NAS-SM context retention indication may be included in the NAS-MM part of the message so that the AMF can use the activated NAS-SM context retention indication during SMF selection, thereby ensuring that the AMF will select an SMF that supports this feature. The activated NAS-SM context retention indication may also be part of the N1 SM container (e.g., the NAS-SM part of the message) so that the SMF knows that this feature should be enabled for the PDU Session.

[0150] Alternatively, the system may be designed so that certain SMFs only serve PDU sessions whose contexts need to be retained during a NAS-MM reset. In this scenario, an activated NAS-SM context retention indication will not need to be included in the NAS-SM part of the PDU session establishment request message.

[0151] Alternatively, as described above, the UE may have been configured with an indication of support for persistent NAS-SM contexts for the S-NSSAI associated with the PDU establishment request. The UE may interpret the indication of support for persistent NAS-SM contexts as an indication that the feature may be enabled for the PDU sessions of the slice, or the UE may interpret the indication as an indication that the feature is associated with all PDU sessions of the slice. If the indication is interpreted by the UE as an indication that the feature is associated with all PDU sessions of the slice, the UE does not need to provide the indication during PDU session establishment; the UE and the network function will understand that the feature is enabled for the PDU session because the indication is included in the configuration information associated with the slice.

[0152] The PDU SESSION SETUP ACCEPT message may indicate to the UE whether the feature is enabled for the PDU session. For example, the SMF may include a NAS-SM context retention enable indication in the PDU SESSION SETUP ACCEPT message sent to the UE, and the UE may maintain a list of PDU sessions in which the NAS-SM context is configured to be retained during a NAS-MM reset event. The SMF may also include a NAS-SM context retention timer to indicate to the UE how long the NAS-SM context will be retained after a NAS-MM reset event.

[0153] When the SMF calls the Namf_Communication_N1N2MessageTransfer service operation, the SMF may also send a NAS-SM context retention enable indication to the AMF. The reason for sending the NAS-SM context retention enable indication to the AMF is that it will serve as a notification to the AMF that the UE has a PDU session whose NAS-SM context needs to be maintained during the NAS-MM reset, and 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, when a NAS-MM reset event occurs, the AMF may save in the UE context which PDU sessions maintained by the AMF for the UE are configured for NAS-SM context retention. Furthermore, the UE will not need to specify the PDU sessions whose NAS-SM context should be retained during deregistration. In addition to the NAS-SM context retention enable indicator, the SMF may also provide a timer value for how long the NAS-SM context should be retained. The timer value can be sent to both the AMF and the UE.

[0154] The NAS-SM context retention enable indication may be sent by the TE to the ME via an AT command. For example, this indication may be provided when the +CGDCONT=? AT command is used. The +CGDCONT=? AT command defined in TS27.007 is used to check or read PDU session parameters.

[0155] The persistent NAS-SM context feature may be considered an extension or improvement of SSC Mode 1. When SSC Mode 1 is used, the UE's IP address is retained 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 retained even when there is a NAS-MM reset.

[0156] A fourth SSC mode may be considered. SSC mode 4 may also be characterized by the fact that the IP address of the UE is retained 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 retained during a NAS-MM reset, whereas the SM context associated with the PDU session of SSC mode 1 is not retained during a NAS-MM reset.

[0157] When the persistent NAS-SM context feature is associated with SSC mode 4, the UE may send an activated NAS-SM context retention indication to the network by setting the requested SSC mode in the PDU session establishment request to 4, and the network may send a NAS-SM context retention enable indication to the UE by setting the allowed SSC modes in the PDU session establishment accept message to 4. Table 5 below shows an example of how SSC mode 4 may be encoded and thus indicate to the network that the activated NAS-SM context retention indication should be enabled.

[0158] It may also be desirable to use the persistent NAS-SM context feature with SSC modes 1 and 2. Although the use of SSC modes 2 and 3 means that UE applications using PDU sessions do not need to retain IP addresses, it may still be advantageous to enable the persistent NAS-SM context feature. Using the persistent NAS-SM context feature with any SSC mode may still be advantageous because using this feature allows the UE and the network to reduce the amount of interaction required between the UE and the network to re-establish a PDU session. Table 6 below shows an example of how the SSC mode coding may be enhanced to additionally indicate whether the UE has requested that the feature be enabled and whether the network has enabled the feature.

[0159] The UE may have established a PDU Session with the persistent NAS-SM context feature enabled. An event may occur at the UE and the UE may determine that the event requires the UE to reset its NAS-MM context. Resetting the NAS-MM context may be initiated by sending a Deregistration Request to the network. However, when the UE is in the RM-DEREGISTERED state, the UE may determine that the NAS-SM context may be retained. When the UE is in the RM-DEREGISTERED state, the UE may indicate to the network in the Deregistration Request that the NAS-SM context should be retained. The AMF may then notify the SMF associated with the PDU Session for which the context needs to be retained and assist the SMF in coordinating the retention timers between the UE and the SMF. The UE initiated Deregistration procedure in Figure 8 and can be enhanced as follows.

[0160] The deregistration request of step 1 may be enhanced so that the UE may indicate to the AMF that the NAS-SM context of the UE should be retained when the UE is in the RM-DEREGISTERED state. The request may identify which PDU sessions' NAS-SM contexts need to be retained by including the PDU session ID of each PDU session whose NAS-SM context needs to be retained. For each PDU session whose context needs to be retained, the UE may include an N1 SM container. The N1 SM container may include an indication that the UE expects to maintain the NAS-SM context and a time value indicating how long the UE requests the SMF to retain the NAS-SM context of the UE. The current 5G system design does not allow the UE to indicate to the network that the deregistration type is "re-registration required". The deregistration request of step 1 may be further enhanced 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 required is that it will allow the UE to indicate to the network that the UE plans to re-register, for example, where the UE only needs to perform a NAS-MM reset.

[0161] Alternatively or in lieu thereof, the UE deregistration request of step 1 may be enhanced such that the UE may indicate the mobility state, the expected re-registration parameters (e.g., immediate vs. timed vs. event-based), the expected re-registration reason (e.g., emergency service release, O&M request). The mobility state may be used by the network to determine whether the same UPF may serve the UE after re-registration. Similarly, other predictive information may be included in the deregistration request that may be used by the network to determine how to configure context storage and re-establishment parameters, buffering at the UPF, etc.

[0162] Alternatively or in lieu thereof, it may not be necessary to explicitly indicate to the AMF that the UE's NAS-SM context should be retained when the UE is in RM-DEREGISTERED. Instead, whenever the UE sets the Deregistration Type IE in the Deregistration Request to "Re-registration Required", the AMF may assume that the UE's NAS-SM context should be retained when the UE is in RM-DEREGISTERED state. The disadvantage of this alternative is that the NAS-SM context may end up being retained in the network even when the UE expects the NAS-SM context to be unretained.

[0163] It was previously described that the AMF may update the UE context it maintains as long as the NAS-SM context retention enable indicator is provided by the SMF to the AMF in the Namf_Communication_N1N2MessageTransfer service operation of the PDU session establishment procedure. If the AMF maintains a list of PDU sessions in which the NAS-SM context is to be retained, the UE may only need to perform a deregistration request to the AMF. In addition, the AMF may also be provided with a timer value for how long the NAS-SM context of the UE is retained, and upon receiving the deregistration request from the UE, the AMF starts the timer. If the UE does not re-register before the timer expires, the AMF deletes the remaining NAS-SM context that has been reserved for the UE.

[0164] The call to Nsmf_PDUSession_ReleaseSMContext request in step 2 may be enhanced 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 may use the contents of the N1 SM container to identify that the UE will enter the RM-DEREGISTED state and that the NAS-SM context should be retained. The N1 SM container may include a retention expiration timer. Alternatively, step 2 may call Nsmf_PDUSession_UpdateSMContext, which may allow forwarding tunnels to be established between UPFs controlled by different SMFs. Figure 8 The process may be enhanced so that step 3 is skipped, or step 3 may be enhanced so that the SMF informs the UPF that the UE will enter the RM-DEREGISTED state and the NAS-SM context should be retained. The advantage of notifying the UPF that the UE will enter the RM-DEREGISTED state and the NAS-SM context should be retained is that the UPF will know to buffer or discard any DL packets received for the PDU session. The SMF may indicate to the UPF whether packets should be buffered or discarded.

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

[0166] Figure 8 The process may be enhanced so that step 5a is skipped, or step 5a may be enhanced so that the SMF notifies the PCF that the UE will enter the RM-DEREGISTED state and the NAS-SM context should be retained.

[0167] Figure 8 The process may be enhanced so that steps 5b to 5c are skipped, or steps 5b to 5c may be enhanced so that instead of unsubscribing from the UDM or indicating to the UDM that the UDM should remove the association it has stored between the SMF identity and the associated DNN and PDU Session Id, the SMF will send the SM context to the UDM and request the UDM to store the SM context.

[0168] Figure 8 The process may be enhanced such that step 7 is enhanced such 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 will be retained (e.g., whether the UE's IP address will be retained during the NAS-MM reset, whether QoS rules for certain flows will be 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 the N1 SM container may be sent by the SMF hosting the PDU session).

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

[0170] An event may occur at the network, and the network may determine that the event requires the UE to reset its NAS-MM context by sending a Deregistration Request to the UE, but the NAS-SM context may be retained 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 retained while the UE is in the RM-DEREGISTERED state, and may further indicate how long the NAS-SM context will be retained before the PDU session is re-established (e.g., registration and re-establishment timers). The AMF may then notify the SMF associated with the PDU session for which the context needs to be retained, and help coordinate the retention timers between the UE and the SMF. The notification from the AMF may also indicate how long the NAS-SM context will be retained before the PDU session is re-established (e.g., registration and re-establishment timers). The network initiated Deregistration procedure is Fig. 9 and can be enhanced as follows.

[0171] In step 2, the event may trigger the AMF to send a deregistration request to the UE. The deregistration request may be enhanced so that the AMF may indicate to the UE that the NAS-SM context of the UE should be retained when the UE is in RM-DEREGISTERED. The request may identify which PDU session's NAS-SM context needs to be retained by including the PDU session ID of each PDU session whose NAS-SM context needs to be retained. For each PDU session whose context needs to be retained, the AMF may include an N1 SM container. The N1 SM container may include an indication that the network expects to maintain the NAS-SM context and a time value indicating how long the UE should retain the NAS-SM context of the UE.

[0172] The deregistration request may also include a deregistration timer. The deregistration timer may indicate to the UE that the UE should deregister before the timer expires. The advantage of providing such a timer is that, compared to requesting the UE to deregister immediately, the ME part of the UE will be able to send a deregistration warning notification to the application hosted by the TE part of the ME. The applications that receive the warning will then be able to save their associated application layer contexts and send warnings to any application servers with which they communicate. Warnings to application servers may be sent over the user plane and may indicate a time window when the UE application is unavailable. AT commands may be used to send warning notifications from the ME part of the UE to applications hosted on the TE part of the UE.

[0173] Alternatively, it may not be necessary to explicitly indicate to the UE that the NAS-SM context of the UE should be retained when the UE is in RM-DEREGISTERED. Instead, whenever the AMF sets the Deregistration Type IE in the Deregistration Request to "Re-registration Required", the UE may assume that the NAS-SM context of the UE should be retained when the UE is in RM-DEREGISTERED state. The disadvantage of this alternative is that the NAS-SM context may end up being retained in the network even when the AMF expects that the NAS-SM context should not be retained.

[0174] Fig. 9 The process may be enhanced so that steps 3 and 3a are skipped, or steps 3 and 3a may be enhanced so that instead of unsubscribing from the UDM or indicating to the UDM that the UDM should remove the association it has stored between the SMF identity and the associated DNN and PDU Session Id, the SMF will send the SM context to the UDM and request the UDM to store the SM context.

[0175] Fig. 9 Step 4 of the procedure may be enhanced in the same manner as steps 2 to 5 of the UE initiated deregistration procedure described above.

[0176] Fig. 9 Steps 5 and 5a of the procedure may be enhanced in the same manner as steps 6 and 6a of the UE initiated deregistration procedure described above.

[0177] Fig. 9 Step 6 of the procedure may be enhanced so that when the UE sends the deregistration accept message, the UE indicates to the network whether it will retain the SM context for each PDU session. For example, the deregistration accept message may include an indication for each PDU session that the UE will save the SM context for that PDU session when the UE is in the RM-DEREGISTERED state. The message may also indicate to the AMF how long the UE plans to save the SM context.

[0178] Alternatively, Fig. 9 The process may be enhanced so that the AMF does not request the SMF, UDM and PCF to retain the SM context until after the AMF receives the deregistration accept message. The advantage of this method 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 operations required to request the UDM, PCF and SMF to save the SM context.

[0179] The UE may display a graphical user interface (GUI) that allows the user to be notified when the network requests a network-initiated registration. The GUI may also allow the user to select which UE applications need to retain their context during the NAS-MM reset. The UE may then determine that any PDU sessions associated with the selected UE applications need to retain their SM context during the NAS-MM reset, and the UE may then include the PDU session IDs of the PDU sessions associated with the selected UE applications in the deregistration accept message.

[0180] In a different example, the user may have used the GUI to configure which applications require or prefer to retain their NAS-SM contexts during a NAS-MM reset. The UE may then use this information to determine whether to indicate to the network in a PDU Session Establishment Request that the associated PDU Sessions require their NAS-SM contexts to be retained during a NAS-MM reset.

[0181] like Figure 3 and Figure 4 As shown in FIG. 1 , when the UE enters the RM-DEREGISTERED state, the NAS-MM context of the UE is reset in the UE and the AMF. Therefore, even when the UE is in the RM-DEREGISTERED state, the method described herein can also be applied to how to retain the NAS-SM state of the UE.

[0182] An alternative approach is to not change the handling of the UE NAS-MM and NAS-SM contexts by the UE and AMF when the UE is in the RM-DEREGISTERED state, but to create a new sub-state or operating mode within the RM-REGISTERED state. This new state or operating mode may be called RM-REGISTERED-PAUSE and may be entered upon a NAS request from the network to the UE or upon a NAS request from the AMF to the UE. This request may be called an N1 reset request, which may be sent by the AMF to the UE or by the UE to the AMF, and which may cause the UE to reset its NAS-MM context. Fig.14 It is shown how the RM state model of AMF and UE is enhanced to support the RM-REGISTERED-PAUSE state.

[0183] like Fig.14 As shown, the UE and AMF may enter the RM-REGISTERED-PAUSE state from the RM-REGISTERED state when the N1 reset procedure is completed. The UE and AMF may enter the RM-REGISTERED state from the RM-REGISTERED-PAUSED when the registration procedure is completed. When the SM context storage expiration timer expires, the UE and AMF may enter the RM-DEREGISTERED state from the RM-REGISTERED-PAUSED.

[0184] In the RM-REGISTERED-PAUSED state, the NAS-MM context of the UE may be reset and the NAS-SM context of the UE may be retained. The AMF may consider the UE to be unreachable in the RM-REGISTERED-PAUSED state.

[0185] To return to the RM-REGISTERED state (e.g., to send and receive data), the UE may initiate a registration procedure while in the RM-REGISTERED-PAUSE state. When the accepted registration procedure is completed, the UE may return to the RM-REGISTERED state. The UE may enter the RM-DEREGISTERED state when the SM context storage expiration timer expires.

[0186] When the UE enters the RM-REGSITERED-PAUSE state, the SM context storage expiration timer may be started. If the timer expires, the UE may enter the RM-DEREGISTERD state unless there is an ongoing registration procedure. Once the registration procedure is started (e.g., when the UE is in the 5GMM-REGISTERED.ATTEMPTING-REGISTRTION-UPDATE state), the UE may stop the timer. Time expiration may mean that the timer reaches the value 0 or the SM context storage expiration timer value received from the network.

[0187] The RM-REGISTERED-PAUSE state may be considered a sub-state of the 5GMM-REGISTEED state. An alternative name for the RM-REGISTERED-PAUSE state may be 5GMM-REGISTERED-PAUSE or 5GMM-REGISTERED-RESETING-MM-CONTEXT.

[0188] When the UE is in RM-REGISTERED-PAUSE state, the AMF and the UE shall consider the UE to be in CM-IDLE state because the UE's N1 connection will be inactive.

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

[0190] The UE may have established a PDU Session with the persistent NAS-SM context feature enabled. An event may occur at the UE, and the UE may determine that the event requires the UE to reset its NAS-MM context by sending an N1 reset request to the network. The request may indicate that the UE will enter 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 retained while the UE is in the RM-REGISTERED-PAUSED state. The AMF may then notify the SMF associated with the PDU Session whose context needs to be retained, and help coordinate the retention timer between the UE and the SMF.

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

[0192] The receipt of the N1 reset request may cause the AMF to invoke the Nsmf_PDUSession_ReleaseSMContext request. As described above, the Nsmf_PDUSession_ReleaseSMContext request may be enhanced so that the AMF sends both the SM context ID and the N1 SM container sent by the UE to the SMF. The SMF may use the contents of the N1 SM container to identify that the UE will enter the RM-REGISTERED-PAUSED state and that the NAS-SM context should be retained.

[0193] The SMF's call to the Nsmf_PDUSession_ReleaseSMContext response may be enhanced so that the SMF may provide the AMF and the 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 of the SM context. The SM context storage ID may identify the storage location where the SM context is stored. For example, the storage location may be associated with an SMF, an UDSF, or an UDM / UDR. The SM context storage expiration time may be stored together with the SM context. The SMF may use the time value included by the UE in the N1 SM container to derive the SM context storage expiration time that will be sent to the UE in the N1 SM container.

[0194] The AMF may send an N1 Reset Accept message to the UE, which includes the N1 SM container sent by the SMF to the AMF.

[0195] An event may occur at the network, and the network may determine that the event requires the UE to reset its NAS-MM context by sending an N1 reset request to the UE, but the NAS-SM context may be retained when the UE's NAS-MM context is reset. The network may indicate to the UE in the N1 reset request that the NAS-SM context should be retained when the UE is in the RM-REGISTERED-PAUSE state. The AMF may then notify the SMF associated with the PDU Session whose context needs to be retained, and help coordinate the retention timer between the UE and the SMF.

[0196] When an event triggers the AMF to send an N1 reset request to the UE, the N1 reset request may be enhanced so that the AMF may indicate to the UE that the NAS-SM context of the UE should be retained when the UE is in RM-REGISTERED-PAUSE. The request may identify which PDU session's NAS-SM context needs to be retained by including the PDU session ID of each PDU session whose NAS-SM context needs to be retained. For each PDU session whose context needs to be retained, the AMF may include an N1 SM container. The N1 SM container may include an indication that the network expects to maintain the NAS-SM context and a time value indicating how long the UE should retain the NAS-SM context of the UE.

[0197] The N1 reset request may also include a reset timer. The reset timer may indicate to the UE that the UE 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 enter the RM-REGISETERED-PAUSE state immediately, the ME part of the UE will be able to send a pause warning notification to the application hosted by the TE part of the ME. The applications that receive the warning will then be able to save their associated application layer context and send a warning to any application server with which they communicate. Warnings to application servers may be sent over the user plane and may indicate a time window when the UE application may be unavailable. AT commands may be used to send a warning notification from the ME part of the UE to an application hosted on the TE part of the UE.

[0198] The UE may send an N1 reset accept message to the AMF, and the message may indicate whether the UE will retain the SM context for each PDU session. For example, the accept message may include an indication for each PDU session that the UE will save the SM context for that PDU session when the UE is in the RM-REGISETERED-PAUSE state. The message may also indicate to the AMF how long the UE plans to save the SM context.

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

[0200] As described above, the UE may initiate a procedure for initiating a reset of the NAS-MM context of the UE in the UE and the AMF. The trigger for the UE to initiate the procedure may be that the UE is connected to a network for emergency services and desires to change its connection to a non-emergency connection, the trigger for the UE to initiate the procedure may be that the configuration of the UE has changed and the configuration change requires a NAS-MM reset, or the trigger for the UE to initiate the procedure may be that the UE is installing a software update and the NAS-MM context needs to be reset and the UE's connection cannot be maintained when the software update is installed.

[0201] When the UE enters the RM-DEREGISTERED state, the UE may store or maintain a NAS-SM context for any PDU Session for which the persistent NAS-SM context feature is enabled. The UE may determine that the persistent NAS-SM context feature is enabled based on negotiation with the network, as previously described in the description of enhancements to the PDU Session Establishment, UE-Initiated Deregistration, and Network-Initiated Deregistration procedures. As described above, the amount of time that the UE stores the NAS-SM context for each PDU Session may be determined by a timer. In other words, if the UE detects that the timer has expired, the UE may delete the NAS-SM context.

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

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

[0204] After resetting its NAS-MM context, the UE may send a registration request to the network in order to enter the RM-REGISTERED state. As described above, this may mean that the UE transitions from the RM-DEREGISTERED state to the RM-REGISTERED state, or may mean that the UE transitions from the RM-REGISTERED-PAUED state to the RM-REGISTERED state.

[0205] When the UE attempts to enter the RM-REGISTERED state from the RM-DEREGISTERED state, the UE will send a registration request to the network. The registration type may indicate that the UE is performing an initial registration. The current 5G system design does not allow the UE to include the "PDU session list to be activated" information element when performing an initial registration. The registration process may be enhanced so that when performing an initial registration, the UE may send a "PDU session list to be activated" information element to the network.

[0206] The presence of the "PDU Session List to be Activated" in the initial Registration Request may be used as an indication to the network that the UE wishes to re-establish the NAS-SM context that was saved in the UE when it was in the RM-DEREGISTED state. The "PDU Session List to be Activated" is conveyed to the network in the NAS PDU Session Status IE.

[0207] When the UE attempts to enter the RM-REGISTERED state from the RM-REGISTERED-PAUSE state, the UE will send a registration request to the network. The registration type may indicate that the UE is performing a mobility registration update, or a new registration type may be defined to explicitly indicate that the purpose of the registration request is to enter the RM-REGISTERED state and restore the NAS-SM context. A "PDU Session List to be Activated" may be included in the request to indicate which PDU Session contexts should be restored.

[0208] Alternatively, the UE may send an explicit indication to the network in a new IE to indicate that the UE desires to re-establish the NAS-SM context that was saved in the UE when it was in the RM DEREGISTED state.

[0209] Note that when the UE sends an initial or mobility registration request to the RAN, the UE will provide the 5G-GUTI in the RRC part of the message. The 5G-GUTI is associated with the AMF that the UE last registered with. It is likely but not guaranteed that the RAN will select the same AMF that provided the 5G-GUTI to serve the UE. If the RAN selects a different AMF to serve the UE, re-establishing the NAS-SM context will still be able to proceed because the NAS-SM is stored in the UDM and SMF.

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

[0211] The AMF may indicate to the UE in the Registration Accept message that the SM context of some PDU Sessions cannot be restored. For example, they may occur if the UE is not able to register with the slice. In other words, this may occur if the slice associated with the PDU Session is not in the allowed NSSAI of the UE. When the NAS-SM context cannot be restored, the UE shall delete the NAS-SM context. The AMF indicates to the UE that the SM context of a PDU Session cannot be restored by including the PDU Session ID in the Registration Accept message.

[0212] When the context is restored, the UE may notify any applications it hosts that the SM context is restored. For example, the notification may let the application know that the application has network connectivity again, and the notification may trigger the application to use the restored PDU session and the restored SM context. Thus, an application layer message may be sent to the network server to notify the server that the application has network connectivity and is available or reachable using the restored SM context (e.g., IP address).

[0213] Prior to performing a NAS-MM reset, the UE may notify any applications hosted by it that the NAS-MM context is about to be reset. The UE-hosted application may then notify the application server that the application is about to enter a period of time during which the application will be unreachable. The notification may indicate to the application server a time value indicating how long the application server may assume that the UE application will retain the application layer context.

[0214] The NAS-SM context retention feature described herein may be subject to validity criteria that specify conditions for the applicability of the feature. The validity criteria may include one or more of a validity area criteria, a time of day criteria, or an access technology related criteria such as an access technology type. For example, the validity area criteria may include one or more of the following: a 3GPP location type, such as a PLMN (Public Land Mobile Network), a TAC (Tracking Area Code), a LAC (Location Area Code), a cell identifier; a WLAN (Wireless Local Area Network) location type, such as an SSID (Service Set Identifier), a HESSID (Homogeneous Extended SSID), a BSSID (Basic SSID); or a geographic location type, such as in the form of latitude, longitude, or radius as defined in TS23.032. The time of day criteria may include one or more of a time start, a time stop, a date start, a date stop, and a day of the week. The access technology standard may include one or more 3GPP RATs (Radio Access Technologies) such as UTRAN RAT (Universal Mobile Telecommunications Service Terrestrial Radio Access Network RAT), EUTRAN (Evolved UTRAN) RAT, NR RAT, one or more WLAN RATs, and the like.

[0215] The UE may receive the validity criteria in a PDU SESSION ACCEPT message or a REGISTER ACCEPT message. When the validity criteria is received in a REGISTER ACCEPT message, the validity criteria may apply to any PDU Session associated with the UE. When the validity criteria is received in a PDU SESSION ACCEPT message, the validity criteria may apply only to the PDU Session associated with the PDU SESSION ACCEPT message.

[0216] The UE may use the validity criteria to determine when to allow a NAS-MM reset to be performed while retaining the NAS-SM context. For example, the UE may determine that a NAS-MM reset is allowed while retaining the NAS-SM context only when the current state of the UE matches the validity criteria.

[0217] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunication network technologies, including radio access, core transport networks, and service capabilities, including research 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"). It is expected that the 3GPP NR standards will continue to develop and include the definition of the next generation of radio access technology (new RAT), which is expected to provide new flexible radio access below 7 GHz and new ultra-mobile broadband radio access above 7 GHz. The flexible radio access is expected to include new non-backward compatible radio access in 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 set of 3GPP NR use cases with different needs. It is expected that ultra-mobile broadband includes centimeter wave and millimeter wave spectrum, which will provide opportunities for ultra-mobile broadband access for indoor applications and hotspots, for example. In particular, ultra mobile broadband is expected to share a common design framework with sub-7 GHz flexible radio access, with centimeter-wave and millimeter-wave specific design optimizations.

[0218] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide range of user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (eMBB), ultra-reliable low latency communications (URLLC), massive machine type communications (mMTC), network operations (e.g., network slicing, routing, migration and interworking, energy conservation), and enhanced connected vehicles to everything (eV2X) communications, which may include any of vehicle-to-vehicle communications (V2V), vehicle-to-infrastructure communications (V2I), vehicle-to-network communications (V2N), vehicle-to-pedestrian communications (V2P), and vehicle communications with other entities. Specific services and applications within these categories include, for example, monitoring and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, cloud-based wireless offices, first responder connectivity, car emergency calls, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile Internet, virtual reality, home automation, robotics, and drones. This article considers all of these use cases and others.

[0219] Fig.15A An exemplary communication system 100 is shown 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 are generally or collectively referred to as WTRUs 102 or multiple WTRUs 102. The communication system 100 may include a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and network services 113. 113. The network services 113 may include, for example, V2X servers, V2X functions, ProSe servers, ProSe functions, IoT services, video streaming, and / or edge computing, etc.

[0220] It should be appreciated that the concepts disclosed herein may be used with any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs in WTRU 102 may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Fig.15A In the example, FIG. 15A to FIG. 15E 102 is depicted as a handheld wireless communication device. It should be understood that, in the context of various use cases contemplated for wireless communication, each WTRU may include or be included in any type of device or apparatus configured to transmit and / or receive wireless signals, including, by way of example only: a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a tablet computer, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronic device, a wearable device (such as a smart watch or smart clothing), a medical device or an e-health device, a robot, an industrial equipment, a drone, a vehicle such as a car, a truck, a train or an airplane, etc.

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

[0222] The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, network services 113, and / or other networks 112. The RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or network services 113. By way of example, the base stations 114a, 114b may be base transceiver stations (BTSs), Node Bs, eNode Bs, Home Node Bs, Home eNode Bs, Next Generation Node Bs (gNode Bs), satellites, site controllers, access points (APs), wireless routers, and the like.

[0223] The base station 114a may be part of the RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. Similarly, the base station 114b may be part of the RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as a BSC, an RNC, a relay node, etc. The base station 114a may be configured to transmit and / or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). Similarly, the base station 114b may be configured to transmit and / or receive wired signals and / or wireless signals within a specific geographic area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, for example, the base station 114a may include three transceivers, for example, one transceiver for each sector of the cell. The base station 114a may employ multiple-input multiple-output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell, for example.

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

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

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

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

[0228] 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, SC-FDMA, etc. For example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c or the RRHs 118a, 118b in the RAN 103b / 104b / 105b, the TRPs 119a, 119b and / or the RSUs 120a and 120b and the WTRUs 102c, 102d, 102e, and 102f may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interfaces 115 / 116 / 117 and / or 115c / 116c / 117c, respectively. WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

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

[0230] The base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, and 102g or the RRHs 118a and 118b, TRPs 119a and 119b and / or RSUs 120a and 120b and the WTRUs 102c, 102d, 102e, and 102f in the RAN 103b / 104b / 105b may implement a radio technology such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE(GERAN) etc.

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

[0232] The RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b may be in communication with the core network 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 the WTRUs 102. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication.

[0233] Although not in Fig.15A Although not shown in the figure, it will be appreciated that the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b, which may be utilizing an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) that employs a GSM or NR radio technology.

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

[0235] Some or all of the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f in the communication system 100 may include multi-mode capabilities. For example, the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f may include multiple transceivers for communicating with different wireless networks via different wireless links. Fig.15A The illustrated WTRU 102g may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114c, which may employ an IEEE 802 radio technology.

[0236] Despite Fig.15A It is not shown, but it should be understood that the user equipment may be wired to the gateway. The gateway may be a residential gateway (RG). The RG may provide a connection to the core network 106 / 107 / 109. It should be understood that many of the ideas contained herein are equally applicable to UEs that are WTRUs and UEs that use wired connections to connect to the network. For example, the ideas applied to the wireless interfaces 115, 116, 117, and 115c / 116c / 117c are equally applicable to wired connections.

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

[0238] like Fig. 15B As shown, Node B 140a, 140b can communicate with RNC 142a. In addition, Node B 140c can communicate with RNC 142b. Node B 140a, 140b and 140c can communicate with corresponding RNC 142a and 142b via Iub interface. RNC 142a and 142b can communicate with each other via Iur interface. Each of RNC 142a and 142b can be configured to control the corresponding Node B 140a, 140b and 140c to which it is connected. In addition, each of RNC 142a and 142b can be configured to perform or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security function, data encryption, etc.

[0239] Fig. 15B The illustrated core network 106 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. While each of the foregoing elements are depicted as part of the core network 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

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

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

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

[0243] Fig. 15C 1 is a system diagram of an exemplary RAN 104 and core network 107. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

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

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

[0246] Fig. 15C The illustrated core network 107 may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it should be understood that any of these elements may be owned and / or operated by an entity other than a core network operator.

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

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

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

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

[0251] Fig.15D 1 is a system diagram of an exemplary RAN 105 and core network 109. The RAN 105 may employ NR radio technology to communicate with the WTRUs 102a and 102b over the air interface 117. The RAN 105 may also be in communication with the core network 109. A non-3GPP interworking function (N3IWF) 199 may employ non-3GPP radio technology to communicate with the WTRU 102c over the air interface 198. The N3IWF 199 may also be in communication with the core network 109.

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

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

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

[0255] Fig.15D The core network 109 shown may be a 5G core network (5GC). The core network 109 may provide a variety of communication services to customers interconnected by a radio access network. The core network 109 includes multiple entities that perform the functionality of the core network. As used herein, the term "core network entity" or "network function" refers to any entity that performs one or more functions of the core network. It should be understood that such core network entities may be logical entities implemented in the form of computer executable instructions (software) stored in a device or computer system (such as a computer system) configured for wireless and / or network communications. Figure 15G The system 90 shown is stored in a memory and executed on a processor thereof.

[0256] exist Fig.15D In the example of , the 5G core network 109 may include access and mobility management function (AMF) 172, session management function (SMF) 174, user plane function (UPF) 176a and 176b, user data management function (UDM) 197, authentication server function (AUSF) 190, network exposure function (NEF) 196, policy control function (PCF) 184, non-3GPP interworking function (N3IWF) 199, user data repository (UDR) 178. Although each of the foregoing elements is depicted as part of the 5G core network 109, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator. It should also be understood that the 5G core network may not include all of these elements, may include additional elements, and may include multiple instances of each of these elements. Fig.15D The network functions are shown connected directly to each other, however, it should be understood that they may communicate via a routing agent such as a Diameter routing agent or a message bus.

[0257] exist Fig.15D In the example of , the connection between network functions is realized via a set of interfaces or reference points. It should be understood that network functions can be modeled, described or realized as a set of services called or invoked by other network functions or services. The invocation of network function services can be realized via direct connection between network functions, message exchange on a message bus, calling software functions, etc.

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

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

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

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

[0262] PCF 184 may be connected to SMF 174 via an N7 interface, to AMF 172 via an N15 interface, and to application function (AF) 188 via an N5 interface. The N15 and N5 interfaces are Fig.15D 102a, 102b, and 102c. The PCF 184 may provide policy rules to control plane nodes such as the AMF 172 and the SMF 174, thereby allowing the control plane nodes to implement these rules. The PCF 184 may send policies for the WTRUs 102a, 102b, and 102c to the AMF 172 so that the AMF may deliver the policies to the WTRUs 102a, 102b, and 102c via the N1 interface. The policies may then be implemented or applied at the WTRUs 102a, 102b, and 102c.

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

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

[0265] AUSF 190 performs authentication-related operations and is connected to UDM 178 via the N13 interface and to AMF 172 via the N12 interface.

[0266] NEF 196 exposes the capabilities and services in the 5G core network 109 to the application function (AF) 188. The exposure may occur on the N33 API interface. NEF can be connected to AF 188 via the N33 interface, and NEF can be connected to other network functions to expose the capabilities and services of the 5G core network 109.

[0267] The application function 188 may interact with the network functions in the 5G core network 109. The interaction between the application function 188 and the network functions may occur via a direct interface or may occur via the NEF 196. The application function 188 may be considered part of the 5G core network 109 or may be external to the 5G core network 109 and deployed by an enterprise having a business relationship with a mobile network operator.

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

[0269] 3GPP has designed the 5G core network to support network slicing. Network slicing is a useful tool that network operators can use to support a variety of 5G use cases that require diverse and sometimes extreme requirements (e.g., massive IoT, critical communications, V2X, and enhanced mobile broadband). Without the use of network slicing technology, when each use case has its own set of specific requirements for performance, scalability, and availability, the flexibility and scalability of the network architecture may not be sufficient to effectively support a wider range of use case requirements. In addition, new network services should be introduced more efficiently.

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

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

[0272] This article and Fig.15A , Fig. 15C , Fig.15D and Fig.15E The core network entities shown in are identified by the names given to these entities in certain existing 3GPP specifications, but it should be understood that these entities and functions may be identified by other names in the future, and that certain entities or functions may be combined in specifications published by 3GPP in the future (including future 3GPP NR specifications). FIG. 15A to FIG. 15E The specific network entities and functionality described and illustrated in the present disclosure are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether currently defined or defined in the future.

[0273] Fig.15E An exemplary communication system 111 is shown in which the systems, methods, and apparatus described herein may be used. The communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, a base station gNB 121, a V2X server 124, and road side units (RSUs) 123a and 123b. In fact, the concepts presented herein may be applied to any number of WTRUs, base stations gNBs, V2X networks, and / or other network elements. One or several or all of the WTRUs A, B, C, D, E, and F may be outside the range of the access network coverage 131. WTRUs A, B, and C form a V2X group, where WTRU A is the group leader and WTRUs B and C are group members.

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

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

[0276] Fig.15F is an exemplary apparatus or device WTRU 102 (such as FIG. 15A to FIG. 15E 102). Fig.15F As shown, the exemplary WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keyboard 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 should be understood that the WTRU 102 may include any sub-combination of the foregoing elements. In addition, the base stations 114a and 114b and / or the nodes that the base stations 114a and 114b may represent (such as, but not limited to, a transceiver station (BTS), a Node B, a site controller, an access point (AP), a home node B, an evolved home node B (eNodeB), a home evolved node B (HeNB), a home evolved node B gateway, a next generation node B (gNode-B), and a proxy node, etc.) may include Fig.15F Some or all of the elements depicted in and described herein.

[0277] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of 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 the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Fig.15F The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0278] The transmit / receive element 122 of the UE may be configured to transmit data to a base station (eg, Fig.15A The transmission / reception element 122 may be a base station 114a) of the wireless communication network or receive a signal from the base station, or transmit a signal to another UE or receive a signal from the UE through the air interface 115d / 116d / 117d. For example, the transmission / reception element 122 may be an antenna configured to transmit and / or receive RF signals. The transmission / reception element 122 may be a transmitter / detector configured to transmit and / or receive, for example, IR signals, UV signals, or visible light signals. The transmission / reception element 122 may be configured to transmit and receive both RF signals and optical signals. It should be understood that the transmission / reception element 122 may be configured to transmit and / or receive any combination of wireless signals or wired signals.

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

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

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

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

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

[0284] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos or videos), universal serial bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, Frequency Modulation (FM) radio units, digital music players, media players, video game player modules, Internet browsers, etc.

[0285] The WTRU 102 may be included in other devices or equipment, such as sensors, consumer electronics, wearable devices (such as smart watches or smart clothing), medical or e-health devices, robots, industrial equipment, drones, vehicles (such as cars, trucks, trains, or airplanes). The WTRU 102 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 that may include one of the peripheral devices 138).

[0286] Figure 15G is a block diagram of an exemplary computing system 90, in which Fig.15A , Fig. 15C , Fig.15D and Fig.15E 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, certain nodes or functional entities in 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, which may be in the form of software, regardless of where or by what means such software is stored or accessed. Such computer-readable instructions may be executed within a processor 91 to enable the computing system 90 to work. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of 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 encoding, data processing, power control, input / output processing, and / or any other functionality that enables the computing system 90 to work in a communication network. Coprocessor 81 is an optional processor distinct from main processor 91 that may perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

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

[0288] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such memory includes circuits that allow information to be stored and retrieved. ROM 93 generally contains stored data that cannot be easily modified. The data stored in RAM 82 can be read or changed by a processor 91 or other hardware device. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that converts a virtual address into a physical address as an instruction is executed. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process virtual address space; unless memory sharing between processes has been set, it cannot access memory within the virtual address space of another process.

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

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

[0291] Further, computing system 90 may contain communications circuitry, such as, for example, a wireless or wired network adapter 97, which may be used to connect computing system 90 to an external communications network or device, such as FIG. 15A to FIG. 15E The RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, WTRU 102 or other network 112 can be used to enable the computing system 90 to communicate with other nodes or functional entities of these networks. Communication circuits alone or in combination with the processor 91 can be used to perform the transmission and reception steps of certain devices, nodes or functional entities described herein.

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

[0293] Table 1 Acronyms

[0294]

[0295]

[0296] Table 2 UE routing selection strategy

[0297]

[0298] Table 3 UE routing selection policy rules

[0299]

[0300]

[0301] Table 4 Routing Descriptor

[0302]

[0303]

[0304] Table 5 SSC Mode Information Element Coding - Option 1

[0305]

[0306] Table 6 SSC Mode Information Element Coding - Option 2

[0307] < / mnc> < / mcc> < / guami> < / guami>

Claims

1. A method implemented by a wireless transmit / receive unit (WTRU) for communicating with a network, the method comprising: sending, by the WTRU to a network node, a registration request message requesting registration with the network, wherein the registration request message includes an indication that the WTRU is able to retain context information associated with communications between the WTRU and the network when the WTRU becomes unavailable to the network; receiving, by the WTRU from the network node, a registration accept message, wherein the registration accept message includes an indication that the network supports retention of the context information when the WTRU becomes unavailable to the network; sending, by the WTRU, a first message to the network based on a determination that the WTRU will become unavailable to the network, the first message indicating a request to retain the context information, wherein the first message includes an indication of a time period for which the WTRU will be unavailable; sending a notification to one or more applications hosted by the WTRU, the notification indicating that the WTRU is about to be unavailable for the network; as well as After the time period has expired, a second message is sent to the network indicating that the WTRU is available to the network.

2. The method of claim 1 , further comprising determining that the WTRU will become unavailable to the network due to any one or more of the following: Modem reset; Operating system updates; Software updates; Network-initiated logout request; WTRU initiated deregistration request; N1 reset request initiated by the network; A WTRU initiated N1 reset request; or A change from the RM-REGISTERED state to the RM-DEREGISTERED state.

3. The method of claim 1, wherein the context information comprises non-access stratum (NAS) session management (SM) context information.

4. The method of claim 1, wherein the context information comprises any one or more of the following: Protocol Data Unit (PDU) session identifier; Data Network Name (DNN); Single Network Slice Assistance Information (S-NSSAI); or Internet Protocol (IP) address.

5. The method of claim 1 , wherein the first message indicating the request to retain the context information comprises one of: N1 reset request message; or A deregistration request message initiated by the WTRU.

6. The method of claim 1, wherein the second message indicating that the WTRU is available for the network comprises a second registration request message.

7. The method of claim 1, further comprising sending a request to the network to establish a protocol data unit (PDU) session, wherein the request to establish the PDU session includes an indication requesting retention of the context information used for the PDU session when the WTRU becomes unavailable.

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

9. The method of claim 1, further comprising receiving, by the WTRU, a second message from the network node, the second message indicating a duration associated with retaining the context information.

10. A wireless transmit / receive unit (WTRU), the wireless transmit / receive unit (WTRU) comprising a processor and a memory, the memory storing instructions that, when executed by the processor, cause the WTRU to: sending a registration request message to a network node requesting registration with the network, wherein the registration request message includes an indication that the WTRU is able to retain context information associated with communications between the WTRU and the network when the WTRU becomes unavailable to the network; receiving a registration accept message from the network node, wherein the registration accept message includes an indication that the network supports retention of the context information when the WTRU becomes unavailable to the network; based on a determination that the WTRU will become unavailable to the network, sending a first message to the network indicating a request to retain the context information, wherein the first message includes an indication of a time period for which the WTRU will become unavailable; sending a notification to one or more applications hosted by the WTRU, the notification indicating that the WTRU is about to be unavailable for the network; as well as After the time period has expired, a second message is sent to the network indicating that the WTRU is available to the network.

11. The WTRU of claim 10, wherein the instructions, when executed by the processor, further cause the WTRU to determine that the WTRU will become unavailable to the network due to any one or more of: Modem reset; Operating system updates; Software updates; Network-initiated logout request; WTRU initiated deregistration request; N1 reset request initiated by the network; A WTRU initiated N1 reset request; or A change from the RM-REGISTERED state to the RM-DEREGISTERED state.

12. The WTRU of claim 10, wherein the context information comprises non-access stratum (NAS) session management (SM) context information.

13. The WTRU of claim 10, wherein the context information comprises any one or more of: Protocol Data Unit (PDU) session identifier; Data Network Name (DNN); Single Network Slice Assistance Information (S-NSSAI); or Internet Protocol (IP) address.

14. The WTRU of claim 10 , wherein the first message indicating the request to retain the context information comprises one of: N1 reset request message; or A deregistration request message initiated by the WTRU.

15. The WTRU of claim 10, wherein the second message indicating that the WTRU is available for the network comprises a second registration request message.

16. A WTRU according to claim 10, wherein the instructions, when executed by the processor, further cause the WTRU to send a request to the network to establish a protocol data unit (PDU) session, wherein the request to establish the PDU session includes an indication requesting to retain the context information associated with the PDU session when the WTRU becomes unavailable.

17. The WTRU of claim 10, wherein the instructions, when executed by the processor, further cause the WTRU to store the context information in the WTRU before the WTRU becomes unavailable.

18. The WTRU of claim 10, wherein the instructions, when executed by the processor, further cause the WTRU to receive a second message from the network node, the second message indicating a duration associated with retaining the context information.

19. A wireless transmit / receive unit (WTRU), the wireless transmit / receive unit (WTRU) comprising a processor and a memory, the memory storing instructions that, when executed by the processor, cause the WTRU to: Receive multiple URSP rules; evaluating the received plurality of URSP rules to determine that an application matches a traffic descriptor of a URSP rule in the plurality of URSP rules; Selecting a routing descriptor (RSD) within the URSP rules; determining an existing protocol data unit (PDU) session that matches all components in the selected RSD; as well as The application is associated with the existing PDU session.

Images