The invention relates to a method for managing a communication between a server device and a customer device, which method comprises the step of
Examples of such a method are protocols, an example of such a server device is an auto configuration server, and an example of such a customer device is a customer premises equipment.
US 2006/0120305 A1 discloses a remote management method and an auto configuration server. US 2006/0075118 A1 discloses a system for exchanging messages between customer devices and servers.
A prior art method is of common general knowledge. A management protocol for example manages a communication between a customer device (CPE) and a server device (auto configuration server or ACS). The management protocol defines a mechanism that for example encompasses secure auto configuration of a CPE, and may further incorporate other CPE management functions into a common framework. The management protocol can make use of RPC methods which define a generic mechanism by which an ACS can read or write parameters to configure a CPE and monitor a CPE status and its statistics. Each parameter for example consists of a name-value pair. The name identifies the particular parameter, and has a hierarchical structure similar to files in a directory, with each level separated by a “.” (dot). The value of a parameter may be one of several defined data types. Parameters may be defined as read-only or read-write.
A problem exists in that there may be no description of the type of the parameter, except if the parameter is standardized, then the type is described, but may not be available from the object model itself. This means that there is no way a new non-standardized object model can be discovered and dynamically uploaded from the customer side to the server side. When going for service management via the management protocol, this is a problem in the business model of multi service provider management. Each service provider can and will create own services and applications. Such application-related parameters won't be standardized as it is today the case for device-dependent parameters. A discovery of services offered by bundles of other service providers should not destroy the value of a service platform that offers the services of bundles to other bundles. For example in case a first service provider has created a bundle, which offer its services to the service platform, and a second service provider enters the service platform, then in order to allow the bundles of the second service provider to make use of the bundles of the first service provider, the second service provider must be able to see and understand, and to keep track of the change of the bundles of the first service provider, even in case the second service provider is not allowed to manage the bundles of the first service provider.
It is an object of the invention, to provide a method as defined above that allows an arbitrary parameter to be introduced.
The method according to the invention is characterized in that the method comprises the step of
By creating an attribute comprising an extended markup language scheme for defining the parameter, an arbitrary parameter can be introduced, and said one of the devices can read and/or write even a completely new parameter for configuring and/or monitoring the other one of the devices.
The method according to the invention is further advantageous, inter alia, in that it is more flexible and offers more possibilities.
An embodiment of the method according to the invention is characterized in that said one of the devices is linked to a northbound interface and a southbound interface, the creating step being performed via the southbound interface. Said one of the devices is linked via the northbound interface to for example a service provider and via the southbound interface to for example the customer device.
An embodiment of the method according to the invention is characterized in that the extended markup language scheme defines a type of the parameter and/or a description of the type of the parameter and/or a description of the parameter and/or metadata of the parameter. This embodiment discloses several ways of how to define the parameter.
An embodiment of the method according to the invention is characterized in that the parameter is a non-standardized parameter comprising a name and a value. Especially non-standardized parameters could not be used in a prior art situation and can now be used advantageously in a situation according to the invention.
An embodiment of the method according to the invention is characterized in that the server device is an auto configuration server and the customer device is a customer premises equipment and the method is a TR069 protocol.
An embodiment of the method according to the invention is characterized in that the method further comprises the step of
An embodiment of the method according to the invention is characterized in that the method further comprises the step of
The invention also relates to a computer program product for performing the steps of the method as defined above.
The invention also relates to a medium for storing and comprising the computer program product as defined above.
The invention also relates to an apparatus for managing a communication between a server device and a customer device, which apparatus is one of the devices and comprises
An embodiment of the apparatus according to the invention is characterized in that said apparatus is linked to a northbound interface and a southbound interface, the attribute reading and/or writing means being linked to the southbound interface.
An embodiment of the apparatus according to the invention is characterized in that the extended markup language scheme defines a type of the parameter and/or a description of the type of the parameter and/or a description of the parameter and/or metadata of the parameter.
An embodiment of the apparatus according to the invention is characterized in that the parameter is a non-standardized parameter comprising a name and a value.
An embodiment of the apparatus according to the invention is characterized in that the server device is an auto configuration server and the customer device is a customer premises equipment and the managing of the communication is in accordance with a TR069 protocol.
Preferably, the apparatus according to the invention further comprises
Further preferably, the apparatus according to the invention further comprises
Embodiments of the computer program product according to the invention and of the medium according to the invention and of the apparatus according to the invention correspond with the embodiments of the method according to the invention.
The invention is based upon an insight, inter alia, that it should be possible to introduce a new parameter without needing to standardize it, and is based upon a basic idea, inter alia, that an attribute comprising an extended markup language scheme for defining the parameter is to be introduced and/or used.
The invention solves a problem, inter alia, to provide a method as defined in the preamble that allows an arbitrary parameter to be introduced. The method according to the invention is further advantageous, inter alia, in that it is more flexible and offers more possibilities.
These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments(s) described hereinafter.
The system shown in the
In a prior art situation, a management protocol such as TR069 manages a communication between a customer device 11, 12, 13 such as a customer premises equipment and a server device 30 such as an auto configuration server. The management protocol defines a mechanism that for example encompasses secure auto configuration of the customer device 11, 12, 13, and may further incorporate other customer device management functions into a common framework. The management protocol can make use of RPC methods which define a generic mechanism by which the server device 30 can read or write parameters to configure the customer device 11, 12, 13 and monitor a customer device status and its statistics. Each parameter for example consists of a name-value pair. The name identifies the particular parameter, and has a hierarchical structure similar to files in a directory, with each level separated by a “.” (dot). The value of a parameter may be one of several defined data types. Parameters may be defined as read-only or read-write.
A problem exists in that there may be no description of the type of the parameter, except if the parameter is standardized, then the type is described, but may not be available from the object model itself. This means that there is no way a new non-standardized object model can be discovered and dynamically uploaded into the server device 30 via the southbound interface 31, 32. When going for service management via the management protocol, this is a problem in the business model of multi service provider management. Each service provider can and will create own services and applications. Such application-related parameters won't be standardized. A discovery of services offered by bundles of other service providers should not destroy the value of a service platform that offers the services of bundles to other bundles.
According to the invention, to be able to allow an arbitrary parameter to be introduced, a method comprises the steps of
By creating an attribute comprising an extended markup language scheme for defining the parameter, an arbitrary parameter can be introduced, and said one of the devices 11, 12, 13, 30 can read and/or write even a completely new parameter for configuring and/or monitoring the other one of the devices 11, 12, 13, 30. Such a method is more flexible and offers more possibilities.
Preferably, said one of the devices 30 is linked to a northbound interface 33 and a southbound interface 31, 32, the creating step being performed via the southbound interface 31, 32. Said one of the devices 30 is linked via the northbound interface 33 to for example a service provider 40 or a service configuration manager 40 and via the southbound interface 31, 32 to for example the customer device 11, 12, 13.
Preferably, the extended markup language scheme defines a type of the parameter and/or a description of the type of the parameter and/or a description of the parameter and/or metadata of the parameter. This embodiment discloses several ways of how to define the parameter.
Preferably, the parameter is a non-standardized parameter comprising a name and a value. Especially non-standardized parameters could not be used in a prior art situation and can now be used advantageously in a situation according to the invention.
An example of an XML scheme is as follows:
An example on how the XML scheme will be used is as follows:
The invention also relates to an apparatus 11, 12, 13, 30 for managing a communication between a server device 30 and a customer device 11, 12, 13, which apparatus 11, 12, 13, 30 is one of the devices 11, 12, 13, 30 and comprises
Preferably, said apparatus 30 is linked to a northbound interface 33 and a southbound interface 31, 32, the attribute reading and/or writing means 90 being linked to the southbound interface 31, 32.
Preferably, the extended markup language scheme defines a type of the parameter and/or a description of the type of the parameter and/or a description of the parameter and/or metadata of the parameter.
Preferably, the parameter is a non-standardized parameter comprising a name and a value.
Preferably, the server device 30 is an auto configuration server and the customer device 11, 12, 13 is a customer premises equipment and the managing of the communication is in accordance with a TR069 protocol.
Thereto, as shown in the
The processor/memory 90 is linked via a southbound interface 31 to the processor/memory 80 and via a southbound interface 32 to the processor/memory 70. Each processor/memory 70, 80, 90 may be means for reading and/or writing a parameter for configuring and/or monitoring the other one of the devices, and may be means for, for the parameter, reading and/or writing an attribute comprising an extended markup language scheme for defining the parameter.
So, instead of having a new object model dump via the northbound interface 33 by a service provider, which works for a single service provider management of the home network, but not for a multi service provider management model, the new object model is automatically discovered via the southbound interface 31, 32 (and does no longer require an action from the service provider). The correct object model is then created. This concept allows the home network to be managed by different service providers. Detection and creation of a new object via the southbound interface 31, 32 is further important for LAN services management. It also makes a business model of multi ACS management possible.
The system shown in the
According to another aspect of the invention, a method comprises the step of
Preferably, the method further comprises the step of
According to this other aspect of the invention, an apparatus further comprises
Preferably, the apparatus further comprises
About this other aspect, the following is observed. In recent years, the home network evolved from a single personal computer connected to the Internet to a full-fledged local area network, interconnecting numerous different devices. With the increasing popularity of the Internet, the number of home devices that are able to communicate using the IP protocol increased dramatically. In the early days, only personal computer devices such as desktop computers, laptops and palmtops were able to access the Internet over the IP protocol. Nowadays, other electronic devices such as hard-disk recorders, camcorders, TV set-top-boxes, etc. are able to access an IP network, allowing the consumer to configure them by means of for example a web interface. Furthermore, other devices in the home such as white goods and domotica applications are making the leap towards the IP network as well.
Because managing this plethora of devices over the home network becomes a challenging task, many efforts are being undertaken to find a common solution. Driven by the requirements of the service providers (e.g., DSLforum, OMA, etc.), the remote management of the home network has become a hot topic. This way, the service provider is able to remotely configure certain devices in the home in order to increase the quality of its offered service and relieve the customer of some difficult and repetitive management tasks.
One of the services that may be offered by the service provider is the remote configuration of the home network by the customer. The service provider offers a centralized platform through which the customer can access the home devices. For example, when the customer is abroad, he/she may use a web browser to access the web server of the service provider in order to get an overview of all managed devices in his/her home network. Throughout this web interface, certain configuration tasks can be performed. For example, the customer may decide the home alarm should be switched on, so he/she will access the appropriate device using the web browser so detailed information on the alarm settings is presented. One of the remaining problems is the visualization of these configuration settings. Because every device requires different settings and is configured in a specific way, a single generic graphical management interface will not suffice.
There mainly exist two different approaches to remotely configure devices in the home network. Unfortunately, they both have drawbacks that make them unsuitable to offer a user-friendly service.
I) Without a home service management platform (HSM): In this case, each home device is accessed directly without the use of a centralized platform. For example, the customer may browse to the web interface of the device that needs to be configured. Therefore, he/she needs to know the IP address of every possible device in the home network. Furthermore, the home firewall/NA(P)T needs to be configured correctly in advance in order to forward the request to the right device. Off coarse, the device needs to run a web server in order to allow remote configuration. Besides these drawbacks, security issues may arise when each individual device should be able to access the Internet independently and in an uncoordinated way.
II) With a home service management platform (HSM): Using a HSM, a service provider offers a remote management service to the home network. To do so, remote management protocols such as TR-069 or OMA-DM may be used. When abroad, the customer goes to the centralized HSM in order to access the home network and get an overview of all home devices or services. Once the appropriate device or service is selected, the customer can configure it. Even though this approach has some major advantages (e.g., centralized access to the home, overview of all managed devices, security can be provided by the service provider etc.), the remote management protocols do not provide enough information to offer a user-friendly device configuration. The TR-069 protocol for example configures devices by means of getting and setting certain parameters of the device. Parameters are defined as name-value pairs, which do not provide any information on the meaning of the parameter. The HSM does not know what the parameters means and the user can only guess the impact of changing the parameter on the device configuration. Currently, the only solution to provide remote management of home devices throughout a HSM, is by presenting the customer a text-based list of parameters that can be changed. A graphical Web interface is only possible if the HSM is configured with the layout of the Web page (and the mapping to the parameters) for every possible type and brand of all existing devices.
The idea to solve the previous problems is to export the graphical user or web interface over the remote management protocol (e.g., TR-069 or OMA-DM) from the home device to HSM. This means that the remote management protocol will be extended with information describing the graphical interface needed to configure devices. For example, the TR-069 protocol requires an object model (parameter tree) for every device. This object model lists all parameters (read/write) to configure the device. The idea is to include metadata for each parameter that describes its meaning and the way it should be depicted in a graphical user interface (GUI). The metadata for the object model can for example be defined by means of an XML schema, as follows:
As an example the object model for a simple light switch (dimmer) that regulates the intensity of a spotlight is shown. The object model may contain a parameter indicating the switch is turned on or off, and a parameter indicating the intensity of the light. The XML schema to provide hints for creating a graphical user interface may define that the first parameters needs to depicted as an on/off switch, while the second parameter needs to be depicted as a rotational wheel with values ranging from 0 to 10 in steps of 1.
Using the graphical user interface extension of the remote management protocol, the HSM may communicate this graphical user interface information through its northbound interface to a web server, which hosts the web page for the device that needs to be configured. Based on the received graphical user interface information from the HSM, the web server creates the web page and provides it to the customer. The layout of this page can be based on a proprietary template, which is defined by the service provider.
In the
In
The expression “for” in for example “for managing” etc. does not exclude that other functions are performed as well, simultaneously or not. The expressions “X coupled to Y” and “a coupling between X and Y” and “coupling/couples X and Y” etc. do not exclude that an element Z is in between X and Y. The expressions “P comprises Q” and “P comprising Q” etc. do not exclude that an element R is comprised/included as well. The terms “a” and “an” do not exclude a possible presence of one or more pluralities.
The steps and/or functions of reading and/or writing etc. do not exclude further steps and/or functions, like for example, inter alia, the steps and/or functions described for the Figures etc.
Number | Date | Country | Kind |
---|---|---|---|
06291863.6 | Nov 2006 | EP | regional |