Device Management Implementation Guide for IoT …T Internet of Things Solutions Organization Device Management Guide 3 Abstract This document is an implementation guide for technical

AT&T Internet of Things Solutions Organization Device Management Implementation Guide

Device Management Implementation Guide for IoT Solutions Version 3.0

AT&T Internet of Things Solutions Organization Device Management Guide

2

Author(s) Group Phone # E-mail

Steve Hardin IoT Solutions (AT&T) +1 (404) 713-2651 [email protected]

Jordan Alexander IoT Solutions (AT&T) +1 (470) 312-0492 [email protected]

Alpana Hoffman Project Manager (Nokia) [email protected]

John Engquist Technical Point of Contact (Nokia)

[email protected]

Rano Sugandi Pre-Sales PM (Nokia) [email protected]

Elvis Mena OEM Customer Team (Nokia) [email protected]

John Ramey OEM Customer Team (Nokia) [email protected]

mailto:[email protected]



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/2015 1.6 Withdrew v.16 of ODIS Implementation Guide

7/9/2015 2.0 Initial release of public version of Device Management Implementation guide

8/3/2015 2.1 Added CDR-DVM details for IoT bootstrap accounts.

4/26/2016 2.2 Section 1.5: Added email address for delivery of .csv files. Added requirement for legacy devices manufactured in 2015 & 2016.

6/6/2016 2.3 Section 1.5: Added table showing sample data. Re-added host unique ID into the data set request.

7/29/2016 2.4 Added sections 3.4 and 3.5

5/22/2017 3.0 New format

8/22/2017 3.1 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.


4

Table of Contents 1. Introduction ......................................................................................................................... 7

1.1. Architecture ...................................................................................................................... 7

1.2. System Components ........................................................................................................ 7

2. Support Requirements for IoT Host Devices ..................................................................... 10

2.1. IoT Host Device Requirements ....................................................................................... 10

3. General Support Requirements for Modules .................................................................... 11

3.1. Embedded Wireless Radio Module Requirements ........................................................ 11

3.2. Device Management Client Protocols – OMA-DM or LwM2M ...................................... 11

3.2.1. OMA-DM Specifications ............................................................................................. 12

3.2.2. LwM2M Specifications ................................................................................................ 12

3.2.3. AT&T Subscriber Product Engineering Device Requirements .................................... 12

3.2.4. OEM Specific DM Implementations ........................................................................... 12

3.3. ODIS/DHIR/Portfolio Requirements for IOT Modules ................................................... 12

3.3.1. General ODIS/DHIR/Portfolio Requirements for the Module .................................... 13

3.3.2. Default ODIS/DHIR/Portfolio settings in DM client .................................................... 13

3.3.3. Default ODIS/DHIR/Portfolio Values for IoT Modules ................................................ 14

3.4. Firmware Update Over the Air (FOTA) ........................................................................... 14

3.4.1. Memory Allocation in the Module ............................................................................. 14

3.5. Host Device to Radio Module Interface ......................................................................... 15

4. Requirements for IOT Modules supporting OMA DM ....................................................... 16

4.1. General OMA DM Requirements ................................................................................... 16

4.1.1. Dedicated APN for OMA DM ...................................................................................... 16

4.2. DM Account Provisioning for IoT Modules Supporting OMA DM ................................. 16

4.2.1. DM Account Parameters for IOT Modules Supporting OMA DM .............................. 16

4.2.1.1. <CDR-DVM-3954> First DM Account Parameters for a Module ......................... 16

4.2.1.2. <CDR-DVM-3955> Second DM Account Parameters for a Module .................... 17

4.3. Identity and Detail Nodes for IOT Modules Supporting OMA DM ................................ 18

4.3.1. Embedded IOT Module SVN (IMEI SV) ....................................................................... 18

4.3.2. ODIS/DHIR Support by an IOT Module Utilizing OMA-DM ........................................ 18

4.4. Firmware Update Over the Air (FOTA) ........................................................................... 20

4.4.1. OMA-DM Firmware Update Management Object (FUMO) Support ...................... 20


5

4.4.2. Proprietary Update ................................................................................................. 20

4.4.3. Memory Allocation in the Module .......................................................................... 21

5. Requirements for IOT Modules supporting LWM2M ........................................................ 21

5.1. General LWM2M Requirements .................................................................................... 21

5.1.1. Dedicated APN for LWM2M ....................................................................................... 21

5.1.2. UQS (UDP with Queue Mode and SMS) Transport and Binding Mode Support ........ 21

5.1.3. LWM2M Operations ................................................................................................... 21

5.1.4. Data Formats .............................................................................................................. 22

5.2. Bootstrap Server Account Provisioning for IoT Modules Supporting LWM2M ............. 22

5.2.1. Bootstrap Prioritization Sequence for IOT Modules Supporting LWM2M ................ 22

5.2.1.1. <CDR-DVM-032> Support for OMA LWM2M Bootstrap Profile as specified in the OMA LWM2M specification .................................................................................................. 23

5.2.1.2. <CDR-DVM-033> Support for OMA LWM2M Write of Bootstrap Profile ........... 23

5.2.1.3. Production Bootstrap Server Security Object ..................................................... 23

5.2.1.4. Lab Bootstrap Server Security Object ................................................................. 24

5.2.1.5. Production Server Security Object Parameters for an IOT Module supporting LWM2M 25

5.2.1.6. Lab Server Security Object Parameters for an IOT Module supporting LWM2M 26

5.2.1.7. Production Server Object Parameters for an IOT Module supporting LWM2M 27

5.2.1.8. Lab Server Object Parameters for an IOT Module supporting LWM2M ............ 29

5.3. Device Details Object for IoT Modules Supporting LWM2M ......................................... 31

5.4. ODIS/DHIR/Portfolio Support by an IOT Module Utilizing LwM2M .............................. 33

5.4.1. LWM2M Object: Portfolio .......................................................................................... 33

5.5. LWM2M Server Object ................................................................................................... 35

5.6. Short Server ID ............................................................................................................... 35

5.6.2. Disable ..................................................................................................................... 35

5.6.5. Binding .................................................................................................................... 36

5.6.6. Registration Update Trigger .................................................................................... 36

5.6.7. Registration Update Trigger with SMS ....................................................................... 36

5.7. Access Control Object .................................................................................................... 36

5.7.1. Object ID ..................................................................................................................... 37

5.7.2. Object Instance ID ...................................................................................................... 37


6

5.7.3. Access Control Owner ................................................................................................ 37

5.8. LWM2M FOTA ................................................................................................................ 37

5.8.1. LWM2M Object: Firmware Update ............................................................................ 37

6. Device Management Testing for IOT Modules .................................................................. 38

6.1. Nokia XDM Server Interoperability Testing ................................................................... 38

6.2. AT&T Technical Acceptance Testing .............................................................................. 38

Appendix A - Minimum Requirements to Implement ODIS/DHIR/Portfolio for IoT Host Devices using an Approved Module (AM) .................................................................................................. 39

Host Device Test Scope ............................................................................................................. 40

Appendix B - Custom Object ID for ODIS/DHIR Parameters utilizing LWM2M ............................ 41

LwM2M Object: HostDeviceInfo ............................................................................................... 41

Appendix C – CoAP over SMS Registration Update Trigger .......................................................... 43


7

1. Introduction

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.

1.1. Architecture

To better facilitate an understanding of the Device Management Implementation required by AT&T a diagram is provided below.

1.2. 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.


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 10241 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 2015.

• 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


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 13340 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.


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.


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.

3.1. 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.

3.2. 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


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.

3.2.1. OMA-DM Specifications

The official OMA-DM specifications can be downloaded from the OMA-DM download center at the following link: http://www.openmobilealliance.org/release/DM/V2_0-20160209-A/

3.2.2. LwM2M Specifications

The official LwM2M specifications can be downloaded from the LwM2M download center at the following link: http://www.openmobilealliance.org/release/LightweightM2M/

3.2.3. AT&T Subscriber Product Engineering Device Requirements This implementation guide is written in alignment with Subscriber Product Engineering (SPE) Device Requirements 1334.

3.2.4. 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.

3.3. 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

http://www.openmobilealliance.org/release/DM/V2_0-20160209-A/

http://www.openmobilealliance.org/release/LightweightM2M/


13

the information from the host device into which the module is integrated. These requirements were introduced in version 5.4 of 13340 which was released in November of 2013. 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.

3.3.1. 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)

3.3.2. 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


14

• The AT&T Device Management production server address must be configured as a default

• Any factory reset should default to the above settings.

3.3.3. 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 10241 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 = HUID1

3.4. 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.

3.4.1. 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.


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 13340 requirement <CDR-DVM-1600> Local Access to Host Device Details for an embedded IOT Module.


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.

4.1.1. Dedicated APN for OMA DM

IOT modules shall use the “attm2mglobal” APN for all Device Management functions (i.e., FOTA, OMA-DM, LWM2M).

4.2. 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 13340 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 13340

2 AT&T Default for IoT modules and devices per Chapter 22 of 13340

3 Blank for OTA bootstrap using NETWPIN method

4+ OEM discretion

4.2.1. 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 13340 which are duplicated in this section.

4.2.1.1. <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 Values

./DMS/Cingular/AppID w7

./DMS/Cingular/ServerID Cingular


17

./DMS/Cingular/Name Cingular

./DMS/Cingular/AppAddr/mdm/Addr https://iotprod.sl.attcompute.com/oma (for

secure connection)

/DMS/Cingular/AppAddr/mdm/Port/mdm/Port

Nbr

Secure connection shall use port 443

./DMS/Cingular/AppAuth/client/AAuthLevel CLCRED

./DMS/Cingular/AppAuth/client/AAuthType 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 bnVsbA== (Base 64 encoded value of string

“null)

./DMS/Cingular/AppAuth/server/AAuthLevel SVRCRED

./DMS/Cingular/AppAuth/server/AAuthType MD5 or HMAC

./DMS/Cingular/AppAuth/server/AAuthName Cingular

4.2.1.2. <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 Values

./DMS/Cingular/AppID w7

./DMS/Cingular/ServerID ATTLabA

./DMS/Cingular/Name ATTLabA

./DMS/Cingular/AppAddr/mdm/Addr https://iotdev.sl.attcompute.com/oma (for

secure connection)

/DMS/Cingular/AppAddr/mdm/Port/mdm/Port

Nbr

Secure connection shall use port 443

./DMS/Cingular/AppAuth/client/AAuthLevel CLCRED

./DMS/Cingular/AppAuth/client/AAuthType MD5 or HMAC

./DMS/Cingular/AppAuth/client/AAuthName Generated using utility in QC defect #25188


18

./DMS/Cingular/AppAuth/client/AAuthSecret Generated using utility in QC defect #25188

./DMS/Cingular/AppAuth/client/AAuthData bnVsbA== (Base 64 encoded value of string

“null)

./DMS/Cingular/AppAuth/server/AAuthLevel SVRCRED

./DMS/Cingular/AppAuth/server/AAuthType MD5 or HMAC

./DMS/Cingular/AppAuth/server/AAuthName 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 4.3.1 and 4.3.2 detail the device detail nodes required.

4.3.1. 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.

4.3.2. 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


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.


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.

4.4. Firmware Update Over the Air (FOTA)

The following specifications apply to IoT modules that will support FOTA.

4.4.1. 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.

4.4.2. 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 13340 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


21

- Host Device Plasma ID

4.4.3. 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.

5.1.1. 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.

5.1.2. 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 5.3.1.1. 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.

5.1.3. 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


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 5.1.2 of the OMA LWM2M Technical Specification.

5.1.4. 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.

5.2. 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.

5.2.1. 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 13340 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.


23

5.2.1.1. <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 5.2.2.4 and 5.2.3 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.

5.2.1.2. <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 5.2.5.1 of the OMA TS Lightweight M2M specification.

5.2.1.3. 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:5684

1 Bootstrap Server TRUE

2 Security Mode 0: Pre-Shared Key mode

3 Public Key/Identity Key Generation Tool to be provided


24

4 Server Public Key/Identity Password generated using utility in QC defect #25188

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

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 1-

65535 and will be sent by the AT&T production LWM2M server in the initial

session.

LWM2M client must store this Server ID for future sessions with the server

11 Client Hold Off Time 28880 seconds (8 hours)

5.2.1.4. 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




ID Name Value

0 LWM2M Server URI To be provided by Nokia

1 Bootstrap Server TRUE



4 Server Public Key/Identity




25






session.



5.2.1.5. 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




ID Name Value

0 LWM2M Server URI coaps://lwprod.iot.attcompute.com:5684 (secure UDP)

1 Bootstrap Server FALSE



4 Server Public Key/Identity Key Generation Tool to be provided





26





session.



5.2.1.6. 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




ID Name Value

0 LWM2M Server URI coaps://lwdev.iot.attcompute.com:5684 (secure UDP)

1 Bootstrap Server FALSE



4 Server Public Key/Identity Key Generation Tool to be provided





27




65535 and will be sent by the AT&T lab LWM2M server in the initial session.


11 Client Hold Off Time 28880 seconds

5.2.1.7. 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


LWM2M Server Object 1 Multiple Mandatory urn:oma:lwm2m:oma:1


ID Name Operations Instances Mandatory Type Range or

Enumeration

Units Description

0 Short Server ID R Single Mandatory Integer 1-65535

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 86400 (1 day)

2 Default

Minimum

Period

RW Single Optional Integer

s The default value the

LwM2M Client should use

for the Minimum Period of an

Observation in the absence of

this parameter being included

in an Observation.

If this Resource doesn’t exist,

the default value is 0.

3 Default

Maximum

Period


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.

4 Disable E Single Mandatory

(AT&T)

If this Resource is executed,

this LwM2M Server Object is


28

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 de-

registration 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.

5 Disable

Timeout

RW Single Mandatory

(AT&T)

Integer

s 86400

6 Notification

Storing When

Disabled or

Offline

RW Single Mandatory

(AT&T)

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.

The maximum number of

storing Notifications per

Server is up to the

implementation.

7 Binding RW Single Mandatory String The possible

values of

Resource are

listed in 5.3.1.1

UQS

8 Registration

Update Trigger

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.


29

5.2.1.8. 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


LWM2M Server Object 1 Multiple Mandatory urn:oma:lwm2m:oma:1


ID Name Operations Instances Mandatory Type Range or Enumeration Units Description

0 Short Server ID R Single Mandatory Integer 1-65535

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

Period


s The default value

the LwM2M

Client should use

for the Minimum

Period of an

Observation in

the absence of

this parameter

being included in

an Observation.

If this Resource

doesn’t exist, the

default value is 0.

3 Default Maximum

Period


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.

4 Disable E Single Mandatory

(AT&T)

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 de-

registration

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.

5 Disable Timeout RW Single Mandatory

(AT&T)

Integer

s 86400

6 Notification Storing

When Disabled or

Offline

RW Single Mandatory

(AT&T)

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


31

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.

7 Binding RW Single Mandatory String The possible values of

Resource are listed in

5.3.1.1

UQS

8 Registration Update

Trigger

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.

5.3. 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 13340

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


Device (IOT Module)

3 Single Mandatory urn:oma:lwm2m:oma:3


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 (TA Letter).

17 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

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).

2 Serial

Number

R Single Mandatory String IOT Module IMEI - 15 digits as defined in the PTCRB PPMD specification.

18 Hardware

Version

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).

3 Firmware

Version

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).

19 Software

Version

R Single Mandatory String IOT Module SVN - 2 digits as defined in the PTCRB PPMD specification.

22 ExtDevInfo R Multiple Optional Objlnk

Connects Portfolio

4 Reboot E Optional Manufacturer specific implementation.

5 Factory Reset

E Optional Manufacturer specific implementation.

6 Available Power Sources

R Optional Manufacturer specific implementation.

7 Power Source Voltage



33

8 Power Source Current


9 Battery Level R Optional Manufacturer specific implementation.

20 Battery Status


10 Memory Free R Optional Manufacturer specific implementation.

21 Memory Total


11 Error Count R Optional Manufacturer specific implementation.

12 Reset Error Count

E Optional Manufacturer specific implementation.

13 Current Time RW Optional Manufacturer specific implementation.

14 UTC Offset RW Optional Manufacturer specific implementation.

15 Timezone RW Optional Manufacturer specific implementation.

16 Supported Binding and Modes


5.4. ODIS/DHIR/Portfolio Support by an IOT Module Utilizing LwM2M

Module implementations of ODIS/DHIR/Portfolio utilizing LWM2M shall use the LWM2M Portfolio Object ID = 16. Formerly AT&T supported implementations utilizing a custom value Object ID of 10241. For modules which utilize the custom value 10241 the fields are defined in Appendix B.

5.4.1. LWM2M Object: Portfolio

This section formalizes the Resources definitions of the Portfolio Object that will be Object ID

16. See also AT&T 13340 <CDR-DVM-4542> Support for OMA LWM2M Portfolio Object and

<CDR-DVM-4543> Support for OMA LWM2M Portfolio Object Resources.

AT&T Approved Modules are required to support a minimum of two (2) instances of the

Portfolio Object ID. All Portfolio Objects shall have the capability of being created with AT

commands or function calls at runtime.

Instance (0) shall be used for the primary Host Device entries which the module is being

integrated into (Example: The primary Host Device Manufacturer name will be stored in

Portfolio object 16/0/0/1). In addition to Host Device entries, if the module runs the host

application, Instance 1 shall be used in the case that the module or device represented by

instance 0 is embedded into another device.


34

All instances of the Portfolio Object shall be programmable by the Host Device using AT

commands or an API similar to the commands for the primary instance of the Portfolio Object..

There shall be clear differentiation between commands for different instances. The specific

usage for the instance (1) programming shall be instructed to the Host Device integrator

(Example: The instance (1) manufacturer name will be stored in Portfolio object 16/1/0/1).

The Portfolio object, as is written in the OMA LWM2M specification, is to be linked through the

Device Details object with resource 22. Object ID 3 resource 22 is an objlnk type and will serve

as the link between the Portfolio Object and the Device Details object. Note: Appendix B

provides a separate method for providing these host device details through proprietary

object 10241.

Object definition Name Object ID Instances Mandatory Object URN

Portfolio 16 Multiple Optional urn:oma:lwm2m:oma:16

Resource definition

ID Name Operations Instances Mandatory Type Range or Enumeration

Units Description

0 Identity RW Multiple Mandatory String

Data Storage extension for other Object Instances as defined by GSMA: 0: Host Device ID, 1: Host Device Manufacturer 2: Host Device Model 3: Host Device Software Version,

The fields for Identity shall be populated as follows:

Host Device 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.

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.


35

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 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.

The Resource ID values of 1 GetAuthData, 2 AuthData, and 3 AuthStatus within the Portfolio Object are not required for implementation by AT&T at this time. The storage of the Host Device Details is to be in Non-Volatile Memory as specified in <CDR-DVM-1601>.

5.5. LWM2M Server Object

The LWM2M Server Object is required. The object will provide instances of the Device Management Servers that the LWM2M client can connect to. The resources that must be supported for this object are listed below. There can be multiple LWM2M servers for one client.

5.6. Short Server ID

The Short Server ID is the ID that the Security Object and Access Control Object refer to when pointing to a LWM2M server. In the Security Object this refers to Resource 10 and in the Access Control Object this refers to Resource 3. All of the ID’s in these corresponding resources must match.

5.6.1. Lifetime Lifetime is the length of time that the LWM2M server will keep the LWM2M client’s registration alive. While the client is within the lifetime a registration need not be performed to initiate a device management session. If the client hasn’t updated its registration before the lifetime ends the client will need to register with the LWM2M server again before continuing Device Management.

5.6.2. Disable

This resource is an executable resource and will be controlled by AT&T in the case that the Device begins to negatively impact the network. This will be put in place to protect network resources beyond the proxy such as, RF channels, IP resources, Packet Core, etc.

5.6.3. Disable Timeout


36

Disable Timeout refers to the amount of time in which the LWM2M client is disabled for after an execution of the Disable Resource. This resource will default to 1 day and will only be used in circumstances in which devices are inadvertently attacking our network.

5.6.4. Notification Storing When Disabled or Offline Notification Storing is required in the case that a LWM2M client is disabled or offline yet undergoes a change in which the device wants to report a change to an Object that is being observed by AT&T.

5.6.5. Binding

This resource describes the binding method used by the Radio Module.

5.6.6. Registration Update Trigger

The Registration Update Trigger is an executable resource such that if AT&T executes the Update the LWM2M client will be required to push the values of the Objects that are observed by AT&T.

5.6.7. Registration Update Trigger with SMS For the Registration Update Trigger executable resource the LWM2M client will receive an SMS in PDU mode where a CoAP packet is sent as the message of the PDU. This packet shall be sent as a confirmable POST CoAP message. The client shall receive the SMS, deserialize the message in the PDU, and then read the CoAP message as specified in RFC 7252. The CoAP packet sent over SMS will not be a secure CoAP message and therefore no DTLS signaling will happen between the Client and Server. The Registration Update Trigger will be used as the method to shoulder tap the device. The SMS for the Registration Update Trigger will only be sent in the case that there is no active registration using UDP. A flow of the message reception using SMS is provided in Appendix C. The above method is being manipulated currently to account for the confusion in the 1.0 LWM2M Technical Specification. In the 1.1 Technical Specification there will be a new binding mode that will cover in depth how devices will perform the trigger over SMS

5.7. Access Control Object

Operations on certain objects shall be limited to use by the AT&T XDM LWM2M server. This must be controlled by the Access Control Object as described in Section 7.3 of the OMA LWM2M Technical Specification. There shall be an Access Control Object for the Device Details Object,


37

Connectivity Monitoring Object, Production LWM2M Server Object, and the Lab LWM2M Server Object. The Production AT&T LWM2M server shall be the owner of these Access Control Objects. Access Control Objects associated with the creation of servers must be created during a bootstrap phase. Access Control Objects that have already been created and simply need more instances created can be created during the Service Enablement Phase. The differences above can be seen in detail in Section 7.3.1.2.

5.7.1. Object ID

The object ID resource of the Access control object is the Object that is being restricted or permissioned. These Objects will be the following:

• Device Object

• Connectivity Monitoring Object Each Object Instance will have its own Access Control Object.

5.7.2. Object Instance ID

The Object Instance ID refers to the instance of the object that is being permissioned.

5.7.3. Access Control Owner

The Access Control Owner will be the short server ID of the LWM2M server which can permission other LWM2M servers on the Access Control Object. XDM will be the access control owner of the Device Object ID 3 the Portfolio Object ID 16 and if implemented Object 10241.

5.8. LWM2M FOTA

For a module using a LWM2M client FOTA is optional but strongly recommended. The process requirements for FOTA are in the following section. For a module using a proprietary FOTA that does not leverage an AT&T managed service the device will not subjected to the 19612 test case for FOTA.

5.8.1. LWM2M Object: Firmware Update

LWM2M clients will use Firmware Update Object (Object ID = 5) as the mechanism to perform updates to the module and host device. In AT&T 13340, <CDR-DVM-1471> and <CDR-DVM-1472> detail the Firmware Object as required by AT&T for LWM2M. The Firmware Update Object is also described in detail in Appendix E.6 of the LWM2M Technical Specification.


38

6. Device Management Testing for IOT Modules

For Embedded Wireless Radio Modules that support ODIS/DHIR/Portfolio functionality, testing is required in two areas:

• Nokia XDM Server Interoperability Testing

• AT&T Approved Vendor Lab Testing

6.1. Nokia XDM Server Interoperability Testing

Before any device can be tested against the AT&T Lab or Production instances of the AT&T OMA servers, it must first complete Interoperability Testing against the Nokia (formerly mFormation) XDM platform or BLS and the results of this testing must be supplied to AT&T. For information regarding the Interoperability Testing program please refer to AT&T document “17781 ATT Device Management IOT Program Overview”. This document can be downloaded from the AT&T On Boarding Tool along with other documents necessary to certify a device on the AT&T network. The test cases applicable to an IOT module can be identified by filtering on Column L in the worksheet named “IOT test cases” in the 19612 test plan.

6.2. AT&T Technical Acceptance Testing

Specific test cases for each category of module or device can be referenced by filtering section 1 of 10776 on the Column AC of the spreadsheet to identify the test cases applicable to an IOT module. For each category of device refer to the column labeled “Data Only Module (DOM) “Data and Voice Module (DVM)”. Individual and detailed test case descriptions are found in the latest version of AT&T document 15096, Device Update Test Plan.


39

Appendix A - Minimum Requirements to Implement ODIS/DHIR/Portfolio for IoT Host Devices using an Approved Module (AM)

As of April 4, 2016 all new devices entering the AT&T Network Ready Lab are required to support DM ODIS/DHIR/Portfolio or else be assigned a unique TAC on a unique device basis as determined by PTCRB PPMD rules. Device Management can be implemented with either of two Open Mobile Alliance (OMA) standards, OMA-DM or LWM2M. Device OEMs that have not implemented ODIS/DHIR/Portfolio or are using a radio module that does not support ODIS/DHIR/Portfolio can still achieve AT&T certification by providing AT&T with a data file which maps IMEIs to the following host device identifiers:

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 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 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.

Host Device 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.

The data file should be a .csv formatted text file with one device per line as follows: Host Device Manufacturer, Host Device Model, Host Device Software Version, Host Device ID, IMEI Sample data for the “csv” file is shown in the table below:

Host Device Manufacturer

Host Device Model

Host Device

Software Version

Host Device ID IMEI

ACME Inc Arrow21 4.0 99bAEfgXXf 357099060399038



40





Please note: By choosing this option, the partner must also provide legacy data for all devices manufactured in 2015 and 2016. The data is needed for all carriers, not just AT&T. The data should be provided to AT&T on a recurring 3 month basis beginning at the time AT&T TA is granted until ODIS/DHIR/Portfolio is implemented in the device or upon request for an investigation. Email address [email protected]. 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.

• IoT host device should update ODIS/DHIR/Portfolio fields in module in the event that the host device firmware is updated via any method (Ex: via FOTA, locally via USB, etc.)

• IoT host device should update ODIS/DHIR/Portfolio fields when IoT host device detects a system reset to factory defaults. (ex. if these values are not persistent in module through a factory reset procedure)

Note: 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 IoT module is expected to support the update of Host Device details through an interface such as AT Commands.

Host Device Test Scope

For integrated NR-AM-DX IOT Devices, ODIS Testing will be a part of the AT&T certification process. Since AT&T is offering multiple paths for NR-AM-DX device certification the process will vary. Procedural details are still being created at this point. The scope of the device level ODIS test is focused on a query to the device and an accuracy review of the response. The Device Management client in the module will respond to the query. The host details provided back to the server will be verified by AT&T to match corresponding values in the AT&T On-Boarding Tool as well as the PTCRB listing for the device. If testing can’t be performed OTA, Host Device OEMs will be asked to create a one page report demonstrating th AT commands and content stored in each Host Device field of the module as mentioned earlier.



41

Appendix B - Custom Object ID for ODIS/DHIR Parameters utilizing LWM2M

Module implementations of ODIS/DHIR utilizing LwM2M shall use the Portfolio Object ID = 16. Formerly AT&T supported implementations utilizing a custom value Object ID of 10241. For modules which utilize the custom value 10241 the fields are defined below.

LwM2M Object: HostDeviceInfo This section formalizes the resources definitions of the AT&T custom object ID HostDeviceInfo.

AT&T Approved Modules are required to support a minimum of two (2) instances of the

HostDeviceInfo Object ID. All module requirements of section 4 of this specification are

applicable for both instances of the HostDeviceInfo Object. Instance (0) shall be used for the

primary Host Device entries which the module is being integrated into (Example: The primary

Host Device Manufacturer name will be stored in HostDeviceInfo object 10241/0/5905).

Instance (1) shall be programmable by the Host Device using programming commands similar

to the commands for the primary instance as defined in section 3.3. There shall be clear

differentiation between commands for different instances. The specific usage for Instance (1)

programming shall be instructed to the Host Device integrator (Example: Instance (1)

manufacturer name will be stored in HostDeviceInfo object 10241/1/5905).

Object definition Name Object ID Instances Mandatory Object URN

HostDeviceInfo 10241 Multiple Mandatory

urn:oma:lwm2m:x:10241

ID Name Operations Instances Mandatory Type Range or Enumeration

Units Description

5905 Host Device Manufacturer

R Single Mandatory String

Host Device 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.


42

5906 Host Device Model Number


Host Device Model Number 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.

5907 Host Device Unique ID


The Host Device Unique ID is 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.

5908 Host Device Software Version

R Single Mandatory String Host Device Software 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) for the Host Device.


43

Appendix C – CoAP over SMS Registration Update Trigger

Documents

Device Management Implementation Guide for IoT …T Internet of Things Solutions Organization Device Management Guide 3 Abstract This document is an implementation guide for technical