Technical Report Document Number



Download 309.51 Kb.
Page7/11
Date31.01.2017
Size309.51 Kb.
#13095
1   2   3   4   5   6   7   8   9   10   11

6.3 MGR-002

6.3.1 Requirement Description


The M2M System shall provide the capability to discover the M2M Area Networks including information about devices on those networks and the parameters (e.g., topology, protocol) of those networks.[i.23]

6.3.2 OMA DM 1.3 and OMA DM 2.0


OMA DM 1.3 provides FULL support for this requirement.

In the setup phase of the OMA DM protocols. The MO DevInfo is transported from DM Client to DM Server. And the MO DevDetail can be requested by DM Server if necessary. In the MO DevInfo and DevDetail, information about how the device can be reached, the protocol, the address, port number, required security parameters is transferred from device to DM server.

For devices in the local area network that are attached to the DM Gateway, GwMO can be used to get the address information.

Also some work has been done in ETSI M2M to define MANMO and MANDMO [i.24] to enable the DM Server to get the information about the topology and protocol of the local area network.

In this way, the DM Server can get to know the connection related parameters (protocol) from the device.GwMO defines how DM Server can manage device in a local area network through DM Gateway. DM Gateway can work in three modes which are transparent mode, proxy mode and adaptor mode. OMA DM devices and non-OMA DM devices can all be managed using DM Gateway. Combined with other MOs defined by OMA DM, devices in the local area network can be managed by DM Server.

6.3.3 BBF TR-069


TR-069 provides FULL support for this requirement.

TR-069 provides support for discovery of devices in the associated Local Area Networks for CWMP enabled devices.

TR-069 proxy management has mechanisms where a CPE Proxier discovers devices using device discovery mechanisms as described in Appendix I of TR-069 [i.13]. These mechanisms rely on the discovery of the device using the device’s native protocol (e.g., UPnP DM, ZigBee, Z-wave).

The discovery of the topology of the area network in which the device exists is constrained by the device’s native protocol support for topology discovery. For example – UPnP DM doesn’t provide any support for discovery of topologies while ZigBee topologies can be inferred by evaluating the routing tables of the ZigBee nodes. The TR-181 data model exposes these elements (e.g., ZigBee routing tables) but rely on the management systems to develop the topologies.

The TR-181i2 data model [reference TR-181 Device Data Model for TR-069 Issue: 02 Amendment 6 November 2012] provides support for the following LAN topologies:


  • Ethernet

  • WiFi

  • USB

  • HPNA

  • MoCA

  • G.hn

  • HomePlug

  • Universal Powerline Association (UPA)

  • UPnP

In addition the ZigBee Pro topology support is expected to be included in the next release of TR-181i2.

6.3.4 OMA LWM2M


OMA LWM2M provides FULL support for this requirement.

Connectivity Monitoring Object contains which networks are available and which network is currently used.

Also, it has parent router IP address of each M2M Device so the M2M System can discover entire topology of M2M Local Area Network.

Protocol (e.g., WLAN, Bluetooth) used by M2M Device is specified in Connectivity Object also.


6.4 MGR-003

6.4.1 Requirement Description


The M2M System shall provide the capability to maintain and describe the management information model of devices and parameters (e.g., topology, protocol) of M2M Area Networks. [i.23]

6.4.2 OMA DM 1.3 and OMA DM 2.0


OMA DM 1.3 provides FULL support for this requirement.

For devices in the local area network, some work has been done in ETSI M2M to define MANMO and MANDMO [i.24] to maintain and describe the information model about the topology and protocol of the local area network. The MANMO and MANDMO have been submitted for registration in OMA.


6.4.3 BBF TR-069


TR-069 provides FULL support for this requirement.

TR-069 provides capabilities to describe and maintain the management information model of CWMP and non-CWMP enabled devices as through the Supported Data Model and Software/Firmware Management features of the protocol. Within TR-069 all devices and services that are of interest to the problem space are modelled using the TR-069 XML meta-model. These models are a description of the device and services that are under management. These models can be either configured within the device or CWMP Proxy (if the device is not CWMP enabled) or the device can report its Supported Data Model to the ACS.


6.4.4 OMA LWM2M


OMA LWM2M provides FULL support for this requirement.

Connectivity Monitoring Object contains lots of Resources to maintain and describe the information model about the topology and protocol of the local area network.

LWM2M has several features to be able to manage LWM2M Clients in M2M Local Area Network. The main barrier is how to reach LWM2M Clients from LWM2M Server.


  • Let a LWM2M Server know when IP Address is changed at LWM2M Client by sending Registration Update logical operation.

  • Support Queue mode which makes LWM2M Server queue the request until LWM2M Client is online. If LWM2M Client with Queue mode is within M2M Local Area Network, LWM2M Client sends Update message triggered by time or event. After LWM2M Server receives Update message, the LWM2M Server reaches LWM2M Client so the LWM2M Server sends queued message.

6.5 MGR-004

6.5.1 Requirement Description


The M2M System shall support common means to manage devices enabled by different management technologies (e.g., OMA DM, BBF TR-069).[i.23]

6.5.2 OMA DM 1.3 and OMA DM 2.0


OMA DM 1.3 can ALLOW the fulfilment of the requirement.

OMA DM does not provide features that translate between OMA DM and other management protocols (e.g., BBF TR-069, oneM2M). As such there is an expectation that the M2M System would translate between management protocols.

The management of devices defined by OMA DM is fulfilled by sending DM Messages from DM Server to DM Client. The management related information is carried by Management Objects. For the oneM2M system to support common means to manage devices through OMA DM, the oneM2M system could include the DM Server, DM Client and DM Gateway in the oneM2M system and could have some abstraction to include the MO trees in the oneM2M system to enable the device management in spite of the detailed technologies.

6.5.3 BBF TR-069


TR-069 ALLOWS fulfilment of the requirement by Service Layer mechanisms.

TR-069 family of specifications do not provide features that translate between TR-069 and other management protocols (e.g., OMA-DM, oneM2M). As such there is an expectation that the M2M System would translate between management protocols.

TR-069 provides access to manage devices through its Auto-configuration Server. The Auto-configuration Server has interfaces with the NMS/OSS and BSS systems of the Service provider. As such the ACS would have expected to interface with the M2M System.

6.5.4 OMA LWM2M


OMA LWM2M ALLOWS fulfilment of the requirement when common means between the oneM2M Server and LWM2M Server are defined. OMA LWM2M only defines the protocol between the LWM2M Server and LWM2M Client.

LWM2M does not provide features that translate between LWM2M and other management protocols (e.g., OMA-DM, oneM2M, TR-069).




Download 309.51 Kb.

Share with your friends:
1   2   3   4   5   6   7   8   9   10   11




The database is protected by copyright ©ru.originaldll.com 2024
send message

    Main page