JP5122024B2 - Managing user data convergence (UDC) notifications - Google Patents
Managing user data convergence (UDC) notifications Download PDFInfo
- Publication number
- JP5122024B2 JP5122024B2 JP2012514544A JP2012514544A JP5122024B2 JP 5122024 B2 JP5122024 B2 JP 5122024B2 JP 2012514544 A JP2012514544 A JP 2012514544A JP 2012514544 A JP2012514544 A JP 2012514544A JP 5122024 B2 JP5122024 B2 JP 5122024B2
- Authority
- JP
- Japan
- Prior art keywords
- application
- udr
- group identifier
- operation request
- user
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/63—Routing a service request depending on the request content or context
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
Description
本出願は、2009年6月11日に提出された米国仮出願61/186,240号の優先権を主張するものである。 This application claims the priority of US Provisional Application No. 61 / 186,240, filed Jun. 11, 2009.
本発明は、全体として通信ネットワークに関するものであり、具体的には、通信ネットワークにおけるユーザデータ・リポジトリ(UDR:User Data Repository)と複数のアプリケーション・フロントエンド(アプリケーションFE:Application Front End)との間のユーザデータ・コンバージェンス(UDC:User Data Convergence)通知を管理するためのシステム及び方法に関するものである。 The present invention generally relates to a communication network, and specifically, between a user data repository (UDR) and a plurality of application front ends (application FE) in the communication network. The present invention relates to a system and method for managing User Data Convergence (UDC) notifications.
ユーザデータ・コンバージェンス(UDC)は、現在、第3世代パートナシップ・プロジェクト(3GPP)によって開発されている。技術仕様3GPP TS 23.355では、UDCの技術的な実現について説明されており、UDCは、異なる複数のネットワーク・エレメントのアプリケーション・ロジックからユーザデータを分離する。ユーザデータ・リポジトリ(UDR)は、集中型データベースを提供し、当該データベースは、異なる複数のアプリケーションFEによってアクセスされる。 User Data Convergence (UDC) is currently being developed by the 3rd Generation Partnership Project (3GPP). Technical specification 3GPP TS 23.355 describes the technical realization of UDC, which separates user data from the application logic of different network elements. The user data repository (UDR) provides a centralized database that is accessed by different application FEs.
図1は、一般的なUDCアーキテクチャ10の簡略化したブロック図である。ユーザデータは、UDR11に保存される。アプリケーション・フロントエンド(FE)12a〜12cは、データ無しの機能的なエンティティである。アプリケーションFEは、ホーム・ロケーション・レジスタ(HLR)、ホーム加入者サーバ(HSS)、認証センタ(AUS)、アプリケーション・サーバ(AS)、プロビジョニング・システム等の、機能的なネットワーク・エンティティのアプリケーション・ロジックを保持するが、局所的に、ユーザデータを恒久的には保存することがない。アプリケーションFEは、1つ以上のアプリケーションを同時に処理しうる。UDCアーキテクチャは、ダイアメータ(Diameter)、モバイル・アプリケーション・プロトコル(MAP)、セッション確立プロトコル(SIP)、またはその他の適切なプロトコル等の、プロトコル14を介して、コアネットワーク、サービス・レイヤ、及びオペレーション・サポート・システム(OSS)13とのインタフェースとして機能する。UDCの実装の要求条件は、既存のネットワークに対する影響を最小限にすることである。
FIG. 1 is a simplified block diagram of a
図2は、UDR11が、複数のHLR−FE22a〜22eとして実装されている複数のアプリケーションFEのためのユーザデータを提供する、UDCアーキテクチャの簡略化したブロック図である。複数のHLR−FEは、同様に、複数のMSC/VLR22a〜22eをサポートする。同図から明らかなように、各アプリケーションFEは、「フロントエンド識別子」として通常知られている個別の識別子を用いて構成されており、当該識別子は、当該アーキテクチャに含まれる他のエンティティとの通信を確立するために使用される。UDRと複数のHLR−FEとの間のインタフェース23は、UDR内の特定のユーザデータに対して起こりうる特定のイベントについて、関連のあるHLR−FEにUDRが通知することを可能にする通知機能をサポートしている。当該イベントは、既存のユーザデータに対する変更、ユーザデータに対する追加等であってもよい。コアネットワーク及びサービス・レイヤ・アプリケーションは、これらの通知を明示的に予約(subscribe)してもよい。例えば、(アプリケーションFEの一例としての)ASは、特定のユーザデータに対する変更情報を受信することを予約してもよい。あるいは、コアネットワーク及びサービス・レイヤ・アプリケーションは、UDCコンセプトに従った通知を黙示的に予約してもよい。例えば、ユーザが位置しているという通知とその位置情報は、管理上で削除されてもよい。
FIG. 2 is a simplified block diagram of a UDC architecture in which
「HLR」等の特定のアプリケーション・タイプの任意のアプリケーションFEは、当該アプリケーション・タイプに関連するコアネットワーク/サービス・レイヤ/OSS内のエレメントのいずれかに対する通知を処理するのに適していることが想定されている。このため、図2では、UDR11が任意のHLR−FE21a〜21cに、ユーザデータの変更を通知可能であり、また、通知を受けたHLR−FEが、条件(例えば、ユーザの地理的位置)を問わず、MSC/VLR22a〜22cのいずれかに通知可能であることが想定されている。したがって、UDRが、特定のHLR−FEに通知を送信することを懸念することはない。
Any application FE of a particular application type such as “HLR” may be suitable for handling notifications for any of the elements in the core network / service layer / OSS associated with that application type. Assumed. Therefore, in FIG. 2, the
しかし、大規模なネットワークを有するオペレータによっては、例えば複数の信号中継局(STP:Signaling Transfer Point)によって接続された複数のエリアネットワークに、ネットワーク全体が分割されているルーティング階層を利用する可能性がある。このネットワーク構成では、第1のエリアネットワーク内のHLR−FEは、第2のエリアネットワーク内のMSC/VLRに対する「直接の」シグナリング・コネクションを有しない可能性がある一方で、1つ以上のSTPを通じてシグナリングがルーティングされる「間接の」コネクションを有する可能性がある。また、通信ネットワークにおいて全てのノードを相互にメッシュ状にすることは、通常、複雑かつ高価な開発を必要とすることを考慮すると、例えば他の地理的位置のエリア内の全てのMSC/VLRとのシグナリング・コネクションをHLR−FEが有しえないことが生じる可能性がある。このため、特定のMSC/VLRに対して影響を与えるデータの変更について、UDRは、影響を受ける当該MSC/VLRに到達することができないHLR−FEを当該UDRが選択することがないように、HLR−FEの選択を管理しなければならない。 However, there is a possibility that an operator having a large-scale network may use a routing hierarchy in which the entire network is divided into a plurality of area networks connected by a plurality of signal relay stations (STPs). is there. In this network configuration, the HLR-FE in the first area network may not have a “direct” signaling connection to the MSC / VLR in the second area network, while one or more STPs It is possible to have an “indirect” connection through which signaling is routed. Also, considering that all nodes in a communication network are meshed with each other usually requires complex and expensive development, for example, all MSC / VLRs in other geographical locations May not be possible for the HLR-FE. Therefore, for data changes that affect a particular MSC / VLR, the UDR will not select an HLR-FE that cannot reach the affected MSC / VLR, HLR-FE selection must be managed.
この課題を解決するための3GPPにおいて規定された仕組みは、現時点では存在しない。これは、定義された全てのエリアネットワークに全てのアプリケーションFEが到達することが想定されていないためである。現在の仕様では、ULRは、ユーザによらず、かつ、当該ユーザの「位置」によらず、任意のアプリケーションFEを選択して、データ変更の通知を送信(例えば、プロビジョニング)する。したがって、UDRは、通知を必要としているネットワーク・エレメントに対して当該通知を提供することができないアプリケーションFEに、当該通知を送信する可能性がある。本発明は、UDRと複数のアプリケーションFEとの間のUDC通知を管理するための方法及び装置を提供することで、この課題を解決する。 At present, there is no mechanism defined in 3GPP for solving this problem. This is because it is not assumed that all application FEs reach all defined area networks. According to the current specification, the ULR selects an arbitrary application FE regardless of the user and regardless of the “position” of the user, and transmits (for example, provisioning) a data change notification. Therefore, the UDR may send the notification to the application FE that cannot provide the notification to the network element that needs the notification. The present invention solves this problem by providing a method and apparatus for managing UDC notifications between a UDR and multiple application FEs.
一実施形態において、本発明は、通信ネットワーク内の複数のアプリケーションFEから、イベント通知を受信するアプリケーションFEを選択するための、UDRにおける方法を対象としている。本方法は、複数のアプリケーションFEのそれぞれに関連付けられたアプリケーション・タイプ及びグループ識別子をデータベースに追加するステップを含み、各グループ識別子は、関連付けられたアプリケーションFEを介してアクセス可能な、通信ネットワークに含まれる異なる部分を識別する。本方法は、更に、その後、特定のユーザのユーザデータの変更を報告するためのイベント通知手続を開始するステップと、選択されるアプリケーションFEのアプリケーション・タイプ及びグループ識別子に基づいて、イベント通知を受信するアプリケーションFEを選択するステップとを含む。複数のアプリケーションFEのうちの1つからUDR操作リクエストが受信された際に、当該複数のアプリケーションFEのそれぞれについてのアプリケーション・タイプ及びグループ識別子を保存することによって、データベースに追加されてもよい。所与のアプリケーションFEについてのグループ識別子は、所定の条件が満たされた場合にデータベース内で更新されてもよい。 In one embodiment, the present invention is directed to a method in UDR for selecting an application FE that receives an event notification from a plurality of application FEs in a communication network. The method includes adding an application type and group identifier associated with each of a plurality of application FEs to a database, each group identifier being included in a communication network accessible via the associated application FE. Identify different parts. The method then further initiates an event notification procedure for reporting a change in user data for a particular user and receives an event notification based on the application type and group identifier of the selected application FE. Selecting an application FE to be executed. When a UDR operation request is received from one of the plurality of application FEs, it may be added to the database by storing the application type and group identifier for each of the plurality of application FEs. The group identifier for a given application FE may be updated in the database when a predetermined condition is met.
任意的に、本方法は、複数のアプリケーションFEのそれぞれに、負荷分散重みを割り当てるステップと、さらに、割り当てられている負荷分散重みを、アプリケーションFEの選択の基礎とするステップとを含んでいてもよい。 Optionally, the method may include assigning load balancing weights to each of the plurality of application FEs, and further using the assigned load balancing weights as a basis for selection of the application FE. Good.
別の実施形態において、本発明は、通信ネットワーク内の複数のアプリケーションFEから、イベント通知を受信するアプリケーションFEを選択するための、UDRにおける装置を対象としうる。本装置は、複数のアプリケーションFEのそれぞれに関連付けられたアプリケーション・タイプ及びグループ識別子をデータベースに追加する手段であって、各グループ識別子は、関連付けられたアプリケーションFEを介してアクセス可能な、通信ネットワークに含まれる異なる部分を識別する、追加する手段と、その後、特定のユーザのユーザデータの変更を報告するために、イベント通知手続を開始する手段と、選択されるアプリケーションFEのアプリケーション・タイプ及びグループ識別子に基づいて、イベント通知を受信するアプリケーションFEを選択する手段とを備える。データベースに追加する手段は、複数のアプリケーションFEのうちの1つからUDR操作リクエストが受信された際に、当該複数のアプリケーションFEのそれぞれについてのアプリケーション・タイプ及びグループ識別子を保存してもよい。所与のアプリケーションFEについてのグループ識別子は、所定の条件が満たされた場合にデータベース内で更新されてもよい。 In another embodiment, the present invention may be directed to an apparatus in UDR for selecting an application FE that receives an event notification from a plurality of application FEs in a communication network. The apparatus is a means for adding an application type and a group identifier associated with each of a plurality of application FEs to the database, and each group identifier is connected to a communication network accessible via the associated application FE. Means for identifying and adding different parts included, then means for initiating an event notification procedure to report a change in user data of a particular user, and the application type and group identifier of the selected application FE And means for selecting an application FE that receives the event notification. The means for adding to the database may store an application type and a group identifier for each of the plurality of application FEs when a UDR operation request is received from one of the plurality of application FEs. The group identifier for a given application FE may be updated in the database when a predetermined condition is met.
任意的に、イベント通知を受信するアプリケーションFEを選択する手段は、複数のアプリケーションFEのそれぞれに割り当てられた負荷分散重みに基づいて、アプリケーションFEを選択してもよく、所与のアプリケーションFEが、前記特定のユーザにサービスを行うサービスノードに対して直接のコネクションを有する場合には、高い負荷分散重みが当該所与のアプリケーションFEに割り当てられており、当該所与のアプリケーションFEが、前記特定のユーザにサービスを行うサービスノードに対して間接のコネクションのみを有する場合には、低い負荷分散重みが当該所与のアプリケーションFEに割り当てられている。 Optionally, the means for selecting the application FE that receives the event notification may select the application FE based on a load balancing weight assigned to each of the plurality of application FEs, where a given application FE is When having a direct connection to the service node serving the specific user, a high load distribution weight is assigned to the given application FE, and the given application FE If there is only an indirect connection to the service node serving the user, a low load distribution weight is assigned to the given application FE.
本発明は、UDR通知に関連した目的で、ネットワーク・トコポジの考察を有利に考慮する。本発明は、全てのコアネットワーク・エレメントが、関連する(1つまたは複数の)全てのアプリケーションFEに接続されているとは限らない配置を対象とする。本発明は、グループID及び負荷分散重みを使用することによって、UDR通知に関連した負荷分散メカニズムについての柔軟性を提供する。その結果、当該通知に関連した負荷が、それに応じて分散されうる。本発明は、UDR通知に関連した目的で、拡張性のあるソリューションも提供する。これは、関連するグループIDのUDR設定の修正のみが、より多くのアプリケーションFEを追加するために必要とされるためである。最後に、本発明は、UDR通知に関連した目的で、耐障害性ソリューションを提供する。これは、通知を発行するために特定のグループID値を共有する全てのアプリケーションFEの中からUDRが選択できるためである。 The present invention advantageously takes into account network topology considerations for purposes related to UDR notification. The present invention is directed to an arrangement where not all core network elements are connected to all associated application (s) FE. The present invention provides flexibility for the load balancing mechanism associated with UDR notification by using group IDs and load balancing weights. As a result, the load associated with the notification can be distributed accordingly. The present invention also provides a scalable solution for purposes related to UDR notification. This is because only the modification of the UDR setting of the associated group ID is required to add more application FEs. Finally, the present invention provides a fault tolerant solution for purposes related to UDR notification. This is because the UDR can be selected from all application FEs that share a specific group ID value to issue a notification.
図3は、本発明を実装するのに適したUDRアーキテクチャについての簡略化したブロック図である。オペレータのネットワーク全体は、信号中継局(STP1)33によって接続された、第1のエリアネットワーク(エリアネットワーク1)31と第2のエリアネットワーク(エリアネットワーク2)32とに分割される。このネットワーク構成において、修正されたUDR30は、HLR−FE34a〜34eとして実装される複数のアプリケーションFEのためのユーザデータを提供する。同様に、HLR−FEは、複数のMSV/VLR35a〜35eをサポートする。しかし、HLR−FEの全てが、全てのMSC/VLRに到達できるわけではない。例えば、エリアネットワーク2内に位置するHLR−FE5は、エリアネットワーク1内に位置するMSC/VLR1またはMSC/VLR2に、到達することができない。その他のいくつかの場合において、いくつかのHLR−FEは、STP1を介してのみ、間接的にMSC/VLRに到達することができる。例えば、エリアネットワーク2内に位置するHLR−FE3は、STP1を介してのみ、エリアネットワーク1内に位置するMSC/VLR1に到達することができる。これらの場合、たとえアクセスが可能であっても、オペレータは、最短のパスを使用してMSC/VLR1に到達することを望むこともありうる。例えば、HLR−FE3は、MSC/VLR1に到達するためには最良の選択ではない可能性がある。これは、HLR−FE1またはHLR−FE2からの「直接の」パスが、STPを介したルーティング・シグナリングを全く必要とせず、より適切であるためである。
FIG. 3 is a simplified block diagram of a UDR architecture suitable for implementing the present invention. The entire operator network is divided into a first area network (area network 1) 31 and a second area network (area network 2) 32 connected by a signal relay station (STP1) 33. In this network configuration, the modified
適切なMSC/VLRに通知を確実に到達させるため、及び、最適なパスが確実に利用されるようにするため、UDRは、発行された通知をどこに送信するのかを決定する際に、ルーティングの決定を行わなければならない。例えば、回線交換/パケット交換(CS/PS)ユーザがエリアネットワーク1内に位置するMSC/VLRによって管理される予定であることコアネットワークが決定する場合には、「マップ位置更新(MAP Location Update)」操作情報が、(通常の場合)MSC/VLR1またはMSC/VLR2から、HLR−FE1またはHLR−FE2に向かって送信される。その後、UDRは、このユーザについてのHLR関連通知(HLR-related notification)を送信する必要がありうる。例えば、このユーザについてのCS/PS関連属性(CS/PS-related attribute)が、プロビジョニング・エンティティによってUDRにおいて変更されており、この新たなデータは、このユーザの「ホスティング」を現在行っているMSC/VLRエレメントにおいて更新される必要がある。この場合、MSC/VLR1またはMSC/VLR2へ通知を配信するためには、HLR−FE1またはHLR−FE2を選択することが、UDRにとっての最適な選択であろう。このUDR通知によってトリガされる最終的なMAP操作情報がSTP1を介してMSC/VLR1またはMSC/VLR2に到達しなければならないため、HLR−FE3またはHLR−FE4は最適な選択ではなく、遅延の理由から望ましくないであろう。なお、UDRは、このCS/PSユーザ関連通知を、HLR−FE5に対して送信してはならない。これは、HLR−FE5が、STP1に対するコネクションを有しておらず、それ故に、エリアネットワーク1内に位置するいずれのMSC/VLRに対しても到達する方法を有していないためである。
In order to ensure that notifications reach the appropriate MSC / VLR and to ensure that the best path is utilized, the UDR is responsible for routing decisions when deciding where to send issued notifications. A decision must be made. For example, if the core network determines that a circuit-switched / packet-switched (CS / PS) user is to be managed by an MSC / VLR located in the
本発明は、オペレータのネットワーク内のアプリケーションFEを設定するための新たなパラメータを導入する。UDR30に保存される追加的な情報は、例えばあるユーザのデータが修正された際に発行される通知の送信先となる、適切な(1つまたは複数の)アプリケーションFEをUDRが選択することを可能にする。
The present invention introduces new parameters for configuring the application FE in the operator's network. The additional information stored in the
3GPP TS 23.335によれば、オペレータのネットワーク内の各アプリケーションFEは、そのアプリケーション・タイプ(Application Type)(例えば、AppType=HLR−FE、AppType=HSS−FE等)を定義するように設定されている。本発明は、さらに、UDRにおける新たなパラメータ、即ち、アプリケーションFEがサービスを行う「(1つまたは複数の)エリアネットワーク」に関連付けられた「グループ識別子」(グループID:GroupId)を用いてアプリケーションFEを設定する。特定のアプリケーションFEが、1つ以上のエリアネットワークにサービスを行う場合、当該特定のアプリケーションFEは、サービスが行われる各エリアネットワークに対応するグループIDを用いて、UDRにおいて設定される。例えば、図3のHLR−FE3は、エリアネットワーク2に属するように設定されるが、エリアネットワーク1に属するようにも設定されうる。これは、HLR−FE3が、エリアネットワーク1内のMSC/VLRに、STP1(33)を介して間接的に接続可能であるためである。
According to 3GPP TS 23.335, each application FE in the operator's network is set to define its Application Type (eg, AppType = HLR-FE, AppType = HSS-FE, etc.). ing. The present invention further uses a new parameter in UDR, ie, a “group identifier” (group ID: GroupId) associated with “(one or more) area networks” served by the application FE. Set. When a specific application FE services one or more area networks, the specific application FE is set in the UDR using a group ID corresponding to each area network where the service is performed. For example, the HLR-FE 3 in FIG. 3 is set to belong to the
一例として、全てのHLR−FEが、「AppType=HLR−FE」(全てについて同一のAppType値)を用いて設定されうるとともに、それらは「エリアネットワーク」においてグループ化されうる。このため、同一のエリアネットワーク内に配置された全てのHLR−FEは、同一のグループID値を共有し、当該グループID値は、当該エリアネットワークに割り当てられる。この情報は、UDR内に保存されてもよいし、または、UDRがアクセス可能なデータベース内に保存されてもよい。HLR−FEが、取り出し/更新リクエスト(本明細書では、共通して「UDR操作リクエスト」と称する。)をUDRへ送信する場合、UDRは、当該リクエストから、当該リクエスト中のHLR−FEに関連付けられたAppType値およびグループID値を得ることができる。好ましくは、特定のアプリケーションFEのアプリケーション・タイプ(AppType)は、フロントエンド識別子から、またはそれに対応するグループ識別子(グループID)から得られることが好ましい。 As an example, all HLR-FEs can be configured with “AppType = HLR-FE” (the same AppType value for all) and they can be grouped in an “area network”. For this reason, all HLR-FEs arranged in the same area network share the same group ID value, and the group ID value is assigned to the area network. This information may be stored in the UDR or may be stored in a database accessible to the UDR. When the HLR-FE sends a fetch / update request (commonly referred to herein as a “UDR operation request”) to the UDR, the UDR associates the request with the HLR-FE in the request. The obtained AppType value and the group ID value can be obtained. Preferably, the application type (AppType) of a particular application FE is preferably obtained from the front end identifier or from the corresponding group identifier (group ID).
これは、LDAPがUDRデータアクセス・インタフェースである場合には、それぞれが特定のAppType値及び特定のグループID値を有する、種々の「ディレクトリアクセス認証情報(credentials)」エントリを定義することによって達成されうる。同一の「ディレクトリアクセス認証情報」エントリを使用してLDAPセッションを確立する全てのHLR−FEは、同一のAppType及び同一のグループIDを共有する。 This is accomplished by defining various “directory access credentials” entries, each with a specific AppType value and a specific group ID value, when LDAP is a UDR data access interface. sell. All HLR-FEs that establish an LDAP session using the same “directory access authentication information” entry share the same AppType and the same group ID.
MSC/VLRが、選択されたHLR−FEを介してCS/PSユーザデータの取り出し/更新をリクエストする場合、または、S−CSCFが、選択されたHSS−FEを介してIMSユーザデータの取り出し/更新をリクエストする場合、当該選択されたHLR−FEまたはHSS−FEは、UDRにアクセスして、いわゆるUDR操作リクエスト(例えば、LDAP操作)によってCS/PSユーザ関連データの取り出し/更新を行う。UDRは、このリクエストされた操作を確認するとともに、関係するAppTypeに対応する選択されたHLR−FEまたはHSS−FEに関連付けられた(1つまたは複数の)グループID値が、ユーザレベルで(即ち、UDRによってユーザとの関係で保持されているデータの一部として)保存されているか否かを判定する。例えば、特定のユーザについての「CS位置データ」の更新(即ち、当該ユーザを現在管理しているMSC/VLRエンティティを保存しているユーザ属性の更新)を行うために、HLR−FEがUDRに対して操作をリクエストするごとに、UDRは、当該関係するユーザについて、この更新リクエストを発行している特定のHLR−FEに割り当てられている(1つまたは複数の)グループIDを有するAppType=HLR−FEに関連付けられたグループID値を更新する。 When MSC / VLR requests CS / PS user data retrieval / update via selected HLR-FE, or S-CSCF retrieves IMS user data via selected HSS-FE / When requesting an update, the selected HLR-FE or HSS-FE accesses the UDR and retrieves / updates the CS / PS user related data by a so-called UDR operation request (for example, an LDAP operation). The UDR confirms this requested operation and the group ID (s) associated with the selected HLR-FE or HSS-FE corresponding to the relevant AppType is at the user level (ie , Determine whether it is stored (as part of the data held by the UDR in relation to the user). For example, in order to update the “CS location data” for a particular user (ie, update the user attribute that stores the MSC / VLR entity that currently manages the user), the HLR-FE is in UDR. Each time an operation is requested for an UDR, AppType = HLR with the group ID (s) assigned to the particular HLR-FE issuing this update request for the relevant user. -Update the group ID value associated with the FE.
その後、保存された[AppType,(1つまたは複数の)グループID値]のペアは、UDRにおいて保存/管理されているユーザごとに、特定のユーザについての特定のアプリケーション・タイプに関連する発行された通知を報告するのに利用可能な、当該特定のアプリケーション・タイプの複数のアプリケーションFEから成るグループを識別する。また、UDRは、識別される複数のアプリケーションFE間で、通知の負荷分散を行うために、予め設定された決定論的なアルゴリズムを利用しうる。特定のアプリケーション・タイプに対応する全てのアプリケーションFEが、あるエリアに対して一様に有効である場合には、UDRは、任意のアプリケーションFEを使用できるため、可能性のある複数のアプリケーションFEから成るリストを用いて設定される必要がない。 The saved [AppType, group ID value (s)] pair is then issued for each user stored / managed in the UDR, associated with a specific application type for a specific user. Identifies a group of application FEs of that particular application type that can be used to report notifications. Further, the UDR can use a predetermined deterministic algorithm in order to perform load distribution of notification among a plurality of identified application FEs. If all application FEs corresponding to a specific application type are uniformly valid for a certain area, UDR can use any application FE, and thus from multiple possible application FEs. Need not be set up with a list of
保存された[AppType,(1つまたは複数の)グループID値]のペアは、UDRから、このAppTypeに属するアプリケーションFE(または複数のアプリケーションFEから成るグループ)に、ユーザについて発行される任意の通知に対して適用されることに留意されたい。したがって、[AppType,(1つまたは複数の)グループID値]のペアは、「ユーザ」に関係するとともに、特定のAppTypeに関係する一方で、複数のユーザ関連属性から成る特定のグループに関係することは全くない。 The saved [AppType, group ID value (s)] pair is an arbitrary notification issued for the user from the UDR to the application FE (or group consisting of multiple application FEs) belonging to this AppType. Note that this applies to. Thus, a pair of [AppType, group ID value (s)] relates to a “user” and to a specific group of user-related attributes while related to a specific AppType. There is nothing at all.
図4は、UDR操作がステップ41においてリクエストされた際に、グループID属性を更新するか否かを決定する方法の一実施形態に含まれるステップを示すフローチャートである。複数のFE(例えば、HLR−FE34a〜34e)のいずれかからリクエストされるUDR操作は、UDR内の、関係する(1または複数の)ユーザのデータをアドレス指定するために使用可能な識別子を含む。特定ユーザの(本明細書では「ユーザ・アプリケーションデータ」または「ユーザデータ」と称される)データの取り出し/更新を直近にリクエストしたアプリケーションFEの(1つまたは複数の)グループID値をUDRが保存/更新するか否かを決定するための基準/条件のセットが、UDRによって既知の各AppTypeについて指定される。図4に示す条件は例示のみであり、特定ユーザのユーザデータの取り出し/更新を直近にリクエストしたアプリケーションFEの(1つまたは複数の)グループID値をUDRが保存/更新するか否かを決定する際に、追加の条件を考慮することも可能である。
FIG. 4 is a flowchart illustrating steps included in one embodiment of a method for determining whether to update a group ID attribute when a UDR operation is requested in
ステップ42では、リクエストを送信するアプリケーションFEに関連付けられているアプリケーション・タイプ(AppType)が、特定のエリアネットワークに関連付けられているか否かが判定される。HLR及びHSSは特定のエリアネットワークに関連付けられているため、例えば、AppType=HLR、または、AppType=HSSは、更新処理を必要としうる。AppTypeが、特定のエリアネットワークに関連付けられていない場合には、本方法はステップ43に移行し、グループID値は更新されない。AppTypeが特定のエリアネットワークに関連付けられている場合には、本方法はステップ44に移行し、当該ステップにおいて、アプリケーションFEによってリクエストされているデータベース操作が、更新リクエストまたは作成リクエスト等のオリジネーティング・リクエスト(originating request)であるか、取り出しリクエストまたは削除リクエスト等のターミネーティング・リクエスト(terminating request)であるかが判定される。典型的には、リクエストされた操作が更新である場合、この情報は、いずれのアプリケーションFEがオリジネーティング・リクエスト(例えば、IMS登録)に対応するユーザに対処しているかを知ることについて関連性があるため、UDRは、(1つまたは複数の)グループID値を保存する。ターミネーティング・リクエストについては、実行される操作はデータの取り出しであり、これは、典型的には、UDR内のグループIDを更新させる結果とはならない。したがって、アプリケーションFEによってリクエストされているデータベース操作がターミネーティング・リクエストである場合、本方法はステップ43に移行して、グループID値は更新されない。
In
アプリケーションFEによってリクエストされているデータベース操作が、オリジネーティング・リクエストである場合、本方法はステップ45に進み、当該ステップにおいて、修正されたユーザ・アプリケーションデータが、グループIDに関連しているか否かが判定される。この(関連している/関連していない)要素は、修正されたデータのタイプに依存しうるとともに、ユーザの位置に関連したデータ(例えば、割り当てられたMSC/VSR名、または割り当てられたS−CSCF名、特定のサービスに関連したユーザデータ等)等の、特定のデータタイプに、UDR内で関連した属性である可能性がある。例えば、ユーザが登録されているS−CSCFの名前が変わる場合、UDRは、グループID値を保存する。これは、ユーザが別のエリア(即ち、異なるグループID値を有するエリア)に移動した可能性があるためである。あるいは、操作の結果としてユーザの転送先番号(forwarded-to number)等のユーザデータが変わる場合、UDRは、グループID値を保存/上書きする必要はない。したがって、修正されたユーザ・アプリケーションデータがグループIDに関連していない場合、本方法はステップ43に移行して、グループID値は更新されない。 If the database operation requested by the application FE is an originating request, the method proceeds to step 45, where the modified user application data is related to the group ID. Is determined. This (related / unrelated) element may depend on the type of data modified and data related to the user's location (eg, assigned MSC / VSR name or assigned S -Attributes that are relevant in the UDR for a particular data type, such as CSCF name, user data associated with a particular service, etc.). For example, if the name of the S-CSCF to which the user is registered changes, the UDR stores the group ID value. This is because the user may have moved to another area (ie, an area having a different group ID value). Alternatively, if user data such as a forwarded-to number of the user changes as a result of the operation, the UDR does not need to save / overwrite the group ID value. Thus, if the modified user application data is not associated with a group ID, the method moves to step 43 and the group ID value is not updated.
修正されたユーザ・アプリケーションデータがグループIDに関連している場合、本方法はステップ46に移行し、当該ステップにおいて、リクエストされた操作がUDRにおいて成功したか否かが判定される。成功しなかった場合、本方法はステップ43に移行して、グループID値は更新されない。リクエストされた操作がUDRにおいて成功した場合、本方法はステップ47に進み、当該ステップにおいて、グループID値が更新される。 If the modified user application data is associated with a group ID, the method moves to step 46, where it is determined whether the requested operation was successful in UDR. If unsuccessful, the method moves to step 43 and the group ID value is not updated. If the requested operation is successful in UDR, the method proceeds to step 47, where the group ID value is updated.
適用可能な条件は、各AppTypeに関連付けてUDRにおいて設定されうる。例えば、条件のセットは、AppType=HLR−FEに対応して設定されうるし、AppType=HSS−FEに対応して設定されうる、等である。 Applicable conditions can be set in the UDR in association with each AppType. For example, the set of conditions can be set corresponding to AppType = HLR-FE, can be set corresponding to AppType = HSS-FE, and so on.
3GPP TS 23.335では、UDRは、現在、UDRに接続するアプリケーションFEを認証することが要求されており、それ故に、各アプリケーションFEについての認証データを既に保管している。新しいグループID値は、UDRにおいて管理されることになる、各アプリケーションFEに関連付けられた追加の属性である。 In 3GPP TS 23.335, the UDR is currently required to authenticate application FEs that connect to the UDR, and therefore has already stored authentication data for each application FE. The new group ID value is an additional attribute associated with each application FE that will be managed in UDR.
再び図3を参照すると、UDR30に設定されている、配置されたHLR−FE34a〜34eを記述する設定パラメータの一例は、以下のとおりである。
・HLR−FE1 →[AppType=HLR−FE,グループID=AN1]
・HLR−FE2 →[AppType=HLR−FE,グループID=AN1]
・HLR−FE3 →[AppType=HLR−FE,グループID=AN2]
・HLR−FE4 →[AppType=HLR−FE,グループID=AN2]
・HLR−FE5 →[AppType=HLR−FE,グループID=AN2]
Referring to FIG. 3 again, an example of setting parameters describing the arranged HLR-
-HLR-FE1 [AppType = HLR-FE, group ID = AN1]
-HLR-FE2 → [AppType = HLR-FE, group ID = AN1]
-HLR-FE3 → [AppType = HLR-FE, group ID = AN2]
-HLR-FE4 [AppType = HLR-FE, group ID = AN2]
-HLR-FE5 [AppType = HLR-FE, group ID = AN2]
負荷分散重みが、各アプリケーションFEについて更に保存されてもよい。当該重みは、特定のユーザに対して通知を送信するための特定のアプリケーションFEを選択することの望ましさ(desirability)を示しうる。上記の予め設定されたグループID値によって、かつ、負荷分散重みも含まれた状態で、通知分散(notification distribution)を目的としたUDRの設定は、以下のようになりうる。
(1)AppType=HLR−FE,グループID=AN1
・HLR−FE1(負荷分散重み:100)
・HLR−FE2(負荷分散重み:100)
・HLR−FE3(負荷分散重み:1)
・HLR−FE4(負荷分散重み:1)
(2)AppType=HLR−FE,グループID=AN2
・HLR−FE1(負荷分散重み:1)
・HLR−FE2(負荷分散重み:1)
・HLR−FE3(負荷分散重み:100)
・HLR−FE4(負荷分散重み:100)
・HLR−FE5(負荷分散重み:100)
The load distribution weight may be further stored for each application FE. The weight may indicate the desirability of selecting a specific application FE to send a notification to a specific user. The UDR setting for notification distribution with the above-described preset group ID value and including the load distribution weight can be as follows.
(1) AppType = HLR-FE, group ID = AN1
-HLR-FE1 (load distribution weight: 100)
-HLR-FE2 (load distribution weight: 100)
-HLR-FE3 (load distribution weight: 1)
-HLR-FE4 (load distribution weight: 1)
(2) AppType = HLR-FE, group ID = AN2
-HLR-FE1 (load distribution weight: 1)
-HLR-FE2 (load distribution weight: 1)
-HLR-FE3 (load distribution weight: 100)
-HLR-FE4 (load distribution weight: 100)
-HLR-FE5 (load distribution weight: 100)
なお、HLR−FE5はエリアネットワーク1内のいずれのMSC/VSRにも接続することはできないため、HLR−FE5は、グループID=AN1についてのリストには含まれていない。また、関連するエリアネットワーク内のMSC/VSRに対してSTP1を介して接続しなければならないHLR−FEには、低い負荷分散重みが割り当てられている一方で、関連するエリアネットワーク内のMSC/VSRに対して直接に接続するHLR−FEには、高い負荷分散重みが割り当てられている。当然ながら、FEを選択する際に追加的な要素を考慮するために、他の負荷分散重もありうる。
Since HLR-FE5 cannot be connected to any MSC / VSR in
最後に、AppType=HLR−FEについての(ユーザレベルで管理された)グループID属性を更新する、本例における条件は、以下のようになりうる。
AppType=HLR−FEについてのグループID値を更新する「条件のセット」
‐リクエストされた操作:更新
かつ
‐ユーザデータ:CS/PS位置データ
かつ
‐操作結果:成功
Finally, the conditions in this example for updating the group ID attribute (managed at the user level) for AppType = HLR-FE can be as follows:
“Set condition” to update group ID value for AppType = HLR-FE
-Requested operation: Update and-User data: CS / PS location data and-Operation result: Success
この条件のセットは、MAP位置更新の操作情報が、特定のユーザについて、選択されたHLR−FEに向けてMSC/VLRから発行された際に、UDR30が、当該選択されたHLR−FEについてのグループID値を保存し、かつ、当該グループIDを当該特定のユーザと関連付けることを保証することに、留意されたい。
This set of conditions indicates that when the MAP location update operation information is issued from the MSC / VLR to the selected HLR-FE for a particular user, the
UDRが上記で示したように設定されており、かつ、エリアネットワーク1内に位置するMSC/VSRによってユーザが管理されており、かつ、AppType=HLR−FEに関連付けられた通知がUDRによってHLR−FEに向けて送信される必要がある場合には、UDRにおいて設定された決定論的な通知分散アルゴリズムによって、通知の約50パーセントがHLR−FE1に対して配信され、通知の約50パーセントがHLR−FE2に配信される。非常に稀な場合(例えば、HLR−FE1及びHLR−FE2が到達不可能である場合)にのみ、UDRは、HLR−FE3またはHLR−FE4に通知を送信し、HLR−FE3またはHLR−FE4は、必要に応じて、STP1を介してMSC/VSR1またはMSC/VSR2に当該通知を転送する。これと同様に、ユーザが、エリアネットワーク2内に位置するMSC/VSRによって管理されている場合、通常、HLR−FE3、HLR−FE4、またはHLR−FE5に対して通知が送信されることで、負荷の分担がそれらに適用される。非常に稀な場合(例えば、HLR−FE3、HLR−FE4及びHLR−FE5が到達不可能である場合)にのみ、UDRは、HLR−FE1またはHLR−FE2に通知を送信し、HLR−FE1またはHLR−FE1は、必要に応じて、STP1を介してMSC/VSR3、MSC/VSR4、またはMSC/VSR5に当該通知を転送する。
The UDR is set as shown above, the user is managed by the MSC / VSR located in the
図5は、オペレータが、異なるS−CSCFベンダを有するUDRアーキテクチャについての簡略化したブロック図である。S−CSCF1及びS−CSCF2(51a及び51b)は、ベンダ1(52)によって提供される。S−CSCF3、S−CSCF4及びS−CSCF5(51c〜51e)は、ベンダ2(53)によって提供される。複数のS−CSCFは、異なるベンダによって提供されうる。これは、例えば、S−CSCF1及びS−CSCF2が、ベンダ1によってのみサポートされているプレゼンス・サービス及び優先サービスを利用可能な特定のユーザにサービスを行うことが意図されているためである。オペレータは、これらのサービスを提供するために、プライベートかつ分散したネットワークを有する。
FIG. 5 is a simplified block diagram for a UDR architecture in which an operator has different S-CSCF vendors. S-CSCF1 and S-CSCF2 (51a and 51b) are provided by vendor 1 (52). S-CSCF3, S-CSCF4 and S-CSCF5 (51c-51e) are provided by vendor 2 (53). Multiple S-CSCFs may be provided by different vendors. This is because, for example, the S-
本例のUDR30は、複数のHSS−FE54a〜54eを介して、また、ダイアメータ・プロキシ1及びダイアメータ・プロキシ2(55a及び55b)を介して、様々なS−CSCFに接続する。このアーキテクチャを利用する方法について、図6を参照しながら以下で説明する。
The
図6は、本発明の一実施形態における、ユーザの登録及び登録解除を行う方法を示す信号フロー図である。図5及び図6を参照すると、ベンダ1(52)を介して優先サービスに加入しているユーザ(例えば、ネットワークが高いトラヒック負荷を処理している場合に、特定の呼に対して優先付け(prioritization)を要求可能なユーザ)が、ステップ61において、IMS登録を実行する。S−CSCF1(51a)及びS−CSCF2(52b)のみが、このユーザにサービスを行うことができる。このため、登録メッセージをユーザから受信するインテロゲーティングCSCF(I−CSCF)62は、ステップ63〜66に示されている登録手続の間、当該ユーザのために必要とされる能力に従って、(負荷バランシング設定において)S−CSCF1またはS−CSCF2を選択する。本例では、S−CSCF1が選択され、ステップ67〜68において登録メッセージはS−CSCF1に対して転送される。
FIG. 6 is a signal flow diagram illustrating a method for registering and deregistering a user in one embodiment of the present invention. Referring to FIGS. 5 and 6, users who subscribe to priority services via vendor 1 (52) (for example, prioritize specific calls when the network is handling high traffic loads ( The user who can request prioritization) performs IMS registration in
ステップ68において、HSS−FE1(54a)は、ダイアメータ・リクエストをS−CSCF1から受信すると、ステップ69において、HSS−FE1は、ユーザがサービスを受けるS−CSCF名を設定するために、UDR30に更新コマンドを送信する。登録状態も変更される。なお、HSS−FE1は、新たなグループID(即ち、ベンダ1)に属しているため、オペレータは、(ベンダ2に属している)S−CSCF3とは異なるアクセスルールを設定しうる。これは、ユーザに優先サービスを保証するために必要とされうる。UDRは、更新コマンドの受信に応じて、ステップ70においてグループIDを保存する/保存しないための条件を確認する。ユーザはそれ以前に登録されていなかったため、当該条件は、S−CSCF名が更新されることである。その結果、UDRは、グループID(ベンダ1)とAppType=HSSとを保存する。
In
その後、オペレータは、優先サービスをユーザから解除することを決定しうる。この場合、当該ユーザは、その時点で、ベンダ2のS−CSCF2のいずれかによってサービスを受けうる。オペレータが、ユーザをベンダ2のS−CSCF2に移動させることを決定すると、それを行うために当該ユーザのために必要となる能力が変更される。ユーザの能力が変更されているため、オペレータは、ステップ71において、新たなS−CSCFが割り当てられるように、管理上でユーザの登録解除を行う。(登録状態がアプリケーション・タイプ=プロビジョニングによって変更される)UDRにおいて設定された条件は、(登録されていない)新たな状態とS−CSCF名(S−CSCF1)とを有するHSS−FEに向けられる通知をトリガする。AppType=HSSについてのユーザに対応して保存されたグループIDを使用することによって、UDRは、通知を送信するための適切な複数のHSS−FE(HSS−FE1及びHSS−FE2)から成るリストを有する。その両方に対して設定された優先度/重みは同一であるため、UDRは、ステップ72において、HSS−FE2(54b)を選択して、通知を送信する。ステップ73における確認応答に続いて、HSS−FE2は、ステップ74において、登録解除コマンドをS−CSCF1に向かって送信する。
The operator can then decide to release the priority service from the user. In this case, the user can receive service by any of the S-
ユーザは、この登録解除について通知されるため、ユーザ装置(UE)は、上述の手続と同様の手続を使用して、新たな登録を実行する。そのような手続(図示せず)において、I−CSCFは、新たな能力に基づいて、適切なS−CSCFをユーザに対して選択する。例えば、S−CSCF4が選択されうるとともに、S−CSCF4は、ダイアメータ・リクエストを、HSS−FE5(54e)等のHSS−FEに送信する。HSS−FE5からの、それに続く更新コマンドを受信すると、UDR30は、グループIDを保存する/保存しないための条件を確認する。当該条件は、更新されたデータがS−CSCF名である、ということである(ユーザが登録されなかったため、S−CSCF名は空であった)。したがって、UDRは、グループID(ベンダ2)及びAppType=HSSを保存する。
Since the user is notified of this deregistration, the user equipment (UE) performs a new registration using a procedure similar to the procedure described above. In such a procedure (not shown), the I-CSCF selects an appropriate S-CSCF for the user based on the new capabilities. For example, S-CSCF4 may be selected and S-CSCF4 sends a Diameter request to an HSS-FE such as HSS-FE5 (54e). Upon receiving a subsequent update command from the HSS-
図7は、本発明の教示に従って修正されたUDR30についての簡略化したブロック図である。UDRの動作は、プログラム・メモリ82に保存されているコンピュータ・プログラム・ソフトウェアを実行するプロセッサ81によって制御されうる。図3に関連して上述したように、UDRは、アプリケーションFEインタフェース部83を、HLR−FE5(34a〜e)を介してHLR−FE1等のアプリケーションFEと通信するために利用しうる。UDR操作リクエストがアプリケーションFEから受信された場合、認証部84は、保存されている認証データ85を、当該リクエスト中のアプリケーションFEを認証するために利用しうる。UDR操作リクエストが、このアプリケーションFEからの最初のリクエストである場合、保存決定部86は、FE AppType及びリクエスト中のアプリケーションFEに対応するグループIDを、FEアプリケーション・タイプ/グループIDテーブル87に保存する。これがこのアプリケーションFEからの最初のUDR操作リクエストではない場合、図4に関連して示し、かつ、説明したように、保存決定部は、当該リクエスト中のアプリケーションFEに対応する更新されたグループID情報を保存するか否かを決定するために、所定の保存条件88を利用しうる。肯定的な決定に応じて、保存決定部は、FEアプリケーション・タイプ/グループIDテーブル内のグループID情報を更新する。その後、特定のユーザデータに関するUDCイベント通知が、関連するアプリケーションFEに対して送信される必要がある場合には、アプリケーションFE選択部89は、FEアプリケーション・タイプ/グループIDテーブル内の情報にアクセスして、当該イベント通知を受信する適切なアプリケーションFEを選択する。
FIG. 7 is a simplified block diagram for a
図8は、本発明の方法の例示的な実施形態についてのステップを示すフローチャートである。ステップ91において、上述したように、各アプリケーションFEには、AppType、グループID、及び負荷分散重みが割り当てられる。ステップ92において、UDRは、UDR操作リクエストをアプリケーションFEから受信する。ステップ93において、UDRは、アプリケーションFEを認証する。ステップ94において、このリクエストが、このアプリケーションFEから受信された最初のUDR操作リクエストであるか否かが判定される。当該UDR操作リクエストが、このアプリケーションFEから受信された最初のリクエストである場合には、本方法はステップ95に移行し、当該ステップにおいて、UDRは、当該リクエスト中のアプリケーションFEについてのFEアプリケーション・タイプ及びグループIDを保存する。当該UDR操作リクエストが、このアプリケーションFEから受信された最初のリクエストではない場合には、本方法はステップ96に移行し、当該ステップにおいて、UDRは、このリクエスト中のアプリケーションFEについての更新されたグループIDを保存するか否かを決定するために、所定の保存条件を利用しうる。当該リクエストが所定の保存条件を満たす場合には、ステップ95において、UDRは、FEアプリケーション・タイプ/グループIDテーブル内のグループID情報を更新する。その後、UDRは、特定のユーザに関するUDRイベント通知が関連するアプリケーションFEに対して送信される必要がある場合には、ステップ98において、保存したFEアプリケーション・タイプ/グループID情報にアクセスするとともに、任意的に、当該情報を負荷分散重みとともに使用して、当該イベント通知を受信する適切なアプリケーションFEを選択する。
FIG. 8 is a flowchart showing the steps for an exemplary embodiment of the method of the present invention. In
当然ながら、本発明は、本発明の本質的な特徴から逸脱することなく、本明細書で説明した方法以外の方法によって実施されることもありうる。したがって、本実施形態は、あらゆる点で例示的であると考えられるべきであり、添付の特許請求の範囲の意味及び均等の範囲内のあらゆる変更が、本発明に包含されることを意図している。 Of course, the present invention may be implemented by methods other than those described herein without departing from the essential characteristics of the invention. Accordingly, the embodiments are to be considered in all respects as illustrative and all modifications within the meaning and equivalent scope of the appended claims are intended to be embraced therein. Yes.
Claims (19)
前記複数のアプリケーションFEのそれぞれに関連付けられたアプリケーション・タイプ及びグループ識別子をデータベース(88)に追加するステップ(95)であって、各グループ識別子は、前記関連付けられたアプリケーションFEを介してアクセス可能な、前記通信ネットワークに含まれる異なる部分を識別する、前記追加するステップと、
その後、特定のユーザのユーザデータの変更を報告するためのイベント通知手続を開始するステップ(97)と、
選択されるアプリケーションFEの前記アプリケーション・タイプ及びグループ識別子に基づいて、前記イベント通知を受信するアプリケーションFEを選択するステップ(98)と
を含むことを特徴とする方法。A method in a user data repository (UDR) (30) for selecting an application FE that receives event notifications from a plurality of application front ends (application FEs) (34a-34e) in a communication network comprising:
Adding (95) an application type and group identifier associated with each of the plurality of application FEs to the database (88), wherein each group identifier is accessible via the associated application FE; Identifying the different parts included in the communication network, the adding step;
Then, starting an event notification procedure for reporting a change in user data of a particular user (97);
Selecting (98) an application FE to receive the event notification based on the application type and group identifier of the selected application FE.
前記複数のアプリケーションFEのうちの1つからUDR操作リクエストが受信された際に(92)、アプリケーションFEについての前記アプリケーション・タイプ及びグループ識別子を、ユーザレベルで前記データベースに保存するステップを含むことを特徴とする請求項1に記載の方法。The step (95) of adding to the database comprises:
When a UDR operation request is received from one of the plurality of application FEs (92), including storing the application type and group identifier for the application FE in the database at a user level. The method of claim 1, characterized in that:
所与のアプリケーションFEからUDR操作リクエストを受信するステップ(92)であって、当該リクエストは、ユーザデータを変更し、かつ、当該所与のアプリケーションFEについてのアプリケーション・タイプ及びグループ識別子を含む、前記受信するステップと、
前記UDR操作リクエストが、前記所与のアプリケーションFEから受信された最初のUDR操作リクエストであるか否かを判定するステップ(94)と、
前記UDR操作リクエストが、前記所与のアプリケーションFEから受信された前記最初のUDR操作リクエストである場合に、前記アプリケーション・タイプ及びグループ識別子を前記データベースに保存するステップ(95)と、
前記UDR操作リクエストが、前記所与のアプリケーションFEから受信された前記最初のUDR操作リクエストではない場合に、更新されたグループ識別子を保存するか否かを決定するステップ(96)と
を含むことを特徴とする請求項2に記載の方法。The storing step includes
Receiving (92) a UDR operation request from a given application FE, wherein the request modifies user data and includes an application type and group identifier for the given application FE; Receiving step;
Determining whether the UDR operation request is the first UDR operation request received from the given application FE;
(95) storing the application type and group identifier in the database if the UDR operation request is the first UDR operation request received from the given application FE;
Determining whether to save an updated group identifier if the UDR operation request is not the first UDR operation request received from the given application FE. The method of claim 2, wherein the method is characterized in that:
前記UDR操作リクエストに関する所定の基準に基づいて、前記更新されたグループ識別子を保存するか否かを決定するステップ
を含むことを特徴とする請求項3に記載の方法。The step (96) of determining whether to save the updated group identifier comprises:
4. The method of claim 3, comprising determining whether to save the updated group identifier based on predetermined criteria regarding the UDR operation request.
前記アプリケーション・タイプが、前記通信ネットワークの、前記特定のユーザの位置に依存した部分に関連付けられたタイプであると、前記更新されたグループ識別子を保存するステップ
を含むことを特徴とする請求項4に記載の方法。The step (96) of determining whether to save the updated group identifier based on predetermined criteria,
5. The step of storing the updated group identifier if the application type is a type associated with a location-dependent portion of the communication network. The method described in 1.
前記UDR操作リクエストが、更新リクエストまたは生成リクエストであると、前記更新されたグループ識別子を保存するステップ
を含むことを特徴とする請求項4に記載の方法。The step (96) of determining whether to save the updated group identifier based on predetermined criteria,
5. The method of claim 4, comprising storing the updated group identifier if the UDR operation request is an update request or a generation request.
変更された前記ユーザデータが、前記グループ識別子に関連している場合にのみ、前記更新されたグループ識別子を保存するステップ
を含むことを特徴とする請求項4に記載の方法。The step (96) of determining whether to save the updated group identifier based on predetermined criteria,
5. The method of claim 4, comprising storing the updated group identifier only if the modified user data is associated with the group identifier.
前記リクエストされたUDR操作が、前記UDRにおいて成功した場合にのみ、前記更新されたグループ識別子を保存するステップ
を含むことを特徴とする請求項4に記載の方法。The step (96) of determining whether to save the updated group identifier based on predetermined criteria,
5. The method of claim 4, comprising saving the updated group identifier only if the requested UDR operation is successful in the UDR.
当該割り当てるステップでは、
所与のアプリケーションFEが、前記特定のユーザにサービスを行うサービスノードに対して直接のコネクションを有する場合には、高い負荷分散重みを当該所与のアプリケーションFEに割り当て、当該所与のアプリケーションFEが、前記特定のユーザにサービスを行うサービスノードに対して間接のコネクションのみを有する場合には、低い負荷分散重みを当該所与のアプリケーションFEに割り当てる
ことを特徴とする請求項1に記載の方法。Further comprising assigning a load distribution weight to each of the plurality of application FEs (91);
In the assigning step,
If a given application FE has a direct connection to a service node that serves the particular user, a high load distribution weight is assigned to the given application FE, and the given application FE The method of claim 1, wherein if there is only an indirect connection to a service node serving a particular user, a low load distribution weight is assigned to the given application FE.
選択されるアプリケーションFEに割り当てられている前記負荷分散重みに基づいて、前記アプリケーションFEを選択するステップ
をさらに含むことを特徴とする請求項9に記載の方法。The step (98) of selecting an application FE that receives the event notification includes:
The method of claim 9, further comprising selecting the application FE based on the load balancing weight assigned to the selected application FE.
前記複数のアプリケーションFEのそれぞれに関連付けられたアプリケーション・タイプ及びグループ識別子をデータベース(88)に追加する手段(86)であって、各グループ識別子は、前記関連付けられたアプリケーションFEを介してアクセス可能な、前記通信ネットワークに含まれる異なる部分を識別する、前記追加する手段と、
その後、特定のユーザのユーザデータの変更を報告するために、イベント通知手続を開始する手段(81)と、
選択されるアプリケーションFEの前記アプリケーション・タイプ及びグループ識別子に基づいて、前記イベント通知を受信するアプリケーションFEを選択する手段(89)と
を備えることを特徴とする装置。An apparatus in a user data repository (UDR) (30) for selecting an application FE that receives event notifications from a plurality of application front ends (application FEs) (34a-34e) in a communication network,
Means (86) for adding to the database (88) an application type and group identifier associated with each of the plurality of application FEs, each group identifier being accessible via the associated application FE The adding means for identifying different parts included in the communication network;
Thereafter, means (81) for initiating an event notification procedure to report a change in user data of a particular user;
And (89) means for selecting an application FE to receive the event notification based on the application type and group identifier of the selected application FE.
前記複数のアプリケーションFEのうちの1つからUDR操作リクエストが受信された際に(92)、アプリケーションFEについての前記アプリケーション・タイプ及びグループ識別子を、ユーザレベルで前記データベースに保存する
ことを特徴とする請求項11に記載の装置。The means (86) for adding to the database comprises:
When a UDR operation request is received from one of the plurality of application FEs (92), the application type and group identifier for the application FE are stored in the database at a user level. The apparatus of claim 11.
所与のアプリケーションFEからUDR操作リクエストを受信するインタフェース部(83)であって、当該リクエストは、ユーザデータを変更し、かつ、当該所与のアプリケーションFEについてのアプリケーション・タイプ及びグループ識別子を含む、前記インタフェース部と、
前記UDR操作リクエストが、前記所与のアプリケーションFEから受信された最初のUDR操作リクエストであるか否かを判定する手段(86)と、
前記UDR操作リクエストが、前記所与のアプリケーションFEから受信された前記最初のUDR操作リクエストである場合に、前記アプリケーション・タイプ及びグループ識別子を前記データベースに保存するとともに、前記UDR操作リクエストが、前記所与のアプリケーションFEから受信された前記最初のUDR操作リクエストではない場合に、更新されたグループ識別子を保存するか否かを決定する保存決定部(86)と
を備えること特徴とする請求項12に記載の装置。The means for adding is
An interface unit (83) for receiving a UDR operation request from a given application FE, wherein the request modifies user data and includes an application type and group identifier for the given application FE; The interface unit;
Means (86) for determining whether the UDR operation request is the first UDR operation request received from the given application FE;
If the UDR operation request is the first UDR operation request received from the given application FE, the application type and group identifier are stored in the database, and the UDR operation request is The storage determination unit (86) for determining whether or not to save the updated group identifier when the request is not the first UDR operation request received from a given application FE. The device described.
ことを特徴とする請求項13に記載の装置。The apparatus according to claim 13, wherein the storage determination unit (86) determines whether or not to store the updated group identifier based on a predetermined criterion related to the UDR operation request.
前記保存決定部(86)は、前記アプリケーション・タイプが、前記通信ネットワークの、前記特定のユーザの位置に依存した部分に関連付けられたタイプであると、前記更新されたグループ識別子を保存する
ことを特徴とする請求項14に記載の装置。One of the predetermined criteria (87) is the application type of the given application FE;
The saving determination unit (86) saves the updated group identifier when the application type is a type associated with a part of the communication network depending on a position of the specific user. The device according to claim 14, characterized in that:
前記保存決定部(86)は、前記UDR操作リクエストが、更新リクエストまたは生成リクエストであると、前記更新されたグループ識別子を保存する
ことを特徴とする請求項14に記載の装置。One of the predetermined criteria (87) is the type of UDR operation request received;
The apparatus according to claim 14, wherein the storage determination unit (86) stores the updated group identifier when the UDR operation request is an update request or a generation request.
前記保存決定部(86)は、変更された前記ユーザデータが、前記グループ識別子に関連している場合にのみ、前記更新されたグループ識別子を保存する
ことを特徴とする請求項14に記載の装置。One of the predetermined criteria (87) is the relevance of the modified user data to the group identifier;
The apparatus according to claim 14, wherein the storage determination unit (86) stores the updated group identifier only when the changed user data is related to the group identifier. .
前記保存決定部(86)は、前記リクエストされたUDR操作が、前記UDRにおいて成功した場合にのみ、前記更新されたグループ識別子を保存する
ことを特徴とする請求項14に記載の装置。One of the predetermined criteria (87) is the success or failure of the requested UDR operation;
The apparatus according to claim 14, wherein the storage determination unit (86) stores the updated group identifier only when the requested UDR operation is successful in the UDR.
所与のアプリケーションFEが、前記特定のユーザにサービスを行うサービスノードに対して直接のコネクションを有する場合には、高い負荷分散重みが当該所与のアプリケーションFEに割り当てられており、
当該所与のアプリケーションFEが、前記特定のユーザにサービスを行うサービスノードに対して間接のコネクションのみを有する場合には、低い負荷分散重みが当該所与のアプリケーションFEに割り当てられている
ことを特徴とする請求項11に記載の装置。The means for selecting an application FE that receives the event notification further selects the application FE based on a load balancing weight assigned to each of the plurality of applications FE,
If a given application FE has a direct connection to a service node that serves the particular user, a high load distribution weight is assigned to the given application FE;
When the given application FE has only an indirect connection to the service node serving the specific user, a low load distribution weight is assigned to the given application FE. The apparatus according to claim 11.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US18624009P | 2009-06-11 | 2009-06-11 | |
US61/186,240 | 2009-06-11 | ||
PCT/IB2009/007705 WO2010143014A1 (en) | 2009-06-11 | 2009-12-09 | User data convergence (udc) notification management |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2012532476A JP2012532476A (en) | 2012-12-13 |
JP5122024B2 true JP5122024B2 (en) | 2013-01-16 |
Family
ID=42306631
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2012514544A Expired - Fee Related JP5122024B2 (en) | 2009-06-11 | 2009-12-09 | Managing user data convergence (UDC) notifications |
Country Status (6)
Country | Link |
---|---|
US (1) | US8452894B2 (en) |
EP (1) | EP2441233B1 (en) |
JP (1) | JP5122024B2 (en) |
CN (1) | CN102461121B (en) |
AU (1) | AU2009347834B2 (en) |
WO (1) | WO2010143014A1 (en) |
Families Citing this family (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2006066145A2 (en) | 2004-12-17 | 2006-06-22 | Tekelec | Supporting database access in an internet protocol multimedia subsystem |
WO2010088622A1 (en) | 2009-02-02 | 2010-08-05 | Level 3 Communications, Llc | Analysis of network traffic |
RU2575987C2 (en) * | 2010-02-11 | 2016-02-27 | Телефонактиеболагет Л М Эрикссон (Пабл) | Data management in directory database |
US20140089485A1 (en) * | 2011-03-29 | 2014-03-27 | Telefonaktiebolaget L M Ericsson (Publ) | Method and Arrangement for Providing Update Notifications in a Telecommunication Network |
US9225849B2 (en) * | 2011-05-06 | 2015-12-29 | Tekelec, Inc. | Methods, systems, and computer readable media for steering a subscriber between access networks |
US9319378B2 (en) | 2013-01-23 | 2016-04-19 | Tekelec, Inc. | Methods, systems, and computer readable media for using a diameter routing agent (DRA) to obtain mappings between mobile subscriber identification information and dynamically assigned internet protocol (IP) addresses and for making the mappings accessible to applications |
US8989776B2 (en) * | 2013-03-22 | 2015-03-24 | Alcatel Lucent | Location aggregation system |
US20160302055A1 (en) * | 2013-03-27 | 2016-10-13 | Nec Corporation | Information processing system |
CN103678242B (en) * | 2013-12-09 | 2017-07-21 | 腾讯科技(深圳)有限公司 | Subscriber data sending method and device |
CN105472594B (en) * | 2014-09-09 | 2018-09-04 | 阿尔卡特朗讯 | A kind of method and apparatus for handling data |
US10951519B2 (en) | 2015-06-17 | 2021-03-16 | Oracle International Corporation | Methods, systems, and computer readable media for multi-protocol stateful routing |
US9668135B2 (en) | 2015-08-14 | 2017-05-30 | Oracle International Corporation | Methods, systems, and computer readable media for providing access network signaling protocol interworking for user authentication |
US10084755B2 (en) | 2015-08-14 | 2018-09-25 | Oracle International Corporation | Methods, systems, and computer readable media for remote authentication dial in user service (RADIUS) proxy and diameter agent address resolution |
US9923984B2 (en) | 2015-10-30 | 2018-03-20 | Oracle International Corporation | Methods, systems, and computer readable media for remote authentication dial in user service (RADIUS) message loop detection and mitigation |
US9668134B2 (en) | 2015-08-14 | 2017-05-30 | Oracle International Corporation | Methods, systems, and computer readable media for providing access network protocol interworking and authentication proxying |
US10554661B2 (en) | 2015-08-14 | 2020-02-04 | Oracle International Corporation | Methods, systems, and computer readable media for providing access network session correlation for policy control |
US11283883B1 (en) | 2020-11-09 | 2022-03-22 | Oracle International Corporation | Methods, systems, and computer readable media for providing optimized binding support function (BSF) packet data unit (PDU) session binding discovery responses |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6651063B1 (en) * | 2000-01-28 | 2003-11-18 | Andrei G. Vorobiev | Data organization and management system and method |
JP2003152783A (en) * | 2001-11-19 | 2003-05-23 | Fujitsu Ltd | Server load distributing device |
JP4022117B2 (en) | 2002-09-20 | 2007-12-12 | 富士通株式会社 | Load balancing method and apparatus |
JP3995580B2 (en) | 2002-11-05 | 2007-10-24 | 富士通株式会社 | Load balancing processing system |
US7162472B2 (en) * | 2003-06-24 | 2007-01-09 | Microsoft Corporation | System and method for database change notification |
CN101448243B (en) * | 2008-04-11 | 2011-09-21 | 中兴通讯股份有限公司 | Method for realizing user registration |
-
2009
- 2009-12-09 JP JP2012514544A patent/JP5122024B2/en not_active Expired - Fee Related
- 2009-12-09 CN CN200980159872.XA patent/CN102461121B/en active Active
- 2009-12-09 EP EP20090802208 patent/EP2441233B1/en not_active Not-in-force
- 2009-12-09 AU AU2009347834A patent/AU2009347834B2/en not_active Ceased
- 2009-12-09 US US13/376,443 patent/US8452894B2/en active Active
- 2009-12-09 WO PCT/IB2009/007705 patent/WO2010143014A1/en active Application Filing
Also Published As
Publication number | Publication date |
---|---|
CN102461121B (en) | 2014-10-01 |
AU2009347834A1 (en) | 2012-01-12 |
CN102461121A (en) | 2012-05-16 |
AU2009347834B2 (en) | 2013-09-05 |
US8452894B2 (en) | 2013-05-28 |
WO2010143014A1 (en) | 2010-12-16 |
EP2441233A1 (en) | 2012-04-18 |
JP2012532476A (en) | 2012-12-13 |
EP2441233B1 (en) | 2015-04-22 |
US20120089993A1 (en) | 2012-04-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5122024B2 (en) | Managing user data convergence (UDC) notifications | |
US8423678B2 (en) | Resilient network database | |
CN101176369B (en) | Service profiles in IMS processes | |
US7761600B2 (en) | Method and apparatus for distributing application server addresses in an IMS | |
JP5302330B2 (en) | Method and apparatus for use in a communication network | |
EP2522102B1 (en) | Method, system, and computer readable medium for policy charging and rules function (pcrf) node selection | |
CN101505472B (en) | User data server system and apparatus | |
US9282143B2 (en) | Method for handling data stored by a communication system | |
JP2006517064A5 (en) | ||
WO2005064896A1 (en) | Application server adressing | |
US8600031B2 (en) | Method for connecting calls between an IP multimedia subsystem (IMS) domain and a circuit switched (CS) domain | |
EP2037658B1 (en) | Assignment of a serving entity in a communication system | |
US9628938B2 (en) | Determination of IMS application server instance based on network information | |
WO2009024029A1 (en) | Visited network, home netwrok, system and corresponding method for using service of visited network, and terminal | |
US20100017527A1 (en) | Sip server and communication system | |
JP5174708B2 (en) | Session control system in IMS | |
CN101132407B (en) | Method for processing exception caused by re-selection service call conversation control function | |
KR20030055417A (en) | The Apparatus and Method for the Mobility Management of IP Multimedia Service Subscriber | |
EP2418818B1 (en) | Network entity for managing communications towards a user entity over a communication network | |
WO2023095031A1 (en) | Method for transmitting and receiving multimedia data | |
EP2710775B1 (en) | Method and network entity for selecting for a subscriber a call session establishing server to be registered with in a voice over internet protocol network | |
CN103125106B (en) | For managing network entity and the method for the communication to user subject on a communication network | |
WO2010000441A1 (en) | Data repository device and associated method for data management |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20120928 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20121023 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20151102 Year of fee payment: 3 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 5122024 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
LAPS | Cancellation because of no payment of annual fees |