Pipeline Publishing, Volume 5, Issue 4
This Month's Issue:
Enabling Innovation
download article in pdf format
last page next page

Simplifying Device Management:
The TM Forum's Call to Action

back to cover

article page | 1 | 2 | 3 | 4 | 5 |

    • Device detection/status can also mean actively scanning the network to identify new devices. The end user may add new devices to the home network, without the service provider noticing it. Those devices may also be managed by the service provider based on a subscriber request.
    • Device detection can also be extended to error detection. When a device is not able to connect to a network element, the error can be automatically detected in the network element. Depending on the nature of the error (no subscription, wrong parameters, and so forth) the relevant correction can be triggered. For example, the connection parameters can be updated in the device.
    • Device detection must be a multi-vendor-capable solution. It collects triggers and interacts with network elements independent of the different network element suppliers' equipment installed in the service provider's network.
  • A database of devices that describes the device capabilities in detail – in order to know how the devices are being used

    Earlier devices typically had one service. With increased convergence, devices have started supporting multiple services and are expected to support even more services in the future. For such a scenario, instead of building service-specific silos, as is often the case now, a horizontal and abstract way to represent device capabilities will be needed, leading to the need for a device capabilities database. This information base identifies the devices and maps them to various devices attributes. The database needs to include relevant device information (such as brand and model), capabilities (such as features supported), and configuration information (e.g., how to configure the device for certain services). The list of other device attributes could be made optional to take account of certain device-specific details.

With increased convergence, devices have started supporting multiple services and are expected to support even more services in the future.



    It must be possible to edit the device database and add additional devices and device attributes. This will help to resolve unknown device or device attribute issues. Also, it must be possible to remotely update the device database on a regular basis including incremental and full updates. Export and import facilities must be provided by the device capabilities database.

  • A common approach to detect faults in the devices, thus enhancing their usability, including user-initiated or auto-run diagnostics, and user control for remote diagnostics

    We may distinguish the following scenarios:

    • Hardware and software faults of end-user devices: Diagnostics might involve both self-detection mechanisms on the device and active monitoring from the network side (the latter is the only option for an important category of problems like power-off of device and total loss of connection).
    • Device/service configuration: Configuration checks might be initiated locally (auto-run or by the end-user) or remotely.
    • Service performance and quality issues (detected through suitable KPI measurements on device): The corresponding measurements might be performed proactively (permanent or selected time intervals; all or selected devices) or reactively on request.


article page | 1 | 2 | 3 | 4 | 5 |
last page back to top of page next page
 

© 2006, All information contained herein is the sole property of Pipeline Publishing, LLC. Pipeline Publishing LLC reserves all rights and privileges regarding
the use of this information. Any unauthorized use, such as copying, modifying, or reprinting, will be prosecuted under the fullest extent under the governing law.