Patent Description:
The document "<NPL>, proposes a solution how to transfer Network Slice Selection Assistance information, NSSAI, between User Equipment, UE, and a Non-3GPP Interworking Function, N3IWF, for an Untrusted WLAN scenario. The document proposes to transfer this information in Internet Key Exchange Version <NUM>, IKEv2, signaling during a registration phase.

The document "<NPL>, proposes to add network slicing support for non-3GPP access to the <NUM> Core Network.

The invention is as set out in the appended independent claims. Advantageous refinements are defined in the dependent claims.

A detailed description of illustrative embodiments will now be described with reference to the various Figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.

The full duplex radio may include an interference management unit <NUM> to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor <NUM>).

While each of the foregoing elements is depicted as part of the CN <NUM>, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.

While each of the foregoing elements is depicted as part of the CN <NUM>, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.

For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different Protocol Data Unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like.

In view of <FIG>, and the corresponding description of <FIG>, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME <NUM>, SGW <NUM>, PGW <NUM>, gNB 180a-c, AMF 182a-ab, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown).

Fifth generation (<NUM>) wireless communication systems may support diverse use cases with different requirements using the same physical infrastructure. A <NUM> wireless communication system may be implemented, for example, using network slicing, which may virtually partition a network into multiple logical slices. A (e.g., each) slice may be associated with (e.g., specific) network capabilities and characteristics that may cater to requirements of one or more use cases. Different WTRUs may be accessed and/or may be assigned different network slices depending on their capabilities and requested services.

A (e.g., <NUM>) network may permit a WTRU (e.g., UE) to discover slices that may be supported by the network. In an example, a network slice in a 3rd Generation Partnership Project (3GPP) network may be identified with a Single Network Slice Selection Assistance information (S-NSSAI). An S-NSSAI may comprise, for example, (i) a Slice/Service type (SST), which may refer to expected Network Slice behavior (e.g., in terms of features and services) and (ii) a Slice Differentiator (SD), which may refer to (e.g., optional) information that may complement Slice/Service type(s), e.g., to differentiate amongst multiple Network Slices of the same Slice/Service type. Information regarding a network slice may be generally referred to as NSSAI and/or S-NSSAI herein (and vice versa). There may be various types of NSSAI used for various purposes.

A WTRU may be configured to provide information to assist with selection of an Access and Mobility Management Function (AMF), for example using NSSAI.

A WTRU may be configured by a home Public Land Mobile Network (PLMN) with slicing information, e.g., with a Configured NSSAI per PLMN. A Configured NSSAI may be PLMN-specific. A home PLMN (HPLMN) may indicate one or more applicable PLMN(s) for a (e.g., each) Configured NSSAI.

A WTRU may provide a Requested NSSAI to a network (e.g., upon registration). A WTRU in a PLMN may (e.g., only) use S-NSSAls that may belong to a Configured NSSAI, if any, of that PLMN.

A WTRU may (e.g., upon successful completion of a WTRU's Registration procedure) obtain (e.g., from an AMF) an Allowed NSSAI for a PLMN, which may include one or more S-NSSAls. S-NSSAls may be valid for a current Registration Area (e.g., that a WTRU has registered with) that may be provided by a serving AMF. Multiple S-NSSAls may be used simultaneously by a WTRU. A received Allowed NSSAI may (e.g., from a WTRU perspective) overwrite a Configured NSSAI associated with a PLMN.

A WTRU may (e.g., during registration) include a Requested NSSAI at Radio Resource Control (RRC) Connection Establishment and in Non-Access Stratum (NAS) messages. A RAN may route NAS signaling between a WTRU and an AMF. An AMF may be selected, for example, using a Requested NSSAI that may be obtained during RRC Connection Establishment. A RAN may route NAS signaling to an AMF from a set of default AMFs, for example, when the RAN may be unable to select an AMF based on a Requested NSSAI.

A WTRU may access a NextGen Core, for example, via non-3GPP access. A Non-3GPP Interworking Function (N3IWF) may provide or support one or more of the following functions: (i) support IPsec tunnel establishment with a WTRU (e.g., N3IWF may terminate IKEv2/IPsec protocols with a WTRU over NWu and may relay over N2 information to authenticate a WTRU and authorize its access to a <NUM> Core Network); (ii) termination of N2 and N3 interfaces to a <NUM> Core Network for Control-Plane and user-plane, respectively; (iii) relay uplink and downlink control-plane NAS (e.g., N1) signaling between WTRU and AMF; (iv) handle N2 signaling from SMF (e.g., relayed by AMF) related to PDU sessions and QoS; (v) establish IPsec Security Association (IPsec SA) to support PDU Session traffic; (vi) relay uplink and downlink user-plane packets between WTRU and UPF (e.g., De-capsulation/Encapsulation of packets for IPSec and N3 tunnelling); (vii) enforce QoS corresponding to N3 packet marking (e.g., taking into account QoS requirements that may be associated with such marking received over N2); (viii) N3 user-plane packet marking in the uplink; (ix) local mobility anchor within untrusted non-3GPP access networks (e.g., using IKEv2 Mobility and Multihoming Protocol (MOBIKE)) and/or (x) support AMF selection. The N31WF may be implemented as a standalone network node or server or may be co-located with one or more other network functions or gateways.

N3IWF may be an interface between non-3GPP access and the 3GPP <NUM> Core Network. The N3IWF might be an interface towards 3GPP RAN over an Xn interface.

NSSAI may be registration area specific. A WTRU may request or demand different types of slices from a network. Selection of a set of network slice instances for a WTRU in a 3GPP <NUM> network may be triggered, for example, by the first AMF that may be contacted in a registration procedure, which may lead to a change in AMF. A (e.g., <NUM>) network may provide inter-working or coordination between cellular network and other RATs, e.g., 3GPP and non-3GPP (e.g., WiFi). Cross-RATs network slicing capability advertisement (e.g., notification of available slices) may be implemented, for example, with coordination between 3GPP and non-3GPP access technologies. Registration Areas (e.g., a set of Tracking Areas where one or more WTRUs may be registered) may be (e.g., independently) assigned and distinct, e.g., as between 3GPP and Non-3GPP access. NSSAls may be Registration Area specific.

A WTRU attached to a non-3GPP access network may send a message to one or more network entities (e.g., N3IWF) to determine what slices may be available in a 3GPP access network. A WTRU attached to a 3GPP network may acquire information relating to slice availability in a nearby non-3GPP network by requesting such information from one or more network entities (e.g., AMF). Network slicing capability (e.g., in a 3GPP network) may be different among multiple PLMNs and/or amongst different registration areas. A RAN may (e.g., during RRC Connection Establishment) route NAS signaling to an AMF from a set of default AMFs, for example, when the RAN may be unable to select an AMF based on a Requested NSSAI. In some instances, a WTRU may be unable (e.g., without going through a Registration procedure) to re-select AMF in other PLMNs where desired network slices may be available.

WTRUs may obtain information about available network slices across distinct Access Networks (e.g., to provide awareness of network slice availability on 3GPP access while connected to a non-3GPP access and/or vice versa).

Information may be advertised/broadcast (e.g., in 3GPP access stratum, for example using system information) about network slicing capabilities that may be available at non-3GPP accesses.

N3IWF may provide information (e.g., during an association procedure such as through a Generic Advertisement Service (GAS)) about network slicing capabilities that may be available at a 3GPP access.

A RAN may select a PLMN (e.g., and AMF) and/or a Registration Area that may be (e.g., is/are) capable of fulfilling network slicing requests from a WTRU, for example, based on knowledge from the RAN about multiple subscriptions of the WTRU.

A WTRU may be configured to request and/or receive network slicing advertisement information (e.g., information about available network slices for a 3GPP network), for example through non-3GPP access networks.

A WTRU may acquire information regarding an Allowed NSSAI, for example, upon registration with a 3GPP access network.

N3IWF may be utilized, for example, to disseminate information regarding one or more network slices. A 3GPP RAN may, for example, (e.g., periodically) exchange information (e.g., via interfaces such N2 and N3) with a N3IWF about network slicing capabilities. A RAN may have this information, for example, since it may be responsible for AMF selection during WTRU registration. This may be similar to multiple base stations sharing network slicing information (e.g., over an Xn interface). Information exchange may (e.g., also) occur between base stations (e.g., RAN) and N3IWF.

An N3IWF may convey information (e.g., acquired from a 3GPP RAN) to a WTRU, for example, over an IPsec tunnel (e.g., via IPv6 neighbor discovery messages, over ICMP, over DHCP, etc.).

<FIG> is an example of network slicing advertisement through untrusted non-3GPP access. <FIG> shows an example of how a WTRU may decide to register with a 3GPP RAN, for example, based on network slicing information that may be fetched from non-3GPP (e.g., WiFi) Access.

Example procedures are described with numeric references that do not limit this example or other examples to a particular order or number of activities (e.g., communication messages, analyses, determinations, selections and/or other activities). Examples presented and other examples may be implemented with any number and order of procedural activities, which may be the same or different (e.g., additional and/or alternative) relative to activities presented in examples.

At <NUM>, 201a, 201b, a 3GPP RAN may, for example, share (e.g., periodically and/or aperiodically) its network slicing capabilities with an N3IWF. For example, at <NUM> a 3GPP RAN may inform a N3IWF of network slicing capabilities by sharing slicing information, such as, for example, Available NSSAI (e.g., a set of one or more S-NSSAI for slice(s) that are available). At 201a, an AMF and a N3IWF may exchange network slicing capabilities information (e.g., Available NSSAI). At 201b, an AMF and a 3GPP RAN may exchange network slicing capabilities information (e.g., Available NSSAI). At <NUM>, 201a, 201b, information may be updated periodically. At <NUM>, 201a, 201b, information may be updated on a per-event basis. An N3IWF may, for example, store this information. Information may be (e.g., regularly) updated, for example, using (e.g., periodic and/or aperiodic) incoming information (e.g., from a 3GPP RAN). A <NUM> CN may (e.g., also) update gNBs and a N3IWF with information, e.g., regarding neighboring ANs. Dynamic Xn and NG-C (N2 TNL) interface Configuration procedures may (e.g., also) be used to transfer slicing capabilities, for example, between one or more gNBs and N3IWFs and/or between one or more <NUM> CNs and applicable ANs.

At <NUM>, a WTRU may (e.g., as it is powered on), for example, initially be associated with a non-3GPP (e.g., WiFi) access point for services. At 202a, 202b, Generic Advertisement Services (GAS) may be used, for example, to retrieve slicing information.

At <NUM>, a WTRU may, for example, establish an IPsec tunnel with an N3IWF, e.g., to receive information from the N3IWF. At 203a, 203b, 203c, a WTRU may, for example, use Extensible Authentication Protocol (EAP) to encapsulate slicing information between the WTRU and an N3IWF. This may be accomplished, for example, with a vendor-specific procedure that may use EAP packets with an "Expanded" type. In an example, a vendor-specific EAP procedure may comprise EAP-LWA, which may use an existing 3GPP vendor-id that may be registered with IANA (e.g., under an SMI Private Enterprise Code registry).

At <NUM>, an N3IWF may, for example, relay 3GPP RAN network slicing capability information (e.g., Available NSSAls (e.g., a set of one or more S-NSSAI for slice(s) that are available)) to a WTRU (e.g., via an established IPsec tunnel). An N3IWF may, for example, provide a list of Available S-NSSAI on a per Registration Area basis. Relaying of information may be periodic and/or aperiodic. In an example, (e.g., aperiodic) relaying may be triggered, for example, by one or more of the following: (i) an occurrence of one or more events; (ii) a request from a WTRU and/or (iii) a decision by a network.

Relaying of 3GPP RAN network slicing capability information may be triggered, for example, by one or more events. Examples of events that may trigger relaying may include, for example, one or more of the following: (i) a WTRU may move (e.g., to a specific location); (ii) a WTRU battery and/or WTRU mobility may reach a certain level or threshold; and/or (iii) a WiFi traffic level may reach a certain level or threshold.

An N3IWF may obtain information relating to occurrence(s) of one or more events, for example, via one or more Application Programming Interfaces (APIs) that may be capable of extracting context information for WiFi radio access and a WTRU. Context information may be, for example, in a virtualized computing platform (e.g., as part of "services" in a Multi-Access Edge Computing (MEC) architecture).

Relaying of 3GPP RAN network slicing capability information may be triggered, for example, by a request from a WTRU. In an example, a WTRU may send a request message to a WiFi Network, for example, when a desirable network slice may not be available. A request may be transported, for example, by IPv6 neighbor/router solicitations, DHCP requests, etc..

Relaying of 3GPP RAN network slicing capability information may be triggered, for example, by a network. A network decision may be made, for example, based on context information for WiFi radio access and/or for a WTRU. Context information may be extracted, for example, via one or more APIs (e.g., in a virtualized computing platform). Context information may be extracted, for example, as part of "services" in Multi-Access Edge Computing (MEC) architecture.

At <NUM>, a WTRU may, (based on received information, find that a 3GPP RAN may provide one or more network slices that may fit its requirement better. A WTRU (e.g., decides to) initiates a registration process with a 3GPP RAN (e.g., using a requested NSSAI). A requested NSSAI may be, for example, a subset of an available NSSAI (e.g., that may have been previously shared via an N3IWF). At <NUM>, the 3GPP RAN may select an AMF. At <NUM>, the WTRU may provide the requested NSSAI to the network.

Advertisement of network slicing capabilities may be available, for example, at non-3GPP access. A WTRU may attach to a 3GPP access network (e.g., directly) after it is powered on. A WTRU may request a set of network slices (e.g., Requested NSSAI), for example, from a 3GPP network (e.g., during registration process). A 3GPP RAN may (e.g., also) provide information (e.g., available NSSAI) to a WTRU. A WTRU (e.g., without available information) may be unable to obtain information about a network slicing capability of a (e.g., nearby) non-3GPP network. Information exchange between a 3GPP RAN and an N3IWF may (e.g., also) cover network slicing capability. A non-3GPP access network (e.g., WiFi) may (e.g., periodically or aperiodically) provide information (e.g., relating to its network slicing capabilities) to a 3GPP RAN (e.g., via an N3IWF). A 3GPP RAN may become aware of the availability of requested slices, for example, through an N3IWF, which may be reachable from the location of a WTRU (e.g., meeting end-to-end requirements of a slice). A RAN may, for example, embed information relating to network slicing capability of at least one non-3GPP network (e.g., that may be near a WTRU) in none or more signals, such RRC-Connection-ReConfiguration messages (e.g., during and/or after registration).

<FIG> is an example of network slicing advertisement about network slices that may be available through untrusted non-3GPP access. <FIG> shows an example procedure that a WTRU may use to obtain network slicing information of WiFi Access from 3GPP RAN.

In an example (e.g., at <NUM>), a 3GPP RAN may (e.g., periodically or aperiodically) fetch network slicing capabilities of a WiFi access network from an N3IWF. In an example (e.g., at 301a, 301b), NS capabilities (e.g., Available NSSAI) of a node in a Registration Area may be configured, for example, by a CN at an Access Network (AN) (e.g., 3GPP RAN/N3IWF).

At <NUM>, a WTRU may (e.g., as the WTRU may power on), for example, search for 3GPP RAN base stations (e.g., gNBs), which may be implemented, for example, based on received synchronization signals (e.g., PSS/SSS) and/or system information (e.g., MIB/SIBs). A WTRU may initiate an attachment process, for example, to commence network registration.

At <NUM>, a 3GPP RAN may (e.g., during a registration process), for example, transmit a message (e.g., for RRC connection setup). A message may comprise, for example, one or more of the following: (i) information that may relate to a network slicing capability of a non-3GPP access network and/or (ii) an N3IWF IP Address.

At <NUM>, a WTRU may (e.g., based on received information), for example, determine that non-3GPP access may provide one or more network slices that may fit its requirement better. A WTRU may decide to initiate attachment to a corresponding non-3GPP access network.

One or more S-NSSAI from a (e.g., only one) PLMN may limit possibilities for WTRUs (e.g., with multiple subscriptions) to find potential network slices from other subscribed PLMNs. Different PLMNs may (e.g., periodically and/or aperiodically) exchange information relating to their available NSSAI. A RAN belonging to a first PLMN may provide information regarding its available NSSAI to a WTRU and may (e.g., also) provide information regarding available NSSAI of a second PLMN.

<FIG> is an example of network slicing advertisement regarding network slices of other PLMNs.

In an example (e.g., as shown in <FIG>), a 3GPP RAN may belong to different PLMNs. At <NUM>, different PLMNs may, for example, (e.g., periodically or aperiodically (e.g., as information changes)) exchange information relating to their network slicing capabilities. In an example, a CN may (e.g., also) be involved in an exchange of network slicing capabilities.

At <NUM>, a WTRU (e.g., subscribing to a first PLMN and a second PLMN) may (e.g., as it is powered on), for example, search for 3GPP RAN base stations (e.g., gNBs) for its one or more subscribed PLMNs. This may be implemented, for example, based on received synchronization signals (e.g., PSS/SSS) and/or system information (e.g., MIB/SIBs). A WTRU may initiate an attachment process, for example, to commence network registration (e.g., with a first PLMN).

At <NUM>, a RAN belonging to a first PLMN may (e.g., during a registration process), for example, transmit a message (e.g., for RRC connection setup). A message may comprise, for example, one or more of the following: (i) an Available-NSSAI of a RAN belonging to the first PLMN and/or (ii) an Available-NSSAI of a RAN belonging to the second PLMN.

At <NUM>, a WTRU may (e.g., based on received information), for example, determine that a RAN belonging to the second PLMN may provide one or more network slices that may fit its requirement better. The WTRU may decide to initiate attachment to the RAN belonging to the second PLMN.

Systems, methods, and instrumentalities have been disclosed for advertising and selecting network slices across multiple access technologies (e.g., 3GPP and non-3GPP access) and multi-subscriber scenarios in <NUM>. WTRUs may, for example, obtain information about available network slices across distinct Access Networks, which may, for example, provide awareness of network slice availability for 3GPP access while connected to a non-3GPP access and vice versa. Information may be advertised/broadcast (e.g., in 3GPP access stratum) about network slicing capabilities that may be available at non-3GPP accesses. An N3IWF may provide information (e.g., during an association procedure) about network slicing capabilities that may be available at a 3GPP access. A RAN may select a PLMN (e.g., and AMF) and/or a Registration Area that may be capable of fulfilling one or more network slicing requests from a WTRU, e.g., based on knowledge from a RAN regarding multiple subscriptions of the WTRU.

<FIG> is an example of network slicing advertisement through non-3GPP access. At <NUM>, the WTRU may attach to a non-3GPP access network. At <NUM>, the 3GPP RAN may provide information to (e.g., share with) the N3IWF about network slicing capabilities. At <NUM>, the WTRU may establish a secure link (e.g., IPSec tunnel) with the N3IWF via the non-3GPP access network. At <NUM>, the WTRU may (e.g., prior to registering with that 3GPP network) request slicing information for the 3GPP cellular network from the N3IWF using the established secure link. At <NUM>, the WTRU may receive the slicing information for the 3GPP cellular network from the N3IWF. The WTRU may determine whether or not to register to the 3GPP cellular network (e.g., based on the received slicing information).

The processes and instrumentalities described herein may apply in any combination, may apply to other wireless technologies, and for other services.

A WTRU may refer to an identity of the physical device, or to the user's identity such as subscription related identities, e.g., MSISDN, SIP URI, etc. WTRU may refer to application-based identities, e.g., user names that may be used per application.

Each of the computing systems described herein may have one or more computer processors having memory that are configured with executable instructions or hardware for accomplishing the functions described herein including determining the parameters described herein and sending and receiving messages between entities (e.g., WTRU and network) to accomplish the described functions.

Claim 1:
A wireless transmit/receive unit (<NUM>), WTRU, comprising:
a memory (<NUM>); and
a processor (<NUM>) to execute instructions from the memory, wherein the processor (<NUM>) is configured to:
access (<NUM>, <NUM>) a non-3rd Generation Partnership Project, 3GPP, Access Network, AN;
establish (<NUM>, <NUM>) a link with a Non-3GPP Interworking Function, N3IWF, via the non-3GPP AN;
receive (<NUM>, <NUM>) information from the Non-3GPP Interworking Function about network slicing capabilities of a 3GPP Radio Access Network, RAN; and
initiate (<NUM>) a registration with the 3GPP RAN based upon the information about the network slicing capabilities of the 3GPP RAN.