Patent Description:
Current wireless communication networks, such as third generation (<NUM>) and fourth generation (<NUM>) networks, have little to no support for enhanced Vertical and local area network (LAN) services. Mechanisms are needed to provide enhanced Vertical and LAN services in upcoming fifth generation (<NUM>) wireless communication networks.

<CIT> discloses a cellular system in which access to a closed subscriber group can be controlled based on a cell ID, or access to services is based on a user identity. <CIT> discloses a cellular system in which a network identifier is included in a broadcast message, the content of which message enables a connection to the cellular system.

The invention is defined by the independent claims appended to this description. A selection of optional features is set out in the dependent claims.

For simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity of presentation. Furthermore, reference numerals may be repeated among the figures to indicate corresponding or analogous elements.

The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the various aspects of various embodiments. However, it will be apparent to those skilled in the art having the benefit of the present disclosure that the various aspects of the various embodiments may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and processes are omitted so as not to obscure the description of the various embodiments with unnecessary detail. For the purposes of the present document, the phrase "A or B" means (A), (B), or (A and B).

<FIG> illustrates an architecture of a system <NUM> of a network in accordance with some embodiments. The system <NUM> is shown to include a user equipment (UE) <NUM> and a UE <NUM>. The UEs <NUM> and <NUM> are illustrated as smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more cellular networks), but may also comprise any mobile or non-mobile computing device, such as Personal Data Assistants (PDAs), pagers, laptop computers, desktop computers, wireless handsets, or any computing device including a wireless communications interface.

In some embodiments, any of the UEs <NUM> and <NUM> can comprise an Internet of Things (IoT) UE, which can comprise a network access layer designed for low-power IoT applications utilizing short-lived UE connections. An IoT UE can utilize technologies such as machine-to-machine (M2M) or machine-type communications (MTC) for exchanging data with an MTC server or device via a public land mobile network (PLMN), Proximity-Based Service (ProSe) or device-to-device (D2D) communication, sensor networks, or IoT networks. The M2M or MTC exchange of data may be a machine-initiated exchange of data. An loT network describes interconnecting IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure), with short-lived connections. The loT UEs may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate the connections of the loT network.

The UEs <NUM> and <NUM> may be configured to connect, e.g., communicatively couple, with a radio access network (RAN) <NUM> The UEs <NUM> and <NUM> utilize connections <NUM> and <NUM>, respectively, each of which comprises a physical communications interface or layer (discussed in further detail below); in this example, the connections <NUM> and <NUM> are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols.

The connection <NUM> can comprise a local wireless connection, such as a connection consistent with any IEEE <NUM> protocol.

The RAN <NUM> is shown to be communicatively coupled to a core network (CN) <NUM> - via an S1 interface <NUM>. In embodiments, the CN <NUM> may be an evolved packet core (EPC) network, a NextGen Packet Core (NPC) network, or some other type of CN. In this embodiment the S1 interface <NUM> is split into two parts: the S1-U interface <NUM>, which carries traffic data between the RAN nodes <NUM> and <NUM> and the serving gateway (S-GW) <NUM>, and the S1-mobility management entity (MME) interface <NUM>, which is a signaling interface between the RAN nodes <NUM> and <NUM> and MMEs <NUM>.

<FIG> illustrates example components of a device <NUM> in accordance with some embodiments. In some embodiments, the device <NUM> may include application circuitry <NUM>, baseband circuitry <NUM>, Radio Frequency (RF) circuitry <NUM>, front-end module (FEM) circuitry <NUM>, one or more antennas <NUM>, and power management circuitry (PMC) <NUM> coupled together at least as shown. The components of the illustrated device <NUM> may be included in a UE or a RAN node. In some embodiments, the device <NUM> may include less elements (e.g., a RAN node may not utilize application circuitry <NUM>, and instead include a processor/controller to process IP data received from an EPC). In some embodiments, the device <NUM> may include additional elements such as, for example, memory/storage, display, camera, sensor, or input/output (I/O) interface. In other embodiments, the components described below may be included in more than one device (e.g., said circuitries may be separately included in more than one device for Cloud-RAN (C-RAN) implementations).

The baseband circuitry <NUM> may include circuitry such as, but not limited to, one or more singlecore or multi-core processors. The baseband circuitry <NUM> may include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry <NUM> and to generate baseband signals for a transmit signal path of the RF circuitry <NUM>. Baseband processing circuity <NUM> may interface with the application circuitry <NUM> for generation and processing of the baseband signals and for controlling operations of the RF circuitry <NUM>. For example, in some embodiments, the baseband circuitry <NUM> may include a third generation (<NUM>) baseband processor 204A, a fourth generation (<NUM>) baseband processor 204B, a fifth generation (<NUM>) baseband processor 204C, or other baseband processor(s) 204D for other existing generations, generations in development or to be developed in the future (e.g., second generation (<NUM>), sixth generation (<NUM>), etc.). The baseband circuitry <NUM> (e.g., one or more of baseband processors 204A-D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry <NUM>. In other embodiments, some or all of the functionality of baseband processors 204A-D may be included in modules stored in the memory <NUM> and executed via a Central Processing Unit (CPU) 204E. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some embodiments, modulation/demodulation circuitry of the baseband circuitry <NUM> may include Fast-Fourier Transform (FFT), precoding, or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry <NUM> may include convolution, tail-biting convolution, turbo, Viterbi, or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments.

In some embodiments, the baseband circuitry <NUM> may include one or more audio digital signal processor(s) (DSP) 204F. The audio DSP(s) 204F may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry <NUM> and the application circuitry <NUM> may be implemented together such as, for example, on a system on a chip (SOC).

In some embodiments, the receive signal path of the RF circuitry <NUM> may include mixer circuitry 206a, amplifier circuitry 206b and filter circuitry 206c. In some embodiments, the transmit signal path of the RF circuitry <NUM> may include filter circuitry 206c and mixer circuitry 206a. RF circuitry <NUM> may also include synthesizer circuitry 206d for synthesizing a frequency for use by the mixer circuitry 206a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 206a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry <NUM> based on the synthesized frequency provided by synthesizer circuitry 206d. The amplifier circuitry 206b may be configured to amplify the down-converted signals and the filter circuitry 206c may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry <NUM> for further processing.

In some embodiments, the mixer circuitry 206a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 206d to generate RF output signals for the FEM circuitry <NUM>. The baseband signals may be provided by the baseband circuitry <NUM> and may be filtered by filter circuitry 206c.

In some embodiments, the synthesizer circuitry 206d may be a fractional-N synthesizer or a fractional N/N+<NUM> synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 206d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

Synthesizer circuitry 206d of the RF circuitry <NUM> may include a divider, a delaylocked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by either N or N+<NUM> (e.g., based on a carry out) to provide a fractional division ratio.

The present disclosure considers a non-public network (NPN), which can be a self-contained network or interworking with one or more service networks (which may be operated by one or more mobile network operators (MNO)s providing PLMN services or third-party service network operators (SNO)). As used herein, a "type-a network" may refer to a 3GPP network that is not for public use and for which service continuity and roaming with a public PLMN is possible, and a "type-b network" may refer to an isolated 3GPP network that does not interact with a public PLMN. The type-a and type-b networks may be considered "non-public" because they may be accessed only by UEs with appropriate NPN configuration information as described herein.

Aspects of the present disclosure may provide solutions to the following issues that arise in the context of type-a and type-b networks: (<NUM>) Type-a and type-b network subscriptions; (<NUM>) How information identifying a type-a or type-b network is provided to the UE for network discovery and selection; (<NUM>) Which criteria are used by the UE for automatic selection of type-a or type-b networks; (<NUM>) How to support manual selection of type-a and type-b networks; (<NUM>) How to prevent UEs not authorized for a given type-a or type-b network from attempting to automatically select and register in that type-a or type-b network; (<NUM>) How to enable the network to verify whether a UE is authorized to access a type-a or type-b network; (<NUM>) Which network entities perform access control for type-a and type-b networks; (<NUM>) Access barring aspects for type-a and type-b networks; (<NUM>) Where access restrictions are configured (e.g. subscription or configuration); (<NUM>) How to enable UEs to access type-b networks but prevent the same UEs from accessing public PLMNs; (<NUM>) How to prevent UEs not supporting type-a and type-b networks from attempting to access type-a and type-b networks; (<NUM>) How to prevent NG-RAN from handing over a UE to a type-a network if the UE is not permitted to access the type-a network; (<NUM>) What are the information elements included in the network identification and what is the granularity of each information, e.g. network operator identifier, type of the network, location information; (<NUM>) Whether and how to provide differentiation between type-a and type-b network in a network identification; (<NUM>) What are the assumption on the uniqueness of the network identification; and/or (<NUM>) Whether and how is the network identification related to the UE identification.

Current solutions include some studies in MulteFire, which may provide the methods for interworking a MulteFire network with LTE+EPC. However, some of the issues indicated above have not been resolved yet in these solutions, and the methods used for EPS may not be applicable for 5GS. In contrast, the embodiments herein may provide comprehensive solutions in support of different deployment options for enabling services in PLMN domain or vertical domain for the 5GS UE capable of type-a/type-b network communication. Further, the present disclosure provides mechanisms to resolve the abovementioned open issues for network identification, network discovery and selection, as well as the access control. In support of type-a/type-b network access for a UE, embodiments include a set of UE configuration parameters in type-a/type-b network service profile, and design principles for type-a/type-b network identification and service network identification which can be used for the UE to perform PLMN selection, network discovery and selection based on configured type-a/type-b network service profile.

For purposes of the present disclosure, for type-a networks, the interworking service networks (e.g., service networks <NUM>, <NUM> of <FIG>) are 5GS PLMNs. The interworking system architecture may be of another type, however. In some cases, the fundamental system architecture and UE Configuration Update procedure is assumed to supported and used in a NPN according to 3GPP TS <NUM>, <NUM>, and <NUM>.

<FIG> is a diagram showing example user equipment (UE) <NUM>, <NUM>, <NUM> connected to a non-public network (NPN) <NUM> in accordance with some embodiments. In particular, <FIG> shows an example NPN and various use cases, such as where the the NPN is a self-contained network (e.g., for UE <NUM>) or the case where the NPN provides interaction with external service networks (e.g., for UEs <NUM>, <NUM>). In the example shown, the UEs may access local/non-public network services (e.g., Internet <NUM>) via the NPN <NUM>, or may access external services (e.g., through service networks <NUM>, <NUM>, <NUM>) via the NPN <NUM>. The service networks <NUM>, <NUM>, <NUM> may be third-party networks, and in some cases, may be public land mobile networks (PLMNs) that provide mobile cellular services according to the 3GPP TR <NUM>.

From the UE point of view, the major difference between the type-a and type-b networks is whether the UE is authorized to use services provided by the PLMN via the registered NPN <NUM>. That is, if the UE is not authorized to use services provided by any PLMNs, the UE is registered to a type-b network. On the other hand, an NPN <NUM> may support services provided by one or more service network providers which can include MNOs. That is, in some cases, the NPN <NUM> can be both of type-a and type-b. For the UE, it actually selects a service network which can provide authorized services via a selected NPN <NUM>.

As shown in <FIG>, for UE <NUM>, UE <NUM>, and UE <NUM>, each can register to the same NPN <NUM> identified as NID#X. However, logically: (<NUM>) the UE <NUM> is registered to a type-a network if it is authorized to use the service provided by a PLMN#<NUM>; (<NUM>) the UE <NUM> is registered to a type-b network if it is not authorized to use any service provided by any PLMNs, e.g. SN#N; (<NUM>) the UE <NUM> registers to a self-contained type-b network which provides local, non-public network services without any interaction to external service networks.

Certain deployment options of NPN <NUM> may include: (<NUM>) NPN <NUM> is a type-a network which provides PLMN service by operating as a RAN node in the PLMN; (<NUM>) NPN <NUM> is a type-a network which provides non-public network services and PLMN services by interworking with one or more PLMNs; (<NUM>) NPN <NUM> provide is a type-b network which provides Non-PLMN services by interworking with one or more service network; or (<NUM>) NPN <NUM> is a self-contained type-b network which provides local PLMN or Non-PLMN services (also referred to herein as non-public network services) without any interaction to external service networks. Deployment option <NUM> above may be referred to as a non-standalone case, whereas deployment options <NUM>-<NUM> above may be referred to as standalone cases.

Embodiments herein provide mechanisms for UEs to access an NPN using the following principles for NPN identification: (<NUM>) the NPN may be able to support type-a and/or type-b and both may have the same format of the network identification, defined as NID; (<NUM>) NID of the NPN may be able to indicate the support of external service network, e.g. SN#<NUM>,. ,SN#N, or non-public network service, e.g. as a self-contained private network; (<NUM>) the NPN may provide information of the supported external service network, e.g. SN#<NUM>, SN#N, which can be identified by a service network identification, defined as SN-ID; (<NUM>) SN-ID of the service network may be able to indicate the support of MNO which is with the format of PLMN-ID (e.g., indicating a mobile country code (MCC) and mobile network code (MNC)), and other Service Network Operators (SNO) which format is FFS; (<NUM>) the RAN node in the NPN may broadcast the following information: (a) NID; and/or (b) Supported SN-IDs list; (<NUM>) the UE may be configured with the following information in NPN profile: (a) SN-IDs list in priority order; (b) Authentication parameters including credential, authentication method of the configured SN-ID; and/or (c) DNN, S-NSSAI, SSC mode of the configured SN-ID.

For a UE configured with an NPN profile, it may be important that NPN discovery and selection is able to be compatible with existing PLMN selection procedure as in 3GPP TS <NUM>/TS <NUM>. For example, when a UE is switched on, a PLMN is selected by NAS, and on request of the NAS, the AS may perform a search for available PLMNs with CN type if available for each PLMN and report them to NAS. Thus, a UE may need to be able to select a PLMN-ID that is used for the NPN, and the NPN selection procedure may need to be able to provide information for the UE to differentiate if external services are provided via a service network or non-public network service is supported.

Embodiments herein provide mechanisms for UEs to access an NPN using the following principles for NPN discovery and selection. In the PLMN selection procedure, a reserved global unique PLMN-ID may be used for an NPN as an indication to differentiate access network between the 3GPP Network and NPN. The RAN nodes in NPN may broadcast the reserved global unique PLMN-ID along with other supported PLMNs, if available, in the system information. As a part of the configuration of the NPN Profile, the UE may be also configured with the following information: the Reserved PLMN-ID to be used in PLMN selection. For the UE configured with NPN profile, when it detects and selects the reserved PLMN-ID, it continues with NPN Discovery and Selection procedure. For the NPN selection procedure, if external services are supported, NPN selection can base on the information with combination of SNID+NID, and if non-public network services are supported, NPN selection can only be based on NID.

In some cases, the following two options can be further considered for the UE to differentiate the type of NPN. First (option <NUM>), two different reserved PLMN-IDs may be allocated to represent two types of NPN selection procedure, for either external service or non-public network service. Second (option <NUM>), NID contains an indication which is used to differentiate if associated service is provided by the external service network or non-public network service network.

Embodiments herein provide mechanisms for UEs to access an NPN using access class information may be stored in USIM or as a part of the configuration of the NPN Profile. The UE may be also configured with the access class information corresponding to the configured SN-ID. Access control of the NPN may be based on the RAN node of the NPN broadcasting information of the allow/non-allowed access class of the Service Network identified by the SN-ID.

<FIG> are flow diagrams showing example processes <NUM> of NPN discovery and selection in accordance with some embodiments. Operations in the example process <NUM> may be performed by one or more components of a UE device (e.g., one or more components the baseband circuitry <NUM> of <FIG>), and, in certain cases, may be encoded in computer-readable media as instructions executable by processing circuitry of at least one processor. The example processes <NUM> may include additional or different operations, and the operations may be performed in the order shown or in another order. In some cases, one or more of the operations shown in <FIG> are implemented as processes that include multiple operations, sub-processes, or other types of routines. In some cases, operations can be combined, performed in another order, performed in parallel, iterated, or otherwise repeated or performed another manner.

In one embodiment (embodiment <NUM>, shown in <FIG>), which is according to claimed invention, the following example procedure is used for discovery of a NPN with external service support. A UE autonomously scans applicable frequency bands for cells of 3GPP Network(s) and NPN(s) at 402A, detects that a cell supports a NPN based on the reserved PLMN-ID (broadcast by the cell) at 404A, and identifies the NID and the list of service networks (e.g., SN-IDs) supported by the NPN identified by NID at 406A. For the NPN Selection, the example procedure may be used. The UE detects a match between configured SN-IDs and available SN-IDs at 408A, selects the SN-ID among the discovered SN-IDs based on the prioritized list of configured SN-IDs at 410A, connects to a NID serving the Service Network identified as SN-ID and performs corresponding authentication procedures at 412A.

In another embodiment (embodiment <NUM>, shown in <FIG>), which is according to the claimed invention, for NPN Discovery where different reserved PLMN-IDs indicate support of non-public network service or external service in NPN), the following procedure is used. The UE autonomously scans applicable frequency bands for cells of 3GPP Network(s) and NPN(s) at 402B, and detects that a cell supports NPN based on the reserved PLMN-ID (broadcast by the cell) at 404B. Based on the reserved PLMN-ID, the UE determines at 406B if the detected NPN provides external services or non-public network services. If the reserved PLMN-ID indicates external services are provided by the NPN, the UE performs NPN discovery steps 408B, 410B, 412B (the same as steps 408A, 410A, 412A, respectively, described above with respect to Embodiment <NUM>). If, however, the reserved PLMN-ID indicates the NPN provides local, non-public network services, the UE may identify the NID and detect a match between a configured NID for the UE and optional configured non-public network service information (e.g. DNN, S-NSSAI, SSC mode, etc.) at 409B, and connects to the local/NPN services at 411B.

In another embodiment (embodiment <NUM>, shown in <FIG>), which is according to the claimed invention, for NPN Discovery where a bit (e.g., first bit) in NID indicates the support of non-public network service or external service in NPN), the following procedure is used. The UE autonomously scans applicable frequency bands for cells of 3GPP Network(s) and NPN(s) at 402C, detects that a cell supports NPN based on the reserved PLMN-ID at 404C, and identifies the NID and the list of SN-IDs supported by the NPN identified by NID at 406C. Based on the first bit of the NID, UE determines at 408C whether the NPN provides external services or local/non-public network services. If NID indicates support for external service, the UE performs NPN discovery steps 410C, 412C, 414C (the same as steps 408A, 410A, 412A, respectively, described above with respect to Embodiment <NUM>). If, however, NID indicates support for non-public network services, the UE may identify the NID (skipping the detection of SN-IDs list and NPN selection procedure) at 409C, detect a match between configured NID and optional configured non-public network service information (e.g. DNN, S-NSSAI, SSC mode, etc.) at 411C, and connect to the local/NPN services at 411C.

In some embodiments, the UE Configuration in NPN profile includes the indication for NPN deployment option <NUM> described above (the non-standalone case), or deployment options <NUM>, <NUM>, or <NUM>, which indicates the which NPN deployment option is enabled. If deployment option <NUM>, <NUM>, or <NUM> are enabled, the UE may follows the procedures described above to perform PLMN selection, and NPN discovery/selection. If deployment option <NUM> is enabled, loose coupling to a NR-RAN node may also be supported, which may require enhanced features for the RAN node in NPN. In this case, the differentiation of the NPN RAN node (referred to herein as a NPN-RAN node) and other NR-RAN nodes is needed. In some cases, the UE may be able to determine whether a detected Cell-ID of NPN-RAN node is NPN. Thus, a new NPN-Cell-ID may be designed as follows (e.g., as additions to TS <NUM>). The NPN may be a new category in NR-RAN-Node and the first [X] bits (e.g., the first bit) of the NPN-Cell-ID may indicate the NPN-RAN-Node ID. The UE NPN configuration profile can include one or more NPN-RAN-Node IDs supported by the UE. The UE may perform PLMN selection and select a cell which matches configured NPN-RAN-Node IDs.

In some embodiments, the NPN may use a UE Configuration Update procedure as described in TS <NUM> or <NUM> to configure NPN Profile configuration information for the UE with the following parameters. In some cases, The UE NPN configuration profile includes an indication of network deployment options (e.g. deployment option <NUM> (NPN interworks as a RAN node, type-a network), or Options <NUM>, <NUM>, or <NUM> (NPN with self-contained service or external services). In cases where deployment option <NUM> is indicated, the UE NPN configuration profile may include a set of NR-RAN-Node IDs supported by the UE. In cases where deployment options <NUM>, <NUM>, or <NUM> are indicated, the UE NPN configuration profile may include one or more of: a reserved global unique PLMN-ID and a list of SN-IDs in priority order. For each SN-ID in the configured SN-IDs list, the following parameters may be provided: authentication parameters (e.g., including credentials or authentication methods/procedures), Access Class information, local service information (e.g., DNN, S-NSSAI, SSC mode if network slicing is supported in Service network), or Service Network type (e.g., IMS, 5GS, EPS).

Claim 1:
An apparatus of a User Equipment, UE, device, the apparatus comprising:
memory (<NUM>) storing non-public network, NPN, configuration information;
radio frequency, RF, circuitry (<NUM>) configured to receive information broadcast by a radio access network, RAN, node (<NUM>, <NUM>) of a particular NPN (<NUM>), the information comprising a NPN indicator indicating that the RAN node supports a NPN and NPN service information indicating services supported by the particular NPN, wherein the NPN service information comprises a set of service network identifiers, SN-IDs, for respective external service networks, SNs, (<NUM>, <NUM>, <NUM>) supported by the particular NPN (<NUM>); and
processing circuitry (204E) coupled to the memory (<NUM>) and the RF circuitry (<NUM>), wherein the processing circuitry (204E) is configured to establish, in response to detecting the NPN indicator in the information received from the RAN node (<NUM>, <NUM>), a connection to the particular NPN (<NUM>) based on the NPN configuration information and the NPN service information received from the RAN node (<NUM>, <NUM>),
wherein the NPN configuration information indicates a network identifier, NID, supported by the UE device, the information broadcast by the RAN node (<NUM>, <NUM>) further comprises a NID for the particular NPN (<NUM>), and the processing circuitry (204E) is configured to establish the connection to the particular NPN (<NUM>) based on detecting that the NID in the NPN configuration information matches the NID for the particular NPN (<NUM>).