CN1968267A - Server positioning function network element and application method thereof - Google Patents

Abstract

The invention discloses a server positioning function network element, which includes a configuration interface for configuring the relationship data between the wildcard type user identifier and the home subscription server HSS address; a data storage unit for storing the data obtained through the configuration interface Relational data; a query processing unit, configured to search the data storage unit for the home HSS address corresponding to the user ID according to the user ID to be checked included in the query request. The present invention provides a specific realization of the server positioning function network element. Those skilled in the art can realize the specific server positioning function network element by referring to the above technical solution.

Description

Network element with server positioning function and application method thereof

technical field

The invention relates to the field of communication technology, in particular to a network element with a server positioning function and an application method thereof.

Background technique

Internet Multimedia Subsystem IMS (IP Multimedia Subsystem) is a subsystem added to the WCDMA network in the third generation mobile communication standardization partnership project 3GPP (3rd Generation Partnership Project) R5 phase, and is used to provide IP-based multimedia services. In the IMS network, the home subscription server HSS (Home Subscriber Server) network element saves the user's user identity, such as IMS private user identity IMPI (IMS Private User Identity), IMS public user identity IMPU (IMS Public User Identity), international mobile Subscriber identification code IMSI (International Mobile Subscriber Identity) and mobile station international ISDN number MSISDN (Mobile Station International ISDN Number), etc. In addition, user information such as subscription and authentication is also stored in the HSS.

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

In the actual networking, the user capacity supported by one HSS network element is limited. Therefore, there may be two or more HSS network elements in the IMS network, and the subscription information of a user is only saved in one of the HSS network elements. in the entity. Other network elements in the IMS network (such as AS network elements, I-CSCF network elements, S-CSCF network elements, AAA Server network elements, etc.) must know that the corresponding user information is stored in the attribution In which HSS network element entity in the IMS network. For this reason, a Server Locator Function (SLF) network element is introduced into the IMS network.

In the current 3GPP specification on the IMS network, it is pointed out that the IMS network can use a server location function (SLF) network element. However, the server location function SLF is not specifically defined in the standard, nor is there any known implementation.

Contents of the invention

The purpose of the present invention is to provide a specific implementation scheme of the server location function SLF, so as to solve the technical problem that no SLF implementation scheme is provided in the existing standards.

In order to solve the above-mentioned technical problems, the object of the present invention is achieved through the following technical solutions: a network element with server positioning function, including a configuration interface for configuring the relationship data between the wildcard type user identifier and the home subscription server HSS address; A data storage unit, configured to store the relationship data obtained through the configuration interface; a query processing unit, configured to search the data storage unit for the home HSS corresponding to the user ID according to the user ID to be checked contained in the query request address.

Preferably, the configuration interface is also used to configure the relationship data between the non-wildcard user ID and the home HSS address.

Preferably, the query processing unit first searches the data storage unit for relational data containing non-wildcard type user IDs, and if unsuccessful, then searches for relational data containing wildcard type user IDs.

Preferably, the query processing unit specifically includes a transceiver subunit and a matching subunit, wherein:

The sending and receiving subunit is used to receive the query request and provide the matching subunit with the user identification to be checked contained in the query request, and respond to the query request initiator according to the query result provided by the matching subunit;

The matching subunit is used to search the data storage unit for a user ID that matches the user ID to be checked, and inform the sending and receiving subunit of the query result.

Preferably, if the matching subunit finds a matching user ID, then inform the sending and receiving subunit of the home HSS address in the relationship data where the matching user ID is located; if the matching subunit does not find a matching user ID flag, it informs the transceiver subunit that the matching fails.

Preferably, the wildcard-type user ID represents a group of specific user IDs.

Preferably, the configuration interface is an OSS interface and/or a network management interface.

A method for obtaining home HSS address information through a server location function network element, said method comprising the following steps: a server location function network element receives a query request message, the message includes a user identification to be checked; is a keyword, searching for the relational data between the matching local wildcard type user ID and the home HSS address; and notifying the originator of the query request of the home HSS address in the matching relational data.

Preferably, before using the user ID to be searched as a keyword to search for the relational data between the matching local wildcard type user ID and the home HSS address, it further includes: using the user ID to be checked as a keyword, Find the matching relationship data between the local non-wildcard user ID and the home HSS address.

Preferably, it also includes presetting the priorities of different types of relational data.

Preferably, the priority of the relationship data between the non-wildcard type user ID and the home HSS address is higher than the priority of the relationship data between the wildcard type user ID and the home HSS address.

As can be seen from the above technical solutions, in the server location function SLF network element structure disclosed by the present invention, the operator is provided with the relationship data between the configuration wildcard type user identifier and the home subscription server HSS address through the configuration interface; and then through the data The storage unit stores the relationship data obtained by the configuration interface; when other network elements in the IMS network query the SLF network element, the SLF uses the query processing unit to store the data in the data storage unit according to the user identification contained in the query request. Search for the home HSS address corresponding to the user ID in , which can provide the required information for the initiator of the query request. It can be seen from this that the SLF network element disclosed in the present invention provides a specific and feasible implementation manner, which makes up for the defect that no specific implementation is given in the existing standards.

Description of drawings

Fig. 1 is the exemplary network diagram that can implement the scheme of the present invention;

FIG. 2 is a schematic structural diagram of the first embodiment of the SLF network element disclosed in the present invention;

FIG. 3 is a schematic structural diagram of a second embodiment of an SLF network element with a server location function disclosed by the present invention;

Fig. 4 is the flow chart of the embodiment of the method for obtaining the home HSS address through the SLF network element of the present invention;

FIG. 5 is a schematic diagram of data interaction in which the I-CSCF queries the user's home HSS address through the SLF network element.

Detailed ways

In order to illustrate the technical solution of the present invention more clearly, first a brief introduction is given to an exemplary network diagram that can implement the solution of the present invention, as shown in FIG. 1 .

An Internet (IP) Multimedia Subsystem (IMS) network includes various network elements that communicate with each other. For example, the exemplary network includes an Application Server (AS) 13, an Inquiring Call Session Control Function (I-CSCF) 14, a Serving Call Session Control Function (S-CSCF) 15 and an Authentication, Authorization and Accounting Server (AAA Server) 16. Each of the above-mentioned network elements communicates with a plurality of home subscription server network elements (HSS) 12 (also denoted as HSS1, HSS2, ... HSSn), and queries or updates relevant subscription information of a specified user in the HSS network elements. However, since a user's subscription information is only stored in one of the HSS network element entities, before the above-mentioned network elements exchange data with the HSS network element, it is necessary to first know which HSS network in the home IMS network the corresponding user information is stored in. In the meta-entity, the home HSS address of the specified user is obtained through the user location function SLF network element 11 .

After understanding an exemplary network implementing the present invention, the specific implementation of the SLF network element of the present invention will be further introduced. It should be appreciated that the exemplary network diagram shown in FIG. 1 is only for the purpose of illustrating the embodiment of the present invention more clearly, and thus should not be construed as limiting the present invention.

Please refer to FIG. 2 , which is a schematic structural diagram of the first embodiment of the SLF network element disclosed in the present invention. The SLF network element includes a configuration interface 21 , a data storage unit 22 connected to the configuration interface 21 , and a query 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; unit 231 and matching subunit 232. Combining with the working principle of the SLF network element, its internal structure will be further introduced below.

First, the configuration interface 21 is introduced in detail, and the configuration interface may be an operation support system OSS interface, a network management interface or a combination of several types of interfaces.

The network operator configures the relationship data between the user ID 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 ID and the home HSS address through the first configuration sub-interface 211; relational data. Of course, in practical applications, the same configuration interface may also be used to configure the above two types of relational data.

The so-called wildcard type user ID refers to a user ID containing wildcard characters, and a wild card type user ID can represent a group of specific user IDs. For example, the user ID of a certain wildcard type is "sip: chatlist*@domain.com ", where "*" is used as a wildcard, and the wildcard can represent any form of information. Therefore, if a specific user ID matches the above wildcard type The difference between the user IDs is only the wildcard part, so the above-mentioned wildcard type of user IDs can represent the specific user IDs, such as: "sip: chatlist_bobo@domain.com", sip: chatlist_jacky@domain .com" and "sip: chatlist3@domain.com", etc. It should be noted that the specific expression of wildcards is not limited to "*", you can choose wildcards that you think are convenient according to your needs, and in a wildcard type user ID The wildcard is not limited to one. In addition, the position of the wildcard in a wildcard type user ID is also set according to the actual situation, and in essence it is to extract the common part of multiple specific user IDs.

Of course, wildcards can also be expressed in an implicit way. For example, an operator can configure a wildcard type user ID as "domain.com". There is no actual wildcard in this wildcard type user ID, but it can represent all Concrete user IDs containing the string "domain.com", ie including implied wildcards.

A user ID of a non-wildcard type refers to a specific user ID, for example, the aforementioned "sip: chatlist_jacky@domain.com" is a user ID of a non-wildcard type.

The network operator configures the relationship data between all wildcard type user identifiers and home HSS addresses through the first configuration sub-interface 211 . The relationship data includes two parts, one is the user identification of each wildcard type, and the other is the HSS address information, and there is a one-to-one correspondence between the two parts. For example, assuming that the configured relationship data contains 100 wildcard type user IDs, each wildcard type user ID should be configured with a corresponding HSS address. Of course, the 100 wildcard type user IDs corresponding to the above 100 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 group of user IDs, so the subscription information of the group of specific users it represents should exist in the same HSS, so as to ensure that a wildcard type user The identifier corresponds to an HSS address.

The network operator configures the relationship data between the non-wildcard user ID and the home HSS address through the second configuration sub-interface 212 . The relational data also includes two parts, one is user IDs of various non-wildcard types (also called specific user IDs), and the other is HSS address information, and there is also a one-to-one correspondence relationship between the contents of these two parts. For example, assuming that the specific identifier of a user is ABC, and its subscription data is stored in HSS3, then there will be a relationship data in the SLF: specific user identifier ABC—the address of HSS3. Of course, there is no limitation on the specific expression form of the relational data, as long as the corresponding relationship between the user identifier and the HSS address can be expressed.

It can be known from the above two paragraphs that there are two types of relational data in the SLF, one is relational data containing wildcard type user identifiers, and the other is relational data containing non-wildcard type user identifiers. As for the specific distribution ratio of these two types of relational data, it may be determined according to actual needs. For example, in the initial configuration process of the SLF network element, it is enough to configure only a few relational data including wildcard type user IDs, and other configurations include relational data including non-wildcard type user IDs.

It should be recognized that although the relationship data in the SLF should be consistent (or synchronized) with the user subscription information stored in the HSS, this should not be construed as a limitation of the present invention, because both the SLF and the HSS are usually provided by the same network The operator configures the data, so keeping the synchronization between the two can be completely solved by the operator. For example, in the initial configuration stage of network elements, SLF can be configured with relational data first, and then correspondingly configure user subscription data in each HSS network element; or first configure user subscription information for each HSS network element, and then according to The storage situation in each HSS configures the SLF correspondingly. If the operator expands or merges the existing HSS network elements according to the actual situation, which leads to the migration of subscription data of some users, the relationship data in the SLF can be correspondingly changed through the configuration interface 21 . Furthermore, when the relationship data between a wildcard user ID and the home HSS address is modified, a batch of specific user ID and home HSS relationship data is actually implicitly modified, thereby reducing the need for modifying the SLF data. workload.

Next, the data storage unit 22 is described in detail, which is used to store the relationship data obtained through the configuration interface unit 21 . 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 subunit 221 is used for storing relation data obtained through the first configuration sub-interface, that is, for storing relation data including wildcard types. The second data storage subunit 222 is used for storing the relationship data obtained through the second configuration sub-interface, that is, for storing relationship data including non-global types. The data accessed in the data storage unit 22 provides services for 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 ID according to the user ID to be checked contained in the query request. Specifically, the query processing unit 23 includes a transceiving subunit 231 and a matching subunit 232 .

When AS, CSCF, AAA server and other network elements have an HSS address query request, they will send a query request to the SLF through the corresponding interface, and carry the user ID to be checked (usually a specific user ID) in the query request. , which is used to indicate to the SLF which user's home HSS address information it needs to obtain. After receiving the query request sent by the above-mentioned exemplary network elements, the transceiver subunit 231 of the SLF parses out the user ID to be checked contained in the request, and provides the user ID to be checked to the matching subunit 232 .

After the matching subunit 232 acquires a user ID to be checked from the sending and receiving subunit 231 , it searches the data storage unit 22 for a user ID in the relational data that matches the user ID to be checked. As can be seen from the foregoing, the data storage unit 22 includes two types of relational data: the relational data between the wildcard type user identification and the home HSS address saved by the first data storage subunit 221; The stored relationship data between the non-wildcard type user ID and the home HSS address.

Preferably, the matching subunit 232 preferentially searches for a user ID that matches the user ID to be checked in the relational data (second data storage subunit 222 ) containing non-wildcard type user IDs. Since the non-wildcard type user ID recorded in the relational data is a specific user ID, and the user ID to be checked is also a specific user ID, therefore, only if the two are completely the same, it is considered that the user ID is found in the second data storage subunit 222. match object. If the matching subunit 232 finds in the second data storage subunit 222 a non-wildcard type user ID that matches the user ID to be checked, then inform the transceiver sub-unit of the home HSS address in the relationship data where the matched user ID is located Unit 231.

If the matching subunit 232 does not find the user identification matched with the user identification to be checked in the second data storage subunit 222, then continue to search in the relational data (first data storage subunit 221) that contains the wildcard type user identification The user ID that matches the user ID to look for. Because the wildcard type user identifier in the relational data is not a specific user identifier, but includes wildcards and represents a group of specific user identifiers. Therefore, if the non-wildcard part of the user ID to be checked and a certain wildcard type user ID are all the same, it is considered that the two match successfully, and there may be cases where different user IDs to be checked match the same wildcard type user ID Phenomenon.

If the matching subunit 232 finds in the first data storage subunit 221 a wildcard-type user identifier that matches the user identifier to be checked, the home HSS address in the relationship data where the matched wildcard-type user identifier is located is notified Transceiver subunit 231. If the matching subunit 232 still does not find a wildcard type user ID that matches the user ID to be checked in the first data storage subunit 221 , it informs the transceiving subunit 231 of the matching failure.

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

Regarding the introduction of the above query processing unit 23 and its internal subunits, there are several points to be explained.

First, due to the different communication interfaces between each network element that initiates the query request and the SLF, for example, the AS communicates with the SLF through the Dh interface, and the CSCF (such as I-CSCF and S-CSCF) communicates with the SLF through the Dx The AAA server and the SLF communicate through the Dw interface. Therefore, the transceiver subunit 231 in the SLF usually supports the Diameter Base Protocol. The Diameter Base Protocol can be extended to support various interfaces. For example, the Dh, Dx, and Dw interfaces mentioned above.

Second, the aforementioned matching subunit 232 preferentially inquires about relational data containing non-wildcard type user IDs, and if unsuccessful, then queries about relational data containing wildcard type user IDs. The present invention does not exclude the situation of preferentially searching for relational data containing wildcard type user identifiers.

Third, when matching is performed in the first data storage subunit 222, there may be a situation where a user ID to be checked matches multiple user IDs of the wildcard type. For this reason, a preferred rule can be formulated, for example, select the wildcard type user identification with the most matching information, assuming that the user identification to be checked is "12CBN", the wildcard type user identification "*CBN" existing in the first data storage subunit 222 " and "12CB*" can be matched with the user ID "12CBN" to be checked, but because the matching information of the user ID "*CBN" of the wildcard type and the user ID "12CBN" to be checked contains 3 characters, and the wildcard type The matching information of the user ID "12CB*" contains 4 characters, so "12CB*" is selected as the wildcard type user ID matching the user ID "12CBN" to be checked. In addition, it is also possible to formulate the principle of matching first, that is, whichever wildcard type user ID and the user ID to be checked are first successfully matched, and the wildcard type user ID is used as the matching object. Or it is directly stipulated that as long as a matching wildcard type user identifier is found, no further search for other wildcard type user identifiers will be performed. The above-mentioned methods are only exemplary, and should not be construed as a limitation of the present invention. The operator can formulate appropriate rules according to the specific conditions of the network.

Please refer to FIG. 3 , which is a schematic structural diagram of a second embodiment of an SLF network element with a server location function disclosed in the present invention. Since the basic principle of this embodiment is the same as that of the first embodiment, in order to highlight the differences between the two more clearly, the same parts commonly involved in the two embodiments will not be repeated here. The difference between this embodiment and the first embodiment is that the configuration interface 21 is only used to configure the relationship data between the wildcard type user ID and the home HSS, and the data storage unit 22 only saves the data containing the wildcard type For the relational data of user IDs, the objects that can be matched with the user IDs to be checked are limited to wildcard type user IDs. The SLF of this structure is also applicable in a specific operator's network. In other words, this embodiment can be regarded as a limit case of the first embodiment, that is, the relational data containing the non-wildcard type user identifier is 0.

The present invention also discloses an application method of the SLF network element with the aforementioned structure. Please refer to FIG. 4 , which is a flow chart of an embodiment of a method for obtaining the home HSS address through the SLF network element disclosed in the present invention.

410: The SLF network element receives a query request message, where the message includes the user ID to be checked. There may be two or more HSS network elements in the IMS network, and the subscription information of a user is only stored in one of the HSS network element entities. Therefore, other network elements in the IMS network (such as AS network elements, I -CSCF network elements, S-CSCF network elements, AAA Server network elements, etc.) Before data interaction with HSS network elements, it is necessary to know which HSS network element entity of the IMS network the corresponding user information is stored in, that is, to the server Locating function SLF (Server Locator Function) network elements to query. When AS, CSCF, AAA server and other network elements have an HSS address query request, they will send a query request to the SLF through the corresponding interface, and carry the user ID to be checked (usually a specific user ID) in the query request. , which is used to indicate to the SLF which user's home HSS address information it needs to obtain.

420: The SLF uses the user ID to be checked as a key to search for the matching relationship data between the local non-wildcard type user ID and the home HSS address. The so-called relational data between the local non-wildcard user ID and the home HSS address refers to the relational data stored in the SLF. The relational data between the non-wildcard type user ID and the home HSS address has been introduced in detail above, in order to make the description of the present invention more concise, no more details are given here. The specific process of so-called matching is to use the user ID to be checked as a keyword to search for the same user ID in the local relational data containing non-wildcard type user IDs, where the same non-wildcard type user ID is located The relational data of , that is, the relational data matching the user ID to be checked.

430: If matching relationship data is found, go to step 460; if no matching relationship data is found, go to step 440.

440: Using the user ID to be searched as a key, search for the matching relationship data between the local wildcard type user ID and the home HSS address, and then go to step 450. The so-called relational data between the local wildcard user ID and the home HSS address refers to the relational data stored in the SLF. The relational data between the wildcard type user ID and the home HSS address has been introduced in detail above, in order to make the description of the present invention more concise, no more details are given here.

The specific matching process in this step is a little different from the matching process described in 420: since the wildcard type user ID in the relational data is not a specific user ID, but includes wildcards, representing a group of specific user IDs , and the user ID to be checked is a specific user ID. Therefore, if the non-wildcard parts of the user ID to be checked and a wildcard type user ID are all the same, it is considered that the two match successfully, and then the relational data where the wildcard type user ID is located is a match with the user ID to be checked relational data.

450: If matching relationship data is found, go to step 460; if no matching relationship data is found, go to step 470.

460: The SLF notifies the originator of the query request of the attributable HSS address in the matching relational data. Regardless of whether it is matching relational data containing non-wildcard type user IDs or matching relational data containing wildcard type user IDs, the attributable HSS address recorded therein corresponds to the user ID to be checked. Therefore, the SLF notifies the query request initiator of the attributable HSS address recorded in the matching relationship data, so that the query request initiator can access the HSS that stores the user subscription data according to the attributable HSS address provided by the SLF.

470: Inform the initiator of the query request that the query failed. Usually, even if the SLF does not find the home HSS address corresponding to the user ID to be checked, it needs to inform the query request initiator that the query fails.

Next, taking the user registration process in the IMS network as an example, the technical solution of the present invention will be disclosed in more detail. Please refer to FIG. 5 , which 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 during the user registration process.

510: The I-CSCF network element receives the user REGISTER registration request message sent by the P-CSCF (Proxy CSCF) network element. P-CSCF is the first entry point for terminals to access the IMS network, also known as proxy CSCF, which is used to implement the functions of Proxy and User Agent (proxy) in the SIP protocol. P-CSCF accepts the registration and calling of all SIP clients, finds the corresponding home domain according to the calling/called user ID, and completes the registration process and call connection.

520: According to the registration process, the I-CSCF network element needs to query the capability set information of the user from 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 user's home HSS, the I-CSCF network element needs to initiate an active query message to the SLF network element (that is, the DX_SLF_QUERY message), to query the home HSS address of the user in the SLF network element. In the DX_SLF_QUERY request message, the user identification information of the user is included.

530: The SLF network element queries the user's home HSS address according to the locally stored relational data between the user ID and the home HSS address:

(530-1) If the user identifier in the request message exactly matches a certain non-wildcard type user identifier locally stored by the SLF network element, query the home HSS address information corresponding to the non-wildcard type user identifier;

(530-2) If the user ID in the request message cannot completely match all the non-wildcard type user IDs stored locally in the SLF network element, check whether there is a wildcard type user ID in the SLF network element and the request message User IDs in can be wildcarded. If it exists, query the home HSS address information corresponding to the wildcard user ID; otherwise, consider that the user ID in the request message does not exist in the SLF network element, indicating that querying the user's home HSS address is unsuccessful.

540: The SLF network element returns a response message (that is, a DX_SLF_RESP message) to the I-CSCF, that is, responds to the query request of the I-CSCF. If the SLF query is successful, the corresponding home HSS address needs to be included in the response message, and if the SLF query is unsuccessful, query failure information needs to be included in the response message.

550: The I-CSCF network element queries the HSS network element for the user's capability set information according to the home HSS address responded by the SLF network element, 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 stop the registration process.

A kind of server positioning function SLF network element provided by the present invention and its application method have been introduced in detail above. In this paper, specific examples have been used to illustrate the principle and implementation of the present invention. The description of the above embodiments is only used to help Understand the method of the present invention and its core idea; at the same time, for those of ordinary skill in the art, according to the idea of the present invention, there will be changes in the specific implementation and scope of application. In summary, the content of this specification is not It should be understood as a limitation of the present invention.

Claims (11)

1, a kind of server positioning function network element is characterized in that, comprising:

Configuration interface is used to dispose the relation data between wildcard type user and the home subscribed services device HSS address;

Data storage cell is used to store the relation data that obtains by described configuration interface;

The query processing unit is used for the user ID to be looked into that comprises according to query requests, and searches the ownership HSS address corresponding with this user ID in described data storage cell.

2, server positioning function network element as claimed in claim 1 is characterized in that, described configuration interface also is used to dispose non-wildcard type user and the relation data that belongs to the HSS address.

3, server positioning function network element as claimed in claim 2, it is characterized in that, the relation data that comprises non-wildcard type user in the data storage cell is preferentially searched in described query processing unit, if the unsuccessful relation data that comprises the wildcard type user of searching again.

4, server positioning function network element as claimed in claim 1 is characterized in that, described query processing unit specifically comprises transmitting-receiving subelement and coupling subelement, wherein:

The transmitting-receiving subelement, the user ID to be looked into that is used for receiving query requests and provides described query requests to comprise to the coupling subelement, and reply to the query requests initiator according to the Query Result that the coupling subelement provides;

The coupling subelement is used for searching the user ID that is complementary with user ID above-mentioned to be looked at data storage cell, and Query Result is informed the transmitting-receiving subelement.

5, server positioning function network element as claimed in claim 4 is characterized in that,

If described coupling subelement finds the user ID that is complementary, the transmitting-receiving subelement is informed in the ownership HSS address in the relation data at the user ID place that then this is complementary;

If described coupling subelement does not find the user ID that is complementary, it fails to match then to inform the transmitting-receiving subelement.

6, as any described server positioning function network element in the claim 1 to 5, it is characterized in that described wildcard type user is represented one group of concrete user ID.

7, as any described server positioning function network element in the claim 1 to 5, it is characterized in that described configuration interface is OSS OSS interface and/or network management interface.

8, a kind ofly obtain the method for ownership HSS address information, it is characterized in that, said method comprising the steps of by server positioning function network element:

Server positioning function network element receives inquiry request message, and described message comprises user ID to be looked into;

With user ID described to be looked into is keyword, searches the relation data between the local wildcard type user that is complementary and the ownership HSS address;

The query requests initiator is informed in ownership HSS address in the relation data that will be complementary.

9, the method for obtaining ownership HSS address by server positioning function network element as claimed in claim 8, it is characterized in that, be keyword with user ID described to be looked into, searching before the local wildcard type user and the relation data between the ownership HSS address that is complementary, also comprising:

With user ID described to be looked into is keyword, searches the relation data between the local non-wildcard type user that is complementary and the ownership HSS address.

10, as claimed in claim 9ly obtain the method for ownership HSS address, it is characterized in that, also comprise the priority that presets dissimilar relation datas by server positioning function network element.

11, the method for obtaining ownership HSS address by server positioning function network element as claimed in claim 10, it is characterized in that, relation data priority between described non-wildcard type user and the ownership HSS address is higher than the relation data priority between described wildcard type user and the ownership HSS address.

Images