Patent Description:
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 = <NUM>), a server object (Object ID = <NUM>), an access control object (Object ID = <NUM>), a device object (Object ID = <NUM>), a connectivity monitoring object (Object ID = <NUM>), and a firmware update object (Object ID = <NUM>). 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. <CIT> teaches the provision of a configuration server to determine one or more preferred communication bearers for a device, where configuration data, including the preferred communication bearer, is sent from the configuration server to the device. In one example, LwM2M protocol is used for sending the configuration data. The citation refers exclusively to <NUM> GPP systems, and not to <NUM> systems. "<NPL> refers to the LwM2M standard, and discusses the benefits of <NUM> systems, whilst indicating that LwM2M is "<NUM> Ready". It is discussed that when LTE-M and NB-IoT were introduced, extensions were made to the LwM2M objects to support new requirements and features for these technologies. However, there is no discussion of extensions suitable or required for <NUM>.

Various embodiments will be described in detail with reference to the accompanying drawings. References made to particular examples and implementations are for illustrative purposes, and are not intended to limit the scope of the claims.

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 )<NUM> standards, or any of the IEEE <NUM> 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 <NUM>. <NUM> 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 <NUM>, <NUM> or <NUM>, or further implementations thereof, technology.

The term "system in a package" (SIP) is used herein to refer to a single module or package that contains multiple resources, computational units, cores and/or processors on two or more IC chips, substrates, or SOCs. For example, a SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, the SIP may include one or more multichip modules (MCMs) on which multiple ICs or semiconductor dies are packaged into a unifying substrate. A SIP may also include multiple independent SOCs coupled together via high speed communication circuitry and packaged in close proximity, such as on a single motherboard or in a single IoT device. The proximity of the SOCs facilitates high speed communications and the sharing of memory and resources.

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 = <NUM>) 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 <NUM>-NR capable chipsets or for supporting network connectivity and/or communicating up-to-date connection values in <NUM> 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 <NUM>-NR capable chipsets and IoT devices, better support establishing or maintaining network connectivity, and/or better support communicating up-to-date connection values in <NUM> NR and future networks. Various embodiments include adding one or more <NUM> NR network bearer support IEs to the connectivity monitoring object (Object ID = <NUM>). In various embodiments, IoT devices and network elements may be configured to support <NUM> RAT based device management by adding support for <NUM> non-standalone (NSA) and/or <NUM> standalone (SA) objects with <NUM> specific parameters.

In some embodiments, adding <NUM> NR network bearer support IEs to the connectivity monitoring object (Object ID = <NUM>) may include adding information identifying the <NUM>-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 <NUM>-NR cellular network IE to the connectivity monitoring object (Object ID = <NUM>). In some embodiments, the IoT devices and network elements may be configured to add a <NUM>-NR frequency division duplexing (FDD) cellular network IE and/or a <NUM>-NR time division duplexing (TDD) cellular network IE to the connectivity monitoring object (Object ID = <NUM>). In some embodiments, the IoT devices and network elements may be configured to support <NUM> RAT based device management by adding support for <NUM> non-standalone (NSA) and/or <NUM> standalone (SA) objects with <NUM> 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, <NUM> 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., <NUM>-<NUM>, 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 "<NUM>" and "<NUM>" may identify evolved packet core (EPC) as the core network, and connectivity options <NUM>," "<NUM>," "<NUM>" and "<NUM>" may identify <NUM> core (5GC) as the core network. Connectivity option "<NUM>" may further identify new radio (NR) as the secondary RAT. Connectivity options "<NUM>" and "<NUM>" may identify new radio (NR) as the master RAT, and connectivity options "<NUM>" and "<NUM>" may identify eLTE as the master RAT. Connectivity option "<NUM>" may identify eLTE as the secondary RAT. Connectivity option "<NUM>" 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 <NUM> cell (in SA or NSA mode).

The S-NSSAI IE may indicate the S-NSSAI element for <NUM> 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 <NUM> SA (FDD/TDD) cellular network. The PDU session id IE may identify the PDU session over which LwM2M session is established for the <NUM> SA (FDD/TDD) cellular network. The SSC mode IE may identify the SSC mode (e.g., SSC Mode <NUM>, SSC Mode <NUM>, SSC Mode <NUM>, etc.) for the <NUM> 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 <NUM> SA (FDD/TDD) cellular network.

The 5QI IE may identify the <NUM> QoS (e.g., standard, operator specific, reserved, spare, etc.) for the <NUM> 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 <NUM> SA (FDD/TDD) cellular network. The QFI IE may identify the QoS flow for the <NUM> SA (FDD/TDD) cellular network. The session AMBR IE may identify the session aggregate maximum bit rate as per the <NUM> 3GPP Spec for the <NUM> 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 <NUM> 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 <NUM> 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 <NUM> SA (FDD/TDD) cellular network. The P-CSCF address index IE may identify an index for the P-CSCF address for the <NUM> 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 <NUM> SA (FDD/TDD) cellular network. The LADN support IE may identify whether LADN is supported for the <NUM> SA (FDD/TDD) cellular network. The access type preference IE may identify the access type preference (e.g., 3GPP, Non-3GPP, etc.) for the <NUM> 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 <NUM> SA (FDD/TDD) cellular network.

Some embodiments may include methods for supporting Fifth Generation (<NUM>) New Radio (NR) connectivity for Internet of Things (IoT) devices, which may include adding one or more <NUM> NR network bearer support information elements to a connectivity monitoring object of the Lightweight Machine-to-Machine (LwM2M) protocol, using <NUM> specific parameters to add support for <NUM> non-standalone (NSA) and/or <NUM> standalone (SA) objects to the LwM2M protocol, and providing <NUM> 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 <NUM> 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 <NUM> NR network bearer support information elements to the connectivity monitoring object of the LwM2M protocol may include adding a <NUM>-NR cellular network information element to a connectivity monitoring object. In some embodiments, adding one or more <NUM> 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 <NUM>-NR frequency division duplexing (FDD) cellular network information element or a <NUM>-NR time division duplexing (TDD) cellular network information element.

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

In the example illustrated in <FIG>, the wireless network <NUM> includes a number of base stations <NUM> and other network entities. A base station may be a station that communicates with wireless devices including IoT devices. Each base station <NUM> may 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 (<NUM>) network systems, the term "cell" and eNB, Node B, <NUM> 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 network <NUM> through various types of backhaul interfaces such as a direct physical connection, a virtual network, or the like using any suitable transport network.

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 networks <NUM> supporting 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., <NUM>). Wireless networks <NUM> may 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 in <FIG>, the base stations 110a, 110b and 110c may be macro base stations for the macro cells 102a, 102b and 102c, respectively. The base station 110x may be a pico base station for a pico cell 102x. The base stations 110y and 110z may be femto base station for the femto cells 102y and 102z, 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.

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 in <FIG>, a relay station 110r may communicate with the base station 110a and an IoT device 120r in order to facilitate communication between the base station 110a and the IoT device 120r. 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 network <NUM> may 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 network <NUM>. For example, macro base station may have a high transmit power level (e.g., <NUM> Watts) whereas pico base station, femto base station, and relays may have a lower transmit power level (e.g., <NUM> Watt).

The techniques described herein may be used for both synchronous and asynchronous operations.

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

The IoT devices <NUM> (e.g., 120x, 120y, etc.) may be dispersed throughout the wireless network <NUM>, 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.

In <FIG>, 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.

For example, the spacing of the subcarriers may be <NUM> and the minimum resource allocation (called a "resource block") may be <NUM> subcarriers (or <NUM>). Consequently, the nominal full frame transfer (FFT) size may be equal to <NUM>, <NUM>, <NUM>, <NUM> or <NUM> for system bandwidth of <NUM>, <NUM>, <NUM>, <NUM> or <NUM> megahertz (MHz), respectively. For example, a subband may cover <NUM> (i.e., <NUM> resource blocks), and there may be <NUM>, <NUM>, <NUM>, <NUM> or <NUM> subbands for system bandwidth of <NUM>, <NUM>, <NUM>, <NUM> or <NUM>, respectively.

A NR base station (e.g., eNB, <NUM> 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> illustrates an example computing system or SIP <NUM> architecture that may be used in IoT devices (e.g., the IoT devices <NUM>) implementing the various embodiments. With reference to <FIG> and <FIG>, the SIP <NUM> may provide all of the processing, data storage and communication capabilities required to support the mission or functionality of a given IoT device. The same SIP <NUM> may 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 SIP <NUM> is 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 SIP <NUM> illustrated in <FIG> includes two SOCs <NUM>, <NUM>, a wireless transceiver <NUM>, a clock <NUM>, and a voltage regulator <NUM>. In some embodiments, the first SOC <NUM> operates 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 SOC <NUM> may operate as a specialized processing unit. For example, the second SOC <NUM> may operate as a specialized <NUM> processing unit responsible for managing high volume, high speed (e.g., <NUM> Gbps, etc.), and/or very high frequency short wave length (e.g., <NUM> mmWave spectrum, etc.) communications.

In the example illustrated in <FIG>, the first SOC <NUM> includes a digital signal processor (DSP) <NUM>, a modem processor <NUM>, a graphics processor <NUM>, an application processor <NUM>, one or more coprocessors <NUM> (e.g., vector co-processor) connected to one or more of the processors, memory <NUM>, custom circuity <NUM>, system components and resources <NUM>, an interconnection/bus module <NUM>, one or more temperature sensors <NUM>, a thermal management unit <NUM>, and a thermal power envelope (TPE) component <NUM>. The second SOC <NUM> includes a <NUM> modem processor <NUM>, a power management unit <NUM>, temperature sensors 262a 262b, an interconnection/bus module <NUM>, a plurality of mmWave transceivers <NUM>, memory <NUM>, and various additional processors <NUM>, such as an applications processor, packet processor, etc..

The first and second SOC <NUM>, <NUM> may 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 resources <NUM> of the first SOC <NUM> may 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 resources <NUM> and/or custom circuitry <NUM> may also include circuitry to interface with peripheral devices, such as cameras, electronic displays, wireless communication devices, external memory chips, etc..

The first and second SOC <NUM>, <NUM> may communicate via an interconnection/bus module <NUM>. The various processors <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, may be interconnected to one or more memory elements <NUM>, system components and resources <NUM>, and custom circuitry <NUM>, and a thermal management unit <NUM> via an interconnection/bus module <NUM>. Similarly, the processors <NUM>, <NUM> may be interconnected to the power management unit <NUM>, the mmWave transceivers <NUM>, memory <NUM>, and various additional processors <NUM> via the interconnection/bus module <NUM>. The interconnection/bus module <NUM>, <NUM>, <NUM> may 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 SOCs <NUM>, <NUM> may further include an input/output module (not illustrated) for communicating with resources external to the SOC, such as a clock <NUM> and a voltage regulator <NUM>. Resources external to the SOC (e.g., clock <NUM>, voltage regulator <NUM>) may be shared by two or more of the internal SOC processors/cores.

<FIG> illustrates an example Non-IP Data Delivery (NIDD) data call architecture <NUM> suitable for use with various embodiments. With reference to <FIG>, the architecture <NUM> shows an example of a NIDD data call between an IoT device <NUM> (e.g., IoT devices <NUM>) and a server <NUM>. The architecture <NUM> is 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 architecture <NUM>. Other protocols, such as other OMA protocols may be used to establish a NIDD data call and the architecture <NUM> may apply to non-LwM2M NIDD data calls. The IoT device <NUM> and the server <NUM> may be configured to communicate using NIDD. As an example, the IoT device <NUM> may be a LwM2M client device. As an example, the server <NUM> may be a LwM2M server, such as a bootstrap server as defined by LwM2M or an LwM2M server that is not a bootstrap server. The server <NUM> may be an application server.

A Service Capability Exposure Function (SCEF) <NUM> enables NIDD communication between the IoT device <NUM> and the server <NUM>. The SCEF <NUM> enables devices such as the IoT device <NUM> and the application server <NUM> to access certain communication services and capabilities, including NIDD. The SCEF <NUM> may support Relative Duplex Distance (RDD). While illustrated as in communication with one server <NUM>, the SCEF <NUM> may 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 SCEF <NUM> may include multiplexed traffic intended for multiple different destinations.

In some embodiments, the IoT device <NUM> may be configured with an LwM2M client 302a that uses the LwM2M device management protocol. The LwM2M device management protocol defines an extensible resource and data model. The LwM2M client 302a may employ a service-layer transfer protocol such as Constrained Application Protocol (CoAP) 302b to enable, among other things reliable and low overhead transfer of data. The IoT device <NUM> may 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 Application 302d. The Non-IP Application 302d may utilize a non-IP protocol 302e to structure non-IP communications.

In some embodiments, the server <NUM> may be configured with an LwM2M server 304a, a transfer protocol such as CoAP 304b, and a security protocol such as DTLS 304c. The application server <NUM> may be configured to utilize a variety of communication protocols, such as non-IP protocol 304d, as well as other communication protocol such as UDP, SMS, TCP, and the like.

As an example, the IoT device <NUM> may 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 device <NUM> to 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 device <NUM> to embed a small amount of data in a container or object <NUM> without use of an IP stack, and to send the container or object <NUM> to the server <NUM> via the SCEF <NUM>. Similarly, the IoT device <NUM> may receive containers or objects <NUM> that define services and capabilities of the network <NUM> the IoT device <NUM> may be connected to enable the IoT device <NUM> to reach the SCEF <NUM> and server <NUM>. For example, such containers or objects <NUM> that define services and capabilities may include various OMA objects, such as an APN connection profile object (Object ID <NUM>), a LwM2M server object (Object ID <NUM>), a LwM2M security object (Object ID <NUM>), etc..

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

<FIG> is a process flow diagram, <FIG> illustrates a component block diagram, and <FIG> is a chart illustrating, illustrating a method <NUM> and aspects of components used in the method <NUM> according to some embodiments. With reference to <FIG>, the method <NUM> may be implemented in hardware components and/or software components of an IoT device (e.g., the IoT devices <NUM>) the operation of which may be controlled by one or more processors (e.g., the processors <NUM>, <NUM>, <NUM> or <NUM>).

In block <NUM>, 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 block <NUM>, the processor may scan characteristics of a plurality of connectivity objects that are linked in a server object. For example, referring to <FIG>, a server object <NUM> may include a plurality of links to connectivity objects, such as the connectivity objects <NUM>, <NUM>, <NUM>, and <NUM>.

In some embodiments, the connectivity objects may include instances of Object <NUM>. In some embodiments, the server object links may include APN links. In some embodiments, the characteristics of the connectivity objects may include an APN name <NUM>, a PLMN identifier <NUM>, a RAT identifier <NUM>, a packet data network (PDN) type <NUM>, and other suitable characteristics.

Referring to <FIG>, in some embodiments, the connectivity objects may include one or more instances of Object <NUM>. In some embodiments, the Object <NUM> instance(s) may include preference and/or priority information <NUM>, such as the example information in the Description column illustrated in <FIG>. In some embodiments, the Object <NUM> may include information indicating a preferred RAT. In some embodiments, the Object <NUM> may include information indicating a RAT priority indication. In some embodiments, the Object <NUM> may include a link to one or more Object <NUM> instances at a LwM2M client. In other embodiments, the server object, Object <NUM>, may include a link to an Object <NUM> instance.

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

Referring back to <FIG>, in block <NUM>, 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 block <NUM>, 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 <NUM> 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 <NUM> NR and receiving <NUM> NR network bearer support information from the base station. <FIG> illustrate an example <NUM> NR connectivity object that could be transmitted to a base station to indicate whether an IoT device is capable of receiving <NUM> NR. The <NUM> 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 in <FIG>.

<FIG> is a process flow diagram illustrating operations 500a that may be performed as part of the method <NUM> by an IoT device. With reference to <FIG> the operations 500a may be implemented in hardware components and/or software components of an IoT device (e.g., the IoT devices <NUM>) the operation of which may be controlled by one or more processors (e.g., the processors <NUM>, <NUM>, <NUM> or <NUM>).

Referring to <FIG>, in some implementations following the operations of block <NUM> of the method <NUM> (<FIG>), the processor may determine an identity of a network with which the IoT devices and communication in block <NUM>. For example, the processor may determine a PLMN identity or another suitable network identity. In block <NUM>, 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 block <NUM> of the method <NUM> (<FIG>).

<FIG> is a process flow diagram illustrating operations 500b that may be performed by an IoT device and/or a base station for supporting <NUM> NR connectivity for Internet of Things (IoT) devices. With reference to <FIG> the operations 500b may be implemented in hardware components and/or software components of an IoT device (e.g., the IoT devices <NUM>) and/or a base station (e.g.. , base stations <NUM>) the operation of which may be controlled by one or more processors (e.g., the processors <NUM>, <NUM>, <NUM> or <NUM>).

Referring to <FIG>, in block <NUM> a processor in the IoT device and/or base station may add one or more <NUM> 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 <NUM> 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 <NUM> NR network bearer support information elements to the connectivity monitoring object of the LwM2M protocol may include adding a <NUM>-NR cellular network information element to the connectivity monitoring object. In some embodiments, adding one or more <NUM> 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 <NUM>-NR frequency division duplexing (FDD) cellular network information element or a <NUM>-NR time division duplexing (TDD) cellular network information element. In block <NUM>, the processor uses <NUM> specific parameters to add support for <NUM> non-standalone (NSA) and/or <NUM> standalone (SA) objects to the LwM2M protocol. In block <NUM>, the processor may provide <NUM> radio access technology (RAT) based device management.

<FIG> is a process flow diagram illustrating operations 500c that may be performed by an IoT device for supporting <NUM> NR connectivity for Internet of Things (IoT) devices. With reference to <FIG> the operations 500c may be implemented in hardware components and/or software components of an IoT device (e.g., the IoT devices <NUM>) the operation of which may be controlled by one or more processors (e.g., the processors <NUM>, <NUM>, <NUM> or <NUM>).

Referring to <FIG>, in block <NUM> a processor in the IoT device (e.g., the IoT devices <NUM>) indicates 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 <NUM> NR. This indication may be provided by including a value assigned in the connectivity monitoring object to indicating <NUM> NR network capability of the IoT device. In some embodiments the connectivity monitoring object transmitted to the base station in block <NUM> may include a network bearer information element and an available network bearer information element, and the <NUM> NR network bearer support information received from the base station in block <NUM> may 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 block <NUM> may include adding or including a <NUM>-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 block <NUM> may include adding or including in the connectivity monitoring object at least one or more of a <NUM>-NR frequency division duplexing (FDD) cellular network information element or a <NUM>-NR time division duplexing (TDD) cellular network information element. In some embodiments, the processor may include the value <NUM> to indicate <NUM> NR cellular network capability. In some embodiments, the processor may include the value <NUM> to indicate <NUM> NR FDD cellular network capability or <NUM> to indicate <NUM> NR TDD cellular network capability.

In block <NUM>, the processor receives <NUM> NR network bearer support information from the base station consistent with the capability indicated in the connectivity monitoring object in block <NUM>.

<FIG> is a process flow diagram illustrating operations 500d that may be performed by a base station for supporting <NUM> NR connectivity for Internet of Things (IoT) devices. With reference to <FIG> the operations 500d may be implemented in hardware components and/or software components of a base station (e.g.. , base stations <NUM>) the operation of which may be controlled by one or more processors.

Referring to <FIG>, in block <NUM> the base station may receive from an IoT device one or more <NUM> NR network bearer support information elements in a connectivity monitoring object of the Lightweight Machine-to-Machine (LwM2M) protocol. As noted above for block <NUM>, 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 <NUM> 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 <NUM> NR network bearer support information elements in a connectivity monitoring object of the LwM2M protocol in block <NUM> may include receiving <NUM>-NR cellular network information element in the connectivity monitoring object. In some embodiments, receiving from an IoT device one or more <NUM> NR network bearer support information elements in a connectivity monitoring object of the LwM2M protocol in block <NUM> may include receiving at least one or more of a <NUM>-NR frequency division duplexing (FDD) cellular network information element or a <NUM>-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 <NUM> to indicate <NUM> NR cellular network capability. In some embodiments, the received network bearer support information element in a connectivity monitoring object may include the value <NUM> to indicate <NUM> NR FDD cellular network capability or <NUM> to indicate <NUM> NR TDD cellular network capability.

In block <NUM>, the base station transmits <NUM> specific parameters to the IoT providing support for <NUM> non-standalone (NSA) or <NUM> standalone (SA) objects to the LwM2M protocol consistent with the received network bearer support information element in a connectivity monitoring object. In block <NUM>, the base station provides <NUM> 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 in <FIG>. With reference to <FIG>, an IoT device <NUM> may include a first SOC <NUM> (e.g., an SOC-CPU) coupled to a second SOC <NUM> (e.g., a <NUM> capable SOC) and a wireless transceiver <NUM>. The first and second SOCs <NUM>, <NUM> may be coupled to internal memory <NUM>. Additionally, the IoT device <NUM> may include or be coupled to an antenna <NUM> for sending and receiving wireless signals from a wireless transceiver <NUM> or within the second SOC <NUM>. The antenna <NUM> and wireless transceiver <NUM> and/or second SOC <NUM> may support communications using various RATs, including Cat. -M1, NB-IoT, CIoT, GSM, and/or VoLTE.

An IoT device <NUM> may also include a sound encoding/decoding (CODEC) circuit <NUM>, 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 SOCs <NUM>, <NUM>, wireless transceiver <NUM> and CODEC <NUM> may include a digital signal processor (DSP) circuit (not shown separately).

Some IoT devices may include an internal power source, such as a battery <NUM> configured to power the SOCs and transceiver(s). Such IoT devices may include power management components <NUM> to manage charging of the battery <NUM>.

The various embodiments (including, but not limited to, embodiments discussed above with reference to FIGs. <NUM>-<NUM>) may also be implemented on any of a variety of commercially available server devices, such as the server <NUM> illustrated in <FIG>. Such a server <NUM> typically includes a processor <NUM> coupled to volatile memory <NUM> and a large capacity nonvolatile memory, such as a disk drive <NUM>. The server <NUM> may also include a floppy disc drive, compact disc (CD) or digital versatile disc (DVD) drive <NUM> coupled to the processor <NUM>. The server <NUM> may also include one or more network transceivers <NUM>, such as a network access port, coupled to the processor <NUM> for establishing network interface connections with a communication network <NUM>, 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, <NUM>, <NUM>, <NUM>, 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 SOC <NUM>) and one processor dedicated to running other applications (e.g., in SOC <NUM>). Typically, software applications may be stored in the internal memory <NUM>, <NUM>, <NUM>, before they are accessed and loaded into a processor. The processor may include internal memory sufficient to store the application software instructions.

As used in this application, the terms "component," "module," "system," and the like are intended to include a computer-related entity, such as, but not limited to, hardware, firmware, a combination of hardware and software, software, or software in execution, which are configured to perform particular operations or functions. For example, a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on an IoT device and the IoT device may be referred to as a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one processor or core and/or distributed between two or more processors or cores. In addition, these components may execute from various non-transitory computer readable media having various instructions and/or data structures stored thereon. Components may communicate by way of local and/or remote processes, function or procedure calls, electronic signals, data packets, memory read/writes, and other known network, computer, processor, and/or process related communication methodologies.

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 (<NUM>), fourth generation wireless mobile communication technology (<NUM>), fifth generation wireless mobile communication technology (<NUM>), 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, CDMA1020TM), enhanced data rates for GSM evolution (EDGE), advanced mobile phone system (AMPS), digital AMPS (IS-<NUM>/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.

Various embodiments illustrated and described are provided merely as examples to illustrate various features of the claims. However, features shown and described with respect to any given embodiment are not necessarily limited to the associated embodiment and may be used or combined with other embodiments that are shown and described. Further, the claims are not intended to be limited by any one example embodiment. For example, one or more of the operations of the methods may be substituted for or combined with one or more operations of the methods.

The hardware used to implement various illustrative logics, logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A processor may also be implemented as a combination of receiver smart objects, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuitry that is specific to a given function.

Claim 1:
A method (500c) for supporting device management in Fifth Generation New Radio, <NUM> NR connectivity for Internet of Things, IoT, devices, the method being performed by an IoT device and comprising:
indicating (<NUM>) in a connectivity monitoring object of the Lightweight Machine-to-Machine, LwM2M, protocol transmitted to a base station whether the IoT device is capable of receiving <NUM> NR; and
receiving (<NUM>) <NUM> NR network bearer support information from the base station; and
wherein the connectivity monitoring object further comprises <NUM> specific parameters providing support for <NUM> non-standalone, NSA, and/or <NUM> standalone, SA, objects to the LwM2M protocol.