Patent Description:
The following abbreviations are herewith defined, at least some of which are referred to within the following description: Third Generation Partnership Project ("3GPP"), Authentication Authorization and Accounting ("AAA"), Positive-Acknowledgment ("ACK"), Access and Mobility Management Function ("AMF"), Authentication Server Function ("AUSF"), Downlink ("DL"), Domain Name System("DNS"), Enhanced Mobile Broadband ("eMBB"), Evolved Node B ("eNB"), Enhanced Subscriber Identification Module ("eSIM"), Equipment Identity Register ("EIR"), European Telecommunications Standards Institute ("ETSI"), Frequency Division Duplex ("FDD"), Frequency Division Multiple Access ("FDMA"), Fully Qualified Domain Name ("FQDN"), Global System For Mobile Communications Association ("GSMA"), Hybrid Automatic Repeat Request ("HARQ"), Home Policy Control Function ("H-PCF"), Home Public Land Mobile Network ("HPLMN"), International Mobile Equipment Identity ("IMEI"), International Mobile Subscriber Identity ("IMSI"), Internet-of- Things ("IoT"), Long Term Evolution ("LTE"), Multiple Access ("MA"), Modulation Coding Scheme ("MCS"), Mobile Country Code ("MCC"), Mobile Network Code ("MNC"), Machine Type Communication ("MTC"), Master Information Block ("MIB), Mobility Management ("MM"), Non-Access Stratum ("NAS"), Narrowband ("NB"), Negative-Acknowledgment ("NACK") or ("NAK"), Next Generation Node B ("gNB"), Orthogonal Frequency Division Multiplexing ("OFDM"), Over-the-Air ("OTA"), Policy Control Function ("PCF"), Public Land Mobile Network ("PLMN"), Pointer ("PTR"), Quality of Service ("QoS"), Radio Resource Control ("RRC"), Radio Access Network ("RAN"), Receive ("RX"), Single Carrier Frequency Division Multiple Access ("SC-FDMA"), Subscriber Management Function ("SMF"), Subscriber Identity Module ("SIM"), System Information Block ("SIB"), Subscription Concealed Identifier ("SUCI"), Subscription Permanent Identifier ("SUPI"), Transmit ("TX"), Unified Data Management ("UDM"), User Data Repository ("UDR"), User Entity/Equipment (Mobile Terminal) ("UE"), Universal Integrated Circuit Card ("UICC"), Uplink ("UL"), Universal Mobile Telecommunications System ("UMTS"), User Plane Function ("UPF"), Universal Subscriber Identity Module ("USIM"), Visited Policy Control Function ("V-PCF"), Visited Public Land Mobile Network ("VPLMN"), and Worldwide Interoperability for Microwave Access ("WiMAX"). As used herein, "HARQ-ACK" may represent collectively the Positive Acknowledge ("ACK") and the Negative Acknowledge ("NAK"). ACK means that a TB is correctly received while NAK means a TB is erroneously received.

In certain wireless communications networks, a remote unit may have multiple networks that may be communicated with. In such networks, the remote unit may be subscribed to only one network out of the multiple networks.

<CIT> describes a method for detecting an inability to serve a UE in the selected serving node due to mismatch between the UE's DCN-related indication and the UE's DCN-related subscription and/or the UE's capabilities and/or due to serving node congestion. <CIT> describes a method that includes selecting a to-be-accessed dedicated core network (DCN) from at least one DCN according to obtained first DCN information, and sending information about the to-be-accessed DCN to an access network device, so that the access network device determines a core network device according to the information about the to-be-accessed DCN. <CIT> describes providing network access to mobile terminals (MTs) in a packet data network that uses Protocol for Carrying Authentication for Network Access (PANA) and Point-to-Point Protocol (PPP) simultaneously. <CIT> describes using network slicing, wherein a network slice instance is in an instantiated form of a network slice that includes at least one network function and resource for providing a network service having a predetermined capability and characteristic to a user equipment.

Claim <NUM> defines a method performed by a remote unit, claim <NUM> defines a remote unit, claim <NUM> defines a method performed by a network unit, and claim <NUM> defines a network unit. In the following, any method and/or apparatus referred to as embodiments but nevertheless do not fall within the scope of the appended claims are to be understood as examples helpful in understanding the invention.

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

In one embodiment, the remote units <NUM> may include computing devices, such as desktop computers, laptop computers, personal digital assistants ("PDAs"), tablet computers, smart phones, smart televisions (e.g., televisions connected to the Internet), set-top boxes, game consoles, security systems (including security cameras), vehicle on-board computers, network devices (e.g., routers, switches, modems), IoT devices, or the like. The remote units <NUM> may communicate directly with one or more of the network units <NUM> via UL communication signals.

In certain embodiments, a network unit <NUM> may also be referred to as an access point, an access terminal, a base, a base station, a Node-B, an eNB, a gNB, a Home Node-B, a relay node, a device, a network device, or by any other terminology used in the art. In some embodiments, a network unit <NUM> may include one or more of the following network components a gNB, an AMF, a DB, a PCF, a UDR, a UPF, and/or a UDM.

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

In certain embodiments, a remote unit <NUM> may transmit a first message including a first registration request. In various embodiments, the remote unit <NUM> may receive a second message including a first indication of a network to which the remote unit <NUM> belongs. In such embodiments, the second message is received in response to transmitting the first message. In some embodiments, the remote unit <NUM> may transmit a third message including a second registration request. In such embodiments, the second registration request includes a second indication of the network to which the remote unit <NUM> belongs, and the second indication is based on the first indication. Accordingly, a remote unit <NUM> may be used for receiving an indication of a network for the remote unit <NUM>.

In various embodiments, a network unit <NUM> may receive a first message including information corresponding to a registration request transmitted from a remote unit <NUM>. In various embodiments, the network unit <NUM> may determine a network to which the remote unit <NUM> belongs. In some embodiments, the network unit <NUM> may transmit a second message including an indication of the network to which the remote unit <NUM> belongs. In such embodiments, the second message is transmitted in response to receiving the first message. Accordingly, a network unit <NUM> may be used for indicating a network for the remote unit <NUM>.

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

In some embodiments, the memory <NUM> stores data relating to network registration.

The transmitter <NUM> is used to provide UL communication signals to the network unit <NUM> and the receiver <NUM> is used to receive DL communication signals from the network unit <NUM>. In certain embodiments, the transmitter <NUM> is used to transmit a first message including a first registration request from the apparatus <NUM>. In various embodiments, the receiver <NUM> is used to receive a second message including a first indication of a network to which the apparatus <NUM> belongs. In such embodiments, the second message is received in response to transmitting the first message. In some embodiments, the transmitter <NUM> is used to transmit a third message including a second registration request from the apparatus <NUM>. In such embodiments, the second registration request includes a second indication of the network to which the apparatus <NUM> belongs, and the second indication is based on the first indication.

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

In various embodiments, the receiver <NUM> is used to receive a first message including information corresponding to a registration request transmitted from a remote unit <NUM>. In various embodiments, the processor <NUM> is used to determine a network to which the remote unit <NUM> belongs. In some embodiments, the transmitter <NUM> is used to transmit a second message including an indication of the network to which the remote unit <NUM> belongs. In such embodiments, the second message is transmitted in response to receiving the first message. Although only one transmitter <NUM> and one receiver <NUM> are illustrated, the network unit <NUM> may have any suitable number of transmitters <NUM> and receivers <NUM>.

In some embodiments, credentials for a remote unit <NUM> (e.g., IoT UE) may be found in a UDM, but not in the remote unit <NUM>. In such embodiments, the subscriber (e.g., a big company) may buy many remote units <NUM> (e.g., IoT devices, a set of IoT devices, etc.) and a subscription for each remote unit <NUM>. Moreover, all of the remote units <NUM> may be considered "off the shelf" - meaning that the remote units <NUM> do not have credentials stored in the remote units <NUM>. As may be appreciated, credentials as used herein may mean network information such as a home PLMN, subscription information, authentication information, access information, and so forth.

In addition, the remote unit <NUM> operator does not have information about the remote units <NUM>, but the remote unit <NUM> operator reserves credentials in a UDM and/or AUSF and creates a corresponding number of subscription profiles (e.g., one for each remote unit <NUM>). The subscriber provides the remote unit <NUM> operator with information of the device identities ("IDs") (e.g., this may be an IMEI or a unique identifier) which is used for binding the remote units <NUM> to the subscription profile. Because the remote units <NUM> do not have any information about their subscription, the remote units <NUM> won't necessarily be able to connect to the correct PLMN on a first try but instead may select an initial PLMN based on a strongest radio signal. In order to find the correct PLMN, the remote unit <NUM> operator may configure a database (e.g., a global database, a country database, etc.) with the binding information of device IDs and subscription IDs. In one embodiment, the subscription IDs may each include IMSI, SUPI, and/or SUCI (e.g., the encrypted SUPI) and may point to an operator identity ("ID") (e.g., MNC and/or MCC). In some embodiments, the subscription IDs may be a group SUPI (e.g., a special SUPI identifying a pool of subscriptions from which the UDM activates the subscriber profiles). In various embodiments, the subscription IDs may include a list of PLMNs (e.g., especially in response to a remote unit <NUM> being roaming or otherwise unavailable to a HPLMN). If the subscription IDs use one or more SUPI, encryption of the SUPI may be performed in a mobile operator domain (e.g., the UDM) and stored encrypted in a database. This may be because the database holding the subscription information may be outside the mobile operator domain (and may therefore not have an unencrypted subscription ID, such as for privacy and/or security). In some embodiments, a subscription database may be globally maintained by an organization (e.g., GSMA) and/or may be specific within a country (e.g., maintained by an independent organization). In various embodiments, the subscription database may be part of an EIR and/or may be collocated with any network function (e.g., AMF, SMF, UDM, etc.). In certain embodiments, the remote unit <NUM> operator may be able to detect if an unsubscribed remote unit <NUM> pretends to use one of its registered subscriptions based on an initial encrypted SUPI (which is not time dependent). In some embodiments, a remote unit <NUM> may encrypt a SUPI in a time dependent manner to minimize replay attacks. In various embodiments, a remote unit <NUM> may be preconfigured with and/or able to generate an encryption key (e.g., public and/or private key, certificate) and may be able to store an encryption key from a network. In certain embodiments, if preconfigured encryption keys are installed in a remote unit <NUM>, then a subscription database may authenticate a request from the remote unit <NUM>.

<FIG> and <FIG> illustrate registration requests sent to a PLMN with different options. In <FIG>, a remote unit <NUM> (e.g., UE) subscription belongs to a PLMN that it sends a registration request to; while in <FIG>, a remote unit <NUM> (e.g., UE) subscription does not belong to a PLMN that it sends a registration request to. As used herein, a remote unit <NUM> may "belong" to a network if the remote unit <NUM> has a subscription for the network.

<FIG> illustrates one embodiment of communications <NUM> for registering a device (e.g., a remote unit <NUM>). Specifically, communications <NUM> between a UE <NUM>, an AMF <NUM>, a database ("DB") (e.g., a subscription binding database, a device identification binding database, etc.) <NUM>, a UDM <NUM>, and a UPF <NUM> are illustrated. As may be appreciated, any of the communications <NUM> described herein may be considered messages and/or parts of messages.

In some embodiments, the UE <NUM> performs <NUM> PLMN selection and sends a registration request for IoT registration to the AMF <NUM>. In certain embodiments, a RAN may be configured to broadcast (e.g., in SIB or MIB) an indication that a network supports IoT restricted registration procedure with PLMN discovery. In such embodiments, the UE <NUM> may use this information to perform PLMN selection (e.g., the UE <NUM> may first try networks which support a IoT restricted registration procedure before trying the PLMNs that do not broadcast this information). In various embodiments, the UE <NUM> may indicate that the registration request is for initial IoT registration and may include an encryption key (e.g., a public key, a certificate). In such embodiments, if the encryption key is preconfigured to the UE <NUM> and included in the registration request, then the UE <NUM> may be authenticated (e.g., in the AMF <NUM> or DB <NUM>). In certain embodiments, the registration request may include a discovery indication indicating that the UE <NUM> is attempting to discover a network configured for use by the remote unit.

In various embodiments, the AMF <NUM> detects <NUM> that a registration request is for initial IoT registration and requests that the UE <NUM> sends it's device ID in order to retrieve a SUPI. In certain embodiments, if the UE <NUM> includes a certificate, the AMF <NUM> may determine (e.g., verify) whether it trusts the UE <NUM>. In some embodiments, the AMF <NUM> may encrypt a reply to the registration request with the UE's <NUM> encryption key and include an encryption key (e.g., a public key, a certificate) for the AMF <NUM>. In such embodiments, the UE <NUM> may verify the AMF <NUM> encryption key if available and the UE <NUM> may send its device ID (e.g., IMEI, a unique string - such as a device manufacturer globally uniquely provisioned string) encrypted with the AMF <NUM> encryption key to the AMF <NUM>. In one embodiment, if the UE <NUM> has not provided its encryption key, the UE <NUM> may include its encryption key.

In certain embodiments, the AMF <NUM> contacts <NUM> the DB <NUM>. In some embodiments, the DB <NUM> may be broadly maintained (e.g., by an organization such as GSMA, by a specific organization within a country, by an independent organization, globally, geographically, etc.). In various embodiments, in the DB <NUM>, a SUPI corresponding to a device ID may be stored with the device ID. In such embodiments, the SUPI may be preconfigured and/or encrypted (e.g., SUCI). In certain embodiments, the DB <NUM> may authenticate the registration request from the UE <NUM> if an encryption key is present and may provide an encrypted SUPI (e.g., which includes a PLMN ID - such as MNC and/or MCC) to the AMF <NUM>. In some embodiments, if the UE <NUM> cannot be authenticated or there is no database entry corresponding to the device ID (e.g., the database entry never existed, the database entry was removed, etc.), then the DB <NUM> may reject the registration request. In certain embodiments, interaction between the AMF <NUM> and the DB <NUM> may be similar to interactions between the AMF <NUM> and the UDM <NUM> and/or interactions between the AMF <NUM> and an AAA server.

In some embodiments, the AMF <NUM> may detect <NUM> whether the UE <NUM> is part of the same PLMN as the AMF <NUM> by comparing an unencrypted MNC and/or MCC of a SUPI. In certain embodiments, if the UE <NUM> has the subscription with another PLMN, the AMF <NUM> sends a registration request reject to the UE <NUM>. In various embodiments, the registration request reject may include the SUPI (e.g., encrypted SUPI, an indication of a network to which the UE <NUM> belongs). In some embodiments, the UE <NUM> stores the SUPI and uses MNC and/or MCC for PLMN selection. In certain embodiments, the UE <NUM> may not have credentials to unencrypt a SUPI. In various embodiments, the UE <NUM> selects a PLMN from the SUPI and sends a new registration request for IoT registration to the AMF <NUM>. The new registration request may indicate that the registration request is for IoT initial registration and may include an encryption key (e.g., a public key, a certificate) and SUPI (e.g., encrypted SUPI).

In various embodiments, if the UE <NUM> belongs to the same PLMN, then long term credentials, USIM, and/or eSIM are provisioned <NUM> to the UE <NUM>. As may be appreciated, there may be different technologies to provision the long term credentials, the USIM, and/or the eSIM to the UE <NUM>. In some embodiments, there may be messages exchanged between various devices or functions to signal a credential server (e.g., OTA server) identity and address, a UICC ID, a UICC vendor ID of the UE <NUM>, and/or OTA keys for securing credentials.

In certain embodiments, after successfully provisioning long term credentials, USIM, and/or eSIM, the AMF <NUM> sends <NUM> an IoT subscription profile activation request to the UDM <NUM>. In some embodiments, the IoT subscription profile activation request may include a device ID and a SUPI. In various embodiments, after successful provisioning the AMF <NUM> may send a registration accept for IoT indicating that the network is ready to receive a real registration from the UE <NUM>. In certain embodiments, the UE <NUM> may use received credentials to register with a network. In some embodiments, once the AMF <NUM> receives a registration request, the registration request may trigger a subscription profile activation request, which may be a normal UDM subscriber profile query.

In some embodiments, the UDM <NUM> verifies <NUM> the SUPI and device ID binding, verifies whether it is the first request for subscription activation, and/or verifies whether there was no misuse of a SUPI (e.g., initial and/or encrypted). In one embodiment, the UDM <NUM> activates a subscription profile corresponding to the device ID.

In various embodiments, the UDM <NUM> provides <NUM> a subscription profile corresponding to the UE <NUM> to the AMF <NUM>. In certain embodiments, the AMF <NUM> may not run any authentication and/or authorization procedure at this time because the UE <NUM> may not be provisioned with corresponding credentials. In some embodiments, the subscription profile may contain the SUPI (e.g., unencrypted).

In certain embodiments, the AMF <NUM> sends <NUM> a registration accept to the UE <NUM>.

<FIG> illustrates another embodiment of communications <NUM> for registering a device (e.g., a remote unit <NUM>). Specifically, communications <NUM> between a UE <NUM>, a first AMF <NUM> (e.g., AMF of a first PLMN), a second AMF <NUM> (e.g., AMF of a second PLMN), a DB <NUM>, a UDM <NUM>, and a UPF <NUM> are illustrated. As may be appreciated, any of the communications <NUM> described herein may be considered messages and/or parts of messages.

In some embodiments, a first communication <NUM> from the UE <NUM> to the first AMF <NUM> may include the UE <NUM> performing PLMN selection and sending a registration request for IoT registration to the first AMF <NUM>. In certain embodiments, a RAN may be configured to broadcast (e.g., in SIB or MIB) an indication that a network supports IoT restricted registration procedure with PLMN discovery. In such embodiments, the UE <NUM> may use this information to perform PLMN selection (e.g., the UE <NUM> may first try networks which support a IoT restricted registration procedure before trying the PLMNs that do not broadcast this information). In various embodiments, the UE <NUM> may indicate that the registration request is for initial IoT registration and may include an encryption key (e.g., a public key, a certificate). In such embodiments, if the encryption key is pre-provisioned to the UE <NUM> and included in the registration request, then the UE <NUM> may be authenticated (e.g., in the first AMF <NUM> or DB <NUM>). In certain embodiments, the registration request may include a discovery indication indicating that the UE <NUM> is attempting to discover a network configured for use by the remote unit.

In various embodiments, a second communication <NUM> from the first AMF <NUM> to the UE <NUM> may include the first AMF <NUM>, after it detects that a registration request is for initial IoT registration, requesting that the UE <NUM> sends it's device ID in order to retrieve a SUPI. In certain embodiments, if the UE <NUM> includes a certificate, the first AMF <NUM> may determine (e.g., verify) whether it trusts the UE <NUM>. In some embodiments, the first AMF <NUM> may encrypt a reply to the registration request with the UE's <NUM> encryption key and include an encryption key (e.g., a public key, a certificate) for the first AMF <NUM>.

In a third communication <NUM> from the UE <NUM> to the first AMF <NUM>, the UE <NUM>, after verifying the first AMF <NUM> encryption key if available, may send its device ID (e.g., IMEI, a unique string - such as a device manufacturer globally uniquely provisioned string) encrypted with the first AMF <NUM> encryption key to the first AMF <NUM>. In one embodiment, if the UE <NUM> has not provided its encryption key, the UE <NUM> may include its encryption key.

In certain embodiments, in a fourth communication <NUM> from the first AMF <NUM> to the DB <NUM>, the first AMF <NUM> may contact the DB <NUM> to request a SUPI corresponding to the device ID of the UE <NUM>. In some embodiments, the DB <NUM> may be broadly maintained (e.g., by an organization such as GSMA, by a specific organization within a country, by an independent organization, globally, geographically, etc.). In various embodiments, in the DB <NUM>, a SUPI corresponding to a device ID may be stored with the device ID and/or a list of one or more PLMNs corresponding to the device ID may be stored with the device ID. In such embodiments, the SUPI may be preconfigured and/or encrypted.

In some embodiments, the DB <NUM> may authenticate <NUM> the registration request from the UE <NUM> if an encryption key is present. In certain embodiments, if the UE <NUM> cannot be authenticated or there is no database entry corresponding to the device ID (e.g., the database entry never existed, the database entry was removed, etc.), then the DB <NUM> may reject the registration request.

In various embodiments, in a fifth communication <NUM> from the DB <NUM> to the first AMF <NUM>, the DB <NUM> may provide an encrypted SUPI (e.g., which includes a PLMN ID - such as MNC and/or MCC) corresponding to the device ID of the UE <NUM> to the first AMF <NUM> and/or the DB <NUM> may provide a list of one or more PLMNs corresponding to the device ID of the UE <NUM> to the first AMF <NUM>. In certain embodiments, interaction between the first AMF <NUM> and the DB <NUM> may be similar to interactions between the first AMF <NUM> and the UDM <NUM> and/or interactions between the first AMF <NUM> and an AAA server.

In certain embodiments, the first AMF <NUM> may detect <NUM> whether the UE <NUM> is part of the same PLMN as the first AMF <NUM> by comparing an unencrypted MNC and/or MCC of a SUPI and/or by comparing a PLMN of the first AMF <NUM> to the list of one or more PLMNs corresponding to the device ID of the UE <NUM>.

In a sixth communication <NUM> from the first AMF <NUM> to the UE <NUM>, the first AMF <NUM> sends a registration reject to the UE <NUM> in response to determining that the UE <NUM> is not part of the same PLMN as the first AMF <NUM>. In some embodiments, the registration reject may include an encrypted SUPI corresponding to the device ID of the UE <NUM> and/or a list of one or more PLMNs corresponding to the device ID of the UE <NUM> (e.g., an indication of a network to which the UE <NUM> belongs). In certain embodiments in which an encrypted SUPI is sent as part of the registration reject, then the message may be encrypted with the UE's <NUM> encryption key to protect the encrypted SUPI (e.g., because SUPI encryption may not be time dependent, not encrypting the SUPI with the encryption key may lead to replay attacks if leaked to an attacker pretending to be the real subscriber belonging to the SUPI). In various embodiments, the first AMF <NUM> receives a registration request with a PLMN discovery indication. In such embodiments, the first AMF <NUM> may construct an FQDN in the form <deviceld>. provisioning. 3GPPnetwork. org and send a DNS PTR query with this FQDN. Essentially, this DNS query attempts to find all provisioning servers that can be used to provision the UE <NUM>. The DNS response could include a list of equivalent PLMNs, such as:.

In various embodiments, the UE <NUM> may store <NUM> an encrypted SUPI and may extract MNC and/or MCC from the encrypted SUPI in order to know the PLMN ID of the subscription corresponding to the UE <NUM>. In some embodiments, the UE <NUM> performs PLMN selection and selects its HPLMN = a second PLMN (e.g., PLMN indicated by the PLMN ID).

In a seventh communication <NUM> from the UE <NUM> to the second AMF <NUM>, the UE <NUM> sends a registration request for IoT registration to the second AMF <NUM>. In some embodiments, the UE <NUM> indicates that the registration request is for IoT initial registration and may include its encryption key (e.g., public key, certificate). In certain embodiments, the registration request may include an indication (e.g., flag) used to indicate that a HPLMN query with the DB <NUM> is not required. In various embodiments, an intermediate RAN detects that the registration request is for IoT registration based on the indication in the request and selects an appropriate AMF. In some embodiments, there may be a dedicated AMF for handling initial IoT registration requests. In certain embodiments, the UE <NUM> may include a PLMN ID in the registration request (e.g., an indication of the network to which the UE <NUM> belongs). In such embodiments, the PLMN ID may be selected from a list of one or more PLMNs received from the DB <NUM>. In various embodiments, the second AMF <NUM> may detect that a PLMN ID received is a PLMN ID for initial IoT registration.

In an eighth communication <NUM> from the second AMF <NUM> to the UE <NUM>, the second AMF <NUM> detects that the registration request is for initial IoT registration and requests with a request for the UE <NUM> to send it's device ID. In some embodiments, if the UE <NUM> has included an encryption key transmission to the second AMF <NUM>, the second AMF <NUM> may verify whether it trusts the UE <NUM>. In certain embodiments, the second AMF <NUM> may encrypt the request with the UE's <NUM> encryption key if available and include it's second AMF <NUM> encryption key (e.g., public key, certificate).

In a ninth communication <NUM> from the UE <NUM> to the second AMF <NUM>, after the UE <NUM> verifies the second AMF <NUM> encryption key (if available), the UE <NUM> may send its encrypted SUPI and Device ID (e.g., IMEI, a unique string - such as a device manufacturer globally uniquely provisioned string) encrypted with the second AMF <NUM> encryption key to the second AMF <NUM>. In one embodiment, if the UE <NUM> has not provided its encryption key, the UE <NUM> may include its encryption key.

In a tenth communication <NUM> from the second AMF <NUM> to the DB <NUM>, the second AMF <NUM> may detect that the UE <NUM> identified SUPI is part of the same PLMN as the second AMF <NUM>. In some embodiments, the second AMF <NUM> may not trust the UE <NUM> information and may sends a SUPI Request to the DB <NUM> in order to verify the binding between the UE <NUM> and the SUPI, to determine whether the SUPI is compromised, to determine whether the DB <NUM> has deleted its reference to the UE <NUM>, and/or to determine whether the UE <NUM> is blacklisted in the DB <NUM>.

In some embodiments, the DB <NUM> may verify <NUM> the request and determine whether a request for this SUPI was previously sent, determine whether the DB <NUM> has been notified that the profile belonging to this SUPI has already been activated, and/or determine whether the entry for this SUPI has been deleted (e.g., due to a termination of the subscription, prior registration, etc.).

In an eleventh communication <NUM> from the DB <NUM> to the second AMF <NUM>, the DB <NUM> provides the encrypted SUPI corresponding to the device ID sent from the UE <NUM> (e.g., the SUPI may be a random identity that has a correct PLMN ID - such as including MNC and/or MCC) back to the second AMF <NUM>. In certain embodiments, the tenth communication <NUM>, the verify <NUM>, and the eleventh communication <NUM> may not be performed if the second AMF <NUM> trusts the UE <NUM> SUPI information. In some embodiments, the UE <NUM> may be preconfigured with an encryption key and may be authenticated in the second AMF <NUM>.

In certain embodiments, if the UE <NUM> belongs to the same PLMN, the UE <NUM> may connect <NUM> to a credentials server with its unencrypted SUPI and retrieve long term credentials (e.g., a USIM, an eSIM profile, etc.). In various embodiments, there may be different technologies to provision long term credentials, a USIM, and/or an eSIM to the UE <NUM> and there may be some message exchange to signal the credential server (e.g., OTA Server) identity and address, a UICC ID, a UICC vendor ID of the UE <NUM>, and/or OTA keys for securing credentials.

In a twelfth communication <NUM> from the second AMF <NUM> to the UE <NUM>, the second AMF <NUM> may send a registration accept to the UE <NUM> to indicate successful registration for profile provisioning.

In a thirteenth communication <NUM> from the UE <NUM> to the second AMF <NUM>, the UE <NUM> may send a new registration request for initial registration to the second AMF <NUM>, now using the newly provisioned profile.

In various embodiments, the second AMF <NUM> may perform <NUM> UDM selection. In some embodiments, there may be a dedicated UDM <NUM> for handling IoT registration and activation requests.

In a fourteenth communication <NUM> from the second AMF <NUM> to the UDM <NUM>, the second AMF <NUM> sends an IoT subscription profile activation request to the UDM <NUM>. In such embodiments, the subscription profile activation request may include the device ID corresponding to the UE <NUM> and the encrypted SUPI.

In some embodiments, the UDM <NUM> may verify <NUM> the encrypted SUPI and device ID binding, may determine whether it is the first request for subscription activation, and/or may determine whether there is misuse of the encrypted SUPI (e.g., initial misuse). In various embodiments, after verifying <NUM> the encrypted SUPI and device ID binding, the UDM <NUM> may activate the corresponding subscription profile.

In certain embodiments, the UDM <NUM> may notify <NUM> the DB <NUM> that the subscription for the SUPI and/or PLMN paired with the device ID has been successfully activated and that the DB <NUM> now should reject any further requests and/or that the DB <NUM> should delete the entry from the database.

In a fifteenth communication <NUM> from the UDM <NUM> to the second AMF <NUM>, the UDM <NUM> acknowledges the activation of the subscription profile to the second AMF <NUM>. In some embodiments, the subscription profile may contain the SUPI (e.g., unencrypted).

In one embodiment, the second AMF <NUM> may run <NUM> a normal authentication and/or authorization procedure, because the UE <NUM> is provisioned with corresponding credentials for authentication and/or authorization. In some embodiments, the authentication and/or authorization procedure may involve an AUSF.

In a sixteenth communication <NUM> from the second AMF <NUM> to the UDM <NUM>, the second AMF <NUM> may invoke a Nudm_UEContextManagement_Registration service operation towards the UDM <NUM> including a subscription data retrieval indication. In some embodiments, the sixteenth communication <NUM> is not needed if it is performed as part of another communication.

In a seventeenth communication <NUM> from the UDM <NUM> to the second AMF <NUM>, the UDM <NUM> invokes a Nudm_SubscriptionData_UpdateNotification service operation to provide subscription data from the UDM <NUM>. The second AMF <NUM> creates an MM context for the UE <NUM> after getting the mobility related subscription data from the UDM <NUM>. In some embodiments, the seventeenth communication <NUM> is not needed if it is performed as part of another communication.

In an eighteenth communication <NUM> from the second AMF <NUM> to the UE <NUM>, the second AMF <NUM> sends a registration accept to the UE <NUM>.

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

The method <NUM> may include transmitting <NUM> a first message including a first registration request from a remote unit <NUM>. In various embodiments, the method <NUM> includes receiving <NUM> a second message including a first indication of a network to which the remote unit <NUM> belongs. In such embodiments, the second message is received in response to transmitting the first message. In certain embodiments, the method <NUM> includes transmitting <NUM> a third message including a second registration request from the remote unit <NUM>. In such embodiments, the second registration request includes a second indication of the network to which the remote unit <NUM> belongs, and the second indication is based on the first indication.

In one embodiment, the method <NUM> includes determining a set of available mobile networks. In a further embodiment, the method <NUM> includes determining a first mobile network of the set of available mobile networks based on information indicating that the first mobile network supports internet-of-things device registration. In certain embodiments, transmitting the first message includes transmitting the first message to the first mobile network of the set of available mobile networks. In various embodiments, transmitting the third message includes transmitting the third message to a second mobile network of the set of available mobile networks, and the second mobile network is determined based on the first indication.

In some embodiments, the first registration request and the second registration request each include an internet-of-things initial registration request. In various embodiments, the first message and the third message each include an encryption key corresponding to the remote unit <NUM>. In one embodiment, the second message includes an encryption key corresponding to a network device (e.g., a network unit <NUM>). In certain embodiments, the first indication includes a subscription identifier, a home network identifier, or a combination thereof corresponding to the remote unit <NUM>. In various embodiments, the remote unit <NUM> includes an internet-of-things device out of a set of internet-of-things devices.

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

The method <NUM> may include receiving <NUM> a first message including information corresponding to a registration request transmitted from a remote unit <NUM>. In some embodiments, the first message may be received by an AMF; while, in other embodiments, the first message may be received by a subscription database. In various embodiments, the method <NUM> includes determining <NUM> a network to which the remote unit <NUM> belongs. In certain embodiments, the method <NUM> includes transmitting <NUM> a second message including an indication of the network to which the remote unit <NUM> belong. In such embodiments, the second message is transmitted in response to receiving the first message.

In one embodiment, the registration request includes an internet-of-things initial registration request. In a further embodiment, the first message includes an encryption key corresponding to the remote unit <NUM>. In certain embodiments, the second message includes an encryption key corresponding to a network device (e.g., a network unit <NUM>). In some embodiments, the indication includes a subscription identifier, a home network identifier, or a combination thereof corresponding to the remote unit <NUM>.

In some embodiments, the remote unit <NUM> includes an internet-of-things device out of a set of internet-of-things devices. In certain embodiments, determining the network to which the remote unit <NUM> belongs further includes transmitting a request to a database for the indication of the network to which the remote unit <NUM> belongs. In various embodiments, determining the network to which the remote unit belongs further includes receiving a response to the request from the database, and the response includes the indication of the network to which the remote unit <NUM> belongs. In one embodiment, receiving the first message includes receiving the first message at a database.

In a further embodiment, the database is configured with an identifier corresponding to the remote unit <NUM> and subscription information corresponding to the remote unit. In some embodiments, the first message includes information identifying the remote unit <NUM>. In certain embodiments, the method <NUM> includes determining whether the remote unit <NUM> is roaming.

In various embodiments, the method <NUM> includes determining whether the remote unit <NUM> is reachable by a home mobile network at a current location of the remote unit <NUM>. In one embodiment, the method <NUM> includes receiving a third message indicating that a subscription corresponding to the remote unit <NUM> is successfully activated. In a further embodiment, the method <NUM> includes rejecting a fourth message related to the subscription.

Claim 1:
A method (<NUM>) performed by a remote unit, the method comprising:
transmitting (<NUM>) a first message to a first network unit of a first network, the first message comprising a first internet-of-things registration request for restricted access for PLMN discovery;
receiving (<NUM>) a second message from the first network unit, the second message comprising a first indication of at least one network to which the remote unit belongs, wherein the second message is received in response to transmitting the first message; and
transmitting (<NUM>) a third message to a second network unit, the third message comprising a second internet-of-things registration request, wherein the second internet-of-things registration request comprises a second indication of a network to which the remote unit belongs, and the second indication is selected from the first indication.