CN1856167B - Method to request registration of users who are not registered with IMS - Google Patents

Abstract

A method for requesting a user who has not registered with IMS to register, comprising the following steps: a) user terminal A initiates an IMS domain session or sends IMS-related signaling to the called user; b) the network registers the called user without IMS registration c) User terminal A requests the called terminal to perform IMS registration; d) After the called terminal registers, the IMS session restarts. Through the present invention, the user equipment that has not registered with the IMS can also perform the IMS service.

Description

Method to request registration of users who are not registered with IMS

technical field

The present invention relates to the third generation mobile communication, in particular to the registration request initiated by the non-user of the Internet multimedia subsystem.

Background technique

As shown in Figure 1, the Internet Multimedia Subsystem (hereinafter referred to as IMS) is a structural framework formulated by 3GPP to provide users with Internet multimedia services. Before the user utilizes IMS to conduct business, he must first register with the Serving Call Session Control Function (hereinafter referred to as S-CSCF) in the IMS. This registration is to inform the S-CSCF of the user's public user identity (hereinafter referred to as PUI) The binding relationship of the IP address of the location. Of course, during the registration process, the user can also tell the network some of his features, supported capabilities, etc. For details, please refer to the 3GPP specification TS 23.228. The Proxy Call Session Control Function (hereinafter referred to as P-CSCF) in Figure 1 is a proxy gateway used to access the IMS. It is usually a gateway of the network where the user is currently located. The time is notified by the network through the P-CSCF discovery. For specific steps, please refer to TS23.228. The P-CSCF finds an Inquiry Call Session Control Function (hereinafter referred to as I-CSCF) by analyzing the home network domain name included in the user's PUI, and knows the user's identity through the interaction between the I-CSCF and the home network registration subscriber server (hereinafter referred to as HSS). The S-CSCF. After the I-CSCF finds the user's S-CSCF, it forwards the message received from the P-CSCF to the S-CSCF for processing by the S-CSCF. If the S-CSCF has not stored the service attributes of the user, it will request such information from the HSS. Part of the interaction between the I-CSCF and the HSS and the part of the interaction between the S-CSCF and the HSS are shown in Figure 9 . S-CSCF continues to process messages received from users.

Figure 9 describes the registration status query process. The I-CSCF receives an INVITE message 801, which is the first Session Initiation Protocol (SIP for short) message initiated for establishing an IMS call. The INVITE message contains the user's SIP URI or TELURI. Regardless of which user's PUI is included, the I-CSCF can find the user's HSS according to the existing specifications. The HSS includes information such as some service characteristics agreed upon when the user signs a contract with the operator. The HSS includes information about whether the user has registered with the IMS. The I-CSCF sends 802 a location query Cx-LocQuery message to the HSS, which contains information such as the user's PUI, and the HSS returns 803 information about whether the user is registered in the location query response Cx-LocQueryResp message. If the user has already registered, it returns the selected Information about the S-CSCF. If 803 contains the information of the user's S-CSCF or the characteristic information of the S-CSCF required by the user, then the I-CSCF selects an S-CSCF according to the characteristic of the S-CSCF. After the S-CSCF is selected, the I-CSCF sends the received INVITE message to the S-CSCF805. If the S-CSCF does not have information such as the service attribute of the user, the S-CSCF will request the information from the HSS. The 806S-CSCF sends an information pull Cx-Pull message to the HSS, and the message includes information such as the PUI of the user equipment. The HSS returns information 807 such as the user's service attributes to the S-CSCF. The S-CSCF performs service control 808 according to the user service attribute information obtained in the previous step, and then performs corresponding service procedures.

On the basis of IMS, 3GPP is formulating a combined circuit domain call and IMS session (hereinafter referred to as CSI) standard, as shown in FIG. 8 . There are two clients in one user equipment, one is a call for circuit domain (hereinafter referred to as CS domain), and the other is a session for IMS domain. When a CS domain call and an IMS domain session are simultaneously performed between the same two UEs, the same combined service is presented to the user at the application layer of the user equipment. In this way, some interactions and operations between the CS domain and the IMS domain are required. The CS core in FIG. 1 refers to the collective name of network entities involved in CS domain calls, generally including mobile terminal interaction center (hereinafter referred to as MSC), visitor location register (hereinafter referred to as VLR) and so on. The IMS core refers to the collective name of the network entities involved in the IMS domain session, and generally includes all the entities in FIG. 1 .

Before the two UEs perform the CSI service, the two UEs must know the user's ability to support CSI in advance. The user's ability to support CSI is communicated through the OPTIONS message. Figure 2 describes the ability of the terminal to be transferred between two users through the OPTIONS message. The parameters included in the message include user A's MS-ISDN, SIP URI, media bearer type, whether to support CSI, and so on. For specific parameters, please refer to 3GPP TS 23.279. Then, in the 200OK message sent by UE B to UE A, it includes user B's MS-ISDN, SIP URI, media bearer type, whether to support CSI, and so on. In this way, UE A knows the terminal capability of UE B, and UE B also knows the terminal capability of UE A. The terminal capability of the opposite end is stored in the user terminal and monitored by a timer. If the timer expires, the new terminal capability exchange process will be restarted, and the peer terminal capability stored in the memory will be overwritten by the new terminal capability.

When the terminal of user A has not stored the terminal capability of the opposite terminal, user A initiates a circuit domain (hereinafter referred to as CS) call with user B. As shown in FIG. 3 , in 301 , user A and user B establish a call between CS and user B in a traditional manner, and talk with each other. In order to enable user A and user B to perform CSI subsequently, user A initiates a process of exchanging terminal capabilities with user B. As shown in 302 in FIG. 3 , this step is a summary of all the steps in FIG. 2 . When user A sends an OPTIONS message to its S-CSCF, the message includes not only the terminal capability information of user A, but also the TEL URI of the called UE B. After the message is delivered from the S-CSCF of UE A to the IMS core B of the called UE B, it is found that the user has not registered with IMS, that is, the IMS core B does not know the current IP address of the user, so it cannot communicate with the UE B communicates. Similarly, if UE A already has the terminal capability of UE B, when the IMS session is established in 303, IMS core B finds that the user has not registered with IMS, that is, IMS core B does not know the current IP address of the user, Therefore, it is impossible to communicate with UE B.

Contents of the invention

The purpose of the present invention is to provide a registration method initiated by a non-user of the Internet multimedia subsystem. By allowing the calling user UE A to send a CS message, the called user B is notified to perform IMS registration, so that the communication between the calling user and the called party can be ensured. CSI business is available.

According to an aspect of the present invention, a method for requesting a user who has not registered with IMS to register includes the following steps:

a) The user terminal A initiates a call in the CS domain to the called user, sends a call control message to the called user, and informs the called user of the IMS registration willingness of the user terminal A, and the IMS registration willingness of the user terminal A refers to the user The terminal has or is about to perform IMS registration or the user terminal will not perform IMS registration;

b) If the user terminal A has not performed IMS registration, and the IMS registration willingness of the user terminal A is to perform IMS registration, perform IMS registration;

c) The called user informs the user terminal A of the IMS registration willingness of the called user in the response message of the call control message, and the IMS registration willingness of the called user refers to that the called user has or is about to perform IMS registration or The called user will not register with IMS;

d) If the called user has not registered with IMS, and the called user's IMS registration willingness is to perform IMS registration, perform IMS registration;

e) The user terminal A or the called user decides whether to perform the IMS session or terminal capability exchange process according to the IMS registration willingness of itself and the opposite end.

Description of drawings

Figure 1 is a block diagram of the IMS architecture;

Figure 2 shows that the UE uses the option OPTIONS to exchange terminal capabilities;

Figure 3 shows two UEs adding an IMS session on the basis of a CS domain call;

Fig. 4 is the constitution of the present invention;

Figure 5 is an IMS registration request initiated with a call control message when the option OPTIONS is passed;

FIG. 6 is an IMS registration request initiated with a call control message when the INVITE is delivered;

Figure 7 is a call control message used to initiate an IMS registration request when a call is established;

Figure 8 is the CSI structural framework;

Figure 9 is an IMS registration status check;

Fig. 10: Behavior actions of the user equipment for the third embodiment.

Detailed ways

Figure 4 shows the composition of the present invention. 401 The calling user initiates an IMS domain session or sends IMS-related signaling to the called user through its user terminal UE A. When the network finds that the user has not registered with IMS, it will tell UE A through 402 that UE A will send an IMS message to the called user. The user's terminal equipment UE sends an IMS registration request 403 . UE B negotiates 404 with the called user, and if the called user decides to perform IMS registration, then UE B performs IMS registration 405. After registration, UE B tells UE A 406 the state of IMS registration, and this step is optional in the present invention. Then the UE A or the IMS core B restarts or proceeds to 407 with the original call.

What Fig. 5 provided is an embodiment of the present invention.

After UE A and UE B establish a call in their CS domain, UE A needs to exchange terminal capabilities with UE B, so UE A sends an OPTIONS message 501 to its IMS core A, which contains UE B's SIP URI identifier, UE A's MSISDN, SIP URI, media bearer type, whether to support CSI, etc. When the IMS core A of UE A receives the message, after processing, it finds the IMS core entity of UE B according to the routing addressing mode of the IMS. The core sends an option OPTIONS message 502, which only changes information such as the routing address of the original message, and should not change the terminal capability of UE A. After the IMS core of UE B receives the option OPTIONS message, it will check whether the UE has performed IMS registration 503. This process will be better illustrated when explaining Figure 9. When the IMS core B finds that the UE has not registered with the IMS, it will return a 404 not found message 504 to the UE, and the message is routed to the UE A side 505 by the IMS core A. When UE A receives the message and finds that UE B is not registered, UE A can initiate a request to request UE B to register with IMS. UE A sends a call control message USER INFORMATION 506 to the CS core entity (generally speaking, MSC). This message can be an existing call control message or a newly defined call control message. In this example, we USER INFORMATION message, which contains IMS registration request information element and other information defined by existing specifications. CS core A converts the message USER INFORMATION into user-to-user information USR and sends it to CS domain core 507 of UE B. The CS core of UE B forwards this message to UE B 508. After UE B receives the message, it finds that the message contains information requesting IMS registration. If the user of UE B allows IMS registration, then the IMS registration process 509 is performed between UE B and the IMS core entity of UE B. The specific description of this process can be found in 3GPP TS 24.228. After UE B successfully registers with IMS, UE B either actively initiates an OPTIONS message to exchange terminal capabilities with UE A or tells UE A its IMS registration status. If the former, UE B sends OPTIONS message 515 to IMS core B. The option OPTIONS message is forwarded 514 through IMS core B of UE B and IMS core A of UE A, and finally reaches UE A 513. UE A includes the terminal capability of UE A in the message 518 in the confirmation message 200OK to the message, and the 200OK is finally sent to UE B 517 and 516 through the IMS core A of UE A and the IMS core B of UE B, thus completing Exchange of Terminal Capabilities. If UE B wants to tell UE A its IMS registration information, then UE B sends user information USER INFORMATION 510 to CS core B, and then CS core B sends the message to CS core A through 511 user-to-user information USR, and then CS Core A sends the message user information USER INFORMATION 512 to UE A. The message includes the status of UE B's IMS registration: successful registration or registration failure.

Figure 6 shows another embodiment of the present invention.

UE A and UE B have established a CS domain call. Because UE A has saved the terminal capability of UE B, when UE A wants to add another IMS session, it sends an invitation INVITE message 601 to IMS core A, and the message is routed and addressed by IMS core A Sent to IMS core B 602. IMS core B checks whether UE B has performed IMS registration 603 according to the method shown in FIG. 9 . In this embodiment, we assume that the UE B has not performed IMS registration. IMS core B sends a 404 not found message 604 to IMS core A. The message also carries the timing length of a timer. This timer means that UE A will re-initiate the IMS call after the timer expires, that is, the INVITE message shown in 610 in the figure. If there is no timer in the message, then UE A will not initiate an IMS call to the network, and the remaining work of the call will be completed by the network. When UE A receives 404 not found message 605, UE A requests UE B to perform IMS registration, and UE A initiates user information USER INFORMATION message 606 to CS core A, which contains the information unit requesting IMS registration. CS core A encapsulates the message in the form of a user-to-user information USR message and sends it to CS core B607, and the user-to-user information USR message also includes an information element requesting IMS registration. CS core B repackages the content of the message, and sends it to UEB 608 as a message of USER INFORMATION. This message contains an information element requesting IMS registration. When UE B receives the user information USERINFORMATION message, it finds that the calling side requests it to perform IMS registration. UE B negotiates with its user, and if the user allows IMS registration, then UE B and IMS core B perform IMS registration 609. This registration process has no direct relationship with the present invention, and the specific content can be referred to 3GPP TS24.228. After IMS core B finds that UE B has successfully registered, if it does not include timers 604 and 605 in the 404 sent to UE A, then IMS core B will be responsible for sending an invitation INVITE message 612 to UE B, and UE A will continue to Triggered IMS session establishment process. Otherwise, UE A sends the INVITE message 610 again after the timer expires. When the IMS core B receives the invitation INVITE 611, it continues to send the message to UE B 612 to make a call. UE B accepts the call 613 to 615 with a 200 OK message. When UE A receives 200 OK, it sends ACK to UE B 616 to 618, thus completing the establishment process of the IMS session.

In this embodiment, if UE B does not want to perform IMS registration, when UE A initiates a call again 610 and 611, even if it receives 404 and does not find that there are timers 619 and 620, then UE A will no longer request an IMS session of establishment. In another case, IMS core B finds that UE B has not registered within a period of time, so it discards the IMS session.

What Fig. 7 provided is the third embodiment of the present invention.

This embodiment actually includes two situations. The first case is that when a CS call is established between UE A and UE B, the IMS registration request 701 is included in the SETUP message sent by UE A to the CS core of UE A. The IMS registration request sent by UE A means that UE A has performed IMS registration, otherwise the SETUP message does not contain the IMS registration request. This information is sent to UE B through the CS core of UE A and the CS core of UE B. The name of the message when the CS core of UE A and the CS core of UE B transmits is IAM. When UE B receives the IMS registration request, it negotiates with its user whether to perform IMS registration. If necessary, then it is indicated in the IMS status returned in the CONNECT message that UE B will perform IMS registration 703. Connection CONNECT can also be ALERTING reminder message. When this message is sent, generally speaking, the IMS registration has not yet started, so this status only means that UE B is willing to perform IMS registration, and then the IMS registration process will be performed. The information is transmitted to the CS network of UE A through the message ANM or ACM between the network and the network, and finally sent to UEA through ALTERTING or CONNECT. After UE A receives the IMS status, it will refer to this information to decide when initiating an IMS call or exchanging terminal capabilities in the future. Similarly, because UE B has received the IMS registration request, it knows that UE A is already in the IMS registration state, and this information can be used as reference information for initiating an IMS call or exchanging terminal capabilities in the future. Only when both the self and the opposite end have performed IMS registration, can the process of initiating an IMS call or exchanging terminal capabilities (the processes in Fig. 6 and Fig. 5 ) be performed.

The second case included in this embodiment is that after a CS call has been established between UE A and UE B, when UE A decides to exchange terminal capabilities with UE B or initiate an IMS session, UE A can First communicate with UE B to query the IMS registration status, or after UE A receives 404 not found, as shown in 604 in Figure 6 or 504 in Figure 5, query the IMS registration status. In either case, the messages used are the same. UE A sends user information USERINFORMATION to CS core A to query its IMS registration status 701, then CS core A translates it into user-to-user information USR and sends it to CS core B, and CS core B translates user-to-user information USR into user information USER INFORMATION is sent to UE B. Conversely, UE B sends the status of the IMS to UE A, also using the user information USER INFORMATION 701.

In this embodiment, the parameter included in the CS message may not be the IMS registration request. In the CS message sent by UE A to UE B requesting IMS registration, UE A may inform UEB of its IMS registration willingness. For example, UE A has registered with IMS or is about to register with IMS, then the CS message sent to UE B contains the IMS registration status information of UE A, which means that UE A has registered with IMS or is about to register with IMS. If UE A If you do not want to perform IMS registration, the meaning of the IMS registration status information contained in this message is that UE A will not perform IMS registration. If the UEA is about to perform IMS registration, the IMS registration process is performed within a limited time after sending the message or before sending the message. After UE B receives the IMS registration status information contained in the message, it saves the information, and informs UE A of UE B's IMS registration willingness in a returned response message such as an ALTERTING or CONNECT message. The meaning of this information is that UE B has or is about to perform IMS registration or UE B will not perform IMS registration. If UE B is about to perform IMS registration, the IMS registration process is performed within a limited time after sending the message or before sending the message. When UE A and UE B know that both themselves and the opposite end have performed IMS registration, they initiate the IMS call or perform the process of exchanging terminal capabilities (the process in Figure 6 and Figure 5). If any party is unwilling to perform IMS registration, neither party can initiate an IMS call or perform a process of exchanging terminal capabilities.

If the IMS registration intention information is included in the CS control message, such as setting up SETUP, reminding ALTERTING or connecting CONNECT, the parameter that can carry this information can be the User-User information element in these messages. The User-User protocol discriminator in the User-User information unit may be the IMS registration status, and the User-User information is 0 means that there is a willingness to register, and 1 means that there is no willingness to register. The specific encoding method can vary.

All the messages used above are just for the convenience of examples, and the possibility of using newly defined messages is not excluded.

FIG. 10 describes the actions of the user equipment based on the third embodiment in FIG. 7 .

First judge whether this is the action behavior of the calling user or the action behavior of the called user 1001, if this is the calling user, it is judged whether the user has carried out IMS registration or the user is willing to perform IMS registration 1002, if so, the calling user The user includes the registration request information unit in the message sent to the called user or sets the IMS registration willingness to be 1003, otherwise 1004 the calling user does not include the registration request information unit in the message sent to the called user or sets the IMS registration willingness to No 1004. After sending the message, the calling user receives the message sent by the called party, and according to the information contained in the message, saves 1005 the IMS registration willingness of the peer user equipment. If this is the action behavior of the called user, judge whether the received message contains the IMS registration request information unit 1006, if so, save the IMS registration willingness of the opposite end user equipment as 1007, if it does not contain the IMS registration request information unit and IMS registration intention information unit, then save the IMS registration intention of the peer user equipment as No. If the IMS registration intention information element is included, then save the IMS registration intention of the peer user equipment as Yes 1008 . The called user equipment sends a message to the calling user equipment to inform the opposite end whether its IMS registration willingness is yes or no 1009 . No matter which user equipment is sending the IMS session establishment process or the terminal capability exchange process, it is necessary to determine whether both parties have the willingness to register with IMS 1010, and if so, the subsequent IMS session establishment process or terminal capability exchange process 1011 can be performed. ; Otherwise, the subsequent IMS session establishment process or terminal capability exchange process 1012 cannot be performed.

Claims (6)

1. the request user that do not carry out the IMS registration carries out process registration, may further comprise the steps:

A) user terminal A is initiated the calling in CS territory to the called subscriber, send call control message to the called subscriber, and inform that the IMS registration wish of called subscriber's user terminal A, the IMS registration wish of described user terminal A have referred to user terminal or be about to carry out the IMS registration or user terminal can not carry out the IMS registration;

B) if user terminal A is not also carried out IMS registration, and the IMS of user terminal A registration wish is to be about to carry out the IMS registration, then carries out the IMS registration;

C) called subscriber informs user terminal A called subscriber's IMS registration wish in the response message of described call control message, and described called subscriber's IMS registration wish has referred to the called subscriber or be about to carry out the IMS registration or the called subscriber can not carry out the IMS registration;

D) if the called subscriber does not also carry out IMS registration, and called subscriber's IMS registration wish is to be about to carry out the IMS registration, then carries out the IMS registration;

E) whether user terminal A or called subscriber carry out IMS session or terminal capability exchange process according to the IMS registration wish decision of own and opposite end.

2. method according to claim 1, it is characterized in that in step e), if user terminal A and called subscriber's IMS registration wish be user terminal or be about to carry out the IMS registration, either party can initiate IMS session or terminal capability exchange process so.

3. method according to claim 1, it is characterized in that in described step e), can not carry out the IMS registration if user terminal A or called subscriber's IMS registration wish is a user terminal, either party cannot initiate IMS session and terminal capability exchange process so.

4. method according to claim 1 is characterized in that: described call control message is user profile USER INFORMATION, user-to-user information USR.

5. method according to claim 1 is characterized in that: described call control message is to set up SETUP, reminds ALTERTING, connects CONNECT, IAM, ACM, ANM.

6. method according to claim 1 is characterized in that: described call control message is the user of redetermination and the new information between network, network and the network.

Images