Method and apparatus for non-seamless wlan offload interconnection between independent non-public networks

Abstract

In one embodiment, a user equipment forms a registration request comprising a modified network access identifier (NAI) indicating a cellular subscription of the user equipment and indicating an interconnection indication for causing a non-seamless WLAN offload (NSWO) interconnection from a first independent non-public network (SNPN) to a second SNPN; sending a registration request to the first SNPN; and receiving, after the registration request, an indication of a result of the registration request from the first SNPN. A mobility management entity of a first SNPN receives a registration request including a modified NAI, forms an authentication request, the authentication request including the modified NAI and an indication of a first SNPN name, sends the authentication request to a second SNPN, receives an authentication response from the second SNPN; and indicating a result of the registration request to the user equipment according to the authentication response.

Description

Technical Field

[0001] Various example implementations involve non-seamless WLAN offloading interconnection between independent, non-public networks. Background Technology

[0002] This section provides useful background information, but does not acknowledge that any technology described herein represents prior art.

[0003] Mobile communications have evolved from sparse proprietary systems with vast ranges to high-density public networks with increasingly smaller ranges for increased capacity. However, there are use cases for non-public systems or networks serving limited user groups. In some cases, interconnecting such non-public systems or providing connectivity to a Public Land Mobile Network (PLMN) via a Standalone Non-Public Network (SNPN) is advantageous. Non-Seamless WLAN Offloading (NSWO) interconnection allows for automatic changes to the NSWO used for radio access, but NSWO interconnection between SNPNs may not currently be supported. In this context, WLAN can refer to a wireless local area network backward compatible with IEEE 802.11 version a.

[0004] SNPN and NSWO are standardized or are being standardized in 3GPP for different 5G versions. These SNPN and NSWO are also expected to be available in next-generation 3GPP and other standards. In this document, 3GPP 5G can be considered as a baseline system being improved and is not intended to exclude other and subsequent systems compatible with the examples and aspects presented in this document. Summary of the Invention

[0005] The scope of protection sought for the various embodiments of the invention is defined by the independent claims. Embodiments and features described in this specification that are not within the scope of the independent claims (if any) should be interpreted as examples useful for understanding the various embodiments of the invention.

[0006] According to the first example aspect, an apparatus as defined in the appended claim 1 is provided.

[0007] According to the second example aspect, an apparatus as defined in the appended claim 4 is provided.

[0008] According to a third example aspect, an apparatus as defined in appended claim 8 is provided.

[0009] According to the fourth example aspect, a method as defined in appended claim 15 is provided.

[0010] According to the fifth example aspect, a method as defined in the appended claim 16 is provided.

[0011] According to the sixth exemplary aspect, a method as defined in appended claim 17 is provided.

[0012] According to the seventh exemplary aspect, an apparatus as defined in the appended claim 18 is provided.

[0013] According to the eighth exemplary aspect, an apparatus as defined in the appended claim 19 is provided.

[0014] According to the ninth exemplary aspect, an apparatus as defined in the appended claim 20 is provided.

[0015] According to the eleventh exemplary aspect, a computer program as defined in the appended claim 21 is provided.

[0016] According to the twelfth exemplary aspect, a non-transitory computer-readable medium as defined in the appended claim 22 is provided.

[0017] According to the thirteenth exemplary aspect, a computer-readable medium as defined in the appended claim 23 is provided.

[0018] According to the fourteenth exemplary aspect, a system as defined in the appended claim 24 is provided.

[0019] According to the fourteenth exemplary aspect, a system as defined in the appended claim 25 is provided.

[0020] Any of the aforementioned storage media may include digital data storage, such as data disks or floppy disks, optical storage, magnetic storage, holographic storage, opto-magnetic storage, phase-change memory, resistive random access memory, magnetic random access memory, solid-state electrolyte memory, ferroelectric random access memory, organic memory, or polymer memory. Storage media may be configured as a device without any other substantial function besides storage, or may be configured as part of a device with other functions, including but not limited to computer memory, chipsets, and sub-components of electronic devices.

[0021] Various non-limiting exemplary aspects and embodiments have been described in the foregoing. The embodiments described above are only for illustrating selected aspects or steps that can be utilized in implementation. Some embodiments may be presented with reference only to certain exemplary aspects of the invention. It should be understood that corresponding embodiments may also be applied to other exemplary aspects. Attached Figure Description

[0022] To gain a more complete understanding of the exemplary embodiments, reference is now made to the following description taken in conjunction with the accompanying drawings, wherein:

[0023] Figure 1 The process of an example embodiment is shown.

[0024] Figure 2A flowchart of a process in a user equipment according to an example embodiment is shown.

[0025] Figure 3 A simplified flowchart of the process in a mobility management entity for a first independent non-public network (SNPN) according to an example embodiment is shown.

[0026] Figure 4 A simplified flowchart of the process in the authentication entity for a second SNPN according to an example embodiment is shown; and

[0027] Figure 5 A block diagram of an apparatus according to an example embodiment is shown. Detailed Implementation

[0028] By referring to the attached diagram Figures 1 to 5 To understand the example embodiments and their potential advantages. In this document, the same reference numerals denote the same parts or steps.

[0029] Various example embodiments are operable in 3GPP systems, wherein the following combinations of features are provided according to example embodiments:

[0030] Support for non-seamless WLAN offloading

[0031] Non-Seamless Wireless LAN (WLAN) Offloading (NSWO) is an optional capability for User Equipment (UE) that supports WLAN radio access. UEs supporting NSWO can route specific data flows via the WLAN access without traversing the 5G core network (5GC) when connected to the WLAN access. For example, these UE data flows can be identified using a UE Routing Policy (URSP) configuration for NSWO or UE-local configurations as defined in Clauses 6.1.2.2 and 6.6.2 of 3GPP TS23.503 Release 18.3.0. For these data flows, the UE uses a local Internet Protocol (IP) address assigned by the WLAN access network, and there is no IP address reservation between the WLAN and the Next Generation Radio Access Network (NG-RAN).

[0032] To perform NSWO, the UE obtains a local IP address from the WLAN access network and does not need to connect to a non-3GPP Interoperability Function (N3IWF), Evolved Packet Data Gateway (ePDG), or Trusted Non-3GPP Gateway Function (TNGF). For example, if the WLAN access network is configured to require the UE's 5G System-based (5GS) access authentication connection to the WLAN, the UE performs the authentication process for NSWO in 5GS as defined in Clause 4.2.15 of 3GPP TS 23.501 and Annex S of 3GPP TS 33.501 Release 18.3.0. After successful authentication, the UE is not considered to have entered the 5GS registration state. The UE can send and receive services that do not traverse the 5GC and are not under the control of the 5GC.

[0033] Non-3GPP access networks can connect to multiple PLMNs via reference point SWA' for 5G NSWO. In interconnection scenarios, the UE can reach the HPLMN via WLAN access connected to more than one VPLMN. Therefore, when interconnecting, the UE should be able to indicate a specific selected VPLMN (e.g., using a modified NAI for 5G NSWO), and the NSWO request should be sent to the HPLMN through that VPLMN.

[0034] UEs connected to WLAN access networks using 5GS credentials (e.g., 3GPP TS 33.501 version 18.3.0) Figure 4 As shown in .2.15-1, it can also connect to the 5GC, for example, to establish a PDU session. For example, the UE can connect to the 5GC via another access type (such as NG-RAN), or via the same WLAN access network, for example, by performing 5GS registration via an untrusted non-3GPP access procedure (using N3IWF) as defined in Clause 14.12 of 3GPP TS23.502 Release 18.3.0, or for example, by interworking between the ePDG connected to the EPC and the 5GS (using ePDG) as defined in Clause 4.3.4 of TS 23.501 Release 18.3.0.

[0035] When a UE connects to a WLAN access network (e.g., using 5GS credentials) and uses untrusted non-3GPP access, the UE can perform some or all data services to the NSWO of that WLAN access network, sending services outside of IP Security Protocol (IPSec) tunnel encapsulation as defined in the URSP rules with NSWO indication.

[0036] For example, a UE can use the registration process for trusted non-3GPP access defined in Clause 4.12a.2.2 of 3GPP TS 23.502 Release 18.3.0, and then determine to send some services outside the IPSec tunnel established with TNGF (which will be subject to NSWO constraints).

[0037] Note: A UE cannot first connect to a WLAN access network using 5GS credentials without performing 5GS registration, and then later perform 5GS registration on that WLAN access network using a trusted non-3GPP access procedure, without first releasing the WLAN and then establishing a new WLAN association, for example, according to the registration procedure for trusted non-3GPP access as defined in Clause 4.12a.2.2 of 3GPP TS 23.502 version 18.3.0.

[0038] When a UE decides to use its 5GS credentials but not register with the 5GS, and connects to a WLAN access network using a 5G NSWO, it uses a NAI format for the 5G NSWO, whose fields differ from those defined for trusted non-3GPP access using the 5GC (e.g., defined in clauses 28.7.6 and 28.7.7 of 3GPP TS 23.003 version 18.3.0). In an example embodiment, for example, the NAI format for the 5G NSWO is as defined in TS 23.003 version 18.3.0 and is reproduced below:

[0039] Modified NAI format for SUCI

[0040] The modified NAI should be in the form of NAI and should have the format "home domain!username@other domain" as specified in Clause 2.7 of IETF RFC 4282.

[0041] The modified NAI's domain portion consists of "Other Domains," see IETF draft 2486-bisRFC 4282. "Home Domain" is the domain as specified in Clause 14.2, using the HPLMN ID ("Home MCC" + "Home MNC"). "Other Domains" is the domain constructed using the PLMN ID (Visitor MCC + Visitor MNC) of the PLMN selected as a result of WLAN PLMN selection (e.g., see 3GPP TS 24.234 version 12.2.0).

[0042] When using EAP AKA authentication, the username portion of the root NAI should conform to IETF RFC 4187; when using EAP SIM authentication, it should conform to IETF RFC 4186.

[0043] When the username portion of the modified NAI includes the IMSI, it should be constructed following the same steps specified in Clause 14.3 for the root NAI.

[0044] The result will be a modified NAI in the following form:

[0045] For EAP AKA certification, it should be "wlan.mnc<belonging MNC>.mcc<belonging MCC>.3gppnetwork.org!0". <imsi>@wlan.mnc<interviewed MNC>.mcc<interviewed MCC>.3gppnetwork.org, and regarding EAP SIM authentication as "wlan.mnc<home MNC>.mcc<home MCC>.3gppnetwork.org!1 <imsi>@wlan.mnc<Home MNC>.mcc<Home MCC>.3gppnetwork.org”.

[0046] For example, for EAP AKA authentication: If the IMSI is 234150999999999 (MCC = 234, MNC = 15) and the PLMN ID of the selected PLMN is MCC = 610, MNC = 71, the modified NAI takes the form wlan.mnc015.mcc234.3gppnetwork.org!0234150999999999@wlan.mnc071.mcc610.3gppnetwork.org.

[0047] Note: The "other domain" specified in this document is resolved by the WLAN AN. If the WLAN AN cannot access the GRX, the WLAN AN shall resolve the domain by other means, such as a static lookup table, a private local DNS server acting as the authoritative name server for that subdomain.

[0048] Modified NAI for 5G NSWO

[0049] The modified NAI for 5G NSWO interconnection scenarios shall take the form of the NAI defined in Clause 28.7.9.1, where the "home domain" and "other domain" shall start with the label "5gc-nswo".

[0050] The result is a modified NAI in the following form:

[0051] 5gc-nswo.mnc<Home MNC>.mcc<Home MCC>.3gppnetwork.org!<Username of the SUCI in the NAI format>@5gc-nswo.mnc<Visited MNC>.mcc<Visited MCC>.3gppnetwork.org.

[0052] Example: Assume IMSI 234150999999999, where MCC = 234, MNC = 15, MSISN = 0999999999, routing indicator 678, home network public key identifier 27, null scheme, and visited PLMN ID (MCC = 610, MNC = 71): - The NAI format of the SUCI for 5G NSWO takes the form: type0.rid678.schid0.userid0999999999@5gc-nswo.mnc015.mcc234.3gppnetwork.org - The modified NAI format for SUCI used for 5G NSWO interconnect is as follows: 5gc-nswo.mnc015.mcc234.3gppnetwork.org!type0.rid678.schid0.userid0999999999@5gc-nswo.mnc071.mcc610.3gppnetwork.org

[0053] NAI for 5G NSWO

[0054] When a UE decides to use its 5GS credentials but not register with 5GS, and connects to a WLAN access network using a 5G NSWO, it uses the NAI format for 5G NSWO in non-interconnected scenarios. For the NAI format for 5G NSWO in interconnected scenarios, see Clause 28.7.9.2.

[0055] Note: In this case, the NAI field is different from the field defined for use during 5G registration via trusted non-3GPP access to the 5GCN (see Clause 28.7.6), or when an N5CW device accesses the 5GCN via trusted non-3GPP access (see Clause 28.7.7). See, for example, Clause 5.42 in 3GPP TS 23.501 Release 18.3.0.

[0056] In 5G NSWO use cases, the UE should use the NAI in the following format: -For PLMN: "<username>@5gc-nswo.mnc <mnc>.mcc <mcc>.3gppnetwork.org - For SNPN: "<username>@5gc-nswo.nid <nid>.mnc <mnc>.mcc <mcc>.3gppnetwork.org

[0057] In the above use cases: a) The username portion is defined in Clause 28.7.3; and b) The label "5gc-nswo" in the domain portion indicates that the NAI is used for 5G NSWO. For PLMN, <mnc>and <mnc>Identify PLMN, and for SNPN, <nid> 、 <mnc>and <mcc>Identify the SNPN, for example, the UE attempts to connect to the SNPN via a 5G NSWO as described in Clause 4.2.15 of 3GPP TS 23.501 version 18.3.0.

[0058] Use cases for interconnection between SNPNs

[0059] describe

[0060] SNPNs are expected to be deployed in government offices, banks, hotels, hospitals, schools, and other locations within administrative regions. Each SNPN will offer its localized services.

[0061] Interconnection between different SNPNs, under the constraints of appropriate protocols, can enable seamless access to localized services. That is, when SNPNs deployed by different management departments interconnect and their services are made available, a local service of one SNPN can be accessed via other SNPNs. For example, a medical service instantiated on an SNPN deployed at a central hospital can be made available to distributed family clinics. Furthermore, identifiers created in family clinics can be utilized at the central hospital.

[0062] The advantages of interconnecting SNPNs can also be seen during disasters, where PLMN-based services become unavailable due to congestion in the region caused by the disaster. On the other hand, since SNPNs are largely isolated from PLMNs, they are unaffected by congestion within the PLMN. This is advantageous for city governments, for example, as they can maintain their public services through interconnected SNPNs.

[0063] In the context of an interconnected SNPN, the identity provider authenticates individual users within the SNPN and authorizes them to consume services on the SNPN.

[0064] Suppose multiple SNPNs, such as SNPN-1, SNPN-2, and SNPN-3, are deployed in different locations. Figure 3 In .5.1-2, SNPN-1 is the central SNPN, and SNPN-2 and SNPN-3 are branches. A backbone / transmission network is also anticipated to provide interconnectivity between SNPN-1, SNPN-2, and SNPN-3. The backbone network can be a public network (e.g., the Internet) or a private / managed network (e.g., a corporate network that owns an SNPN).

[0065] The following interconnections can be considered, but the list is not exhaustive. 1. Point-to-point interconnectivity, which connects one point to another. 2. The central radial interconnectivity that connects the root node to other leaf nodes. 3. Gateway interconnection that connects multiple points to multiple other points in a full mesh topology.

[0066] exist Figure 3 In the case of deploying point-to-point interconnection pairs between SNPN-1 and SNPN-2, and between SNPN-2 and SNPN-3, as described in .5.1-3, the interconnection has 6 interconnection endpoints. Each SNPN among SNPN-1, SNPN-2, and SNPN-3 uses 2 interconnection endpoints to reach the other SNPNs. For traffic originating from one SNPN to another, each SNPN should manage which route reaches the other SNPN (e.g., EP12 hosting SNPN-1 supports point-to-point connections to EP21 hosting SNPN-2).

[0067] Deployment among SNPN-1, SNPN-2 and SNPN-3 Figure 3 In the case of the central-radius interconnection described in .5.1-4, internal traffic between interconnected endpoints is transmitted via the root endpoint. For example, a central hospital provides SNPN-1, while family clinics #2 and #3 are consumers of SNPN-2 and SNPN-3, respectively. Assuming SNPN-1 is the central SNPN, SNPN-1 can also provide identification services. For example, internal traffic from EP-3L, which hosts SNPN-3, is transmitted to SNPN-1 via EP-1R, and then SNPN-1 routes the traffic from EP-1R to EP-2L, which hosts SNPN-2. It should be noted that identification provider services can also reside in an external data network connected to SNPN-1.

[0068] Deployment among SNPN-1, SNPN-2 and SNPN-3 Figure 3 In the case of gateway interconnection as described in .5.1-5, internal traffic between interconnected endpoints is transmitted between each interconnected endpoint. Each SNPN can communicate with each other via gateway interconnection services. For example, services (such as identity provider services) can interface directly with the interconnection. In this case, the identity provider service can be seamlessly consumed via any SNPN, and the identity assigned to a user can be authenticated and authorized in any SNPN.

[0069] Interconnectivity (e.g., point-to-point, hub-and-spoke, gateway, etc.) is designed, for example, by the interconnect producer. An interconnect describes the set of interconnect endpoints and how to access the interconnect endpoints from SNPN-1, SNPN-2, and SNPN-3.

[0070] Typically, interconnect information is provided to consumers by producers. For example, there may be a situation where the backbone network operator is the producer of the interconnect, while SNPN-1, SNPN-2, and SNPN-3 are consumers. In another scenario, SNPN-1 is the producer of the interconnect, while SNPN-2 and SNPN-3 are consumers. Interconnect information can be exchanged between producers and consumers.

[0071] Prerequisites

[0072] Assume a hub-and-spoke model is deployed in a central hospital and family clinics for this service flow. SNPN-1 is the root node, deployed in the central hospital, and SNPN-2 and SNPN-3 are leaf nodes, deployed in family clinics #2 and #3, respectively. SNPN-1, SNPN-2, and SNPN-3 are connected to the backbone network and are at least IP reachable from each other. Therefore, this use case discusses the managed interconnection between different SNPNs.

[0073] Service flow 1. The interconnects used for the central radial model were designed by the producer of SNPN-1 deployed in the central hospital. The interconnects describe the set of interconnect endpoints for the root and branch nodes, and how to access the interconnect endpoints from SNPN-1, SNPN-2, and SNPN-3. 2. Interconnection provided by SNPN-1 to SNPNs (i.e., SNPN-2 and SNPN-3) deployed in family clinics. 3. The SNPN-1 management system selects the endpoint within the 5GS of SNPN-1 to the interconnect endpoint (root node), and then prepares the access link to the interconnect endpoint. 4. The SNPN-2 management system selects the endpoint within the 5GS of SNPN-2 to the interconnect endpoint (leaf node), and then prepares the access link to the interconnect endpoint. 5. The SNPN-3 management system selects the endpoint within the 5GS of SNPN-3 to the interconnect endpoint (leaf node), and then prepares the access link to the interconnect endpoint.

[0074] Postconditions

[0075] The selected topology and 5GS endpoints are used to interconnect SNPN-1, SNPN-2, and SNPN-3, allowing SNPNs to exchange data.

[0076] Use cases for independent naval non-public network interconnection

[0077] describe

[0078] This use case involves a self-organizing, broadband, low-latency connectivity solution between ships in a fleet. It can be applied to various sectors, including military, coast guard fleets, or fishing fleets… in short, any situation requiring intra-fleet communication and coordination.

[0079] In this use case, 5G systems are deployed on every ship in the fleet, with each system being a fully autonomous communication network enabling inter-ship and intra-ship communication. All ships in the fleet ultimately form a group of independent, non-public 5G networks interconnected by an inherently variable topology. An example of such an interconnected group of independent, non-public networks is envisioned.

[0080] All independent, non-public networks are interconnected via wireless links, preferably 5G links operating in the same frequency band as the 5G radio links connecting the terminals and the SNPN (access network). Furthermore, since interconnected SNPN groups can be deployed in operational areas or in harsh sea conditions, it is important to maintain their capacity even if one or more vessels are lost.

[0081] Each SNPN in the fleet can connect to other vessels via a wireless link or provide connectivity in the immediate vicinity of the vessels it is deployed in. Users on board can consume any services hosted by the other vessels that make up the fleet.

[0082] The system will ultimately have the following characteristics: - Average size of the target fleet: 5 or 6 ships - A self-organizing SNPN group with interconnecting links that are dynamically established and determined based on the positions of the vessels relative to each other and the quality of the radio links. - Dynamic routing based on access and interconnection link quality Full-duplex communication between ships - The mobility of terminals from one ship (one SNPN) to another ship (another SNPN) without losing communication. - Differentiated service quality management - Extremely high flexibility; the connection between SNPN sets must remain operational during ship combat, regardless of sea conditions and the number of remaining ships. -performance: Within 40 kilometers of the line of sight of the interconnection link 1-10 Mbit / s in a 5MHz bandwidth Latency << 100ms

[0083] Prerequisites

[0084] User A's terminal is loaded with a USIM registered to SNPN A.

[0085] SNPN A has local coverage on ship A, and SNPN B has coverage on ship B.

[0086] Service B is provided by application B, which is instantiated on ship B. Application B has 5G connectivity via SNPN B.

[0087] User A has the credentials required to access service B.

[0088] Service flow 1) User A, who is on ship A and attached to SNPN A on ship A, establishes a PDU session to access service B. 2) During the establishment of a PDU session, the communication between the 5G system identifier and service B should be routed from SNPN A to SNPN B via SNPN D to meet the quality of service required by service B. The 5G system configures all resources on this path according to the quality of service requirements of service B. 3) Later, the ships have moved relative to each other, and based on the metrics collected on the wireless interconnection link, the 5G system now identifies that communication with Service B should be routed through SNPN C. The call is switched to the new path without User A even noticing. 4) Later, unfortunately, SNPN C became unavailable (or out of range) and was replaced by a helicopter with an embedded self-organizing SNPN. As part of the discovery process, the new SNPN in the helicopter identified and authenticated itself to those SNPNs within range. The new routes, now including the SNPN on the helicopter, are evaluated based on quality of service requirements and are ultimately selected by the 5G system for the user's A PDU session. 5) Simultaneously, while the helicopter was launching, the 5G system realized that the communication path using SNPN C was no longer available. Therefore, communication from user A to service B was reconfigured to the initial communication path via SNPN D. Communication experienced quality issues until the communication path was switched to the path involving the SNPN on the helicopter. 6) Communication with service B is terminated by user A, and all resources used for communication between SNPN A and SNPN B are released.

[0089] Postconditions

[0090] User A attaches to SNPN A.

[0091] In example embodiments, the modified NAI is applicable to both SNPN and NSWO use cases applicable to SNPN. AMF and AUSF are provided with support for authorization and denial reasons for SNPN through some example embodiments. Specifically, some example embodiments disclose... - UEs connected to SNPN in the interconnection will generate a modified NAI for SNPN. - The network receives the modified NAI and decodes it. - The network also uses the SNPN ID available in the modified NAI to identify the SNPN selection of the UE and accordingly allows or rejects the request. Example

[0092] Modified SNPN NAI

[0093] Overview

[0094] In an example embodiment, the modified NAI format for SUCI takes the form of NAI and has the form of "home domain! user name @ other domain" as specified in clause 2.7 of IETF RFC 4282.

[0095] In an example embodiment, for example, the user name part of the modified NAI contains the user name of the NAI format for SUCI as specified in clause 28.7.3 of TS 23.003 version 18.3.0.

[0096] In an example embodiment, for example, the "home domain" is the domain of the NAI format for SUCI as specified in clause 28.7.3 of TS 23.003 version 18.3.0, unless otherwise specified in the relevant clause.

[0097] In an example embodiment, the domain part of the modified NAI consists of "other domain", see IETF RFC 4282. The "other domain" is a domain constructed using the SNPN ID (visited NID + visited MCC + visited MNC) of the visited SNPN selected by the UE.

[0098] In an example embodiment, for example, the "home domain" and the "other domain" start with one or more labels for a specific use case of the modified NAI format for SUCI (e.g., for 5G NSWO (see clause 28.7.9.2 of TS 23.003 version 18.3.0)).

[0099] In an example embodiment, the result is a modified NAI in the following form: <one or more labels>.nid<home NID>.mnc<home MNC>.mcc<home MCC>.3gppnetwork.org!<user name of the NAI format for SUCI>@<one or more labels>.nid<visited NID>.mnc<visited MNC>.mcc<visited MCC>.3gppnetwork.org.

[0100] Modified NAI for 5G NSWO

[0101] In an example embodiment, for instance, the modified NAI for a 5G NSWO interconnection scenario takes the form of the NAI defined in clause 28.7.9.1 of TS 23.003 version 18.3.0, where "home realm" and "other realm" shall start with the label "5gc-nswo". In the example embodiment, the result is a modified NAI in the following form:

[0102] 5gc-nswo.nid<Home NID>.mnc<Home MNC>.mcc<Home MCC>.3gppnetwork.org!<Username of the SUCI in NAI format>@5gc-nswo.nid<Visited NID>.mnc<Visited MNC>.mcc<Visited MCC>.3gppnetwork.org.

[0103] Example:

[0104] Assume IMSI 234150999999999, where MCC = 234, MNC = 15, NID = 15 and MSISN = 0999999999, routing indicator 678, home network public key identifier is 27, null scheme, and visited PLMN ID (MCC = 610, MNC = 71, NID = d5):

[0105] - The NAI format of the SUCI for 5G NSWO takes the form:

[0106] type0.rid678.schid0.userid0999999999@5gc-nswo.nid015.mnc015.mcc234.3gppnetwork.org

[0107] - The modified NAI format of the SUCI for 5G NSWO interconnection takes the form:

[0108] 5gc-nswo.nid015.mnc015.mcc234.3gppnetwork.org!type0.rid678.schid0.userid0999999999@5gc-nswo.nid0d5.mnc071.mcc610.3gppnetwork.org

[0109] 5GMM Cause

[0110] The purpose of the 5GMM cause information element is to indicate the reason why a 5GMM request from the UE is rejected by the network.

[0111] The 5GMM cause information element is encoded as shown in Tables 1 and 2 below. The 5GMM cause is a Type 3 information element with a length of 2 octets. Table 1: 5GMM Cause Information Elements Table 2: 5GMM Cause Information Elements Note: For example, the reason code "SNPN" is not allowed is new in Table 7.2.1-1 of 3GPP TS 24.501 Release 18.4.0 9.11.3.2.

[0112] Application errors in AUSF

[0113] For example, the general application errors defined in Table 5.2.7.2-1 of 3GPP TS 29.500 Release 18.3.0 can also be used for the Nausf_UEAuthentication service. The following application errors, listed in Table 3 below, are specific to the Nausf_UEAuthentication service. Table 3: Application Errors Note: For example, the application error SNPN_NOT_AUTHORIZED in Table 3 is new relative to Table 6.1.7.3-1 of 3GPP TS 29.50918.2.0.

[0114] Figure 1 The process of an example embodiment is shown.

[0115] In the case of interconnected SNPNs, in an example embodiment, the UE generates a modified NAI in the interconnected context. Assume the UE belongs to S-NPN#2 and is currently in S-NPN#1. The UE sends a registration request with the modified SNPN NAI to the AMF of S-NPN#1. In the example embodiment, the AMF of S-NPN#1 forwards the modified NAI and SNN ID to the AFSF of S-NPN#2. In the example embodiment, the AFSF of S-NPN#2 verifies whether the visitor's SNN ID is allowed. If not allowed, registration is rejected; otherwise, registration continues, for example, as described in Appendix I.2.2.2.1 of TS 33.501 version 18.3.0.

[0116] In the example embodiment, the above scenario also applies to the NSWO interconnection of SNPN.

[0117] For example, regarding step 4 in Appendix I.2.2.2.2 of 3GPP TS 33.501 version 18.3.0:

[0118] In the example implementation, the choice of using an external credential holder for authentication is based on the home domain.

[0119] Key hierarchy:

[0120] In example implementations, for instance, the service network (SN name) as described in version 33.501 18.3.0 is another domain that implements the binding to the service network. If the NAI is just a "simple version", then the SN NAME is the home network.

[0121] Figure 2 A simplified flowchart of a process in a device for a user equipment (such as a UE, a controller for a UE, or a chipset for a UE) according to an example embodiment is shown. The process includes: 201. Form a registration request, the registration request including a modified network access identifier (NAI) indicating the cellular subscription of the user equipment and indicating an interconnection indication for inducing a non-seamless WLAN offloading (NSWO) interconnection from a first independent non-public network (SNPN) to a second SNPN. 202. Send a registration request to the first SNPN. 203. After the registration request, receive an instruction from the first SNPN indicating the result of the registration request.

[0122] Figure 3 A simplified flowchart of a process in a mobility management entity for a first SNPN according to an example embodiment is shown. The process includes: 301. Receive a registration request from a user equipment, the registration request including a modified network access identifier (NAI) indicating the user equipment's cellular subscription and indicating an interconnection indication for inducing a non-seamless WLAN offloading (NSWO) interconnection from a first SNPN to a second SNPN. 302. Form an authentication request, which includes a modified NAI and an indication of the first SNPN name. 303. Send an authentication request to the second SNPN. 304. Receive authentication response from the second SNPN. 305. Based on the authentication response, indicate the result of the registration request to the user equipment.

[0123] Figure 4 A simplified flowchart of a process in an authentication entity for a second SNPN according to an example embodiment is shown. The process includes: 401. Receive an authentication request, which includes a modified NAI and an indication of a first SNPN name, the modified NAI indicating the cellular subscription of the user equipment and indicating an interconnection indication for inducing a non-seamless WLAN offloading (NSWO) interconnection of the user equipment from the first SNPN to the second SNPN. 402. Verify whether the first SNPN is in the allowed access SNPN and allow or deny the authentication request accordingly. 403. Send an authentication response to the second SNPN, indicating whether the authentication response is allowed or denied.

[0124] Figure 5 A block diagram of an apparatus 500 according to an embodiment of the present invention is shown.

[0125] Device 500 includes a memory 540 comprising working memory 542 and non-volatile memory 544 containing computer program code 546 and data (such as pre-configured rules or configuration information). Device 500 also includes a processor 520 for controlling the operation of device 500 using computer program code 546, and a communication unit 510, such as a new radio capable of 5G cellular communication, for communicating with user equipment and cellular networks. Communication unit 510 includes, for example, a local area network (LAN) port, a wireless local area network (WLAN) unit, a Bluetooth unit, a cellular data communication unit, or a satellite data communication unit. Processor 520 includes, for example, any one or more of the following: a main control unit (MCU), a microprocessor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array, and a microcontroller. Device 500 also includes a user interface 530, which includes, for example, any one or more of the following: a display, a touchscreen, buttons, a microphone, a speaker, and a fingerprint reader.

[0126] As used in this application, the term "circuit system" may refer to one or more of the following: (a) Hardware circuit implementation only (e.g., implementation only in analog and / or digital circuit systems); and (b) A combination of hardware circuitry and software, such as (if applicable): (i) A combination of (multiple) analog and / or digital hardware circuits with software / firmware; and (ii) Any part of a hardware processor (including digital signal processors), software, and memory (including multiple memory), which work together to enable a device (such as a mobile phone or server) to perform various functions; and (c) (a ...

[0127] The definition of "circuit system" applies to all uses of the term in this application, including in any claim. As another example, as used in this application, the term "circuit system" also covers only hardware circuitry or a processor (or multiple processors) or portions of hardware circuitry or a processor and its accompanying software and / or firmware implementation. For example, if applicable to a particular claim element, the term "circuit system" also covers baseband integrated circuits or processor integrated circuits for user equipment, or similar integrated circuits in servers, cellular network devices, or other computing or network devices.

[0128] Without limiting the scope, interpretation, or application of the following claims in any way, the technical effect of one or more example embodiments disclosed herein is to enable user equipment to interconnect with a second SNPN of its own selection via NSWO. Another technical effect of one or more example embodiments disclosed herein is that existing 5G and other compatible standalone non-public networks can be used to license the use of standalone WLAN networks.

[0129] Implementations may be carried out in software, hardware, application logic, or a combination of software, hardware, and application logic. The software, application logic, and / or hardware may reside on a user equipment, an SNPN mobility management entity, or an SNPN authentication entity. If desired, portions of the software, application logic, and / or hardware may reside on the user equipment, portions of the software, application logic, and / or hardware may reside on the SNPN mobility management entity, and portions of the software, application logic, and / or hardware may reside on the SNPN authentication entity. In example embodiments, the application logic, software, or instruction set is held on any of a variety of conventional computer-readable media. In the context of this document, "computer-readable media" can be any non-transitory medium or component that can contain, store, communicate, propagate, or transmit instructions for instruction execution by a system, apparatus, or device (such as a computer; an example of a computer is...). Figure 5 The computer-readable medium may be used or used in conjunction with the description and depiction herein. A computer-readable medium may include a computer-readable storage medium, which may be any medium or component that may contain or store instructions for use by or in conjunction with an instruction execution system, apparatus, or device, such as a computer. As used herein, the term nontransient is a limitation on the medium itself (i.e., tangible, not signaling), rather than a limitation on the persistence of data storage (e.g., random access memory versus read-only memory).

[0130] If necessary, the different functions discussed in this article can be executed in different orders and / or concurrently with each other. Furthermore, if necessary, one or more of the functions described above can be optional or can be combined.

[0131] While various aspects of the invention are set forth in the independent claims, other aspects of the invention include other combinations of features from the described embodiments and / or dependent claims with those of the independent claims, and not only combinations expressly set forth in the claims.

[0132] It should also be noted that while exemplary embodiments of the invention have been described above, these descriptions should not be regarded as limiting. Rather, several variations and modifications are possible without departing from the scope defined in the appended claims.< / mcc> < / mnc> < / nid> < / mnc> < / mnc> < / mcc> < / mnc> < / nid> < / mcc> < / mnc> < / imsi> < / imsi>

Claims

1. An apparatus for a user equipment, wherein the apparatus comprises: Cellular radio circuitry systems used for communication with cellular networks; At least one processor; as well as At least one memory storing instructions that, when executed by the at least one processor, cause the device to at least: A registration request is generated, the registration request including a modified network access identifier (NAI) indicating the cellular subscription of the user equipment and indicating an interconnection indication for inducing a non-seamless WLAN offloading (NSWO) interconnection from a first independent non-public network (SNPN) to a second SNPN; Send the registration request to the first SNPN; as well as Following the registration request, an indication of the result of the registration request is received from the first SNPN.

2. The apparatus of claim 1, wherein the apparatus comprises or is included in the user equipment.

3. The apparatus according to claim 1 or 2, wherein the user equipment is a mobile device.

4. An apparatus comprising: At least one processor; as well as At least one memory storing instructions that, when executed by the at least one processor, cause the device to at least: A registration request is received from a user equipment, the registration request including a modified network access identifier (NAI) indicating the user equipment's cellular subscription and indicating an interconnection indication for inducing a non-seamless WLAN offloading (NSWO) interconnection from a first SNPN to a second SNPN. A request for authentication is formed, the request including the modified NAI and an indication of the first SNPN name; Send the authentication request to the second SNPN; Receive an authentication response from the second SNPN; as well as Based on the authentication response, the result of the registration request is indicated to the user equipment.

5. The apparatus of claim 4, wherein the apparatus comprises, or is included in, the mobility management entity of the first SNPN.

6. The apparatus of claim 5, wherein the mobility management entity is an access and mobility management function (AMF).

7. The apparatus according to any one of claims 4 to 6, wherein if the result of the registration request is a rejection of the registration request, then the result indicated by the registration request is the reason code "SNPN not allowed".

8. An apparatus comprising: A communication circuit system for communication with at least the mobility management entity of a first independent non-public network (SNPN); At least one processor; as well as At least one memory stores instructions that, when executed by the at least one processor, cause the device to at least: Receive an authentication request, the authentication request including a modified network access identifier (NAI) and an indication of the first SNPN name, the modified NAI indicating the cellular subscription of the user equipment and indicating an interconnection indication, the interconnection indication being used to induce a non-seamless WLAN offloading (NSWO) interconnection of the user equipment from the first SNPN to the second SNPN; Verify whether the first SNPN is in the allowed access SNPN and allow or deny the authentication request accordingly; as well as Send an authentication response to the second SNPN, the authentication response indicating whether the authentication response is allowed or denied.

9. The apparatus of claim 8, wherein the apparatus comprises, or is included in, the authentication entity of the second SNPN.

10. The apparatus of claim 9, wherein the authentication entity is an authentication server function (AUSF).

11. The apparatus according to any one of claims 8 to 10, wherein if the authentication request is rejected, the authentication response is the message "SNPN not authorized".

12. The apparatus according to any one of the preceding claims, wherein the modified NAI includes an NSWO interconnect indication.

13. The apparatus according to any one of the preceding claims, wherein the interconnection indication is a tag, the tag being included in the home domain portion and other domain portions of the modified NAI.

14. The apparatus according to any one of the preceding claims, wherein the modified NAI includes an indication of the second SNPN, an indication of the home SNPN of the cellular subscription, and a subscriber hidden identifier (SUCI) of the cellular subscription.

15. A method in an apparatus for a user equipment, comprising: A registration request is generated, the registration request including a modified network access identifier (NAI) indicating the cellular subscription of the user equipment and indicating an interconnection indication for inducing a non-seamless WLAN offloading (NSWO) interconnection from a first independent non-public network (SNPN) to a second SNPN; Send the registration request to the first SNPN; as well as Following the registration request, an indication of the result of the registration request is received from the first SNPN.

16. A method in a mobility management entity for a first independent non-public network (SNPN), comprising: A registration request is received from a user equipment, the registration request including a modified network access identifier (NAI) indicating the user equipment's cellular subscription and indicating an interconnection indication for inducing a non-seamless WLAN offloading (NSWO) interconnection from a first SNPN to a second SNPN. A request for authentication is formed, the request including the modified NAI and an indication of the first SNPN name; Send the authentication request to the second SNPN; Receive an authentication response from the second SNPN; as well as Based on the authentication response, the result of the registration request is indicated to the user equipment.

17. A method for an authentication entity used in a second independent non-public network (SNPN), comprising: Receive an authentication request, the authentication request including a modified NAI and an indication of the name of the first SNPN, the modified NAI indicating the cellular subscription of the user equipment and indicating an interconnection indication, the interconnection indication being used to cause the user equipment to perform a non-seamless WLAN offloading (NSWO) interconnection from the first SNPN to the second SNPN; Verify whether the first SNPN is in the allowed access SNPN and allow or deny the authentication request accordingly; as well as Send an authentication response to the second SNPN, the authentication response indicating whether the authentication response is allowed or denied.

18. An apparatus comprising: Components for forming a registration request, the registration request including a modified network access identifier (NAI) indicating the cellular subscription of the user equipment and indicating an interconnection indication for inducing a non-seamless WLAN offloading (NSWO) interconnection from a first independent non-public network (SNPN) to a second SNPN; Components used to send the registration request to the first SNPN; as well as A component for indicating the result of receiving the registration request from the first SNPN after the registration request.

19. An apparatus comprising: A component for receiving a registration request from a user equipment, the registration request including a modified network access identifier (NAI) indicating the user equipment's cellular subscription and indicating an interconnection indication for inducing a non-seamless WLAN offloading (NSWO) interconnection of the user equipment from a first SNPN to a second SNPN; Components for forming an authentication request, the authentication request including the modified NAI and an indication of the first SNPN name; as well as Components used to send the authentication request to the second SNPN; Components for receiving authentication responses from the second SNPN; as well as A component for instructing the user equipment, based on the authentication response, of the result of the registration request.

20. An apparatus comprising: A component for receiving an authentication request, the authentication request including a modified network access identifier (NAI) and an indication of the name of the first SNPN, the modified NAI indicating the cellular subscription of the user equipment and indicating an interconnection indication, the interconnection indication being used to induce a non-seamless WLAN offloading (NSWO) interconnection of the user equipment from the first SNPN to the second SNPN; A component for verifying whether the first SNPN is in an allowed access SNPN and accordingly allowing or denying the authentication request; as well as A component for sending an authentication response to the second SNPN, the authentication response indicating whether the authentication is allowed or denied.

21. A computer program comprising instructions for at least performing the method according to any one of claims 15 to 17.

22. A non-transitory computer-readable medium comprising program instructions stored thereon for performing at least the method according to any one of claims 15 to 17.

23. A computer-readable medium comprising program instructions stored thereon for performing at least the method according to any one of claims 15 to 17.

24. A system comprising: At least one processor and at least one memory, the at least one memory storing instructions that, when executed by the at least one processor, cause the system to at least: A registration request is generated, the registration request including a modified network access identifier (NAI) indicating the cellular subscription of the user equipment and indicating an interconnection indication for inducing a non-seamless WLAN offloading (NSWO) interconnection from a first independent non-public network (SNPN) to a second SNPN; Send the registration request to the first SNPN; Following the registration request, an indication of the result of the registration request is received from the first SNPN; Receive the registration request, including the modified NAI, from the user equipment; A request for authentication is formed, the request including the modified NAI and an indication of the first SNPN name; Send the authentication request to the second SNPN; Receive an authentication response from the second SNPN; Based on the authentication response, the result of the registration request is indicated to the user equipment; Receive the authentication request, which includes the modified NAI and the indication of the first SNPN name; Verify whether the first SNPN is in the allowed access SNPN and allow or deny the authentication request accordingly; as well as The authentication response is sent to the second SNPN, indicating whether the authentication response is allowed or denied.

25. A system comprising: Components for forming a registration request, the registration request including a modified network access identifier (NAI) indicating a user equipment's cellular subscription and indicating an interconnection indication for inducing a non-seamless WLAN offloading (NSWO) interconnection from a first independent non-public network (SNPN) to a second SNPN; Components used to send the registration request to the first SNPN; A component for receiving an indication of the result of the registration request from the first SNPN after the registration request; A component for receiving the registration request, including the modified NAI, from the user equipment; Components for forming an authentication request, the authentication request including the modified NAI and an indication of the first SNPN name; Components used to send the authentication request to the second SNPN; Components for receiving authentication responses from the second SNPN; A component for instructing the user equipment, based on the authentication response, of the result of the registration request; A component for receiving the authentication request, the authentication request including the modified NAI and the indication of the first SNPN name; A component for verifying whether the first SNPN is in an allowed access SNPN and accordingly allowing or denying the authentication request; as well as A component for sending the authentication response to the second SNPN, the authentication response indicating whether the authentication is allowed or denied.

Images