WO2008003209A1 - A server locator function network element and application method thereof - Google Patents

Abstract

A server locator function network element comprises a configuring interface for configuring the relationship data between the user's identifier with wildcard and the address of the home subscriber server (HSS); a data storing unit for storing the relationship data acquired by the configuring interface; and a searching and processing unit for searching the home subscriber server's address corresponding to the user's identifier in the data storing unit based on the pending user's identifier contained in the searching request. The invention gives a concretely implement for the server locator function network element, and the skilled in the art can realize particular server locator function network element according the technical solution mentioned above.

Description

 Server positioning function network element and application method thereof

 This application claims priority to Chinese Patent Application No. 200610086572.1, entitled "A Server Location Function Network Element and Its Application Method", which is filed on June 30, 2006, the entire contents of which are incorporated by reference. In this application.

Technical equipment

 The present invention relates to the field of communications technologies, and in particular, to a server positioning function network element and an application method thereof.

Background technique

 Internet Multimedia Subsystem IMS (IP Multimedia Subsystem) is a subsystem added to the WCDMA (Wideband Code Division Multiple Access) network during the R3 phase of the 3rd Generation Partnership Project 3GPP (3rd Generation Partnership Project) Used to provide IP-based multimedia services. In the IMS network, the user identifier of the user is saved by the Home Subscriber Server (HSS) network element, such as IMS Private User Identity (IMPI), IMS Public User Identity (IMPU), International Mobile User ID IMSI (International Mobile Subscriber Identity) and so on. In addition, user information such as subscriptions and authentication is also stored in the HSS.

 In the Internet multimedia subsystem, other network elements download corresponding user information from the HSS network element according to the user identifier. For example, in the registration process of the IMS user, the query call server control function (I-CSCF) network element queries the user's capability set information through the Cx interface to the HSS network element, and the service call session control function (S-CSCF) network element The user's subscription information is downloaded from the Cx interface to the HSS network element. In the current IMS network, various network elements, such as an application server (AS) network element, an I-CSCF network element, an S-CSCF network element, and an AAA server, interact with the HSS network element to query or update the HSS network element. Specify the relevant subscription information of the user.

In an actual networking, an HSS network element supports a limited number of users. Therefore, there may be two or more HSS network elements in the IMS network. One user's subscription information is only stored in one of the HSS network elements. In the entity. The other network elements in the IMS network (such as the AS network element, the I-CSCF network element, the S-CSCF network element, the AAA Server network element, etc.) must know that the corresponding user information is stored in the home before performing data interaction with the HSS network element. Which HSS network element entity in the IMS network. To do this, in the IMS network The server location function SLF (Server Locator Function) network element is introduced.

 In the current 3GPP specification for IMS networks, it is pointed out that the IMS network can use Server Location Function (SLF) network elements. However, the server location function SLF is not specifically defined in the standard and there are no known implementations.

Summary of the invention

 The embodiment of the invention provides a server positioning function network element and an application method thereof to provide a specific implementation scheme of the SLF.

 The server positioning function network element provided by the embodiment of the present invention includes a configuration interface, configured to configure relationship data between the user name of the wildcard type and the HSS address of the home subscription server, and a data storage unit configured to store through the configuration interface. The obtained relation data; the query processing unit is configured to search, in the data storage unit, the home HSS address corresponding to the user identifier according to the to-be-checked user identifier included in the query request.

 Another server positioning function network element provided by the embodiment of the present invention includes:

 a receiving unit, configured to receive a message from another network element in the network, where the message includes a query request, and a sending unit, configured to send a message to other network elements in the network, where the message includes a response to the query result;

 The configuration interface is configured to configure relationship data between the user identifier and the HSS address of the home subscription server;

 a data storage unit, configured to store relationship data obtained through the configuration interface;

 a query processing unit, configured to search for a home HSS address corresponding to the to-be-checked user identifier in the data storage unit according to the to-be-checked user identifier included in the query request received by the receiving unit, and notify the query result The sending unit.

 The method for obtaining the home HSS address information by using the server positioning function network element is provided by the embodiment of the present invention, including: the server positioning function network element receives the query request message, where the message includes the user identifier to be checked; The user identifier is a keyword, and the relationship data between the matching local wildcard type user identifier and the home HSS address is searched; and the home HSS address in the matched relationship data is notified to the query request initiator.

According to the technical solution provided by the embodiment of the present invention, in the SLF network element structure of the server positioning function disclosed in the embodiment of the present invention, the configuration interface is used to provide the operator with the configuration wildcard type user standard. Knowing the relationship data between the HSS address and the home registration server; and further storing the relationship data obtained by the configuration interface through the data storage unit; when other network elements in the IMS network query the SLF network element, the SLF passes the query. The processing unit searches the data storage unit for the home HSS address corresponding to the user identifier according to the user identifier included in the query request, that is, can provide the query request initiator with the required information. It can be seen that the SLF network element disclosed in the present invention provides a specific feasible implementation manner, so that in two or more IMS networks, the network element that needs to perform data interaction with the HSS network element can pass The introduced SLF network element obtains address information of the home HSS.

DRAWINGS

 1 is an exemplary network diagram of an embodiment of the present invention;

 2 is a schematic structural view of a first embodiment of a server positioning function SLF network element according to an embodiment of the present invention;

 3 is a schematic structural diagram of a second embodiment of a server positioning function SLF network element according to an embodiment of the present disclosure;

 4 is a schematic structural diagram of a third embodiment of a server positioning function SLF network element according to an embodiment of the present invention;

 FIG. 5 is a flowchart of a method for obtaining a home HSS address by using an SLF network element according to an embodiment of the present invention;

 FIG. 6 is a schematic diagram of data interaction of an I-CSCF querying a user's home HSS address through an SLF network element according to an embodiment of the present invention.

detailed description

 In order to explain the technical solution of the present invention more clearly, an exemplary network diagram in which an embodiment of the present invention can be implemented is first introduced, as shown in FIG.

The IMS network includes various network elements that communicate with each other. For example, the exemplary network includes an application server (AS) 13, an inquiry call session control function (I-CSCF) 14, a service call session control function (S-CSCF) 15, and an authentication, authorization, and accounting server (AAA Server) 16. Each of the network elements communicates with a plurality of home subscription server network elements (HSS) 12 (also denoted as HSS1, HSS2, ...HSSn), and queries or updates related subscription information of the specified user in the HSS network element. However, since the subscription information of a user is only stored in one of the HSS network element entities, before the data element and the HSS network element perform data interaction, it must first know which one of the home IMS networks the corresponding user information is stored. In the HSS network element entity, the home location function SLF network element 11 acquires the home HSS address of the specified user.

 It is to be understood that the exemplary network diagrams shown in FIG. 1 are for the purpose of illustrating the embodiments of the present invention, and are not to be construed as limiting.

 Referring to FIG. 2, it is a schematic structural diagram of a first embodiment of an SLF network element according to an embodiment of the present invention. The SLF network element includes a configuration interface 21, a data storage unit 22 connected to the configuration interface 21, and an inquiry processing unit 23 connected to the data storage unit 22. Specifically, the configuration interface 21 includes a first configuration sub-interface 211 and a second configuration sub-interface 212; the data storage unit 22 includes a first data storage sub-unit 221 and a second data storage sub-unit 222; the query processing unit 23 includes a transceiver Unit 231 and matching subunit 232. The following describes the internal structure of the SLF network element in combination with the working principle of the SLF network element.

 First, the configuration interface 21 is described in detail, which may be an OSS (Operations Support System) interface, a network management interface, or a combination of several interface types.

 The network operator configures the relationship data between the user identifier and the HSS address of the home subscription server through the configuration interface 21 of the SLF network element. Specifically, the network operator configures the relationship data between the wildcard type user identifier and the home HSS address through the first configuration sub-interface 211; and configures the non-wildcard type user identifier and the home HSS address through the second configuration sub-interface 212. Relationship data. Of course, in the actual application, the two types of relationship data can be configured by sharing the same configuration interface.

The so-called wildcard type user identifier refers to a user identifier containing a wildcard, and a wildcard type user identifier can represent a specific group of user identifiers. For example, the user ID of a wildcard type is "sip:chatlist*(3⁄4domain.com", where "*" is a wildcard, and the wildcard can represent any form of the wildcard, then the user ID of the above generic type can represent The specific user identifier, such as: "sip:chatlist-bobo@domain.com", sip:chatlist"acky@domain.com", and "sip:chatlist3@domain.com,, etc. Need to pay attention The specific representation of wildcards is not limited to "*,,, you can use wildcards that you think are convenient, and the wildcards that exist in a wildcard type user ID are not limited to 1. In addition, wildcards are in a wildcard. The location of the type user identifier is also set according to the actual situation, which is essentially the extraction of a common part of multiple specific user identifiers. Of course, the wildcard can also be expressed in an implicit manner. For example, the operator can configure a wildcard type user identifier as "domain.com", and the wildcard does not appear in the wildcard type user identifier, but it can represent all A specific user ID containing the string "domain.com", including the implicit wildcard.

 A non-wild type user ID refers to a specific user ID, such as the aforementioned

"sipxhatlistJacky@domain.com" is a non-wildcard type of user ID.

 The network operator configures the relationship data between all the wildcard type user identifiers and the home HSS addresses through the first configuration sub-interface 211. The relationship data includes two parts of content, one of which is a user identifier of each wild type, and the other is HSS address information, and the relationship between the two parts is a corresponding relationship. For example, suppose that the configured relationship data contains 100 wildcard type user identifiers, and each wildcard type user identifier should be configured with a corresponding HSS address. Of course, 100 corresponding to the above 100 wildcard type user identifiers. Among the HSS addresses, some HSS addresses may be the same, that is, several wildcard type user identifiers correspond to the same HSS address. As mentioned above, each wildcard type user ID represents a specific set of user IDs, so the subscription information of the specific group of users it represents should exist in the same HSS, so as to ensure a wildcard type user. The identifier corresponds to an HSS address.

 The network operator configures the relationship data between the non-wildcard type user identifier and the home HSS address through the second configuration sub-interface 212. The relationship data also includes two parts, one of which is a non-wild type user identifier (also called a specific user identifier), and the other is HSS address information, and the content of the two parts is also a corresponding relationship. For example, if a user's specific ID is ABC and the subscription data is stored in HSS3, then there will be a relationship data in the SLF: Specific User ID ABC - The address of HSS3. Of course, the specific expression of the relational data is not limited as long as it can represent the correspondence between the user identifier and the HSS address.

 As can be seen from the above description, there are two types of relational data in the SLF, one is relational data including the user identification of the wildcard type, and the other is the relational data including the non-wildcard type user identifier. As for the specific allocation ratio of the two types of relationship data, it can be determined according to actual needs. For example, in the initial configuration process of the SLF network element, several relationship data including the user ID of the wildcard type may be configured, and the remaining configurations include the relationship data of the non-wild type user identifier.

It should be recognized that although the relational data in the SLF should be signed with the user stored in the HSS. Consistent (or synchronous), but this should not be construed as a limitation of the present invention, because either the SLF or the HSS are usually configured by the same network operator, so the synchronization between the two can be completely through the operator. solve. For example, in the initial configuration phase of the network element, the relationship data may be configured on the SLF, and then the user subscription data in each HSS network element may be configured accordingly; or the user subscription information may be configured for each HSS network element, and then according to The SLF is configured correspondingly in the storage situation in each HSS. If the existing HSS network elements are expanded or merged according to the actual situation, and the subscription data of some users is migrated, the relationship data in the SLF can be changed correspondingly through the configuration interface 21. Further, when the relationship data of a wildcard type user identifier and the home HSS address is modified, the relationship data between a specific user identifier and the home HSS is implicitly modified, thereby reducing the data modification to the SLF. The amount of work.

 Next, the data storage unit 22 for storing the relation data obtained by the configuration interface unit 21 is explained in detail. The data storage unit 22 specifically includes a first data storage subunit 221 and a second data storage subunit 222, which can be regarded as a database.

 The first data storage sub-unit 221 is configured to store relational data obtained through the first configuration sub-interface, that is, to store relational data including a wildcard type. The second data storage sub-unit 222 is configured to store relational data obtained through the second configuration sub-interface, that is, to store relational data including non-wildcard types. The data accessed in the data storage unit 22 provides services to the query processing unit 23.

 Finally, the internal structure of the query processing unit 23 is described, which searches the data storage unit 22 for the home HSS address corresponding to the user identifier based on the to-be-checked user identifier contained in the query request. Specifically, the query processing unit 23 includes a transceiving subunit 231 and a matching subunit 232.

 When the network element such as the AS, the CSCF, and the AAA server has an HSS address query request, the query request is sent to the SLF through the corresponding interface, and the user identifier (usually a specific user identifier) is carried in the query request. , used to indicate to the SLF which user needs to obtain the home HSS address information. After receiving the query request sent by each exemplary network element, the SLF transceiver unit 231 parses the to-be-checked user identifier included in the request, and provides the to-be-checked user identifier to the matching sub-unit 232.

After the matching sub-unit 232 learns a to-be-checked user identifier from the transceiver sub-unit 231, the data storage unit 22 searches for the user identifier existing in the relationship data that matches the to-be-checked user identifier. As can be seen from the foregoing, the data storage unit 22 includes two types of relationship data: by the first data storage subunit 221 The relationship data between the saved wildcard type user identifier and the home HSS address; the relationship data between the non-wildcard type user identifier and the home HSS address held by the second data storage subunit 222.

 Preferably, the matching sub-unit 232 preferentially searches the relationship data (the second data storage sub-unit 222) containing the non-wild type user identifier for the user identifier that matches the identity of the user to be checked. Since the non-wild type user identifier recorded in the relationship data is a specific user identifier, and the user identifier to be checked is also a specific user identifier, only the two are identical and are considered to be found in the second data storage subunit 222. Match the object. If the matching sub-unit 232 finds the non-wild-type user identifier matching the to-be-checked user identifier in the second data storage sub-unit 222, the destination HSS address in the relationship data in which the matching user identifier is located is notified to the transceiver. Unit 231.

 If the matching sub-unit 232 does not find the user identifier matching the to-be-checked user identifier in the second data storage sub-unit 222, proceed to the relationship data (the first data storage sub-unit 221) including the wildcard type user identifier. The user ID that matches the ID of the user to be checked. Since the wildcard type user ID in the relational data is not a specific user identifier, it includes a wildcard and represents a specific set of user identifiers. Therefore, if the part of the user ID and the non-wildcard of the user ID of the wildcard type are all the same, it is considered that the matching is successful, and thus the different user IDs to be checked may be matched to the same wildcard type user identifier. phenomenon.

 If the matching sub-unit 232 finds the wildcard type user identifier matching the to-be-checked user identifier in the first data storage sub-unit 221, the home HSS address in the relationship data in which the matched wildcard type user identifier is located is notified. Transceiver subunit 231. If the matching sub-unit 232 still does not find a wildcard type user identifier matching the to-be-checked user identifier in the first data storage sub-unit 221, it is notified that the transceiving sub-unit 231 fails to match.

 After receiving the query result replied by the matching subunit 232, the transceiver subunit 231 responds to the query request initiator according to the query content. Specifically, if the query result received by the transceiver sub-unit 321 is the home HSS address, that is, the query is successful, the home HSS address is carried in the response message replied to the query request initiator; if the transceiver sub-unit 32 receives If the result of the query is a match failure, the corresponding failure response message is returned to the query request initiator.

For the introduction of the above query processing unit 23 and its internal subunits, there are several points to be explained. First, because the communication interface between each network element that initiates the query request and the SLF is different, for example, the AS and the SLF communicate through the Dh interface, and the CSCF (such as the I-CSCF and the S-CSCF) and the SLF pass through. The Dx interface communicates, and the AAA server and the SLF communicate through the Dw interface. Therefore, the transceiver subunit 231 in the SLF generally supports the Diameter Base Protocol, which can be extended to support various interfaces. For example, the Dh, Dx, Dw interfaces mentioned above.

 Second, the foregoing matching sub-unit 232 preferentially queries the relationship data including the non-wild type user identifier. If the relationship data including the wild type user identifier is not successfully searched, it is only a preferred embodiment, and should not be construed as the present invention. The limitation of the present invention does not preclude the case of prioritizing the search for relational data containing the user identification of the wildcard type.

 Third, when matching is performed in the first data storage sub-unit 222, there may be a case where the user ID to be checked matches the plurality of wildcard type user identifiers. To this end, a preferred rule can be formulated, for example, selecting a wildcard type user identifier with the most matching information, assuming that the user identifier to be checked is "12CBN", and the wildcard type user identifier exists in the first data storage subunit 222" *CBN , and "12CB*" can match the user ID "12CBN" to be checked, but the match information of the user type "*CBN" of the wildcard type and the user ID "12CBN" to be checked contains 3 characters. The matching information of the type user identifier "12CB*" contains 4 characters, so "12CB*" is selected as the wildcard type user identifier matching the user ID "12CBN," to be checked. In addition, the first matching priority principle can be formulated. That is, which wildcard type user identifier matches the to-be-checked user identifier first, which wildcard type user identifier is used as the matching object, or directly stipulates that once a matching wildcard type user identifier is found, it will not continue. Find other user IDs of the wildcard type. The above several methods are only exemplary and should not be construed as limiting the present invention. Establish appropriate rules for the specific situation of the network.

 Please refer to FIG. 3 , which is a schematic structural diagram of a second embodiment of a server positioning function SLF network element according to the present invention. Since the basic principle of the present embodiment is the same as that of the first embodiment, in order to more clearly highlight the difference between the two, the same portions that are commonly referred to in the two embodiments will not be described herein. The difference between the embodiment and the first embodiment is that: the configuration interface 21 is only used to configure the relationship data between the user identifier of the wildcard type and the home HSS, and the data storage unit 22 only stores the wildcard type. The relationship data of the user identifier, which can match the identifier of the user to be checked, is limited to the user ID of the wildcard type. The SLF of this structure is also applicable in a specific carrier network. In other words, the embodiment can be regarded as a limit case of the first embodiment, that is, the relationship data including the non-wild type user identifier is 0.

Referring to FIG. 4, it is a third implementation of a server positioning function SLF network element disclosed in an embodiment of the present invention. • Schematic diagram of the structure of the example.

 The SLF network element includes a receiving unit 44, a transmitting unit 45, a configuration interface 41, a data storage unit 42 connected to the configuration interface 41, and an inquiry processing unit 43 connected to the data storage unit 42. Specifically, the configuration interface 41 includes a first configuration sub-interface 411 and a second configuration sub-interface 412; the data storage unit 42 includes a first data storage sub-unit 421 and a second data storage sub-unit 422; the query processing unit 43 and the receiving unit 44 is connected to the transmitting unit 45. The following describes the internal structure of the SLF network element in combination with the working principle of the SLF network element.

 The configuration of the configuration interface 41 may be the same as the configuration interface 21 in the embodiment shown in FIG. 2 or the embodiment shown in FIG. 3. The structure of the data storage unit 42 may be the same as the embodiment shown in FIG. 1 or the embodiment shown in FIG. The data storage unit 22 is the same and will not be described in detail herein.

 The receiving unit 44 is configured to receive a message from other network elements in the network, where the message includes a query request. The query processing unit 43 is configured to use the to-be-checked user identifier included in the query request received by the receiving unit 44 in the data storage unit 42. Searching for the home HSS address corresponding to the to-be-checked user identifier, and notifying the sending unit 45 of the query result; the sending unit 45 is configured to send a message to other network elements in the network, where the message includes a response to the query result.

 When the network element such as the AS, the CSCF, and the AAA server has an HSS address query request, the query request is sent to the SLF through the corresponding interface, and the user identifier (usually a specific user identifier) is carried in the query request. , used to indicate to the SLF which user needs to obtain the home HSS address information. After receiving the query request sent by each of the exemplary network elements, the receiving unit 44 of the SLF parses the to-be-checked user identifier included in the request, and provides the to-be-checked user identifier to the query processing unit 43.

 After the query processing unit 43 learns a to-be-checked user identifier from the receiving unit 44, it searches the data storage unit 42 for the user identifier existing in the relationship data that matches the to-be-checked user identifier. As can be seen from the foregoing, the data storage unit 42 includes two types of relationship data: relationship data between the wildcard type user identifier and the home HSS address; relationship data between the non-wildcard type user identifier and the home HSS address.

Preferably, the query processing unit 43 preferentially searches for the user identifier that matches the to-be-checked user identifier in the relationship data including the non-wild type user identifier. The non-wild type user identifier recorded in the relationship data is a specific user identifier, and the user identifier to be checked is also a specific user identifier. Therefore, Only if the two are identical, the match is considered to be found. If the query processing unit 43 finds the non-wildcard type user identifier that matches the user identifier to be checked, the home HSS address in the relationship data in which the matched user identifier is located is notified to the sending unit 45.

 If the query processing unit 43 does not find the user identifier that matches the identity of the user to be checked, it proceeds to the relationship data containing the user identifier of the wildcard type to find the user identifier that matches the identifier of the user to be checked. Since the wildcard type user ID in the relational data is not a specific user identifier, it includes a wildcard and represents a specific set of user identifiers. Therefore, if the part of the user ID and the non-wildcard of the user ID of the wildcard type are all the same, the two are considered to be successfully matched, and thus the different user IDs to be checked may be matched to the same wildcard type user identifier. phenomenon.

 If the matching sub-unit 232 finds the wildcard type user identifier that matches the 'home identification' to be checked, the transmitting unit 45 is notified of the home HSS address in the relationship data in which the matching wildcard type user identifier is located. If the query processing unit 43 does not find a wildcard type user identifier that matches the identity of the user to be checked, the sending unit 45 is notified that the query has failed.

 The sending unit 45 replies to the query request originator. Specifically, if the query result received by the sending unit 45 is the home HSS address, that is, the query is successful, the home HSS address is carried in the response message that is sent to the query requesting initiator; if the sending unit 45 receives the query result If the query fails, the corresponding failure response message is returned to the query request initiator. It can be seen that the specific server positioning function network element can be implemented by using the SLF provided by the embodiment of the present invention.

 The present invention also discloses a method for applying the foregoing structure SLF network element. Referring to FIG. 5, it is a flowchart of an embodiment of a method for obtaining a home HSS address by using an SLF network element.

510: The SLF network element receives the query request message, where the message includes the user identifier to be checked. There may be two or more HSS network elements in the IMS network. The subscription information of one user is only stored in one of the HSS network element entities. Therefore, other network elements in the IMS network (such as AS network element, I) Before the data exchange with the HSS network element, the CSCF network element, the S-CSCF network element, the AAA server network element, etc. must know which HSS network element entity of the home IMS network is stored, that is, to the server. The location function SLF (Server Locator Function) network element is queried. When the network element such as the AS, the CSCF, and the AAA server has an HSS address query request, the query request is sent to the SLF through the corresponding interface, and the user identifier (usually a specific user identifier) is carried in the query request. , used to indicate to the SLF which user needs to obtain the home HSS address information. 520: The SLF searches for the relationship data between the matching local non-wildcard type user identifier and the home HSS address by using the to-be-checked user identifier as a key. The relationship data between the local non-wildcard type user identifier and the home HSS address refers to the relationship data stored in the SLF. The relationship data between the non-wild type user identifier and the home HSS address has been described in detail in the foregoing. In order to make the description of the present invention more concise, no further details are provided herein. The specific process of matching is to find the same user identifier in the relation data with the non-wild type user identifier locally, and the non-wildcard type user identifier is the same as the user identifier to be checked. The relationship data is the relationship data that matches the identity of the user to be checked.

 530: If the matching relationship data is found, proceed to step 560; if the matching relationship data is not found, proceed to step 540.

 540: Search for the relationship data between the matching local wildcard type user identifier and the home HSS address by using the to-be-checked user identifier as a key, and then proceed to step 550. The relationship data between the local wildcard type user ID and the home HSS address refers to the relationship data stored in the SLF. In the foregoing, the relationship data between the user ID and the home HSS address has been described in detail. For the sake of brevity of the embodiment of the present invention, details are not described herein again.

 The specific process of matching in this step is slightly different from the matching process described in 520: since the wildcard type user identifier in the relationship data is not a specific user identifier, but includes a wildcard, representing a specific set of user identifiers. , and the user ID to be checked is a specific user identifier. Therefore, if the part of the user ID and the non-wildcard of the user ID of the wildcard type are all the same, the relationship between the two is considered to be the match, and the relationship data of the user type of the wildcard type is matched with the identifier of the user to be checked. Relationship data.

 550: If the matching relationship data is found, proceed to step 560; if the matching relationship data is not found, proceed to step 570.

560: The SLF informs the query request initiator of the home HSS address in the matched relationship data. Whether it is a matching relationship data including a non-wild type user identifier, or a matching relationship data including a wildcard type user identifier, the recorded home HSS address is corresponding to the to-be-checked user identifier. Therefore, the SLF informs the query request originator of the home HSS address recorded in the matched relationship data, so that the query request initiator can access the HSS storing the user subscription data according to the home HSS address provided by the SLF. 570: Inform the query request that the initiator failed to query. Usually, even if the SLF does not find the home HSS address corresponding to the user identifier to be checked, it is necessary to inform the query requesting initiator that the query fails.

 The following describes the technical solution of the present invention in more detail by taking the registration process of the user in the IMS network as an example. Referring to FIG. 6, FIG. 6 is a schematic diagram of data interaction in which the I-CSCF network element queries the user's home HSS address through the SLF network element in the user registration process.

 610: The I-CSCF network element receives a user registration request message (ie, REGISTER) sent by the P-CSCF (Proxy CSCF) network element. The P-CSCF is the first entry point for the terminal to access the IMS network, also known as the proxy CSCF, which is used to implement the Proxy and User Agent functions in the SIP protocol. The P-CSCF accepts all SIP client registrations and calls, and finds the corresponding home domain based on the calling/called user ID to complete the registration process and call connection.

 620: According to the registration process, the I-CSCF network element needs to query the capability set information of the user in the HSS network element to which the user belongs. However, since there are multiple HSS network elements in the current IMS network, and the I-CSCF network element does not know which HSS network element is the home HSS of the user, the I-CSCF network element needs to initiate an active query message to the SLF network element. (ie DX-SLF-QUERY message), go to the SLF network element to query the home HSS address of the user. In the DX-SLF_QUERY request message, the user identification information of the user is included.

 630: The SLF network element queries the home HSS address of the user according to the relationship data between the locally saved user identifier and the home HSS address:

 If the user identifier in the request message is completely matched with a non-wildcard type user identifier saved locally by the SLF network element, the home HSS address information corresponding to the non-wildcard type user identifier is queried;

 If the user identifier in the request message cannot be completely matched with all the non-wildcard type user identifiers saved locally by the SLF network element, check whether there is a wildcard type user identifier and the user identifier in the request message in the SLF network element. Wild. If yes, the home HSS address information corresponding to the user ID of the wildcard type is queried; otherwise, the user identifier in the request message does not exist in the SLF network element, indicating that the home HSS address of the query user is unsuccessful.

640: The SLF network element returns a response message (ie, DX_SLF_RESP message) to the I-CSCF, that is, responds to the I-CSCF query request. If the SLF query is successful, the corresponding home HSS address needs to be included in the response message. If the SLF query is unsuccessful, the query message needs to be included in the response message. Letter,

 650: The I-CSCF network element queries the HSS network element for the capability set information of the user according to the home HSS address that the SLF network element responds, and continues the registration process. If the I-CSCF network element learns that the query fails from the corresponding message returned by the SLF, the I-CSCF network element will abort the registration process.

 It can be seen that, by using the method provided by the embodiment of the present invention, in a network element with two or more IMS networks, the network element that needs to perform data interaction with the HSS network element can obtain the address information of the home HSS through the imported SLF network element. The program can be executed by instructing related hardware, and the program can be stored in a computer readable storage medium such as a ROM/RAM, a magnetic disk, an optical disk, or the like.

 The above description of the foregoing embodiments of the server positioning function SLF network element and its application method provided by the present invention is only for helping to understand the present invention; meanwhile, for those skilled in the art, according to the idea of the present invention, The scope of the present invention and the scope of the application are subject to change. In the above, the contents of the present specification are not to be construed as limiting the invention.

Claims

Rights request  A server positioning function network element, comprising:  The configuration interface is configured to configure relationship data between the user identifier and the HSS address of the home subscription server.  a data storage unit, configured to store relationship data obtained through the configuration interface;  The query processing unit is configured to receive the query request and search for the home HSS address corresponding to the to-be-checked user identifier in the data storage unit according to the to-be-checked user identifier included in the query request.  2. The server positioning function network element according to claim 1, wherein the configuration interface comprises:  a first configuration sub-interface, configured to configure relationship data between the user identifier of the wildcard type and the HSS address of the home subscription server; and/or  The second configuration sub-interface is configured to configure relationship data between the non-wildcard type user identifier and the home HSS address.  The server positioning function network element according to claim 2, wherein the query processing unit preferentially searches for the relationship data of the non-wild type user identifier in the data storage unit, and if not, finds the The relationship of the type user identifier: according to.  The server positioning function network element according to claim 1, wherein the query processing unit comprises a transceiver subunit and a matching subunit, wherein:  The transceiver unit is configured to receive a query request, and provide the matching sub-unit with the to-be-checked user identifier included in the query request, and request the initiator to respond according to the query result provided by the matching sub-unit;  The matching subunit is configured to search, in the data storage unit, a user identifier that matches the to-be-checked user identifier, and notify the transceiver subunit of the query result.  The server positioning function network element according to any one of claims 1 to 4, wherein the configuration interface comprises: an operation support system OSS interface and/or a network management interface.  6. A server positioning function network element, including: a receiving unit, configured to receive a message from another network element in the network, where the message includes a query request, and a sending unit, configured to send a message to other network elements in the network, where the message includes a response to the query result; It is characterized in that it further comprises:  The configuration interface is configured to configure relationship data between the user identifier and the HSS address of the home subscription server.  a data storage unit, configured to store relationship data obtained through the configuration interface;  a query processing unit, configured to search for a home HSS address corresponding to the to-be-checked user identifier in the data storage unit according to the to-be-checked user identifier included in the query request received by the receiving unit, and notify the query result The sending unit.  The server positioning function network element according to claim 6, wherein the configuration interface comprises:  a first configuration sub-interface, configured to configure relationship data between the user identifier of the wildcard type and the HSS address of the home subscription server; and/or  The second configuration sub-interface is configured to configure relationship data between the non-wildcard type user identifier and the home HSS address.  The server positioning function network element according to claim 6 or 7, wherein the configuration interface comprises: an operation support system OSS interface and/or a network management interface.  A method for obtaining home HSS address information by using a server positioning function network element, wherein the method includes the following steps:  The server positioning function network element receives the query request message, where the message includes the user identifier to be checked; and uses the to-be-checked user identifier as a key to search for the relationship data between the matching local user identifier and the home HSS address;  The query request originator is informed of the home HSS address in the matched relationship data.  10. The method for obtaining a home HSS address by a server positioning function network element according to claim 9, wherein:  The relationship data between the local user identifier and the home HSS address includes: relationship data between the user identifier of the wildcard type and the home HSS address, or relationship data between the non-wildcard type user identifier and the home HSS address.  11. The method for obtaining a home HSS address by a server positioning function network element according to claim 9, wherein: The relationship data between the local user identifier and the home HSS address includes: Relationship data between the subscriber identity and the home HSS address, and relationship data between the non-wildcard type subscriber identity and the home HSS address;  The step of searching for the relationship data between the matching local user identifier and the home HSS address includes: preferentially searching for the relationship data including the non-wild type user identifier, and if not, searching for the relationship data including the wildcard type user identifier.  The method for obtaining a home HSS address by using a server positioning function network element according to any one of claims 9 to 11, wherein the method further comprises: presetting a priority of different types of relationship data;  When the relationship data between the matching local user identifier and the home HSS address is searched by using the to-be-checked user identifier as a key, the query order of the relationship data is determined according to the priority of the relationship data.