CN108881118B

CN108881118B - IMS (IP multimedia subsystem) cascade networking method and equipment

Info

Publication number: CN108881118B
Application number: CN201710333861.5A
Authority: CN
Inventors: 吴鹏程
Original assignee: Datang Mobile Communications Equipment Co Ltd
Current assignee: Datang Mobile Communications Equipment Co Ltd
Priority date: 2017-05-12
Filing date: 2017-05-12
Publication date: 2020-07-17
Anticipated expiration: 2037-05-12
Also published as: CN108881118A

Abstract

The invention discloses an IMS cascade networking method and equipment. In the IMS cascade networking method, a first IMS sends a first registration request to a second IMS, the first registration request is used for requesting the second IMS to access a network, and the first registration request comprises a user identifier which is distributed by the first IMS for a terminal registered in the first IMS, so that the second IMS provides service for the terminal corresponding to the user identifier; the second IMS returns a registration success message to the first IMS after receiving the first registration request; the method can simplify the configuration process of the routing information when the IMS is networked, and reduce the cost of the IMS networking.

Description

IMS (IP multimedia subsystem) cascade networking method and equipment

Technical Field

The present invention relates to the field of communications, and in particular, to an IMS cascade networking method and device.

Background

In the specification of protocols such as 3GPP, different IMS (IP Multimedia Subsystem) systems realize communication by configuring routing information with each other. And the IMS system performs service processing according to the preconfigured routing information and the IMS system name and address in the received signaling.

In practical applications, a plurality of IMS systems are distributed in different enterprise networks, and for a certain group company, a plurality of enterprise networks need to be connected. According to the existing IMS networking method, when a set of IMS system is added, a set of gateway devices accessing the network needs to be added, and routing information in other IMS systems needs to be reconfigured.

Because the gateway equipment of the access network is expensive, the workload of reconfiguring the routing information is huge and tedious, and if the added IMS system only provides services for users and terminals with smaller scales, the input and output are not proportional.

Disclosure of Invention

The IMS cascade networking method and the equipment provided by the embodiment of the invention are used for reducing the cost of IMS networking.

The embodiment of the invention provides an IMS cascade networking method, which comprises the following steps:

a first IMS sends a first registration request to a second IMS, wherein the first registration request is used for requesting to access a network through the second IMS, and the first registration request comprises a user identifier distributed by the first IMS for a terminal registered in the first IMS, so that the second IMS provides service for the terminal corresponding to the user identifier;

and the first IMS receives a registration success message sent by the second IMS.

a second IMS receives a first registration request sent by a first IMS, wherein the first registration request is used for requesting to access a network through the second IMS, and the first registration request comprises a user identifier distributed by the first IMS for a terminal registered in the first IMS, so that the second IMS provides service for the terminal corresponding to the user identifier;

and the second IMS returns a registration success message to the first IMS.

An embodiment of the present invention provides an IMS, where the IMS includes, as a first IMS:

a sending module, configured to send a first registration request to a second IMS, where the first registration request is used to request to access a network through the second IMS; the first registration request includes a user identifier allocated by the first IMS to the terminal registered in the first IMS, so that the second IMS provides a service for the terminal corresponding to the user identifier

A receiving module, configured to request access to a network through the second IMS.

An embodiment of the present invention provides an IMS, where the IMS as a second IMS includes:

a receiving module, configured to receive a first registration request sent by a first IMS, where the first registration request is used to request access to a network through the second IMS, and the first registration request includes a user identifier allocated by the first IMS to a terminal registered in the first IMS, so that the second IMS provides a service for the terminal corresponding to the user identifier;

a sending module, configured to send a registration success message to the first IMS.

By the embodiment, when the IMS is networked, the newly added first IMS is used as the established lower-level IMS of the second IMS, so that the first IMS is accessed to the network through the second IMS, a set of equipment for accessing the network does not need to be added to the first IMS, and the networking cost is saved; furthermore, since the first IMS accesses the network through the second IMS, it is also possible to avoid reconfiguring a large amount of routing information in other IMS that is already established.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive exercise.

Fig. 1 is a schematic diagram of IMS system networking in the prior art;

fig. 2 is a schematic flowchart of an IMS system cascade networking method according to an embodiment of the present invention;

fig. 3 is a schematic diagram of a terminal registration process in the prior art;

fig. 4 is a schematic diagram of a terminal registration flow after applying the IMS system cascade networking method provided in the embodiment of the present invention;

fig. 5 is a second schematic diagram of a terminal registration process after applying the IMS system cascade networking method provided in the embodiment of the present invention;

fig. 6 is a third schematic diagram of a terminal registration process after the IMS system cascade networking method provided by the embodiment of the present invention is applied

Fig. 7 is a schematic diagram of an IMS system cascading networking provided in an embodiment of the present invention;

fig. 8 is a schematic diagram of a call flow after applying the IMS system cascading networking method provided in the embodiment of the present invention;

fig. 9 is a second schematic call flow chart after the IMS system cascading networking method according to the embodiment of the present invention is applied;

fig. 10 is a schematic diagram of IMS networking after applying the IMS cascade networking method provided in the embodiment of the present invention;

fig. 11 is a second schematic diagram of IMS networking after applying the IMS cascading networking method provided by the embodiment of the present invention;

fig. 12 is a flowchart illustrating an IMS registration method according to an embodiment of the present invention;

fig. 13 is a schematic diagram of a specific IMS registration flow according to an embodiment of the present invention;

fig. 14 is a schematic structural diagram of an IMS system according to an embodiment of the present invention;

fig. 15 is a schematic structural diagram of an IMS system according to an embodiment of the present invention;

fig. 16 is a schematic structural diagram of an IMS system according to an embodiment of the present invention;

fig. 17 is a schematic structural diagram of a terminal according to an embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention clearer, the present invention will be described in further detail with reference to the accompanying drawings, and it is apparent that the described embodiments are only a part of the embodiments of the present invention, not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

IMS is a form of multimedia service that can meet the demands of modern, more diverse multimedia services for end-users. The IMS system can enable a packet switched domain (PS) to have partial functions of a circuit switched domain (CS), and support conversational multimedia services and non-conversational multimedia services. IMS provides a common service platform for future multimedia applications, typically services like presence, messaging, conferencing, push-to-talk, etc.

The main functional entities involved in the IMS system are:

● HSS (Home Subscriber Server)

The HSS is used as a database for storing user information in the IMS, and mainly stores user authentication information, specific information of a subscriber, dynamic information of the subscriber, network policy rules, and device identification register information, for mobility management and user service data management. It is a logical entity that can physically consist of multiple physical databases.

● CSCF (Call Session Control Function)

The CSCF is the core part of IMS and is mainly used for packet-switched based SIP session control. In IMS, the CSCF is responsible for handling user multimedia sessions and can be seen as a SIP server in the IETF architecture. The functions are classified into P-CSCF (Proxy-CSCF, Proxy call session control function), I-CSCF (interrogating-CSCF, interrogating call session control function), and S-CSCF (Serving-CSCF, service call session control function) according to their respective main functions, which may be physically separated or independent.

● MRF (Multimedia Resource Function)

The MRF mainly performs the functions of multi-party calling and multimedia conference. The MRF includes an MRFC (Multimedia Resource function Controller) and an MRFP (Multimedia Resource function processor), which respectively complete the control and bearer functions of the media stream. The MRFC interprets SIP (Session Initiation Protocol) signaling received from the S-CSCF, and controls the MRFP to perform corresponding media stream codec, conversion, mixing, and playing functions using a media gateway control Protocol instruction.

● gateway function

The gateway functions mainly include: BGCF (Breakout Gateway Control Function, out of IMS Gateway Control Function), MGCF (Media Gateway Control Function), IMS-MGW (IMS-Media Gateway), and SGW (Signaling Gateway).

In practical applications, since the coverage area of one set of IMS system is limited, multiple sets of IMS systems are usually required to be networked to meet the user requirements. In the prior art, the networking of sets of IMS systems may be as shown in fig. 1. Each IMS system shown in fig. 1 is in a peer-to-peer relationship, and each IMS system is configured with a different home domain name and serves as a home domain server to provide IMS services for users belonging to the home domain.

The IMS system 1, the IMS system 2, and the IMS system 3 are all configured with a route forwarding relationship. If the terminal 1 served by the IMS system 1 calls the terminal 2 served by the IMS system 3, the IMS system 1 determines that the terminal 2 is a user registered in the IMS system 3 according to the domain name of the called terminal 2 in the call request of the terminal 1 and a pre-configured route forwarding relationship, and sends the call request to the IMS system 3 for processing, thereby realizing communication between users registered in different IMS systems.

If a set of IMS system 4 is added to the network shown in fig. 1, the routing forwarding relationship among the existing IMS system 1, IMS system 2, and IMS system 3 needs to be configured in the newly added IMS system 4; on the other hand, the routing forwarding relationship of the IMS system 4 needs to be added to the routing forwarding relationships configured in the IMS system 1, the IMS system 2, and the IMS system 3. In addition, the IMS system 3 and the newly added IMS system 4 need to perform the interface with the 2/3/4G network independently, as the interface with the 2/3G network is completed.

For example, multiple sets of IMS systems are distributed among different enterprise networks, and for a corporate enterprise, multiple enterprise networks need to be connected. According to the networking method of the existing IMS system, each set of IMS system needs to be configured with the routing information of other IMS systems, and the workload of configuring the routing information is very large. Especially, in the case of multiple enterprise networks under a group needing to be interconnected with the 2/3/4G network, an IMS system of one enterprise network may serve only a small number of users, but routing information is cumbersome to configure, and the newly added IMS system is expensive to interface with the 2/3/4G network.

In order to solve the above problem, an embodiment of the present invention provides a method for cascading and networking an IMS system, so as to reduce the cost of networking the IMS system by establishing a cascading relationship of the IMS system.

The IMS system in the present application may comprise functional entities as described above, but may of course comprise more or less functional entities than the above.

When an IMS system needs to be added, a cascade relationship may be established between the added IMS system and one or more existing IMS systems, that is, the newly added IMS system serves as a subordinate of the one or more IMS systems. Still taking fig. 1 as an example, when a set of IMS system 4 needs to be added, the IMS system 4 may be used as the lower level of the IMS system 1, and therefore, only routing information in the IMS system needs to be reconfigured, that is, routing information of a user served by the IMS system 4 is added, and the IMS system cascade networking method provided by the embodiment of the present invention is applied, so that the IMS system cascade networking method provided by the embodiment of the present invention is implemented, so that the IMS system 4 is used as the lower level of the

Referring to fig. 2, a schematic flow chart of an IMS system cascade networking method provided in the embodiment of the present invention is shown, where as shown in the drawing, the method includes the following steps:

step 201, the first IMS system sends a first registration request to the second IMS system.

The first IMS system is a newly established IMS system, and is positioned as a lower-level IMS system after networking is performed by the cascade networking method provided by the embodiment of the invention; the second IMS system is an IMS system in which routing information is configured in other IMS systems, and is located as a superior IMS system after networking is performed by the cascade networking method provided by the embodiment of the present invention.

The first IMS system sends a first registration request to the second IMS system, and the first registration request is used for requesting to access the network through the second IMS system, namely requesting to register as a subordinate IMS subsystem of the second IMS system.

The first registration request comprises a user identifier distributed by the first IMS system for the terminal registered in the first IMS system, so that the second IMS system provides service for the terminal corresponding to the user identifier.

Optionally, the first registration request may be sent by an S-CSCF in the first IMS system to the second IMS system.

Step 202, the second IMS system returns a registration success message to the first IMS system.

In a possible implementation manner, the second IMS system is pre-configured with a user identifier for being allocated to the first IMS system, so as to be allocated to a terminal served by the first IMS system; the first IMS system is also pre-configured with a user identification used for registering in the second IMS system, and the pre-configured user identification in the second IMS system is consistent with the user identification configured in the first IMS system. The terminals assigned to the user identities need to complete registration in the first IMS system and also need to complete registration in the second IMS system during registration, when messages are sent to terminals under other IMS systems, the messages are forwarded to the second IMS system by the first IMS system and then sent to the other IMS systems by the second IMS system, when the messages from the other IMS systems are received, the messages are sent to the second IMS system by the other IMS systems, and the messages are forwarded to the first IMS system by the second IMS system and then sent to the terminals.

For example, the second IMS system allocates user identifications 13012341000-13012349999 to the terminal registered in the second IMS system. Before the first IMS system and the second IMS system establish the cascade networking, the user identifications 13012340000-13012340999 distributed by the first IMS system for the terminal registered in the first IMS system can be configured in the second IMS system in advance.

The first registration request includes the user identification allocated by the first IMS system to the terminal registered in the first IMS system. After receiving the first registration request sent by the first IMS system, the second IMS system determines whether the user identifier included in the first registration request has been configured in advance. If so, the second IMS system returns a registration success message to the first IMS system; otherwise, returning a registration failure message.

In another possible implementation manner, the second IMS system may not be configured in advance for allocating the user identifier registered in the first IMS system. In this case, when the first IMS system sends the first registration request, the first IMS system carries the user identifier allocated to the terminal in the first registration request, so that the second IMS system provides the service to the terminal allocated to the user identifier.

Through the steps, the first IMS system and the second IMS system establish a cascade relation, namely the first IMS system becomes a lower level of the second IMS system, and the first IMS system accesses the network through the second IMS system.

After the first IMS system and the second IMS system establish a cascade relationship, the terminal may initiate a registration process to the first IMS system, where the registration is to bind an IMPI (IP Multimedia Private Identity) of the terminal with an IMPU (IP Multimedia Public Identity) that the terminal wants to register, and authentication in the registration process ensure network security.

In the prior art, a schematic diagram of a registration process initiated by a terminal may be as shown in fig. 3, and includes the following steps:

step 301, the terminal sends a Register request to the P-CSCF in the IMS system.

Specifically, the terminal may obtain the address of the P-CSCF through a P-CSCF discovery procedure, where the Register includes a home domain name, an IMPI, and an IMPU.

Step 302, the P-CSCF determines the address of the I-CSCF according to the home domain name of the terminal, and sends the Register to the I-CSCF.

Step 303, after receiving the Register, the I-CSCF sends an SAR (Server assignment request) to the HSS to query the address of the S-CSCF.

Step 304, the HSS carries the address of the S-CSCF in the SAA (Server Assignment Answer) and sends the address to the I-CSCF.

Step 305, the I-CSCF sends the Register to the S-CSCF based on the address of the S-CSCF.

Step 306, the S-CSCF finds that the terminal is not authorized yet, that is, the terminal is initially registered, and the S-CSCF sends a UAR (User Authorization Request) to the HSS to acquire the authentication information.

Step 307, the HSS returns the authentication information to the S-CSCF via the UAA (User authentication Answer).

Step 308, the S-CSCF sends a "401 Unauthorized" response to the I-CSCF to challenge the user.

Step 309 the I-CSCF sends a "401 Unauthorized" response to the P-CSCF.

Step 310, the P-CSCF sends a "401 Unauthorized" response to the terminal.

And 311, the terminal calculates the authentication information and carries the authentication information in the Register to send the authentication information to the P-CSCF.

Step 312, the P-CSCF sends the Register to the I-CSCF.

Step 313, the I-CSCF sends the SAR to the HSS to query the address of the S-CSCF.

Step 314, the HSS carries the address of the S-CSCF in the SAA and sends it to the I-CSCF.

Step 315 the I-CSCF forwards the new Register to the S-CSCF.

Step 316, the S-CSCF checks whether the authentication information in the Register is correct according to the authentication information sent by the HSS, if not, the authentication fails, and the registration process is terminated; if the authentication is correct, the authentication is successful, and the S-CSCF sends a MAR (Multimedia authentication Request) to the HSS.

Step 317, the HSS saves the identifier of the S-CSCF and returns a Multimedia authentication response (MAA) to the S-CSCF.

Step 318, the S-CSCF saves the information of the terminal and sends a "200 OK" message to the I-CSCF indicating acceptance of the registration of the terminal.

Step 319 the I-CSCF forwards the "200 OK" message to the P-CSCF.

Step 320, the P-CSCF sends a "200 OK" message to the terminal.

Step 321, the S-CSCF sends the Register to the AS (Application Server).

Step 322, the AS returns a "200 OK" message to the S-CSCF indicating acceptance of the registration.

The steps 301 to 322 are the registration process of the terminal in the prior art.

After the IMS system cascade networking method provided in the embodiment of the present invention is applied, when the terminal registers in the newly established first IMS system, the registration in the first IMS system is completed according to the above steps 301 to 322. Further, after the first IMS system completes registration, the first IMS system may forward a registration request of the terminal to the second IMS system, so that the terminal completes registration in the second IMS system, and further, the second IMS system may provide a service for the terminal registered in the first IMS system, and may send the request to the first IMS system when receiving a request for calling the terminals sent by another IMS system, and the first IMS system sends the request to the terminals.

In a possible implementation manner, the S-CSCF in the first IMS system may send the registration request of the terminal to the P-CSCF in the second IMS system, and then steps executed by the P-CSCF, the I-CSCF, the S-CSCF, the HSS, and the AS in the second IMS system are consistent with the above steps 302 to 322, which is not described herein again.

The authentication process requires a series of operations performed by the terminal and the HSS, and the Register carrying the authentication information sent by the terminal requires IPSec (Internet Protocol Security) encryption and integrity protection. Therefore, although the authentication process achieves security protection, the large amount of calculation increases the load of the terminal and the IMS system, and the processing process is slow. In the above implementation manner, the terminal has already completed the authentication process when registering in the first IMS system, and if authentication is performed again when registering in the second IMS system, the registration process is more complicated and redundant, and the registration time is longer.

Therefore, in another possible implementation manner, according to actual needs (for example, for some terminals that need to consider efficiency), the terminal may not perform the steps of authentication and encryption when registering in the first IMS system and when registering in the second IMS system, or perform authentication and encryption when registering in the first IMS system but not perform authentication or perform authentication only but no encryption again when registering in the second IMS system, so as to simplify the registration process and save the registration time.

Optionally, when the HSS returns the UAA to the S-CSCF after receiving the UAR sent by the S-CSCF, the HSS may add a field in the UAA to indicate whether to initiate an authentication procedure. If the field indicates that the authentication process needs to be initiated, the above steps 308 to 317 need to be executed for authentication; if this field indicates that the authentication procedure does not need to be initiated, the S-CSCF, upon receiving the UAA, returns a "200 OK" message to the I-CSCF, i.e. does not perform steps 308-317 as described above.

Optionally, when the HSS returns the UAA to the S-CSCF after receiving the UAR sent by the S-CSCF, the HSS may add a field in the UAA to indicate whether to perform encryption during authentication. If the field indicates that encryption is required, the P-CSCF needs to encrypt the "401 Unauthorized" returned to the terminal (i.e. the step 310), the Register carrying the authentication information sent by the terminal to the P-CSCF (i.e. the step 311), and the "200 OK" sent by the AS to the S-CSCF (i.e. the step 320); otherwise, the "401 Unauthorized" returned by the P-CSCF to the terminal, the Register carrying the authentication information sent by the terminal to the P-CSCF, and the "200 OK" sent by the AS to the S-CSCF do not need to be encrypted.

Of course, the above-mentioned field for indicating whether to authenticate or not and the field for indicating whether to encrypt or not may both be added to the UAA, or only one of them may be added. For example, if two fields are added, if the field for indicating whether authentication is required indicates that authentication is not required, the authentication process is not performed, and since the authentication process is not performed, the indication of the field for indicating whether encryption is required may be ignored or the field is directly defaulted; if the field for indicating whether the authentication is needed indicates that the authentication is needed, further encrypting is needed, if the encryption is not needed, the authentication process is initiated but the encryption is not needed, otherwise, the authentication process and the encryption are initiated. For another example, if only a field indicating whether authentication is required is added, if the field indicates that authentication is required, an authentication process may be initiated and encrypted according to the prior art, otherwise, the authentication process is not performed. For another example, if only a field indicating whether encryption is required is added, if the field indicates that encryption is required, an authentication process is initiated and encryption is performed, otherwise, an authentication process is initiated but not encrypted.

In order to clearly understand the above embodiments of the present invention, two specific embodiments are described in detail below.

It is assumed that a field for indicating whether to perform an authentication process is authentication-Indication, when a bit value of the field is 0, it indicates that authentication is required, and when the bit value of the field is 1, it indicates that authentication is not required.

It is assumed that a field indicating whether or not encryption is performed is SA-Indication, and when the bit value of the field is 0, encryption is required, and when the bit value of the field is 1, encryption is not required.

In embodiment 1, when the terminal registers in the first IMS system and the second IMS system, whether authentication encryption is performed may be controlled by a field added in the UAA.

The first IMS system and the second IMS system may perform the steps as shown in fig. 4:

step 401, the terminal sends a Register to the P-CSCF in the first IMS system.

And step 402, the P-CSCF in the first IMS system determines the address of the I-CSCF in the first IMS system according to the home domain name of the terminal, and sends the Register to the I-CSCF.

Step 403, after receiving the Register, the I-CSCF in the first IMS system sends the SAR to the HSS in the first IMS system to query the address of the S-CSCF in the first IMS system.

And step 404, the HSS in the first IMS system carries the address of the S-CSCF in the SAA and sends the address to the I-CSCF in the first IMS system.

Step 405, the I-CSCF in the first IMS system sends the Register to the S-CSCF according to the address of the S-CSCF.

Step 406, the S-CSCF in the first IMS system finds that the terminal is not authorized yet, i.e. the terminal is initially registered, and the S-CSCF sends UAR to the HSS to acquire authentication information.

Step 407, the HSS in the first IMS returns the authentication and Authorization information to the S-CSCF through the UAA, where a bit value corresponding to the Authorization-Authorization field in the UAA is 1, which indicates that the authentication process is not initiated any more.

Step 408, the S-CSCF in the first IMS system sends a "200 OK" message to the I-CSCF in the first IMS system, which indicates that the registration of the terminal is accepted, and the "200 OK" message carries indication information that the authentication process is not initiated.

Step 409, the I-CSCF in the first IMS system forwards the "200 OK" message to the P-CSCF in the first IMS system, and the "200 OK" message carries indication information that the authentication process is not initiated.

Step 410, the P-CSCF in the first IMS system sends a "200 OK" message to the terminal, where the "200 OK" message carries indication information that the authentication process is not initiated.

Step 411, the S-CSCF in the first IMS system sends the Register to the AS in the first IMS system.

Step 412, the AS in the first IMS system returns a "200 OK" message to the S-CSCF in the first IMS system indicating acceptance of the registration.

Step 413, the S-CSCF in the first IMS system sends the Register of the terminal to the P-CSCF in the second IMS system.

When the S-CSCF in the first IMS system sends the Register, the home domain name in the original Register needs to be modified into the home domain name of the second IMS system.

After step 413, the steps of the terminal registering in the second IMS system are similar to steps 402 to 412 of registering in the first IMS system, and are not described again.

Embodiment 2, the terminal needs to perform authentication encryption when registering in the first IMS system, and may be controlled not to perform authentication encryption by a field added in the UAA when registering in the second IMS system.

After the terminal completes registration of the first IMS system according to steps 301 to 322, the first IMS system and the second IMS system may perform the steps shown in fig. 5:

and step 501, the S-CSCF in the first IMS system sends the Register of the terminal to the P-CSCF in the second IMS system.

Step 502, the P-CSCF in the second IMS system determines the address of the I-CSCF in the second IMS system according to the home domain name in the Register, and sends the Register to the I-CSCF.

Step 503, after receiving the REGISTER, the I-CSCF in the second IMS system sends the SAR to the HSS in the second IMS system to query the address of the S-CSCF in the second IMS system.

Step 504, the HSS in the second IMS system carries the address of the S-CSCF in the SAA and sends the address to the I-CSCF in the second IMS system.

And step 505, the I-CSCF in the second IMS system sends the REGISTER to the S-CSCF in the second IMS system according to the address of the S-CSCF.

Step 506, the S-CSCF in the second IMS system finds that the terminal is not authorized yet, i.e. the terminal is initially registered, and the S-CSCF sends UAR to the HSS in the second IMS system to obtain the authentication information.

Step 507, the HSS in the second IMS system returns the authentication and Authorization information to the S-CSCF through the UAA, where a bit value corresponding to the Authorization-Authorization field in the UAA is 1, which indicates that the authentication process is not initiated any more.

Step 508, the S-CSCF in the second IMS system sends a "200 OK" message to the I-CSCF in the second IMS system, which indicates that the registration of the terminal is accepted, and the "200 OK" message carries indication information that the authentication process is not initiated.

Step 509, the I-CSCF in the second IMS system forwards the "200 OK" message to the P-CSCF in the second IMS system, where the "200 OK" message carries indication information that the authentication process is not initiated.

Step 510, the P-CSCF in the second IMS system sends a "200 OK" message to the S-CSCF in the first IMS system, where the "200 OK" message carries indication information that the authentication process is not initiated.

Step 511, the S-CSCF in the second IMS system sends the Register to the AS in the second IMS system.

Step 512, the AS in the second IMS system returns a "200 OK" message to the S-CSCF in the second IMS system, indicating that the registration is accepted.

Embodiment 3, the terminal needs to perform authentication encryption when registering in the first IMS system, and may control authentication not to be encrypted by a field added in the UAA when registering in the second IMS system.

After the terminal completes registration in the first IMS system, the terminal, the first IMS system, and the second IMS system may perform the steps shown in fig. 6:

step 601 to step 606 are the same as step 501 to step 506, and are not described again.

Step 607, the HSS in the second IMS system returns the authentication information to the S-CSCF in the second IMS system through the UAA, where a bit value corresponding to the Authorization-Indication field in the UAA is 0, which indicates that the authentication process is initiated, but a bit value corresponding to the SA-Indication field in the UAA is 1, which does not require encryption.

Step 608, the S-CSCF in the second IMS system sends a "401 Unauthorized" response to the I-CSCF in the second IMS system to challenge the user, where the "401 Unauthorized" response carries unencrypted indication information.

Step 609, the I-CSCF in the second IMS system sends a "401 Unauthorized" response to the P-CSCF in the second IMS system, where the "401 Unauthorized" response carries indication information that is not encrypted.

And step 610, the P-CSCF in the second IMS system sends a "401 Unauthorized" response to the S-CSCF in the first IMS system, where the "401 Unauthorized" response carries indication information that is not encrypted.

And when the P-CSCF in the second IMS sends the '401 Unauturized' response, the home domain name in the '401 Unauturized' response is modified into the home domain name of the first IMS system.

Step 611, the S-CSCF in the first IMS system sends a "401 Unauthorized" response to the I-CSCF in the first IMS system, where the "401 Unauthorized" response carries indication information that is not encrypted.

Step 612, the I-CSCF in the first IMS system sends a "401 Unauthorized" response to the P-CSCF in the first IMS system, where the "401 Unauthorized" response carries indication information that is not encrypted.

Step 613, the P-CSCF in the first IMS system sends a "401 Unauthorized" response to the terminal, where the "401 Unauthorized" response carries unencrypted indication information.

And step 614, the terminal calculates the authentication information and carries the authentication information in the Register to send the authentication information to the P-CSCF in the first IMS system. The Register carries the authentication information but is not encrypted.

Step 615, the P-CSCF in the first IMS system sends the new Register to the I-CSCF in the first IMS system.

Step 616, the I-CSCF in the first IMS system forwards the new Register to the S-CSCF in the first IMS system.

Step 617, the S-CSCF in the first IMS system sends the new Register to the P-CSCF in the second IMS system.

When the S-CSCF in the first IMS system sends the Register, the home domain name in the Register needs to be modified to the home domain name of the second IMS system.

Step 618, the P-CSCF in the second IMS system sends the new Register to the I-CSCF in the second IMS system.

Step 619, the I-CSCF in the second IMS system forwards the new Register to the S-CSCF in the second IMS system.

Step 620, the S-CSCF in the second IMS system checks whether the authentication information in the Register is correct according to the authentication information sent by the HSS in the second IMS system, and if not, the authentication fails and the registration flow is terminated; if the authentication is correct, the authentication is successful, and the S-CSCF in the second IMS system sends the MAR to the HSS in the second IMS system.

Step 621, the HSS in the second IMS system stores the identifier of the S-CSCF, and returns the MAA to the S-CSCF in the second IMS system.

Step 622, the S-CSCF in the second IMS system saves the information of the terminal and sends a "200 OK" message to the I-CSCF in the second IMS system, indicating that the registration of the terminal is accepted.

Step 623, the I-CSCF in the second IMS system forwards the "200 OK" message to the P-CSCF in the second IMS system.

And step 624, the P-CSCF in the second IMS system sends a "200 OK" message to the S-CSCF in the first IMS system.

Step 625, the S-CSCF in the second IMS system sends the Register to the AS in the second IMS system.

Step 626, the AS in the second IMS system returns a "200 OK" message to the S-CSCF in the second IMS system indicating acceptance of the registration.

After the terminal completes registration in the IMS system of the tandem networking provided in the embodiment of the present invention, the first IMS system and the second IMS system can provide various service services for the terminal.

It is assumed that terminal a is a terminal registered in an IMS _1 system (a lower IMS system, i.e., a first IMS system), and terminal B is a terminal registered in an IMS _2 system (an upper IMS system, i.e., a second IMS system), as shown in fig. 7. Assume that the home domain name of the IMS _1 system is: @ IMS _ 1; the home domain name of the IMS _2 system is: @ IMS _ 2.

When terminal a requests to call terminal B, the flow diagram of the cascaded IMS system may be as shown in fig. 8, and includes the following steps:

step 801, terminal a sends a call request (INVITE) to IMS _1 system.

The INVITE includes the user identifier of the terminal a, the home domain name @ IMS _1 of the IMS _1 system, and the user identifier of the terminal B.

When the terminal A calls the terminal B, if the home domain name of the terminal B is known, the home domain name of the terminal B is carried in the INVITE, if the home domain name of the terminal B is not known, the home domain name of the terminal B can be defaulted, and the home domain name of the terminal B can be recorded as the same home domain name @ IMS _1 as the terminal A.

Step 802, the IMS _1 system determines that the terminal B is not a terminal registered in the IMS _1 system according to the user identifier of the terminal registered in the IMS _1 system, which is configured in advance, and the IMS _1 system sends INVITE to the IMS _2 system.

Specifically, when the IMS _1 system sends an INVITE to the IMS _2 system, the home domain names of the terminal a and the terminal B in the original INVITE are modified to the home domain name @ IMS _2 of the IMS _2 system.

Step 803, the IMS _2 system determines that the terminal B is a terminal registered in the IMS _2 system according to the pre-configured user identifier of the terminal registered in the IMS _2 system, and sends the INVITE to the terminal B.

Because the terminal B is a registered terminal in the IMS _2 system as an example, the IMS _2 system directly sends the INVITE to the terminal B, if the terminal B is not the registered terminal in the IMS _2 system, the IMS _2 system determines the IMS system registered by the terminal B according to the user identification of the terminal B and the pre-configured routing information, modifies the home domain name of the terminal B in the INVITE into the home domain name of the IMS system registered by the terminal B, and sends the modified INVITE to the IMS system registered by the terminal B.

Step 804, the terminal B receives the call of the terminal A and replies a 200OK message to the IMS _2 system.

Step 805, the IMS _2 system sends a "200 OK" message to the IMS _1 system.

Step 806, the IMS _1 system modifies the home domain names of the terminal a and the terminal B in the received "200 OK" message to the home domain name @ IMS _1 of the IMS _1 system, and sends the modified "200 OK" message to the terminal a.

In step 807, terminal a sends a response (ACK) to the IMS _1 system.

Step 808, the IMS _1 system modifies the home domain names of the terminal a and the terminal B in the ACK to @ IMS _2, and sends the modified ACK to the IMS _2 system.

Step 809, the IMS _2 system sends an ACK to terminal B.

When terminal B requests to call terminal a, the flow diagram of the cascaded IMS system may be as shown in fig. 9, including the following steps:

step 901, terminal B sends a call request (INVITE) to IMS _2 system.

The INVITE includes the user identity of the terminal B, the home domain name @ IMS _2 of the IMS _2 system, and the user identity of the terminal a.

Step 902, the IMS _2 system determines that terminal a is a terminal registered in the IMS _1 system according to the configured routing information, modifies the home domain names of terminal a and terminal B to @ IMS _1, and sends the modified INVITE to the IMS _1 system.

Step 903, the IMS _1 system determines that the terminal a is a terminal registered in the IMS _1 system according to the pre-configured user identifier of the terminal registered in the IMS _1 system, and sends the INVITE to the terminal a.

Step 904, terminal a accepts the call of terminal B and replies a "200 OK" message to IMS _1 system.

Step 905, the IMS _1 system sends a "200 OK" message to the IMS _2 system.

Step 906, the IMS _2 system modifies the home domain names of the terminal a and the terminal B in the received "200 OK" message to the home domain name @ IMS _2 of the IMS _2 system, and sends the modified "200 OK" message to the terminal B.

In step 907, terminal B sends an Acknowledgement (ACK) to IMS _2 system.

Step 908, the IMS _2 system modifies the home domain names of terminal a and terminal B in the ACK to @ IMS _1, and sends the modified ACK to the IMS _1 system.

Step 909, the IMS _1 system sends ACK to terminal a.

In the foregoing embodiments, the first IMS system and only one second IMS system are taken as an example to establish a cascade networking, but in the IMS cascade networking method provided in the embodiments of the present invention, one first IMS system may establish a cascade networking relationship with a plurality of second IMS systems, and one second IMS system may also establish a cascade networking relationship with a plurality of first IMS systems.

Under the condition that a first IMS system and a plurality of second IMS systems establish a cascade networking relationship, when the first IMS system sends a registration request of a terminal to the second IMS systems, or when the first IMS system sends a call request to the second IMS systems, whether the first IMS system establishes a cascade relationship with the second IMS system or not, wherein the second IMS system registers the user identification of the terminal sending the registration request or sending the call request, and the first IMS system sends the registration request or the call request to the IMS system if the cascade relationship is established.

By the embodiment, when the IMS system is networked, the newly added first IMS system is used as the lower-level IMS system of the established second IMS system, so that the first IMS system is accessed to the network through the second IMS, a set of equipment for accessing the network is not required to be added to the first IMS system, and the networking cost is saved; in addition, since the first IMS system accesses the network through the second IMS, it is also possible to avoid reconfiguring a large amount of routing information in other IMS systems that have already been established.

For example, as shown in fig. 10, an IMS networking schematic diagram constructed after applying the IMS cascade networking method provided in the embodiment of the present invention may be configured such that a newly established IMS system accesses an 2/3G network through an established IMS system, compared with the prior art, the newly established IMS system does not need a separate L STP (L cal Signal Transfer Point) device connection of a VMSC (Visited Mobile Switching Center) public network, so as to save the device cost, and in addition, it is also possible to avoid reconfiguring a large amount of routing information in other established IMS systems.

For another example, in an IMS system already established by the main company, the subsidiary company 1 and the subsidiary company 2 also need to establish an IMS system, and the traffic volumes of the subsidiary company 1 and the subsidiary company 2 are small, so that the IMS cascading networking method provided by the embodiment of the present invention can be applied, and the IMS system 1 of the subsidiary company 1 and the IMS system 2 of the subsidiary company are used as a lower-level IMS system of the main company, as shown in fig. 11, so that links do not need to be established between the subsidiary companies and corresponding routing information does not need to be added.

The embodiment of the invention also provides an IMS registration method which is used for simplifying the registration process. As shown in fig. 3, in the IMS registration process in the prior art, the process is very complicated and takes a long time. In some special scenarios, such as a testing phase, authentication of the terminal identity may not be required, and it is desirable to simplify the registration process, so as to achieve fast registration and save registration time.

Referring to fig. 12, a flowchart of an IMS registration method according to an embodiment of the present invention is shown, where the method includes the following steps:

step 1201, the terminal sends a registration request to the IMS system. Authentication information is not included in the registration request.

Step 1202, after receiving the registration request, the IMS system returns a response message to the terminal. The response message includes an authentication identifier and/or an encryption identifier, the authentication identifier is used for indicating whether the terminal initiates an authentication process, and the encryption identifier is used for indicating whether the terminal initiates an authentication process and is encrypted.

Specifically, if the authentication identifier included in the response message returned by the IMS system indicates that the terminal does not initiate the authentication process, the response message indicates that the terminal is successfully authenticated, and the specific process is similar to steps 501 to 510 shown in fig. 5, and "P-CSCF of the first IMS system" in fig. 5 is replaced with "terminal".

If the authentication identifier in the response message returned by the IMS system indicates that the terminal needs to initiate the authentication process, but the encryption identifier indicates that the terminal does not encrypt when initiating the authentication process, the registration process of the terminal may be as shown in fig. 13.

Step 1301, the terminal sends a Register to a P-CSCF in the IMS system;

step 1302, the P-CSCF sends the Register to an I-CSCF in the IMS system;

step 1303, the I-CSCF sends the SAR to the HSS in the IMS system to inquire the address of the S-CSCF in the first IMS system;

step 1304, the HSS carries the address of the S-CSCF in the SAA and returns the address to the I-CSCF;

step 1305, the I-CSCF sends the Register to the S-CSCF;

step 1306, S-CSCF finds the terminal is not authorized yet, namely the terminal is the initial registration, S-CSCF sends UAR to HSS in order to obtain the authentication information;

step 1307, the HSS returns UAA to the S-CSCF, the value of the bit corresponding to the Authorization-Indication field in the UAA is 0, indicating that the authentication process is initiated, and the value of the bit corresponding to the SA-Indication field is 1, that is, no encryption is needed during authentication;

step 1308, the S-CSCF sends a "401 Unauthorized" response to the I-CSCF to challenge the user, where the "401 Unauthorized" response carries indication information that authentication is not encrypted;

step 1309, I-CSCF sends "401 Unauthorized" response to P-CSCF, where the "401 Unauthorized" response carries indication information for authentication but not encryption;

step 1310, the P-CSCF sends the "401 Unauthorized" response to the terminal, where the "401 Unauthorized" response carries indication information that authentication is not encrypted;

and step 1311, the terminal calculates the authentication information, carries the authentication information in the Register and sends the authentication information to the P-CSCF. The Register carries the authentication information but is not encrypted;

step 1312, the P-CSCF sends the new Register to the I-CSCF;

step 1313, the I-CSCF sends the SAR to the HSS in the IMS system to query the address of the S-CSCF in the first IMS system;

step 1314, the HSS carries the address of the S-CSCF in the SAA and returns the address to the I-CSCF;

step 1315, the I-CSCF sends the new Register to the S-CSCF;

step 1316, the S-CSCF checks whether the authentication information in the Register is correct according to the authentication information sent by the HSS, if not, the authentication fails, and the registration process is terminated; if the authentication is correct, the authentication is successful, and the S-CSCF sends the MAR to the HSS;

step 1317, the HSS saves the identifier of the S-CSCF, and returns the MAA;

step 1318, the S-CSCF saves the information of the terminal and sends a "200 OK" message to the I-CSCF indicating that the registration of the terminal is accepted;

step 1319, the I-CSCF forwards the "200 OK" message to the P-CSCF;

step 1320, the P-CSCF sends a "200 OK" message to the terminal;

step 1321, the S-CSCF sends the Register to the AS.

Step 1322, the AS returns a "200 OK" message to the S-CSCF indicating acceptance of the registration.

If the authentication identifier in the response message returned by the IMS system indicates that the terminal needs to initiate an authentication process, and the encryption identifier indicates that the terminal needs to be encrypted when authenticating, the registration process is similar to the registration process shown in fig. 3, and details are not repeated here.

In the embodiment of the method, the authentication identifier and/or the encryption identifier are/is added to control whether the terminal initiates the authentication process or not according to different application scenes, or whether the terminal needs to encrypt or not in the process of initiating the authentication, so that whether the IMS registration process is simplified or not is controlled according to actual requirements.

Based on the same technical concept, the embodiment of the invention also provides an IMS system, which serves as a first IMS system, and is used for implementing the method embodiment. Fig. 14 shows a schematic structural diagram of the first IMS system, which includes:

a sending module 1401, configured to send a first registration request to a second IMS, where the first registration request is used to request to access a network through the second IMS system, and the first registration request includes a user identifier that is allocated by the first IMS system to a terminal registered in the first IMS system, so that the second IMS system provides a service for the terminal corresponding to the user identifier;

a receiving module 1402, configured to request access to a network through the second IMS system.

Optionally, the receiving module 1402 is further configured to: receiving a second registration request sent by a terminal, wherein the second registration request is used for requesting the terminal to register in a first IMS system;

the sending module 1401 is further configured to: sending a registration success message to the terminal; sending a third registration request to the second IMS system, wherein the third registration request is used for requesting the terminal to register in the first IMS system and the second IMS system;

the receiving module 1402 is further configured to: and receiving a response message returned by the second IMS system.

Optionally, the receiving module 1402 is further configured to: receiving a call request sent by a calling terminal, wherein the calling terminal is a terminal registered in the first IMS system;

the sending module 1401 is further configured to: if the called terminal indicated by the call request is not the terminal registered in the first IMS system, sending the call request to the second IMS system, so that the second IMS system sends the call request to the called terminal or the IMS system registered by the called terminal;

the receiving module 1402 is further configured to: and receiving a response message returned by the second IMS system, and sending the response message to the calling terminal.

Optionally, the sending module 1401, when sending the call request to the second IMS system, is specifically configured to: modifying the domain name of the calling terminal in the call request into the domain name of the second IMS system; sending the modified call request to the second IMS system;

the sending module 1401, when sending the response message to the calling terminal, is specifically configured to: modifying the domain name of the calling terminal in the response message into the domain name of the first IMS system; and sending the modified response message to the calling terminal.

Optionally, the receiving module 1402 is further configured to: receiving a call request sent by the second IMS system, wherein a calling terminal indicated by the call request is a terminal registered in the second IMS system or other IMS systems, and the other IMS systems are other IMS systems except the first IMS system and the second IMS system;

the sending module 1401 is further configured to: sending the call request to a called terminal indicated by the call request, wherein the called terminal is a terminal registered in the first IMS system;

the receiving module 1402 is further configured to receive a response message returned by the called terminal;

the sending module 1401 is further configured to send the response message to the second IMS system, so that the second IMS system sends the response message to the calling terminal.

Optionally, the sending module 1401, when sending the call request to the called terminal indicated by the call request, is specifically configured to: modifying the domain name of the called terminal in the call request into the domain name of the first IMS system, and sending the modified call request to the called terminal;

the sending module 1401, when sending the response message to the second IMS system, is specifically configured to: and modifying the domain name of the called terminal in the response message into the domain name of the second IMS system, and sending the modified response message to the second IMS system.

Optionally, the receiving module 1402 is further configured to: receiving a second registration request sent by a terminal, wherein the registration request does not include authentication information;

the sending module 1401 is further configured to return a response message to the terminal, where the response message includes an authentication identifier and/or an encryption identifier, the authentication identifier is used to indicate whether the terminal initiates an authentication process, and the encryption identifier is used to indicate whether the terminal initiates an authentication process and is encrypted; and if the authentication identification indicates that the terminal does not initiate an authentication process, the response message is used for indicating that the terminal is successfully authenticated.

Optionally, the authentication identifier and the encryption identifier are generated by a home subscriber server HSS in the first IMS system.

Based on the same technical concept, the embodiment of the invention also provides an IMS system, which serves as a second IMS system, and is used for implementing the method embodiment. Fig. 15 shows a schematic structural diagram of the IMS system, which includes:

a receiving module 1501, configured to receive a first registration request sent by a first IMS system, where the first registration request is used to request to access a network through a second IMS system, and the first registration request includes a user identifier allocated by the first IMS system to a terminal registered in the first IMS system, so that the second IMS system provides a service for the terminal corresponding to the user identifier;

a sending module 1502, configured to send a registration success message to the first IMS system.

Optionally, the receiving module 1501 is further configured to: receiving a third registration request sent by the first IMS system after receiving a second registration request sent by a terminal, wherein the third registration request is used for registering the terminal in the second IMS system;

the sending module 1502 is further configured to send a response message to the first IMS system.

Optionally, the receiving module 1501 is further configured to: receiving a call request sent by the first IMS system, wherein a calling terminal of the call request is a terminal registered in the first IMS system;

if the called terminal of the call request is a terminal registered in the second IMS system, the sending module 1502 is further configured to: sending the call request to the called terminal; the receiving module 1501 is further configured to: receiving a response message returned by the called terminal; the sending module 1502 is further configured to: sending the response message to the first IMS system;

if the called terminal of the call request is not a terminal registered in the first IMS system or the second IMS system, the sending module 1502 is further configured to: sending the call request to an IMS system registered by the called terminal; the receiving module 1501 is further configured to: receiving a response message returned by an IMS system registered by the called terminal; the sending module 1502 is further configured to send the response message to the first IMS system.

Optionally, the domain name of the calling terminal in the call request is the domain name of the second IMS system.

Optionally, the receiving module 1501 is further configured to: receiving a call request, wherein a calling terminal of the call request is a terminal registered in the second IMS system or a terminal registered in other IMS systems, and the other IMS systems are other IMS systems except the first IMS system and the second IMS system; the called terminal of the call request is a terminal registered in the first IMS system;

the sending module 1502 is further configured to: sending the call request to the first IMS system so that the first IMS system sends the call request to the called terminal;

the receiving module 1501 is further configured to: receiving a response message returned by the first IMS system;

the sending module 1502 is further configured to: and sending the response message to the calling terminal or to the other IMS systems.

Optionally, the domain name of the called terminal in the response message is the domain name of the second IMS system.

Optionally, the receiving module 1501 is further configured to: receiving a third registration request sent by the first IMS system and used for registering the terminal in the first IMS system and the second IMS system, wherein the third registration request does not include authentication information;

the sending module 1502 is further configured to return a response message to the first IMS system, where the response message includes an authentication identifier and/or an encryption identifier, the authentication identifier is used to indicate whether the terminal initiates an authentication process, and the encryption identifier is used to indicate whether the terminal initiates an authentication process and is encrypted; and if the authentication identification indicates that the terminal does not initiate an authentication process, the response message is used for indicating that the terminal is successfully authenticated.

Optionally, the authentication identifier and the encryption identifier are generated by a home subscriber server HSS in the second IMS system.

Based on the same technical concept, an embodiment of the present invention further provides an IMS system, configured to implement the above IMS registration method embodiment, where a schematic structural diagram of the IMS system is shown in fig. 16, and the IMS system includes:

a receiving module 1601, configured to receive a registration request sent by a terminal, where the registration request does not include authentication information;

a sending module 1602, configured to return a response message to the terminal, where the response message includes an authentication identifier and/or an encryption identifier, the authentication identifier is used to indicate whether the terminal initiates an authentication process, and the encryption identifier is used to indicate whether the terminal initiates an authentication process and is encrypted.

Optionally, if the authentication identifier indicates that the terminal does not initiate an authentication process, the response message is used to indicate that the terminal is successfully authenticated.

Optionally, the authentication identifier and/or the encryption identifier are generated by a home subscriber server HSS in the IMS system.

Based on the same technical concept, an embodiment of the present invention further provides a terminal, configured to implement the foregoing IMS registration method embodiment, where a schematic structural diagram of the terminal is shown in fig. 17, and the terminal includes:

a sending module 1701, configured to send a registration request to the IMS system, where the registration request does not include authentication information;

a receiving module 1702, configured to receive a response message returned by the IMS system, where the response message includes an authentication identifier and/or an encryption identifier, the authentication identifier is used to indicate whether the terminal initiates an authentication process, and the encryption identifier is used to indicate whether the terminal initiates an authentication process and is encrypted.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

While preferred embodiments of the present invention have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all such alterations and modifications as fall within the scope of the invention.

It will be apparent to those skilled in the art that various changes and modifications may be made in the present invention without departing from the spirit and scope of the invention. Thus, if such modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include such modifications and variations.

Claims

1. An IP multimedia subsystem IMS cascade networking method is characterized by comprising the following steps:

2. The method of claim 1, further comprising:

the first IMS receives a second registration request sent by a terminal, and the second registration request is used for requesting the terminal to register in the first IMS;

the first IMS returns a registration success message to the terminal;

the first IMS sends a third registration request to the second IMS, and the third registration request is used for requesting the terminal to register in the first IMS and the second IMS;

and the first IMS receives a response message returned by the second IMS.

3. The method of claim 1, further comprising:

the first IMS receives a call request sent by a calling terminal, wherein the calling terminal is a terminal registered in the first IMS;

if the called terminal indicated by the call request is not the terminal registered in the first IMS, the first IMS forwards the call request to the second IMS, so that the second IMS sends the call request to the called terminal or the IMS registered by the called terminal;

and the first IMS receives a response message returned by the second IMS and sends the response message to the calling terminal.

4. The method of claim 3, wherein the first IMS forwarding the call request to the second IMS comprises:

the first IMS modifies the domain name of the calling terminal in the call request into the domain name of the second IMS; the first IMS sends the modified call request to the second IMS;

the sending the response message to the calling terminal includes:

the first IMS modifies the domain name of the calling terminal in the response message into the domain name of the first IMS; and the first IMS sends the modified response message to the calling terminal.

5. The method of claim 1, further comprising:

the first IMS receives a call request sent by the second IMS and sends the call request to a called terminal indicated by the call request; the calling terminal indicated by the call request is a terminal registered in the second IMS or other IMS, and the other IMS is other IMS except the first IMS and the second IMS; the called terminal indicated by the call request is a terminal registered in the first IMS;

and the first IMS sends a response message returned by the called terminal to the second IMS so that the second IMS sends the response message to the calling terminal.

6. The method of claim 5, wherein the sending the call request to the called terminal indicated by the call request comprises:

the first IMS modifies the domain name of the called terminal in the call request into the domain name of the first IMS, and the first IMS sends the modified call request to the called terminal;

the sending, by the first IMS, the response message returned by the called terminal to the second IMS includes:

and the first IMS modifies the domain name of the called terminal in the response message into the domain name of the second IMS, and the first IMS sends the modified response message to the second IMS.

7. The method of claim 1, further comprising:

a first IMS receives a second registration request sent by a terminal, wherein the registration request does not include authentication information;

the first IMS returns a response message to the terminal, the response message comprises an authentication identification and/or an encryption identification, the authentication identification is used for indicating whether the terminal initiates an authentication process, and the encryption identification is used for indicating whether the terminal encrypts when initiating the authentication process;

and if the authentication identification indicates that the terminal does not initiate an authentication process, the response message is used for indicating that the terminal is successfully authenticated.

8. The method of claim 7, wherein the authentication identity and the encryption identity are generated by a home subscriber server, HSS, in the first IMS.

9. An IP Multimedia Subsystem (IMS) networking method is characterized by comprising the following steps:

and the second IMS returns a registration success message to the first IMS.

10. The method of claim 9, further comprising:

the second IMS receives a third registration request sent by the first IMS after receiving a second registration request sent by a terminal, wherein the third registration request is used for the terminal to register in the second IMS;

and the second IMS returns a response message to the first IMS.

11. The method of claim 9, further comprising:

the second IMS receives a call request sent by the first IMS, and a calling terminal of the call request is a terminal registered in the first IMS;

if the called terminal of the call request is the terminal registered in the second IMS, the second IMS sends the call request to the called terminal; the second IMS sends a response message returned by the called terminal to the first IMS;

if the called terminal of the call request is not the terminal registered in the first IMS and the second IMS, the second IMS sends the call request to the IMS registered by the called terminal; and the second IMS receives a response message returned by the IMS registered by the called terminal and sends the response message to the first IMS.

12. The method of claim 11, wherein the domain name of the calling terminal in the call request is a domain name of the second IMS.

13. The method of claim 9, further comprising:

the second IMS receives a call request, a calling terminal of the call request is a terminal registered in the second IMS or a terminal registered in other IMS, and the other IMS is other IMS except the first IMS and the second IMS; the called terminal of the call request is a terminal registered in the first IMS;

the second IMS sends the call request to the first IMS so that the first IMS sends the call request to the called terminal;

and the second IMS receives a response message returned by the first IMS and sends the response message to the calling terminal or other IMS.

14. The method of claim 13, wherein the domain name of the called terminal in the response message is the domain name of the second IMS.

15. The method of claim 9, further comprising:

the second IMS receives a third registration request which is sent by the first IMS and used for the terminal to register in the first IMS and the second IMS, wherein the third registration request does not include authentication information;

the second IMS returns a response message to the first IMS, the response message comprises an authentication identifier and/or an encryption identifier, the authentication identifier is used for indicating whether the terminal initiates an authentication process, and the encryption identifier is used for indicating whether the terminal initiates encryption when initiating the authentication process;

16. The method of claim 15, wherein the authentication identity and the encryption identity are generated by a home subscriber server, HSS, in the second IMS.

17. An IP multimedia subsystem, IMS, as a first IMS, comprising:

a sending module, configured to send a first registration request to a second IMS, where the first registration request is used to request access to a network through the second IMS, and the first registration request includes a user identifier that is allocated by the first IMS to a terminal registered in the first IMS, so that the second IMS provides a service for the terminal corresponding to the user identifier;

and the receiving module is used for receiving the registration success message sent by the second IMS.

18. The IMS of claim 17, wherein the receiving module is further configured to: receiving a second registration request sent by a terminal, wherein the second registration request is used for requesting the terminal to register in the first IMS;

the sending module is further configured to: sending a registration success message to the terminal; sending a third registration request to the second IMS, wherein the third registration request is used for requesting the terminal to register in the first IMS and the second IMS;

the receiving module is further configured to: and receiving a response message returned by the second IMS.

19. The IMS of claim 17, wherein the receiving module is further configured to: receiving a call request sent by a calling terminal, wherein the calling terminal is a terminal registered in the first IMS;

the sending module is further configured to: if the called terminal indicated by the call request is not the terminal registered in the first IMS, sending the call request to the second IMS, so that the second IMS sends the call request to the called terminal or the IMS registered by the called terminal;

the receiving module is further configured to: and receiving a response message returned by the second IMS, and sending the response message to the calling terminal.

20. The IMS of claim 19, wherein the sending module, when sending the call request to the second IMS, is specifically configured to: modifying the domain name of the calling terminal in the call request into the domain name of the second IMS; sending the modified call request to the second IMS;

the sending module, when sending the response message to the calling terminal, is specifically configured to: modifying the domain name of the calling terminal in the response message into the domain name of the first IMS; and sending the modified response message to the calling terminal.

21. The IMS of claim 17, wherein the receiving module is further configured to: receiving a call request sent by the second IMS, wherein a calling terminal indicated by the call request is a terminal registered in the second IMS or other IMS, and the other IMS is other IMS except the first IMS and the second IMS;

the sending module is further configured to: sending the call request to a called terminal indicated by the call request, wherein the called terminal is a terminal registered in the first IMS;

the receiving module is also used for receiving a response message returned by the called terminal;

the sending module is further configured to send the response message to the second IMS, so that the second IMS sends the response message to the calling terminal.

22. The IMS of claim 21, wherein the sending module, when sending the call request to the called terminal indicated by the call request, is specifically configured to: modifying the domain name of the called terminal in the call request into the domain name of the first IMS, and sending the modified call request to the called terminal;

the sending module, when sending the response message to the second IMS, is specifically configured to: and modifying the domain name of the called terminal in the response message into the domain name of the second IMS, and sending the modified response message to the second IMS.

23. The IMS of claim 17, wherein the receiving module is further configured to: receiving a second registration request sent by a terminal, wherein the registration request does not include authentication information;

the sending module is further configured to return a response message to the terminal, where the response message includes an authentication identifier and/or an encryption identifier, the authentication identifier is used to indicate whether the terminal initiates an authentication process, and the encryption identifier is used to indicate whether the terminal initiates an authentication process and is encrypted;

24. The IMS of claim 23, wherein the authentication identity and the encryption identity are generated by a home subscriber server, HSS, in the first IMS.

25. An IP multimedia subsystem, IMS, as a second IMS, comprising:

26. The IMS of claim 25, wherein the receiving module is further configured to: receiving a third registration request sent by the first IMS after receiving a second registration request sent by a terminal, wherein the third registration request is used for registering the terminal in the second IMS;

the sending module is further configured to send a response message to the first IMS.

27. The IMS of claim 25, wherein the receiving module is further configured to: receiving a call request sent by the first IMS, wherein a calling terminal of the call request is a terminal registered in the first IMS;

if the called terminal of the call request is a terminal registered in the second IMS, the sending module is further configured to: sending the call request to the called terminal; the receiving module is further configured to: receiving a response message returned by the called terminal; the sending module is further configured to: sending the response message to the first IMS;

if the called terminal of the call request is not a terminal registered in the first IMS or the second IMS, the sending module is further configured to: sending the call request to an IMS registered by the called terminal; the receiving module is further configured to: receiving a response message returned by the IMS registered by the called terminal; the sending module is further configured to send the response message to the first IMS.

28. The IMS of claim 27, wherein the domain name of the calling terminal in the call request is the domain name of the second IMS.

29. The IMS of claim 25, wherein the receiving module is further configured to: receiving a call request, wherein a calling terminal of the call request is a terminal registered in the second IMS or a terminal registered in other IMS, and the other IMS is other IMS except the first IMS and the second IMS; the called terminal of the call request is a terminal registered in the first IMS;

the sending module is further configured to: sending the call request to the first IMS so that the first IMS sends the call request to the called terminal;

the receiving module is further configured to: receiving a response message returned by the first IMS;

the sending module is further configured to: and sending the response message to the calling terminal or to the other IMS.

30. The IMS according to claim 29, wherein the domain name of the called terminal in the response message is the domain name of the second IMS.

31. The IMS of claim 25, wherein the receiving module is further configured to: receiving a third registration request sent by the first IMS and used for registering the terminal in the first IMS and the second IMS, wherein the third registration request does not include authentication information;

the sending module is further configured to return a response message to the first IMS, where the response message includes an authentication identifier and/or an encryption identifier, the authentication identifier is used to indicate whether the terminal initiates an authentication process, and the encryption identifier is used to indicate whether the terminal initiates an authentication process and is encrypted;

32. The IMS of claim 31, wherein the authentication identity and the encryption identity are generated by a home subscriber server, HSS, in the second IMS.