CN105786876A

CN105786876A - Method, device and system of subscribing and notifying data changes in UDRs

Info

Publication number: CN105786876A
Application number: CN201410816746.XA
Authority: CN
Inventors: 姚德谊
Original assignee: Alcatel Optical Networks Israel Ltd
Current assignee: Alcatel Optical Networks Israel Ltd
Priority date: 2014-12-23
Filing date: 2014-12-23
Publication date: 2016-07-20

Abstract

The invention provides a method, device and system of subscribing and notifying data changes in centralized and distributed user databases. On the one hand, according to the method, the device and the system, subscription requests for notifications of appointed data changes in the user data bases can be extended to comprise subscriptions of extended information; the subscriptions of extended information are used for indicating the subscriptions of any piece of following information. The subscriptions comprise 1), the subscription of request level information; and 2) the subscription of object level appointed information. On the other hand, according to the method, the device and the system, notification requests for subscribed data change in the user databases can be extended to comprise notifications of extended information; the notifications of extension information are used for indicating notifications of any piece of following information. The notifications comprise 1), the notification of request level additional information; 2) the notification of object level additional information; and 3), the notification of object attribute level additional information.

Description

Subscribe to and the method for data variation, device and system in notice UDR

Technical field

The present invention relates to communication technical field, particularly relate to and a kind of subscribe to and notify the technology of data variation in centralized, distributed user data base.

Background technology

3GPPTS29.335 technical specification defines Simple Object Access Protocol (SOAP), it is as a part for Ud interface, the notice for the data variation of front end (FE) dynamically booking reader data base (UDR) side and when receiving that in customer data base, user data changes.

The SOAPUd specification of current TS 29.335 has many limitations, mainly lacks the distributed UDC support disposed.It addition, even centralized UDC disposes, many special applications scenes relevant with performance optimization can not obtain the support of current TS 29.335SOAPUd specification.

Summary of the invention

It is an object of the invention to provide a kind of subscribe to and the notify method of data variation, device and system in centralized, distributed user data base, and by the existing generally applicable extension subscribing to request and notice request is solved the problem in Current specifications.

According to an aspect of the present invention, provide a kind of in user data fusion architecture front end subscribe to about the device of the notice of data variation in customer data base, wherein, described user data fusion architecture at least includes multiple front end (FE) and at least one customer data base LIST SERVER (DS)；

Wherein, this device is used for:

-send to target DS and to ask about to the subscription of the notice that its customer data base middle finger given data changes, subscribing to, with described, the notice request that request is corresponding to obtain, described notice request is initiated when ordered data variation occurs its customer data base by described target DS；

Wherein, described subscription request includes subscribing to extension information, and described subscription extension information is for indicating the subscription to following at least any one information:

The appointment information of-subscription request level；

The appointment information of-subscription object level.

According to a preferred embodiment of the present invention, provide a kind of in distributed user data fusion framework front end subscribe to about the device of the notice of data variation in customer data base, wherein, described distributed user data fusion framework includes multiple front end (FE), multiple customer data base proxy server (PS) and multiple customer data base LIST SERVER (DS)；

Wherein, this device is further used for:

-send the subscription about the notice that the customer data base middle finger given data of described target DS change via the PS corresponding to current FE to target DS and ask, subscribing to, with described, the notice request that request is corresponding to receive from a PS, described notice request is initiated when ordered data variation occurs its customer data base by described target DS；

The appointment information of-subscription request level；

The appointment information of-subscription object level.

Wherein, it is that a FE forwarding is subscribed to the PS of request and notifies that the PS asked can be two different PS to this FE forwarding.

According to another aspect of the present invention, additionally provide a kind of for the device notifying data variation subscribed in its customer data base of customer data base LIST SERVER in user data fusion architecture, wherein, described user data fusion architecture includes multiple front end (FE) and at least one customer data base LIST SERVER (DS)；

Wherein, this device is used for:

-in response at least one FE, the subscription of the notice that the customer data base middle finger given data of current DS changes is asked, at least one FE described, each sends the notice request of its ordered data variation respectively；

Wherein, described notice request includes notice extension information, and described notice extension information is for indicating the notice to following at least any one information:

The additional information of-notice request level；

The additional information of-notice object level；

The additional information of-notice object properties level.

According to a preferred embodiment of the present invention, additionally provide a kind of for the device notifying data variation subscribed in its customer data base of customer data base LIST SERVER in distributed user data fusion framework, wherein, described distributed user data fusion framework includes multiple front end (FE), multiple customer data base proxy server (PS) and multiple customer data base LIST SERVER (DS)；

Wherein, this device is further used for:

-in response at least one FE, the subscription of the notice that the customer data base middle finger given data of current DS changes is asked, ask to each notice sending its ordered data variation at least one FE described respectively via described PS；

The additional information of-notice request level；

The additional information of-notice object level；

The additional information of-notice object properties level.

According to a further aspect of the invention, additionally provide a kind of subscription and notice about the user data fusion architecture of data variation in customer data base, wherein, described user data fusion architecture includes multiple front end (FE) and at least one customer data base LIST SERVER (DS)；

Wherein, each FE pulled subscription for:

The appointment information of-subscription request level；

The appointment information of-subscription object level；

Wherein, each DS sending notice is used for:

The additional information of-notice request level；

The additional information of-notice object level；

The additional information of-notice object properties level.

According to a preferred embodiment of the present invention, additionally provide a kind of subscription and notice about the distributed user data fusion framework of data variation in customer data base, wherein, described distributed user data fusion framework includes multiple front end (FE), multiple customer data base proxy server (PS) and multiple customer data base LIST SERVER (DS)；

Wherein, each FE pulled subscription is further used for:

The appointment information of-subscription request level；

The appointment information of-subscription object level；

Wherein, each DS sending notice is further used for:

-in response at least one FE, the subscription of the notice that the customer data base middle finger given data of current DS changes is asked, ask to each notice sending its ordered data variation at least one FE described respectively via one or more PS；

The additional information of-notice request level；

The additional information of-notice object level；

The additional information of-notice object properties level.

According to an aspect of the present invention, provide a kind of in user data fusion architecture front end subscribe to about the method for the notice of data variation in customer data base, wherein, described user data fusion architecture at least includes multiple front end (FE) and at least one customer data base LIST SERVER (DS)；

Wherein, the method includes:

The appointment information of-subscription request level；

The appointment information of-subscription object level.

According to a preferred embodiment of the present invention, provide a kind of in distributed user data fusion framework front end subscribe to about the method for the notice of data variation in customer data base, wherein, described distributed user data fusion framework includes multiple front end (FE), multiple customer data base proxy server (PS) and multiple customer data base LIST SERVER (DS)；

Wherein, the method includes:

The appointment information of-subscription request level；

The appointment information of-subscription object level.

According to another aspect of the present invention, additionally provide a kind of for the method notifying data variation subscribed in its customer data base of customer data base LIST SERVER in user data fusion architecture, wherein, described user data fusion architecture includes multiple front end (FE) and at least one customer data base LIST SERVER (DS)；

Wherein, the method includes:

The additional information of-notice request level；

The additional information of-notice object level；

The additional information of-notice object properties level.

According to a preferred embodiment of the present invention, additionally provide a kind of for the method notifying data variation subscribed in its customer data base of customer data base LIST SERVER in distributed user data fusion framework, wherein, described distributed user data fusion framework includes multiple front end (FE), multiple customer data base proxy server (PS) and multiple customer data base LIST SERVER (DS)；

Wherein, the method includes:

-in response at least one FE, the subscription of the notice that the customer data base middle finger given data of current DS changes is asked, via described PS, at least one FE described, each sends its notice sending ordered data variation request respectively；

The additional information of-notice request level；

The additional information of-notice object level；

The additional information of-notice object properties level.

According to a further aspect of the invention, additionally provide and a kind of user data fusion architecture is subscribed to and the method for data variation in notice customer data base, wherein, described user data fusion architecture includes multiple front end (FE) and at least one customer data base LIST SERVER (DS)；

Wherein, the method includes:

-each FE pulled subscription sends to target DS and asks about to the subscription of the notice that its customer data base middle finger given data changes, subscribing to, with described, the notice request that request is corresponding to obtain, described notice request is initiated when ordered data variation occurs its customer data base by described target DS；

The appointment information of-subscription request level；

The appointment information of-subscription object level；

The subscription of the notice that the customer data base middle finger given data of current DS changes is asked by-each DS sending notice in response at least one FE, and at least one FE described, each sends the notice request of its ordered data variation respectively；

The additional information of-notice request level；

The additional information of-notice object level；

The additional information of-notice object properties level.

According to a preferred embodiment of the present invention, additionally provide and a kind of distributed user data fusion framework is subscribed to and the method for data variation in notice customer data base, wherein, described distributed user data fusion framework includes multiple front end (FE), multiple customer data base proxy server (PS) and multiple customer data base LIST SERVER (DS)；

Wherein, the method includes:

-each FE pulled subscription sends the subscription about the notice that the customer data base middle finger given data of described target DS change via the PS corresponding to current FE to target DS and asks, subscribing to, with described, the notice request that request is corresponding to receive from a PS, described notice request is initiated when ordered data variation occurs its customer data base by described target DS；

The appointment information of-subscription request level；

The appointment information of-subscription object level；

The subscription of the notice that the customer data base middle finger given data of current DS changes is asked by-each DS sending notice in response at least one FE, asks to each notice sending its ordered data variation at least one FE described respectively via one or more PS；

The additional information of-notice request level；

The additional information of-notice object level；

The additional information of-notice object properties level.

Compared with prior art, on the one hand, the subscription of the notice changed about customer data base middle finger given data is asked by the present invention to be extended to include subscription extension information, subscribe to extension information for indicating subscription to following at least any one information: 1) subscribe to the appointment information of request level, 2) subscribe to the appointment information of object level；On the other hand, the notice of data variation subscribed in customer data base is asked by the present invention to be extended to include notice extension information, notice extension information is for indicating the notice to following at least any one information: the 1) additional information of notice request level, 2) notify object level additional information, 3) notice object properties level additional information.

The present invention proposes a kind of general extension and subscribes to request and extension notice request, specifies subscription and the notice of information for customer data base in UDC centralized, distributed.Wherein, centralized UDC is disposed, in above-mentioned extension proposed by the invention, except to except subscription and the notice of specifying DS/NRG, other extension is all applicable.

The extension of the present invention is subscribed to and asked and extend the request of notice is to subscribing to the extension asked and notify the XSD specification asked in TS29.335 respectively through a kind of generic way, request is subscribed in this extension and extension notice request is meeting on the basis of existing XSD specification, it is possible not only to meet subscription demand and the notice demand of current all UDR suppliers, it is also possible to cover the unknown being likely to use future and subscribe to demand and notice demand.

Accompanying drawing explanation

By reading the detailed description that non-limiting example is made made with reference to the following drawings, the other features, objects and advantages of the present invention will become more apparent upon:

Fig. 1 illustrates the schematic diagram of centralized user data fusion architecture；

Fig. 2 illustrates the schematic diagram of distributed user data fusion framework；

Fig. 3 illustrates a kind of according to an embodiment of the invention subscription for distributed user data fusion framework and the notice method flow diagram about the change of customer data base middle finger given data；

Fig. 4 illustrates the schematic diagram subscribing to the XSD specification asked that current TS 29.335 is defined；

Fig. 5 illustrates the XSD specification schematic diagram subscribing to request extended according to an embodiment of the invention；

Fig. 6 illustrates the schematic diagram of XSD specification of the defined notice request of current TS 29.335；

Fig. 7 illustrates the XSD specification schematic diagram of the notice request extended according to an embodiment of the invention；

Fig. 8 illustrates the flow chart when LDAPPS and SOAPPS separates and disposes to the extension notice request of RFC-5805 affairs according to a preferred embodiment of the present invention；

Fig. 9 illustrates the flow chart when LDAPPS and SOAPPS merges and disposes to the extension notice request of RFC-5805 affairs in accordance with a preferred embodiment of the present invention；

Figure 10 illustrates the flow chart of the extension notice request of the source DS of instruction data variation in accordance with a preferred embodiment of the present invention.

In accompanying drawing, same or analogous accompanying drawing labelling represents same or analogous parts.

Detailed description of the invention

At this, it is provided that the bilingual of Key Term in description, in order to read this specification:

Present invention may apply to the subscription of data variation in centralized, distributed user data base and notice, wherein, aforementioned customer data base such as GSM-HLR, LTE-HSS, IMS-HSS, ANSI-41HLR etc..

Below in conjunction with accompanying drawing, the present invention is described in further detail.

Fig. 1 illustrates the schematic diagram of centralized user data fusion architecture.

As it is shown in figure 1, in a centralized UDC framework, it includes multiple front end (FE) and a UDR LIST SERVER (DS).FE is divided into two types.One is pre-configured FE (Prov-FE), for Service Management, as user services pre-configured.Another kind is call treatment FE (CP-FE), is used for and the net element communication in mobile core network.

In each customer data base (UDR) needing to subscribe to this DS the FE of data variation can directly and this DS mutual, and ask to carry out subscription and the notice of related data change by SOAPUd.

Therefore, for each FE pulled subscription, owing to only having a DS, therefore this DS is all FE and subscribes to the target DS of data variation in UDR.Wherein, each FE and DS can there is a specific device for performing the correlation function of subscription and the notice changed in the present invention about customer data base middle finger given data by device respectively.Hereinafter, the specific device being installed on FE and DS respectively is hereinafter referred to as the first subscription device and the first notice device.

Specifically, illustrate with a subscription between FE and target DS and notice.This FE (or therein first subscribe to device) sends to target DS and asks about to the subscription of the notice that its UDR middle finger given data change, to ask the notice about ordered data variation to this target DS.

Wherein, FE includes subscribing to extension information to the target DS subscription sent request, and described subscription extension information can be used for the instruction subscription to following at least any one information:

1) the appointment information of request level is subscribed to, for instance, independent of the information of some special object, such as share and related information etc. between global information, object；

2) the appointment information of object level is subscribed to, for instance, belong to the information of some special object.

Wherein, above-mentioned " object " Object element meaning to carry in notice request.One DS itself is not the object of TS29.335 standard indication.One DS represents a data base.Countless Object objects is comprised in one DS.Subscribing to specific NRG/DS and belong to the subscription across object, be namely equivalent to subscribe to one group of specific object set, these are subscribed to object (DS) and are all located on certain NRG.

When there is the data variation ordered by this FE in the UDR of this target DS, this target DS (or first notice device therein) asks in response to the subscription of this FE, sends the notice request of its ordered data variation to this FE.

Wherein, the request of this notice includes notice extension information, and described notice extension information can be used for the instruction notice to following at least any one information:

1) additional information of request level is notified, such as, suitable in whole notice request information of overall importance, independent of sharing between the information of some special object, object and related information etc., concrete as current notice derive from which DS/NRG, current notifications data variation by which application amendment；

2) additional information of object level is notified, as being applicable to some special object, concrete DS or its attribute as currently carried out data variation notice；

3) additional information of object properties level is notified, as being applicable to some particular community of some special object, concrete as currently carried out the change of a certain particular community of DS notified.

Fig. 2 illustrates the schematic diagram of distributed user data fusion framework.

As in figure 2 it is shown, in a distributed UDC framework, UDR server is divided into UDR proxy server (PS) and UDR LIST SERVER (DS).PS is same load equalizer such as, typically represents the DS subscription received from FE and asks.DS is the server of actual storage data.

Some DS can replicate data mutually.These DS mutually replicated constitute a network redundancy group (NRG).The data belonging to the DS in a NRG together are identical.Different NRG comprise different data.In mobile core network, after numerous DS are deployed in a small amount of PS, thus obtaining the availability of height and the performance extensibility of height.

At this, FE is divided into Prov-FE and CP-FE equally.Distributed deployment can also avoid the complexity of SOAP/LDAP connection management significantly for FE.When FE sends LDAP/SOAPUd request, FE only needs to send to certain PS, and this PS then forwards the request to a large amount of downstream DS.If data variation occurs in DS side, notice will first be sent to this PS, is forwarded to the FE subscribing to this data variation subsequently.

The data being stored in distributed UDR are divided into two types.One is referred to as user data, and for different users, relative users data are also different.The second is referred to as shared user data (SSD), and shared user data is further classified as two kinds of subclasses.Subclass 1 is referred to as local SSD (local-SSD), and local SSD is shared by the user within the scope of a NRG.Subclass 2 is referred to as overall situation SSD (global-SSD), and it is shared by the user within the scope of all NRG.

Different UDR suppliers can take different storage scheme to store local SSD and overall situation SSD.Such as, overall situation SSD can be stored in special NRG by some suppliers；And for example, overall situation SSD can be stored in all NRG by other suppliers by duplication.Some schemes can take the mode of unidirectional replication, and other schemes can take the mode of multidirectional duplication.

For each FE, it can be subscribed to particular data change in the UDR of one or more DS and obtain the notice of corresponding data change from these DS.Therefore, these subscribed and the corresponding notice of transmission DS are this FE target DS pulled subscription.

Wherein, each FE sends about the subscription request of the notice of data variation in the UDR to target DS to its corresponding PS；It is forwarded to subscribed DS from the corresponding FE request of subscribing to received by each PS；When there is subscribed data variation, the DS of this generation data variation will notify that request sends to certain PS accordingly；Subsequently, the request of this notice is forwarded to the FE subscribing to this data variation by the PS of this reception notice request.

Fig. 3 illustrates method flow diagram according to an embodiment of the invention, and it specifically illustrates in distributed UDC framework, carries out the process to the subscription of data variation in DS1 and notice via PS1 between FE1 and DS1.

Wherein, FE1, DS1 and PS1 can there is a specific device for performing the correlation function of subscription and the notice changed in the present invention about customer data base middle finger given data by device respectively.Hereinafter, the specific device being installed on FE1, DS1 and PS1 respectively is hereinafter referred to as the second subscription device, retransmission unit and the second notice device.

As it is shown on figure 3, in step S301, FE1 (or second subscription device therein) sends the subscription to the notice changed about customer data base middle finger given data to PS1 (or retransmission unit) to be asked.

Wherein, this subscription request includes subscribing to extension information, subscribes to extension information for indicating the subscription to following at least any one information:

1) subscribing to the appointment information of request level, it is unrelated with the information of some special object, and more pays close attention to some information of overall importance, concrete such as shared between global information, object and related information etc.；

2) the appointment information of object level is subscribed to, its information being applicable to belong to some special object.

According to the XSD specification subscribing to request in TS29.335, requestedData element can be used for indicating to the subscription of the change of each operation in UDR (only having a UDR in centralized UDC), at this, the appointment information of the indicated subscription object level of request is subscribed in the extension of the present invention, include but not limited to belong to the customizing messages of arbitrary special object, concrete as specified the object properties change inventory wanting to pay close attention to, it is not desired to the object properties change inventory paid close attention to, force the object properties inventory of association, opportunistic concern, the concern etc. that amendment object identity name (ModifyDN) is operated.The appointment information subscribing to object level can be represented by subscription object level extension information (information as indicated by<requestedDataExt>label).

At this, subscribe to object level extension information and not only include the Data expansion to requestedData element, such as the information indicated by<requestedDataExt>label, also include requestedData attribute of an element classification is extended, as object property list extends, specifically such as the information indicated by<attributeList>label, even also include the classification to requestedData element property and extend, as the classification of<notificationCondition>attribute is extended.

Subscribe to the appointment information of request level for defining the information independent of certain special object, concrete as share between global information, object and related information, only subscribe to data variation within certain specific DS/NRG, in specified conditions time-out concern etc..The appointment information subscribing to request level can be represented by subscription request level extension information (information as indicated by<requestLevelExt>label).

In step s 302, this subscription of FE1 is asked to be forwarded to subscribed DS1 by PS1 (or retransmission unit).

After there is the data variation ordered by FE1 in DS1, in step S303, DS1 (or second notice device therein) asks in response to the subscription of FE1, asks to send to PS1 by the notice of the data variation ordered by FE1.

Wherein, the request of this notice includes notice extension information, and notice extension information is for indicating the notice to following at least any one information:

1) notify the additional information of request level, for instance which NRG/DS notice derive from, be which applies the amendment that causes by, the reason of data variation, the transaction list of association, the restricted selection of target FE, data base stop service etc. temporarily；

2) additional information of object level is notified, for instance notice of timestamp that certain object changes, certain object ModifyDN operation etc.；

3) additional information of object properties level is notified, for instance force instruction sending ISD/DSD message etc..

According to the XSD specification notifying request in TS29.335, object element can be used for indicating the operation of certain object in UDR (only having a UDR in centralized UDC), attribute to change, and attribute element can be used for indicating the concrete change of certain object built-in attribute.

At this, the additional information of the notice request level of the present invention is for defining the global information of notice request level, include but not limited to be applicable to whole notice request information of overall importance, independent of sharing between the information of some special object, object and related information etc., concrete as notice derive from which NRG/DS, the data variation that notifies be which applies the amendment that causes by, the reason of data variation, the transaction list of association, the restricted selection of target FE, data base stop service etc. temporarily.The additional information of notice request level can be passed through to notify that request level extension information (information as indicated by<notificationExt>label) represents.

The additional information of the notice object level of the present invention is for defining the information belonging to certain special object, for instance timestamp that certain object changes, the notice etc. of certain object ModifyDN operation.The additional information of notice object level can be passed through to notify that object level extension information (information as indicated by<objectExt>label) represents.At this, notice object level extension information not only includes the Data expansion to object element, such as the information indicated by<objectExt>label, also include object attribute of an element classification is extended, such as oldDN element, even also include the classification to object element property to extend, as the classification of<operation>attribute is extended.

The additional information of the notice object properties level of the present invention is for defining the information of certain particular community belonging to certain special object, as forced to send the instruction etc. of ISD/DSD message.The additional information of notice object properties level can be passed through notification properties level extension information (information as indicated by<attributeExt>label) and represent.

In step s 304, PS1 (or retransmission unit₎The request of this notice is forwarded to the FE1 subscribing to wherein data variation.At this, notice request can include the identification information of target FE, the i.e. identification information of FE1.When notice request does not include the identification information of target FE, PS1 can inquire about the routing table of its storage, to determine the FE of data variation in the initiation DS subscribing to the request of this notice.

Request and extension notice request are subscribed in extension proposed by the invention described in detail below, and illustrate the possible occupation mode of every extension information in conjunction with specific embodiments.

I. subscribe to request

Fig. 4 illustrates the XSD specification subscribing to request that current TS 29.335 is defined.

As shown in Figure 4, subscription request (SR) in current TS 29.335 specification only includes one and subscribes to object hierarchy, is mainly usually transmitted the information of this level by requesteddata unit.First, with regard to request level generally speaking, former specification cannot specify the subscription under distributed UDC deployment to specific NRG/DS data variation.Secondly, former specification problem in requesteddata element is the whole attribute change that can only subscribe to certain object, subscription attribute can not be screened, relating attribute can not be forced, subscription condition can not be added, ModifyDN event cannot be supported etc., even if former specification there is also these problems under centralized UDC disposes.

According to one embodiment of the invention, Fig. 5 illustrates the schematic diagram of the XSD specification subscribing to request after extension.

As it is shown in figure 5, the request of subscribing to is expanded in 2 levels: the first level, for subscribing to request level, is illustrated by<requestLevelExt>label, and information therein is transmitted by AVP parameter；Second level, for subscribing to object hierarchy, is mainly illustrated by<requestedDataExt>label, and information therein is transmitted mainly through AVP parameter.Such as, subscribe to request level extension information for indicating the subscription to the appointment information subscribing to request level, subscribe to object level extension information for indicating the subscription to the appointment information subscribing to object level.

But, further regard to Fig. 5, it can be seen that the extension information wherein subscribing to object level not only includes the information by the transmission of<requestedDataExt>label, also include the information transmitted by<attributeList>label in requestedData attribute of an element.It is somebody's turn to do<attributeList>label and can be used for the relevant subscription of particular community, the attribute of its data variation should be monitored in specified data object.

Subscription request illustrated in fig. 4 is primarily present problems with:

Problem one:In distributed UDC disposes, specifying the part of NRG to specify the data variation of DS (namely also not all DS) if FE needs to subscribe to part, FE cannot inform PS DS or NRG specifically subscribed to.The main principle of UDC framework is that the UDR by logic hides actual DS/NRG information, and therefore application example follows this rule mostly.But there is the Special use example of some exceptions, this is mainly for performance optimization, the network optimization, special operational etc..

Problem two:SOAPUd subscribes to request can not specify the other monitoring parameter of object level, as do not screened subscription attribute, can not force relating attribute, can not add subscription condition etc..This problem had both been present in distributed UDC framework, existed in centralized UDC framework.

Problem three:Some UDR suppliers are likely to there is specific demand, it is necessary to increase in request level and/or object level and expand parameter.

Problem four:The existing web services definition language (WSDL) subscribing to request can not support that LDAP revises object identity name (modifyDN) operation.

Being asked by the subscription of extension proposed by the invention, the problems referred to above all can be solved.It is described individually below.

The solution of problem one:

·Solution 1

According to a preferred embodiment of the present invention, UDC disposes and has 2 NRG and each NRG includes 4 DS.User only needs half DS to be responsible for the flow of UdSOAP subscription request and notice request.Typical cause be by SOAPUd flow from LDAP flow separation to realize better LDAP performance.Generally, if LDAP turnover rate is high, SOAP notifies that flow is likely to have a strong impact on UDR performance.By using the extension information of following subscription request level, FE can only subscribe to the data variation of ds-newyork-backend2 and the ds-chicago-backend2 of ds-newyork-backend1 and the ds-chicago-backend1 and NRG2 of NRG1.

At this,<requestLevelExt>,</requestLevelExt>represent the origin identification subscribing to request level extension information respectively, terminate mark.

<parameterAvp>,</parameterAvp>represent that property value is to the origin identification of parameter, end mark respectively.

<parameterName>,</parameterName>represent the origin identification of parameter name respectively, terminate mark.

<parameterValue>,</parameterValue>represent the origin identification of parameter value respectively, terminate mark.

Subscribe to request level extension the mark of information, the mark of property value parameter, the mark of parameter name, parameter value mark in this article by Reusability, for simple declaration for the purpose of, below be not repeated explain.

Wherein, parameter name RedundantUdrDsServerGroup represents that the name of parameter is called the DS subscribing to NRG；Parameter value N RG1:ds-newyork-backend1,

NRG1:ds-chicago-backend1、NRG2:ds-newyork-backend2、

NRG2:ds-chicago-backend2 is NRG1's for indicating the DS subscribing to NRG

Ds-newyork-backend1 and ds-chicago-backend1's and NRG2

Ds-newyork-backend2 and ds-chicago-backend2.

·Solution 2

According to a preferred embodiment of the present invention, identical with the reason of above-mentioned solution 1, it is necessary to separate SOAP and LDAP flow, but implementation is more intelligent than solution 1.It is different from and specifies concrete DS, the FE that process SOAP notice flow in NRG to require nothing more than 2 minimum DS of overload degree in NRG to process SOAP notice flow statically.Such as, UDC disposes and has 2 NRG and each NRG includes 4 DS.User only needs half DS to be responsible for the flow of UdSOAP subscription request and notice request.But user only needs DS server that overload degree in each NRG is minimum to be responsible for UdSOAP flow.FE can extend information by following subscription request level and PS carries out this kind of instruction.

At this, parameter name DsOverloadBasedSubscriptionPolicy represents that the name of parameter is called the subscription strategy based on DS overload degree；Parameter value FEWEST_OVERLOAD_RANK_1 is for indicating subscription strategy for subscribing to overload degree minimum DS, parameter value FEWEST_OVERLOAD_RANK_2 for indicating the DS that subscription strategy is low for subscribing to overload degree time.

Wherein, PS is directly issued in the subscription of FE all the time.NRG is by proprietary protocol judges which pack heaviest in internal DS/the lightest.

·Solution 3

According to a preferred embodiment of the present invention, user has a distributed UDR and disposes, wherein, overall situation SSD be implemented as unidirectional replication and in a specific NRG being referred to as main NRG (mainNRG) only one be referred to as the DS of main DS (primaryDS) and be responsible for the UdLDAP of overall situation SSD and write flow.PrimaryDS is responsible for overall situation SSD other DS copying in mainNRG.For realizing high availability purpose, primaryDS in mainNRG is also revocable.If current primaryDS can not work, another DS can dynamically be switched to primaryDS.For reducing the overload degree of primaryDS, user needs UdSOAP to subscribe to be not directed to primaryDS, and points to the DS of other non-primaryDS in mainNRG.FE can extend information by following subscription request level and UDRPS instruction carries out this kind of strategy instruction.

At this, parameter name GlobalSSDSubscriptionPolicy represents that the name of parameter is called that overall situation SSD subscribes to strategy；Parameter value

AVOID_SUBSCRIPTION_ON_PRIMARY_DS is used for indicating overall situation SSD to subscribe to strategy for avoiding subscribing to primaryDS.

·Solution 4

According to a preferred embodiment of the present invention, operator needs to move to another NRG some user data NRG from distributed UDR cluster.This is referred to as user and returns genus (subscriberrehoming), and it is generally increasing after network node or performed by operator for static capacity adjustment.If, operator needs to move to NRG2 range of telephone numbers user between 12340000-12349999 from NRG1.Return genus process, by UdLDAP, user data is copied to NRG2 from NRG1, delete the such user data on NRG1 subsequently.Owing to not changing from the angle user data of FE, thus operator triggers any UdSOAP notice without wishing to returning genus operation.Therefore, FE can extend information by following subscription request level and UDRPS carries out this kind of instruction, temporarily to stop the subscription to the upper range of telephone numbers 12340000-12349999 user of NRG1 and NRG2.

At this, parameter name TemporallyPauseSubscriptionBeforeRehoming represents that the name of parameter is called before returning genus and suspends subscription；It is 98765412300 that parameter value REHOMING_OPERATION_ID:98765412300 returns genus Action number for instruction；It is NRG1, NRG2 that parameter value TARGET_NRG_LIST:NRG1, NRG2 are used for indicating target NRG list；It is 12340000-12349999 that parameter value TARGET_SUBSCRIBER_KEY_RANGE:12340000-12349999 is used for indicating targeted customer's range of telephone numbers.

After returning genus and completing, FE can use following subscription request level extension information to restart to subscribe to.

At this, parameter name ResumeSubscriptionAfterRehoming represents that the name of parameter is called after returning genus and recovers to subscribe to；It is 98765412300 that parameter value REHOMING_OPERATION_ID:98765412300 returns genus Action number for instruction；It is NRG1, NRG2 that parameter value TARGET_NRG_LIST:NRG1, NRG2 are used for indicating target NRG list；It is 12340000-12349999 that parameter value TARGET_SUBSCRIBER_KEY_RANGE:12340000-12349999 is used for indicating targeted customer's range of telephone numbers.

The solution of problem two:

·Solution 1

According to a preferred embodiment of the present invention, the dynamic position data that there is frequent updating for GSMHLR, GSM user and the service data infrequently updated, the latter such as calling transfer data.Call treatment FE (CP-FE) is not usually required to the dynamic position change subscribing to vlrIsdn/sgsnIsdn, but it should be understood that data variation is shifted in calling, because FE is likely to need the service VLR (servingVLR) to user to send ISD/DSD.Some attaching position registers (HLR) supplier is likely to be of such Data Model Designing, and data that are that namely frequently change and that infrequently change are in same data object (such as entry).If only calling transfer data monitored (such as, whole data object is monitored) cannot be indicated, every time when there is location updating on this data object, notice request all can be sent to call treatment FE.This will cause substantial amounts of notice flow, thus reducing the performance of UDR and FE, therefore this situation needs to be avoided by.A kind of good mode is the attribute that instruction need to be monitored in the request of subscribing to.Such as, in the examples described above, dynamic position attribute should not be monitored, such that it is able to exclude nonessential notice flow.

This can by realizing the extension subscribing to object-level information, and as increased new xml attribute under<requestedData>element, as can be described as " attributeList ", it comprises the attribute list that need to monitor.Separated by space between the attribute that need to monitor.

Such as, only these 4 attributes of forwardedToNumber, subAddressValue, cfProvisionedFlag and cfActivatedFlag are monitored.FE can extend information by following subscription object level and indicate.

At this,<requestedData>,</requestedData>represent the origin identification subscribing to object-level information respectively, terminate mark.

<notificationCondition>,</notificationCondition>represent the origin identification of the condition of trigger notification request respectively, terminate mark.

Subscribe to the mark of condition of object-level information, trigger notification request in this article by Reusability, for the purpose of simple declaration, be below not repeated to explain.

AttributeList represents monitored attribute list.

AttributeList=" forwardedToNumbersubAddressValuecfProvisionedFlagcfActiv atedFlag " represents that monitored attribute includes forwardedToNumber, subAddressValue, cfProvisionedFlag and cfActivatedFlag.

At this, modify, delete, add represent respectively the data of monitored attribute being modified, delete, when increasing, by trigger notification request.

·Solution 2

According to a preferred embodiment of the present invention, similar to the above-mentioned solution 1 of problem two, another way is get rid of monitoring vlrIsdn/sgsnIsdn from data object.FE can extend information by following subscription object level and indicate.

At this,<requestedDataExt>,</requestedDataExt>represent the origin identification subscribing to object level extension information respectively, terminate mark.

Subscribe to the mark of object level extension information in this article by Reusability, for the purpose of simple declaration, be below not repeated to explain.

Parameter name Exclude_Attributes represents that the name of parameter is called eliminating monitoring attributes；Parameter value vlrIsdn, sgsnIdsn represent that the attribute being excluded monitoring is vlrIsdn, sgsnIdsn respectively.

The solution of problem three:

·Solution 1

According to a preferred embodiment of the present invention, identical with the example in the above-mentioned solution 2 of problem two, CP-FE needs to subscribe to the data variation on the UDRDS conformed to a predetermined condition, described predetermined condition such as overload.This can by using the extension information subscribing to request level to complete.Meanwhile, CP-FE need not subscribe to the data variation of frequent updating, and such as dynamic subscriber position, this can by using the extension information subscribing to object level to complete.

Parameter name UdrDsServerAffinity represents that the name of parameter is called and is related to DS；Parameter value LOWEST_OVERLOADED is for indicating the DS subscribing to minimum overload.

<requestedDataobjectClass=" GsmServiceProfile ">represents that the object of the request of subscription is GsmServiceProfile；Modify, delete, add represent respectively the data of monitored object being modified, delete, when increasing, by trigger notification request.

·Solution 2

According to a preferred embodiment of the present invention, some CP-FE may want to subscribe to the data variation of an attribute, but when this attribute changes, some adeditive attributes in same data object are also expected to be included in notice request, and no matter whether these adeditive attributes change.This can process MAP_ISD/DSD for CP-FE and save extra LDAP search.By subscribing to object level extension information, such requirement is easy to represent.

Such as, when attribute " CallForwardingNumber " changes, such as the adeditive attribute such as " subAddressValue ", " cfProvisionedFlag " and " cfActivatedFlag " is expected to occur in NotifyRequest message, processing MAP_ISD/DSD for CP-FE, no matter whether the data of these adeditive attributes update.

At this, attributeList=" CallForwardingNumber " represents that monitored attribute includes CallForwardingNumber.

Modify represents that the data of monitored attribute are when being modified, by trigger notification request.

Parameter name CORELATED_ATTRIBUTES represents that the name of parameter is called the association attributes that need to monitor；Parameter value subAddressValue, cfProvisionedFlag, cfActivatedFlag represent that the association attributes that need to monitor includes subAddressValue, cfProvisionedFlag, cfActivatedFlag.

·Solution 3

According to a preferred embodiment of the present invention, CP-FE is likely to need the change of one attribute of subscription sometimes, it may be desirable to only when property value generation specific change, as become value 2 from value 1, just trigger notification request.By subscribing to object level extension information, such requirement is easy to represent.

For GSMHLR, only when the attribute " gsmSubscriptionActivationStatus " of user is become NO from YES by Prov-FE, notice request should be sent to CP-FE, to delete the position of active user.If this value is become YES from NO by Prov-FE, not yet registering on any VLR/SGSN due to this user, CP-FE is without sending MAP_CANCEL_LOCATION.This can save the notice flow between CP-FE and UDR.

At this, attributeList=" gsmSubscriptionActivationStatus " represents that monitored attribute includes gsmSubscriptionActivationStatus, that is, GSM subscribes to state of activation.

Parameter name CHANGE_FROM represents that the name of parameter is called that the GSM before amendment subscribes to state of activation；It is YES that parameter value YES represents that the GSM before amendment subscribes to state of activation.

Parameter name CHANGE_TO represents that the name of parameter is called that amended GSM subscribes to state of activation；It is NO that parameter value N O represents that amended GSM subscribes to state of activation.

Preferably for above preferred embodiment, if user is unregistered before data variation occurs, then notice request should not be sent to CP-FE.Under the certain logic of this embodiment, for optimizing notice request, the following extension information subscribing to object level can be added into and reduce nonessential notice.When NOTIFICATION_DEPENDENT_CONDITION is designated in subscribing to object level extension information, only UERegistrationStatus=YES can trigger notice.

Parameter name NOTIFICATION_DEPENDENT_CONDITION represents that the name of parameter is called the dependence condition of notice request；Parameter value UERegistrationStatus and parameter value YES represents that the dependence condition of notice request be user registration state is YES.

The solution of problem four:

The WSDL of existing TS29.335 specification can not support that LDAP revises subscription and the notice of DN operation.

Amendment DN operates cipher key change that is extremely important and that be generally used for user, such as changes IMSI, MSISDN etc., and these information are generally the correlated identities name (RDN) of object.

Such as, for changing IMSI, following amendment DN operation can be used:

OldDN:

MSubIdentificationNumberId=1234567890, mobileNetworkCodeId=01, mobileCountryCodeId=208, plmnFunctionId=1, managedElementId=HSS1

NewDN:

MSubIdentificationNumberId=2345678901, mobileNetworkCodeId=01, mobileCountryCodeId=208, plmnFunctionId=1, managedElementId=HSS1

Above-mentioned amendment DN operates expression: mobile identification number is revised as 2345678901 by 1234567890；And other information are unchanged.

At this, following two solution can be used to support the subscription that LDAP revises DN operation:

·Solution 1

The subscription that LDAP revises DN operation can be realized by the extension information of subscription object level, such as the extension of the classification to notification condition.

Specifically, it is possible in<notificationCondition>(condition of trigger notification request), increase new classification " modifyDN " (amendment DN).Such as, the extension information for subscribing to the subscription object level of amendment DN operation is shown below:

<notificationCondition>modifyDN</notificationCondition>

</requestedData>

·Solution 2

Alternative solution is, still uses existing subscription specification, but notice specification is extended.

Specifically, the request of subscribing to still uses existing "<notificationCondition>", but in notice request, add two<object>(object) elements, one is " delete " (deletion) operation, another is " add " (increase) operation, and uses<objectExt>(object level extension information) to indicate this to be one " modifyDN " (amendment DN) operation.The object level extension information of notice request will illustrate in the description of the extension below in relation to notice request.

At this, it is necessary to explanation, those skilled in the art will be understood that the solution of the problems referred to above one to four and each problem is all merely illustrative, but not exhaustive to the problem that can solve of request of subscribing to of extension proposed by the invention or its corresponding solution.Due to it is desirable to provide request is subscribed in a kind of general extension, therefore, the request of subscribing to of this extension is possible not only to meet the existing subscription demand that centralized, distributed user data base's middle finger given data are changed, including but not limited to the subscription demand shown by above-mentioned each solution, it can be additionally used in issuable to other subscription demands centralized, the change of distributed user data base's middle finger given data in the future.For other subscription demands that are NM in the above embodiment of the present invention and that be likely to occur in the future; request can be subscribed to by extension proposed by the invention such as it to realize; then should be comprised within the scope of patent protection of the present invention, and be incorporated herein with way of reference.

II. notice request

Fig. 6 illustrates the XSD specification notifying request that current TS 29.335 is defined, for the notice of the data variation to centralized user database.

As shown in Figure 6, notice request (NR) in current TS 29.335 specification only includes two levels, and the first level is object level (object), and the second level is property level (attribute).

According to one embodiment of the invention, Fig. 7 illustrates the schematic diagram of the XSD specification of the notice request after extension.

As it is shown in fig. 7, notice request is expanded in 3 levels: the first level is notice request level,<notificationExt>label illustrate；Second level is notice object hierarchy, is mainly illustrated by<objectExt>label；Third layer level is notice object properties level, is mainly illustrated by<attributeExt>label.Wherein, the transmission of the information in each extension level is all transmitted mainly through AVP parameter.

Such as, notice request level extension information is for indicating the additional information of notice request level, and notice object level extension information is for indicating the additional information of notice object level, and notification properties level extension information is for indicating the additional information of notice object properties level.

When notice request illustrated in fig. 6 is applied to distributed UDC, it is primarily present problems with:

Problem one:In distributed UDC disposes, if a LDAP atomic transaction (atomictransaction) based on RFC-5805 have updated the multiple data objects being positioned on multiple UDR LIST SERVER, PS or FE cannot make to be triggered by same affairs but interrelated from the multiple independent notice request of different DS.Owing to 3GPPTS29.335 recommends RFC-5805 affairs in UDC, a generic way therefore must be adopted in distributed UDC disposes to notify that request solves this problem by UdSOAP.

Problem two:In distributed UDC disposes, when notice request is transferred into FE by PS, it is impossible to represent this notice is asked from which DS in which NRG.

Problem three: the reason of data variation cannot be represented.Such as, data variation be triggered by call treatment or by the pre-configured triggering of OAM etc..Different reasons may result in the different disposal of FE.This problem is present in centralized and distributed UDC deployment.

Problem four:Some UDR suppliers are likely to be of increases, in notice request level, notice object level and/or notification properties level, the particular demands expanding parameter.This problem is present in centralized and distributed UDC deployment.

Problem five:The WSDL of existing notice request can not support that LDAP revises DN operation.This problem is present in centralized and distributed UDC deployment.

Being asked by the notice of extension proposed by the invention, the problems referred to above all can be solved.It is described individually below.

The solution of problem one:

·Solution 1

According to a preferred embodiment of the present invention, Fig. 8 is shown in LDAPPS and SOAPPS and separates flow chart when disposing, the extension notice of RFC-5805 affairs asked.

As shown in Figure 8, in typical distributed UDC disposes, Prov-FE1 is responsible for user and services pre-configured.CP-FE1 is responsible for communicating with the ext nal network element in core net.

This deployment has LDAPPS (being specially LDAPPS1) separated from one another and SOAPPS (being specially SOAPPS2, SOAPPS3).Ud subscribes to record and is stored on DS, but not on PS.

At this, the user data of user 1 is respectively stored on the DS2 of DS1 and NRG2 of NRG1.By RFC-5805 atomic transaction, the user data of user 1 is updated by two operations (as operated 1 and operation 2, be respectively labeled as op1 and op2 at this) from Prov-FE1 to LDAPPS1.Operation 1 is by the data object 1 (sub1-entry1) of user 1 on DS1 in amendment NRG1.Operation 2 is by the data object 2 (sub1-entry2) of user 1 on DS2 in amendment NRG2.

Owing to DS1 and DS2 belongs to different NRG, between DS1 and DS2, it is absent from data replicates.Flow process based on the extension notice request of RFC-5805 affairs is as follows:

S801.Prov-FE1 starts RFC-5805 affairs to LDAPPS1；

S802.LDAPPS1 starts the RFC-5805 affairs DS1 to NRG1；

S803.LDAPPS1 obtains affairs numbering tr1 (tid=tr1)；

S804.LDAPPS1 starts the RFC-5805 affairs DS2 to NRG2；

S805.LDAPPS1 obtains affairs numbering tr2 (tid=tr2)；

S806.Prov-FE1 obtains affairs numbering tr0 (tid=tr0)；

S807.Prov-FE1 starts operation 1 (op1) of the amendment to user 1 by affairs tr0；

S808.OP1 is routed to the DS1 of NRG1；

S809.OP1 returns success message from DS1；

S810.LDAPPS1 returns OP1 success message to Prov-FE1；

S811.Prov-FE1 starts operation 2 (op2) of the amendment to user 1 by affairs tr0；

S812.OP2 is routed to the DS2 of NRG2；

S813.OP2 returns success message from DS2；

S814.LDAPPS1 returns OP2 success message to Prov-FE1；

S815.Prov-FE1 is that affairs tr0 sends commit (), and at this, commit represents trust；

S816.LDAPPS1 is that affairs tr1 transmission commit () comprises LDAP control information " totalTxnListControl " to DS1, commit (), comprises affairs numbering tr1 and tr2 in " totalTxnListControl "；

S817. affairs tr1commit () success；

S818.LDAPPS1 is that affairs tr2 transmission commit () comprises LDAP control information " totalTxnListControl " to DS2, commit (), comprises affairs numbering tr1 and tr2 in " totalTxnListControl "；

S819. affairs tr2commit () success；

S820. affairs tr0commit () success；

S821.DS1 sends UdSOAP notice and asks to SOAPPS2, notice request comprises information op1, sub1-entry1, tr1, totalTnxList=" tr1; tr2 " and notfTarget=CallProcessing-FE1, at this, CallProcessing-FE1 will be used to receive notice request.DS1 can take selection algorithm, and such as HASH (sub1-key, the key of user 1), its result can map to the CallProcessing-FE1 in subscription list.

S822.SOAPPS2 forwards notice request to CallProcessing-FE1, comprises information op1, sub1-entry1, tr1, totalTnxList=" tr1, tr2 " in notice request.After CallProcessing-FE1 receives this request, its tr1 only known in " tr1, tr2 " arrives.CallProcessing-FE1 will wait the arrival of tr2.

S823.DS2 sends UdSOAP notice and asks to SOAPproxy3, notice request comprises information op2, sub1-entry2, tr2, totalTnxList=" tr1; tr2 " and notfTarget=CallProcessing-FE1, at this, CallProcessing-FE1 will be used to receive notice request.The selection algorithm that DS2 takes is essentially identical with DS1's, to obtain identical notice target.

S824.SOAPproxy3 forwards notice request to CallProcessing-FE1, comprises information op2, sub1-entry2, tr2, totalTnxList=" tr1, tr2 " in notice request.After CallProcessing-FE1 receives this request, it knows the tr2 notice being last asks.

S825.CallProcessing-FE1 sends MAP_ISD/DSD to servicing VLR/SGSN, so that pre-configured service comes into force.

Wherein, in step S821, notice request can use notice request level extension information to indicate additional parameter tid, totalTnxList and notfTarget, specifically illustrates as follows:

At this,<notificationExt>,</notificationExt>represent the origin identification of notice request level extension information respectively, terminate mark.

The mark of notice request level extension information is in this article by Reusability, for the purpose of simple declaration, is below not repeated to explain.

Parameter name TRANSACTION_ID represents that the name of parameter is called that affairs are numbered；Parameter value tr1 represents that affairs are numbered tr1.

Parameter name TOTAL_TRANSACTION_ID_LIST represents that the name of parameter is called overall affairs numbered list；Parameter value tr1, tr2 represent that overall affairs numbered list comprises tr1 and tr2.

Parameter name NOTIFY_TARGET represents that the name of parameter is called the target of notice request；Parameter value CallProcessing-FE1 represents that the target of notice request is CallProcessing-FE1.

In step S822, notice request can use notice request level extension information to indicate additional parameter tid, totalTnxList, specifically illustrates as follows:

In step S823, notice request can use notice request level extension information to indicate additional parameter tid, totalTnxList and notfTarget, specifically illustrates as follows:

Parameter name TRANSACTION_ID represents that the name of parameter is called that affairs are numbered；Parameter value tr2 represents that affairs are numbered tr2.

In step S824, notice request can use notice request level extension information to indicate additional parameter tid, totalTnxList, specifically illustrates as follows:

·Solution 2

According to a further advantageous embodiment of the invention, Fig. 9 is shown in flow chart when LDAPPS and SOAPPS merges deployment, the extension notice of RFC-5805 affairs asked.

As it is shown in figure 9, LDAPPS and SOAPPS is integrated on same physical server (is labeled as LDAP&SOAPPS1).

Step S901 is to step S920, essentially identical with step S801 to S820 in Fig. 8, and part difference is as follows:

1) in step S916 and S918, it is not necessary to additional LDAP controls information " totalTxnListControl "；

2) in step S921 and S922, it is not necessary to increase parameter " totalTnxList "；

3) in step S923, LDAP&SOAPPS1 knows whole transaction list and comprises tr1 and tr2, therefore, a new notice request is merged in the notice request of step S921 and S922 by LDAP&SOAPPS1, and sends new notice request to CAllProcessing-FE1.

Wherein, in step S921, notice request can use notice request level extension information to represent additional parameter tid and notfTarget, specifically illustrates as follows:

At this, parameter name TRANSACTION_ID represents that the name of parameter is called that affairs are numbered；Parameter value tr1 represents that affairs are numbered tr1.

In step S922, notice request can use notice request level extension information to represent additional parameter tid and notfTarget, specifically illustrates as follows:

At this, parameter name TRANSACTION_ID represents that the name of parameter is called that affairs are numbered；Parameter value tr2 represents that affairs are numbered tr2.

The solution of problem two:

·Solution 1

According to one embodiment of present invention, Figure 10 illustrates the flow chart of the extension notice request of the source DS of instruction data variation.

As shown in Figure 10, after GSMHLR, the Prov-FE1 amendment user 1 data object in the DS1 of NRG1, notice request is received by CP-FE1, and CP-FE1 is likely to need to send MAP_ISD/DSD to VLR/SGSN.But owing to the information needed for MAP_ISD/DSD is likely stored in another data object, this another data object is not changed by Prov-FE1, thus these information are likely to not be completely contained in the request of this notice.Therefore, CP-FE1 is likely to require over the extra LDAP search request of LDAPPS2 and downloads these information for active user.If notice request can indicate, for user, the source DS initiating notice request, CP-FE1 can control information sending to the LDAP search request of LDAPPS2 additional LDAP, LDAPPS2 can walk around the search of its internal routing table, directly LDAP search request is forwarded to target DS (that is, source DS) rapidly.This can promote the performance of PS2, because if user 1 is not in the routing table of PS2, PS2 is the LDAP broadcast traffic finding this user to have to initiate all NRG.Such broadcast adds the overhead of UDR system, therefore should be avoided by.

Specifically, notification procedure is as follows:

S1001. pre-configured FE (Prov-FE1) revises the calling forwarding number of user 1 by LDAP amendment request (LDAPmodifyrequest)；

This amendment request is forwarded to the DS1 in the NRG1 at user 1 place by S1002.LDAPPS1；

S1003. amendment is asked successfully；

S1004.LDAPPS1 returns success message to Prov-FE1；

S1005.DS1 sends notice request to SOAPPS1, comprises UDR_DS_ORIGIN=DS1, to indicate source DS for DS1 in notice request；

The request of this notice is forwarded to call treatment FE (CP-FE1), CP-FE1 and has subscribed to calling transfer data variation by S1006.SOAPPS1；

S1007.CP-FE1 needs additional information to determine the need for sending MAP_ISD/DSD message and sending MAP_ISD/DSD message to where.LDAP search request is sent to LDAPPS2 by CP-FE1, comprises LDAP and controls information " DsPreferecePolicy=DS1 ", to accelerate the forwarding of PS2 in LDAP search request；

S1008.LDAPPS2 uses this LDAP control information and this searching request is forwarded directly to target DS1；

S1009.DS1 returns additional information, determines the need for sending the target VLR/SGSN of MAP_ISD/DSD message and user 1 wherein for CP-FE1；

Search Results is forwarded to CP-FE1 by S1010.LDAPPS2；

MAP_ISD/DSD message is sent the VLR/SGSN to user 1 by S1011.CP-FE1.

Wherein, in step S1005 and step S1006, notice request level extension information can serve to indicate that source DS (UDR_DS_ORIGIN), specifically illustrates as follows:

At this, parameter name UDR_DS_ORIGIN represents that the name of parameter is called source DS；Parameter value DS1 represents that source DS is DS1.

·Solution 2

According to a preferred embodiment of the present invention, subscribe to extension information and notice extension information may be used for subscribing to and notice reset process.This solution is applicable to centralized and distributed UDC and disposes.

Resetting the process for GSM-HLR/LTE-HSS that (RESET) is 3GPP definition, when all or part of HLR/HSS collapses, reset process is activated.

Some UDR suppliers can utilize UdSOAP to subscribe to and notice carries out reset process.Such as, during distributed UDR disposes, special mainNRG is used for storing overall situation SSD, and there is multiple user NRG in UDR cluster.User NRG is the overall SSD being defined as on mainNRG according to user key scope.Currently, user NRG1 collapses for a certain reason, and when NRG1 is restarted, the request of specifically notifying is sent to the CP-FE subscribed to by a DS on this NRG1, and all dynamic user data illustrated on this NRG1 are lost.After receiving this UdSOAP notice request, CP-FE should send corresponding information to the relevant network element of affected user's IMSI scope, as send MAP_RESET message to VLRs/SGSNs (for GSM-HLR), send S6aRESET_REQUEST message and to MMEs (for LTE-HSS) and send SwxPUSH_PROFILE_REQUEST message to AAAservers (for LTE-HSS).Owing to there is the notice extension information of which user NRG collapse of instruction in notice request, CP-FE can obtain corresponding user key scope from overall situation SSD.

Specifically, CP-FE can subscribe to request level extension information in the request of subscribing to below use, for reset process:

At this, parameter name RESET_HANDLING_SUBSCRIPTION represents the subscription that title is reset process of parameter；Parameter value ALL_NRGs represents that the subscription of reset process includes all NRG.

Correspondingly, notice request can include the request level extension information that sends a notice:

At this, parameter name NRG_DOWN_NOTIFICATION represents that the name of parameter is called NRG crash notification.

Parameter name UDR_NRG_ORIGIN represents that the name of parameter is called the source UDR_NRG of notice request；Parameter value N RG1 represents that the source UDR_NRG of notice request is NRG1.

Parameter name SUBSCRIBER_KEY_RANGE_LIST represents that the name of parameter is called

User key range list；Parameter value 12340000-12349999 represents that user key range list includes 12340000-12349999；Parameter value 92340000-92349999 represents that user key range list includes 92340000-92349999.

Under centralized UDC disposes, total system only one of which DS, it is considered a special case of distributed UDC, thus above-mentioned solution is equally applicable.

The solution of problem three:

According to a preferred embodiment of the present invention, notice request level extension information can serve to indicate that the reason of data variation.

For GSMHLR, there is multiple user and service data and both can be revised by CP-FE or Prov-FE.

Such as, for calling transfer service, if Prov-FE amendment calling forwarding number, when CP-FE receives this UdSOAP notice, CP-FE answers the MAP-INSERT-SUBSCRIBER-DATA operation of the service VLR of triggered for user.If but calling forwarding number is revised by MAP_ACTIVATE_SS operation by a CP-FE, after notice request is received by any CP-FE, the service VLR of this user should not sent MAP-INSERT-SUBSCRIBER-DATA operation by this notification received CP-FE.Therefore, should there is mark (flag) in notice request indicates this data variation to be completed by CP-FE.This mark can realize in notice request level extension information, it is shown that as follows:

At this, parameter name DATA_CHANGE_REASON represents that the name of parameter is called data variation reason；Parameter value Provisioning-Management-Operation represents that data variation reason is pre-configured management operation.

This solution is applicable to centralized and distributed UDC and disposes.

The solution of problem four:

·Solution 1

According to a preferred embodiment of the present invention, notice object level extension information can serve to indicate that the timestamp of the operation causing data variation.

In some cases, CP-FE is likely to be received a series of continuous notice request from same user, and therefore, the logic of CP-FE is likely to be dependent on the order of notice request continuously.

For GSMHLR, there may come a time when there are two standalone transactions revising same user.Such as, for same user, affairs 1 (being labeled as tr1) are 1234 for updating calling forwarding number at time point T1, and affairs 1 (being labeled as tr2) are 5678 for updating calling forwarding number at time point T2.Time point T2 is after time point T1, but close to T1.In this case, if the notice of CP-FE reception tr1 is later than tr2, VLR and obtains the calling forwarding number (1234) of mistake the most at last.For solving this problem, UDR supplier can increase notice object level extension information<objectExt>in notice request, concrete such as ENTRY_OPERATION_TIMESTAMP.CP-FE is then that same user can according to the notice request of correct sequential processing.This notice object level extension information can ensure that in the scheduled time window timestamp earlier is processed prior to more late timestamp.

Specifically, for indicating the notice object level extension information of operating time stamp to be shown below:

The notice request of affairs tr1 revises data object " suMSubscriberId=sub1, subscriptionFunctionId=1, managedElementId=HSS1 " at 2014-03-2415:15:29.

At this,<object>,</object>represent the origin identification of notice object-level information respectively, terminate mark.

<attribute>,</attribute>represent the origin identification of notification properties level information respectively, terminate mark.

<objectExt>,</objectExt>represent the origin identification of notice object level extension information respectively, terminate mark.

The notice mark of object-level information, the mark of notification properties level information, notice object level extend the mark of information in this article by Reusability, for the purpose of simple declaration, are below not repeated to explain.

DN=" suMSubscriberId=sub1, subscriptionFunctionId=1, managedElementId=HSS1 " represents the identification name of object.

Operation=" modify " represents that operation is for amendment.

Name=" CallForwardingNumber " represents that Property Name is calling forwarding number.

Modification=" replace " represents that amendment mode is for replacing.

<currentValue>1234</currentValue>represent that amended value is 1234.

<beforeValue>0000</beforeValue>represent that the value before amendment is 0000.

Parameter name ENTRY_OPERATION_TIMESTAMP represents that the name of parameter is called data object operation timestamp；Parameter value 2014-03-2415:15:29 represents that data object operation timestamp is 2014-03-2415:15:29.

The notice request of affairs tr2 revises data object " suMSubscriberId=sub1, subscriptionFunctionId=1, managedElementId=HSS1 " at 2014-03-2415:15:30

Operation=" modify " represents that operation is for amendment.

Modification=" replace " represents that amendment mode is for replacing.

<currentValue>5678</currentValue>represent that amended value is 5678.

<beforeValue>1234</beforeValue>represent that the value before amendment is 1234.

Parameter name ENTRY_OPERATION_TIMESTAMP represents that the name of parameter is called data object operation timestamp；Parameter value 2014-03-2415:15:30 represents that data object operation timestamp is 2014-03-2415:15:30.

This solution is applicable to centralized and distributed UDC and disposes.

·Solution 2

According to a preferred embodiment of the present invention, notification properties level extension information can serve to indicate that the notice relevant to particular community.

For GSMHLR, some users are for misarrangement purpose, a kind of mode is needed to reload the files on each of customers (profile) of (reload) service node, this reloading process is usually used on Prov-FE to perform technical instruction, as being used to that from original value, calling forwarding number is revised as identical value.The notice triggered to CP-FE is asked by this, but owing to calling forwarding number does not actually occur change, CP-FE generally abandons the request of this notice.For forcing manually to send MAP_ISD/DSD message to servicing VLR/SGSN, the request of this notice can comprise a special tag on " CallForwardingNumber " attribute, to indicate this to be a manual MAP_ISD/DSD process and CP-FE also should process this notice, even if " CallForwardingNumber " does not actually occur change.This can extend information<attributeExt>by notification properties level and realize, it is shown that as follows:

Operation=" modify " represents that operation is for amendment.

Modification=" replace " represents that amendment mode is for replacing.

<currentValue>+ 1-908-123-4567</currentValue>represent that amended value is for+1-908-123-4567.

<beforeValue>+ 1-908-123-4567</beforeValue>represent that the value before amendment is+1-908-123-4567.

<attributeExt>,</attributeExt>represent the origin identification of notification properties level extension information respectively, terminate mark.

The mark of notification properties level extension information is in this article by Reusability, for the purpose of simple declaration, is below not repeated to explain.

This solution is applicable to centralized and distributed UDC and disposes.

The solution of problem five:

Described in the problem four of the request of subscribing to, the WSDL of existing TS29.335 specification can not support that LDAP revises subscription and the notice of DN operation.Further, about the problem four of the request of subscribing to, aforementioned provide two kinds of solutions, at this, be proposed by the corresponding solution that the extension of notice request is provided individually below for both solutions.

·Corresponding solution 1

For support, LDAP is revised the subscription of DN operation, subscribes in request by the extension of the classification of notification condition being realized this subscription in subscription object level.

Correspondingly, the classification of attribute is extended the notice realizing that LDAP revises DN operation also by notice object level by notice request.

Such as, the attribute " operation " of object (<object>) is extended to " modifyDN ", and it represents amendment DN operation.

The attribute " DN " of object is for indicating the new DN of data object.

Object elements can increase an optional new attribute " oldDN " for indicating the old DN of data object.

Therefore, the notice of amendment DN operation can be passed through with the object level extension information realization that sends a notice:

<notification>,</notification>represent the origin identification of notice request level information respectively, terminate mark.

The mark of notice request level information is in this article by Reusability, for the purpose of simple declaration, is below not repeated to explain.

DN=" suMSubscriberId=sub2, subscriptionFunctionId=1, managedElementId=HSS1 " is for indicating the new DN of data object.

OldDN=" suMSubscriberId=sub1, subscriptionFunctionId=1, managedElementId=HSS1 " operation=" modifyDN " is for indicating the old DN of data object.

Operation=" modifyDN " represents that operation is for amendment DN.

This solution is applicable to centralized and distributed UDC and disposes.

·Corresponding solution 2

Still can adopt existing subscription specification defined for TS29.335 that LDAP revises DN operation to subscribe to, as used in subscription request existing "<notificationCondition>", but in notice request, put into two object elements, one of them represents " delete " (deletion) operation, and another represents that " add " (increase) operates and use notice object level extension information (<objectExt>) by the two<object>elements correlation in a modifyDN operation.

Such as, by the amendment DN operation to send a notice indicated by object level extension information, " suMSubscriberId=sub1; subscriptionFunctionId=1; managedElementId=HSS1 " is revised as " suMSubscriberId=sub2; subscriptionFunctionId=1, managedElementId=HSS1 ".MODIFY_DN_OPERATION_ID value identical in two object elements can be associated in together.

At this,

DN=" suMSubscriberId=sub1, subscriptionFunctionId=1, managedElementId=HSS1 " represents the identification name of object；Corresponding operation is for deleting.

DN=" suMSubscriberId=sub2, subscriptionFunctionId=1, managedElementId=HSS1 " represents the identification name of object；Corresponding operation is for increasing.

Parameter name MODIFY_DN_OPERATION_ID represents that the name of parameter is called amendment DN Action number；Parameter value represents that amendment DN Action number is OP12345.

This solution is applicable to centralized and distributed UDC and disposes.

At this, it is necessary to explanation, those skilled in the art will be understood that the solution of the problems referred to above one to five and each problem is all merely illustrative, but not exhaustive to the notice problem that can solve of request of extension proposed by the invention or its corresponding solution.Due to it is desirable to provide a kind of general extension notice is asked, therefore, the notice request of this extension is possible not only to meet the existing notice demand that centralized, distributed user data base's middle finger given data are changed, including but not limited to the notice demand shown by above-mentioned each solution, it can be additionally used in issuable to other notice demands centralized, the change of distributed user data base's middle finger given data in the future.For other notice demands that are NM in the above embodiment of the present invention and that be likely to occur in the future; as it can be realized by extension notice request proposed by the invention; then should be comprised within the scope of patent protection of the present invention, and be incorporated herein with way of reference.

It should be noted that the present invention can be implemented in the assembly of software and/or software and hardware, for instance, special IC (ASIC), general purpose computer or any other similar hardware device can be adopted to realize.In one embodiment, the software program of the present invention can perform to realize steps described above or function by processor.Similarly, the software program of the present invention can be stored in computer readable recording medium storing program for performing (including the data structure being correlated with), for instance, RAM memory, magnetically or optically driver or floppy disc and similar devices.It addition, some steps of the present invention or function can employ hardware to realize, for instance, as coordinating with processor thus performing the circuit of each step or function_。

It addition, the part of the present invention can be applied to computer program, for instance computer program instructions, when it is computer-executed, by the operation of this computer, it is possible to call or provide the method according to the invention and/or technical scheme.And call the programmed instruction of the method for the present invention, it is possibly stored in fixing or moveable record medium, and/or by broadcast or data stream in other signal bearing medias and be transmitted, and/or be stored in the working storage of the computer equipment run according to described programmed instruction.At this, include a device according to one embodiment of present invention, this device includes the memorizer for storing computer program instructions and for performing the processor of programmed instruction, wherein, when this computer program instructions is performed by this processor, trigger this plant running based on the method for aforementioned multiple embodiments according to the present invention and/or technical scheme.

It is obvious to a person skilled in the art that the invention is not restricted to the details of above-mentioned one exemplary embodiment, and when without departing substantially from the spirit of the present invention or basic feature, it is possible to realize the present invention in other specific forms.Therefore, no matter from which point, embodiment all should be regarded as exemplary, and be nonrestrictive, the scope of the invention rather than described above limits, it is intended that all changes in the implication of the equivalency dropping on claim and scope be included in the present invention.Any accompanying drawing labelling in claim should be considered as the claim that restriction is involved.Furthermore, it is to be understood that " including " word is not excluded for other unit or step, odd number is not excluded for plural number.Multiple unit or the device stated in system claims can also be realized by software or hardware by a unit or device.The first, the second word such as grade is used for representing title, and is not offered as any specific order.

Claims

1. one kind for the subscribing to about the device of the notice of data variation in customer data base of front end in user data fusion architecture, wherein, described user data fusion architecture at least includes multiple front end (FE) and at least one customer data base LIST SERVER (DS)；

Wherein, this device is used for:

The appointment information of-subscription request level；

The appointment information of-subscription object level.

2. device according to claim 1, wherein, described user data fusion architecture is distributed user data fusion framework, and described distributed user data fusion framework includes multiple front end (FE), multiple customer data base proxy server (PS) and multiple customer data base LIST SERVER (DS)；

Wherein, this device is further used for:

-send described subscription request via the PS corresponding to current FE to described target DS, to receive described notice request from a PS.

3. device according to claim 1 and 2, wherein, described subscription extension information includes following at least any one:

-subscribe to request level extension information；

-subscribe to object level extension information.

4. device according to claim 3, wherein, described subscription request level extension information is for indicating the subscription to the appointment information subscribing to request level, and described subscription object level extension information is for indicating the subscription to the appointment information subscribing to object level.

5. the device according to claim 3 or 4, wherein, described subscription object level extension information includes the extension to requestedData attribute of an element classification.

6. one kind for the device notifying data variation subscribed in its customer data base of customer data base LIST SERVER in user data fusion architecture, wherein, described user data fusion architecture includes multiple front end (FE) and at least one customer data base LIST SERVER (DS)；

Wherein, this device is used for:

The additional information of-notice request level；

The additional information of-notice object level；

The additional information of-notice object properties level.

7. device according to claim 6, wherein, described user data fusion architecture is distributed user data fusion framework, and described distributed user data fusion framework includes multiple front end (FE), multiple customer data base proxy server (PS) and multiple customer data base LIST SERVER (DS)；

Wherein, this device is further used for:

-subscribe to request in response to the described of at least one FE described, via described PS, at least one FE described, each sends described notice request respectively.

8. the device according to claim 6 or 7, wherein, described notice extension information includes following at least any one:

-notice request level extension information；

-notice object level extension information；

-notification properties level extension information.

9. device according to claim 8, wherein, described notice request level extension information is for indicating the additional information of notice request level, described notice object level extension information is for indicating the additional information of notice object level, and described notification properties level extension information is for indicating the additional information of notice object properties level.

10. device according to claim 8 or claim 9, wherein, described notice object level extension information includes the Attribute class purpose to current DS and extends.

11. subscribe to and notice is about a user data fusion architecture for data variation in customer data base, wherein, described user data fusion architecture includes multiple front end (FE) and at least one customer data base LIST SERVER (DS)；

Wherein, each FE pulled subscription for:

The appointment information of-subscription request level；

The appointment information of-subscription object level；

Wherein, each DS sending notice is used for:

The additional information of-notice request level；

The additional information of-notice object level；

The additional information of-notice object properties level.

12. user data fusion architecture according to claim 11, wherein, described user data fusion architecture is distributed user data fusion framework, and described distributed user data fusion framework includes multiple front end (FE), multiple customer data base proxy server (PS) and multiple customer data base LIST SERVER (DS)；

Wherein, each FE pulled subscription is further used for:

-send described subscription request via the PS corresponding to current FE to described target DS, to receive described notice request from a PS；

Wherein, each DS sending notice is further used for:

-subscribe to request in response to the described of at least one FE described, via one or more PS, at least one FE described, each sends described notice request respectively.

13. one kind for the subscribing to about the method for the notice of data variation in customer data base of front end in user data fusion architecture, wherein, described user data fusion architecture at least includes multiple front end (FE) and at least one customer data base LIST SERVER (DS)；

Wherein, the method includes:

The appointment information of-subscription request level；

The appointment information of-subscription object level.

14. one kind for the method notifying data variation subscribed in its customer data base of customer data base LIST SERVER in user data fusion architecture, wherein, described user data fusion architecture includes multiple front end (FE) and at least one customer data base LIST SERVER (DS)；

Wherein, the method includes:

The additional information of-notice request level；

The additional information of-notice object level；

The additional information of-notice object properties level.