PDF - New Generation Device Management Protocols

Welcome to the course on “Digital Home: Introduction to New Generation Device Management
Protocols”.
© Nokia 2018 - Nokia Confidential

Before we start, please take a quick look at the controls of this web-based training.
The side panel allows you to see the menu and view the voice-over script.
The control bar along the bottom allows you to play or pause, adjust volume or go to the next
or previous page. The Glossary and Resources such as a PDF or podcast version of this course
are options.
When you are ready, select the “Next” page button to continue.

Upon completion of this course, you will be able to:
• Understand the Nokia Smart Home Solution architecture,
• List the functions provided by the TR-069 protocol,
• Explain the session initiation and connection request in the TR-069 protocol,
• Explain the different Inform messages,
• Understand the need for and the use of OMA-DM, and
• Explain a session in the OMA-DM protocol.
At the end, you can take a quiz to test your gained knowledge.
Please click Next to continue.

Chapter 1 – The Nokia Smart Home solution overview

In this first chapter, we are presenting a global overview of a smart home network and where to
situate the two most important protocols, the TR-069 and the OMA-DM.
The main components we see here are:
• The Nokia IMPACT Platform, which includes:
- The Connected Device Platform (CDP), acting as Auto-Configuration Server (ACS)
- The Impact, which consists of Application, Device, and Execution platform and Data
Collection and Processing
• The 7368 ONT: This is a Residential Gateway ONT with integrated Smart Home or Internet of
Things gateway.
• The Smart Home cloud app, which provides operator access and storage of historical data
received from Impact.
• A smartphone or smart device for controlling home devices: The connection can be
established over a mobile network or over Wi-Fi.
On the next slides, we will show where to situate the two important protocols.

The first important protocol is TR-069, which is used by the CDP to configure and manage the
7368 ONT. Both the ONT gateways, the Residential gateway and the IoT gateway, have a TR-069
adapter for this purpose.
The second important protocol is OMA-DM.
OMA stands for Open Mobile Alliance, DM for Device Management.
It is used by Impact for data collection from home devices. Therefore, an Impact gateway is
included in the IoT gateway. This is software only.
This allows communication using the OMA-DM protocol between Impact and the IoT gateway.
The actual communication between the IoT gateway and the home devices uses the ZigBee, Z-
Wave, Wi-Fi, and Bluetooth Low Energy protocols, but these are handled in another course.

Chapter 2 – TR-069

The first important protocol is TR-069.
TR-069 or CPE WAN Management Protocol (CWMP) is intended for communication between the
CPE or ONT and the ACS.
The broadband forum defines the protocols for remote management framework.
The TR-069 encompasses secure auto-configuration of any CPE or ONT and incorporates other
ONT management functions into a common framework.
In this presentation, we will use CPE in the explanation, but for smart home solution, this is the
ONT.
As an extension on TR-069, there are TR-098, TR-104, TR-142, TR-181, and some other variants.
We will not go into detail on all the variants, but a few will be highlighted later on.
The TR-069 protocol is intended to perform auto-configuration, dynamic service provisioning,
firmware management, fault and performance management, and diagnostics on CPE.

The CPEs or ONTs should have IP connectivity if they have to be managed. For the devices to
get connected through an IP address, some initial configuration is required to be made on the
devices.
For the CPEs or ONTs with the Residential Gateway function, to get connected with the OLT, the
IP address is acquired. Mostly, a DHCP server is used to provide the IP address.
The devices should have TR-069 enabled and have the ACS URL and login credentials to the
ACS.
Once the device is connected, the ACS can update and reconfigure the CPEs.

TR-069 is a widely adopted industry-standard protocol defined by the broadband forum.
TR-069 defines a set of Remote Procedure Calls (RPCs) that define a single call between the ACS
and the CPEs.
This protocol includes the protocol stack, the protocol rules for communication between the
CPEs and the ACS, and the object models.
It is a TCPIP-based protocol and is transparent to the access network. The access networks can
be PON, DSL, or any other access.
The TR-069 protocol provides SSL/TLS security, which is equivalent to the security in a “web-
banking” approach.
The TR-069 protocol uses CPE-initiated HTTP connections and the connection requests or CRs
initiated by the ACS. The CRs can be initiated in any network with firewall, NAT, or proxy servers.
This protocol utilizes XML and SOAP for data representation, interfacing with middleware, and
improving time-to-market results.

The TR-069 protocol's session initiation defines a CPE contacting the ACS with the inform
message.
The CPE should contact the ACS based on certain conditions. The CPE should contact the ACS
based on the frequency of "Periodic Inform Interval" that is configured in the CPE. Note that the
Periodic Inform has to be enabled on the CPE.
The CPE contacts ACS after rebooting for registration purposes. The CPE also contacts ACS
after changing its WAN IP address. The WAN IP address of the equipment can change based on
the subscriber’s usage behavior. The WAN IP address can also change due to the network-
forced IP renewal. The other occasions when the CPE contacts the ACS are during the ACS URL
change, during the “active notification” parameter value change, and also after receiving a
connection request from the ACS. Notifications will be discussed in the later part of this training.
The ACS also contacts the CPE whenever needed, using the Connection Request mechanism.
CPE should always reply to a CR message with an Inform message.
If the CPE does not reply to a Connection Request with a Code 6 CR Inform, the ACS will have to
wait for the next Inform.

Inform messages are sent by any TR-069 device when the devices want to establish communications
with the ACS. These messages are sent periodically to the ACS to communicate the device parameter
values. The Inform messages are also sent in response to the ACS connection requests. Inform
messages are also referred to as ACS Inform messages and they are directed toward the ACS.
All TR-069 Inform messages initiated by the CPE begin with the ACS connection URL and
authentication credentials that will be used by ACS to authenticate the CPE.
This is followed by the device details that the CPE presents to the ACS. The device details include the
device manufacturer, device OUI, product class, and device serial number. Device OUI, also referred to
as the Organizationally Unique Identifier, is a number that uniquely identifies any manufacturer.
Device OUIs are assigned by the IEEE Registration Authority. The device product class ensures
uniqueness of devices and device types. Note that the product class for any device is an optional
component. The combined OUI, the product class, and the serial number uniquely identify the
devices.
The device details are followed by an Inform event. The Inform event informs the ACS of certain
event occurrences.
Some common Inform events include the Bootstrap Inform message, Boot Inform message,
Connection Request Inform message, Periodic Inform message, and Value Change Inform message.
Note that an Inform message may contain one or more than one Inform event. For example, an
Inform message at CPE Boot may contain the Boot Inform and the Bootstrap Inform. In this example,
the Periodic Inform message allows the CPE to send the Inform message to ACS based on a "Periodic
Inform Interval". The "Periodic Inform Interval" may occur once every 24 hours. Inform events will be
discussed later in this training. The CPE also presents the time when an Inform message is sent to the
ACS.
As part of an Inform message, the device also shares the parameter names and their values with the
ACS. The device shares its hardware and software versions, the URL where the ACS can send a
connection request to the CPE, and the Public IP address of the device. In some cases, CPEs may
have a different CR URL and Public IP address.
In response to an Inform message, the ACS sends an Inform response.

Here is an example of a session initiation by the CPE. Note that for simplicity, the initial dialog in
the graph is presented with an empty inform message, however, in reality, there will be other
Inform messages between the CPE and ACS. In this dialog, as the CPE does not know how to
authenticate, it sends an empty Inform message, without any user ID or password.
The ACS responds to the CPE by sending instructions for authentication. The response from
ACS includes some additional details like authentication required or not required; if required,
then whether it will be hashing authentication or not.
Based on the authentication requirement details received from the ACS, the CPE sends an
Inform message with the credentials in the right format.
If the authentication is OK, then the ACS replies with a 200 OK message. The ACS may also
provide some additional configuration instructions to the CPE. The instructions from ACS can
be, for example, to set parameter value operation.
The dialog ends with the exchange of 204 empty messages. If the CPE fails to send a “no
content” http message, ACS sends the message instead and the CPE replies with the http 204
empty message. This would terminate the session as well.
If neither the ACS nor the CPE sends any http 204 empty message, there can be a system
setting in the ACS to abort the session after a configurable amount of time, which is usually 30
seconds.

Inform events are included in the Inform messages that are sent to the ACS by the CPEs.
This slide lists the Inform events between the CPE and the ACS. Multiple Inform events can be
reported in a single Inform message.
The next slides discuss some of these Inform events in detail.

The CPE sends the Bootstrap message when it is installed the first time, after factory reset or
after the ACS URL has changed. This event provisions a device from a clean state to a state that
can initiate device management sessions.
In this example, there are two Inform events, the "0 BOOTSTRAP" event is combined with the "1
BOOT" Inform event. This indicates that the device is booting and then it needs to be
provisioned to start the device management sessions.
This is the case for every new CPE that tries to communicate with the ACS. However, there can
also be only a bootstrap without any boot event. A bootstrapped client can still use only the
bootstrap event to connect to a new device management server.

A Boot message is sent when a CPE is booted up or is reset. As seen in the previous case, a
Boot message can be combined with, for example, a bootstrap in the same Inform. “M Reboot”
is included in the Inform if the device reboots in reply to a reboot RPC sent by the ACS.
In this example, you see two Inform events, the "1 BOOT" event and the "M Reboot" event,
indicating that the CPE reboots upon an ACS reboot request.

Periodic Inform event polls the ACS for a new configuration. This event occurs based on the
"Periodic Inform Interval" configured for that CPE device. For example, a device may be
configured to send a message to the ACS every 24 hours. Periodic Inform is enabled with a
certain "Periodic Inform Interval," as set by the ACS.
In this example, “2 PERIODIC” Inform event is sent by the device based on the "Periodic Inform
Interval". The operator can change the frequency of "Periodic Inform Interval" to any other
value.

Value Change Inform message occurs based on a parameter value change. The value change
parameter is included in the Inform message. Value change informs can trigger alarms on the
ACS. These Inform events are the active or passive notifications that are triggered at change of
a parameter value. A value change notification also includes the value and the name of the
parameter that has triggered this notification.
In this example, you will see a value change notification sent at Periodic Inform for the
parameter “Periodic Inform Interval." As this notification is not sent immediately and sent only
upon the Periodic Inform, this notification is passive type.

When a value change notification is issued without any Periodic Inform message, it indicates that
the notification is sent immediately, without waiting for the Periodic Inform message. Such
notifications sent immediately are active notifications. All notifications contain the name and
value of the parameter for the notification that is issued.

A Connection Request Inform message occurs based on Connection Request URL from the ACS.
The CPE sends the "6 CONNECTION REQUEST" Inform to the ACS after which the ACS can
execute some functions on CPE.
For example, the ACS can request the CPE to download the new firmware after receiving the "6
CONNECTION REQUEST" Inform from the CPE. Connection Request Inform lets the ACS speed
up the execution of some functions. Without Connection Request Inform, the Periodic Inform
has to be set to a lower value, which in turn increases the load on ACS.

Transfer Complete Inform occurs when a previously requested download or upload completes
on the CPE. A Transfer Complete Inform message is generated irrespective of successful or
unsuccessful download or upload operation.
The Transfer Complete Inform event follows the download or upload request by the ACS, where
the ACS shares the download or upload details with the CPE.

In this example, the ACS through the Download method shares the file details that the CPE
needs to download. The details shared by the ACS include the file type, file location, login
credentials, and the file size of the ACS.
CPE, after performing the required download or upload operation, sends the Download
response with the success or failure status.
The process is completed with the sending of Transfer Complete Inform event.

Custom events are also vendor-specific events that begin with X, followed by the event name.
These events are not defined by the standard bodies.
Custom events can trigger a policy on the device. For example, an NBI call can request the ACS
to enable VOIP for a CPE.

The Remote Procedure Calls (RPCs) is a mechanism that is used for bidirectional communication
between any CPE device and the ACS. RPCs sent toward the ACS are the ACS methods. An
Inform message sent toward the ACS is an ACS Inform method. This slide presents the
mandatory and optional ACS methods.
Some of the important ACS methods are explained in the subsequent slides.

This slide presents the CPE methods. All RPCs that are sent toward the CPEs are CPE methods.
For example, the Reboot method initiated by the ACS toward the CPE is referred to as a CPE
method. CPE methods are also classified as mandatory methods and optional methods.
Some of the important RPC methods are explained on the subsequent slides.

As an example, we will explain the "Set Parameter Value" or SPV method, which is a CPE method.
This method is used by the ACS to modify the value of one or more device parameters.
The ACS requests the gateway device to set the port mapping parameters for its LAN devices,
as provided by the ACS. Any message sent by the ACS to the external port of 1024 of the
gateway device should be directed to the LAN device with the private IP address 192.168.2.2 and
port 8104.

Fault codes indicate errors that occurred while processing some action. Fault codes classified as
fault at the CPE are identified by CPE fault codes and faults at the ACS are classified as ACS
fault codes. The ranges for CPE fault codes are 9000 to 9032 and 9800 to 9899. The range
9000 to 9032 specifies standard fault codes, indicating issues with the parameter names,
values, and others. The range 9800 to 9899 specifies vendor-specific fault codes.
The ACS fault codes range from 8000 to 8005 for standard faults and 8800 to 8899 for
vendor-specific faults.
In this example, the ACS requests port mapping details from the gateway device. As the port
mapping is not yet defined in the gateway device, the gateway device responds with fault code
9005 invalid parameter name.

Both the TR-181 devices and the Device1 devices use the XML schema in ACS. Note that the
XML is not entirely the same for Device:1 and Device:2. An additional element called type is
required for TR-181 whereas that element is optional for Device:1. Review the xml schema for
Device 1 and Device 2.

TR-106 defines a general template for data model definition and additionally defines common
objects for LAN devices.
This slide gives an overview of a Data Model Template for TR-069-enabled devices. One can
clearly distinguish the different device types, which include the Internet Gateway Device, the
LAN Device or Device:1, the combined new device type Device:2, and the service objects. The
TR-106 was also described previously on the Broadband Home Remote Management
Framework slide.

This reference slide provides details on Provisioning Parameters for VoIP CPE.
The configuration is only supported for gateway devices that are conform to TR-104. Some
parameters that need to be configured for the Voice profile include the tones that will be
supported for MP3, WAVE, AMR, and others. The RTP protocol for VoIP application defines the
port numbers and payload type which, in VoIP, will be voice.
Line configuration includes the codecs, ringer type, calling features, voice processing, and
session. The codecs configured specify the voice encoding for quality.

The TR-181 Issue 2, Amendment 2 for Device 2 data model applies to all types of TR-069-
enabled devices, including End Devices, Residential Gateways, and other Network Infrastructure
Devices. This specification is a next-generation evolution that supersedes both Device:1 and
InternetGatewayDevice:1.
The data objects defined are simple, covering things like basic device information, time-of-day
configuration, network interface and protocol stack configuration, routing and bridging
management, throughput statistics, and diagnostic tests.
The cornerstone of the Device:2 data model is the interface stacking mechanism. Network
interfaces and protocol layers are modeled as independent data objects that can be stacked,
one on top of the other, into whatever configuration a device might support. This data model
supports configuration of IPv6-related parameters.

The diagram shows the situation where the ONT supports TR-069. In this case, OMCI is still used
for link layer configuration and management between OLT and ONT, while IP-based services are
configured and managed by TR-069. In this example, TR-069 would handle the Residential
Gateway functionality and a voice over IP client integrated into the ONT.
But actually what it means is that TR-069 follows the path that makes use of OMCI from OLT
toward ONT to reach the Residential Gateway.

Chapter 3 – Open Mobile Alliance, Device Management

Several operators and vendors realized that managing devices remotely was a difficult task and
is often done in a proprietary fashion:
• Operators were worried about their call center costs being too high and customers not
being happy with their service.
• Vendors were worried that they were not able to provide the operator with information
about their device. They were also worried about how to update their firmware remotely.
• Operators and vendors got together and wrote a standard SyncML DM, which later came to
be known as OMA-DM. This standard allowed operators to reduce their call center time,
remotely update devices, and help keep their customers happy.

Remember this slide from the beginning of this course.
OMA-DM is the protocol that is used between the Impact Platform and the ONT Smart Home
Gateway. In the Smart Home Gateway, there is a piece of software that was specifically
designed to handle OMA-DM. This piece is called the Impact Gateway on the ONT and translates
the OMA-DM protocol messages from Impact to the protocol needed to talk to remote devices.
It can be ZigBee, Z-Wave, Wi-Fi, or Bluetooth Low Energy.

OMA DM is used for:
• Provisioning of remote devices:
This includes the initial setting of configuration data as well as the update of configuration
data.
• Determination of the device’s DM capabilities:
This includes information about the device as well as details on the make, model, firmware
version, etc.
• OMA-DM is designed to work with small mobile devices that are intermittently connected. It
uses small messages that are compressed using WBXML or transport compression.

• OMA-DM uses a Client-Server architecture:
- HTTP is used as the primary transport.
• Commands are simple and apply only to a management tree. Applicable commands are Add,
Replace, Get, and Delete. With these commands, it is possible to access single nodes or
entire subtrees.
• Exec is a special command used to have the client execute some local command, such as
firmware update.
• OMA-DM has a strong security:
- Client and Server must be mutually authenticated on the transport layer as well as the
application layer.
- HTTP must use TLS 1.0 or SSL 3.0.

A Device Management (DM) session consists of a series of commands exchanged between a DM
server and a client device. The server sends commands indicating operations that must be
performed on the client device's management tree. The client responds by sending commands
that contain the results and any requested status information.
A DM session can be divided into two phases: Setup phase and Management phase
These are the steps in more detail:
• Step 1 : The DM client is invoked to call back to the management server.
The trigger message includes the server ID and tells the client device to initiate a session
with the server. The client device authenticates the trigger message and verifies that the
server is authorized to communicate with it.
• Step 2 : The device sends a message, over an IP connection, to initiate the session.
This message includes device information and credentials. The client and server do mutual
authentication over an SSL channel or at the DM application level.
• Step 3 : The DM server responds, over an IP connection (HTTPS).
The server sends initial device management commands, if any.
• Step 4 : The device responds to server management commands.
This message includes the results of performing the specified device management
operations.
• Step 5 : The DM server terminates the session or sends another command.
The DM session ends, or Step 4 is repeated.
The step numbers in the table do not represent message identification numbers (MsgID). All
messages from the server must have a MsgID that is unique within the session, starting at 1 for
the first message and increasing by an increment of 1 for each additional message.
For more information about MsgID and OMA SyncML protocol, see "OMA Device Management
Representation Protocol" (OMA-TS-DM_RepPro-V1_2-20070209-A) available from the OMA
website.

Bootstrapping is a way of bringing a device from a clean state to a state where it is capable to
initiate a management session with a specific management authority.
Previously bootstrapped devices may be further bootstrapped for additional servers.
Bootstrap messages can arrive:
• At the factory (not defined by OMA DM)
• Or can be server-initiated (through SMS, WAP Push, or OBEX)
• Or can be smartcard initiated
Information installed through smartcard is removed when the smartcard is removed.

In this course, we have covered the following items:
• Understand the Nokia Smart Home Solution architecture,
• List the functions provided by the TR-069 protocol,
• Explain the session initiation and connection request in the TR-069 protocol,
• Explain the different Inform messages,
• Understand the need for and the use of OMA-DM, and
• Explain a session in the OMA-DM protocol.

Please take a moment to read the disclaimer on this screen.


PDF - New Generation Device Management Protocols

Uploaded by

Copyright:

Available Formats

PDF - New Generation Device Management Protocols

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PDF - New Generation Device Management Protocols

Uploaded by

Copyright:

Available Formats

Welcome to the course on “Digital Home: Introduction to New Generation Device Management

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

© Nokia 2018 - Nokia Confidential

You might also like