The present invention relates to a method and apparatus for communicating configuration information to a communications network service that is scaled over a plurality of network nodes. Such a method and apparatus is particularly but not exclusively applicable to a Universal Mobile Telecommunications System having an IP Multimedia Subsystem.
IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
The UMTS (Universal Mobile Telecommunications System) is a third generation wireless system designed to provide higher data rates and enhanced services to subscribers. UMTS is standardised by the 3rd Generation Partnership Project (3GPP). See 3GPP TS 23.002 for more details.
The UMTS architecture includes a subsystem known as the IP Multimedia Subsystem (IMS) for supporting traditional telephony as well as new IP multimedia services (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7). IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS is able to connect to both PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network) as well as the Internet.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. The 3GPP has chosen SIP for signalling between a User Equipment (UE) and the IMS as well as between the components within the IMS.
Specific details of the operation of the UMTS communications network and of the various components within such a network can be found from the Technical Specifications for UMTS that are available from http://www.3gpp.org. Further details of the use of SIP within UMTS can be found from the 3GPP Technical Specification TS 24.229 V8.2.0 (2007-12).
Within the IMS service network, Application Servers (ASs) are provided for implementing IMS service functionality. Generally, Application Servers and core services of an IMS network need to be runtime configurable. In IMS networks with high loads of traffic, Application Servers and core services may have to be scaled over several nodes. When a service is scaled over several nodes, each node will still need to be configured.
A node can, in this context, be one physical server or several physical servers joined in a cluster. Generally each server would be configured independently from a central Network Management Server (NMS), and the applicant has appreciated the desirability of providing a more efficient implementation from a technical perspective.
According to a first aspect of the present invention there is provided a method of communicating configuration information to a network service that is scaled over a plurality of network nodes, comprising designating one of the nodes of the plurality as a master node, providing an XML Document Manager Server, XDMS, function in the master node, arranging for the configuration information to be provided to the XDMS function in the master node, and arranging for the XDMS function in the master node to communicate the configuration information to the non-master nodes, or at least any of the configuration information that is relevant to them, such that configuration can be performed in each node of the plurality based on the configuration information.
The method may comprise notifying each of the non-master nodes of receipt of the configuration information, and subsequently providing the configuration information on request.
The method may comprise subscribing each of the non-master nodes to receive a notification from the XDMS function in the master node following receipt at the master node of the configuration information, for example by using SUBSCRIBE and NOTIFY messages.
The method may comprise using the Session Initiation Protocol, SIP, event notification framework for notifying each of the non-master nodes of receipt at the master node of the configuration information.
The method may comprise using the “xcap-diff” event package relating to the XML Configuration Access Protocol, XCAP.
The method may comprise using an XML Configuration Access Protocol, XCAP, procedure for communicating the configuration information from the XDMS function in the master node to each of the non-master nodes, for example using an XCAP GET message.
The method may comprise, for use in the XCAP procedure, allocating each non-master node its own SIP address and informing it of the root URI to the XDMS function in the master node.
The configuration information may comprise updates to previously-received configuration information.
The XDMS function may be arranged to handle a plurality of different services, and comprising differentiating the services with reference to Application Unique Identifiers, AUIDs, associated with the respective services.
The XDMS function may be arranged to handle a plurality of different nodes/users, and comprising differentiating the nodes/users with reference to XCAP User Identifiers, XUIs, associated with the respective nodes/users, optionally also with reference to a document name associated with the node/user.
The master node may comprise a plurality of nodes.
The configuration information may comprise performance and/or fault management information.
The network service may be provided in an IMS network.
According to a second aspect of the present invention there is provided a method of configuring a network service that is scaled over a plurality of network nodes, comprising using a method according to the first aspect of the present invention to communicate configuration information to the nodes, and configuring the nodes in dependence upon that information.
According to a third aspect of the present invention there is provided a system of network nodes arranged to provide a network service, the system comprising an XML Document Manager Server, XDMS, function provided in one of the nodes, the XDMS function being arranged to receive configuration information relating to the network service on behalf of all nodes of the system, the XDMS function being further arranged to communicate the configuration information to the other nodes of the system, or at least any of the configuration information that is relevant to them, such that configuration can be performed in each node of the system based on the configuration information
According to a fourth aspect of the present invention there is provided an apparatus for use as or in a node of a network service that is scaled over a plurality of nodes, the apparatus comprising an XML Document Manager Server function arranged to receive configuration information relating to the network service and further arranged to communicate the configuration information to the other nodes of the network service, or at least any of the configuration information that is relevant to them, such that configuration can be performed in each node of the plurality based on the configuration information.
According to a fifth aspect of the present invention there is provided an apparatus for use as or in a node of a network service that is scaled over a plurality of nodes, the apparatus comprising an XML Document Manager Client function, the XML Document Manager Client function being arranged to receive configuration information from an XML Document Manager Server function provided in another node of the network service, and to arrange for a configuration of the node to be performed based on the received configuration information.
According to a sixth aspect of the present invention there is provided a program for controlling an apparatus to perform a method according to the first or second aspect of the present invention or which, when loaded into an apparatus, causes the apparatus to become a system or an apparatus according to the third, fourth or fifth aspect of the present invention. The program may be carried on a carrier medium. The carrier medium may be a storage medium. The carrier medium may be a transmission medium.
According to a seventh aspect of the present invention there is provided an apparatus programmed by a program according to the sixth aspect of the present invention.
According to an eighth aspect of the present invention there is provided a storage medium containing a program according to the sixth aspect of the present invention.
An embodiment of the present invention has an advantage associated with it in addressing an issue mentioned above.
As mentioned above, in a scenario in which a service in an IMS network is scaled over several nodes, where a node may be one physical server or several physical servers joined in a cluster, each node needs to be configured and also subsequently re-configured with configuration updates. There is currently no standard for how to spread configuration changes over several nodes; each server is generally configured independently from a central Network Management Server (NMS), and configuration data are duplicated in each server.
The Open Mobile Alliance (OMA) Architecture Document “XML Document Management Architecture” (OMA-AD-XDM-V2—0, currently at OMA-AD-XDM-V2—0-20080617-D) describes the features and architecture of the “XML Document Management enabler” as follows.
“The XDM enabler defines a common mechanism that makes user-specific service-related information accessible to the service enablers that need them. Such information is expected to be stored in the network where it can be located, accessed and manipulated (e.g. created, changed, deleted, etc.). XDM specifies how such information will be defined in well-structured XML documents, as well as the common protocol for access and manipulation of such XML documents.
The XDM Specification [“XML Document Management (XDM) Specification” from the Open Mobile Alliance, OMA-TS-XDM_Core-V2—0, currently at OMA-TS-XDM_Core-V2—0-20080606-D] defines the features of the XDM enabler, which include the following:
Documents accessed and manipulated via XCAP are stored in logical repositories in the network, called XDMS. Each repository may be associated with a functional entity which uses its data to perform its functions.
Each XML document stored in an XDMS is described as an XCAP Application Usage, which enables applications to use the document via XCAP. The XDM enabler describes Application Usages which can be reused by multiple enablers and are stored in the Shared XDMSs, of which there are four types: Shared List XDMS, Shared Group XDMS, Shared Policy XDMS and Shared Profile XDMS. The documents supported by these XDMSs are as follows:
In addition to above documents the XDM Enabler also defines the Extended Group Advertisement.
Due to the reusable nature of the XDM enabler, there will be interactions with other service enablers, and therefore, the architectural design of the XDM enabler accommodates the needs of those enablers.”
The XML Document Manager (XDM) provides an architecture for managing service specific data. The XML Document Management defines a common mechanism that makes user-specific service-related information accessible to the service enablers that need them. The service-specific information is expressed and exchanged by means of XML documents, and this information is stored in the network where it can be located, accessed and manipulated (created, changed, deleted, etc.). The network entity assumed responsible for storing and manipulation of such information is the XDM Server (XDMS).
An embodiment of the present invention provides a method of communicating configuration changes to a network service that is scaled over a plurality of network nodes. One of the nodes of the service is designated as a master node and that master node is provided with an XML Document Manager Server (XDMS) function (referred to herein as the “Config XDMS”). The Config XDMS holds configuration data for all nodes of the scaled service in XML format. The Config XDMS can hold both configuration data that are common for many services/nodes/users, and configuration data that are specific for a particular service/node/user.
Where a configuration update is to be applied to the scaled service, it is arranged that the configuration update is sent to the Config XDMS in the master node, and it is arranged that the Config XDMS in the master node notifies the other nodes (Config XDMS clients) of the configuration update, or at least any parts of the configuration update relevant to them, such that the configuration update can be applied to all nodes as required.
For example, nodes other than the master node can be provided with SIP clients subscribing to changes in the configuration data stored in the Config XDMS. In one particular embodiment of the present invention, the “xcap-diff” SIP event [draft-ietf-sip-xcapevent “An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package”] is used for distribution of configuration data between nodes, and this embodiment is illustrated in
Shown in
According to draft-ietf-sip-xcapevent, a subscriber node signals to the notifier the resources it is interested in getting information. These resource selections are indicated by sending a URI-list to the notifier in a subscription body. The URIs of this list point to a collection, a document or an XCAP component. Relating this to the present embodiment as shown in
For this purpose, configuration is required in the Config XDMS clients (Nodes 2 to 4) to set up node-specific SIP addresses, as well as informing them of the root URI to the Config XDMS (Node 1).
The setting up of the subscriptions is illustrated in
The procedure to be applied for a configuration update is illustrated in
In the above embodiment, configuration of a scaled service is done towards one node of the scaled service, the master node (Node 1). The protocol transporting configuration changes between the NMS and master node (in step P1) can be any protocol, for example Hypertext Transfer Protocol (HTTP), HTTP Secure (HTTPS), XCAP, NETCONF (a network management protocol), Simple Network Management Protocol (SNMP) or Secure Shell (SSH).
The master node (Node 1) implements the Config XDMS and all other nodes of the scaled service (Nodes 2 to 4) implement Config XDMS clients. That is, all nodes of the service apart from the master node retrieve and receive the configuration data from the master node and need not to be separately configured from the NMS. The only configuration needed in the Config XDMS clients in this embodiment is a node-specific SIP address and the root URI to the Config XDMS.
All configuration data can be retrieved from the Config XDMS via XCAP according to standard XCAP procedures (see RFC4825) or subscribed to via SIP according to standard event xcap-diff procedures (see draft-ietf-sip-xcapevent).
An embodiment of the present invention is able to use the IMS/SIP/XCAP standards to configure and spread configuration changes over a scaled network. As mentioned above, one idea is to use the SIP event package ‘xcap-diff’ for distribution of configuration data between nodes. One node (or the OSS itself) is set up as master node with the “Config XDMS” service. The Config XDMS holds data about all nodes (in XML format). Every node, service or service inside a node is configured with a SIP address that is also used as XUI in XCAP and with the XCAP RootURI and SIP address for the master node. Each node has a SIP client and subscribes for changes of the configuration data in the Config XDMS. A node can use XCAP to fetch the full set of configuration data and receive notification of its configuration data via SIP Notify. The Config XDMS may both hold data that is common for many services, nodes or users as well as specific data for each.
An XDMS can handle one or several document types identified by unique Application Unique Identifiers (AUIDs). An XDMS can also handle several instances of a specific document type (AUID) which are identified by the XCAP User Identifier (XUI) and document name. This functionality is according to OMA XML Document Management standard (see OMA-TS-XDM_Core-V2—0-20080606-D) and can be useful for the Config XDMS in an embodiment of the present invention. That is, the service-, node- and user-specific configuration data can be specifically identified by the use of different AUIDs, XUIs and document names.
For example, the Config XDMS can be set up to handle several services. Each service has its specific AUID and each node of a scaled service has its specific config document identified by the AUID for the service and XUI representing the node.
Additionally, if a service has user-specific configuration data this can be specified in a document identified by the AUID for the service and XUI for the user or XUI representing the node and document name specific for the user.
An overview of steps carried out in an embodiment of the present invention, and apparatus for carrying out those steps, is provided in
In step T1, one of the nodes of the scaled service is designated as the Master Node 1. In step T2, the XML Document Manager Server, XDMS, Function 16 is provided in the Master Node 1. In step T3 it is arranged for any configuration information relating to the scaled service to be provided to the XDMS Function 16 in the Master Node 1. In step T4 it is arranged for any received configuration information to be sent onwards to the Non-master Node 2 (or at least any of the configuration information that is relevant to it); this involves setting up the XDM Client Function 26 in the Non-master Node 2 and an associated relationship between the XDMS 16 and XDMC 26, for example a subscription-type relationship, so that the Non-master Node 2 will be informed of any configuration information relevant to it that is received at the Master Node 1. The configuration information may either be sent to all subscribed Non-master Nodes 2 following receipt at the Master Node 1, or notifications can instead be sent to all subscribed Non-master Nodes 2 such that those Non-master Nodes 2 are then able to request the configuration information subsequently from the Master Node 1. The above steps T1 to T4 can be considered to be a setup procedure, carried out under control of the Setup Control Portions 12 and 22 of the Master Node 1 and Non-master Node 2 respectively. A specific embodiment of the setup procedure is described above with reference to
Subsequent steps T5 to T8 are steps carried out during operation. In step T5, configuration information is received at the I/O Portion 10 of the Master Node 1 and forwarded to the XDMS 16. Based on the previous setup procedure, and by any suitable mechanism, configuration information is then forwarded in step T6 to the Non-master Node 2. This is received at the I/O Portion 20 of the Non-master Node 2 and forwarded to the XDMC 26 for processing. Any configuration information relevant to the configuration of the Configurable Components 28 of the Non-master Node 2 is sent to the Configuration Control Portion 24, and used in configuring the Configurable Components 28. Likewise, at the Master Node 1, any configuration information relevant to the configuration of the Configurable Components 18 of the Master Node 1 is sent to the Configuration Control Portion 14, and used in configuring the Configurable Components 18. A specific embodiment of the operation procedure is described above with reference to
An embodiment of the present invention has one or more of the following advantages:
Although it could be argued that it is not wise to send OAM traffic over the normal traffic interface, it should be appreciated that it is only when the subscription is established that the message is routed via IMS Core; the subsequent notifications about configuration updates can be sent directly (no Record Routing used). The operator may set up a specific OAM IMS network if this becomes a common approach.
Although the above embodiment is described in the context of IMS and UMTS, it will be appreciated that IMS is not limited to mobile networks but is also applicable to fixed networks and other types of network altogether. It is also to be understood that an embodiment of the present invention is not limited to its application within the context of IMS or UMTS.
It will be appreciated that operation of one or more of the above-described components can be controlled by a program operating on the device or apparatus. Such an operating program can be stored on a computer-readable medium, or could, for example, be embodied in a signal such as a downloadable data signal provided from an Internet website. The appended claims are to be interpreted as covering an operating program by itself, or as a record on a carrier, or as a signal, or in any other form.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/EP2008/058587 | 7/3/2008 | WO | 00 | 1/13/2011 |