Specification
METHOD FOR MANAGING A COMMUNICATION BETWEEN A SERVER DEVICE AND A CUSTOMER DEVICE
The present Invention relates to a method for managing a communication between a server device and a customer device, and such a server device and a customer device.
Such a method is known from the DSL-Forum that has defined the Customer Premises Equipment Wide area Network Management Protocol, shortly called the WAN Management Protocol in the Technical Report TR-69. This TR069 Management Protocol is intended for communication between Customer Premises Equipment and an Auto-Configuration Server, shortly called an ACS. The version of May 2004 of this Technical Report TR-69 is to be found at www.dslforum.org.
This document describes at page 9, paragraph 1.6 the commonly used terminology. The following definitions are relevant for the further reading of this applications.
The ACS is on auto-configuration Server, as the component in a broadband network responsible for auto-configuration of the CPE for advanced services. The CPE is the Customer Premises Equipment whereby a B-NT is a broadband access CPE device capable of being managed by and ACS and being one form of a broadband CPE.
An RPC is a remote procedure call, whereby a "parameter" defines a name-value pair representing a manageable CPE parameter mode accessible to on ACS for reading and/or writing.
In this way the TR069 -Management Protocol defines a mechanism that encompasses secure auto-configuratlon of a CPE, and also incorporates other CPE management functions into a common framework. The TR069-Management protocol makes use of these Remote Procedure Calls - RPC Methods that defines a generic mechanism by which an ACS con read (get) or write (set) Parameters to configure a CPE and monitor CPE status and statistics.
At page 12 paragraph 2.3.1 the Parameters are discussed more in details. There it is described that an RPC Method Specification defines
a generic mechanism by which on ACS can read or write Parameters to configure a CPE and monitor CPE status and statistics. Each parameter 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 may be defined as read-write. For some predefined objects, multiple instances may be defined. The individual instances ore identified by an index number, assigned by the CPE.
A method is described for managing a communication between a server device e.g. an ACS and a customer device e.g. a CPE that comprises the step of:
- at one of the devices e.g. the ACS, comprises a parameter description for a parameter name in a parameter message e.g. a GET message. The parameter description consists of an hierarchical tree-like structure of characters with each' level separated by a predefined character (dot); and
- transmitting the parameter message to the other one of the devices e.g. to the CPE; and
- reading and/or writing by the other one of the devices the parameter description for configuring and/or monitoring of one or more parameters of the other one of the devices.
It has to be explained that this step of reading and/or writing is described in the TR-069 document at page 12 in paragrapti 2.3.1 that describes the parameters. There it is explained that the parameters may be defined as read-only or read-write. Read-only Parameters may be used to allow an ACS to determine specific CPE characteristics, observe the current state of the CPE, or collect statistics. Writeable Parameters allow an ACS to customize various aspects of the CPE's operation. All writeable Parameters must also be readable. The value of some writeable Parameters may be independently modifiable through means other than the interface defined in this specification (e.g. some
Parameters may also be modified via a LAN side auto-configuration protocol).
In this way the protocol supports a discovery mechanism that allows and ACS to determine what Parameters a particular CPE supports, allowing definition of optional parameters as well as supporting straightforward addition of future standard Parameters.
An example of a parameter is hereafter described in an abstract way. The name of the parameter is called e.g. "C". Presume there are 2 values for C existing on the CPE device. The ParameterValue pairs on the device are then e.g.:
1)
A.B.C.l.Dl=VaLDl]
A.B.C.l.D2=VaLD12
A.B.C.1.D3=VaLD13
A.B.C.l.D4=VaLD14
2)
A.B.C.lO.Dl=VaLD101 A.B.C.10.D2=VaLD102 A.B.C.10.D3=VaLD103 A.B.C.10.D4=VaLD104
In the event when the ACS is interested in the name of "C", but however,
doesn't know the number of "C" instances, the ACS can retrieve the
information according to two 2 ways which are described her below.
1) A first way to retrieve the parameters, the RPC-method
„GetParameterValues" is used, but since the ASC doesn't know the
number of instances in the array, a method with two steps with dynamic
arrays is used.
Firstly the ACS sends the message "GetParameterNames" with next level
on true:
GetParameterNamesC'A.B.C", nextLevel=true)
Hereby the CPE sends the response with:
GetParameterNamesResponse("A.B.C.l","A.B.C.10").
In a second step, with this received response from the CPE, the ACS can construct the message GetParameterValues and transmits this request again to the CPE:
GetParameterValuesC'A.B.C.l .Dl ","A.B.C.10.D1"), The CPE generates the response: .
GetParameterValuesResponse('A.B.C.l.Dl","VaLDll",'A.B. C .10. Dl" , " VaLDlOl").
A drawback of this first approach is that the ACS only learns the answers after two roundtrips of question/answer.
2) A second way to obtain the parameter values is immediately with the
message GetParameterValues but with an incomplete path:
GetParameterValues("A.B.C.").
The response from the CPE comprises:
GetParameterValuesResponse('A.B.C.l.Dl"," VaLDl 1", "A.B.C.l.D2","VaLD12",
"A.B.C.
1.D3","VaLDl3",A.B.C.l.D4","VaLDl4","A.B.C.l0.D1","VaLDl0l","A.B.C.l0.D2","Val
_D102",A.B.C.10.D3","VaLD103",A.B.C.10.D4","VaLD104")
A drawback of this second approach is that the ACS receives too much information besides the values for the distinct parameters it needed to know.
So, the existing solutions provide a lot of load over the network and generate implementation complexity on the ACS. Since the ACS is dealing with millions of devices, scalability becomes with these solutions a concern in any ACS implementation. Latency and too much response time are introduced.
An object of the present invention is to provide a method for managing a communication between a server device and a customer device, and such a server device and a customer device, as described above but that ensures less load over the network and lower latency and reduction of response time.
-5-
According to the invention, this object is achieved due to the fact that the present method comprises a step of including firstly by the one of the devices e.g. by the ACS in the parameter description between two of the predefined characters (dot) a predefined wildcard character that substitutes other characters of one or more levels and that thereby defines with the global parameter description according to predefined rules one or more of the parameters. Furthermore, when reading and/or writing by the other one of the devices e.g. by the CPE the parameter description defines the exact set of one or more parameters of the CPE that is to be configured and/or monitored.
By introducing a wildcard character i.e. a character that substitutes for other characters in this regular expression, such as e.g. "*" which means "all", or "**" which means "do not care" or "?" which means "any character", the number of messages needed for having the information that the ACS needs is reduced. Some examples of possible wildcards are provided with its meaning:
"*" to be used between two dots boarding a same level and with the meaning : Undefined number of any characters except"."
Or
"**" to be used between two dots boarding more then one level with the meaning : Undefined number of any characters
Or
"?" to be used between two dots boarding a same level and with the meaning : one or any character
The provided solution will now be further explained based upon the above-mentioned abstract example.
The solution of the present application will now be made clear based upon the same example as provided above. A) Example with "*":
The ACS is interested in the name of "C", and doesn't know the number of "C" - files. ACS is sending the message to CPE: GetParameterValues("A.B.C.*.Dl")
The CPE must now response with all elements defined: GetParameterValuesResponse{"A.B.C.l.Dl";Val_Dll","A.B.C.10.Dl","Val_D10T'
);
B) Example with "**":
The ACS is interested in the name of "C", and doesn't know the number
of "C"-files. ACS is sending the message to CPE:
GetParameterValues{"A.B.**.D 1")
The CPE must now response with all elements defined:
GetParameterValuesResponse("A.B.C.l.Dl";'Val_Dll","A.B.C.10.DT',"Val
_D11"C) Example with"?":
The ACS is interested in the name of the "C", and doesn't know the
number of "C"-files. The ACS is sending the message to CPE:
GetParameterValues("A.B.C.?.Dl")
The CPE must now response with all elements defined. The "?" will be
replaced
by one'character and only one character:
GetParameterValuesResponse("A.B.C.l.Dl","VaLDll");
D) Example with"??":
The ACS is interested in the name of the "C", and doesn't know the
number of "C"-files. The ACS is sending the message to CPE:
GetParameterValues("A.B.C.??.D1")
And the response will be:
GetParameterValuesResponse("A.B.C.l.Dl","VaLDn",A.B.C.10.DT',"Val_
DIOT');
In this way, by defining wildcards to replace in a "get" or "set" -message one or more levels between a "dot" of the hierarchical structure of the parameter-name in the message and by making use of wildcards, the number of messages needed for having the information that you need is reduced.
Indeed, as mentioned in the above paragraph, it has to be explained that the implementation of the above described parameter message is not limited to a GET message whereby e.g. the ACS is
requesting parameter values for one or more parameters of the CPE by using a parameter description that comprises a wildcard, but might as well be implemented by a SET message whereby e.g. the ACS is imposing parameter values for one or more parameters of the CPE by using a parameter description that comprises a wildcard i.e. configuration of one or more parameters of the CPE by using a parameter description that comprises a wildcard.
A further characterizing embodiment of the present is provided when the server device is implemented by an Auto-configuration server and the customer device is implemented by a customer Premises equipment device and when the communication is a Remote Procedure call according to the TR069 Technical Report of the DSL Forum.
Furthermore, as described above, the predefined wildcard character can be defined to substitute only one character level.
It is to be noticed that the term 'conhprising', used in the claims, should not be interpreted as being limitative to the means listed thereafter. Thus, the scope of the expression 'a device comprising means A and B' should not be limited to devices consisting only of components A and B. It means that with respect to the present invention, the only relevant components of the device are A and B.
Similarly, it is to be noticed that the term 'coupled', also used in the claims, should not be interpreted as being limitative to direct connections only. Thus, the scope of the expression 'a device A coupled to a device B' should not be limited to devices or systems wherein an output of device A is directly connected to an input of device B. It means that there exists a path between an output of A and an input of B which may be a path including other devices or means.
The above and other objects and features of the invention will become more apparent and the invention itself will be best understood by referring to the following description of an embodiment taken in conjunction with the accompanying drawings wherein the Figure
-8-
represents Customer Premises Equipment CPE and a Auto configuration Server ACS in an Access Communication Network.
The working of the device according to the present invention in accordance with its telecommunication environment that is shown in the Figure-will also be explained by means of a functional description of the different blocks shown therein. Based on this description, the practical implementation of the blocks will be obvious to a person skilled in the art and will therefore not be described in details.
It has to be explained that this actual method con be applied in two directions i.e. from the ACS to the CPE and from the CPE to the ACS. However, in order not to overload this description, the method will only be described in the direction from the ACS towards the CPE as starting point.
The ACS comprises a Questioner Q that is coupled to an Includer INC and to a Compriser COMP_ACS. The Questioner Q provides an input to the Includer INC and to the Compriser COMP_ACS. This input comprises the desired parameter information request. This parameter information request can be implemented by e.g. a request for a name of one or more parameters, or a request for the value of one or more parameters, or a request for the setting of one or more parameters with a predefined parameter value. As an example it is preferred to introduce the question "Q: Vol for Dl of all C ?". This means that the ACS requires the Value for the Dl character-level of all C character-levels.
The Includer INC generates a parameter description based upon the required parameter information. The parameter description consists of an hierarchical tree-like structure of characters e.g. A, B, C, and/or Dl with each level separated by a predefined character "." (dot). A parameter description identifies hereby one or more parameter names in a parameter message such as e.g. a GET message. It has to be explained that as a matter of example the predefined character is implemented by a "." (dot). However, it has to be clear that other kinds of predefined characters might as well be used to separate the different
-9-
levels of characters of the hierarchical tree such as e.g. a "," (comma) or a "?" question-mark etc.
However, in the event when the Includer doesn't know the number of instances of one or more of the character-levels, it is not enabled to include the list of parameters for-which a value is requested. According to the know methods the ACS should firstly request the CPE for these names. Referring to the Example, the ACS doesn't know the total hierarchical character tree for the following parameters A.B.C.l.Dl or A.B.C.lO.Dl since the ACS doesn't know the number of instances of C being, according to this example the two instances "1" and "10". So, when the global character-tree is not knows the Includer INC includes according to the present application, in the parameter description, between two of the predefined characters (dot) that separate the different levels of the hierarchical tree of characters, a predefined wildcard character. This predefined wildcard character substitutes hereby one or more characters of one or more levels and defines thereby with the parameter description according to predefined rules one or more parameters. Referring to the example, since the Includer INC doesn't know the number of instances of the C character, "A.B.C.?.D1", it includes in the parameter description, between two of the predefined characters (dot) that separate the different levels of the hierarchical tree of characters, a predefined wildcard character "*" ==> "A.B.C.*.D1". This predefined wildcard character "*" substitutes in this example the "instance-number of C"-character and defines thereby with the parameter description "A.B.C.*.D1" according to predefined rules one or more parameters i.e. all parameters, including the hierarchical tree up fo the level of Dl, for each existing C instance.
It has to be remarked here that this actual example, wherein the complete character tree name is not known for the ACS, is not the only situation whereby a wildcard can be introduced. Indeed, also in other situations when e.g. the ACS desires to configure one or more parameters of the CPE with predefined values, and whereby the ACS
-10-
l
Documents
Application Documents
| # |
Name |
Date |
| 1 |
2741-chenp-2009 power of attorney 15-05-2009.pdf |
2009-05-15 |
| 1 |
2741-CHENP-2009-AbandonedLetter.pdf |
2017-07-20 |
| 2 |
2741-CHENP-2009-FER.pdf |
2016-10-31 |
| 2 |
2741-chenp-2009 pct search report 15-05-2009.pdf |
2009-05-15 |
| 3 |
2741-chenp-2009 pct 15-05-2009.pdf |
2009-05-15 |
| 3 |
2741-chenp-2009 abstract 15-05-2009.pdf |
2009-05-15 |
| 4 |
2741-chenp-2009 form-5 15-05-2009.pdf |
2009-05-15 |
| 4 |
2741-chenp-2009 claims 15-05-2009.pdf |
2009-05-15 |
| 5 |
2741-chenp-2009 form-3 15-05-2009.pdf |
2009-05-15 |
| 5 |
2741-chenp-2009 correspondence others 15-05-2009.pdf |
2009-05-15 |
| 6 |
2741-chenp-2009 form-2 15-05-2009.pdf |
2009-05-15 |
| 6 |
2741-chenp-2009 description (complete) 15-05-2009.pdf |
2009-05-15 |
| 7 |
2741-chenp-2009 form-18 15-05-2009.pdf |
2009-05-15 |
| 7 |
2741-chenp-2009 drawings 15-05-2009.pdf |
2009-05-15 |
| 8 |
2741-chenp-2009 form-1 15-05-2009.pdf |
2009-05-15 |
| 9 |
2741-chenp-2009 form-18 15-05-2009.pdf |
2009-05-15 |
| 9 |
2741-chenp-2009 drawings 15-05-2009.pdf |
2009-05-15 |
| 10 |
2741-chenp-2009 description (complete) 15-05-2009.pdf |
2009-05-15 |
| 10 |
2741-chenp-2009 form-2 15-05-2009.pdf |
2009-05-15 |
| 11 |
2741-chenp-2009 form-3 15-05-2009.pdf |
2009-05-15 |
| 11 |
2741-chenp-2009 correspondence others 15-05-2009.pdf |
2009-05-15 |
| 12 |
2741-chenp-2009 form-5 15-05-2009.pdf |
2009-05-15 |
| 12 |
2741-chenp-2009 claims 15-05-2009.pdf |
2009-05-15 |
| 13 |
2741-chenp-2009 pct 15-05-2009.pdf |
2009-05-15 |
| 13 |
2741-chenp-2009 abstract 15-05-2009.pdf |
2009-05-15 |
| 14 |
2741-CHENP-2009-FER.pdf |
2016-10-31 |
| 14 |
2741-chenp-2009 pct search report 15-05-2009.pdf |
2009-05-15 |
| 15 |
2741-CHENP-2009-AbandonedLetter.pdf |
2017-07-20 |
| 15 |
2741-chenp-2009 power of attorney 15-05-2009.pdf |
2009-05-15 |
Search Strategy
| 1 |
searchstr2741che_17-10-2016.pdf |