WO2008049355A1 - Procédé, dispositif et système de synchronisation de données utilisateur dans un réseau nouvelle génération - Google Patents

Procédé, dispositif et système de synchronisation de données utilisateur dans un réseau nouvelle génération Download PDF

Info

Publication number
WO2008049355A1
WO2008049355A1 PCT/CN2007/070734 CN2007070734W WO2008049355A1 WO 2008049355 A1 WO2008049355 A1 WO 2008049355A1 CN 2007070734 W CN2007070734 W CN 2007070734W WO 2008049355 A1 WO2008049355 A1 WO 2008049355A1
Authority
WO
WIPO (PCT)
Prior art keywords
user data
user
racf
clf
entity
Prior art date
Application number
PCT/CN2007/070734
Other languages
English (en)
French (fr)
Inventor
Fuqing Huang
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to EP07816925A priority Critical patent/EP2068508A1/en
Publication of WO2008049355A1 publication Critical patent/WO2008049355A1/zh

Links

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/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • 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/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles

Definitions

  • the present invention relates to the field of Next Generation Network (NGN) technology, and more particularly, to a method, apparatus and system for synchronizing user data in a next generation network.
  • NTN Next Generation Network
  • DiffServ differentiated services
  • InterServ guarantees a tight end-to-end quality of service for the Internet.
  • InterServ is a flow-based QoS mechanism that strictly controls resources and provides strict QoS guarantees for applications.
  • InterServ has scalability problems. Because each router through which a service flow passes must maintain a soft state for it, IntServ cannot be used on a large scale.
  • DiffServ is a class-based QoS mechanism that is relatively successful in deployment, but it can only provide relative QoS guarantees, especially when bandwidth is not sufficient.
  • the IETF proposed the DS-Aware MPLS TE model.
  • the advantages of DiffServ and MPLS-TE are integrated, the transmission resources are optimized, and the performance and efficiency of the network are further improved.
  • this model has an N-square problem and it is difficult to solve the problem of inter-domain interworking.
  • the current general view in the industry is: No matter the large bandwidth or DiffServ can not really solve the end-to-end QoS problem.
  • the session-based dynamic QoS (DQoS, Dynamic QoS) control mechanism has gradually become the research direction.
  • This mechanism implements the CAC, resource reservation and dynamic policy based on each session in the control plane; Perception and policy enforcement. This mechanism provides both strict QoS guarantees and good scalability.
  • TISPAN Internet convergence services and advanced networks
  • FIG. 1 is a schematic diagram of an NGN network architecture established by TISPAN in the prior art.
  • the architecture uses the design philosophy of Subsystem. It adapts to new demands and services over time and facilitates the introduction of subsystems from other standards organizations.
  • the architecture within the subsystem can be flexibly adjusted without affecting other subsystems, and each subsystem is a collection of functional entities and interfaces.
  • some functional entities can be combined according to the business model, the services provided, and the capabilities, so the interface between these entities becomes the internal interface.
  • the functional architecture is divided into a service layer and an IP-based transport layer.
  • the business layer has the following components: core IP Multimedia Subsystem (IMS), PSTN/ISDN Emulation Subsystem (PES), other multimedia systems (such as streaming media subsystems, content broadcast subsystems), and applications.
  • IMS core IP Multimedia Subsystem
  • PSTN/ISDN Emulation Subsystem PES
  • other multimedia systems such as streaming media subsystems, content broadcast subsystems
  • applications such as billing functions, user data management, security management, routing database, and so on.
  • the transport layer provides an IP interconnection for user equipment, which includes two control subsystems: the Network Attachment Subsystem (NASS) and the Resource Admission Control Subsystem (RACS).
  • NSS Network Attachment Subsystem
  • RACS Resource Admission Control Subsystem
  • the Network Attachment Subsystem (NASS) mainly performs the following functions:
  • the Resource Admission Control Subsystem mainly provides admission control and gate control functions. Admission control involves checking and authorizing based on operator-based policy rules, resource availability, and user subscription information.
  • the Connected Session Location and Repository Function (CLF) in the NASS subsystem can provide user data such as user location information and user subscription information for the RACS subsystem.
  • CCF Connected Session Location and Repository Function
  • An E4 reference point is defined between the Access Resource and Admission Control Functional entity (A-RACF) and the CLF functional entity in the NASS subsystem in the RACS subsystem. Through this E4 reference point, the A-RACF obtains location information (such as the physical node address of the user) from the CLF to determine the available network resources. A-RACF can also obtain user network profile information from the CLF for reference when processing resource allocation requests.
  • the information exchanged at the E4 reference point mainly includes: a subscriber identity, a user physical access identifier, a user logical access identifier, a user access network type, a user global unique IP address, a user initial gateway setting, a user subscription data, and a user. QoS list, user-based charging rules, user-based policy information, and so on.
  • User data reporting information flow This information flow is used by the CLF to actively report user data to the A-RACF. The information flow occurs after the IP address is assigned to the user, or When the user who has reported to A-RACF signs the contract modification data.
  • User data acquisition information flow This information flow is used by the A-RACF to request specific user data from the CLF, and the response of the user data acquisition information flow is the user data reporting information flow.
  • the A-RACF must provide the CLF with the user's globally unique IP address or user ID, and the CLF will report the correct user data based on this information.
  • IP connectivity release indication information flow This information flow is used by the CLF to report the loss of IP connectivity to the RACS, which allows the RACS to delete the corresponding user data, which occurs when the assigned IP address is released or due to The release of the second layer of resources is caused.
  • the existing information flow between CLF and A-RACF cannot solve the problem of reported user data loss caused by internal faults of A-RACF.
  • the CLF can re-report the user data by reporting the information flow through the user data when the protocol connection with the A-RACF is reestablished.
  • the CLF cannot detect the internal fault of the RACS, so the user data will not be reported again, and the A-RACF will not be able to. Keep user data synchronized with CLF.
  • Embodiments of the present invention propose a method for synchronizing user data in a next generation network, so that the A-RACF can maintain user data synchronization with the CLF.
  • Embodiments of the present invention propose a system for synchronizing user data in a next generation network, so that the A-RACF can maintain user data synchronization with the CLF.
  • the embodiment of the present invention also proposes an A-RACF and a CLF to enable the A-RACF to maintain user data synchronization with the CLF.
  • a method for synchronizing user data in a next generation network comprising:
  • the access network resource admission control function entity A-RACF sends a user data synchronization request to the connected session location storage function entity CLF;
  • the CLF After receiving the user data synchronization request, the CLF sends the user data of the user to the A-RACF to keep the user data of the A-RACF and the CLF synchronized.
  • a system for synchronizing user data in a next generation network comprising an A-RACF entity and a CLF entity, wherein:
  • An A-RACF entity configured to send a user data synchronization request to the CLF entity
  • the CLF entity is configured to send user data of each user to the A-RACF entity after receiving the user data synchronization request, so that user data of the A-RACF entity and the CLF entity are synchronized.
  • An A-RACF the A-RACF includes a user data synchronization request sending unit and a user data receiving unit, wherein:
  • a user data synchronization request sending unit configured to generate a user data synchronization request, and send the user data synchronization request to the CLF;
  • the user data receiving unit is configured to receive user data sent by the CLF in response to the user data synchronization request.
  • a CLF comprising a user data synchronization request receiving unit and a user data transmitting unit, wherein:
  • a user data synchronization request receiving unit configured to receive a user data synchronization request sent by the A-RACF
  • a user data sending unit configured to return user data to the A-RACF in response to the user data synchronization request.
  • the A-RACF first sends a user data synchronization request to the CLF; after receiving the user data synchronization request, the CLF synchronizes the user data of each user with the A-RACF. Therefore, after applying the present invention, the A-RACF can instruct the CLF to synchronize user data with the A-RACF, so the A-RACF can keep user data synchronized with the CLF.
  • FIG. 1 is a diagram of a next-generation network architecture developed by TISPAN in the prior art
  • FIG. 2 is a flow chart of a method for synchronizing user data in a next generation network according to an embodiment of the present invention
  • FIG. 3 is an exemplary flowchart of a method of synchronizing user data in a next generation network according to an embodiment of the present invention
  • FIG. 4 is a schematic diagram showing an exemplary structure of a synchronous user data system in a next generation network according to an embodiment of the present invention.
  • FIG. 5 is a schematic diagram showing an exemplary structure of an A-RACF according to an embodiment of the present invention.
  • FIG. 6 is a schematic diagram showing an exemplary structure of a CLF according to an embodiment of the present invention. Mode for carrying out the invention
  • a new information flow between the A-RACF and the CLF that is, the user data synchronization information flow is proposed, so that the reported CLF cannot be detected due to the failure to detect the internal fault caused by the A-RACF. Problems such as loss of user data.
  • FIG. 2 is an exemplary flow chart of a method of synchronizing user data in a next generation network in accordance with an embodiment of the present invention. As shown in Figure 2, the method includes:
  • Step 201 The A-RACF sends a user data synchronization request to the CLF.
  • the A-RACF will send a User Data Synchronization Request message to the CLF.
  • the information elements involved in the User Data Synchronization Request message may be as shown in Table 1 below. Description of the carrying situation corresponding to the information element name AVP
  • the RACS-Id AF-App must carry an A-RACF functional entity that identifies the requested user data.
  • the user data synchronization request message needs to carry the AF-Application-Identifier AVP, and the value of the AVP is set to the identifier of the A-RACF functional entity that requests the user data.
  • the command code of the user data synchronization request message can be uniformly allocated by the IANA organization, and the Diameter message format of the user data synchronization request message can be defined as follows:
  • Diameter Header indicates a Diameter message header, which may carry a request flag and a proxy flag;
  • ⁇ Session-Id> indicates a session target;
  • Vendor-Specific-Application-Id ⁇ indicates an operator specific application identifier;
  • Auth-Session-State ⁇ indicates the authorization session state;
  • Origin-Host ⁇ indicates the source host name;
  • Origin-Realm ⁇ indicates the source i or name;
  • [ Destination-Host ] indicates the destination host name;
  • Destination-Realm ⁇ indicates the destination i or name;
  • [AF-Application-Identifier] indicates the application function identifier;
  • *[AVP] indicates other AVPs;
  • *[Proxy-Info] indicates proxy information;
  • *[Route-Record] indicates route records .
  • Step 202 After receiving the user data synchronization request, the CLF synchronizes the user data of each user with the A-RACF.
  • the CLF may further determine whether the A-RACF is legal according to the A-RACF identifier carried in the user data synchronization request, and if it is legal, the A-RACF identifier is used.
  • the corresponding A-RACF sends the user data of each user, so that the A-RACF corresponding to the A-RACF identifier and the user data of the CLF are kept synchronized, and if not, the synchronization operation is not performed.
  • the CLF may also send a user data synchronization end notification to the A-RACF. More preferably, after receiving the user data synchronization end notification, the A-RACF may return a user data synchronization end notification response to the CLF.
  • the CLF may further determine, according to the local policy rule, whether to perform user data synchronization with the A-RACF. If the local policy rule allows user data synchronization to the A-RACF, The A-RACF sends the user data of each user, and sends a user data synchronization response carrying the information indicating the consent to the synchronization to the A-RAC; if the local policy rule does not allow the user data synchronization to the A-RACF, the A-RAC is sent to the A-RAC. The user data synchronization response indicating the information that is rejected for synchronization does not send the user data of each user to the A-RACF.
  • the CLF may further determine, according to local policy rules and/or user privacy information, a list of users that can be synchronized to the A-RACF, and to the A-RACF.
  • the user data of the user in the user list is sent, so that the A-RACF entity and the CLF entity keep the user data of the user in the user list synchronized.
  • the CLF preferably further determines whether the user data is being updated, and if so, waits for the user data update to be completed, and sends the updated user data to the A-RACF. If not, send the user data of each user to A-RACF.
  • the user data may include: a subscription user identifier, a user physical access identifier, a user logical access identifier, a user access network type, a user global unique IP address, a user initial gateway setting, a user subscription data, and a user. Any combination of QoS list, user-based charging rules, user-based policy information, or any combination of more than one.
  • Diameter Header indicates the Diameter header: with the proxy flag; ⁇ Session-Id> indicates the session identifier; ⁇ Vendor-Specific-Application-Id ⁇ indicates the carrier specific application identifier; [ Result-Code ] indicates the result code ; [ Experimental-Result ] indicates the experimental result; ⁇ Auth-Session-State ⁇ indicates the authorized session state; ⁇ Origin-Host ⁇ Indicates the source host name; ⁇ Origin-Realm ⁇ indicates the source domain name; *[ AVP ] indicates other AVPs; *[ Failed- AVP ] indicates failure information; *[ Proxy-Info ] indicates proxy information; *[ Route-Record ] indicates routing recording.
  • the value of the Result-Code AVP is set to DIAMETER_SUCCESS in the user data synchronization response message sent to the A-RACF. If the CLF decides not to synchronize the user data with the A-RACF, then The value of Result-Code AVP is set to a value other than DIAMETER_SUCCESS in the A-RACF Transmit User Data Synchronization Reply message. For example, it can be set to DIAMETER_UNABLE_TO_COMPLY to indicate that the user data is not synchronized to A-RACF.
  • the A-RACF may synchronously mark the user data reported by the CLF stored on the A-RACF, indicating that the user data needs to be synchronized.
  • the CLF After receiving the A-RACF user data synchronization request and sending an A-RACF User Data Synchronization Reply message to the A-RACF (the value of the Result-Code AVP is set to DIAMETER_SUCCESS), the CLF starts user data synchronization with the A-RACF. Specifically, the CLF may check whether the user data stored in the CLF can be reported to the A-RACF according to the local policy rule and/or the user's private information. For user data that can be reported to the A-RACF for synchronization, the CLF will also check whether the user data is currently being updated. If the user data is being updated, the CLF will postpone the reporting of the user data until the user data is After the update, the updated user data is reported to the A-RACF. The user data report message and the user data report response message are composed. During a user data synchronization process, multiple user data reporting interactions may be required. Exemplarily, the information elements involved in the user data report message may be as shown in Table 2 below.
  • Diameter Header 309, REQ, PXY> indicates the Diameter message header: command code is 309, with request flag, proxy flag; ⁇ Session-Id> indicates session identifier; ⁇ Vendor-Specific- Application-Id ⁇ indicates operator Specific application identifier; ⁇ Auth-Session-State ⁇ indicates the authorization session state; ⁇ Origin-Host ⁇ indicates the source host name; ⁇ Origin-Realm ⁇ indicates the source i or name; ⁇ Destination-Host ⁇ indicates the destination host name; ⁇ Destination- Realm ⁇ indicates the destination i or name; [Globally-Unique-IPAddress] indicates the global unique IP address; [User-Name] indicates the user name; [Logical-Access-Id] indicates the access ID; [Physical- Access-Id ] indicates the physical access ID; [Access-Network-Type] indicates the access network type; [Initial-Gate-Setting] indicates the initial gate setting; *[Q
  • the A-RACF After receiving the message from each user data of the CLF, the A-RACF will send a user data report response message to the CLF to respond.
  • the user data report response message can also use the existing message, and the message format is:
  • Diameter Header 309
  • PXY> indicates the Diameter message header: the command code is 309 with a proxy flag; ⁇ Session-Id> indicates the session identifier; ⁇ Vendor-Specific-Application-Id ⁇ indicates the carrier specific application identifier; Result-Code ] indicates the result code; [ Experimental-Result ] indicates the actual risk result; ⁇ Auth-Session-State ⁇ indicates the authorized session state; ⁇ Origin-Host ⁇ indicates the source host name; ⁇ Origin-Realm ⁇ indicates the source domain name; [AVP] indicates other AVPs; * [Failed-AVP] indicates failure information; *[Proxy-Info] indicates proxy information; *[Route-Record] indicates routing records. If the reported user data already exists on the A-RACF, the stored user data is updated, and if the original user data has a synchronization flag, the synchronization flag is cleared;
  • the A-RACF does not have the reported user data, and stores the reported user data.
  • the CLF can indicate to the A-RACF that the user data synchronization ends. Specifically, after the CLF synchronizes all the user data that needs to be synchronized to the A-RACF, the user data synchronization end notification message may be sent to the A-RACF.
  • the command code of the user data synchronization end notification message can be uniformly allocated by the IANA organization, and the message format of the user data synchronization end notification message can be defined as follows:
  • Diameter Header REQ
  • PXY> indicates the Diameter message header: with the request flag, the proxy flag
  • ⁇ Session-Id> indicates the session identifier
  • ⁇ Vendor-Specific-Application-Id ⁇ indicates the carrier specific application identifier
  • ⁇ Auth- Session-State ⁇ indicates the authorization session ⁇ dog state
  • ⁇ Origin-Host ⁇ indicates the source host name
  • ⁇ Origin-Realm ⁇ indicates the source i or name
  • [ Destination-Host ] indicates the destination host name
  • ⁇ Destination-Realm ⁇ indicates the destination i or name
  • *[ AVP ] indicates other AVPs
  • *[ Proxy-Info ] indicates proxy information
  • *[ Route-Record ] indicates route records.
  • the A-RACF may also send a user data synchronization end notification response message to the A-RACF to respond.
  • the command code of the user data synchronization end notification response message may be the same as the user data synchronization request message, and the message format of the message may be defined as follows:
  • Diameter Header indicates the Diameter header: with the proxy flag; ⁇ Session-Id> indicates the session identifier; ⁇ Vendor-Specific-Application-Id ⁇ indicates the carrier specific application identifier; [ Result-Code ] indicates the result code ; [ Experimental-Result ] indicates the experimental result; ⁇ Auth-Session-State ⁇ indicates the authorized session state; ⁇ Origin-Host ⁇ indicates the source host name; ⁇ Origin-Realm ⁇ indicates the source domain name; *[ AVP ] indicates other AVPs; [ Failed- AVP ] indicates failure information; *[Proxy-Info ] indicates proxy information; *[ Route-Record ] indicates route record.
  • the A-RACF performs the user data reported by the CLF before the synchronization starts. Check, for the user data that still has the synchronization mark (this means that the user data is not re-reported during the synchronization process, otherwise the synchronization mark should have been cleared), A-RACF will consider these user data is no longer valid, A-RACF will Delete these user data and release the affected session.
  • Fig. 3 is an exemplary flowchart of a method of synchronizing user data in a next generation network according to an embodiment of the present invention. As shown in Figure 3, the method includes:
  • Step 301 The A-RACF sends a user data synchronization request to the CLF.
  • Step 302 The CLF returns a user data synchronization response to the A-RACF.
  • Step 303 The CLF reports the user data of the user 1 to the A-RACF.
  • Step 304 The A-RACF returns a user data report response to the user 1 to the CLF. Then, in the following steps, the CLF reports the user data of the remaining users to the A-RACF in turn, and the A-RACF returns the user of each user to the CLF. The data is reported as a response. After the synchronization of the data is completed, the CLF sends a user data synchronization end notification to the A-RACF, and then the A-RACF returns a user data end notification response to the CLF.
  • the user data reporting response of each user is reported in the user data, it is not necessarily strictly in this order in practice, and the present invention is not limited thereto.
  • the embodiment of the invention also discloses a system for synchronizing user data in a next generation network.
  • 4 is a schematic diagram showing an exemplary structure of a synchronous user data system in a next generation network according to an embodiment of the present invention. As shown in FIG. 4, the system includes an A-RACF entity 401 and a CLF entity 402, where:
  • the A-RACF entity 401 is configured to send a user data synchronization request to the CLF 402.
  • the CLF entity 402 is configured to send the user data of each user to the A-RACF entity 401 after receiving the user data synchronization request, so that A -RACF entity 401 and CLF entity The user data of 402 remains synchronized.
  • the user data synchronization request may carry an A-RACF identifier, where: the CLF entity 402 is configured to: after receiving the user data synchronization request, and according to the information carried in the user data synchronization request When the A-RACF identifier determines that the A-RACF entity is legal, the user data of each user is sent to the A-RACF entity corresponding to the A-RACF identifier, so that the A-RACF entity and the CLF entity corresponding to the A-RACF identifier are used. User data is kept in sync.
  • the CLF entity 402 is further configured to send a user data synchronization end notification to the A-RACF entity 401 after transmitting the user data of each user to the A-RACF entity 401;
  • the A-RACF entity 401 is further configured to return a user data synchronization end notification response to the CLF entity 402 after receiving the user data synchronization end notification.
  • the CLF 402 entity may be further configured to: after receiving the user data synchronization request, determine, after the user data synchronization is performed to the A-RACF entity 401 according to the local policy rule, send the user of each user to the A-RACF entity 401.
  • the data is sent to the A-RACF entity 401 with a user data synchronization response, and the user data synchronization response carries information indicating consent to synchronization.
  • the CLF entity 402 can be configured to, after receiving the user data synchronization request, and after determining that the user data synchronization is performed to the A-RACF entity 401 according to local policy rules,
  • the CLF entity 402 can be further configured to: determine, according to local policy rules and/or user privacy information, a list of users that can be synchronized to the A-RACF entity 401, and send the user of the user list to the A-RACF entity 401.
  • User data so that A-RACF and CLF keep the user data of the user in the user list synchronized.
  • the CLF entity 402 is further configured to receive the user data synchronization. After the request, it is further determined whether the user data is being updated by another entity, and if so, waiting for the user data update to be completed, and synchronizing the updated user data to the A-RACF entity 401, if not, to A- The RACF entity 401 synchronizes the user data of each user.
  • the user data may include: a subscription user identifier, a user physical access identifier, a user logical access identifier, a user access network type, a user global unique IP address, a user initial gateway setting, and a user subscription. Any combination of data, user's QoS list, user-based charging rules, user-based policy information, or any combination of more than one.
  • the present invention can enable the A-RACF to synchronize the user data from the CLF by using the user data synchronization information stream after the user data is lost, thereby avoiding acquiring the user data through the user data acquisition information flow when the user session is established, thereby effectively reducing the user data.
  • the user session establishment delay increases the user experience.
  • A-RACF can also audit user data through user data synchronization information flow, which can eliminate invalid user data and improve the reliability of A-RACF.
  • An embodiment of the invention also discloses an A-RACF.
  • FIG. 5 is a schematic diagram showing an exemplary structure of an A-RACF according to an embodiment of the present invention.
  • the A-RACF includes a user data synchronization request transmitting unit 501 and a user data receiving unit 502, where:
  • a user data synchronization request sending unit 501 configured to generate a user data synchronization request, and send the user data synchronization request to the CLF;
  • the user data receiving unit 502 is configured to receive user data sent by the CLF in response to the user data synchronization request.
  • FIG. 6 is a schematic diagram showing an exemplary structure of a CLF according to an embodiment of the present invention.
  • the CLF includes a user data synchronization request receiving unit 601 and a user data transmitting unit 602, where:
  • a user data synchronization request receiving unit 601 configured to receive a user data synchronization request sent by the A-RACF;
  • the user data sending unit 602 is configured to return user data to the A-RACF in response to the user data synchronization request.
  • the user data synchronization request carries an A-RACF identifier
  • the CLF further includes a determining unit.
  • a determining unit configured to determine, according to the A-RACF identifier carried in the user data synchronization request, whether the A-RACF is legal; the user data sending unit is configured to: when the determining unit determines that the A-RACF is legal, User data is returned to the A-RACF in response to the user data synchronization request.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

下一代网络中同步用户数据的方法、 装置和系统
技术领域
本发明涉及下一代网络（ NGN, Next Generation Network )技术领域， 更具体地， 本发明涉及一种下一代网络中同步用户数据的方法、 装置和 系统。 发明背景
互联网诞生以来， 采用 "尽力而为" （Best-Effort ) 的分发模式， 并 没有服务质量（QoS, Quality Of Service )保证。 在尽力而为的服务模式 下， 所有业务的需求都采用相同的优先级来排队处理， 无法为特定的高 要求业务提供更好的 QoS保证。
为此， 互联网工程任务组（IETF, Internet Engineering Task Force ) 提出了诸如差分服务（DiffServ )和综合服务（InterServ )之类的 IP服 务质量技术。 DiffServ 能够为不同类型的流量提供不同的服务等级， 而 InterServ能够为互联网保证严格的端到端的服务质量。 InterServ是一种 基于流的 QoS机制， 它对资源进行严格控制， 为应用提供严格的 QoS 保证。 但是， InterServ存在扩展性问题， 由于业务流经过的每个路由器 必须为其维护软状态， 所以 IntServ无法大规模使用。 DiffServ是一种基 于类的 QoS机制， 它在部署上比较成功， 但它只能提供相对的 QoS保 证， 特别是当带宽不够时仍然无法保证 QoS。
2002年， IETF提出 DS-Aware MPLS TE模型。 在该模型中融入了 DiffServ和 MPLS - TE的优点， 优化了传输资源， 也进一步提高了网络 的性能和效率。 然而， 这种模型存在 N平方问题， 而且在解决域间互通 的问题上存在困难。 当前业界普遍观点是： 无论大带宽还是 DiffServ都无法真正解决端 到端 QoS问题。 近几年， 基于会话的动态 QoS ( DQoS, Dynamic QoS ) 控制机制逐渐成为研究方向， 该机制在控制平面实现基于每个会话的 CAC、 资源预留和动态的策略下发； 在数据平面完成业务感知和策略执 行。 这种机制既能够提供严格的 QoS保证， 又具有良好的可扩展性。 目 前很多标准组织都在研究类似机制， 其中电信和互联网融合业务及高级 网络（TISPAN ) 的研究得到了比较广泛的认可。
图 1为现有技术中 TISPAN制定的 NGN网络架构图。该架构采用面 向子系统（Subsystem )的设计思想。 它能够随着时间不断适应新的需求 和业务， 而且便于从其它标准组织引入子系统。 另外， 子系统内的架构 可以灵活调整而不会影响其它子系统， 并且每个子系统又是一个功能实 体和接口的集合。 在具体实施时可以根据商业模型、 提供的业务和能力 将有些功能实体组合在一起， 所以这些实体之间的接口就变为内部接 口。
如图 1所示， 该功能架构分为业务层和基于 IP的传输层。 业务层有 以下部件： core IP Multimedia Subsystem ( IMS )、 PSTN/ISDN仿真子 系统（ Emulation Subsystem ) ( PES )、 其它多媒体系统（如流媒体子系 统、 内容广播子系统） 以及应用。 另外， 业务层还有一些公共部件如计 费功能、 用户数据管理、 安全管理、 路由数据库等。 传输层为用户设备 提供 IP互连， 它包括两个控制子系统： 网络附着子系统（NASS )和资 源接纳控制子系统（ RACS )。
网络附着子系统（NASS, Network Attachment Sub-system )主要完 成以下功能：
( 1 )动态提供 IP地址以及其它用户设备配置参数； （ 2 )在 IP地址 分配之前或分配过程中的用户认证； ( 3 ) 网络接入授权； （4 )用户位置 管理； （5 ) CPE配置。
资源接纳控制子系统 ( RACS , Resource and Admission Control Sub-system )主要提供接纳控制和关口控制 （gate Control )功能。 接纳 控制涉及到基于运营者的策略规则、 资源可用性， 以及用户签约信息来 进行检查和授权。 NASS子系统中的连通会话位置存储功能实体（ CLF , Connectivity Session Location and Repository Function )可以为 RACS子 系统提供用户定位信息和用户签约信息等用户数据。
在 RACS 子系统中的接入网资源接纳控制功能实体（A-RACF , Access Resource and Admission Control Functional entity )和 NASS子系统 中的 CLF功能实体之间定义了 E4参考点。 通过该 E4参考点， A-RACF 从 CLF获取位置信息（如到达用户的物理节点地址）以确定可用的网络 资源。 A-RACF还可以从 CLF获取用户网络清单（ profile )信息， 以在 处理分配资源请求时作为参考。 在 E4参考点上交换的信息主要包括： 签约用户标识、 用户物理接入标识、 用户逻辑接入标识、 用户接入网络 类型、 用户全局唯一 IP地址、 用户初始关口设置、 用户的签约数据、 用 户的 QoS清单（ profile )、基于用户的计费规则、基于用户的策略信息等。
CLF与 A-RACF之间定义了三种信息流： 1 )用户数据上报信息流： 这个信息流用于 CLF将用户数据主动上报给 A-RACF,该信息流发生在 IP地址分配给用户后，或者已经上报给 A-RACF的用户签约数据修改时。 2 )用户数据获取信息流： 这个信息流用于 A-RACF向 CLF请求特定的 用户数据，用户数据获取信息流的响应是用户数据上报信息流。 A-RACF 必须向 CLF提供用户的全局唯一 IP地址或者用户标识， CLF将根据这 些信息来上报正确的用户数据。 3 ) IP 连通性释放指示信息流： 这个信 息流用于 CLF向 RACS上报 IP连通性丟失， 这使得 RACS可以将相应 的用户数据删除掉，该信息流发生在已分配的 IP地址被释放时或者由于 二层资源释放引起。
然而， CLF 与 A-RACF 之间现有的信息流不能 4艮好地解决由于 A-RACF内部故障引起的已上报用户数据丟失的问题。 当这种 A-RACF 的内部故障引起 CLF与 A-RACF之间的协议连接中断时， CLF可以在 与 A-RACF之间的协议连接重建时，通过用户数据上报信息流来重新上 报用户数据。 但是， 如果这种 A-RACF 的内部故障并未引起 CLF 与 A-RACF之间的协议连接中断，那么 CLF就无法检测到 RACS内部故障， 因此不会重新上报用户数据， A-RACF也就无法和 CLF保持用户数据同 步。 这样， A-RACF在对用户会话进行资源接纳控制时发现没有用户数 据，将需要通过用户数据获取信息流来向 CLF获取用户数据， 而用户数 据获取信息流将加大用户会话建立的时延， 影响用户体验。 发明内容
本发明实施例提出一种下一代网络中同步用户数据的方法， 以使得 A-RACF能够和 CLF保持用户数据同步。
本发明实施例提出一种下一代网络中同步用户数据的系统， 以使得 A-RACF能够和 CLF保持用户数据同步。
本发明实施例还提出一种 A-RACF和 CLF,以使得 A-RACF能够和 CLF保持用户数据同步。
本发明实施例的技术方案是这样实现的：
一种下一代网络中同步用户数据的方法， 该方法包括：
接入网资源接纳控制功能实体 A-RACF向连通会话位置存贮功能实 体 CLF发送用户数据同步请求；
CLF接收到所述用户数据同步请求后， 向该 A-RACF发送用户的用 户数据， 以使 A-RACF和 CLF的用户数据保持同步。 一种下一代网络中同步用户数据的系统， 该系统包括 A-RACF实体 和 CLF实体， 其中：
A-RACF实体， 用于向 CLF实体发送用户数据同步请求；
CLF实体， 用于在接收到所述用户数据同步请求后， 向该 A-RACF 实体发送各用户的用户数据， 以使 A-RACF实体和 CLF实体的用户数 据保持同步。
一种 A-RACF, 该 A-RACF包括用户数据同步请求发送单元和用户 数据接收单元， 其中：
用户数据同步请求发送单元，用于生成用户数据同步请求，并向 CLF 发送该用户数据同步请求；
用户数据接收单元， 用于接收 CLF响应该用户数据同步请求所发送 来的用户数据。
一种 CLF,该 CLF包括用户数据同步请求接收单元和用户数据发送 单元， 其中：
用户数据同步请求接收单元， 用于接收由 A-RACF发送来的用户数 据同步请求；
用户数据发送单元， 用于响应于该用户数据同步请求向 A-RACF返 回用户数据。
从上述技术方案中可以看出， 在本发明中， A-RACF首先向 CLF发 送用户数据同步请求； CLF接收到所述用户数据同步请求后， 向该 A-RACF同步各用户的用户数据。 因此， 应用本发明以后， A-RACF可 以指示 CLF向 A-RACF同步用户数据， 所以 A-RACF能够和 CLF保持 用户数据同步。 附图简要说明
图 1为现有技术中 TISPAN制定的下一代网络架构图；
图 2为根据本发明实施例的下一代网络中同步用户数据方法的流程 图；
图 3为根据本发明实施例的下一代网络中同步用户数据方法的示范 性流程图；
图 4为根据本发明实施例的下一代网络中同步用户数据系统的示范 性结构示意图。
图 5为根据本发明实施例的 A-RACF的示范性结构示意图。
图 6为根据本发明实施例的 CLF的示范性结构示意图。 实施本发明的方式
为使本发明的目的、 技术方案和优点表达得更加清楚明白， 下面结 合附图及具体实施例对本发明再作进一步详细的说明。
在本发明实施例中，提出了 A-RACF和 CLF之间的一种新的信息流， 即用户数据同步信息流， 从而可以解决诸如 CLF 由于无法检测到由 A-RACF内部故障引起的已上报用户数据丟失等问题。
图 2为根据本发明实施例的下一代网络中同步用户数据方法的示范 性流程图。 如图 2所示， 该方法包括：
步骤 201： A-RACF向 CLF发送用户数据同步请求；
在这里， A-RACF在检测到需要与 CLF进行用户数据同步后， 将向 CLF发送用户数据同步请求消息。
示范性地， 用户数据同步请求消息中涉及的信息元素可以如下面的 表 1所示。 信息元素名 对应的 携带情况 描述 AVP
RACS-Id AF-App 必须携带 标识请求用户数据的 A-RACF功能实体
lication- Identifie
r 表 1
用户数据同步请求消息中需要携带 AF- Application-Identifier AVP, 并 将该 AVP的值设置为请求用户数据的 A-RACF功能实体的标识。
用户数据同步请求消息的命令码可以由 IANA组织统一分配， 并且 用户数据同步请求消息的 Diameter消息格式可以定义如下：
〈用户数据同步请求消息>：: = < Diameter Header: REQ, PXY>
< Session-Id >
Figure imgf000009_0001
[AF- Application-Identifier]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record]
其中， < Diameter Header: REQ, PXY>表示 Diameter消息头， 可以带 请求标志 、 代理标志 ； < Session-Id >表示会话标 只 ； { Vendor-Specific- Application-Id }表示运营商具体应用 标识； { Auth-Session-State }表示授权会话状态； { Origin-Host }表示源主机名； { Origin-Realm }表示源 i或名； [ Destination-Host ]表示目的主机名； { Destination-Realm }表示目的 i或名； [AF- Application-Identifier]表示应用 功能标识； *[ AVP ]表示其它 AVP; *[ Proxy-Info ]表示代理信息； *[ Route-Record ]表示路由记录。
步骤 202: CLF接收到所述用户数据同步请求后， 向该 A-RACF同步 各用户的用户数据。
在这里， CLF接收到所述用户数据同步请求后， 可以根据携带在用户 数据同步请求中的所述 A-RACF标识， 进一步判断该 A-RACF是否合法， 如果合法则向该 A-RACF标识所对应的 A-RACF发送各用户的用户数据， 以使该 A-RACF标识所对应的 A-RACF和该 CLF的用户数据保持同步，如 果不合法， 则不执行同步操作。
另外， CLF在向 A-RACF同步各用户的用户数据之后， CLF还可以向 A-RACF发送用户数据同步结束通知。 更优选地， A-RACF收到所述用户 数据同步结束通知后， 可以向 CLF返回用户数据同步结束通知应答。
可选地， CLF在接收到所述用户数据同步请求后， CLF可以进一步根 据本地策略规则判断是否向 A-RACF进行用户数据同步， 如果本地策略 规则允许向 A-RACF进行用户数据同步，则向 A-RACF发送各用户的用户 数据， 并且向 A-RAC发送携带表示同意同步的信息的用户数据同步应 答；如果本地策略规则不允许向 A-RACF进行用户数据同步，则向 A-RAC 发送携带表示拒绝同步的信息的用户数据同步应答， 并不向 A-RACF发 送各用户的用户数据。 优选地， CLF接收到所述用户数据同步请求后， 后， CLF还可以进一步根据本地的策略规则和 /或用户的隐私信息， 确定 出能够向 A-RACF同步的用户名单，并向 A-RACF发送该用户名单中用户 的用户数据， 以使 A-RACF实体和 CLF实体对该用户名单中用户的用户 数据保持同步。 另夕卜， CLF接收到所述用户数据同步请求后，优选进一步判断用户数 据是否正在被更新，如果是，则等待该用户数据更新完成，并向 A-RACF 发送各用户被更新后的用户数据； 如果不是， 则向 A-RACF发送各用户 的用户数据。
本发明实施例中， 用户数据可以包括： 签约用户标识、 用户物理接 入标识、 用户逻辑接入标识、 用户接入网络类型、 用户全局唯一 IP地址、 用户初始关口设置、 用户的签约数据、 用户的 QoS清单、 基于用户的计 费规则、 基于用户的策略信息中的任意一个或者多于一个的任意组合。
示范性地， 用户数据同步应答消息的命令码可以与用户数据同步请 求消息相同， 并且用户数据同步应答消息的消息格式可以定义如下： (〈用户数据同步应答消息>：: = < Diameter Header: PXY>
< Session-Id >
Figure imgf000011_0001
*[ Failed- AVP ]
*[ Proxy-Info ]
*[ Route-Record]
其中， < Diameter Header: PXY>表示 Diameter消息头： 带代理标志； < Session-Id >表示会话标识； { Vendor-Specific- Application-Id }表示运营 商具体应用标识； [ Result-Code ]表示结果码； [ Experimental-Result ]表 示实验结果； { Auth-Session-State }表示授权会话状态； { Origin-Host } 表示源主机名； { Origin-Realm }表示源域名； *[ AVP ]表示其它 AVP; *[ Failed- AVP ]表示失败信息； *[ Proxy-Info ]表示代理信息； *[ Route-Record ]表示路由记录。 据同步的决策。 如果 CLF决定向 A-RACF同步用户数据， 则在向 A-RACF 发送用户数据同步应答消息中将 Result-Code AVP的值设置为 DIAMETER_SUCCESS , 如果 CLF决定不向 A-RACF同步用户数据， 则 在向 A-RACF发送用户数据同步应答消息中将 Result-Code AVP的值设置 为 除 DIAMETER_SUCCESS之夕卜 的值 。 比如 ， 可以设置为 DIAMETER_UNABLE_TO_COMPLY , 用来表示拒绝向 A-RACF同步用 户数据。
另外， A-RACF在收到 CLF的用户数据同步应答消息后， 可以将 A-RACF上已经存储的该 CLF上报的用户数据进行同步标记， 表示该用 户数据需要进行同步。
CLF在接纳 A-RACF的用户数据同步请求并向 A-RACF发送 A-RACF 用 户 数据 同 步应 答消 息 （ Result-Code AVP 的 值设置 为 DIAMETER_SUCCESS )后， 则开始向 A-RACF进行用户数据同步。 具 体地， CLF可以根据本地的策略规则和 /或用户的隐私信息， 检查 CLF内 存储的用户数据是否可以向该 A-RACF同步上报。对于可以向该 A-RACF 进行同步上报的用户数据， CLF还将检查用户数据当前是否正在被更新， 如果该用户数据正在被更新， CLF将延后对该用户数据的上报， 直到该 用户数据被更新后， 再将更新后的用户数据向 A-RACF进行上报。 的用户数据上报消息和用户数据上报应答消息组成。 在一个用户数据同 步过程中， 可能需要有多个用户数据上报交互。 示范性地， 用户数据上报消息涉及的信息元素可以如下表 2所示。
Figure imgf000013_0001
表 2
用户数据上报消息可以利用现有的消息， 其消息格式为： 〈用户数据上才艮消息 〉： := < Diameter Header: 309, REQ PXY> < Session-Id >
{ Vendor-Specific- Application-Id } { Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ Destination-Realm }
[Globally-Unique-IPAddress]
[User-Name]
[Logical- Access-Id]
[Physical- Access-Id]
[Access-Network- Type]
[Initial-Gate-Setting]
*[QoS-Profile]
[IP- Connectivity- Statu s]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
其中， < Diameter Header: 309, REQ, PXY>表示 Diameter消息头： 命令码为 309, 带请求标志， 代理标志； < Session-Id >表示会话标识； { Vendor-Specific- Application-Id }表示运营商具体应用 标识； { Auth-Session-State }表示授权会话状态； { Origin-Host }表示源主机名； { Origin-Realm }表示源 i或名； { Destination-Host }表示目的主机名； { Destination-Realm }表示目的 i或名； [Globally-Unique-IPAddress]表示全 局唯一 IP地址； [User-Name]表示用户名； [Logical- Access-Id]表示還辑 接入 ID; [Physical- Access-Id]表示物理接手 ID; [Access-Network-Type] 表示接入网络类型； [Initial-Gate-Setting]表示初始门设置； *[QoS-Profile] 表示 QoS清单； [IP-Connectivity-Status]表示 IP连通性状态； *[ AVP ]表 示其它 AVP; *[ Proxy-Info ]表示代理信息； *[ Route-Record ]表示路由记 录。
A-RACF在收到 CLF的每个用户数据上报消息后， 将会向 CLF发 送用户数据上报应答消息来进行响应。 用户数据上报应答消息也可以利 用现有的消息， 其消息格式为：
〈用户数据上报应答消息>：: =< Diameter Header: 309, PXY>
< Session-Id >
{ Vendor-Specific- Application-Id
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ AVP ]
*[ Failed- AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
其中， < Diameter Header: 309, PXY>表示 Diameter消息头： 命令码 为 309 , 带代理标志 ； < Session-Id >表示会话标识 ； { Vendor-Specific- Application-Id }表示运营商具体应用 标识； [ Result-Code ]表示结果码； [ Experimental-Result ]表示实险结果； { Auth-Session-State }表示授权会话状态； { Origin-Host }表示源主机名； { Origin-Realm }表示源域名； * [ AVP ]表示其它 AVP； * [ Failed- AVP ]表 示失败信息； *[ Proxy-Info ]表示代理信息； *[ Route-Record ]表示路由记 录。 如果 A-RACF上已经存在所上报的用户数据， 则对所存储的用户数 据进行更新， 如果原用户数据存在同步标记， 则清除该同步标记； 如果
A-RACF没有所上报的用户数据， 则对所上报的用户数据进行存储。
其中， CLF在向 A-RACF同步完所有需要同步的用户数据后， 可以 向 A-RACF指示用户数据同步结束。 具体地， 当 CLF向 A-RACF同步 完所有需要同步的用户数据后，可以向 A-RACF发送用户数据同步结束 通知消息。
用户数据同步结束通知消息的命令码可以由 IANA组织统一分配， 并且用户数据同步结束通知消息的消息格式可以定义如下：
〈用户数据同步结束通知消息〉： := < Diameter Header: REQ,
PXY>
< Session-Id >
{ Vendor-Specific- Application-Id } { Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ Destination-Realm }
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
其中， < Diameter Header: REQ, PXY>表示 Diameter消息头： 带请求 标 志 ， 代 理 标 志 ； < Session-Id > 表 示 会 话 标 识 ； { Vendor-Specific- Application-Id }表示运营商具体应用 标识； { Auth-Session-State }表示授权会话^犬态； { Origin-Host }表示源主机名； { Origin-Realm }表示源 i或名； [ Destination-Host ]表示目的主机名； { Destination-Realm }表示目的 i或名； *[ AVP ]表示其它 AVP； *[ Proxy-Info ]表示代理信息； *[ Route-Record ]表示路由记录。
另外， A-RACF在收到 CLF的用户数据同步结束通知消息后， 还可 以向 A-RACF发送用户数据同步结束通知应答消息以进行响应。
用户数据同步结束通知应答消息的命令码可以与用户数据同步请求 消息的相同， 并且该消息的消息格式可以定义为如下：
〈用户数据同步结束通知应答消息>：: = < Diameter Header: PXY>
< Session-Id >
{ Vendor-Specific- Application-Id
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ AVP ]
*[ Failed- AVP ]
[ Proxy-Info ]
*[ Route-Record ]
其中， < Diameter Header: PXY>表示 Diameter消息头： 带代理标志； < Session-Id >表示会话标识； { Vendor-Specific- Application-Id }表示运营 商具体应用标识； [ Result-Code ]表示结果码； [ Experimental-Result ]表 示实验结果； { Auth-Session-State }表示授权会话状态； { Origin-Host } 表示源主机名； { Origin-Realm }表示源域名； *[ AVP ]表示其它 AVP; *[ Failed- AVP ]表示失败信息； *[ Proxy-Info ]表示代理信息； *[ Route-Record ]表示路由记录。
优选地， A-RACF对该 CLF在同步开始之前所上报的用户数据进行 检查， 对于仍然存在同步标记的用户数据（这说明该用户数据在同步过 程中没有重新上报， 否则该同步标记应该已经被清除）， A-RACF将认为 这些用户数据不再有效， A-RACF将删除这些用户数据并释放受影响的 会话。
基于图 2所示流程以及上述详细分析， 图 3为根据本发明实施例的 下一代网络中同步用户数据方法的示范性流程图。 如图 3所示， 该方法 包括：
步骤 301: A-RACF向 CLF发送用户数据同步请求；
步骤 302: CLF向 A-RACF返回用户数据同步应答；
步骤 303: CLF向 A-RACF上报用户 1的用户数据；
步骤 304: A-RACF向 CLF返回关于用户 1的用户数据上报应答； 然后， 在下面的步骤中， CLF依次向 A-RACF上报其余用户的用户 数据， 并且 A-RACF向 CLF返回各用户的用户数据上报应答。 在完成 数据的同步上报以后， CLF向 A-RACF发送用户数据同步结束通知， 然 后 A-RACF向 CLF返回用户数据结束通知应答。
以上实施例中， 虽然各个用户的用户数据上报应答紧随着用户数据 上报， 然而在实际中却不一定要严格按照这种顺序， 本发明对此也并无 任意限定。
本发明实施例还公开了一种下一代网络中同步用户数据的系统。 图 4 为根据本发明实施例的下一代网络中同步用户数据系统的示范性结构 示意图。 如图 4所示， 该系统包括 A-RACF 实体 401和 CLF实体 402, 其中：
A-RACF实体 401 , 用于向 CLF 402发送用户数据同步请求； CLF实体 402,用于在接收到所述用户数据同步请求后，向 A-RACF 实体 401发送各用户的用户数据， 以使 A-RACF实体 401和 CLF实体 402的用户数据保持同步。
其中， 所述用户数据同步请求中可以携带有 A-RACF标识， 此时： CLF实体 402, 用于在接收到所述用户数据同步请求后， 并当根据 携带在用户数据同步请求中的所述 A-RACF标识判定该 A-RACF实体合 法时，向该 A-RACF标识所对应的 A-RACF实体发送各用户的用户数据， 以使该 A-RACF标识所对应的 A-RACF实体和 CLF实体的用户数据保 持同步。
优选地， CLF实体 402, 进一步用于在向 A-RACF实体 401发送各 用户的用户数据之后， 向 A-RACF实体 401发送用户数据同步结束通 知；
A-RACF实体 401 , 进一步用于在收到所述用户数据同步结束通知 后， 向 CLF 实体 402返回用户数据同步结束通知应答。
另外， CLF 402实体， 还可以用于在接收到所述用户数据同步请求 后，并根据本地策略规则确定向 A-RACF实体 401进行用户数据同步后， 向 A-RACF实体 401发送各用户的用户数据，并且向 A-RACF 实体 401 发送用户数据同步应答， 在该用户数据同步应答中携带有表示同意同步 的信息。
而且， CLF实体 402, 可以用于在接收到所述用户数据同步请求后， 并且在根据本地的策略规则判定出向 A-RACF实体 401进行用户数据同 步后，
该 CLF实体 402可以进一步用于， 根据本地的策略规则和 /或用户 的隐私信息， 确定出能够向 A-RACF 实体 401 同步的用户名单， 并向 A-RACF实体 401发送该用户名单中用户的用户数据， 以使 A-RACF和 CLF对该用户名单中用户的用户数据保持同步。
优选地， CLF实体 402, 还可以用于在接收到所述用户数据同步请 求后， 进一步判断用户数据是否正在被另外的实体更新， 如果是， 则等 待该用户数据更新完成， 并向 A-RACF实体 401同步各用户被更新后的 用户数据， 如果不是， 则向 A-RACF实体 401同步各用户的用户数据。
在该示范性系统中， 所述用户数据可以包括： 签约用户标识、 用户 物理接入标识、 用户逻辑接入标识、 用户接入网络类型、 用户全局唯一 IP地址、 用户初始关口设置、 用户的签约数据、 用户的 QoS清单、 基于 用户的计费规则、 基于用户的策略信息中的任意一个或者多于一个的任 意组合。
显然， 以上对用户数据的罗列仅为示范性的， 并不用于限定本发明 的保护范围， 本发明同样适用于其它类型的用户数据信息。
综上， 本发明可以使得 A-RACF在用户数据丟失后能够使用用户数 据同步信息流从 CLF同步用户数据，避免了在用户会话建立时再通过用 户数据获取信息流来获取用户数据， 从而有效降低了用户会话建立时 延， 提高了用户体验。 另外， A-RACF还可以通过用户数据同步信息流 来对用户数据进行审计， 从而能够清除无效的用户数据， 进而提高了 A-RACF的可靠性。
本发明实施例还公开了一种 A-RACF。
图 5为根据本发明实施例的 A-RACF的示范性结构示意图。
如图 5所示， 该 A-RACF包括用户数据同步请求发送单元 501和用 户数据接收单元 502, 其中：
用户数据同步请求发送单元 501 , 用于生成用户数据同步请求， 并 向 CLF发送该用户数据同步请求；
用户数据接收单元 502, 用于接收 CLF响应该用户数据同步请求所 发送来的用户数据。
本发明实施例还公开了一种 CLF。 图 6为根据本发明实施例的 CLF的示范性结构示意图。
如图 6所示，该 CLF包括用户数据同步请求接收单元 601和用户数 据发送单元 602, 其中：
用户数据同步请求接收单元 601 , 用于接收由 A-RACF发送来的用 户数据同步请求；
用户数据发送单元 602 ,用于响应于该用户数据同步请求向 A-RACF 返回用户数据。
优选地，用户数据同步请求中携带有 A-RACF标识，该 CLF进一步 包括判断单元。 判断单元， 用于根据携带在用户数据同步请求中的所述 A-RACF标识， 进一步判断该 A-RACF是否合法； 此时用户数据发送单 元， 用于当判断单元判断该 A-RACF合法时， 响应于该用户数据同步请 求向 A-RACF返回用户数据。
以上所述，仅为本发明的较佳实施例而已， 并非用于限定本发明的 保护范围。 凡在本发明的精神和原则之内， 所作的任何修改、等同替换、 改进等， 均应包含在本发明的保护范围之内。

Claims

权利要求书
1、 一种下一代网络中同步用户数据的方法， 其特征在于， 该方法包 括：
接入网资源接纳控制功能实体 A-RACF向连通会话位置存贮功能实 体 CLF发送用户数据同步请求；
CLF接收到所述用户数据同步请求后， 向该 A-RACF发送用户的用 户数据， 以使 A-RACF和 CLF的用户数据保持同步。
2、根据权利要求 1所述的下一代网络中同步用户数据的方法，其特 征在于， 所述用户数据同步请求中携带有 A-RACF标识，
CLF接收到所述用户数据同步请求后， 根据携带在用户数据同步请 求中的所述 A-RACF标识，进一步判断该 A-RACF是否合法，如果合法， 则向该 A-RACF标识所对应的 A-RACF发送各用户的用户数据，以使该 A-RACF标识所对应的 A-RACF和该 CLF的用户数据保持同步。
3、根据权利要求 1所述的下一代网络中同步用户数据的方法，其特 征在于， 该方法进一步包括：
CLF在向 A-RACF发送各用户的用户数据之后， CLF 进一步向 A-RACF发送用户数据同步结束通知。
4、根据权利要求 3所述的下一代网络中同步用户数据的方法，其特 征在于， 该方法进一步包括：
A-RACF收到所述用户数据同步结束通知后， 向 CLF返回用户数据 同步结束通知应答。
5、根据权利要求 1所述的下一代网络中同步用户数据的方法，其特 征在于， CLF在接收到所述用户数据同步请求后，
CLF进一步根据本地策略规则判 步， 如果是， 则向 A-RACF发送各用户的用户数据， 并且向 A-RACF发 送携带表示同意同步的信息的用户数据同步应答；如果否，则向 A-RACF 发送携带表示拒绝同步的信息的用户数据同步应答。
6、根据权利要求 5所述的下一代网络中同步用户数据的方法，其特 征在于， CLF接收到所述用户数据同步请求后，并且 CLF在根据本地的 策略规则判定出向 A-RACF进行用户数据同步后，
CLF进一步根据本地的策略规则和 /或用户的隐私信息，确定出能够 向 A-RACF同步的用户名单，并向 A-RACF发送该用户名单中用户的用 户数据， 以使 A-RACF和 CLF对该用户名单中用户的用户数据保持同 步。
7、根据权利要求 1所述的下一代网络中同步用户数据的方法，其特 征在于， CLF接收到所述用户数据同步请求后， 进一步判断用户数据是 否正在被更新， 如果是， 则等待该用户数据更新完成， 并向 A-RACF发 送各用户被更新后的用户数据， 如果不是， 则向 A-RACF发送各用户的 用户数据。
8、根据权利要求 1-7中任一项所述的下一代网络中同步用户数据的 方法， 其特征在于， 所述用户数据包括： 签约用户标识、 用户物理接入 标识、 用户逻辑接入标识、 用户接入网络类型、 用户全局唯一 IP地址、 用户初始关口设置、 用户的签约数据、 用户的 QoS清单、 基于用户的计 费规则、 基于用户的策略信息中的任意一个或者多于一个的任意组合。
9、 一种下一代网络中同步用户数据的系统， 其特征在于， 该系统包 括 A-RACF实体和 CLF实体， 其中：
A-RACF实体， 用于向 CLF实体发送用户数据同步请求；
CLF实体， 用于在接收到所述用户数据同步请求后， 向该 A-RACF 实体发送各用户的用户数据， 以使 A-RACF实体和 CLF实体的用户数 据保持同步。
10、 根据权利要求 9所述的下一代网络中同步用户数据的系统， 其 特征在于， 所述用户数据同步请求中携带有 A-RACF标识，
CLF实体， 用于在接收到所述用户数据同步请求后， 并当根据携带 在用户数据同步请求中的所述 A-RACF标识判定该 A-RACF实体合法 时， 向该 A-RACF标识所对应的 A-RACF实体发送各用户的用户数据， 以使该 A-RACF标识所对应的 A-RACF实体和 CLF实体的用户数据保 持同步。
11、 根据权利要求 9所述的下一代网络中同步用户数据的系统， 其 特征在于，
CLF实体，进一步用于在向 A-RACF实体发送各用户的用户数据之 后， 向 A-RACF实体发送用户数据同步结束通知。
12、根据权利要求 11所述的下一代网络中同步用户数据的系统，其 特征在于，
A-RACF实体， 进一步用于在收到所述用户数据同步结束通知后， 向 CLF实体返回用户数据同步结束通知应答。
13、 根据权利要求 9所述的下一代网络中同步用户数据的系统， 其 特征在于，
CLF实体， 用于在接收到所述用户数据同步请求后， 并根据本地策 略规则确定向 A-RACF实体进行用户数据同步后，向 A-RACF实体发送 各用户的用户数据， 并且向 A-RACF实体发送用户数据同步应答， 在该 用户数据同步应答中携带有表示同意同步的信息。
14、根据权利要求 13所述的下一代网络中同步用户数据的系统，其 特征在于，
CLF实体， 用于在接收到所述用户数据同步请求后， 并且在根据本 地的策略规则判定出向 A-RACF实体进行用户数据同步后，
该 CLF 实体进一步用于， 根据本地的策略规则和 /或用户的隐私信 息，确定出能够向 A-RACF实体同步的用户名单， 并向 A-RACF实体发 送该用户名单中用户的用户数据， 以使 A-RACF实体和 CLF实体对该 用户名单中用户的用户数据保持同步。
15、 根据权利要求 9所述的下一代网络中同步用户数据的系统， 其 特征在于，
CLF实体， 用于在接收到所述用户数据同步请求后， 进一步判断用 户数据是否正在被更新， 如果是， 则等待该用户数据更新完成， 并向 A-RACF实体发送各用户被更新后的用户数据，如果不是，则向 A-RACF 实体发送各用户的用户数据。
16、根据权利要求 9-15中任一项所述的下一代网络中同步用户数据 的系统， 其特征在于，
所述用户数据包括： 签约用户标识、 用户物理接入标识、 用户逻辑 接入标识、 用户接入网络类型、 用户全局唯一 IP地址、 用户初始关口设 置、 用户的签约数据、 用户的 QoS清单、 基于用户的计费规则、 基于用 户的策略信息中的任意一个或者多于一个的任意组合。
17、 一种 A-RACF, 其特征在于， 该 A-RACF包括用户数据同步请 求发送单元和用户数据接收单元， 其中：
用户数据同步请求发送单元，用于生成用户数据同步请求，并向 CLF 发送该用户数据同步请求；
用户数据接收单元，用于接收 CLF响应该用户数据同步请求所发送 来的用户数据。
18、 一种 CLF, 其特征在于， 该 CLF包括用户数据同步请求接收单 元和用户数据发送单元， 其中： 用户数据同步请求接收单元， 用于接收由 A-RACF发送来的用户数 据同步请求；
用户数据发送单元， 用于响应于该用户数据同步请求向 A-RACF返 回用户数据。
19、 根据权利要求 18所述的 CLF, 其特征在于， 所述用户数据同 步请求中携带有 A-RACF标识， 该 CLF进一步包括判断单元，
判断单元， 用于根据携带在用户数据同步请求中的所述 A-RACF标 识， 进一步判断该 A-RACF是否合法；
用户数据发送单元， 用于当判断单元判断该 A-RACF合法时， 响应 于该用户数据同步请求向 A-RACF返回用户数据。
PCT/CN2007/070734 2006-09-30 2007-09-20 Procédé, dispositif et système de synchronisation de données utilisateur dans un réseau nouvelle génération WO2008049355A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP07816925A EP2068508A1 (en) 2006-09-30 2007-09-20 Method, device and system for synchronizing user data in next generation network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200610159672.2 2006-09-30
CN 200610159672 CN101155023A (zh) 2006-09-30 2006-09-30 一种下一代网络中同步用户数据的方法和系统

Publications (1)

Publication Number Publication Date
WO2008049355A1 true WO2008049355A1 (fr) 2008-05-02

Family

ID=39256486

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2007/070734 WO2008049355A1 (fr) 2006-09-30 2007-09-20 Procédé, dispositif et système de synchronisation de données utilisateur dans un réseau nouvelle génération

Country Status (3)

Country Link
EP (1) EP2068508A1 (zh)
CN (1) CN101155023A (zh)
WO (1) WO2008049355A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5421341B2 (ja) 2010-11-29 2014-02-19 ゼットティーイー（ユーエスエー）インコーポレーテッド 加入者サービス品質プロファイルを構成する方法及び装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1747400A (zh) * 2004-09-08 2006-03-15 华为技术有限公司 下一代网络中动态协商服务质量的系统及其实现方法
CN1747467A (zh) * 2004-09-08 2006-03-15 华为技术有限公司 一种ngn中的资源和准入控制子系统及方法
CN1832447A (zh) * 2005-03-08 2006-09-13 华为技术有限公司 下一代网络中实现用户请求模式资源预留的方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1747400A (zh) * 2004-09-08 2006-03-15 华为技术有限公司 下一代网络中动态协商服务质量的系统及其实现方法
CN1747467A (zh) * 2004-09-08 2006-03-15 华为技术有限公司 一种ngn中的资源和准入控制子系统及方法
CN1832447A (zh) * 2005-03-08 2006-09-13 华为技术有限公司 下一代网络中实现用户请求模式资源预留的方法

Also Published As

Publication number Publication date
CN101155023A (zh) 2008-04-02
EP2068508A1 (en) 2009-06-10

Similar Documents

Publication Publication Date Title
US7647406B2 (en) Method for implementing resources reservation in a proxy-requested mode in next generation network
EP1762056B1 (en) Dynamic service information for the access network
AU2006344794B2 (en) Loss of signalling bearer transport
WO2006094448A1 (fr) Procede pour implementer la reservation des ressources en mode de requete utilisateur dans le reseau de prochaine generation
US8005090B2 (en) QoS information notification method, communication apparatus and inter-domain signaling apparatus for transmitting QoS information over a multi-domain network
WO2006026920A1 (fr) Methode et systeme pour une consultation dynamique de qualite de service dans un reseau de la prochaine generation (ngn)
WO2007025449A1 (fr) Procede de revocation de ressource basee sur le sous-systeme de controle d&#39;admission de ressource et dispositif reseau pour celle-ci
WO2009071012A1 (fr) Procédé, système et dispositif de traitement d&#39;une requête de flux multimédia dans un réseau sip
WO2011147074A1 (zh) 策略与计费控制的实现方法、系统及相应设备
WO2007085195A1 (fr) Système et procédé pour la gestion de requête de ressources
WO2011022893A1 (zh) 一种资源接纳控制系统间的交互方法和装置
WO2007082448A1 (fr) Procédé de qualité de service (qos) garantie, dispositif de gestion de ressources et système d&#39;accès multi-services
WO2009094869A1 (fr) Procédé de commande de ressources et d&#39;admission
WO2008083597A1 (fr) Procédé et dispositif de commande du nombre de sessions d&#39;un utilisateur
WO2009146593A1 (zh) 一种资源接纳控制方法及系统
WO2007085184A1 (fr) Procédé, système et entité pour la négociation de données multimédia
US20080317054A1 (en) SERVICE GATEWAY, SERVING SYSTEM, QoS NEGOTIATION METHOD AND SERVING RECOURSE RELEASE METHOD
US20090204698A1 (en) Method, system and apparatus for reserving bearer resources
WO2010075721A1 (zh) 一种基于签约数据的ims用户级控制方法及系统
WO2008151528A1 (fr) Procédé, dispositif et système pour commander une ressource de multidiffusion
WO2009079843A1 (fr) Procédé pour réaliser une gestion d&#39;accès aux ressources en mode du pousser en situation de nomadisme de réseau de prochaine génération
US20100023998A1 (en) Method, entity and system for realizing network address translation
WO2007033612A1 (fr) Systeme et procede de commande de ressource du reseau d&#39;acces
WO2010022610A1 (zh) 服务质量请求信息的实现方法以及策略执行功能实体
WO2008049355A1 (fr) Procédé, dispositif et système de synchronisation de données utilisateur dans un réseau nouvelle génération

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07816925

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2007816925

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE