Method and apparatus for zero-touch bulk identity assignment, provisioning and network slice orchestration for massive IOT (MIOT) deployments

In one illustrated example, automated or semi-automated system operations for Massive IoT (MIoT) deployment may involve the automatic assignment of external IDs, subscriber IDs (e.g. IMSIs), and mobile network IDs (e.g. MSISDNs) to IoT devices of a group, followed by the provisioning of assigned identities at the relevant network nodes and the IoT devices themselves. The process may continue seamlessly with network slice orchestration for the creation of a network slice instance (NSI) and the provisioning of its associated Network Slice Selection Assistance Information (NSSAI) and NSI ID at the relevant network nodes. Network Slice Selection Policies (NSSP) may be derived and sent to a policy function and subsequently to IoT devices of the group. Signaling efficiency may be achieved by performing operations on a group basis.

TECHNICAL FIELD

The present disclosure relates generally to deploying a plurality of Internet of Things (IoT) devices in a mobile network in a Massive IoT (MIoT) deployment, and more particularly to a zero-touch bulk identity assignment, provisioning, and network slice orchestration for an MIoT deployment.

BACKGROUND

The term “Massive IoT” (MIoT) refers to the connection and use of an incredibly large number (potentially tens of billions) of IoT devices and/or machines for communications via a mobile network. Given the large number of devices in an MIoT deployment, there is a need for efficient methods and apparatus for use in identity assignment, provisioning, and/or network slice orchestration in a mobile network.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

Automated or semi-automated system operations for “zero-touch” bulk identity assignment, provisioning, and network slice orchestration for massive IoT (MIoT) deployment in a mobile network are described herein.

In one illustrated example, the operations may involve the automatic assignment of external IDs, subscriber IDs, and mobile network IDs to IoT devices of a group, followed by the provisioning of the assigned identities at relevant network nodes and the IoT devices themselves. In some implementations, operations may continue seamlessly with network slice orchestration for the creation of a network slice instance (NSI) and the provisioning of its associated Network Slice Selection Assistance Information (NSSAI) and NSI ID at the relevant network nodes. Network Slice Selection Policies (NSSP) may also be derived and sent to a policy function and IoT devices of the group. Signaling efficiency may be achieved by performing operations on a group basis.

More detailed and alternative techniques and implementations are provided herein as described below.

Example Embodiments

According to at least some implementations of the present disclosure, massive IoT (MIoT) deployment may be performed with use of automated or semi-automated system operations in a mobile network. The operations may involve the automatic assignment of external identities and network identities (e.g. SUPI/IMSI and MSISDN) to a plurality of IoT devices of a group, and a propagation of mappings of the assigned identities to an operations support system (OSS) domain (e.g. an application server or “AS”), a 5G core network, a 5G Network Exposure Function (NEF), and SIM server for provisioning the IoT devices. Operations may continue seamlessly with network slice orchestration, for the creation of a network slice instance (NSI) and the provisioning of associated Network Slice Selection Assistance Information (NSSAI) and NSI ID at the relevant network nodes. Network Slice Selection Policies (NSSP) may also be derived and sent to a policy function and thereafter to the IoT devices of the group.

To better illustrate,FIG. 1Ais an illustrative representation of a network architecture100A of a 5G mobile network configured to facilitate communications for a user equipment (UE)102. UE102may be an IoT or similar device. In general, network architecture100aincludes common control network functions (CCNF)105and a plurality of slice-specific core network functions106. UE102may obtain access to the mobile network via an access network (AN)104, which may be a radio access network (RAN). In the present disclosure, the UEs operating in the 5G mobile network may be any suitable type of devices, such as cellular telephones, smart phones, tablet devices, IoT devices, and machine-to-machine (M2M) communication devices, to name but a few. Techniques of the present disclosure may involve UEs that are IoT devices in an MIoT deployment.

CCNF105includes a plurality of network functions (NFs) which commonly support all sessions for UE102. UE102may be connected to and served by a single CCNF105at a time, although multiple sessions of UE102may be served by different slice-specific core network functions106. CCNF105may include, for example, an access and mobility management function (AMF) and a network slice selection function (NSSF). UE-level mobility management, authentication, and network slice instance selection are examples of common functionalities provided by CCNF105.

Slice-specific core network functions of network slices106are separated into control plane (CP) NFs108and user plane (UP) NFs110. In general, the user plane carries user traffic while the control plane carries network signaling. CP NFs108are shown inFIG. 1Aas CP NF1through CP NF n, and UP NFs110are shown inFIG. 1Aas UP NF1through UP NF n. CP NFs108may include, for example, a session management function (SMF), whereas UP NFs110may include, for example, a user plane function (UPF).

FIG. 1Bis an illustrative representation of a more detailed network architecture100B of the 5G mobile network ofFIG. 1A. As provided in 3GPP standards for 5G (e.g. 3GPP 23.501 and 23.502), network architecture100bfor the 5G mobile network which is operated by a mobile network operator (MNO) may include an authentication server function (AUSF)116, a unified data management (UDM)118(having a unified data repository or UDR), an AMF112, a policy control function (PCF)114, an SMF120, and a UPF122. A plurality of interfaces and/or reference points N1-N8, N10-N13, N15, and N22shown inFIG. 1B(as well as others) may define the communications and/or protocols between each of the entities, as described in the relevant (evolving) standards documents. One or more application functions, such as an application function (AF)124, of a data network (DN)111may connect to the 5G mobile network via PCF114or UPF122.

UPF122is part of the user plane and all other NFs (i.e. AMF112, SMF120, PCF114, AUSF116, and UDM118) are part of the control plane. Separation of user and control planes guarantees that each plane resource can be scaled independently; it also allows UPFs to be deployed separately from CP functions in a distributed fashion. The NFs in the CP are modularized functions; for example, AMF and SMF are independent functions allowing for independent evolution and scaling. As specifically illustrated inFIG. 1B, NFs such as SMF120and UPF122ofFIG. 1Bmay be provided as specific instances in a first network slice (e.g. network slice1) of a plurality of network slice instances made available in the mobile network.

Also shown in the mobile network is a network exposure function (NEF)150. In general, NEF150may be configured to receive information from other NFs (e.g. based on exposed capabilities of other NFs) and store the received information as structured data. The storage operations may be performed with use of a standardized interface to a data storage network function (e.g. UDM118). The stored information may be re-exposed by NEF150to other NFs and used for other purposes (e.g. analytics). One example use of NEF150is to assist in the establishment of an AS-initiated communication with a UE/IoT device, from an application server (AS)180through an API (e.g. where no other existing data connection exists).

FIG. 2is an illustration of a plurality of IoT devices200which may be part of a massive IoT (MIoT) deployment in a mobile network (e.g. the 5G mobile network ofFIGS. 1A-1B). The IoT devices200may be part of a group of IoT devices configured to communicate with an AS via a mobile network (e.g. the AS180of mobile network ofFIG. 1B). Each one of the IoT devices200, such as an IoT device202, may be assigned with a (unique) device ID. This device ID may be assigned by the manufacturer of the IoT device. In the mobile network, the entire group of IoT devices200may be associated with a (unique) group ID. AlthoughFIG. 2illustrates for clarity only ten (10) devices in the group, there will typically be a much larger number IoT devices in a group, for example, on the order of hundreds, thousands, or millions of devices.

FIG. 3is an illustration of a plurality of subscriber identity modules (SIMs)300or enhanced SIMs (eSIMs) which may be for use with IoT devices in a MIoT deployment. Each one of the SIMs300may be assigned with a (unique) ID or subscriber ID, such as an International Mobile Subscriber Identity (IMSI). Each one of SIMs300may also be assigned or associated with a (unique) mobile network ID, such as a Mobile Station International Subscriber Directory Number (MSISDN). Pairing with the IoT devices200ofFIG. 2, each one of SIMs300will be matched with an IoT device ofFIG. 2; the number of SIMs300ofFIG. 3will match the number of IoT devices200ofFIG. 2. AlthoughFIG. 3illustrates for clarity only ten (10) devices, there will typically be a much larger number of SIMs, for example, on the order of hundreds, thousands, or millions of modules.

FIG. 4is an illustrative representation of a system400for use in provisioning SIMs for IoT devices in a mobile network. System400may include a SIM manufacturer402, a mobile operator404, a control center406, and a subscriber database408(e.g. a home subscriber server or “HSS” and/or home location register or “HLR”). SIM manufacturer402may be, for example, Giesecke+Devrient Mobile Security GmbH (“G+D”) of Munich, Germany. Control center406may be configured to provision SIMs associated with IoT devices in the subscriber database408. Control center406may be, for example, the Cisco Jasper Control Center from Cisco Jasper of Santa Clara, Calif., U.S.A.

InFIG. 4, a SIM procurement procedure420may be initiated by mobile operator404(step1ofFIG. 4) for the ordering and receiving of SIMs from SIM manufacturer402(step2ofFIG. 4). Mobile operator404may receive one or more SIM information files422associated with the procured SIMs, which is sent to control center406(step3ofFIG. 4). As illustrated in a table426, SIM information file422may include (enterprise) account details432, subscriber IDs (e.g. IMSIs), and SIM Integrated Circuit Card Identifications (ICCIDs). A SIM provisioning procedure424may be performed by control center406for provisioning the SIMs in subscriber database408(step4ofFIG. 4). Control center406is able to generate IMSI to MSISDN mappings, as well as allow SIM profile updates from the SaaS platform. Provisioning may be facilitated with data460which include, for each SIM/IoT device, operator account data462, enterprise account data464, an IMSI472, an ICCID474, an MSISDN476, and a device ID478. Device ID478may be a custom data field populated by mobile operator404or the enterprise, independent of subsequently-assigned network identifiers.

In the above-described environment or similar environment, there is a need for efficient methods and apparatus for use in identity assignment, provisioning, and/or network slice orchestration for an MIoT deployment of IoT devices.

According to at least some implementations, automated or semi-automated system operations of the present disclosure may involve the assignment of external IDs and mobile network IDs (e.g. IMSIs and MSISDNs) to IoT devices of a group and the provisioning of the assigned identities at relevant mobile network entities (e.g. the UDM, the NEF, and the AS of the OTT/Enterprise domain) and the IoT devices themselves. Once the assignment and provisioning are complete, Operations may continue seamlessly with network slice orchestration for the creation of a network slice instance (NSI) and the provisioning of associated Network Slice Selection Assistance Information (NSSAI) at relevant mobile network entities (e.g. the UDM and NSSF). Further, Network Slice Selection Policies (NSSP) may be derived and sent to the PCF and IoT devices of the group. Advantageously, signaling efficiency may be achieved by performing operations on a group basis.

To better illustrate,FIGS. 5A-5Eare process flow diagrams for describing automated or semi-automated system operations for “zero-touch” bulk identity assignment, provisioning, and network slice orchestration for an MIoT deployment according to some implementations of the present disclosure. More particularly,FIGS. 5A-5Bare process flow diagrams500A and500B relating to methods for zero-touch bulk identity assignment and provisioning for the MIoT deployment, whereasFIGS. 5C-5Eare process flow diagrams500C and500D relating to methods for network slice orchestration for the MIoT deployment which may directly and seamlessly follow the methods described in relation toFIGS. 5A-5B.

Such methods may be performed at one or more mobile network nodes as will be described below. Such a network node may include one or more processors and one or more memories coupled to the one or more processors. The methods may be embodied as a computer program product (e.g. memory) including a non-transitory computer readable medium and instructions stored in the computer readable medium, where the instructions are executable on one or more processors of the network node for performing the steps of the methods.

In particular, and as described earlier, NEF150may be generally configured for exposure of services and capabilities of a mobile network, and also for interfacing with AS180for communication of data via the mobile network. In preferred implementations, NEF150is suitably configured with additional, enhanced functionality according to techniques of the present disclosure as described herein.

Beginning with the process flow diagram500A ofFIG. 5A, BSS130of the MNO may receive a list of devices IDs assigned to and associated with the plurality of IoT devices of a group (step502ofFIG. 5A). The list of device IDs may be received from a BSS of a manufacturer of the IoT devices. Similarly, a SIM server590may receive a (same) list of devices IDs assigned to and associated with IoT devices of the group (step504ofFIG. 5A). Again, the list of device IDs may be received from the BSS of the IoT device manufacturer.

For the procedure, NEF150may be provided with an Nb interface, and expose and/or publish an Nb REST “Identity Provisioning” API for an operations support system (OTT) or enterprise domain. AS180may operate as a BSS of the OTT or enterprise domain (step506ofFIG. 5A). AS180may be onboarded and authenticated at the NEF150, where credentials and service level agreement (SLA) data may be transferred (step508ofFIG. 5B).

Processes may continue with the process flow diagram500B ofFIG. 5B, which illustrates a procedure for zero-touch bulk identity assignment and provisioning for the MIoT deployment. NEF150may receive from a server of BSS130one or more messages which indicate a request for bulk onboarding of identities associated with the plurality of IoT devices (step512ofFIG. 5B). The plurality of IoT devices may be a group of IoT devices configured for communications with AS180via the mobile network (e.g. mobile network ofFIGS. 1A-1B). The one or more messages may include or otherwise identify a plurality of device IDs assigned to the IoT devices, a plurality of subscriber IDs assigned to the plurality of SIMs, and the plurality of mobile network IDs. Here, the subscriber IDs may be IMSIs; the mobile network IDs may be MSISDNs. The one or more messages may include one or more lists of IDs and/or one or more ranges of IDs.

InFIG. 5B, the following procedure may be performed for each device ID of the plurality of device IDs assigned to the IoT devices of the group. In general, NEF150may assign a plurality of identities to the device ID. More specifically, NEF150may generate and assign an external ID to the device ID (step514ofFIG. 5B). In addition, NEF150may select and assign a subscriber ID (e.g. IMSI) and a mobile network ID (e.g. MSISDN) to the device ID (step516ofFIG. 5B). NEF150may then store in memory (e.g. NEF or NEF-accessible memory) one or more associations between the device ID and the assigned identities (step518ofFIG. 5B). The procedure may be repeated for each device ID (step520ofFIG. 5B).

Identity mappings may then be exported to the AS180(step522ofFIG. 5B). More specifically, NEF150may send to AS180one or more messages which include or otherwise identify the external IDs and/or the device IDs, and/or the assignments and/or associations therebetween (step524ofFIG. 5B). The external IDs may be subsequently used by AS180to address the IoT devices for communications.

Identity mappings may also be exported to the UDM118(step526ofFIG. 5B). More specifically, a group ID may be generated and assigned to the group (step528ofFIG. 5B). The NEF150may then send to UDM118one or more messages which include or otherwise identify the group ID along with the subscriber IDs and the mobile network IDs (step530ofFIG. 5B), for UDM/UDR storage of the group ID in association with the subscriber IDs and the mobile network IDs of group. Note that the group ID may be subsequently used in one or more other processes (e.g. later in relation to step560ofFIG. 5D).

Identity mappings may also be exported to SIM server590(step532ofFIG. 5B). More specifically, NEF150may send to SIM server590one or more messages which include or otherwise identify the device IDs and/or the subscriber IDs, and/or the assignments or associations therebetween (step534ofFIG. 5B). The assigned identities may be used by SIM server590for a subsequent provisioning of the IoT devices of the group.

NEF150may then send a message to BSS130of MNO for acknowledgement, for example, a message which indicates an onboard device response to the initial onboarding device request of step512(step536ofFIG. 5B). In some implementations, the acknowledgement message of step536may be used by BSS130of MNO as a trigger to initiate subsequent processes ofFIG. 5C(e.g. trigger the messaging of subsequent step542ofFIG. 5C).

Note that, in some alternative implementations ofFIG. 5B, the AS180which operates as a BSS in the OTT domain may send to NEF150a list of the device IDs of the IoT devices, where NEF150is pre-provisioned with the IMSI and MSISDN ranges to assign to the device IDs or alternatively obtain this information from BSS130.

Processes may continue with the process flow diagram500C ofFIG. 5C, which (e.g. together withFIG. 5D) illustrates an automated or semi-automated for network slice orchestration. The process ofFIG. 5Cmay follow directly and seamlessly after the process ofFIG. 5B. Here, NEF150may operate as a network slice controller and/or a communications service management function (CSMF). As illustrated inFIG. 5C, the process flow may involve use of a network slice management function (NSMF)592together with a network functions virtualization management and orchestration (MANO)594according to some implementations.

InFIG. 5C, the procedure may begin with a process for creating a network slice instance (NSI) for the group of IoT devices (step540ofFIG. 5C). Here, NEF150may initially receive from the server of BSS130one or more messages which indicate a request for communication service for the group of IoT devices (step542ofFIG. 5C). Thus, BSS130of the MNO may trigger the instantiation of the network slice for the group of IoT devices. Again, the acknowledgement message of step536ofFIG. 5Bmay be used by BSS130of MNO as a trigger to initiate the messaging of this step542ofFIG. 5C.

The one or more message of step542ofFIG. 5Cmay include or otherwise identify a communication service description associated with the requested communication service. The communication service description may indicate a service type corresponding to MIoT, a coverage type associated with a specified geo-location, a charging type, as well as other information.

NEF150may map the received communication service description to network service requirements of the mobile network (step544ofFIG. 5C). Here, NEF150may derive or select appropriate network service requirements according to the communication service description. The network service requirements may be or include one or more Quality of Service (QoS) parameters, one or more latency parameters, one or more throughput or bandwidth (BW) parameters, etc. Specifically, step544may be performed per the 3GPP “SA5” specification (Service and System Aspects 5=Telecom Management).

NEF150may then send to NSMF592one or more messages which indicate a request for creating an NSI according to the selected network service requirements (step546ofFIG. 5C). In response, NSMF592together with MANO594may create the NSI (step548ofFIG. 5C). The NSI may be created according to a specified practice of the MNO.

Here, NSMF592may send to MANO594one or more messages which indicate a request for NSI creation and include a network service descriptor (step550ofFIG. 5C). The process may be performed according to 3GPP SA5 and/or ETSI standards. Here, MANO594may create an NSI and associated NFs according to the network service descriptor (step552ofFIG. 5C). Here, network slice selection assistance information (NSSAI) configuration data and an NSI ID associated with the NSI may be generated. NEF150may then receive from NSMF592one or more messages which indicate a response to the request for creating the NSI of step546(step554ofFIG. 5C). The one or more messages may include the NSSAI configuration data and the NSI ID associated with the created NSI and associated NFs. NEF150may send to BSS130one or more messages which indicate a response to the request for communication service of previous step542(step556ofFIG. 5C).

Processes may continue with the process flow diagram500D ofFIG. 5D, which continues the automated or semi-automated procedure for network slice orchestration. More specifically, process flow diagram500D ofFIG. 5Drelates to the storage of information for the created NSI. The process ofFIG. 5Dmay follow directly and seamlessly after the process ofFIG. 5C.

InFIG. 5D, NEF150may obtain or retrieve from memory the group ID of the group of IoT devices (step560ofFIG. 5D). The obtaining of the group ID in step560may be performed directly after and/or in response to the receipt of the one or more messages from the NSMF indicating the response to the NSI creation create of step554ofFIG. 5C. NEF150may then send to the UDM118one or more messages which include the group ID of the group and the NSI ID associated with the created network slice (step562ofFIG. 5D), for UDM/UDR storage of the NSI ID in association with the group ID and/or the associated subscriber and mobile network IDs. This may be considered a notification or indication to the UDM/UDR of the creation of the NSI for the group of IoT devices. NEF150may then send to NSSF152one or more messages which include the NSSAI configuration data and the NSI ID (step564ofFIG. 5D), for NSSF storage of the NSSAI configuration data and the NSI ID.

NEF150may also derive Network Slice Selection Policies (NSSP) based on a profile associated with the AS (e.g. an SLA profile) (step566ofFIG. 5D). The profile of the AS may have been received earlier in step508ofFIG. 5A. NEF150may then send to PCF114one or more messages which include the NSSP, the NSSAI, the plurality of subscriber IDs of the group, and MIoT application information (step568ofFIG. 5D), for storage of the NS SP in association with the NSSAI, the subscriber IDs of the group, and the MIoT application information.

Processes may continue with the process flow diagram500E ofFIG. 5Ewhich may be performed for each IoT device202of the group. More specifically, process flow diagram500E ofFIG. 5Erelates to the provisioning of the NS SP at the IoT devices themselves. The process ofFIG. 5Dmay follow after the process ofFIG. 5Cfor each device.

InFIG. 5E, IoT device202may send to AMF112a message for registration or attachment (step560ofFIG. 5E). The message may include or otherwise indicate the IMSI of the IoT device202. In response, AMF112may send to PCF114a message which indicates a request for the NSSP based on the IMSI of the IoT device202(step562ofFIG. 5E). PCF114may selectively retrieve the NSSP according to the IMSI of the IoT device202, and send or return the retrieved NSSP to the AMF112(step564ofFIG. 5E). The NSSP may include the NSSAI and the associated policies. AMF112may send to the IoT device202the NSSP as a response to the request of previous step562(step566ofFIG. 5E). Subsequently, IoT device202may use the NSSP and/or NSSAI in communications with its associated AS.

FIG. 6is a message format of network slice selection assistance information (NSSAI)602which may be generated and stored in response to the creation of the NSI in the processes ofFIGS. 5C-5D. As shown, NSSAI602may include a slice/service type (SST)604and a slice differentiator (SD)606. SSTs are high-level categories for NSIs, which reflect the distinct requirements for network solutions. Currently, three fundamental SSTs are defined for 5G: (1) enhanced mobile broadband (eMBB); (2) ultra-reliable low latency communications (URLLC); and (3) MIoT. In the present techniques, the SST604may be set to “MIoT.”

Referring now toFIG. 7, an illustrative representation of a system700for use in network slice creation according to some implementations of the present disclosure is shown. System700may include a communication service management function (CSMF)740in communication with NSMF592. Here, CSMF740may be part of NEF150. As described previously, AS180may utilize the Nb REST Identity Provisioning” API with the NEF. AS180may send to CSMF740of the NEF a communication service description according to a communication service request. CSMF740of the NEF may receive the communication service description and select network service requirements according to such description. CSMF740of the NEF may translate the selected network service requirements into slice-specific requirements. CSMF740may send the slice-specific requirements to NSMF592. At NSMF592, a selected one of a plurality of network slice templates (NSTs)732may be used to create NSI722according to the slice-specific requirements. The selected NST732may provide the created NSI722with required instance specific policies and configurations. The created NSI722may include associated NFs, such as an access network (AN) function724, a core network (CN) function726, and a transport network (TN) function728.

In general, an NSI is the instantiation of a network slice. A network slice is a logical network that may include a set of network functions, which may be Virtual Network Functions (VNFs) or Physical Network Functions (PNFs), and corresponding resources, such as compute, storage, and networking resources. It may be considered to be “sliced out” from the “physical” network in order to provide specific capabilities and characteristics that the application running within the slice requires. Specific capability and characteristics may be or include customized connectivity with ultra-low latency, extreme reliability, and/or value-added services, as necessary and/or configured. A slice may also be viewed as a unique profile for an application, defined as a set of services within the network, or as a network function chain built to support a given use case, traffic type or a customer.

FIG. 8is an illustrative representation of a network function virtualization management and orchestration (MANO)594which may be used in at least some implementations of the present disclosure. As described in relation toFIG. 5C, NSMF592may be configured to interact and communicate with MANO594in the creation of NSIs. MANO594is generally configured for the management or orchestration of the instantiation, modification, and tear-down of virtualized functions. MANO594may generally provide interfaces to existing systems such as an OSS/BSS. MANO594may include an orchestrator834which can access libraries836such as a Network Service catalog838, a VNF Catalog840, a VNF Instances repository842and NFVI resources repository844. NS Catalog838may include templates that can be used as the basis for supporting network services. VNF catalog840may contain templates for the instantiation of different classes of VNFs. A particular VNF, after being instantiated, may be referred to as a VNF instance, and its attributes may be stored in VNF instances repository842. NFVI resources844may be used to track the availability of resources, including both virtual resources and the physical infrastructure upon which they are instantiated. The NFVO834may be connected to a number of VNF Managers846and to a Virtualized Infrastructure Manager (VIM)848, and VNFM846and VIM848may also be connected to each other.

FIGS. 9A-9Bare illustrative representations of example mobile network communication routes between AS180and IoT device202for communications therebetween after MIoT deployment. InFIG. 9A, a first configuration is shown for IP data delivery902where an N6interface of the 5G mobile network terminates at the NEF150, such that routing to IoT device202is provided via NEF150and UPF122. InFIG. 9B, a second configuration for IP data delivery904is shown where the N6interface of the 5G mobile network terminates at AS180, such that routing to IoT device202is provided through UPF122but not through NEF150. InFIG. 9B, a configuration is shown for non-IP data delivery (NIDD)906such that routing to IoT device202is provided via NEF150and AMF122.

FIG. 10is a flowchart1000for describing a method for use in communicating data between an AS and an IoT device with use of an external ID, after MIoT deployment. The IoT device has been assigned a device ID by the manufacturer. Beginning at a start block1002ofFIG. 10, a network node (e.g. the NEF) may receive from the AS a message which indicates a request to communicate data to the IoT device (step1004ofFIG. 10). The message may include an external ID assigned to the IoT device having the device ID. The network node may selectively retrieve a subscriber ID and/or mobile network ID of the IoT device based on a stored mapping between the external ID and the subscriber ID and/or mobile network ID (step1006ofFIG. 10). The network node may cause or otherwise facilitate data communication between the AS and the IoT device using the retrieved subscriber ID and/or mobile network ID (step1008ofFIG. 10).

Thus, in at least some implementations of the present disclosure, what is provided is a zero-touch bulk external ID creation and provisioning for IoT devices as well as network slice orchestration with minimal input from an enterprise. Such techniques may enable a mobile network to hide the subscriber IDs from application systems and automate the bulk creation of application-aware IDs for service exposure. Further advantageously, the described approach may further enable multiple application-aware identities associated with a SUPI when provisioned in a subscriber database or UDM/UDR. This may even further enable multiple-enterprise BSS systems to benefit from the same network deployment. For example, smart city environmental monitoring sensors may be able collect environment data, and these data may be leveraged across multiple unique applications with unique external IDs that are bulk-provisioned.

Implementations of the present disclosure have been shown in the figures to apply to a 5G mobile network; however, implementations may be readily applied to other suitable types mobile networks, such as 4G, Long Term Evolution (LTE) based networks having a control and user plane separation (CUPS) architecture, as one ordinarily skilled in the art will readily appreciate. In 4G/LTE with CUPS, an NEF may instead be a service capabilities and exposure function (SCEF), and the subscriber database of UDM/UDR may instead be a home subscriber server (HSS) and/or home location register (HLR). As other examples, the UPF may instead be a gateway-user plane (GW-U). the SMF may instead be a GW-control plane (GW-C), the AMF may instead be a mobility management entity (MME), the PCF may instead be a policy and control rules function (PCRF). The SMF and GW-C may be more generally referred to as a CP entity for session management. Other naming conventions may be adopted or realized.

Note that, although in some implementations of the present disclosure, one or more (or all) of the components, functions, and/or techniques described in relation to the figures may be employed together for operation in a cooperative manner, each one of the components, functions, and/or techniques may indeed be employed separately and individually, to facilitate or provide one or more advantages of the present disclosure.

It will also be understood that, although the terms “first,” “second,” etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used to distinguish one element from another. For example, a first identity could be termed a second identity, and similarly, a second identity could be termed a first identity, without changing the meaning of the description, so long as all occurrences of the “first identity” are renamed consistently and all occurrences of the “second identity” are renamed consistently. The first identity and the second identity are both identities, but they are not the same identity.