5G-NR connectivity support for IOT devices

Various aspects support 5G NR connectivity for Internet of Things (IoT) devices by adding one or more 5G NR network bearer support information elements to a connectivity monitoring object of the Lightweight Machine-to-Machine (LwM2M) protocol, and using 5G specific parameters to add support for 5G non-standalone (NSA) and/or 5G standalone (SA) objects to the LwM2M protocol.

BACKGROUND

The Open Mobile Alliance (OMA) is a standards body that defines a Lightweight Machine-to-Machine (LwM2M) protocol. The LwM2M protocol defines various LwM2M objects that may include one or more resource definition information elements (IE). For example, the LwM2M protocol defines a security object (Object ID=0), a server object (Object ID=1), an access control object (Object ID=2), a device object (Object ID=3), a connectivity monitoring object (Object ID=4), and a firmware update object (Object ID=5). The connectivity monitoring object includes a network bearer IE, an available network bearer IE, a radio signal strength IE, a link quality IE, an Internet protocol (IP) addresses IE, a link utilization IE, an access point name (APN) IE, a cell id IE, a serving mobile network code (SMNC) IE, and a serving mobile country code (SMCC) IE. These information elements allow for the monitoring of parameters related to network connectivity and/or for the communication network or wireless device to communicate up-to-date values for the wireless device's current connections.

SUMMARY

Various aspects enable methods of supporting Fifth Generation (5G) New Radio (NR) connectivity for Internet of Things (IoT) devices, which include indicating in a connectivity monitoring object of the Lightweight Machine-to-Machine (LwM2M) protocol transmitted to a base station whether an IoT device is capable of receiving 5G NR and receiving 5G NR network bearer support information from the base station. In some aspects the connectivity monitoring object transmitted to the base station may include a network bearer information element and an available network bearer information element. In some aspects receiving 5G NR network bearer support information from the base station may include receiving information identifying a network bearer type or a communication session that can be established with the base station. In some aspects indicating in the connectivity monitoring object of the LwM2M protocol transmitted to the base station may include adding or including a 5G-NR cellular network information element in the transmitted connectivity monitoring object. In some aspects indicating in the connectivity monitoring object of the LwM2M protocol transmitted to the base station may include adding or including in the connectivity monitoring object at least one or more of a 5G-NR frequency division duplexing (FDD) cellular network information element or a 5G-NR time division duplexing (TDD) cellular network information element.

Some aspects may include methods for supporting Fifth Generation (5G) New Radio (NR) connectivity for Internet of Things (IoT) devices that include receiving from an IoT device one or more 5G NR network bearer support information elements in a connectivity monitoring object of the Lightweight Machine-to-Machine (LwM2M) protocol, transmitting 5G specific parameters to the IoT providing support for 5G non-standalone (NSA) or 5G standalone (SA) objects to the LwM2M protocol, and providing 5G NR service to the IoT device. In some aspects, the connectivity monitoring object received from the IoT device may include a network bearer information element and an available network bearer information element. In some aspects, the 5G NR network bearer support information may include information identifying a network bearer type or a communication session that can be established with the base station. In some aspects, receiving from an IoT device one or more 5G NR network bearer support information elements in a connectivity monitoring object of the LwM2M protocol may include receiving 5G-NR cellular network information element in the connectivity monitoring object. In some aspects, receiving from an IoT device one or more 5G NR network bearer support information elements in a connectivity monitoring object of the LwM2M protocol may include receiving at least one or more of a 5G-NR frequency division duplexing (FDD) cellular network information element or a 5G-NR time division duplexing (TDD) cellular network information element.

Further aspects include an IoT device having a processor configured with processor-executable instructions to perform operations of any of the IoT device methods summarized above. Various aspects include an IoT device having means for performing functions of any of the IoT device methods summarized above. Various aspects include a non-transitory processor-readable medium having stored thereon processor-executable instructions configured to cause a processor of an IoT device to perform operations of any of the IoT device methods summarized above.

Further aspects include a base station having a processor configured with processor-executable instructions to perform operations of any of the base station methods summarized above. Various aspects include a base station having means for performing functions of any of the base station methods summarized above. Various aspects include a non-transitory processor-readable medium having stored thereon processor-executable instructions configured to cause a processor of a base station to perform operations of any of the base station methods summarized above.

DETAILED DESCRIPTION

The term “IoT device” is used herein to refer to any of a variety of devices including a processor and transceiver for communicating with other devices or a network. For ease of description, examples of IoT devices are described as communicating via radio frequency (RF) wireless communication links, but IoT devices may communicate via wired or wireless communication links with another device (or user), for example, as a participant in a communication network, such as the IoT. Such communications may include communications with another wireless device, a base station (including a cellular communication network base station and an IoT base station), an access point (including an IoT access point), or other wireless devices.

Various embodiments may be implemented in any device, system or network that is capable of transmitting and receiving RF signals according to any of the Institute of Electrical and Electronics Engineers (IEEE)16.11 standards, or any of the IEEE 802.11 standards, the Bluetooth standard, code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), Global System for Mobile communications (GSM), GSM/General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), Terrestrial Trunked Radio (TETRA), Wideband-CDMA (W-CDMA), Evolution Data Optimized (EV-DO), 1xEV-DO, EV-DO Rev A, EV-DO Rev B, High Speed Packet Access (HSPA), High Speed Downlink Packet Access (HSDPA), High Speed Uplink Packet Access (HSUPA), Evolved High Speed Packet Access (HSPA+), Long Term Evolution (LTE), AMPS, or other known signals that are used to communicate within a wireless, cellular or internet of things (IoT) network, such as an IEEE 802.15.4 protocol (for example, Thread, ZigBee, and Z-Wave), 6LoWPAN, Bluetooth Low Energy (BLE), LTE Machine-Type Communication (LTE MTC), Narrow Band LTE (NB-LTE), Cellular IoT (CIoT), Narrow Band IoT (NB-IoT), BT Smart, Wi-Fi, LTE-U, LTE-Direct, MuLTEfire, as well as relatively extended-range wide area physical layer interfaces (PHYs) such as Random Phase Multiple Access (RPMA), Ultra Narrow Band (UNB), Low Power Long Range (LoRa), Low Power Long Range Wide Area Network (LoRaWAN), Weightless, or a system utilizing 3G, 4G or 5G, or further implementations thereof, technology.

The term “system on chip” (SOC) is used herein to refer to a single integrated circuit (IC) chip that contains multiple resources and/or processors integrated on a single substrate. A single SOC may contain circuitry for digital, analog, mixed-signal, and radio-frequency functions. A single SOC may also include any number of general purpose and/or specialized processors (digital signal processors, modem processors, video processors, etc.), memory blocks (e.g., ROM, RAM, Flash, etc.), and resources (e.g., timers, voltage regulators, oscillators, etc.). SOCs may also include software for controlling the integrated resources and processors, as well as for controlling peripheral devices.

The term “multicore processor” is used herein to refer to a single integrated circuit (IC) chip or chip package that contains two or more independent processing cores (e.g., central processing unit (CPU) core, internet protocol (IP) core, graphics processor unit (GPU) core, etc.) configured to read and execute program instructions. A SOC may include multiple multicore processors, and each processor in an SOC may be referred to as a core. The term “multiprocessor” is used herein to refer to a system or device that includes two or more processing units configured to read and execute program instructions.

The various embodiments are described herein using the term “server” to refer to any computing device capable of functioning as a server, such as a master exchange server, web server, mail server, document server, content server, or any other type of server. A server may be a dedicated computing device or a computing device including a server module (e.g., running an application that may cause the computing device to operate as a server). A server module (e.g., server application) may be a full function server module, or a light or secondary server module (e.g., light or secondary server application) that is configured to provide synchronization services among the dynamic databases on receiver devices. A light server or secondary server may be a slimmed-down version of server-type functionality that can be implemented on a receiver device thereby enabling it to function as an Internet server (e.g., an enterprise e-mail server) only to the extent necessary to provide the functionality described herein.

As noted above, the LwM2M protocol defines various LwM2M objects that each include one or more resource definition information elements (IE). For example, the connectivity monitoring object (Object ID=4) includes a network bearer IE, an available network bearer IE, a radio signal strength IE, a link quality IE, an Internet protocol (IP) addresses IE, a link utilization IE, an access point name (APN) IE, a cell id IE, a serving mobile network code (SMNC) IE, a serving mobile country code (SMCC) IE, a SignalSNR IE, and a location area code (LAC) IE. While these information elements (IEs) may be adequate for the monitoring network connectivity parameters in LTE, CDMA, NB-IoT and other similar legacy systems, they may not be sufficient for supporting the device management of 5G-NR capable chipsets or for supporting network connectivity and/or communicating up-to-date connection values in 5G NR and future networks.

Various embodiments include system information as well as IoT devices and network elements (e.g., a gNodeB) configured to better support device management of 5G-NR capable chipsets and IoT devices, better support establishing or maintaining network connectivity, and/or better support communicating up-to-date connection values in 5G NR and future networks. Various embodiments include adding one or more 5G NR network bearer support IEs to the connectivity monitoring object (Object ID=4). In various embodiments, IoT devices and network elements may be configured to support 5G RAT based device management by adding support for 5G non-standalone (NSA) and/or 5G standalone (SA) objects with 5G specific parameters.

In some embodiments, adding 5G NR network bearer support IEs to the connectivity monitoring object (Object ID=4) may include adding information identifying the 5G-NR network bearer types and/or the LwM2M communication sessions that can be established to the network bearer and/or available network bearer IEs of the connectivity monitoring object.

In some embodiments, the IoT devices and network elements may be configured to add a 5G-NR cellular network IE to the connectivity monitoring object (Object ID=4). In some embodiments, the IoT devices and network elements may be configured to add a 5G-NR frequency division duplexing (FDD) cellular network IE and/or a 5G-NR time division duplexing (TDD) cellular network IE to the connectivity monitoring object (Object ID=4). In some embodiments, the IoT devices and network elements may be configured to support 5G RAT based device management by adding support for 5G non-standalone (NSA) and/or 5G standalone (SA) objects with 5G specific parameters.

An IoT device may determine an identity of the network (e.g., a Public Land Mobile Network (PLMN) or another suitable network) with which the IoT device is in communication, and scan the characteristics of one or more connectivity objects that are linked in a server object based on the determined network identity. In some embodiments, the connectivity objects may each include a connectivity option IE, a band support available IE, a band attached IE, a single network slice selection assistance information (S-NSSAI) IE, a data network name (DNN) IE, a protocol/packet data unit (PDU) session id IE, a session and service continuity (SSC) mode IE, a PDU session type IE, 5G quality-of-service identifier (5QI) IE, a service data adaptation protocol (SDAP) enablement IE, quality-of-service flow identifier (QFI) IE, a session aggregate maximum bit rate (AMBR) IE, an APN-AMBR IE, a reflective quality-of-service (QOS) IE, an access stratum reflective QoS IE, a proxy call session control function (P-CSCF) address index IE, a PDU session authentication IE, PLMN id IE, a local area data network (LADN) support IE, an access type preference IE, and/or an integrity protection on data radio bearer (DRB) IE.

The connectivity option IE may identify a connectivity option (e.g., 1-7, etc.) that identifies or is associated with a core network, a master radio access technology (RAT), and/or a secondary RAT. For example, connectivity options “1” and “3” may identify evolved packet core (EPC) as the core network, and connectivity options 2,” “4,” “5” and “7” may identify 5G core (5GC) as the core network. Connectivity option “3” may further identify new radio (NR) as the secondary RAT. Connectivity options “2” and “4” may identify new radio (NR) as the master RAT, and connectivity options “5” and “7” may identify eLTE as the master RAT. Connectivity option “4” may identify eLTE as the secondary RAT. Connectivity option “7” may identify NR as the secondary RAT. The band support available IE may identify the NR bands supported by IoT device (in SA or NSA mode). The band attached IE may indicate the NR Band over which the IoT device is attached currently in 5G cell (in SA or NSA mode).

The S-NSSAI IE may indicate the S-NSSAI element for 5G SA mode, such as enhanced mobile broadband (eMBB), ultra-reliable low latency communications (URLLC), massive IOT (mIoT), custom, etc.). The DNN IE may identify the data network name in case the network bearer resource is a 5G SA (FDD/TDD) cellular network. The PDU session id IE may identify the PDU session over which LwM2M session is established for the 5G SA (FDD/TDD) cellular network. The SSC mode IE may identify the SSC mode (e.g., SSC Mode 1, SSC Mode 2, SSC Mode 3, etc.) for the 5G SA (FDD/TDD) cellular network. The PDU session type IE may identify the type of PDU session (e.g., IPv4, IPv6, IPv4v6, Unstructured, Ethernet, Reserved, etc.) over which LwM2M connection is established for the 5G SA (FDD/TDD) cellular network.

The 5QI IE may identify the 5G QoS (e.g., standard, operator specific, reserved, spare, etc.) for the 5G SA (FDD/TDD) cellular network. The SDAP enablement IE may identify whether SDAP is enabled (e.g., in uplink only, in downlink only, or in both uplink and downlink) for the 5G SA (FDD/TDD) cellular network. The QFI IE may identify the QoS flow for the 5G SA (FDD/TDD) cellular network. The session AMBR IE may identify the session aggregate maximum bit rate as per the 5G 3GPP Spec for the 5G SA (FDD/TDD) cellular network. The APN-AMBR IE may identify the aggregate maximum bit rate that is applicable to a given APN over which LwM2M session is established for the 5G SA (FDD/TDD) cellular network.

The reflective QOS IE may identify the QoS at non-access stratum (NAS) layer (e.g., disabled, enabled, etc.) for the 5G SA (FDD/TDD) cellular network. The access stratum reflective QoS IE may identify the QoS for Access Stratum (e.g., absent, present, etc.) for the 5G SA (FDD/TDD) cellular network. The P-CSCF address index IE may identify an index for the P-CSCF address for the 5G SA (FDD/TDD) cellular network. The PDU session authentication IE may identify the authentication type (e.g., primary, secondary, both, etc.) for the PDU session. The PLMN ID IE may identify the PLMN over which wireless device is currently attached for the 5G SA (FDD/TDD) cellular network. The LADN support IE may identify whether LADN is supported for the 5G SA (FDD/TDD) cellular network. The access type preference IE may identify the access type preference (e.g., 3GPP, Non-3GPP, etc.) for the 5G SA (FDD/TDD) cellular network. The integrity protection on DRB IE may identify whether support for integrity protection on the data radio bearer is enabled for 5G SA (FDD/TDD) cellular network.

Some embodiments may include methods for supporting Fifth Generation (5G) New Radio (NR) connectivity for Internet of Things (IoT) devices, which may include adding one or more 5G NR network bearer support information elements to a connectivity monitoring object of the Lightweight Machine-to-Machine (LwM2M) protocol, using 5G specific parameters to add support for 5G non-standalone (NSA) and/or 5G standalone (SA) objects to the LwM2M protocol, and providing 5G radio access technology (RAT) based device management. In some embodiments, the connectivity monitoring object may include a network bearer information element and an available network bearer information element. In some embodiments, adding one or more 5G NR network bearer support information elements to the connectivity monitoring object of the LwM2M protocol may include adding information identifying a network bearer type or a communication session that can be established to the network bearer information element or the available network bearer information element. In some embodiments, adding one or more 5G NR network bearer support information elements to the connectivity monitoring object of the LwM2M protocol may include adding a 5G-NR cellular network information element to a connectivity monitoring object. In some embodiments, adding one or more 5G NR network bearer support information elements to the connectivity monitoring object of the LwM2M protocol may include adding to the connectivity monitoring object at least one or more of a 5G-NR frequency division duplexing (FDD) cellular network information element or a 5G-NR time division duplexing (TDD) cellular network information element.

FIG. 1illustrates an example wireless network100, such as a new radio (NR) or 5G network, in which embodiments of the present disclosure may be performed. For example, an IoT device equipped with the system in a package (SIP)200illustrated inFIG. 2may include a 5G modem processor that is configured to send and receive information via the wireless network100.

In the example illustrated inFIG. 1, the wireless network100includes a number of base stations110and other network entities. A base station may be a station that communicates with wireless devices including IoT devices. Each base station110may provide communication coverage for a particular geographic area. In 3rd Generation Partnership Project (3GPP), the term “cell” can refer to a coverage area of a Node B and/or a Node B subsystem serving this coverage area, depending on the context in which the term is used. In new radio (NR) or Fifth Generation (5G) network systems, the term “cell” and eNB, Node B, 5G NB, access point (AP), NR base station, NR base station, or transmission and reception point (TRP) may be interchangeable. In some examples, a cell may not necessarily be stationary, and the geographic area of the cell may move according to the location of a mobile base station. In some examples, the base stations may be interconnected to one another and/or to one or more other base stations or network nodes (not shown) in the wireless network100through various types of backhaul interfaces such as a direct physical connection, a virtual network, or the like using any suitable transport network.

In general, any number of wireless networks may be deployed in a given geographic area. Each wireless network may support a particular RAT and may operate on one or more frequencies. A frequency may also be referred to as a carrier, a frequency channel, etc. Each frequency may support a single RAT in a given geographic area in order to avoid interference between wireless networks of different RATs. Wireless networks100supporting IoT device communications may use or support a number of different RATs, including for example, LTE/Cat. M, NB-IoT, Global System for Mobile Communications (GSM), and Voice over Long Term Evolution (VoLTE) RATs as well as other RATs (e.g., 5G). Wireless networks100may use a different APN for each different RAT.

A base station may provide communication coverage for a macro cell, a pico cell, a femto cell, and/or other types of cell. A macro cell may cover a relatively large geographic area (e.g., several kilometers in radius) and may allow unrestricted access by IoT devices with service subscription. A pico cell may cover a relatively small geographic area and may allow unrestricted access by IoT devices with service subscription. A femto cell may cover a relatively small geographic area (e.g., a home) and may allow restricted access by IoT devices having association with the femto cell (e.g., IoT devices in a Closed Subscriber Group (CSG), IoT devices for users in the home, etc.). A base station for a macro cell may be referred to as a macro base station. A base station for a pico cell may be referred to as a pico base station. A base station for a femto cell may be referred to as a femto base station or a home base station. In the example shown inFIG. 1, the base stations110a,110band110cmay be macro base stations for the macro cells102a,102band102c, respectively. The base station110xmay be a pico base station for a pico cell102x. The base stations110yand110zmay be femto base station for the femto cells102yand102z,respectively. A base station may support one or multiple (e.g., three) cells. Further, base stations may support communications on multiple networks using multiple RATs, such as Cat.-M1, NB-IoT, GSM, and VoLTE.

The wireless network100may also include relay stations. A relay station is a station that receives a transmission of data and/or other information from an upstream station (e.g., a base station or an IoT device) and sends a transmission of the data and/or other information to a downstream station (e.g., an IoT device or a base station). A relay station may also be a wireless device that relays transmissions for other wireless devices including IoT devices. In the example shown inFIG. 1, a relay station110rmay communicate with the base station110aand an IoT device120rin order to facilitate communication between the base station110aand the IoT device120r.A relay station may also be referred to as a relay base station, a relay, etc. Further, relay stations may support communications on multiple networks using multiple RATs, such as Cat.-M1, NB-IoT, GSM, and VoLTE.

The wireless network100may be a heterogeneous network that includes base stations of different types, e.g., macro base station, pico base station, femto base station, relays, etc. These different types of base stations may have different transmit power levels, different coverage areas, and different impact on interference in the wireless network100. For example, macro base station may have a high transmit power level (e.g., 20 Watts) whereas pico base station, femto base station, and relays may have a lower transmit power level (e.g., 1 Watt).

The wireless network100may support synchronous or asynchronous operation. For synchronous operation, the base stations may have similar frame timing, and transmissions from different base stations may be approximately aligned in time. For asynchronous operation, the base stations may have different frame timing, and transmissions from different base stations may not be aligned in time. The techniques described herein may be used for both synchronous and asynchronous operations.

A network controller130may be coupled to a set of base stations and provide coordination and control for these base stations. The network controller130may communicate with the base stations110via a backhaul. The base stations110may also communicate with one another, e.g., directly or indirectly via wireless or wireline backhaul.

The IoT devices120(e.g.,120x,120y,etc.) may be dispersed throughout the wireless network100, and each IoT device may be stationary or mobile. Some IoT devices may be considered evolved or machine-type communication (MTC) devices or evolved MTC (eMTC) devices. MTC and eMTC IoT devices include, for example, robots, drones, remote devices, sensors, meters, monitors, location tags, etc., that may communicate with a base station, another device (e.g., remote device), or some other entity. A wireless node may provide, for example, connectivity for, or to, a network (e.g., a wide area network such as Internet or a cellular network) via a wired or wireless communication link.

InFIG. 1, a solid line with double arrows indicates desired transmissions between an IoT device and a serving base station, which is a base station designated to serve the IoT device on the downlink and/or uplink. A dashed line with double arrows indicates interfering transmissions between the IoT device and a base station.

A NR base station (e.g., eNB, 5G Node B, Node B, transmission reception point (TRP), access point (AP)) may correspond to one or multiple base stations. NR cells may be configured as access cell (ACells) or data only cells (DCells). For example, the radio access network (RAN) (e.g., a central unit or distributed unit) may configure the cells. DCells may be cells used for carrier aggregation or dual connectivity, but not used for initial access, cell selection/reselection, or handover. NR base stations may transmit downlink signals to IoT devices indicating the cell type. Based on the cell type indication, the IoT device may communicate with the NR base station. For example, the IoT device may determine NR base stations to consider for cell selection, access, handover (HO), and/or measurement based on the indicated cell type.

The various embodiments may be implemented on IoT devices equipped with any of a number of single processor and multiprocessor computer systems, including a system-on-chip (SOC) or system in a package (SIP).FIG. 2illustrates an example computing system or SIP200architecture that may be used in IoT devices (e.g., the IoT devices120) implementing the various embodiments. With reference toFIGS. 1 and 2, the SIP200may provide all of the processing, data storage and communication capabilities required to support the mission or functionality of a given IoT device. The same SIP200may be used in a variety of different types of IoT devices (e.g., smart meters, smart appliances, sensors, etc.) with device-specific functionality provided via programming of one or more processors within the SIP. Further, the SIP200is an example of components that may be implemented in a SIP used in IoT devices and more or fewer components may be included in a SIP used in IoT devices without departing from the scope of the claims.

The example SIP200illustrated inFIG. 2includes two SOCs202,204, a wireless transceiver266, a clock206, and a voltage regulator208. In some embodiments, the first SOC202operates as central processing unit (CPU) of the IoT device that carries out the instructions of software application programs by performing the arithmetic, logical, control and input/output (I/O) operations specified by the instructions. In some embodiments, the second SOC204may operate as a specialized processing unit. For example, the second SOC204may operate as a specialized 5G processing unit responsible for managing high volume, high speed (e.g., 5 Gbps, etc.), and/or very high frequency short wave length (e.g., 28 GHz mmWave spectrum, etc.) communications.

In the example illustrated inFIG. 2, the first SOC202includes a digital signal processor (DSP)210, a modem processor212, a graphics processor214, an application processor216, one or more coprocessors218(e.g., vector co-processor) connected to one or more of the processors, memory220, custom circuity222, system components and resources224, an interconnection/bus module226, one or more temperature sensors230, a thermal management unit232, and a thermal power envelope (TPE) component234. The second SOC204includes a 5G modem processor252, a power management unit254, temperature sensors262a262b,an interconnection/bus module264, a plurality of mmWave transceivers256, memory258, and various additional processors260, such as an applications processor, packet processor, etc.

Each processor210,212,214,216,218,252,260may include one or more cores, and each processor/core may perform operations independent of the other processors/cores. For example, the first SOC202may include a processor that executes a first type of operating system (e.g., FreeBSD, LINUX, OS X, etc.) and a processor that executes a second type of operating system (e.g., MICROSOFT WINDOWS 10). In addition, any or all of the processors210,212,214,216,218,252,260may be included as part of a processor cluster architecture (e.g., a synchronous processor cluster architecture, an asynchronous or heterogeneous processor cluster architecture, etc.).

The first and second SOC202,204may include various system components, resources and custom circuitry for managing sensor data, analog-to-digital conversions, wireless data transmissions, and for performing other specialized operations, such as decoding data packets and processing encoded audio and video signals for rendering in a web browser. For example, the system components and resources224of the first SOC202may include power amplifiers, voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components used to support the processors and software clients running on an IoT device. The system components and resources224and/or custom circuitry222may also include circuitry to interface with peripheral devices, such as cameras, electronic displays, wireless communication devices, external memory chips, etc.

The first and second SOC202,204may communicate via an interconnection/bus module250. The various processors210,212,214,216,218, may be interconnected to one or more memory elements220, system components and resources224, and custom circuitry222, and a thermal management unit232via an interconnection/bus module226. Similarly, the processors252,260may be interconnected to the power management unit254, the mmWave transceivers256, memory258, and various additional processors260via the interconnection/bus module264. The interconnection/bus module226,250,264may include an array of reconfigurable logic gates and/or implement a bus architecture (e.g., CoreConnect, AMBA, etc.). Communications may be provided by advanced interconnects, such as high-performance networks-on chip (NoCs).

The first and/or second SOCs202,204may further include an input/output module (not illustrated) for communicating with resources external to the SOC, such as a clock206and a voltage regulator208. Resources external to the SOC (e.g., clock206, voltage regulator208) may be shared by two or more of the internal SOC processors/cores.

FIG. 3illustrates an example Non-IP Data Delivery (NIDD) data call architecture300suitable for use with various embodiments. With reference toFIGS. 1-3, the architecture300shows an example of a NIDD data call between an IoT device302(e.g., IoT devices120) and a server304. The architecture300is discussed with reference to LwM2M, but LwM2M is merely an example of an application of a NIDD data call used to illustrate aspects of the architecture300. Other protocols, such as other OMA protocols may be used to establish a NIDD data call and the architecture300may apply to non-LwM2M NIDD data calls. The IoT device302and the server304may be configured to communicate using NIDD. As an example, the IoT device302may be a LwM2M client device. As an example, the server304may be a LwM2M server, such as a bootstrap server as defined by LwM2M or an LwM2M server that is not a bootstrap server. The server304may be an application server.

A Service Capability Exposure Function (SCEF)310enables NIDD communication between the IoT device302and the server304. The SCEF310enables devices such as the IoT device302and the application server304to access certain communication services and capabilities, including NIDD. The SCEF310may support Relative Duplex Distance (RDD). While illustrated as in communication with one server304, the SCEF310may route traffic to multiple servers each identified by their own respective destination port when using the Reliable Data Service (RDS) protocol. In this manner, a single NIDD data call through the SCEF310may include multiplexed traffic intended for multiple different destinations.

In some embodiments, the IoT device302may be configured with an LwM2M client302athat uses the LwM2M device management protocol. The LwM2M device management protocol defines an extensible resource and data model. The LwM2M client302amay employ a service-layer transfer protocol such as Constrained Application Protocol (CoAP)302bto enable, among other things reliable and low overhead transfer of data. The IoT device302may employ a communication security protocol such as Datagram Transport Layer Security (DTLS)302c.DTLS in particular may provide security for datagram-based applications. One such application may be a Non-IP Application302d.The Non-IP Application302dmay utilize a non-IP protocol302eto structure non-IP communications.

In some embodiments, the server304may be configured with an LwM2M server304a,a transfer protocol such as CoAP304b,and a security protocol such as DTLS304c.The application server304may be configured to utilize a variety of communication protocols, such as non-IP protocol304d,as well as other communication protocol such as UDP, SMS, TCP, and the like.

As an example, the IoT device302may be a constrained device having a very small power storage device and may be configured for an operational life of years. Typical protocols for establishing IP data bearers are notoriously power hungry. In contrast, NIDD may enable the IoT device302to communicate small amounts of data by a control plane, rather than a user plane, without the use of an IP stack. NIDD may have particular application in Cat.-M1, NB-IoT and CIoT communications to enable constrained devices to communicate via a cellular network and send or receive small amounts of data per communication (e.g., in some cases, on the order of hundreds of bytes, tens of bytes, or smaller). NIDD may enable the IoT device302to embed a small amount of data in a container or object312without use of an IP stack, and to send the container or object312to the server304via the SCEF310. Similarly, the IoT device302may receive containers or objects312that define services and capabilities of the network100the IoT device302may be connected to enable the IoT device302to reach the SCEF310and server304. For example, such containers or objects312that define services and capabilities may include various OMA objects, such as an APN connection profile object (Object ID 11), a LwM2M server object (Object ID 1), a LwM2M security object (Object ID 0), etc.

In some embodiments, the IoT device302may support RDS in a NIDD data call. The IoT device302may multiplex uplink traffic for different servers304by sending the uplink traffic with a pair of source and destination port numbers and an Evolved Packet System (EPS) bearer ID. The SCEF310may receive uplink traffic from the IoT device302and may route the uplink traffic to the appropriate server, such as server304or any other server, based on the destination port number indicated for the uplink traffic.

FIG. 4Ais a process flow diagram,FIG. 4Billustrates a component block diagram, andFIG. 4Cis a chart illustrating, illustrating a method400and aspects of components used in the method400according to some embodiments. With reference toFIGS. 1-4C, the method400may be implemented in hardware components and/or software components of an IoT device (e.g., the IoT devices120) the operation of which may be controlled by one or more processors (e.g., the processors212,216,252or260).

In block402, the processor may identify one or more communication link characteristic preferences of the IoT device. For example, the processor may identify a network identifier of the network with which the IoT device is currently connected (such as a PLMN), a current RAT, a preferred network binding type (e.g., IP or NIDD), or another suitable preference. In some embodiments, the server object may include a preferred bearer resource indication. In some embodiments, identifying one or more communication link characteristic preferences of the IoT device may include determining a listing order of communication link characteristics of one or more of the connectivity objects.

In block404, the processor may scan characteristics of a plurality of connectivity objects that are linked in a server object. For example, referring toFIG. 4B, a server object420may include a plurality of links to connectivity objects, such as the connectivity objects422,424,426, and428.

In some embodiments, the connectivity objects may include instances of Object 11. In some embodiments, the server object links may include APN links. In some embodiments, the characteristics of the connectivity objects may include an APN name430, a PLMN identifier432, a RAT identifier434, a packet data network (PDN) type436, and other suitable characteristics.

Referring toFIG. 4C, in some embodiments, the connectivity objects may include one or more instances of Object 13. In some embodiments, the Object 13 instance(s) may include preference and/or priority information440, such as the example information in the Description column illustrated inFIG. 4C. In some embodiments, the Object 13 may include information indicating a preferred RAT. In some embodiments, the Object 13 may include information indicating a RAT priority indication. In some embodiments, the Object 13 may include a link to one or more Object 11 instances at a LwM2M client. In other embodiments, the server object, Object 1, may include a link to an Object 13 instance.

Object 13 may help the processor choose the particular PLMN/network, and Object 13/x/0 may allow for the selection of the preferred bearer for LwM2M communication. Object 13/x/0 may allow the user to choose amongst the various bearers such as LTE, Ethernet, Bluetooth etc. In some embodiments, Object 13/x/0 may include an added NR information element using a reserved value, such as 16.

Referring back toFIG. 4A, in block406, the processor may determine a best match access point name based on the communication link characteristic preferences of the IoT device and the scanned characteristics of the plurality of linked connectivity objects. For example, the processor may determine that one or more of the communication link characteristic preferences match one or more of the scanned characteristics of the linked connectivity objects. In some embodiments, the processor may determine the best match access point name based on a number of matches between the communication link characteristic preferences and the scan characteristics of the linked connectivity objects.

In block408, the processor may select a communication link based on the determined best match access point.

As discussed above, various embodiments include methods for supporting device management in 5G NR connectivity for IoT devices, which may include indicating in a connectivity monitoring object of the LwM2M protocol transmitted to a base station whether an IoT device is capable of receiving 5G NR and receiving 5G NR network bearer support information from the base station.FIGS. 4D-1 through 4D-4illustrate an example 5G NR connectivity object that could be transmitted to a base station to indicate whether an IoT device is capable of receiving 5G NR. The 5G NR connectivity object may include various resource definitions, such as a connectivity option, NR band support available, NR band attached, S-NSSAI, DNN Name, PDU session ID, SSC mode, PDU Session Type, 5QI, SDAP Enablement, QFI, Session AMBR, APN-AMBR, Reflective QOS, Access Stratum Reflective QoS, P-CSCF Address Index, PDU session Authentication, PLMN ID, LADN support, Access type preference, and Integrity protection on DRB, example descriptions of which are provided in the Description columns illustrated inFIGS. 4D-1 through 4D-4.

FIG. 5Ais a process flow diagram illustrating operations500athat may be performed as part of the method400by an IoT device. With reference toFIGS. 1-5Athe operations500amay be implemented in hardware components and/or software components of an IoT device (e.g., the IoT devices120) the operation of which may be controlled by one or more processors (e.g., the processors212,216,252or260).

Referring toFIG. 5A, in some implementations following the operations of block402of the method400(FIG. 4A), the processor may determine an identity of a network with which the IoT devices and communication in block502. For example, the processor may determine a PLMN identity or another suitable network identity. In block504, the processor may scan characteristics of the plurality of connectivity objects that are linked in the server object based on the determined network identity. The processor may proceed to perform the operations of block406of the method400(FIG. 4A).

FIG. 5Bis a process flow diagram illustrating operations500bthat may be performed by an IoT device and/or a base station for supporting 5G NR connectivity for Internet of Things (IoT) devices. With reference toFIGS. 1-5Bthe operations500bmay be implemented in hardware components and/or software components of an IoT device (e.g., the IoT devices120) and/or a base station (e.g., base stations110) the operation of which may be controlled by one or more processors (e.g., the processors212,216,252or260).

Referring toFIG. 5B, in block510a processor in the IoT device and/or base station may add one or more 5G NR network bearer support information elements to a connectivity monitoring object of the Lightweight Machine-to-Machine (LwM2M) protocol. In some embodiments, the connectivity monitoring object may include a network bearer information element and an available network bearer information element. In some embodiments, adding one or more 5G NR network bearer support information elements to the connectivity monitoring object of the LwM2M protocol may include adding information identifying a network bearer type or a communication session that can be established to the network bearer information element or the available network bearer information element. In some embodiments, adding one or more 5G NR network bearer support information elements to the connectivity monitoring object of the LwM2M protocol may include adding a 5G-NR cellular network information element to the connectivity monitoring object. In some embodiments, adding one or more 5G NR network bearer support information elements to the connectivity monitoring object of the LwM2M protocol may include adding to the connectivity monitoring object at least one or more of a 5G-NR frequency division duplexing (FDD) cellular network information element or a 5G-NR time division duplexing (TDD) cellular network information element. In block512, the processor may use 5G specific parameters to add support for 5G non-standalone (NSA) and/or 5G standalone (SA) objects to the LwM2M protocol. In block514, the processor may provide 5G radio access technology (RAT) based device management.

FIG. 5Cis a process flow diagram illustrating operations500cthat may be performed by an IoT device for supporting 5G NR connectivity for Internet of Things (IoT) devices. With reference toFIGS. 1-5Cthe operations500cmay be implemented in hardware components and/or software components of an IoT device (e.g., the IoT devices120) the operation of which may be controlled by one or more processors (e.g., the processors212,216,252or260).

Referring toFIG. 5C, in block520a processor in the IoT device (e.g., the IoT devices120) may indicate in a connectivity monitoring object of the Lightweight Machine-to-Machine (LwM2M) protocol transmitted to a base station whether an IoT device is capable of receiving 5G NR. This indication may be provided by including a value assigned in the connectivity monitoring object to indicating 5G NR network capability of the IoT device. In some embodiments the connectivity monitoring object transmitted to the base station in block520may include a network bearer information element and an available network bearer information element, and the 5G NR network bearer support information received from the base station in block522may include information identifying a network bearer type or a communication session that can be established with the base station. In some embodiments indicating in the connectivity monitoring object of the LwM2M protocol in block520may include adding or including a 5G-NR cellular network information element in the transmitted connectivity monitoring object. In some embodiments indicating in the connectivity monitoring object of the LwM2M protocol in block520may include adding or including in the connectivity monitoring object at least one or more of a 5G-NR frequency division duplexing (FDD) cellular network information element or a 5G-NR time division duplexing (TDD) cellular network information element. In some embodiments, the processor may include the value 8 to indicate 5G NR cellular network capability. In some embodiments, the processor may include the value 8 to indicate 5G NR FDD cellular network capability or 9 to indicate 5G NR TDD cellular network capability.

In block522, the processor may receive 5G NR network bearer support information from the base station consistent with the capability indicated in the connectivity monitoring object in block520.

FIG. 5Dis a process flow diagram illustrating operations500dthat may be performed by a base station for supporting 5G NR connectivity for Internet of Things (IoT) devices. With reference toFIGS. 1-5Dthe operations500dmay be implemented in hardware components and/or software components of a base station (e.g., base stations110) the operation of which may be controlled by one or more processors.

Referring toFIG. 5D, in block530the base station may receive from an IoT device one or more 5G NR network bearer support information elements in a connectivity monitoring object of the Lightweight Machine-to-Machine (LwM2M) protocol. As noted above for block522, the connectivity monitoring object received from the IoT device may include a network bearer information element and an available network bearer information element. In some embodiments, the 5G NR network bearer support information may include information identifying a network bearer type or a communication session that can be established with the base station. In some embodiments, receiving the 5G NR network bearer support information elements in a connectivity monitoring object of the LwM2M protocol in block530may include receiving 5G-NR cellular network information element in the connectivity monitoring object. In some embodiments, receiving from an IoT device one or more 5G NR network bearer support information elements in a connectivity monitoring object of the LwM2M protocol in block530may include receiving at least one or more of a 5G-NR frequency division duplexing (FDD) cellular network information element or a 5G-NR time division duplexing (TDD) cellular network information element. In some embodiments, the received network bearer support information element in a connectivity monitoring object may include the value 8 to indicate 5G NR cellular network capability. In some embodiments, the received network bearer support information element in a connectivity monitoring object may include the value 8 to indicate 5G NR FDD cellular network capability or 9 to indicate 5G NR TDD cellular network capability.

In block532, the base station may transmit 5G specific parameters to the IoT providing support for 5G non-standalone (NSA) or 5G standalone (SA) objects to the LwM2M protocol consistent with the received network bearer support information element in a connectivity monitoring object. In block534, the base station may provide 5G NR service to the IoT device.

The various embodiments may be implemented on a variety of IoT devices, an example in the form of a circuit board for use in a device is illustrated inFIG. 6. With reference toFIGS. 1-6, an IoT device600may include a first SOC202(e.g., an SOC-CPU) coupled to a second SOC204(e.g., a 5G capable SOC) and a wireless transceiver266. The first and second SOCs202,204may be coupled to internal memory606. Additionally, the IoT device600may include or be coupled to an antenna604for sending and receiving wireless signals from a wireless transceiver266or within the second SOC204. The antenna604and wireless transceiver266and/or second SOC204may support communications using various RATs, including Cat.-M1, NB-IoT, CIoT, GSM, and/or VoLTE.

An IoT device600may also include a sound encoding/decoding (CODEC) circuit610, which digitizes sound received from a microphone into data packets suitable for wireless transmission and decodes received sound data packets to generate analog signals that are provided to a speaker to generate sound in support of voice or VoLTE calls. Also, one or more of the processors in the first and second SOCs202,204, wireless transceiver266and CODEC610may include a digital signal processor (DSP) circuit (not shown separately).

Some IoT devices may include an internal power source, such as a battery612configured to power the SOCs and transceiver(s). Such IoT devices may include power management components616to manage charging of the battery612.

The various embodiments (including, but not limited to, embodiments discussed above with reference toFIGS. 1-18) may also be implemented on any of a variety of commercially available server devices, such as the server700illustrated inFIG. 7. Such a server700typically includes a processor701coupled to volatile memory702and a large capacity nonvolatile memory, such as a disk drive703. The server700may also include a floppy disc drive, compact disc (CD) or digital versatile disc (DVD) drive706coupled to the processor701. The server700may also include one or more network transceivers704, such as a network access port, coupled to the processor701for establishing network interface connections with a communication network707, such as a local area network coupled to other announcement system computers and servers, the Internet, the public switched telephone network, and/or a cellular network (e.g., CDMA, TDMA, GSM, PCS, 3G, 4G, 5G, LTE, or any other type of cellular network).

The processors used in any embodiments may be any programmable microprocessor, microcomputer or multiple processor chip or chips that can be configured by software instructions (applications) to perform a variety of functions, including the functions of the various embodiments described in this application. In some IoT devices, multiple processors may be provided, such as one processor dedicated to wireless communication functions (e.g., in SOC204) and one processor dedicated to running other applications (e.g., in SOC202). Typically, software applications may be stored in the internal memory220,258,606, before they are accessed and loaded into a processor. The processor may include internal memory sufficient to store the application software instructions.

A number of different cellular and mobile communication services and standards are available or contemplated in the future, all of which may implement and benefit from the various embodiments. Such services and standards include, e.g., third generation partnership project (3GPP), long term evolution (LTE) systems, third generation wireless mobile communication technology (3G), fourth generation wireless mobile communication technology (4G), fifth generation wireless mobile communication technology (5G), global system for mobile communications (GSM), universal mobile telecommunications system (UMTS), 3GSM, general packet radio service (GPRS), code division multiple access (CDMA) systems (e.g., cdmaOne, CDMA1020™), enhanced data rates for GSM evolution (EDGE), advanced mobile phone system (AMPS), digital AMPS (IS-136/TDMA), evolution-data optimized (EV-DO), digital enhanced cordless telecommunications (DECT), Worldwide Interoperability for Microwave Access (WiMAX), wireless local area network (WLAN), Wi-Fi Protected Access I & II (WPA, WPA2), and integrated digital enhanced network (IDEN). Each of these technologies involves, for example, the transmission and reception of voice, data, signaling, and/or content messages. It should be understood that any references to terminology and/or technical details related to an individual telecommunication standard or technology are for illustrative purposes only, and are not intended to limit the scope of the claims to a particular communication system or technology unless specifically recited in the claim language.