WO2012065496A1

WO2012065496A1 - Method and apparatus for updating switching numbers when registering

Info

Publication number: WO2012065496A1
Application number: PCT/CN2011/081137
Authority: WO
Inventors: 李世涛; 陈志峰
Original assignee: 中兴通讯股份有限公司
Priority date: 2010-11-16
Filing date: 2011-10-21
Publication date: 2012-05-24
Also published as: CN102469438A; CN102469438B

Abstract

Disclosed in the present invention are a method and an apparatus for updating switching numbers when registering, and the method comprises the following steps: a Service Centralization and Continuity Application Server (SCC AS) receives a third-party registration request message; updates the Session Transfer Number for SR-VCC (STN-SR) when confirming that the currently registering user is registered for the first time, and the third-party registration request message carries a dynamic STN-SR; when confirming that the currently registering user is not registered for the first time, and updated the STN-SR at the last registration, the SCC AS decides whether to update the STN-SR according to the dynamic STN-SR if the third-party registration request message carries a dynamic STN-SR, or decides whether to update the STN-SR according to the third-party registration request message else if the third-party registration request message does not carry a dynamic STN-SR. The present invention can solve the problem of disordered STN-SR updating.

Description

Method and device for updating switching number when registering

The present invention relates to the field of communications, and more particularly to a method and system for updating a handover number upon registration. Background technique

In today's mobile networks, a large number of packets based on Packet Domain Switching (PS, Packet Switch) (such as E-UTRAN, UTRAN-HSPA) are deployed, but the coverage is not all-network-wide, PS network in some places. The signal will be very poor. At this time, it is necessary to provide the user with the switching of the PS network to the traditional Circuit Switch (CS) circuit (such as UTRAN, GERAN), especially when the user is in the middle of the session.

Figure 1 is a single mode switching mode (SRVCC) approved by the standards organization. First, a call is being made between UE1 101 and UE2 106, and is a PS bearer based on IP Multimedia Core Network Subsystem (IMS). (PS access), its session is anchored on the SCC AS (Service Centralization and Continuity Application Server) 105. During the process of the call, the UE1 101 moves to a better area (CS access) of the CS network, and the UE1 101 sends the received signal test report to the mobile management device (MME, Mobility) through the original PS network. Management Entity 102, after the MME 102 receives the signal test 4, then performs PS to CS handover, at which time the MME 102 sends a handover notification message to an enhanced mobile switching center (MSC, Mobile Switching) that can cover the UE1 101. At the Centre, the handover notification message includes an SRVCC (STN-SR, Session Transfer Number for SR-VCC) assigned by the network to the user; the MSC 103 can directly send the IMS to the IMS network 104 if there is an extended SIP interface. Switch request command, or through media gateway control function (MGCF, Media Gateway Control Function) Sending an IMS handover request command (the IMS side handover update initiated by the MSC 103) to the IMS network 104, the IMS handover request command includes the media resource information of the MSC 103, and the MSC 103 returns a handover response to the MME 102; After receiving the handover response, the MME 102 sends a notification that the handover is completed to the user. In the process, the MSC 103 sends a handover response to the MME 102, and the MME 102 notifies the user that the handover is complete, and the MSC 103 initiates the handover update on the IMS side simultaneously. During the entire handover process, the calling user and the called user Switching is not perceived.

The switching process of the PS network to the CS network based on the single mode switching mode of FIG. 1 is as shown in FIG. 2, and includes:

At this time, an IMS session is being performed between the user UE-1 and the UE-2.

Step 201: For some reason (such as the change of the UE-1 location), the network environment around the UE-1 is changed. The signal of the PS network accessed by the UE-1 may not be very good, but the surrounding CS network signal Preferably, the UE-1 sends a network signal test report to the wireless side network element of the original PS network;

Step 202: The original PS network radio side network element determines, according to the received network signal test report, whether UE-1 needs to be switched to the CS network.

Step 203: When the original PS network radio side network element determines that handover is required, send a handover request to the MME serving the UE-1.

Step 204: After receiving the handover request, the MME sends a handover notification to an enhanced MSC that can cover the UE-1, where the network includes an STN-SR allocated by the network to the UE-1, and the STN-SR is a static route to the SCC AS. Number

Step 205: After receiving the handover notification, the MSC may send a handover request to the IMS network directly through the SIP interface (if any) or through the MGCF, where the request address is the STN-SR allocated by the network for the UE-1, and the media information is the MSC. Information;

Step 206: After receiving the handover request, the IMS side network element will perform the handover request according to the STN-SR. Sent to the SCC AS;

Step 207: Since all IMS sessions of the UE-1 are anchored on the SCC AS, the SCC AS finds the ongoing session of the UE-1 according to the calling number in the handover request, that is, the number of the UE-1, and sends the session to the session. Sending a remote update request, and modifying the sent media information of the UE-1 side to the information of the MSC;

Step 208: After receiving the remote update request, the UE-2 returns a remote update response to the UE-1 side when agreeing to the remote update request.

Steps 209-210, the SCC AS returns a handover request response to the MSC through the IMS side network element. Step 211: After receiving the 204 step handover notification, the MSC may return a handover response to the MME, and the process and the IMS side handover ( Steps 205~210) are performed simultaneously;

After receiving the handover response, the MME sends a notification handover message to the UE-1 through the original PS network radio side network element. After receiving the message, the UE-1 can switch to the CS network.

In the above process, the handover on the IMS side (steps 205-210) will take a long time because of the need for remote update, especially when UE-1 and UE-2 are not in the same network, the time will be longer. Therefore, an optimized architecture for SRVCC, namely eSRVCC, is proposed.

The architecture of the eSRVCC is as shown in Figure 3. A new network element is added: the ATCF (Access Transfer Control Function) 304. The network element is mainly used to anchor the user's session, and the network element is the same. The service user (UE-1) belongs to the same network. When transmitting the handover, the ATCF only needs to perform an internal handover process without notifying the remote end, which greatly saves the handover time.

When eSRVCC is implemented, ATCF needs to be inserted directly into the session path. Whether it is a call or a call, ATCF is required to be anchored. Therefore, the ATCF address needs to be saved in the network when registering. At the end of the call, the network can route the call to the ATCF. The registration process when using eSRVCC is shown in Figure 4, including: Step 401: When a user (UE-1) connects to a PS network, send a registration request to the IMS network through the PS network; if an eSRVCC is deployed in the PS network, the registration request is routed to the ATCF;

Step 402: At this time, the ATCF determines whether to anchor the subsequent session according to the information such as the subscription of the user. If it is determined that the anchor is required, the user is assigned a dynamic STN-SR, and the value of the dynamic STN-SR is the route of the ATCF. Address

Step 403: The ATCF sends the registration request after inserting the dynamic STN-SR to the IMS network element/intermediary session control function (I/S-CSCF, Interrogating/Serving-Call Session Control Function) entity;

Step 404: After the I/S-CSCF authentication is successfully registered, return a 200 OK response to the user; Step 405, the ATCF sends the 200 OK response to the UE-1, and the user is successfully registered; Step 406, when I/S- After receiving the registration request from the user, the CSCF initiates a third-party registration to all application servers (AS, Application Servers) that provide services for the user. Since the user is a user who has signed the eSRVCC, one of the third-party registration requests. The message is sent to the SCC AS, which also carries the dynamic STN-SR allocated by the ATCF to the user when the user registers. Step 407, after the SCC AS receives the third-party registration request message and determines that the dynamic STN-SR is included, Sending a data update request to the Home Subscriber Server (HSS), where the dynamic STN-SR is carried;

Step 408: In the initial state, the HSS stores a static STN-SR allocated to the user. The value of the static STN-SR is the address of the SCC AS. Since the HSS receives the dynamic STN-SR allocated by the ATCF for the user, the HSS uses The dynamic STN-SR covers the previous static STN-SR and returns an update response to the SCC AS;

Step 409: The SCC AS returns a 200 OK response that is successfully registered to the I/S-CSCF. Step 410: The HSS sends an insert subscription data message to the MME, where the dynamic STN is included, because the STN-SR of the user saved by the HSS changes. SR; Step 411: The MME saves the dynamic STN-SR to the user data, and returns an insertion subscription data response to the HSS.

Figure 5 shows the process of switching using eSRVCC, including:

At this time, UE-1 and UE-2 are in an IMS session, and the session is anchored on the ATCF. Step 501: For some reason (such as the change of the UE-1 location), the network environment around the UE-1 is changed. The signal of the PS network accessed by the UE-1 may not be very good, but the surrounding CS network The signal is better, so UE-1 sends a network signal test report to the wireless side network element of the original PS network;

Step 502: The original PS network radio side network element determines, according to the received network signal test report, whether UE-1 needs to be switched to the CS network.

Step 503: When the original PS network radio side network element determines that handover is required, send a handover request to the MME serving UE-1.

Step 504: After receiving the handover request, the MME sends a handover notification to the enhanced MSC that can cover the UE-1, where the network includes the STN-SR allocated by the network for the UE-1: for the eSRVCC user, from the registration process (according to FIG. 4 The process can be seen that the STN-SR allocated by the network for UE-1 is a dynamic STN-SR, which points to the address of the ATCF.

Step 505: After receiving the handover notification, the MSC may send a handover request to the IMS network directly through the SIP interface (if any) or through the MGCF, where the request address is the dynamic STN-SR, and the media information is the information of the MSC; When the value of the dynamic STN-SR is the address of the ATCF, the MSC directly sends the handover request to the ATCF;

Step 506, because the ATCF anchors the user's session, the ATCF finds the ongoing session of the user (UE-1) according to the identity information of the user in the handover request, and sends the media information of the UE-1 side of the session. The information is modified to the MSC. The modification only needs to be notified to the media gateway under the ATCF. The update request is not sent to the remote end. When the modification is completed, the handover request response is returned to the MSC. Step 507: After receiving the handover notification message of step 504, the MSC may return a handover response to the MME, and the process and the handover to the ATCF (steps 505-506) are performed simultaneously;

Steps 508-509, the MME sends a notification handover message to the UE-1 through the original PS network radio side network element. After receiving the message, the UE-1 may switch to the CS.

As can be seen from the above process, when switching between eSRVCC, it is very important that ATCF allocates a dynamic STN-SR to the user during the registration process. However, in the current eSRVCC registration process, multiple registrations are not considered enough. When the user supports multiple registrations, since the third-party registration on the AS at this stage does not distinguish between multiple registrations, the STN-SR will be made. An error occurred during the update process.

When the user supports multiple registrations, the user can access the IMS from different access networks at the same time, and multiple registrations are independent, and the user's multiple registration information is also saved on the network side. In the current research, eSRVCC handover can be deployed only in the 3GPP PS network, that is, only when the user accesses the 3GPP PS network, the eSRVCC technology may be used when PS to CS handover occurs. When a user accesses from another network, such as a wireless local area network (WLAN) access IMS, the user can initiate multiple registration of the IMS through the WLAN network, but in the WLAN network, there is no ATCF, that is, the eSRVCC technology cannot be applied.

As shown in Figure 6, the user is registered in the scenario. When the user accesses the PS network from the 3GPP, the IMS registration is initiated. The network supports the eSRVCC technology. During the registration process, the ATCF allocates a dynamic STN-SR to the user. After the period of time, the user accesses another network such as WLAN. At this time, an IMS registration 2 is also initiated. The registration is independent of registration 1. However, the WLAN network does not support eSRVCC technology. If there is no ATCF, the specific registration process is as shown in FIG. 6. , including:

Steps 601~611, the flow of registration 1 occurs, the registration request includes the registration ID reg-id=l, and the process is the same as 401-411 of FIG. 4, wherein the 3GPP PS network that initiates registration 1 supports eSRVCC. Technically, the third-party registration, the SCC AS saves the dynamic STN-SR to the HSS, and inserts the dynamic STN-SR into the MME through the HSS; Step 612, at this time, the user (UE-1) accesses another network, and the network does not support the eSRVCC technology. Therefore, the registration request is sent to the P-CSCF2 of the network, and the registration process at this time is registration 2, the same registration. 1 independent, the registration ID is reg-id=2;

Step 613: The P-CSCF2 sends the registration request to the I/S-CSCF serving the UE-1 in the IMS network, where the I/S-CSCF is the same as the I/S-CSCF of the registration 1;

Step 614: After the user authentication of the UE-1 is passed by the I/S-CSCF, send a 200 OK response to the UE-1.

Step 615, the P-CSCF2 forwards the 200 OK response to the UE-1.

Step 616, since the I/S-CSCF receives the registration request of the registration 2 at this time, the I/S-CSCF also needs to send a third-party registration request to the SCC AS. Since the network initiated by the registration 2 does not support the eSRVCC technology, this is There is no dynamic STN-SR in the third-party registration request message;

Step 617: Since only one registration data of the user is saved on the SCC AS, the multiple registrations are not distinguished. According to the prior art, the SCC AS finds that there is no dynamic STN-SR in the third-party registration request message, so the SCC AS The static STN-SR assigned to the user is sent to the HSS through a data update request;

Step 618, after receiving the data update request, the HSS overwrites the dynamic STN-SR previously saved (registered in the registration 1) with the static STN-SR in the message, and returns an update response to the SCC AS;

Step 619: The SCC AS returns a 200 OK response that is successfully registered to the I/S-CSCF. Step 620: The HSS sends the static STN-SR to the MME by inserting the subscription data message. Step 621: The MME will receive the static STN-SR coverage. The previously saved dynamic STN-SR and return a response to the HSS.

Since the two registrations of the user are independent of each other at this time, the user can conduct services in their respective networks through different registrations, but it can be found from the above process that the latter registration will dynamically allocate the ATCF to the user in the previous registration. STN-SR is modified to static STN-SR when the user After the IMS session is initiated by the original PS network, if the switch to the CS network needs to be initiated, the dynamic STN-SR is modified to be a static STN-SR, and the user can only perform the SRVCC switch according to the process in FIG. 2, but The eSRVCC switch cannot be performed, which is not desired by users and network operators. Summary of the invention

In view of the above, the main purpose of the present invention is to provide a method and apparatus for updating a handover number at the time of registration, which can solve the problem that the STN- is caused by the presence and absence of the eSRVCC technology in the multiple registration scenarios. The SR update is confusing.

In order to achieve the above object, the technical solution of the present invention is implemented as follows:

The present invention provides a method for updating a handover number upon registration, the method comprising: an anchor and associated application server (SCC AS) receiving a third party registration request message; determining that a user currently registering is a first registration, and the third party When the registration request message carries the dynamic single mode switching mode switching number (STN-SR), the STN-SR is updated; it is determined that the currently registered user is not registered for the first time, and has been executed in the previous registration.

When STN-SR is updated,

If the third-party registration request message carries a dynamic STN-SR, according to the dynamic

The STN-SR determines whether to perform an update of the STN-SR;

If the third party registration request message does not carry the dynamic STN-SR, it is determined according to the third party registration request message whether to perform the update of the STN-SR.

Further, when the user who is currently registered is the first time registration, and the third party registration request message does not carry the dynamic STN-SR, the method further includes: not performing the update of the STN-SR.

Further, the determining, according to the dynamic STN-SR, whether to perform the update of the STN-SR, includes: the dynamic STN-SR carried in the third-party registration request message and the dynamic STN-SR in the previous registration When the values are not the same, perform the STN-SR update; otherwise, do not execute Update of STN-SR.

Further, when the dynamic STN-SR carried in the third-party registration request message is different from the value of the dynamic STN-SR in the previous registration, the method further includes:

The value of the P-Access-Network-Info header field of the third-party registration request message is read. If the network indicating that the eSRVCC is not allowed to be deployed, the update of the STN-SR is not performed; if the network indicating that the eSRVCC is allowed to be deployed, Then perform an update of the STN-SR.

Further, determining whether to perform the update of the STN-SR according to the third-party registration request message includes:

Reading the value of the P-Access-Network-Info header field of the third-party registration request message, and if the network indicating that the optimized single-mode handover mode (eSRVCC) is not allowed to be deployed, the STN-SR update is not performed; The STN-SR is updated to indicate that the network is allowed to deploy eSRVCC.

Reading the registration ID carried in the third-party registration request message, if the registration ID of the previous registration is the same, performing the update of the STN-SR; if the registration with the previous registration

If the IDs are not the same, the STN-SR update is not performed.

Further, the update of the STN-SR is: SCCAS updates the dynamic STN-SR allocated by the ATCF carried in the third-party registration request message to the HSS; or when the third-party registration request message does not have a dynamic STN- In the SR, the SCC AS updates the static STN-SR allocated by the SCC AS to the user in the HSS; the HSS updates the received STN-SR to the

In the MME.

The present invention also provides an apparatus for updating a switching number when registering, comprising: a receiving unit, an analyzing unit, and an updating unit;

The receiving unit is configured to receive a third party registration request message; The analyzing unit is configured to perform condition analysis of the STN-SR update after the receiving unit receives the third-party registration request message, and notify the update unit of the analysis result;

The updating unit is configured to perform STN-SR update according to the analysis result of the analyzing unit, including:

The analyzing unit determines that the user currently registered is the first registration, and when the third party registration request message carries the dynamic STN-SR, the updating unit performs the update of the STN-SR; the analyzing unit determines that the current registration is performed. When the user is not registered for the first time and has performed an update of the STN-SR in the previous registration,

If the third-party registration request message carries the dynamic STN-SR, determine whether to perform the STN-SR update according to the dynamic STN-SR;

If the third-party registration request message does not carry the dynamic STN-SR, it is determined according to the third-party registration request message whether to perform the update of the STN-SR.

Further, the updating unit is further configured to: when the analyzing unit determines that the user currently registered is the first registration, and determines that the third-party registration request message does not carry the dynamic STN-SR, does not perform the STN-SR Update.

Further, the updating unit is further configured to: when the analyzing unit determines that the dynamic STN-SR carried in the third-party registration request message is different from the value of the dynamic STN-SR in the previous registration The update of the STN-SR is performed; otherwise, the update of the STN-SR is not performed; the update unit is further configured to: determine, by the analyzing unit, the dynamic STN-SR carried in the third-party registration request message, and the former When the values of the dynamic STN-SRs in one registration are different, and the analyzing unit determines that the value of the P-Access-Network-Info header field of the third-party registration request message is not allowed to deploy the network of the eSRVCC The update of the STN-SR is not performed; when the network indicated to be allowed to deploy the eSRVCC is determined, the update of the STN-SR is performed.

Further, the updating unit is further configured to: at the analyzing unit, determine, that the value of the P-Access-Network-Info header field of the third-party registration request message is not allowed to deploy eSRVCC The update of the STN-SR is not performed when the network is determined; the update of the STN-SR is performed when the network indicating that the eSRVCC is allowed to be deployed is determined; and the registration unit carries the registration carried in the third-party registration request message. When the ID is the same as the registration ID of the previous registration, the update of the STN-SR is performed; when not, the update of the STN-SR is not performed.

Further, the updating unit is further configured to: update the dynamic STN-SR allocated by the ATCF carried in the third-party registration request message to the HSS; or when there is no dynamic STN-SR in the third-party registration request message The SST AS updates the static STN-SR assigned to the user to the HSS.

The present invention updates the switching number scheme. When the SCC AS receives the third-party registration request message, it performs an analysis to determine whether to perform the STN-SR handover, for example, determining that the currently registered user is the first registration, and the third-party registration request message. When the dynamic STN-SR is carried, the update of the STN-SR is performed; when the user who is currently registering is not the first registration, and the update of the dynamic STN-SR is performed in the previous registration, if the third-party registration request message carries the dynamic The STN-SR determines whether to perform the update of the STN-SR according to the dynamic STN-SR. If the third-party registration request message does not carry the dynamic STN-SR, it determines whether to perform the update of the STN-SR according to the third-party registration request message. This solves the problem of STN-SR update confusion caused by the existence of support for multiple networks that initiate registration and the lack of support for eSRVCC technology. DRAWINGS

Figure 1 is an architectural diagram of an existing SRVCC handover;

2 is a flow chart of an existing SRVCC handover session;

Figure 3 is an architectural diagram of an existing eSRVCC handover;

Figure 4 is a flow chart of registration when the existing eSRVCC handover is implemented;

Figure 5 is a flow chart of an existing eSRVCC handover session;

6 is a multi-registration flow chart in the prior art;

7 is a flowchart of a method for updating a handover number according to the present invention; FIG. 8 is a flowchart of updating an STN-SR in a multiple registration scenario according to Embodiment 1 of the present invention; FIG. 9 is a flowchart of updating an STN-SR in a multiple registration scenario according to Embodiment 2 of the present invention; A schematic diagram of the structure of the device for updating the switching number. detailed description

The technical solutions of the present invention are further elaborated below in conjunction with the accompanying drawings and specific embodiments. As shown in FIG. 7, the method for updating a handover number according to the present invention includes:

Step 701: The SCC AS receives a third-party registration request message.

In step 702, it is determined that the user currently registered is the first registration, and the third party registration request message carries the dynamic STN-SR, and the STN-SR is updated.

Further, if the dynamic STN-SR is not carried in the third-party registration request message, the update of the STN-SR is not performed.

In step 703, it is determined whether the user who is currently registering is not the first registration, and the update of the dynamic STN-SR is performed in the previous registration. If the third-party registration request message carries the dynamic STN-SR, it is determined according to the dynamic STN-SR. Performing an update of the STN-SR; if the third-party registration request message does not carry the dynamic STN-SR, determining whether to perform the update of the STN-SR according to the third-party registration request message.

The determining whether to perform the update of the STN-SR according to the dynamic STN-SR includes: performing the STN-SR when the dynamic STN-SR carried in the third-party registration request message is different from the dynamic STN-SR in the previous registration. Update; otherwise, the STN-SR update is not performed.

When the dynamic STN-SR carried in the third-party registration request message is different from the value of the dynamic STN-SR in the previous registration, the P-Access-Network-Info header of the third-party registration request message is optionally read. The value of the domain, if the network indicating that the eSRVCC is not allowed to be deployed, does not perform the update of the STN-SR; if the network indicating the eSRVCC is allowed to be deployed, the update of the STN-SR is performed.

According to the third-party registration request message, it is determined whether to perform the update of the static STN-SR. the way:

The first step is to read the value of the P-Access-Network-Info header field of the third-party registration request message. If the network indicating that the eSRVCC is not allowed to be deployed, the update of the STN-SR is not performed. If the network is instructed to allow the eSRVCC to be deployed, , then perform an update of the STN-SR.

The network indicating that the eSRVCC is not allowed to be deployed refers to: The network where the user is located when the current registration is initiated does not support eSRVCC.

Manner 2: The registration ID carried in the third-party registration request message is read. If the registration ID of the previous registration is the same, the static STN-SR is updated. If the registration ID is not the same as the previous registration, the STN is not executed. -SR update.

The update of the STN-SR is: SCCAS updates the dynamic STN-SR allocated by the ATCF carried in the third-party registration request message to the HSS; or when there is no dynamic STN-SR in the third-party registration request message, The SCC AS updates the static STN-SR allocated by the SCC AS to the HSS; the HSS re-updates the received STN-SR to the MME.

The method of the present invention will now be described by way of specific examples.

Embodiment 1

FIG. 8 is a flowchart of updating an STN-SR in a multiple registration scenario according to Embodiment 1 of the present invention, where UE-1 accesses an IMS network through an E-UTRAN or UTRAN PS network, and E-UTRAN or UTRAN The PS network supports eSRVCC, and the ATCF allocates dynamic STN-SR to the user. The process includes:

Steps 801 to 811, the process of registration 1 occurs, the registration request includes the registration ID reg-id=l, and the process of registration 1 is the same as steps 401 to 411 in FIG. 4, wherein the E-UTRAN of the registration 1 is initiated or The PS network of the UTRAN supports the eSRVCC. In this embodiment, the registration 1 is the first registration of the user (UE-1), and the third-party registration request message includes the dynamic STN-SR allocated by the ATCF to the UE-1, and the SCC AS executes the STN. - The update of the SR, that is, through the third party registration, the SCC AS saves the dynamic STN-SR to the HSS, and then inserts the dynamic STN-SR into the MME through the HSS. in;

Step 812, at this time, the UE-1 accesses another network, and the network does not support the eSRVCC technology. Therefore, the registration request is sent to the P-CSCF2 in the network, and the registration process is registration 2, and the registration 1 is independent. , the registration ID in the registration request is reg-id=2;

Step 813: The P-CSCF2 sends the registration request of the registration 2 (referred to as the registration request 2) to the I/S-CSCF serving the UE-1 in the IMS network, and the I/S-CSCF is the same as the I/S in the registration 1. CSCF is the same;

Step 814: After the user authentication of the UE-1 is passed by the I/S-CSCF, send a 200 OK response to the P-CSCF2.

Step 815, the P-CSCF2 forwards the 200 OK response to the UE-1;

Step 816: When the registration request 2 is received, the I/S-CSCF also needs to send a third-party registration request to the SCC AS. Since the network that initiates the registration 2 does not support the eSRVCC technology, there is no dynamic STN in the third-party registration request at this time. -SR;

Step 817: At this time, the SCC AS determines the P-Access-Network-Info header field in the third-party registration request message. If the value indicates that the network initiating the registration 2 is not in compliance with the network in which the eSRVCC is deployed, the SCC AS does not execute the STN-SR. Update (SCC AS does not update the static STN-SR to HSS), which is the case in this embodiment; if its value indicates that the network initiating registration 2 is a network that is deployed with eSRVCC, then the SCC AS performs an update of STN-SR (The SCC AS updates the static STN-SR to the HSS).

Steps 818-819, if there is other data to be updated, the SCC AS may send a data update request to the HSS, but the process does not update the STN-SR. If no other data needs to be updated, the SCC AS may not send a data update request to the HSS; Therefore, steps 818-819 are optional; in step 820, the SCC AS returns a registration success 200 OK response to the I/S-CSCF;

Steps 821~822, at this time, if the HSS has other data to be updated, the HSS may send an insert subscription data message to the MME, but the process does not update the STN-SR, if there is no other data. If the update is required, the HSS may not send the insertion subscription data message to the MME; Steps 821~822 are optional.

Embodiment 2

FIG. 9 is a flowchart of updating an STN-SR in a multiple registration scenario according to Embodiment 2 of the present invention, where UE-1 accesses an IMS network through an E-UTRAN or UTRAN PS network, and E-UTRAN or UTRAN The PS network supports eSRVCC, and the ATCF allocates dynamic STN-SR to the user. The process includes:

Steps 901~911, the process of registration 1 occurs, the registration request contains the registration ID reg-id=l, and the process of registration 1 is the same as steps 401-411 in FIG. 4, wherein the E-UTRAN of registration 1 is initiated or The PS network of the UTRAN supports the eSRVCC technology. In this embodiment, the registration 1 is the first registration of the user (UE-1), and the third-party registration request message includes the dynamic STN-SR allocated by the ATCF to the UE-1, SCC AS. Performing the update of the STN-SR, that is, through the third-party registration, the SCC AS saves the dynamic STN-SR to the HSS, and then inserts the dynamic STN-SR into the MME through the HSS;

Step 912, at this time, the UE-1 accesses another network, and the network does not support the eSRVCC technology. Therefore, the registration request is sent to the P-CSCF2 in the network, and the registration process is registration 2, and the registration 1 is independent. , the registration ID in the registration request is reg-id=2;

Step 913: The P-CSCF2 sends the registration request 2 to the I/S-CSCF serving the UE-1 in the IMS network, where the I/S-CSCF is the same as the I/S-CSCF of the registration 1;

Step 914: After the I/S-CSCF passes the user authentication of the UE-1, send a 200 OK response to the P-CSCF2.

Step 915, P-CSCF2 forwards the 200 OK response to UE-1;

Step 916: When the registration request 2 is received, the I/S-CSCF also needs to send a third-party registration request to the SCC AS. Since the network that initiates the registration 2 does not support the eSRVCC technology, there is no dynamic STN in the third-party registration request at this time. -SR; Step 917, at this time, the SCC AS determines the registration ID (reg-id=2) in the third-party registration request message, and if the value is the same as the registration ID (reg-id=l) in the registration 1, the registration 2 is the registration 1 Covering the registration, so the registration data needs to be updated, then the SCC AS performs the STN-SR update (updates the static STN-SR to the HSS); if not, the description is independent registration, then the SCC AS does not execute the STN-SR Update (do not update static STN-SR to HSS), which is different in this embodiment;

Steps 918-919, if there is other data to be updated, the SCC AS may send a data update request to the HSS, but the process does not update the STN-SR. If no other data needs to be updated, the SCC AS may not send a data update request to the HSS;

Step 920: The SCC AS returns a registration success 200 OK response to the S-CSCF.

Steps 921 to 922, if the HSS has other data to be updated, the HSS may send an insertion subscription data message to the MME, but the process does not update the STN-SR. If no other data needs to be updated, the HSS may not send an insertion to the MME. Sign up for data messages.

In order to implement the foregoing switching method, the present invention provides a switching device. Preferably, the device is applied to an SCC AS. As shown in FIG. 10, the present invention includes: a receiving unit, an analyzing unit, and an update unit;

a receiving unit, configured to receive a third party registration request message;

An analyzing unit, configured to perform condition analysis of the STN-SR update after the receiving unit receives the third-party registration request message, and notify the update unit of the analysis result;

The updating unit is configured to perform the STN-SR update according to the analysis result of the analyzing unit, and the method includes: the analyzing unit determines that the currently registered user is the first registration, and the third party registration request message carries the dynamic STN-SR, and executes the STN-SR Update

The analysis unit determines that the user currently registered is not the first registration, and has performed the STN-SR update in the previous registration.

If the third-party registration request message carries the dynamic STN-SR, it is determined according to the dynamic STN-SR. Whether to update the STN-SR;

If the third-party registration request message does not carry the dynamic STN-SR, the third-party registration request message is used to determine whether to update the state STN-SR.

The updating unit is further configured to: when the analyzing unit determines that the currently registered user is the first registration, and the third-party registration request message does not carry the dynamic STN-SR, the STN-SR update is not performed.

The update unit is further configured to determine, according to the dynamic STN-SR whether the update of the STN-SR is performed, the value of the dynamic STN-SR carried in the third-party registration request message and the dynamic STN-SR in the previous registration. When the same is true, the update of the STN-SR is performed; otherwise, the update of the STN-SR is not performed;

When the analyzing unit determines that the dynamic STN-SR carried in the third-party registration request message is different from the value of the dynamic STN-SR in the previous registration, and the analyzing unit determines the third party When the value of the P-Access-Network-Info header field of the registration request message indicates that the network in which the eSRVCC is not allowed to be deployed, the update unit does not perform the update of the STN-SR; when determining the network indicating that the eSRVCC is allowed to be deployed, the update unit performs the STN- SR update.

When the third-party registration request message is used to determine whether to perform the update of the STN-SR, the update unit is further configured to determine, in the analysis unit, that the value of the P-Access-Network-Info header field of the third-party registration request message is not allowed to deploy the eSRVCC. When the network is not performing the update of the STN-SR; when determining the network indicating that the eSRVCC is allowed to be deployed, the update of the STN-SR is performed;

When the third-party registration request message is used to determine whether to perform the update of the STN-SR, the update unit is further configured to: when the analysis unit determines that the registration ID carried in the third-party registration request message is the same as the registration ID of the previous registration, the execution state STN -SR update; not the same, does not perform STN-SR update.

The update unit is further configured to update the dynamic STN-SR allocated by the ATCF carried in the third-party registration request message to the HSS; or when the third-party registration request message does not move In the STN-SR state, the static STN-SR allocated by the SCC AS to the user is updated to the HSS. The above is only the preferred embodiment of the present invention and is not intended to limit the scope of the present invention.

Claims

Claim

A method for updating a switching number at the time of registration, the method comprising: the anchoring and association application server (SCC AS) receiving a third party registration request message; determining that the currently registered user is the first registration, and the method When the third-party registration request message carries the dynamic single-mode handover mode switching number (STN-SR), the STN-SR is updated; it is determined that the currently registered user is not registered for the first time, and has been executed in the previous registration.

When STN-SR is updated,

The STN-SR determines whether to perform an update of the STN-SR;

The method for updating a switching number at the time of registration according to claim 1, wherein the determining that the currently registered user is the first registration, and the third party registration request message does not carry the dynamic STN-SR, The method further includes: not performing an update of the STN-SR.

The method for updating the switching number at the time of registration according to claim 1, wherein the determining whether to perform the updating of the STN-SR according to the dynamic STN-SR includes:

When the dynamic STN-SR carried in the third-party registration request message is different from the value of the dynamic STN-SR in the previous registration, the update of the STN-SR is performed; otherwise, the update of the STN-SR is not performed. .

The method of updating the switching number at the time of registration according to claim 3, wherein the dynamic STN-SR carried in the third-party registration request message is different from the value of the dynamic STN-SR in the previous registration. At the same time, the method also includes:

Reading the value of the P-Access-Network-Info header field of the third-party registration request message, and if the network indicating that the optimized single-mode handover mode (eSRVCC) is not allowed to be deployed, the STN-SR update is not performed; Indicates that the network that is allowed to deploy eSRVCC is executed by STN-SR. Update.

The method for updating a handover number at the time of registration according to claim 1, wherein determining whether to perform the update of the STN-SR according to the third-party registration request message includes:

Reading the registration ID carried in the third-party registration request message, if the registration ID of the previous registration is the same, performing the update of the STN-SR; if not different from the registration ID of the previous registration, Perform an update of the STN-SR.

A method of updating a switching number at the time of registration according to any one of claims 1 to 6, characterized in that

The update of the STN-SR is: the SCC AS updates the dynamic STN-SR allocated by the switching control network element (ATCF) carried in the third-party registration request message to the user home server (HSS); or When there is no dynamic STN-SR in the three-party registration request message, the SCC AS updates the static STN-SR allocated by the SCC AS to the HSS; the HSS re-updates the received STN-SR to the mobility management device (MME). ).

8. A device for updating a switching number when registering, comprising: a receiving unit, an analyzing unit, and an updating unit; wherein

The receiving unit is configured to receive a third party registration request message;

The analyzing unit is configured to perform condition analysis of the STN-SR update after the receiving unit receives the third-party registration request message, and notify the update unit of the analysis result;

The updating unit is configured to perform STN-SR update according to the analysis result of the analyzing unit, and includes: The analyzing unit determines that the user currently registered is the first registration, and when the third party registration request message carries the dynamic STN-SR, the updating unit performs the update of the STN-SR; the analyzing unit determines that the current registration is performed. When the user is not registered for the first time and has performed an update of the STN-SR in the previous registration,

The STN-SR determines whether to perform an update of the STN-SR;

The device for updating the switching number at the time of registration according to claim 8, wherein the updating unit is further configured to: determine, by the analyzing unit, that the user currently registered is the first registration, and determine the third party registration. When the dynamic STN-SR is not carried in the request message, the STN-SR update is not performed.

The device for updating the switching number at the time of registration according to claim 8, wherein the updating unit is further configured to: determine, by the analyzing unit, the dynamic STN-SR and the When the value of the dynamic STN-SR in the previous registration is different, the update of the STN-SR is performed; otherwise, the update of the STN-SR is not performed;

The updating unit is further configured to: when the analyzing unit determines that the dynamic STN-SR carried in the third-party registration request message is different from the value of the dynamic STN-SR in the previous registration, The analyzing unit determines that the value of the P-Access-Network-Info header field of the third-party registration request message indicates that the network of the eSRVCC is not allowed to be deployed, and does not perform the update of the STN-SR; when determining the network indicating that the eSRVCC is allowed to be deployed , Perform an update of the STN-SR.

The device for updating a switching number at the time of registration according to claim 8, wherein the updating unit is further configured to: determine, by the analyzing unit, a P-Access-Network-Info header of the third-party registration request message. When the value of the domain indicates that the network that does not allow eSRVCC is deployed, the update of the STN-SR is not performed; when the network indicated to be allowed to deploy eSRVCC is determined, the execution is performed. And updating the STN-SR; when the analyzing unit determines that the registration ID carried in the third-party registration request message is the same as the registration ID of the previous registration, performing an update of the STN-SR; , The STN-SR update is not performed.

The device for updating a switching number at the time of registration according to any one of claims 8 to 11, wherein the updating unit is further configured to carry the third party registration request message

The ATCF updates the dynamic STN-SR allocated to the user to the HSS; or when the third-party registration request message does not have a dynamic STN-SR, the SCC AS updates the static STN-SR allocated to the user to the HSS.