Device Management Implementation Guide for IoT Solutions

Transcription

1 Device Management Implementation Guide Device Management Implementation Guide for IoT Solutions Version 3.0

2 Author(s) Group Phone # Steve Hardin IoT Solutions (AT&T) +1 (404) sh3153@att.com Jordan Alexander IoT Solutions (AT&T) +1 (470) ja154p@att.com Alpana Hoffman Project Manager (Nokia) alpana.hoffman@nokia.com John Engquist Technical Point of Contact john.engquist@nokia.com (Nokia) Rano Sugandi Pre-Sales PM (Nokia) rano.sugandi@nokia.com Elvis Mena OEM Customer Team (Nokia) elvis.mena@nokia.com John Ramey OEM Customer Team (Nokia) John.ramey@nokia.com 2

3 Abstract This document is an implementation guide for technical approval of Embedded Wireless Radio Modules and Internet of Things (IoT) Host Devices. The guide describes what to consider when implementing OMA-DM or LwM2M into the Embedded Wireless Radio Module for AT&T. Please direct any questions to your IoT Solutions contact. IoT Host Device integrators are directed to review the Appendix A - Minimum Requirements to Implement ODIS/DHIR/Portfolio for IoT Host Devices using an Approved Module (AM) at the end of this document for a simplified guide for enabling and leveraging the ODIS/DHIR/Portfolio functionality embedded in an chosen radio module that supports ODIS/DHIR/Portfolio. This document contains trade secrets and proprietary information of AT&T. No use or disclosure of the information contained herein is permitted without prior written consent. Revision History Date Revision Description 7/9/ Withdrew v.16 of ODIS Implementation Guide 7/9/ Initial release of public version of Device Management Implementation guide 8/3/ Added CDR-DVM details for IoT bootstrap accounts. 4/26/ Section 1.5: Added address for delivery of.csv files. Added requirement for legacy devices manufactured in 2015 & /6/ Section 1.5: Added table showing sample data. Re-added host unique ID into the data set request. 7/29/ Added sections 3.4 and 3.5 5/22/ New format 8/22/ Changed Bootstrap Accounts into LWM2M Server Accounts and added Bootstrap Accounts for actual Bootstrap Servers. Added method for Registration Update Trigger over SMS. Added Nokia contacts. 3

4 Table of Contents 1. Introduction Architecture System Components Support Requirements for IoT Host Devices IoT Host Device Requirements General Support Requirements for Modules Embedded Wireless Radio Module Requirements Device Management Client Protocols OMA-DM or LwM2M OMA-DM Specifications LwM2M Specifications AT&T Subscriber Product Engineering Device Requirements OEM Specific DM Implementations ODIS/DHIR/Portfolio Requirements for IOT Modules General ODIS/DHIR/Portfolio Requirements for the Module Default ODIS/DHIR/Portfolio settings in DM client Default ODIS/DHIR/Portfolio Values for IoT Modules Firmware Update Over the Air (FOTA) Memory Allocation in the Module Host Device to Radio Module Interface Requirements for IOT Modules supporting OMA DM General OMA DM Requirements Dedicated APN for OMA DM DM Account Provisioning for IoT Modules Supporting OMA DM DM Account Parameters for IOT Modules Supporting OMA DM <CDR-DVM-3954> First DM Account Parameters for a Module <CDR-DVM-3955> Second DM Account Parameters for a Module Identity and Detail Nodes for IOT Modules Supporting OMA DM Embedded IOT Module SVN (IMEI SV) ODIS/DHIR Support by an IOT Module Utilizing OMA-DM Firmware Update Over the Air (FOTA) OMA-DM Firmware Update Management Object (FUMO) Support

5 Proprietary Update Memory Allocation in the Module Requirements for IOT Modules supporting LWM2M General LWM2M Requirements Dedicated APN for LWM2M UQS (UDP with Queue Mode and SMS) Transport and Binding Mode Support LWM2M Operations Data Formats Bootstrap Server Account Provisioning for IoT Modules Supporting LWM2M Bootstrap Prioritization Sequence for IOT Modules Supporting LWM2M <CDR-DVM-032> Support for OMA LWM2M Bootstrap Profile as specified in the OMA LWM2M specification <CDR-DVM-033> Support for OMA LWM2M Write of Bootstrap Profile Production Bootstrap Server Security Object Lab Bootstrap Server Security Object Production Server Security Object Parameters for an IOT Module supporting LWM2M Lab Server Security Object Parameters for an IOT Module supporting LWM2M Production Server Object Parameters for an IOT Module supporting LWM2M Lab Server Object Parameters for an IOT Module supporting LWM2M Device Details Object for IoT Modules Supporting LWM2M ODIS/DHIR/Portfolio Support by an IOT Module Utilizing LwM2M LWM2M Object: Portfolio LWM2M Server Object Short Server ID Disable Binding Registration Update Trigger Registration Update Trigger with SMS Access Control Object Object ID Object Instance ID

6 Access Control Owner LWM2M FOTA LWM2M Object: Firmware Update Device Management Testing for IOT Modules Nokia XDM Server Interoperability Testing AT&T Technical Acceptance Testing Appendix A - Minimum Requirements to Implement ODIS/DHIR/Portfolio for IoT Host Devices using an Approved Module (AM) Host Device Test Scope Appendix B - Custom Object ID for ODIS/DHIR Parameters utilizing LWM2M LwM2M Object: HostDeviceInfo Appendix C CoAP over SMS Registration Update Trigger

7 1. Introduction AT&T Internet of Things Solutions Organization AT&T Internet of Things Solutions (IoTS) envisions a scenario where we will enable the ability to provide device management to most of the IoTS embedded wireless radio modules and host devices in our network as a service/solution which may benefit our IoTS partners. This includes all verticals Architecture To better facilitate an understanding of the Device Management Implementation required by AT&T a diagram is provided below System Components For the purposes of this implementation guide, the following components will be referenced: Internet of Things Host Device (IoTHD) - The IoTHD could be a wide variety of connected devices usually serving a specific application and could be part of a larger system of connected devices. Examples could include, but are not limited to utility meters, vehicles, asset or fleet tracking devices, security alarm panels, routers or gateways, etc. In many cases for purposes of simplicity this document will refer to the IoTHD as the host device. IoT Host Device integrators are directed to review the Appendix A - Minimum Requirements to Implement ODIS/DHIR/Portfolio for IoT Host Devices using an Approved Module (AM) at the end of this document for a simplified guide for enabling and leveraging the ODIS/DHIR/Portfolio functionality embedded in an chosen radio module that supports ODIS/DHIR/Portfolio. 7

8 Embedded Wireless Radio Module (EWRM) - The EWRM provides wireless connectivity for the IoTHD. For the purposes of this implementation guide, it is assumed that the EWRM has an embedded Device Management (DM) Client that could be based on either OMA-DM (Open Mobile Alliance Device management) or LwM2M (Lightweight Machine to Machine) standards. In many cases for purposes of simplicity this document will refer the EWRM as the module, IOT module or radio module. OMA-DM IMEI Sync (ODIS) A device management service developed by AT&T used to identify unique IoT devices deployed in a wireless network. ODIS is primarily targeted to host devices which utilize an embedded wireless radio module. Without this service, it is very difficult for a wireless operator to identify unique IoT Host Devices which utilize/leverage an IMEI value which is assigned to the manufacturer of the embedded radio module. The initial implementation of this service utilized the OMA Device Management (OMA-DM) standard. It has since been expanded to also utilize the LwM2M standard API but is referred to as the Portfolio Object within LWM2M. The alternative to the Portfolio object is object also created by AT&T Device Host Identity Reporting (DHIR) This service application should be identical to the AT&T proprietary ODIS service. In an effort to promote wider adoption and use of the ODIS service in 2014 AT&T submitted the service to the committee in GSMA working on the GSMA Connection Efficiency Guidelines. The committee decided to rename the service Device Host Identity Reporting (DHIR) for use within GSMA. The GSMA guidelines containing DHIR were published in International Mobile Equipment Identity (IMEI) The IMEI is a unique 15-digit code used to identify an individual GSM or UTRA or E-UTRA device to a mobile network. The 15 digits of the IMEI consist of 3 parts (an 8 digit TAC, a 6 digit Serial Number Range, and a single digit Check Digit). The 6 digit Serial Number Range allows for up to 1 Million unique IMEI values for every assigned TAC value. Type Allocation Code (TAC) The TAC is the first 8 digits of a 15 digit IMEI. A TAC is issued in blocks of 1M. When a new unique IMEI range is to be assigned the next available TAC is assigned. Typical practice is that IoT devices leverage a TAC which is already allocated to an embedded radio module supplier hence any TAC database reference for such designs identify the supplier of the radio module and do not identify the host device. It is allowed for a Host Device using a radio module design to acquire a dedicated TAC for the device which would then need to be programmed into the embedded radio module before the IoT Host Device is deployed. This method requires tight logistic coordination between the embedded radio module supplier and the IoT Host device manufacturer which is why it is very seldom the chosen method of implementation. Device Management Platform - AT&T manages a DM Platform within its network. This platform is capable of supporting both OMA-DM and LwM2M protocols. The device 8

9 management platform will be used for various functions including device identification and device firmware upgrades. WARNING: For purposes of reading industry specifications such as OMA-DM, LwM2M, and even AT&T many of these documents may refer to the term device. Since the model AT&Tsupports leverages the EWRM to be the master of the device management function for our architecture the term device in these other specifications may be in reference to a function intended for the EWRM. Please be careful not to assume that references to the term device in other specifications is intended to refer to the IoT Host Device. 9

10 2. Support Requirements for IoT Host Devices 2.1. IoT Host Device Requirements IoT Host Devices are required to support the basic ODIS/DHIR/Portfolio functions. IoT Host Device integrators are directed to review the Appendix A - Minimum Requirements to Implement ODIS/DHIR/Portfolio for IoT Host Devices using an Approved Module (AM) of this document for a simplified guide describing how to enable and leverage the ODIS/DHIR/Portfolio functionality embedded in a chosen radio module that supports ODIS/DHIR/Portfolio. IoT Host Devices may optionally support services including data streaming, command and control, and FOTA of the host device offered from the device management applications embedded in the module. 10

11 3. General Support Requirements for Modules AT&T will heavily depend on its module partner ecosystem to properly implement these features to simplify the implementation for hundreds of IoT Host Device integrators. This is why the concepts presented rely on the radio module to be the master element in the relationship between the host device and the module Embedded Wireless Radio Module Requirements The types of device management applications that AT&T may deploy will vary according to customer need. Presently only one application (ODIS/DHIR/Portfolio) is mandatory for all radio modules. ODIS/DHIR/Portfolio support by Radio Modules via either OMA-DM or LwM2M: Effective July 1, 2014, new radio modules entering the AT&T Network Ready Lab for certification must support OMA-DM ODIS/DHIR or LWMWM Portfolio. EXCEPTION: The radio module will only be utilized by a single model of an integrated device and all TACs used in the radio module will only be utilized for that single integrated device. EXCEPTION: The radio module will only be utilized by computing based devices which by PTCRB rules are required to obtain a unique IMEI TAC per device model. (If the module will also be utilized for M2M use cases and does not meet any of the other exception rules then ODIS/DHIR/Portfolio is required). Additional applications supported by the radio module may include but are not limited to: Enablement of radio module firmware upgrade via FOTA Enablement of host device firmware upgrade via FOTA managed by the radio module. Enablement of remote configuration of the radio module Enablement of IoT host device management configuration & command/control managed by the radio module Enablement of enhanced security features Enablement of diagnostics data capture and visualization It is strongly recommended that radio modules entering the AT&T Network Ready Lab support FOTA methods for both the radio module as well as for the host device Device Management Client Protocols OMA-DM or LwM2M Device Management (DM) can be implemented with either of two Open Mobile Alliance (OMA) standards. The two standards are OMA-DM or LwM2M (Lightweight Machine to Machine). AT&T IoTS believes that LwM2M is the preferred standard for implementing device management on 11

12 IoTS radio modules and devices. Presently we will allow our radio module partners to choose between an OMA-DM client and LwM2M client for their particular implementations OMA-DM Specifications The official OMA-DM specifications can be downloaded from the OMA-DM download center at the following link: LwM2M Specifications The official LwM2M specifications can be downloaded from the LwM2M download center at the following link: AT&T Subscriber Product Engineering Device Requirements This implementation guide is written in alignment with Subscriber Product Engineering (SPE) Device Requirements OEM Specific DM Implementations Some radio module OEMs provide customized or proprietary FOTA or DM solutions to their customers. The requirements in this guide do not prohibit these implementations however all radio modules must comply with the ODIS/DHIR/Portfolio requirements utilizing OMA-DM or LwM2M as outlined in this guide. Additional DM accounts may be used to implement OEM specific solutions ODIS/DHIR/Portfolio Requirements for IOT Modules As radio modules are certified for use on the AT&T network and integrated into various IoT host devices the TAC range (first 8 digits of the 15 digit IMEI) of the module is often leveraged by the integrator of the host device. The current PTCRB requirement is that not more than 10,000 units of the host device can use the IMEI TAC range of the embedded radio module however it has frequently been seen that those rules are not always followed. Whenever a host device leverages the IMEI TAC of the module, AT&T has no traceability to the type of host device that the module is installed in and the number of those devices which are present on the network. This lack of traceability is problematic for several reasons including when field issues are discovered with a device and we are unable to pin point what devices or their software versions are causing such problems. To overcome this we have introduced a requirement for all new modules and host devices certified on the AT&T network to support a service which reports information to an AT&T database allowing us to identify each discrete device in our network which leverages the IMEI TAC range of the module. This service originally utilized the OMA Device Management (OMA- DM) standard and is known as OMA-DM IMEI Sync (ODIS). This same service is also part of the GSMA Connection Efficiency Guidelines published in 2015 known as Device Host Identity Reporting (DHIR). AT&T has created new custom OMA-DM nodes and LWM2M Objects to collect 12

13 the information from the host device into which the module is integrated. These requirements were introduced in version 5.4 of which was released in November of AT&T will also support the ODIS implementation using Lightweight M2M (LwM2M). This standard is also an OMA developed standard and was introduced to provide a solution for resource constrained devices generally deployed in the Internet of Things domain General ODIS/DHIR/Portfolio Requirements for the Module The module shall be the location within the IoT Host Device where ODIS/DHIR/Portfolio and other module specific details (Ex: DM DevDetail, DevInfo parameters) are maintained no matter whether those parameters are module based parameters or IoT device host parameters (Ex: ODIS/DHIR/Portfolio). The module shall allow programming of the OMA DM based Host Device custom ODIS/DHIR nodes or LWM2M objects through an interface as defined in section 3.5. The module shall maintain the ODIS/DHIR/Portfolio fields programmed from the IoT Host device on a persistent basis. The IoT host device shall not be expected to send ODIS/DHIR/Portfolio information to the module on each power up cycle. The host device has the responsibility to make sure that the radio module DM client is kept up to date with the correct information about the IoT host device. The host device will send updated information to the radio module for the following events: IoT host device should update ODIS/DHIR/Portfolio fields in module at the first power up after being manufactured/assembled together. IoT host device should update ODIS/DHIR/Portfolio fields in module if the IoT host device firmware is updated via any method (Ex: via FOTA, locally via USB, etc.) IoT host device updates ODIS/DHIR/Portfolio fields in module DM client after IoT host device detects a system reset to factory defaults. (ex. if these values are not persistent in module through a factory reset procedure) As a result the following events should trigger the communication of an alert by the module to the device management platform. Factory / Hard Reset Module FW upgrade (first power up after upgrade) Host Device FW upgrade (first power up after upgrade) Change in any Host information (Manufacturer, model, SW Version, Unique ID) Default ODIS/DHIR/Portfolio settings in DM client When implementing an OMA-DM or LwM2M client in the module the following defaults must be set. ODIS/DHIR/Portfolio must be configured and enabled in the module for any distribution channel of the module ODIS/DHIR/Portfolio should be enabled for any carrier SIM/UICC 13

14 The AT&T Device Management production server address must be configured as a default Any factory reset should default to the above settings Default ODIS/DHIR/Portfolio Values for IoT Modules The following values shall be used in the ODIS/DHIR/Portfolio nodes defined by radio modules for the purpose of certification testing. These values shall be the default values stored in production radio modules in the event that the Host Device has not properly overwritten these fields with host device values. These shall be the default values rewritten to the module fields in the event of a module reset to all factory defaults. Instance 1 for LWM2M Object and Portfolio is not a production requirement. Values for OMA-DM or LWM2M Instance (0) Host Device Manufacturer= HMAN0 Host Device Model= HMOD0 Host Device Software Version= HSW0 Host Device Unique ID = HUID0 Values for LWM2M Instance (1) Host Device Manufacturer= HMAN1 Host Device Model= HMOD1 Host Device Software Version= HSW1 Host Device Unique ID = HUID Firmware Update Over the Air (FOTA) FOTA support is optional for modules. Implementations may utilize either an OMA-DM or LWM2M client. Support for and the implementation of the methodology for interfacing with the host device for FOTA support of the host device firmware is module supplier specific. It is strongly recommended that the module support FOTA for the radio layer as well as the host device firmware Memory Allocation in the Module For IoT modules that support FOTA, OEMs should make sure that enough memory is included in the design of modules that support firmware updating. There must be enough onboard memory to facilitate the updating of the module itself. Module OEMs should also consider how the client within the module can manage updating of the host device as it relates to memory allocation. It is highly desired that the repository for a pending host device firmware update be stored within the module in a temporary memory but allowance for methods which would require the host device to allocate external memory are also acceptable. Module OEMs will be expected to indicate which method they intend to support for host device firmware updates. 14

15 3.5. Host Device to Radio Module Interface When implementing a device management client into the radio module, the module OEM must document and provide an API for the IoT host device OEM to be able to populate the information into the device management client nodes inside the radio module. It is at the radio module OEM s discretion to determine how to make the fields available to the host device to populate. (ex. AT Commands, etc.) This interface must be a secure interface which cannot be subject to reverse engineering or monitoring such that the content identifying the host device to AT&T cannot be compromised and potentially utilized to create cloned host devices utilizing a similar IMEI TAC range. See AT&T requirement <CDR-DVM-1600> Local Access to Host Device Details for an embedded IOT Module. 15

16 4. Requirements for IOT Modules supporting OMA DM 4.1. General OMA DM Requirements An IOT module supporting OMA DM for AT&T should at minimum support the following capabilities Dedicated APN for OMA DM IOT modules shall use the attm2mglobal APN for all Device Management functions (i.e., FOTA, OMA-DM, LWM2M) DM Account Provisioning for IoT Modules Supporting OMA DM A radio module will have two factory bootstrap DM Accounts. These will be AT&T default factory DM accounts as defined for IoT modules and devices in AT&T chapter 22 <CDR-DVM-392> Device Management Accounts. In addition there will be a third account that shall be left empty at the factory but restricted such that this account can only be programmed in the future by using the NETWPIN method for authentication. Additional DM Accounts may be provisioned based on OEM requirements. Account Usage 1 AT&T Default for IoT modules and devices per Chapter 22 of AT&T Default for IoT modules and devices per Chapter 22 of Blank for OTA bootstrap using NETWPIN method 4+ OEM discretion DM Account Parameters for IOT Modules Supporting OMA DM When a module is utilizing OMA DM the two factory bootstrapped DM Accounts will be configured as described in the requirements from AT&T specification which are duplicated in this section <CDR-DVM-3954> First DM Account Parameters for a Module Summary: The first DM Account for DM 1.2/1.3 will be factory bootstrapped to the production server per the following table. The use of MD5 or HMAC authentication is mandatory. DM Account URI./DMS/Cingular/AppID./DMS/Cingular/ServerID Values w7 Cingular 16

17 ./DMS/Cingular/Name./DMS/Cingular/AppAddr/mdm/Addr /DMS/Cingular/AppAddr/mdm/Port/mdm/Port Nbr./DMS/Cingular/AppAuth/client/AAuthLevel./DMS/Cingular/AppAuth/client/AAuthType Cingular (for secure connection) Secure connection shall use port 443 CLCRED MD5 or HMAC./DMS/Cingular/AppAuth/client/AAuthName Generated using utility in QC defect #25188./DMS/Cingular/AppAuth/client/AAuthSecret Generated using utility in QC defect #25188./DMS/Cingular/AppAuth/client/AAuthData./DMS/Cingular/AppAuth/server/AAuthLevel./DMS/Cingular/AppAuth/server/AAuthType./DMS/Cingular/AppAuth/server/AAuthName bnvsba== (Base 64 encoded value of string null) SVRCRED MD5 or HMAC Cingular <CDR-DVM-3955> Second DM Account Parameters for a Module Summary: The second DM Account for DM 1.2/1.3 will be factory bootstrapped to the lab server per the following table. The use of MD5 or HMAC authentication is mandatory. DM Account URI./DMS/Cingular/AppID./DMS/Cingular/ServerID./DMS/Cingular/Name./DMS/Cingular/AppAddr/mdm/Addr /DMS/Cingular/AppAddr/mdm/Port/mdm/Port Nbr./DMS/Cingular/AppAuth/client/AAuthLevel./DMS/Cingular/AppAuth/client/AAuthType Values w7 ATTLabA ATTLabA (for secure connection) Secure connection shall use port 443 CLCRED MD5 or HMAC./DMS/Cingular/AppAuth/client/AAuthName Generated using utility in QC defect #

18 ./DMS/Cingular/AppAuth/client/AAuthSecret Generated using utility in QC defect #25188./DMS/Cingular/AppAuth/client/AAuthData./DMS/Cingular/AppAuth/server/AAuthLevel./DMS/Cingular/AppAuth/server/AAuthType./DMS/Cingular/AppAuth/server/AAuthName bnvsba== (Base 64 encoded value of string null) SVRCRED MD5 or HMAC ATTLabA 4.3. Identity and Detail Nodes for IOT Modules Supporting OMA DM Standard nodes, as detailed in the OMA specification shall be supported by the module to gain visibility to the modules detail and other pertinent information. Any standards reference to device for nodes or objects in reference by this section shall be assumed to refer to the IOT Module itself. Sections and detail the device detail nodes required Embedded IOT Module SVN (IMEI SV) In addition to supporting the DevInfo Device Management Object and the DevDetail Device Management Object as specified in the OMA Device Management Standardized Objects document, the following OMA-DM node has been defined to enable tracking and verification of the SVN (Software Version Number) of the embedded IOT module. The 2 digit SVN is the last 2 digits of the 16 digit IMEI SV Type: IMEI SV Occurrence: One Format: Numeric String (2 digit SVN) Name: DevDetail/Ext/IMEISV Access Type: GET The IMEI is reported in DevInfo/DevId with the SVN to be stored in the IMEI SV node ODIS/DHIR Support by an IOT Module Utilizing OMA-DM Four new custom nodes have been specified to support ODIS/DHIR utilizing the OMA-DM API. Support for these four new custom nodes is mandatory. The following requirement describes the definition of the custom nodes. Access Type: GET <CDR-DVM-4532> Support for Module Host Device Reporting in the Device Detail Management Object 18

19 Summary: For modules embedded in a host device, the host device details shall be supported in an extension node within the Device Detail Management Object. Host Device Manufacturer The following OMA-DM node has been defined to specify information related to the manufacturer of the IoT host device, this field must match the Host Device manufacturer name that is referenced in the AT&T Network Ready Lab certification. Type: Host Device Manufacturer Occurrence: One Format: String Name: DevDetail/Ext/HostMan Access Type: GET Host Device Manufacturer The manufacturer name as submitted into the AT&T IOTS Onboarding Tool and reported in the AT&T Network Ready Lab Notice of Network Compatibility (TA Letter) for the Host Device. Host Device Model The following OMA-DM node has been defined to specify the Model name/number of the host device. This must match the model name/number used in the certification of the device. Type: Host Device Model Occurrence: One Format: String Name: DevDetail/Ext/HostMod Access Type: GET Host Device Model The model identifier as submitted into the AT&T IOTS Onboarding Tool and reported in the AT&T Network Ready Lab Notice of Network Compatibility (TA Letter) for the Host Device. Host Device Software Version The following OMA-DM node has been defined to specify the software version of the host device, this information must be populated by the host device manufacturer, must match the version of SW certified by PTCRB and must be updated whenever the SW is updated on the device. Type: Host Device Software Version Occurrence: One Format: String Name: DevDetail/Ext/HostSwV Access Type: GET Host Device Software Version The version value as submitted into the AT&T IOTS Onboarding Tool and reported in the AT&T Network Ready Lab Notice of Network Compatibility (TA Letter) for the Host Device. 19

20 Host Device Unique ID The following OMA-DM node has been defined to specify the Host Device Unique ID which is equivalent to the AT&T Onboarding Device ID allocated to the host device. The Host Device Unique ID is the ID that is assigned to a device when it is entered into the AT&T onboarding tool through the AT&T Developer portal. Type: Host Device Unique ID Occurrence: One Format: Alphanumeric String Name: DevDetail/Ext/HostUniqueID Access Type: GET Host Device Unique ID The unique ID assigned by AT&T as the Device ID in the AT&T IOTS Onboarding Tool and reported in the AT&T Network Ready Lab Notice of Network Compatibility (TA Letter) for the Host Device Firmware Update Over the Air (FOTA) The following specifications apply to IoT modules that will support FOTA OMA-DM Firmware Update Management Object (FUMO) Support OMA-DM clients will use FUMO as the mechanism to perform updates to the module and host device Proprietary Update A proprietary solution for updating the module or device firmware (either OTA or locally by USB) may also be implemented as long as the following requirement is met. <CDR-DVM-1533> Device Initiated Session following a non- FOTA Update Summary: Devices which are updated using one of the following scenarios shall automatically initiate a session with the AT&T Device Management platform to report new device details from the Device Detail Management Object following the update. This is needed to keep AT&T back-end systems in sync with the new device details. Device update by sideload/usb, WiFi, Bluetooth, etc. Device update using a proprietary OEM Device Management server Note, as well as the standard OMA-DM nodes defined in it is also required for modules to report the contents of the following custom nodes to the server: - Host Device Manufacturer - Host Device Model - Host Device Software Version 20

21 - Host Device Plasma ID AT&T Internet of Things Solutions Organization Memory Allocation in the Module Module OEMs should make sure that enough memory is included in the design of modules that support firmware updating. There needs to be enough onboard memory to facilitate the updating of the modules itself. Module OEMs should also consider how the client within the module can manage updating of the host device as it relates to memory allocation. It is highly desired that the repository for a pending host device firmware update be stored within the module in a temporary memory but allowance for methods which would require the host device to allocate external memory are also acceptable. Module OEMs will be expected to indicate which method they intend to support for host firmware updates. 5. Requirements for IOT Modules supporting LWM2M 5.1. General LWM2M Requirements An IOT module supporting LWM2M for AT&T should at minimum support the following capabilities Dedicated APN for LWM2M IOT modules shall use the attm2mglobal APN for all Device Management functions (i.e., FOTA, OMA-DM, LWM2M). For LWM2M specifically, this APN should be accessible simultaneously with any other context open UQS (UDP with Queue Mode and SMS) Transport and Binding Mode Support IOT modules must support the UQS (UDP with Queue Mode and SMS) transport binding mode as defined in the LWM2M specification section This mode is supported in the case that the device is in a sleep cycle and needs to react to a command from the server. Registration Update Trigger can be sent via SMS to the device to wake it up. This is one use case and should the user want to use CoAP over SMS they should be able to leverage UQS mode to do so. A full CoAP over SMS stack is not required, instead only a method for Registration Update Trigger. UDP (U mode) binding is preferred over SMS whenever possible. Appendix C contains a high level example flow for the CoAP over SMS Registration Update Trigger LWM2M Operations IoT modules shall support the operations in the LWM2M specification in regard to Client Registration Interface, Device Management and Service Enablement Interface, and Information 21

22 Reporting Interface. These operations are detailed in Sections 5.3, 5.4, and 5.5 of the OMA LWM2M Technical Specification. Observe and Notify will be used to monitor changes on object resources that are observable. This means that the LWM2M server will send an Observe command to a resource, and the client should use the Notify operation to update the LWM2M server with the new value of the resource as described in section 5.5 Information Reporting Interface of the OMA LWM2M Technical Specification. A Notify operation should be initiated by the client when all conditions of the Observe operation are met as described in Section of the OMA LWM2M Technical Specification Data Formats The IoT module shall support TLV data format as detailed in section 6.4 in the OMA LWM2M Technical Specification. Data formats beyond TLV will be implementation specific decided upon by the OEM Bootstrap Server Account Provisioning for IoT Modules Supporting LWM2M The Bootstrap Server for provisioning LWM2M servers and settings will be owned by ATT. This will be a single Bootstrap Server solution for all LWM2M capable modules giving the most flexibility to an end customer. The device will not be required to maintain both production and lab objects at a given time. The device will be certified against the lab objects and settings and then for production devices will be factory bootstrapped with the production objects Bootstrap Prioritization Sequence for IOT Modules Supporting LWM2M When a module is utilizing LWM2M, one bootstrapped LWM2M client will be configured as described in the requirements from AT&T specification which are duplicated in this section. Bootstrapping will be prioritized in the order of Factory Bootstrap, Server Initiated Bootstrap, and finally Client Initiated Bootstrap. A module shall be factory bootstrapped. In the case of corruption or failed registration the client shall have a Client Hold Off time of 8 hours. The Server Initiated Bootstrap should happen within this Client Hold Off time which follows the priority order of Factory Bootstrap, Server Initiated Bootstrap, then Client Initiated Bootstrap. Client Initiated Bootstrap should only happen in the case of Client Hold Off time being met before the server initiates bootstrapping. If the Client Initiated Bootstrap fails after the 8 hour Client Hold Off time the module must wait one more full Client Hold Off period before attempting again. In the case of another failure the module must not attempt again. Two Client Initiated Bootstrap attempts is the maximum. 22

23 <CDR-DVM-032> Support for OMA LWM2M Bootstrap Profile as specified in the OMA LWM2M specification Summary: The IOT module with a LWM2M client shall support the bootstrap process for the OMA Server Initiated Bootstrap mode as specified in Section and of the OMA LWM2M technical specification. Note that support of factory bootstrap is also required. The module with LWM2M client, upon downloading and installing a new bootstrap which has the same server ID as the factory bootstrap, shall use the new bootstrap for communication with the AT&T DM server. A factory reset shall wipe any downloaded bootstrap account on the IOT module. The IOT module will always use a factory bootstrap account to communicate with the AT&T DM server unless a new bootstrap was downloaded and installed on the IOT module, at which time the new bootstrap would be used for communication with the AT&T DM server <CDR-DVM-033> Support for OMA LWM2M Write of Bootstrap Profile Summary: The IOT module shall support a temporary write of the OMA LWM2M OTA bootstrap included in the TLV or JSON formatted payload sent by the LWM2M server, and as defined in Section of the OMA TS Lightweight M2M specification Production Bootstrap Server Security Object The Bootstrap Server account on a module supporting the LWM2M client will provision the LWM2M Server objects into the device given that the device cannot register to previous LWM2M servers provisioned or new LWM2M servers need to be added to the device. This account will reside in Instance 0. Following are the values to be provisioned in the account. Object Definition Name Object ID Instances Mandatory Object URN LWM2M Security Object 0 Multiple Mandatory urn:oma:lwm2m:oma:0 Resource Definitions ID Name Value 0 LWM2M Server URI coaps://lwprod.iot.attcompute.com: Bootstrap Server TRUE 2 Security Mode 0: Pre-Shared Key mode 3 Public Key/Identity Key Generation Tool to be provided 23

24 4 Server Public Key/Identity Password generated using utility in QC defect # Secret Key Key Generation Tool to be provided 6 SMS Security Mode 1: Secure Packet Structure Mode 7 SMS Binding Key Parameters Optional include KIc 8 SMS Binding Secret Keys Optional include KIc key 9 LWM2M Server SMS Number 10 Short Server ID Server ID for the AT&T lab LWM2M server will be an ID value in the range and will be sent by the AT&T production LWM2M server in the initial session. 11 Client Hold Off Time seconds (8 hours) LWM2M client must store this Server ID for future sessions with the server Lab Bootstrap Server Security Object The Bootstrap Server account on a module supporting the LWM2M client will provision the LWM2M Server objects into the device given that the device cannot register to previous LWM2M servers provisioned or new LWM2M servers need to be added to the device. This account will reside in Instance 0. Following are the values to be provisioned in the account. Object Definition Name Object ID Instances Mandatory Object URN LWM2M Security Object 0 Multiple Mandatory urn:oma:lwm2m:oma:0 Resource Definitions ID Name Value 0 LWM2M Server URI To be provided by Nokia 1 Bootstrap Server TRUE 2 Security Mode 0: Pre-Shared Key mode 3 Public Key/Identity Key Generation Tool to be provided 4 Server Public Key/Identity 5 Secret Key Key Generation Tool to be provided 6 SMS Security Mode 1: Secure Packet Structure Mode 24

25 7 SMS Binding Key Parameters Optional include KIc 8 SMS Binding Secret Keys Optional include KIc key 9 LWM2M Server SMS Number 10 Short Server ID Server ID for the AT&T lab LWM2M server will be an ID value in the range and will be sent by the AT&T production LWM2M server in the initial session. 11 Client Hold Off Time seconds (8 hours) LWM2M client must store this Server ID for future sessions with the server Production Server Security Object Parameters for an IOT Module supporting LWM2M Summary: The first account on a module supporting the LWM2M client will be factory bootstrapped to the production server per the following table. The use of DTLS authentication is mandatory. This account will be used to register with the AT&T LWM2M production server. This account will reside in Instance 1. This account will be supported in the LWM2M Security Object with defined resources and provisioned on the module. Following are the values to be provisioned in the account. Object Definition Name Object ID Instances Mandatory Object URN LWM2M Security Object 0 Multiple Mandatory urn:oma:lwm2m:oma:0 Resource Definitions ID Name Value 0 LWM2M Server URI coaps://lwprod.iot.attcompute.com:5684 (secure UDP) 1 Bootstrap Server FALSE 2 Security Mode 0: Pre-Shared Key mode 3 Public Key/Identity Key Generation Tool to be provided 4 Server Public Key/Identity Key Generation Tool to be provided 5 Secret Key Key Generation Tool to be provided 6 SMS Security Mode 1: Secure Packet Structure Mode 7 SMS Binding Key Parameters Optional include KIc 25

26 8 SMS Binding Secret Keys Optional include KIc key 9 LWM2M Server SMS Number 10 Short Server ID Server ID for the AT&T lab LWM2M server will be an ID value in the range and will be sent by the AT&T production LWM2M server in the initial session. 11 Client Hold Off Time seconds (8 hours) LWM2M client must store this Server ID for future sessions with the server Lab Server Security Object Parameters for an IOT Module supporting LWM2M Summary: The second account on a module supporting the LWM2M client will be factory bootstrapped to the lab server per the following table. The use of DTLS authentication is mandatory. This account will be used to register with the AT&T LWM2M lab server. This account will reside in Instance 1. This account will be supported in the LWM2M Security Object with defined resources and provisioned on the module. Following are the values to be provisioned in the account. Object Definition Name Object ID Instances Mandatory Object URN LWM2M Security Object 0 Multiple Mandatory urn:oma:lwm2m:oma:0 Resource Definitions ID Name Value 0 LWM2M Server URI coaps://lwdev.iot.attcompute.com:5684 (secure UDP) 1 Bootstrap Server FALSE 2 Security Mode 0: Pre-Shared Key mode 3 Public Key/Identity Key Generation Tool to be provided 4 Server Public Key/Identity Key Generation Tool to be provided 5 Secret Key Key Generation Tool to be provided 6 SMS Security Mode 1: Secure Packet Structure Mode 7 SMS Binding Key Parameters Optional include KIc 26

27 8 SMS Binding Secret Keys Optional include KIc key 9 LWM2M Server SMS Number 10 Short Server ID Server ID for the AT&T lab LWM2M server will be an ID value in the range and will be sent by the AT&T lab LWM2M server in the initial session. 11 Client Hold Off Time seconds LWM2M client must store this Server ID for future sessions with the server Production Server Object Parameters for an IOT Module supporting LWM2M The Server Object as detailed below describes the production server at the address given in the first Security Object. The Short Server ID here should correspond to the short server ID in the first Security Object. This account will reside in instance 0. Object Definition Name Object ID Instances Mandatory Object URN LWM2M Server Object 1 Multiple Mandatory urn:oma:lwm2m:oma:1 Resource Definitions ID Name Operations Instances Mandatory Type Range or Units Description Enumeration 0 Short Server ID R Single Mandatory Integer This should be the same in resource 10 in the Production Server Security Object (0/1/10). 1 Lifetime RW Single Mandatory (AT&T) Integer s (1 day) 2 Default RW Single Optional Integer s The default value the Minimum Period LwM2M Client should use for the Minimum Period of an Observation in the absence of this parameter being included in an Observation. 3 Default Maximum Period If this Resource doesn t exist, the default value is 0. RW Single Optional Integer s The default value the LwM2M Client should use for the Maximum Period of an Observation in the absence of this parameter being included in an Observation. If this Resource is executed, this LwM2M Server Object is 4 Disable E Single Mandatory (AT&T) 27

28 5 Disable Timeout 6 Notification Storing When Disabled or Offline RW Single Mandatory (AT&T) RW Single Mandatory (AT&T) disabled for a certain period defined in the Disabled Timeout Resource. After receiving Execute operation, LwM2M Client MUST send response of the operation and perform deregistration process, and underlying network connection between the Client and Server MUST be disconnected to disable the LwM2M Server account. After the above process, the LwM2M Client MUST NOT send any message to the Server and ignore all the messages from the LwM2M Server for the period. Integer s Boolean If true, the LwM2M Client stores Notify operations to the LwM2M Server while the LwM2M Server account is disabled or the LwM2M Client is offline. After the LwM2M Server account is enabled or the LwM2M Client is online, the LwM2M Client reports the stored Notify operations to the Server. If false, the LwM2M Client discards all the Notify operations or temporarily disables the Observe function while the LwM2M Server is disabled or the LwM2M Client is offline. The default value is true. 7 Binding RW Single Mandatory String The possible values of Resource are listed in Registration Update Trigger The maximum number of storing Notifications per Server is up to the implementation. UQS E Single Mandatory If this Resource is executed the LwM2M Client MUST perform an Update operation with this LwM2M Server using that transport for the Current Binding Mode. 28

29 Lab Server Object Parameters for an IOT Module supporting LWM2M The Server Object as detailed below describes the Lab server at the address given in the first Security Object. The Short Server ID here should correspond to the short server ID in the first Security Object. This account will reside in instance 0. Object Definition Name Object ID Instances Mandatory Object URN LWM2M Server Object 1 Multiple Mandatory urn:oma:lwm2m:oma:1 Resource Definitions ID Name Operations Instances Mandatory Type Range or Enumeration Units Description 0 Short Server ID R Single Mandatory Integer This should be the same as resource 10 in the Lab Server Security Object (0/1/10). 1 Lifetime RW Single Mandatory Integer s 900 (15 min.) 2 Default Minimum RW Single Optional Integer s The default value Period the LwM2M Client should use for the Minimum Period of an Observation in the absence of this parameter being included in an Observation. 3 Default Maximum Period If this Resource doesn t exist, the default value is 0. RW Single Optional Integer s The default value the LwM2M Client should use for the Maximum Period of an Observation in the absence of this parameter being included in 4 Disable E Single Mandatory (AT&T) 29 an Observation. If this Resource is executed, this LwM2M Server Object is disabled for a certain

30 period defined in the Disabled Timeout Resource. After receiving Execute operation, LwM2M Client MUST send response of the operation and perform deregistration process, and underlying network connection between the Client and Server MUST be disconnected to disable the LwM2M Server account. 5 Disable Timeout RW Single Mandatory (AT&T) 6 Notification Storing RW Single Mandatory When Disabled or (AT&T) Offline After the above process, the LwM2M Client MUST NOT send any message to the Server and ignore all the messages from the LwM2M Server for the period. Integer s Boolean If true, the LwM2M Client stores Notify operations to the LwM2M Server while the LwM2M Server account is disabled or the LwM2M Client is offline. After the LwM2M Server account is enabled or the LwM2M Client is online, the LwM2M Client reports the stored Notify operations to the Server. If false, the 30

31 7 Binding RW Single Mandatory String The possible values of Resource are listed in Registration Update Trigger LwM2M Client discards all the Notify operations or temporarily disables the Observe function while the LwM2M Server is disabled or the LwM2M Client is offline. The default value is true. The maximum number of storing Notifications per Server is up to the implementation. UQS E Single Mandatory If this Resource is executed the LwM2M Client MUST perform an Update operation with this LwM2M Server using that transport for the Current Binding Mode Device Details Object for IoT Modules Supporting LWM2M AT&T requires that radio modules support the following standard identity parameters according to the LWM2M specifications. This section aligns with AT&T specification requirements <CDR-DVM-4544> Support for OMA LWM2M Device Object and <CDR-DVM- 4545> Support for OMA LWM2M Device Object Resources. Any standards reference to device for nodes or objects in reference by this section shall be assumed to refer to the IOT Module Object Definition Name Object ID Instances Mandatory Object URN Device (IOT 3 Single Mandatory urn:oma:lwm2m:oma:3 Module) 31

32 Resource definitions ID Name Operation Instance Mandator Type Range or Enumeration Unit Description 0 Manufacturer R Single Mandatory String IOT Module Manufacturer Name as submitted into the AT&T IOTS Onboarding Tool and reported in the AT&T Network Ready Lab Notice of Network Compatibility 17 (TA Letter). Device Type R Single Mandatory String IOT Module type as submitted into the AT&T IOTS Onboarding Tool and reported in the AT&T Network Ready Lab Notice of Network Compatibility (TA Letter). (Example: Module BGA, Module Half Mini PCIe, Module - LCC, Module LGA, Module M.2, Module - PCIe, Module Proprietary) 1 Model Number 2 Serial Number 18 Hardware Version 3 Firmware Version 19 Software Version R Single Mandatory String IOT Module Model Identifier as submitted into the AT&T IOTS Onboarding Tool and reported in the AT&T Network Ready Lab Notice of Network Compatibility (TA Letter). R Single Mandatory String IOT Module IMEI - 15 digits as defined in the PTCRB PPMD specification. R Single Mandatory String IOT Module Hardware Version as submitted into the AT&T IOTS Onboarding Tool and reported in the AT&T Network Ready Lab Notice of Network Compatibility (TA Letter). R Single Mandatory String Current Firmware Version of the module as submitted into the AT&T IOTS Onboarding Tool and reported in the AT&T Network Ready Lab Notice of Network Compatibility (TA Letter). R Single Mandatory String IOT Module SVN - 2 digits as defined in the PTCRB PPMD specification. 22 ExtDevInfo R Multiple Optional Objln Connects Portfolio k 4 Reboot E Optional Manufacturer specific implementation. 5 Factory E Optional Manufacturer specific Reset implementation. 6 Available R Optional Manufacturer specific Power implementation. Sources 7 Power Source Voltage R Optional Manufacturer specific implementation. 32