WO2011121111A1 - A universal snap group (usg) mechanism - Google Patents

A universal snap group (usg) mechanism Download PDF

Info

Publication number
WO2011121111A1
WO2011121111A1 PCT/EP2011/055106 EP2011055106W WO2011121111A1 WO 2011121111 A1 WO2011121111 A1 WO 2011121111A1 EP 2011055106 W EP2011055106 W EP 2011055106W WO 2011121111 A1 WO2011121111 A1 WO 2011121111A1
Authority
WO
WIPO (PCT)
Prior art keywords
controller
parameter
parameters
usg
list
Prior art date
Application number
PCT/EP2011/055106
Other languages
French (fr)
Inventor
Robert Gurdan
Original Assignee
U-Man Universal Media Access Networks Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by U-Man Universal Media Access Networks Gmbh filed Critical U-Man Universal Media Access Networks Gmbh
Publication of WO2011121111A1 publication Critical patent/WO2011121111A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/084—Configuration by using pre-existing information, e.g. using templates or copying from other elements
    • H04L41/0846—Configuration by using pre-existing information, e.g. using templates or copying from other elements based on copy from other elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network

Definitions

  • the broad motivation for the USG mechanism according to the present invention is to enable fast 'snapshots' of a defined group of parameters.
  • the USG mechanism enables an application which can reside on a workstation or device to indicate to any device the defined group of parameters that it is interested in. The application can then request the device to send the values of the defined group of parameters to it.
  • the USG mechanism further enables an application to set the values of a remote device's defined group of parameters.
  • any device or workstation can adopt the role of a
  • the XFN protocol allows a parameter to be addressed in two ways, a full address (8* 13 bits) or a parameter ID (32 bits). It is more bandwidth efficient to address a parameter with a parameter ID.
  • the USG mechanism allows a controller to send a number of full addresses to a device, where some of these addresses may have wildcards that replace their level ID's.
  • the device will send back the number of messages that it needs to transmit to the controller in order to fulfill the request at the given fragmentation level.
  • the controller can now successively request each list of ID's and corresponding values. In most cases there will just be a single list.
  • This response provides a list if XFN ID's and their associated values.
  • the retrieved parameters can be used in the context of parameter value discovery, and once-off display. They can also be used for the later update of parameters, effectively providing a device 'preset' capability. A more complex use is for the regular update of a graphical display, for example when metering is required or when multiple controllers require regular status updates.
  • a controller After going through the process of retrieving the parameter ID's and associated values for a particular group of parameters, a controller can later restore the values of the parameters in the following manner: Controller -> Device
  • the device can use these ID's to index into its XFN ID list, and will access the associated XFN parameter structure to determine and subsequently call the correct XFN callback function.
  • the complete messaging series necessary for the retrieval and restoration of parameters is shown in Figure 1.
  • a controller Given that a controller has obtained a set of parameter ID's from a device via the snapshot retrieval mechanism, it can request that one or more of these ID's and their corresponding values are 'Pushed' to it regularly, with a given frequency. As a first step in this process, the controller has to:
  • the controller can now request that the device should regularly update it with the current values of the parameters that it (the controller) retrieved. It does this via the 'Push USG' command:
  • Push USG ⁇ Controller IP addr + Node ID> ⁇ Update Frequency (messages/sec)>
  • the device On the device side, the device will create a 'listener' entry for each controller that is interested in receiving parameter updates from it. This listener entry will hold the IP address and the Node ID provided by the Controller. It will also have a list to hold parameter ID's and associated values for any parameters that have had changed values. This is sufficient information with which to regularly update the 'listening' controller.
  • the device will also add a listener pointer entry to each parameter from which a controller requires updates. This listener pointer will point to the single listener entry for the device. As indicated in the introduction, there are two contexts where regular parameter updates are required:
  • a device In the case of metering, a device will read the current values of a group of parameters at regular intervals, and after each of these readings, will trigger a parameter change event for each of the parameters.
  • the event handler for this event will view the associated listeners for each triggered parameter, and will add the parameter and its value to each of the listeners.
  • the device After a specified interval (determined by the controller-supplied frequency), the device will send the parameters and values within a listener's parameter list to the specified node of the listener. This is achieved via a Set USG PUSH command:
  • the triggering of parameter updates will come from the controllers. For example, a controller might select a cross point on a routing matrix, and this new routing should be viewable by all controllers. Whenever a particular controller causes such a parameter change, the device will place the parameter's ID and its value in the parameter list of all listeners (controllers) associated with the parameter, except for the listener that made the change. This is because the listener that made the change does not need the update.
  • the device to controller update procedure is the same as for metering. After a specified interval (determined by the controller-supplied frequency), the device will send the parameters and values within a listener's parameter list to the specified node of the listener. This is achieved via a Set USG PUSH command:
  • the parameter ID values of the local parameters on the controller side will differ from the parameter ID's of the actual parameters that they model on the device side.
  • a translation table is required to be set up by the controller to enable the translation of parameter ID's that come from the device.
  • Figure 3 shows a diagram of two controllers and a single device. In the shown example both controllers are interested in receiving regular updates of the value for a single parameter A.
  • Controller 1 and Controller 2 creates a USG group with the single parameter A
  • Controller 1 and controller 2 creates a Node for the device and a local parameter that mirrors the real device parameter A
  • Controller 1 and controller 2 send a request to the device to
  • the device adds controller 1 and controller 2 as 'listeners'.
  • the device adds listener entries for controller 1 and controller 2.
  • parameter A is updated, either via a regular meter update or a request from one of the controllers, parameter A is added, with its value, to each of the listeners' (controller 1 and controller 2) parameter lists.
  • a listener's parameter list is transmitted to the listener (in our case ID of the single parameter A and its value will be sent to the listener - controller 1 or controller 2).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Selective Calling Equipment (AREA)

Abstract

A method for exchanging device parameters between at least two devices connected with each other via a data connection, wherein a first requesting device sends a request message comprising a structured list of parameter addresses to a second device which generates in response to the received request message a structured list comprising parameter values of the requested device parameters and sends the generated structured list to the first device.

Description

TITLE
A Universal Snap Group (USG) Mechanism
The broad motivation for the USG mechanism according to the present invention is to enable fast 'snapshots' of a defined group of parameters. The USG mechanism enables an application which can reside on a workstation or device to indicate to any device the defined group of parameters that it is interested in. The application can then request the device to send the values of the defined group of parameters to it. The USG mechanism further enables an application to set the values of a remote device's defined group of parameters. There are two contexts where this capability is required:
• Retrieval of parameters from a device - it should be possible to retrieve the values of a defined set of parameters from a device, and to later set the parameters to these values. This fulfills the typical task of taking a 'snapshot' of a device, and then restoring this 'preset' at a later stage. This capability is also required when discovering a device and displaying its parameter values via a graphical user interface. It is particularly useful in the context of matrices, where large numbers of parameter values are required for the numerous cross-points of matrices.
• Regular unicast bulk parameter updates from a device to a controlling device or workstation (controller), where the controller specifies which parameters it requires. This could, for example, provide regular metering information to an application such as UNOS Vision. It is also useful in a multi-controller context, where two or more controllers are viewing and altering parameters via graphical user interfaces. All controllers need to view the current status of the device parameters, and to do this require regular updates.
•
In the following sections, note that any device or workstation can adopt the role of a
'controller'.
Controller ~ > Device
The XFN protocol allows a parameter to be addressed in two ways, a full address (8* 13 bits) or a parameter ID (32 bits). It is more bandwidth efficient to address a parameter with a parameter ID. The USG mechanism allows a controller to send a number of full addresses to a device, where some of these addresses may have wildcards that replace their level ID's.
Create USG <fragment size><no of address entries> <full address 1, full address2, ...
fulladdressN> This command is sent from a controller to a device as shown in Fig. 1. The command is intended to acquire a list of XFN parameter ID's, and their corresponding values. However, the controller may have a limit on the size of a list that it can receive, and it needs to indicate this to the device: fragment size - the maximum length of each USG list in bytes Device ~ > Controller
ListNo <No oflists>
In response, the device will send back the number of messages that it needs to transmit to the controller in order to fulfill the request at the given fragmentation level.
Controller ~ > Device
Get USG List <List N>
The controller can now successively request each list of ID's and corresponding values. In most cases there will just be a single list.
Device ~ > Controller
ListData<full addresl, xfnIDI, Value formatl, Valuel, full address 1, xfnID2, Value2, ... full addressN, xfnIDN, Value formatN, ValueN>
This response provides a list if XFN ID's and their associated values.
This fundamental retrieval system can now be utilized in a number of contexts.
As indicated above, the retrieved parameters can be used in the context of parameter value discovery, and once-off display. They can also be used for the later update of parameters, effectively providing a device 'preset' capability. A more complex use is for the regular update of a graphical display, for example when metering is required or when multiple controllers require regular status updates.
After going through the process of retrieving the parameter ID's and associated values for a particular group of parameters, a controller can later restore the values of the parameters in the following manner: Controller -> Device
Set USG<No of entries> <xfnIDl, Value format 1, Value 1, xfnID2, Value format2, Value2, ... xfnIDN, Value formatN, ValueN>
The device can use these ID's to index into its XFN ID list, and will access the associated XFN parameter structure to determine and subsequently call the correct XFN callback function. The complete messaging series necessary for the retrieval and restoration of parameters is shown in Figure 1.
Given that a controller has obtained a set of parameter ID's from a device via the snapshot retrieval mechanism, it can request that one or more of these ID's and their corresponding values are 'Pushed' to it regularly, with a given frequency. As a first step in this process, the controller has to:
• Create a local 'virtual node' with a Node ID that is unique for the controller
• Create local parameters within this node that each have the same XFN address block as the parameters on the remote device
This is shown in the in the Figure 2, where parameters XL.Xn on the controller have the same address blocks as parameters Al ...An on the remote device.
The controller can now request that the device should regularly update it with the current values of the parameters that it (the controller) retrieved. It does this via the 'Push USG' command:
Controller -> Device
Push USG <Controller IP addr + Node ID> <Update Frequency (messages/sec)>
<fragment size>
<No of entries> <xfnIDl, xfnID2, ...xfnIDN>
On the device side, the device will create a 'listener' entry for each controller that is interested in receiving parameter updates from it. This listener entry will hold the IP address and the Node ID provided by the Controller. It will also have a list to hold parameter ID's and associated values for any parameters that have had changed values. This is sufficient information with which to regularly update the 'listening' controller.
The device will also add a listener pointer entry to each parameter from which a controller requires updates. This listener pointer will point to the single listener entry for the device. As indicated in the introduction, there are two contexts where regular parameter updates are required:
• Metering - regular parameter value updates for metering purposes
• Multiple controllers - more than one controller requiring status updates
Metering context
In the case of metering, a device will read the current values of a group of parameters at regular intervals, and after each of these readings, will trigger a parameter change event for each of the parameters. The event handler for this event will view the associated listeners for each triggered parameter, and will add the parameter and its value to each of the listeners.
After a specified interval (determined by the controller-supplied frequency), the device will send the parameters and values within a listener's parameter list to the specified node of the listener. This is achieved via a Set USG PUSH command:
Device ~ > Controller
Set USG PUSH <No of entries> <xfnIDl, Value formatl, Valuel, xfnID2, Value format2, Value2, ... xfnIDN, Value formatN, ValueN> Multiple controller context
In a multi-controller context, the triggering of parameter updates will come from the controllers. For example, a controller might select a cross point on a routing matrix, and this new routing should be viewable by all controllers. Whenever a particular controller causes such a parameter change, the device will place the parameter's ID and its value in the parameter list of all listeners (controllers) associated with the parameter, except for the listener that made the change. This is because the listener that made the change does not need the update.
The device to controller update procedure is the same as for metering. After a specified interval (determined by the controller-supplied frequency), the device will send the parameters and values within a listener's parameter list to the specified node of the listener. This is achieved via a Set USG PUSH command:
Device ~ > Controller Set USG PUSH <No of entries> <xfnIDl, Value formatl, Valuel, xfnID2, Value format!, Value2, ... xfnIDN, Value formatN, ValueN>
The parameter ID values of the local parameters on the controller side will differ from the parameter ID's of the actual parameters that they model on the device side. A translation table is required to be set up by the controller to enable the translation of parameter ID's that come from the device.
Figure 3 shows a diagram of two controllers and a single device. In the shown example both controllers are interested in receiving regular updates of the value for a single parameter A.
Six steps are shown in Figure 3
1. Each controller, i.e. Controller 1 and Controller 2 creates a USG group with the single parameter A
2. Each controller, i.e. Controller 1 and controller 2 creates a Node for the device and a local parameter that mirrors the real device parameter A
3. Both controllers, i.e. Controller 1 and controller 2 send a request to the device to
provide regular updates 'pushes' of the parameter A value
4. The device adds controller 1 and controller 2 as 'listeners'. The device adds listener entries for controller 1 and controller 2.
5. When parameter A is updated, either via a regular meter update or a request from one of the controllers, parameter A is added, with its value, to each of the listeners' (controller 1 and controller 2) parameter lists.
6. Every time interval (the duration is dependent on what the controller set) , a listener's parameter list is transmitted to the listener (in our case ID of the single parameter A and its value will be sent to the listener - controller 1 or controller 2).

Claims

1. A method for exchanging device parameters between at least two devices connected with each other via a data connection,
wherein a first requesting device sends a request message comprising a structured list of parameter addresses to a second device which generates in response to the received request message a structured list comprising parameter values of the requested device parameters and sends the generated structured list to the first device.
2. The method according to claim 1,
wherein the parameter address contains a wild card.
3. The method according to claims 1 or 2,
wherein the parameter address is a hierarchical parameter address.
PCT/EP2011/055106 2010-04-01 2011-04-01 A universal snap group (usg) mechanism WO2011121111A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US32002210P 2010-04-01 2010-04-01
US61/320,022 2010-04-01

Publications (1)

Publication Number Publication Date
WO2011121111A1 true WO2011121111A1 (en) 2011-10-06

Family

ID=44169193

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2011/055106 WO2011121111A1 (en) 2010-04-01 2011-04-01 A universal snap group (usg) mechanism

Country Status (1)

Country Link
WO (1) WO2011121111A1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1515571A2 (en) * 2003-09-08 2005-03-16 Microsoft Corporation System and method for an OMA DM extension to manage mobile device configuration settings
WO2008028072A2 (en) * 2006-08-30 2008-03-06 Hewlett-Packard Development Company, L.P. Electronic device management
WO2009043762A2 (en) * 2007-10-04 2009-04-09 U-Man Universal Media Access Networks Gmbh Digital multimedia network with hierarchical parameter control protocol

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1515571A2 (en) * 2003-09-08 2005-03-16 Microsoft Corporation System and method for an OMA DM extension to manage mobile device configuration settings
WO2008028072A2 (en) * 2006-08-30 2008-03-06 Hewlett-Packard Development Company, L.P. Electronic device management
WO2009043762A2 (en) * 2007-10-04 2009-04-09 U-Man Universal Media Access Networks Gmbh Digital multimedia network with hierarchical parameter control protocol

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
FOSS RICHARD ET AL: "An Integrated Connection Management and Control Protocol for Audio Networks", AES CONVENTION 127; OCTOBER 2009, AES, 60 EAST 42ND STREET, ROOM 2520 NEW YORK 10165-2520, USA, 9 October 2009 (2009-10-09), XP040509221 *

Similar Documents

Publication Publication Date Title
JP7454662B2 (en) Information transmission method, device, readable storage medium and electronic device
EP2723024B1 (en) Method, device and system for sharing microblog message
EP2563062B1 (en) Long connection management apparatus and link resource management method for long connection communication
CA2869505C (en) Method and system for group communication, group server, and group member device
CN102938770B (en) A kind of method and relevant apparatus, system realizing multi-protocols message unified interface
JP2018536226A (en) Data transmission method and apparatus
US9800488B2 (en) Method for setting heartbeat timer, terminal and server
CN104346198B (en) Information processing unit, server unit, information processing method and storage equipment
CN112217649A (en) Terminal equipment management method, server and terminal equipment
CN101262371A (en) Configuration method and device of network devices
CN113824594B (en) Message sending method and device
US8578212B2 (en) Remote communication system and method
WO2011121111A1 (en) A universal snap group (usg) mechanism
CN114374705A (en) Service cluster and message push method
JP2011234345A (en) Method of extracting object from dm client and device management system associated therewith
CN103347067B (en) A kind of Long-distance Control reconstructing method and system
JP4350640B2 (en) Terminal device
EP2369496B1 (en) Method, system and apparatus for propagating data change notifications
JP4884350B2 (en) Supervisory control system
WO2025008847A1 (en) System and method for managing stale session in wireless network
JP2006033681A (en) Network control device, usage status monitoring server and program thereof
JP2003323213A (en) Notification system
CN116467143A (en) State updating method and device
TWI252002B (en) Method and apparatus for signaling virtual channel support in communication networks
JP3885050B2 (en) Network management method

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11716850

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11716850

Country of ref document: EP

Kind code of ref document: A1