Patent Description:
The following abbreviations are herewith defined, at least some of which are referred to within the following description: Third Generation Partnership Project ("3GPP"), Positive-Acknowledgment ("ACK"), Core Access and Mobility Management Function ("AMF"), Base Station ("BS"), Binary Phase Shift Keying ("BPSK"), Clear Channel Assessment ("CCA"), Cyclic Prefix ("CP"), Cyclical Redundancy Check ("CRC"), Channel State Information ("CSI"), Common Search Space ("CSS"), Data Radio Bearer ("DRB"), Discrete Fourier Transform Spread ("DFTS"), Downlink Control Information ("DCI"), Downlink ("DL"), Downlink Pilot Time Slot ("DwPTS"), Enhanced Clear Channel Assessment ("eCCA"), Enhanced LTE ("eLTE"), Enhanced Mobile Broadband ("eMBB"), Evolved Node B ("eNB"), Evolved Packet Core ("EPC"), European Telecommunications Standards Institute ("ETSI"), Evolved, Universal Terrestrial Radio Access ("E-UTRA"), Frame Based Equipment ("FBE"), Frequency Division Duplex ("FDD"), Frequency Division Multiple Access ("FDMA"), Frequency Division Orthogonal Cover Code ("FD-OCC"), Guard Period ("GP"), Globally Unique Temporary UE Identity ("GUTI"), Hybrid Automatic Repeat Request ("HARQ"), Home Location Register ("HLR"), Home Subscriber Server ("HSS"), Identity ("ID"), International Mobile Subscriber Identity ("IMSI"), Internet-of-Things ("IoT"), Licensed Assisted Access ("LAA"), Load Based Equipment ("LBE"), Listen-Before-Talk ("LBT"), Long Term Evolution ("LTE"), Multiple Access ("MA"), Mobility Management Entity ("MME"), Modulation Coding Scheme ("MCS"), Machine Type Communication ("MTC"), Multiple Input Multiple Output ("MIMO"), Multi User Shared Access ("MUSA"), Non Access Stratum ("NAS"), Narrowband ("NB"), Negative-Acknowledgment ("NACK") or ("NAK"), Network Exposure Function ("NEF"), Next Generation Node B or <NUM> Node B ("gNB"), New Radio ("NR"), Network Slice Selection Assistance Information ("NSSAI"), Network Slice Instance ("NSI"), Network Slice Selection Function ("NSSF"), Non-Orthogonal Multiple Access ("NOMA"), Operation and Maintenance System ("OAM"), Orthogonal Frequency Division Multiplexing ("OFDM"), Primary Cell ("PCell"), Physical Broadcast Channel ("PBCH"), Policy Control Function ("PCF"), Physical Downlink Control Channel ("PDCCH"), Physical Downlink Shared Channel ("PDSCH"), Pattern Division Multiple Access ("PDMA"), Packet Data Unit ("PDU"), Physical Hybrid ARQ Indicator Channel ("PHICH"), Public Land Mobile Network ("PLMN"), Physical Random Access Channel ("PRACH"), Physical Resource Block ("PRB"), Physical Uplink Control Channel ("PUCCH"), Physical Uplink Shared Channel ("PUSCH"), Quality of Service ("QoS"), Quadrature Phase Shift Keying ("QPSK"), Radio Access Network ("RAN"), Radio Resource Control ("RRC"), Random Access Procedure ("RACH"), Random Access Response ("RAR"), Radio Network Temporary Identifier ("RNTI"), Reference Signal ("RS"), Registration Area ("RA"), Remaining Minimum System Information ("RMSI"), Resource Spread Multiple Access ("RSMA"), Round Trip Time ("RTT"), Receive ("RX"), Single Network Slice Selection Assistance Information ("S-NSSAI"), Sparse Code Multiple Access ("SCMA"), Scheduling Request ("SR"), Single Carrier Frequency Division Multiple Access ("SC-FDMA"), Secondary Cell ("SCell"), Shared Channel ("SCH"), Signal-to-Interference-Plus-Noise Ratio ("SINR"), System Information Block ("SIB"), Session Management Function ("SMF"), Synchronization Signal ("SS"), Tracking Area ("TA"), Transport Block ("TB"), Transport Block Size ("TBS"), Time-Division Duplex ("TDD"), Time Division Multiplex ("TDM"), Time Division Orthogonal Cover Code ("TD-OCC"), Transmission Time Interval ("TTI"), Transmit ("TX"), Unified Data Management ("UDM"), Uplink Control Information ("UCI"), User Entity/Equipment (Mobile Terminal) ("UE"), Uplink ("UL"), Universal Mobile Telecommunications System ("UMTS"), Uplink Pilot Time Slot ("UpPTS"), User Plane ("UP"), User Plane Function ("UPF"), Ultra-reliability and Low-latency Communications ("URLLC"), and Worldwide Interoperability for Microwave Access ("WiMAX"). As used herein, "HARQ-ACK" may represent collectively the Positive Acknowledge ("ACK") and the Negative Acknowledge ("NACK"). ACK means that a TB is correctly received while NACK (or NAK) means a TB is erroneously received.

In certain wireless communications networks, a remote unit may physically move to an area that makes certain PDU sessions unavailable. In such networks, the unavailable PDU sessions may not be released.

S2-<NUM> is a 3GPP discussion document titled "<NPL>; and proposes updates to functionality required for slice co-existence. S2-<NUM> is a 3GPP discussion document titled "<NPL>; and proposes how to handle rejected S-NSSAIs. S2-<NUM> is a 3GPP discussion document titled "<NPL>; and describes homogeneous support of network slice withing a registration area. 3GPP TS <NUM> v1. <NUM> is a technical specification of group services and system aspects and defines the stage <NUM> architecture for the <NUM> system. S2-<NUM> is a 3GPP discussion document titled "<NPL>; and describes a proposal for the Modification of the Set of Network Slice(s) for a UE. S2-<NUM> is a 3GPP discussion document titled "<NPL>; and describes changes in the Registration procedure and PDU Session release procedure.

Claim <NUM> defines a method in an Access and Mobility Management Function (AMF) and claim <NUM> defines an Access and Mobility Management Function (AMF). In the following, any method and/or apparatus referred to as embodiments but nevertheless do not fall within the scope of the appended claims are to be understood as examples helpful in understanding the invention.

<FIG> depicts an embodiment of a wireless communication system <NUM> for indicating packet data unit sessions as unavailable. In one embodiment, the wireless communication system <NUM> includes remote units <NUM>, base units <NUM>, and a network function <NUM>. Even though a specific number of remote units <NUM>, base units <NUM>, and network functions <NUM> are depicted in <FIG>, one of skill in the art will recognize that any number of remote units <NUM>, base units <NUM>, and network functions <NUM> may be included in the wireless communication system <NUM>.

In one embodiment which is not a part of the claimed invention, the remote units <NUM> may include computing devices, such as desktop computers, laptop computers, personal digital assistants ("PDAs"), tablet computers, smart phones, smart televisions (e.g., televisions connected to the Internet), set-top boxes, game consoles, security systems (including security cameras), vehicle on-board computers, network devices (e.g., routers, switches, modems), aerial vehicles, drones, or the like.

The base units <NUM> may be distributed over a geographic region. In certain embodiments, a base unit <NUM> may also be referred to as an access point, an access terminal, a base, a base station, a Node-B, an eNB, a gNB, a Home Node-B, a relay node, a device, a core network (e.g., EPC, 5GC), an aerial server, or by any other terminology used in the art. The base units <NUM> are generally part of a radio access network that includes one or more controllers communicably coupled to one or more corresponding base units <NUM>. In some embodiments, the base unit <NUM> may include a RAN (e.g., <NUM>-RAN such as E-UTRA, <NUM>-RAN such as eLTE or NR). In certain embodiments, the network function <NUM> may include an MME, an AMF, a UPF, and/or an SMF.

In one implementation, the wireless communication system <NUM> is compliant with the 3GPP protocol, wherein the base unit <NUM> transmits using an OFDM modulation scheme on the DL and the remote units <NUM> transmit on the UL using a SC-FDMA scheme or an OFDM scheme. More generally, however, the wireless communication system <NUM> may implement some other open or proprietary communication protocol, for example, WiMAX, among other protocols.

In the embodiment of the invention, a network function <NUM> (e.g., AMF) may determine that at least one packet data unit session is unavailable. In various embodiments, the network function <NUM> may transmit information indicating that the at least one packet data unit session is to be released. Accordingly, a network function <NUM> may be used for indicating packet data unit sessions as unavailable.

In one embodiment, a network function <NUM> (e.g., SMF) may receive information indicating to release at least one packet data unit session. In various embodiments, the network function <NUM> may determine whether to send explicit signaling to a remote unit <NUM> for releasing the at least one packet data unit session. In certain embodiments, the network function <NUM> may release the at least one packet data unit session in response to receiving the information. Accordingly, a network function <NUM> may be used for indicating packet data unit sessions as unavailable.

<FIG> depicts one embodiment of an apparatus <NUM> that may be used for receiving an indication that packet data unit sessions are unavailable. The apparatus <NUM> includes one embodiment of the remote unit <NUM>. Furthermore, the remote unit <NUM> may include a processor <NUM>, a memory <NUM>, an input device <NUM>, a display <NUM>, a transmitter <NUM>, and a receiver <NUM>. In some embodiments, the input device <NUM> and the display <NUM> are combined into a single device, such as a touchscreen. In certain embodiments, the remote unit <NUM> may not include any input device <NUM> and/or display <NUM>. In various embodiments, the remote unit <NUM> may include one or more of the processor <NUM>, the memory <NUM>, the transmitter <NUM>, and the receiver <NUM>, and may not include the input device <NUM> and/or the display <NUM>.

The transmitter <NUM> is used to provide UL communication signals to the base unit <NUM> and the receiver <NUM> is used to receive DL communication signals from the base unit <NUM>.

<FIG> depicts one embodiment of an apparatus <NUM> that may be used for indicating packet data unit sessions as unavailable. The apparatus <NUM> includes one embodiment of the network function <NUM>. Furthermore, the network function <NUM> may include a processor <NUM>, a memory <NUM>, an input device <NUM>, a display <NUM>, a transmitter <NUM>, and a receiver <NUM>. As may be appreciated, the processor <NUM>, the memory <NUM>, the input device <NUM>, the display <NUM>, the transmitter <NUM>, and the receiver <NUM> may be substantially similar to the processor <NUM>, the memory <NUM>, the input device <NUM>, the display <NUM>, the transmitter <NUM>, and the receiver <NUM> of the remote unit <NUM>, respectively.

In some embodiments, the processor <NUM> may determine that at least one packet data unit session is unavailable. In various embodiments, the transmitter <NUM> may transmit information indicating that the at least one packet data unit session is to be released. In various embodiments, the receiver <NUM> may receive information indicating to release at least one packet data unit session. In various embodiments, the processor <NUM> may determine whether to send explicit signaling to a remote unit for releasing the at least one packet data unit session. In certain embodiments, the processor <NUM> may release the at least one packet data unit session in response to receiving the information. Although only one transmitter <NUM> and one receiver <NUM> are illustrated, the base unit <NUM> may have any suitable number of transmitters <NUM> and receivers <NUM>.

<FIG> is a schematic block diagram illustrating one embodiment of network <NUM> availability. Specifically <FIG> illustrates one embodiment of a UE's RAa and the availability of network slices. In RA1, a UE may be associated with Slice-<NUM> and Slice-<NUM>. Moreover, Slice-<NUM> may use dedicated core network functions grouped and denoted as dedicated CN-<NUM><NUM>. Similarly, Slice-<NUM> may use dedicated core network functions grouped and denoted as dedicated CN-<NUM><NUM>. Furthermore, RA1 may have a connection to AMF1 <NUM>. In RA2, only Slice-<NUM> is available, and RA2 may have a connection to AMF2 <NUM>. If the UE moves from RA1 to RA2, the PDU sessions established with Slice-<NUM> may need to be released, but there may be no connection between the AMF2 <NUM> and the dedicated CN-<NUM><NUM>, so a PDU session release procedure may not be able to be performed.

It should be noted that while PDU sessions are described herein, any of the methods described herein may be applied to any kind of sessions and/or connections (e.g., PDN connection) in a mobile network and/or a fixed network.

Furthermore, different mobility events (e.g., mobility in CM-IDLE state, mobility in CM-CONNECTED state) are described herein; however, the methods described herein are not limited to these mobility events, but may be applied to any change of network slices associated with a UE.

In certain embodiments, a UE may change from one registration area (e.g., old RA) to a new registration area (e.g., new RA). In such embodiments, the network (e.g. AMF) may determine that the network slices used by the UE need to be changed. More specifically, the network may determine that already used network slice cannot be used anymore (e.g., one or more network slices become unavailable). In various embodiments, the network (e.g., AMF that determines the change of network slices) further determines whether the AMF (either new or serving) can contact the network functions (e.g., SMF) from the unavailable network slice (or network slice instances). In such embodiments, the AMF may determine whether existing related PDU sessions need to be released autonomously in the SMF, UPF, and/or PCF, or whether the PDU session release can be performed with explicit N1 session management ("SM") signaling. In certain embodiments, the network (e.g., AMF) may determine that it is not possible to send and/or receive N1 SM signaling between the UE and dedicated slice NF (e.g., SMF) anymore (e.g., the UE is unreachable for this network slice). In such embodiments, the network (e.g., AMF) informs entities from the unavailable network slice instance about the inability to be used for the particular UE, resulting in implicitly deleting the UE's SM context in the entities of the unavailable network slice.

In some embodiments, if a network slice instance ("NSI") used for one or multiple PDU sessions is no longer available, the network (e.g., AMF) may determine whether N1 SM information can be exchanged between the network (e.g., SMF) and the UE. In such embodiments, the following may apply: if N1 SM information can be exchanged, the network initiates a network-triggered PDU session release procedure with an appropriate cause value for the impacted PDU sessions; or if N1 SM information cannot be exchanged (e.g., a new AMF is not a part of the network slice instances for the no longer available network slices), or the UE is in IDLE state (i.e., there is no need to page the UE in order to exchange N1 SM signaling), the serving AMF initiates autonomous release of the UE's SM context in the SMF, UPF, and/or PCF. In such embodiments, the new AMF may indicate to the old AMF which S-NSSAI or which PDU sessions cannot be served any longer. Moreover, the old AMF may inform the corresponding SMFs to autonomously release the UE's SM context. Furthermore, the PDU sessions context may be implicitly released in the UE after receiving allowed NSSAI in a registration accept message.

<FIG> is a schematic block diagram illustrating one embodiment of communications <NUM> to facilitate indicating packet data unit sessions as unavailable. Specifically, <FIG> shows one embodiment of communications <NUM> applied to a UE in CM-IDLE state performing a registration procedure due to mobility. Moreover, in the illustrated embodiment, it is assumed that the registration procedure results in an AMF change. It should be noted that the terms "new AMF" and "target AMF" (e.g., T-AMF) mean the same thing. Similarly, the terms "old AMF" and "source AMF" (e.g., S-AMF) mean the same thing. In various embodiments, if SMF and/or UPF relocation is needed during a mobility procedure, the SMF and/or UPF relocation may be performed by a session and service continuity ("SSC") mechanism.

The communications <NUM> include communication between a UE <NUM>, a RAN <NUM>, a new AMF <NUM>, an old AMF <NUM>, an SMF <NUM>, a UPF <NUM>, an NSSF <NUM>, and a UDM <NUM>. However, in other embodiments, the communications may be between different devices.

In certain embodiments, a first communication <NUM> transmitted from the UE <NUM> to the RAN <NUM> may include an NAS registration request message. In various embodiments, the NAS registration request message may include a UE ID, a registration type (e.g., mobility type), and/or a requested NSSAI. In one embodiment, the NAS registration request message may be transmitted by RRC signaling. In such embodiments, the RRC signaling may include a requested NSSAI.

In some embodiments, the RAN <NUM> may select <NUM> an AMF by performing an AMF selection procedure based on a RRC UE ID and requested NSSAI. In such embodiments, it may be assumed that the RAN <NUM> cannot reach the old AMF <NUM>, so the RAN <NUM> performs a new AMF selection considering the requested NSSAI parameter sent from the UE <NUM>.

In some embodiments, a second communication <NUM> transmitted from the RAN <NUM> to the new AMF <NUM> may include a forwarding of the NAS registration request message to the selected new AMF <NUM>.

In various embodiments, a third communication <NUM> transmitted from the new AMF <NUM> to the old AMF <NUM> may include the new AMF <NUM> retrieving the UE's <NUM> context from the old AMF <NUM>. In certain embodiments, if the UE <NUM> has used the UE temporary ID (e.g. GUTI) in the registration request message, the new AMF <NUM> uses the GUTI to select the old AMF <NUM>. In some embodiments, the new AMF <NUM> may forward the complete registration request message to the old AMF <NUM>. In various embodiments, the third communication <NUM> may include an information request message and/or a UE context request message.

In certain embodiments, a fourth communication <NUM> transmitted from the old AMF <NUM> to the new AMF <NUM> may include the old AMF <NUM> sending the UE's context to the new AMF <NUM> (e.g., using an information response message or a UE context response message). In various embodiments, the UE's context may include a global UE subscription ID (e.g., subscriber permanent identifier ("SUPI"), a UE mobility management ("MM") context (e.g., allowed NSSAI in the old registration area, mobility restrictions, UE capabilities, etc.), and/or SMF information. In certain embodiments. SMF information may include UE session related context (e.g., PDU session IDs and corresponding S-NSSAIs and SMF IDs). In various embodiments, the new AMF <NUM> may verify whether the requested NSSAI are permitted based on the subscribed NSSAI from the UE's context.

In some embodiments, a fifth communication <NUM> (optional communication) includes one or more messages transmitted between the new AMF <NUM> and the NSSF <NUM>. In certain embodiments, if the new AMF <NUM> determines (e.g., based on network configuration and policies) that it can serve the UE <NUM> (e.g., it can serve all S-NSSAIs from the requested NSSAI), the new AMF <NUM> may compose allowed NSSAI and skip communications <NUM> through <NUM>. In various embodiments, if the new AMF <NUM> determines that it may not serve all S-NSSAIs from the requested NSSAI based on AMF-internal configuration, the new AMF <NUM> may query the NSSF for network slice instance ("NSi" or "NSI") resolution.

In certain embodiments, the new AMF <NUM> may determine <NUM> NSSAI. In various embodiments, the new AMF <NUM> may determine <NUM> (based on existing UE context, internal configuration, and/or on information exchanged with the NSSF) that for one or more S-NSSAI from the requested NSSAI there is no corresponding available NSi. In some embodiments, the reason for unavailable NSi may be: NSi unavailable in the new registration area; the slice (characterize by the S-NSSAI) is available in the new registration area, but require a different AMF (meaning that some S-NSSAIs of the Requested NSSAI are not co-existing); or the S-NSSAI is not available at this time of day, etc. In certain embodiments, a particular S-NSSAI may be temporary rejected. In various embodiments, the new AMF <NUM> may determine the allowed NSSAI in the current registration area. In such embodiments, the allowed NSSAI may include a subset of the allowed NSSAI in the old registration area. Moreover, the new AMF <NUM> may compare the allowed NSSAI in the new RA with the S-NSSAIs (and corresponding PDU Sessions) used in the old RA. In some embodiments, if the new AMF <NUM> determines that one or more of the S-NSSAIs used in the old RA are not available in the new RA, the new AMF <NUM> may initiate signaling to indicate autonomous release of UE's SM context in the corresponding SMFs.

In certain embodiments, if the new AMF <NUM> can reach one or more SMFs used for the one or more PDU sessions associated with the unavailable S-NSSAI, the new AMF <NUM> may initiate procedures to these one or more SMFs to release the UE's context in the SMF autonomously (e.g., the SMF does not need to perform a PDU session release procedure with the UE). In certain embodiments, the new AMF <NUM> may initiate an N11 release request procedure for the concerned PDU session with an indication for implicit release. In such embodiments, after receiving the request from the new AMF <NUM>, the SMF may delete the UE's PDU session context and the related states in the UPF autonomously (e.g., allocated IP address and/or prefixes) without sending N1 SM information to the UE (e.g., PDU session release request or PDU session release command). In various embodiments, if the new AMF <NUM> cannot reach the one or more SMFs used for the one or more PDU sessions associated with the unavailable S-NSSAI, the new AMF <NUM> may include the communications <NUM> through <NUM>. In some embodiments, if the slice co-existence rules are not met by the S-NSSAI from the requested NSSAI, then the new AMF <NUM> may provide in a registration accept message: an error indication that incompatible S-NSSAIs were included in the requested NSSAI; network slices coexistence information for each one of the subscribed S-NSSAIs in the PLMN; and/or the allowed NSSAI for this registration area optionally the available S-NSSAIs.

In various embodiments, a sixth communication <NUM> transmitted from the new AMF <NUM> to the old AMF <NUM> may include a registration complete notify message. In one embodiment, if the new AMF <NUM> determines that one or more of the S-NSSAIs used in the previous RA (e.g., in the old RA) cannot be served currently (e.g., in the current RA), the new AMF <NUM> determines that established PDU sessions cannot be supported in the new RA. In such an embodiment, the new AMF <NUM> may determine based on its configuration that it is not able to directly reach the SMF <NUM> from the network slice instance which is not any more available. For example, the new AMF <NUM> may be configured to be a part of a list of NSIs it serves and the new AMF <NUM> may determine that the SMF's <NUM> NSI (as per unavailable S-NSSAI) is not part of the new AMF's <NUM> NSI list. Accordingly, in the sixth communication <NUM>, the new AMF <NUM> may initiate a procedure (e.g., an existing registration complete notify message or a new notification message) towards the old AMF <NUM> to indicate that particular PDU sessions (e.g., characterized by PDU session IDs) and/or particular corresponding S-NSSAI) cannot be served in the current and/or target registration area. Furthermore, the new AMF <NUM> may indicate to the old AMF <NUM> that the PDU sessions need to be released and/or deleted autonomously via communication between the old AMF <NUM> and the SMF <NUM> and/or UPF <NUM>. In some embodiments, the sixth communication <NUM> may be implemented as a protocol message (e.g., based on interface signaling exchange) or as invoking a service operation offered by the new AMF <NUM> (e.g., based on service based architecture "SBA"). In various embodiments, the following implementations may be used: an N14 registration complete notify message (including a cause); an N11 session release request message (e.g., including: PDU session ID for release, unavailable S-NSSAI, release cause, release type, and/or autonomous indicator) per PDU session to be released; a slice release request message (e.g., including: unavailable S-NSSAI, PDU session ID, and/or release cause) per S-NSSAI which is unavailable in the current RA; and/or Namf_Communication_RegistrationCompleteNotify service operation (e.g., including: UE <NUM> ID and/or cause). In certain embodiments, the "cause," "release cause," "Release Type" value of the above messages may indicate that the PDU sessions need to be released and/or deleted autonomously towards the related SMFs, UPFs, and/or PCF. For example, the new AMF <NUM> may invoke the Namf_Communication_RegistrationCompleteNotify service operation with the new AMF <NUM> including an indication of which particular PDU sessions cannot be served in the target RA, a cause value for autonomous UE's <NUM> SM context release, and the UP resources.

In certain embodiments, a seventh communication <NUM> (optional communication) between the new AMF <NUM> and the SMF <NUM> may be transmitted instead of the sixth communication <NUM>. In such embodiments, the new AMF <NUM> is able to directly reach the SMF <NUM> from the network slice instance which is no longer available, therefore, the new AMF <NUM> notifies the SMF <NUM> that the UE's <NUM> SM context for the determined PDU sessions should be released. In some embodiments, the new AMF <NUM> may indicate to the SMF <NUM> whether the UE <NUM> is reachable (e.g., in the CM-CONNECTED state) so that the SMF <NUM> may perform explicit N1 SM exchange for PDU session release. If the UE <NUM> is in the CM-IDLE state (or due to other reasons such as a configuration that does not page the UE <NUM> in order to exchange N1 SM signaling), the new AMF <NUM> may indicate to the SMF <NUM> that the UE's <NUM> SM context may be autonomous and/or implicit released in the SMF <NUM> without N1 SM information exchange. If the seventh communication <NUM> is used, then the eighth communication <NUM> is not used and the ninth communication <NUM> is used. In various embodiments, the seventh communication <NUM> may be performed as: an N11 release SM request message (e.g., including: UE <NUM> ID, PDU session ID, release cause, and/or release type); Nsmf_PDUSession_UpdateSMContext (e.g., including: UE <NUM> ID, PDU session ID, and/or update type); and/or Nsmf_PDUSession_Release (e.g., including: UE <NUM> ID, PDU session ID, and/or release cause). In the above messages, the UE ID may be SUPI, for example. In certain embodiments, the parameter or informational element ("IE") "release cause," "release type," or "update type" may indicate either: autonomous release and/or delete of the UE's <NUM> context in the SMF <NUM>, UPF <NUM>, and/or PCF; or that explicit release (e.g., using N1 SM exchange for PDU session release) is possible. In certain embodiments, the seventh communication <NUM> may include a request and response message exchange with the old AMF <NUM>. For example, the SMF <NUM> may respond to the old AMF <NUM> in response to the reception of the N11 release SM context request message and/or the deletion of the UE's <NUM> SM context. In such embodiments, the old AMF <NUM> may invoke an Nsmf_SMContext_Release service operation with the SMF <NUM> to release the UE's <NUM> SM context and the UP resources. In certain embodiments, if the UE <NUM> is in a CM-CONNECTED state, the new AMF <NUM> behavior and the SMF <NUM> behavior may be similar to the behavior described in the eighth communication <NUM>. In various embodiments, the new AMF <NUM> may indicate whether the UE <NUM> is in a CM-IDLE or the CM-CONNECTED state. If the UE <NUM> is in the CN-CONNECTED state and the PDU session which is to be released is activated (e.g., user plane resources are activated), the RAN <NUM> may be informed to deactivate and/or release corresponding DRBs to the PDU session. In such embodiments, the SMF <NUM> may send an N2 SM resource release request (e.g., including a PDU session ID) to the RAN <NUM> via the new AMF <NUM>. In some embodiments, autonomous and/or implicit PDU session release may mean omitting signaling from the SMF <NUM> to the RAN <NUM> (e.g., omitting the N2 SM resource release request to the RAN <NUM> via the new AMF <NUM>).

In some embodiments, an eighth communication <NUM> between the old AMF <NUM> and the SMF <NUM> may occur after the sixth communication <NUM>. In certain embodiments, based on the received unavailable S-NSSAI or PDU session ID for autonomous and/or implicit release, the old AMF <NUM> may determine to initiate release of N11 association and corresponding PDU sessions context in the network. In such embodiments, the old AMF <NUM> may initiate an N11 release SM context procedure towards the corresponding SMF <NUM> indicating that the PDU sessions should be released without sending N1 SM information to the UE <NUM> (e.g., to send PDU session release request or PDU session release command). In certain embodiments, this may mean that the SMF <NUM> autonomously releases the UE <NUM> SM context. For example, in various embodiments, the eighth communication <NUM> may be performed by the interface messages or services as described in the examples in the seventh communication <NUM>. In some embodiments, the eighth communication <NUM> may include a request and response message exchange. For example, the SMF <NUM> may respond to the old AMF <NUM> in response to the reception of the N11 release SM context request message and/or the deletion of the UE's <NUM> SM context. In such embodiments, the old AMF <NUM> may invoke an Nsmf_SMContext_Release service operation with the SMF <NUM> to release the UE's <NUM> SM context and the UP resources.

In various embodiments, a ninth communication <NUM> between the SMF <NUM> and the UPF <NUM> may include the SMF <NUM> (or SMFs) initiating release of the N4 association with the UPF <NUM> (or UPFs) which was used for the PDU sessions indicated by the old AMF <NUM>. In certain embodiments, this may include an N4 release procedure in order to delete the UE <NUM> states in the UPF <NUM> (e.g., allocated IP address and/or prefixes). In some embodiments, if there is an established session (e.g., IP connectivity access network "IP-CAN" session) between the SMF <NUM> and PCF, the SMF <NUM> may release this session with the PCF. In various embodiments, the SMF <NUM> may respond to the old AMF <NUM> to confirm the reception of the N11 release SM context request message and/or to confirm the completion of the implicit PDU session release procedure.

In certain embodiments, a tenth communication <NUM> (optional communication) transmitted from the old AMF <NUM> to the new AMF <NUM> may include the old AMF <NUM> confirming to the new AMF <NUM> that the PDU sessions corresponding to the unavailable S-NSSAI from either the sixth communication <NUM> or seventh communication <NUM> has been released in the old RA. In various embodiments, the old AMF <NUM> may include an indication of unavailable S-NSSAI and/or PDU session ID in a notify acknowledge message of the tenth communication <NUM>. In some embodiments, the notify acknowledge message may be a slice release response (e.g., including unavailable S-NSSAI and/or cause value). The cause value, in certain embodiments, may indicate success or completion of the request from either the sixth communication <NUM> or seventh communication <NUM>.

In some embodiments, an eleventh communication <NUM> between the new AMF <NUM> and the UDM <NUM> may include the new AMF <NUM> performing an update location procedure.

In various embodiments, a twelfth communication <NUM> transmitted from the UDM <NUM> to the old AMF <NUM> may include the UDM <NUM> performing a cancel location procedure with the old AMF <NUM> in order to delete the UE's <NUM> context in the old AMF <NUM>.

In certain embodiments, a thirteenth communication <NUM> transmitted from the new AMF <NUM> to the UE <NUM> may include the new AMF <NUM> sending a registration accept message to the UE <NUM> including: mobility parameters, a tracking area identifier ("TAI") list, allowed NSSAI, available NSSAI (or rejected S-NSSAI), and/or PDU session status. In various embodiments, the "PDU session status" may indicate to the UE <NUM> which PDU sessions are established in the network and/or which PDU sessions are activated. In certain embodiments, the UE <NUM> removes locally any internal resources related to PDU sessions that are not marked as established in the received PDU session status. In some embodiments, if slice coexistence rules are not met by the S-NSSAI from the requested NSSAI, the serving PLMN (e.g. AMF) may include a registration accept message. The registration accept message may include: an error indication that incompatible S-NSSAIs were included in the requested NSSAI; network slices coexistence information for each one of the subscribed S-NSSAIs in the PLMN; available S-NSSAIs identifying the network slices permitted by the serving PLMN for the current RA; and/or which S-NSSAIs are not possible to access using the new AMF <NUM>, but are possible to access in the current RA via another AMF.

In some embodiments, the UE <NUM> may release <NUM> one or more PDU sessions. In certain embodiments, if the PDU session status does not include one or more PDU session ID which are established in the UE <NUM>, the UE <NUM> may internally (e.g., implicitly) remove the PDU session context for these PDU sessions. Depending on further information about the allowed NSSAI or available NSSAI, the UE <NUM> may determine whether to initiate new PDU session establishment procedures with the same or different S-NSSAIs in order to allow connectivity for the applications using the released PDU sessions.

In various embodiments, a fourteenth communication <NUM> (optional communication) transmitted from the UE <NUM> to the new AMF <NUM> may include the UE <NUM> sending a registration complete message to the new AMF <NUM> (e.g., to confirm the reception of the GUTI change and the allowed NSSAIs).

In certain embodiments, the UE <NUM> may establish <NUM> new or modify existing PDU sessions. In some embodiments, the UE <NUM> may initiate a new PDU session establishment procedure and/or a PDU session modification over available slices.

As used herein, "N1 SM information" is one description for the messages or information exchanged between the SMF <NUM> and UE <NUM>. In some embodiments, the N1 SM information is sent transparently via the new AMF <NUM> and the RAN <NUM> encapsulated in NAS messages between the UE <NUM> and new AMF <NUM>. For example, the N1 SM information may be a PDU session release request message or a PDU session release command message.

As may be appreciated, <FIG> shows only dedicated CN entities which are not available in the new RA. However, network slice entities from other network slices are not shown, but such entities are available and the new AMF <NUM> also interacts with those entities to update the N11 association with the new AMF <NUM>.

<FIG> is a schematic block diagram illustrating another embodiment of communications <NUM> to facilitate indicating packet data unit sessions as unavailable.

<FIG> shows a particular example of how method described herein may be applied to a UE in a CM- CONNECTED state performing handover and/or registration procedures due to mobility. In certain embodiments, it may be assumed that an N2 -based handover procedure with AMF change is used. Furthermore, in some embodiments, it may be assumed that SMF1/UPF1 belong to a network slice instance which is not available in the target cell (e.g., which is served by a
target RAN ("T-RAN") and possibly in a new RA), while other network slice instances (e.g., as shown by SMF2/UPF2) are available in both an old RA and the new RA.

The communications <NUM> include communication between a UE <NUM>, a source RAN <NUM>, a target RAN <NUM>, a source AMF <NUM>, a target AMF <NUM>, an SMF1/UPF1 <NUM>, an SMF2/UPF2 <NUM>, an NSSF <NUM>, and a UDM <NUM>. However, in other embodiments, the communications may be between different devices.

In various embodiments, the UE <NUM> may prepare <NUM> for handover and perform part of the handover execution procedure. In certain embodiments, even if a direct interface between the source RAN <NUM> and the target RAN <NUM> is available (e.g., an X2 and/or Xn interface) the source RAN <NUM> may determine to perform an N2-based handover. In various embodiments, the target RAN <NUM> and/or the source RAN <NUM> may determine that not all network slice instances (e.g., characterized by S-NSSAI) are served in the target cell. In such embodiments, instead of an X2 handover and/or an Xn handover, the source RAN <NUM> may determine to perform an N2-based handover.

In certain embodiments, a first communication <NUM> transmitted from the source RAN <NUM> to the source AMF <NUM> may include the source RAN <NUM> sending a handover required message to the source AMF <NUM>. In various embodiments, the handover required message may include: a source to target transparent container; the target RAN <NUM> ID; a target RA code (e.g., from the target RAN <NUM>); a direct forwarding flag; and/or a RAN cause.

In some embodiments, a second communication <NUM> may be transmitted from the source AMF <NUM> to the target AMF <NUM>. In certain embodiments, the source AMF <NUM> may select the target AMF <NUM> based on an RA code of the target RAN <NUM> and based on the allowed NSSAI configured in the UE <NUM> in the old (source) RA. In various embodiments, as part of the second communication <NUM>, the source AMF <NUM> may send a relocation request message (e.g., the message may include source AMF <NUM> UE MM context (allowed NSSAI, PDU session IDs, SMF IDs, etc.), UE <NUM> session and/or SMF context, a source to target transparent container, a RAN cause, the target RAN <NUM> ID, a target RA code, and/or a direct forwarding flag).

In various embodiments, a third communication <NUM> (optional communication) may occur between the target AMF <NUM> and the NSSF <NUM>. In certain embodiments, the target AMF <NUM> may determine based on an internal configuration or based on interaction with the NSSF <NUM> whether the target AMF <NUM> may serve all S-NSSAI from the allowed NSSAI and which NSi to use for each S-NSSAI. In one embodiment, if the target AMF <NUM> determines that for one or more S-NSSAI from the allowed NSSAI there is no corresponding available NSi in the current area, the target AMF <NUM> may consider this during the derivation of allowed NSSAI for the target RA.

In some embodiments, the target AMF <NUM> may determine <NUM> NSSAI. In certain embodiments, the target AMF <NUM> may determine <NUM> the allowed NSSAI in the target RA. In various embodiments, in case of unavailable S-NSSAI from the old (source RA), the allowed NSSAI may include a subset of the allowed NSSAI in the old RA. In some embodiments, in order to determine the allowed NSSAI in the new RA, the target AMF may perform communication <NUM> as described in relation to <FIG> to check with NSSF about a more appropriate AMF and available network slice instances ("NSIs") in the area. In one example, the target AMF <NUM> may determine that a particular S-NSSAI used in the old RA is unavailable in the new RA. In various embodiments, the target AMF <NUM> may identify corresponding PDU sessions and corresponding SMFs. In one embodiment, the target AMF <NUM> may be able to determine the reachability of SMFs of the unavailable S-NSSAI (e.g., network slice instance cannot be used). In some embodiments, the target AMF <NUM> may determine that the target AMF <NUM> cannot reach SMF1/LTPF1 <NUM>.

In certain embodiments, a fourth communication <NUM> (optional communication) may be between the target AMF <NUM> and the SMF2/UPF2 <NUM>. In one embodiment, the target AMF <NUM> may determine whether an SMF change is needed for the supported S-NSSAIs in the new RA. In various embodiments, the target AMF <NUM> may determine that the SMF2/UPF2 <NUM> for the existing PDU session may be further used. In such embodiments, the target AMF <NUM> may perform a PDU handover request and/or response exchange towards the SMF2/UPF2 <NUM>. In some embodiments, the SMF2/UPF2 <NUM> may determine whether a UPF change is needed and may execute the UPF change.

In some embodiments, a fifth communication <NUM> transmitted from the target AMF <NUM> to the target RAN <NUM> may include the target AMF <NUM> sending a handover request message to the target RAN <NUM>. In certain embodiments, the handover request message may include N2 information, aggregate maximum bit rate ("AMBR") (which can be for the UE <NUM> and/or per access point name "APN"), an S1 application protocol ("AP") cause, a source to target transparent container, and/or a handover restriction list. In one embodiment, the handover request message may create the UE <NUM> context in the target RAN <NUM> including information about the PDU sessions (e.g., data radio bearers) and the security context. In some embodiments, for each PDU session, there may be UPF N3 tunnel information (e.g., tunnel endpoint ID ("TEID") for uplink N3), and PDU session QoS parameters. In such embodiments, if the direct forwarding flag indicates unavailability of direct forwarding and the target AMF <NUM> knows that there is no indirect data forwarding connectivity between the source AMF <NUM> and the target AMF <NUM>, the PDU session information may include an indication of "data forwarding not possible" for each PDU session. In some embodiments, if the target AMF <NUM> determines that some S-NSSAIs are unavailable in the new RA, the target AMF <NUM> may include allowed NSSAI in the N2 message to the target RAN <NUM> (e.g., handover request message). In various embodiments, the target AMF <NUM> may indicate to the target RAN <NUM> that the allowed NSSAI may be different from the RAN context in a source to target transparent container. In certain embodiments, the source to target transparent container may include AS context for all activated UP resources. In one embodiment, the target AMF <NUM> may not process the content of this RAN container. In various embodiments, other means are used to instruct the target RAN <NUM> that if the RAN container contains AS and/or UP context for bearers belonging to network slices (or PDU Sessions) which are not available in the target cell (or area), the target RAN <NUM> may not reserve (or assign) AS and/or UP resources for those bearers. In such embodiments, the target AMF <NUM> may include a new indication to the target RAN <NUM> indicating that the AS and/or UP context from the source RAN <NUM> differs from the allowed NSSAI in the target RA. For example, a new parameter or IE may be specified for this purpose.

In various embodiments, a sixth communication <NUM> transmitted from the target RAN <NUM> to the target AMF <NUM> may include the target RAN <NUM> confirming the reception and processing of the handover request message. In some embodiments, if the new parameter or IE from the target RAN <NUM> for allowed NSSAI differs from AS context (or allowed NSSAI) in the source RAN <NUM> has been received, the target RAN <NUM> may not consider establishing AS context for the bearers (e.g., data radio bearers "DRBs") from the source to target transparent container for which there is no matching to the S-NSSAI from the allowed NSSAI received from the target AMF <NUM>. In certain embodiments, the target RAN <NUM> may generate a target to source transparent container which may be sent to the source RAN <NUM>. In various embodiments, the target RAN <NUM> may consider during the generation of the target to source transparent container to include an indication to the source RAN <NUM> of which PDU sessions (e.g., which DRBs) may not be supported and/or established in the target cell. In such embodiments, the target RAN <NUM> may include in the target to source transparent container only information about the DRBs which will be established (e.g., based on the allowed NSSAI information received from the target AMF <NUM>).

In certain embodiments, a seventh communication <NUM> transmitted from the target AMF <NUM> to the source AMF <NUM> may include the target AMF <NUM> responding to the source AMF <NUM> with a relocation response message. The relocation response message may include a cause, a target to source transparent container, an SMF change indication, accepted PDU sessions, UP addresses, and/or TEIDs (e.g., N3, Xn, and/or X2 tunnel information). In various embodiments, if the target AMF <NUM> determines that the SMFs of the unavailable S-NSSAI are not reachable, then the target AMF <NUM> may include, in the relocation response message, an indication about the unavailable S-NSSAI (or optionally the related PDU session IDs). In one embodiment, the unavailable S-NSSAI indication may mean to the source AMF <NUM> that the target AMF <NUM> cannot reach the related SMFs with direct signaling.

In some embodiments, an eighth communication <NUM> may be made between the source AMF <NUM> and the SMF1/UPF1 <NUM>. In certain embodiments, if the target AMF <NUM> has included an indication about unavailable S-NSSAI in the relocation response message, the source AMF <NUM> may initiate a release procedure in the eighth communication <NUM> transmitted to the SMF1/UPF1 <NUM> serving the PDU sessions related to the unavailable S-NSSAI. In one embodiment, the source AMF <NUM> may determine the PDU sessions which should be implicitly released (e.g., released without N1 SM information signaling towards the UE <NUM>). In certain embodiments, the eighth communication <NUM> may include a request and/or a response message exchange. In some embodiments, the SMF1/UPF1 <NUM> may respond to the source AMF <NUM> indicating the reception of the N11 release SM context request message and/or the deletion of the UE's <NUM> SM context. In certain embodiments, after receiving an indication for autonomous and/or implicit PDU session release, the SMF1/UPF1 <NUM> may omit sending the N2 resource release request (e.g., including a PDU session ID) to the source RAN <NUM> over the source AMF <NUM>. If the source AMF <NUM> hasn't indicated autonomous and/or implicit PDU session release, then the SMF1/UPF1 <NUM> may send an N2 SM resource release request (e.g., including a PDU session ID) and N1 SM information (e.g., PDU session release command).

In various embodiments, a ninth communication <NUM> from the source AMF <NUM> to the source RAN <NUM> may include the source AMF <NUM> sending a handover command message to the source RAN <NUM>. In such embodiments, the handover command message may include a target to source transparent container, PDU sessions subject to forwarding, and/or PDU sessions to release. In certain embodiments, the PDU sessions subject to forwarding includes a list of UP addresses and TEIDs allocated for forwarding. Moreover, in one embodiment, the PDU sessions to release includes the list of PDU sessions to be released. Furthermore, in some embodiments, the target to source transparent container may contain information included by the target RAN <NUM> which PDU sessions (e.g., which DRBs) may not be supported and/or established in the target cell. In various embodiments, the source RAN <NUM> may learn which sessions and/or DRBs may be supported at the target cell and may use this information for further processing.

In certain embodiments, a tenth communication <NUM> transmitted from the source RAN <NUM> to the UE <NUM> may include the source RAN <NUM> sending the handover command message to the UE <NUM>. In one embodiment, the handover command message generated by the source RAN <NUM> may include information about the sessions and/or DRBs which may be established at the target cell (or target RAN <NUM>). In some embodiments, when generating the handover command message, the source RAN <NUM> may consider the target to source transparent containe" generated and sent from the target RAN <NUM>.

In various embodiments, the UE <NUM> may release <NUM> one or more PDU sessions. In certain embodiments, the UE <NUM> may determine which PDU sessions and corresponding DRBs should be released base on the PDU sessions to release indication in the handover command message. In one embodiment, the PDU sessions (e.g., including context in the NAS layer and AS layer, i.e., DRBs) may be released autonomously in the UE <NUM>.

In some embodiments, an eleventh communication <NUM> (optional communication) transmitted from the source RAN <NUM> to the target RAN <NUM> may include the source RAN <NUM> forwarding DL data towards the target RAN <NUM> for PDU sessions subject to data forwarding via direct forwarding.

In various embodiments, a twelfth communication <NUM> (optional communication) transmitted from the source RAN <NUM> to the SMF2/UPF2 <NUM> and a thirteenth communication <NUM> (optional communication) transmitted from the SMF2/UPF2 <NUM> to the target RAN <NUM> may include the source RAN <NUM> forwarding DL data towards the target RAN <NUM> for PDU sessions subject to data forwarding via indirect forwarding.

In various embodiments, a fourteenth communication <NUM> transmitted from the UE <NUM> to the target RAN <NUM> may include the UE <NUM> sending a handover confirm message to the target RAN <NUM>. In certain embodiments, downlink packets forwarded from the source RAN <NUM> may be sent to the UE <NUM>.

In some embodiments, a fifteenth communication <NUM> transmitted from the target RAN <NUM> to the target AMF <NUM> may include the target RAN <NUM> sending a handover notify message (e.g., including TAI plus E-UTRAN cell global identifier "ECGI" and/or local home network ID) to the target AMF <NUM>.

In certain embodiments, a sixteenth communication <NUM> between the source AMF <NUM> and the target AMF <NUM> may include the target AMF <NUM> sending a relocation complete message to the source AMF <NUM>. Moreover, in some embodiments, the source AMF <NUM> may, in response to receiving the relocation complete message, send a relocation complete acknowledge message to the target AMF <NUM>.

In various embodiments, a seventeenth communication <NUM> between the target AMF <NUM> and the SMF2/UPF2 <NUM> may include the target AMF <NUM> transmitting a PDU session modification procedure towards the UMF2/UPF2 <NUM> for the PDU session associated with the S-NSSAIs from the allowed NSSAI (e.g., for the PDU sessions which are successfully handed over). For example, in one embodiment, the target AMF <NUM> may send to the SMF2/UPF2 <NUM> a PDU session modification request message (e.g., UP target RAN <NUM> address and TEID allocated at the target RAN <NUM>) for each PDU session.

In some embodiments, an eighteenth communication <NUM> between the source RAN <NUM> and the source AMF <NUM> may include the source AMF <NUM> performing a N2 context release procedure toward the source RAN <NUM>. In various embodiments, the eighteenth communication <NUM> may be performed after a timer, which has been triggered after the sixteenth communication <NUM>, has expired. In such embodiments, the timer may be a guard time to enable forwarding packets from the source RAN <NUM> to the target RAN <NUM> without losses.

In certain embodiments, a nineteenth communication <NUM> (optional communication) between the source AMF <NUM> and the SMF2/UPF2 <NUM> may include deleting indirect forwarding.

In various embodiments, a twentieth communication <NUM> transmitted from the UE <NUM> to the target AMF <NUM>, a twenty-first communication <NUM> between the target AMF <NUM> and the UDM <NUM>, a twenty-second communication <NUM> transmitted from the target AMF <NUM> to the UE <NUM>, and a twenty-third communication <NUM> (optional communication) transmitted from the UE <NUM> to the target AMF <NUM> may include a registration procedure due to the change of registration area. In certain embodiments, the UE <NUM> sends an NAS registration request message to the target AMF <NUM> due to mobility. The NAs registration request message may include a UE <NUM> ID, a registration type (e.g., Mobility type), and/or requested NSSAI. In some embodiments, the NAS registration request message may be transmitted via RRC signaling. In one embodiment, during the registration procedure, allowed NSSAI may be assigned to the UE <NUM> for the new RA as described herein. In certain embodiments, the UE <NUM> may establish <NUM> new or modify existing PDU sessions.

In another embodiment, during a handover procedure the UE <NUM> in CM-CONNECTED state or the network (e.g., SMF) may initiate N1 SM signaling for any PDU session which cannot be used in the target RA. In various embodiments, registration signaling exchange may happen after the handover procedure is completed, so N1 SM signaling for the unavailable PDU session may fail if the signaling is performed during the handover procedure and before the UE <NUM> receives a registration accept message (e.g., carrying the new allowed NSSAI). In some embodiments, the UE <NUM> and the network (e.g., the serving AMF) may block the N1 SM signaling as long as the handover procedure with the new RA (and corresponding RM procedure) is completed. For example, at the UE <NUM> side, the NAS message carrying N1 SM information may not be processed by the RRC layer. In certain embodiments, the RRC layer may indicate to the NAS layer that the N1 SM information messages for any PDU session are temporary not possible to be transmitted. In various embodiments, after the reception of the registration accept message, the UE <NUM> (e.g., NAS registration management "RM" and/or MM layer) may be able to determine whether to continue with the transmission of the N1 SM information or to discard the message. As another example, at the network side, the AMF (e.g., the old AMF) receiving the N1 SM information from any SMF may determined that during the handover procedure the N1 SM information is temporary not sent to the UE <NUM>. In one embodiment, the AMF may respond with the N11 message (carrying the N1 SM message to the UE <NUM>) to the SMF indicating to the SMF that the N1 SM message temporarily cannot be transmitted. In such an embodiment, the SMF may wait for a particular time (based on timer) or wait until a new AMF performs a PDU session handover procedure.

<FIG> is a schematic block diagram illustrating a further embodiment of communications <NUM> to facilitate indicating packet data unit sessions as unavailable. In various embodiments described in relation to <FIG>, a change in a set of network slices for a particular UE <NUM> may be triggered by: a change of a user's subscription (and thus triggered by the UDM <NUM> and/or HSS); or a change of the network configuration (and thus triggered by the OAM system). In such embodiments, the UE <NUM> may not move, but the change of the set of network slices may happen due to other events (e.g., triggered by the UDM <NUM> and/or HSS or triggered by the OAM system).

The communications <NUM> include communication between a UE <NUM>, a RAN <NUM>, an AMF <NUM>, an SMF <NUM>, a UPF <NUM>, an OAM <NUM>, an NSSF <NUM>, and a UDM <NUM>. However, in other embodiments, the communications may be between different devices.

In certain embodiments, a first communication <NUM> transmitted from the UDM <NUM> to the AMF <NUM> may include information used to trigger a UE <NUM> subscription update in response to a change in a network configuration. In some embodiments, the information may include a parameter (e.g., time guard) used to indicate when the subscription update should be performed (e.g., immediately, at a predetermined time, starting at a selected time and/or date).

In some embodiments, a second communication <NUM> transmitted from the OAM <NUM> to the AMF <NUM> may include information used to trigger a UE <NUM> subscription update in response to a change in a user's subscription. In various embodiments, the OAM <NUM> may determine to turn off a network slice instance. In some embodiments, the information may include a parameter (e.g., time guard) used to indicate when the subscription update should be performed (e.g., immediately, at a predetermined time, starting at a selected time and/or date).

In various embodiments, a third communication <NUM> (optional communication) may occur between the AMF <NUM> and the NSSF <NUM>. In some embodiments, the third communication <NUM> may include information similar to the fifth communication <NUM>.

In certain embodiments, the AMF <NUM> may determine <NUM> NSSAI. In various embodiments, the AMF <NUM> may determine <NUM> (based on existing UE context, internal configuration, and/or on information exchanged with the NSSF) that for one or more S-NSSAI from the requested NSSAI there is no corresponding available NSi. In some embodiments, the reason for unavailable NSi may be: NSi unavailable in the new registration area; the slice (characterize by the S-NSSAI) is available in the new registration area, but require a different AMF (meaning that some S-NSSAIs of the Requested NSSAI are not co-existing); or the S-NSSAI is not available at this time of day, etc. In certain embodiments, a particular S-NSSAI may be temporary rejected. In various embodiments, the AMF <NUM> may determine the allowed NSSAI in the current registration area. In such embodiments, the allowed NSSAI may include a subset of the allowed NSSAI in the old registration area. Moreover, the AMF <NUM> may compare the allowed NSSAI in the new RA with the S-NSSAIs (and corresponding PDU Sessions) used in the old RA. In some embodiments, if the AMF <NUM> determines that one or more of the S-NSSAIs used in the old RA are not available in the new RA, the AMF <NUM> may initiate signaling to indicate autonomous release of UE's SM context in the corresponding SMFs.

In various embodiments, a fourth communication <NUM> may be transmitted from the AMF <NUM> to the SMF <NUM>. In some embodiments, the fourth communication <NUM> may include information similar to the seventh communication <NUM>. In certain embodiments, the fourth communication <NUM> may include part of a request from the AMF <NUM> to the SMF <NUM>. In various embodiments, the AMF <NUM> may be able to contact the SMF <NUM> (e.g., assuming that a guard time described in the first communication <NUM> and/or the second communication <NUM> available). In such embodiments, the AMF <NUM> does not need to determine whether the SMF <NUM> (or SMFs) serving the established PDU sessions is reachable, as it is implicitly assumed that the SMF <NUM> is reachable (at least for the time indicated the first communication <NUM> and/or the second communication <NUM>). In some embodiments, the AMF <NUM> may determine the indication for autonomous release or explicit release of the PDU sessions based on the connection management ("CM") state of the UE <NUM> (e.g., whether the UE <NUM> is in CM-IDLE state or CM-CONNECTED state). For example, if the UE <NUM> is in CM-IDLE state, the AMF <NUM> may determine to initiate autonomous and/or implicit PDU session release. In contrast, if the UE <NUM> is in CM-CONNECTED state, the AMF <NUM> may determine to initiate PDU session release. In various embodiments, the exchange of explicit N1 SM signaling may not result in additional signaling like paging and/or service request procedures.

In certain embodiments, a fifth communication <NUM> between the SMF <NUM> and the UPF <NUM> may be similar to the ninth communication <NUM>.

In some embodiments, a sixth communication <NUM> transmitted from the SMF <NUM> to the AMF <NUM> may be similar to the seventh communication <NUM>. In various embodiments, the sixth communication <NUM> may only include information transmitted from the SMF <NUM> to the AMF <NUM>.

In certain embodiments, the UE <NUM> may complete <NUM> registration and establish new and/or modify existing PDU sessions. In some embodiments, the UE <NUM> may initiate a new PDU session establishment procedure and/or a PDU session modification over available slices. In various embodiments, the UE <NUM> may complete <NUM> the registration using communications similar to the thirteenth communication <NUM> and the fourteenth communication <NUM>. Moreover, the UE <NUM> may release one or more PDU sessions similarly to the release <NUM>.

<FIG> is a schematic flow chart diagram illustrating one embodiment of a method <NUM> for indicating packet data unit sessions as unavailable. In some embodiments, the method <NUM> is performed by an apparatus, such as the network function <NUM> (e.g., AMF). In certain embodiments, the method <NUM> may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

The method <NUM> may include determining <NUM> that at least one packet data unit session is unavailable. In various embodiments, the method <NUM> includes transmitting <NUM> information indicating that the at least one packet data unit session is to be released.

In one embodiment, the method <NUM> includes determining whether a network function is able to communicate with a session management function used for the at least one packet data unit session. In a further embodiment, the method <NUM> includes, in response to determining that the network function is able to communicate with the session management function, transmitting the information indicating that the at least one packet data unit session is to be released, and the information indicates to release the at least one packet data unit session. In certain embodiments, the information indicates that the at least one packet data unit session is to be released without notifying a corresponding remote unit. In various embodiments, the information indicates that the at least one packet data unit session is to be released with notification given to a corresponding remote unit. In some embodiments, the method <NUM> includes, in response to determining that the network function is unable to communicate with the session management function, transmitting the information indicating that the at least one packet data unit session is unavailable to a prior network function. In certain embodiments, the information indicates an identification of the at least one packet data unit session.

In various embodiments, the information indicates that the prior network function is to release the at least one packet data unit session. In some embodiments, the prior network function determines based on the information whether to initiate release of the at least one packet data unit session. In certain embodiments, the prior network function communicates with the session management function to release the at least one packet data unit session, and the at least one packet data unit session is released without providing notification to a remote unit corresponding to the at least one packet data unit session. In one embodiment, the method <NUM> includes receiving feedback indicating that the prior network function released the at least one packet data unit session. In various embodiments, the method <NUM> includes transmitting a message to a remote unit indicating enabled network slice selection assistance information. In some embodiments, the method <NUM> includes transmitting a message to a remote unit indicating available packet data unit sessions.

<FIG> is a schematic flow chart diagram illustrating one embodiment of a method <NUM> for indicating packet data unit sessions as unavailable. In some embodiments, the method <NUM> is performed by an apparatus, such as the network function <NUM> (e.g., SMF). In certain embodiments, the method <NUM> may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

The method <NUM> may include receiving <NUM> information indicating to release at least one packet data unit session. In various embodiments, the method <NUM> includes determining <NUM> whether to send explicit signaling to a remote unit for releasing the at least one packet data unit session. In certain embodiments, the method <NUM> includes releasing <NUM> the at least one packet data unit session in response to receiving the information.

In one embodiment which is not a part of the claimed invention, the method <NUM> includes transmitting feedback indicating that the at least one packet data unit session is released. In a further embodiment, the method <NUM> includes transmitting a message to the remote unit indicating that the at least one packet data unit session is released.

Claim 1:
A method (<NUM>) performed by an Access and Mobility Management Function, AMF (<NUM>), the method comprising:
receiving (<NUM>), from a Unified Data Management, UDM, (<NUM>) information used to trigger a UE (<NUM>) subscription update in response to a change in a network configuration;
determining (<NUM>) that one or more Single Network Slice Selection Assistance Information, S-NSSAI, from a current allowed Network Slice Selection Assistance Information, NSSAI, are not available for the UE (<NUM>);
determining a new allowed NSSAI in a current registration area; and
initiating signalling to a corresponding Session Management Function, SMF, (<NUM>) to indicate release of the UE (<NUM>) Session Management context in the corresponding SMF (<NUM>).