WO2012103792A1 - 切换方法及系统 - Google Patents

切换方法及系统 Download PDF

Info

Publication number
WO2012103792A1
WO2012103792A1 PCT/CN2012/070625 CN2012070625W WO2012103792A1 WO 2012103792 A1 WO2012103792 A1 WO 2012103792A1 CN 2012070625 W CN2012070625 W CN 2012070625W WO 2012103792 A1 WO2012103792 A1 WO 2012103792A1
Authority
WO
WIPO (PCT)
Prior art keywords
handover
hopf
target
message
source
Prior art date
Application number
PCT/CN2012/070625
Other languages
English (en)
French (fr)
Inventor
吴建华
陶全军
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2012103792A1 publication Critical patent/WO2012103792A1/zh

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/12Reselecting a serving backbone network switching or routing node

Definitions

  • the present invention relates to a handover technology in an IP Multimedia Subsystem (IMS) network architecture, and more particularly to a handover method and handover system based on IMS (IMS). Background technique
  • the development of the core network architecture presents two major trends: one is the IP (Internet Protocol) of the network, and the other is the convergence of various networks. Therefore, the future core network will no longer be divided into multiple core networks such as Circuit Switched (CS), Packet Switching (PS), and IMS. It will be an IP-based unified service control system. All services (including voice services, supplementary services, and value-added services, etc.) are implemented by the unified service control system.
  • CS Circuit Switched
  • PS Packet Switching
  • IMS IP-based unified service control system. All services (including voice services, supplementary services, and value-added services, etc.) are implemented by the unified service control system.
  • the IP-based unified service control system (hereinafter referred to as the unified IP core network) has two characteristics. One is that the voice and other services are implemented using the Session Initiation Protocol (SIP); the second is the service control system and The access technology is irrelevant, that is, the user can access through the PS or through the CS.
  • the PS access mode refers to that the user can access the core network through a packet network such as a General Packet Radio Service (GPRS) or a Wireless Local Area Network (WLAN).
  • GPRS General Packet Radio Service
  • WLAN Wireless Local Area Network
  • the CS access mode refers to that the user accesses the core network through a circuit domain wireless access network such as a base station subsystem (BSS, Base Station Subsystem) or a radio network subsystem (RNS, Radio Network Subsystem). Regardless of the access method used, the services are provided by the above unified IP core network.
  • BSS Base Station Subsystem
  • RNS Radio Network Subsystem
  • FIG. 1 is a schematic diagram of an application scenario in which a CS access mode is used to access a unified IP core network.
  • a user equipment (UE, User Equipment) 101 accesses a network through a circuit domain (for example, The BSS or RNS 102 and the signaling adaptation device 103 are connected to the unified IP core network 104.
  • the signaling adaptation device 103 plays the necessary signaling conversion role, and all services are provided by the unified IP core network 104.
  • the architecture of the CS accessing a unified IP core network includes the following network elements: a user equipment (UE, User Equipment) 201, and a base station controller ( a BSC (Base Station Controller) or a Radio Network Controller (RNC) 202, an Access Gateway (AG) 203, an Integrated Service Control Function (ISCF) 204, wherein the BSC and The RNC 202 includes functions for implementing user access and management and control of radio resources in the CS domain.
  • the interface between the BSC and the AG203 uses the Base Station System Application Part (BSSAP) signaling for communication, and the interface between the RNC and the AG203 uses the Radio Access Network Application Part (RANAP).
  • BSSAP Base Station System Application Part
  • RANAP Radio Access Network Application Part
  • CS access signaling is used for communication, and BSSAP and RANAP signaling are collectively referred to as CS access signaling.
  • the interface between the AG203 and the device 202 is communicated by using CS access signaling, and the interface between the ISCF and the ISCF is communicated by using the SIP protocol, and the AG203 implements a conversion function between the CS access signaling and the SIP message.
  • AG also has the functions of establishing media plane bearer, implementing media stream connection and processing.
  • ISCF204 implements functions such as mobility management, service routing, call control, service control, and data storage. It can be implemented by one or more functional entities.
  • the user equipment UE 201 accesses the AG 203 through the BSC or the RNC. After receiving the CS access signaling sent by the BSC or the RNC, the AG 203 converts it into SIP signaling and sends it to the ISCF 204. At this time, the AG acts as a user agent instead of the user.
  • the device 201 accesses the ISCF 204, and the ISCF 204 performs service routing and call control, whereby the user UE 201 can establish a connection with the remote user and make a call.
  • the above is the architectural description of the CS access to the unified IP core network.
  • the evolution and development of the network must take 4 years. Therefore, the above IP core network will not be deployed in a short period of time.
  • CS network will exist for a long time in a certain period of time. Therefore, there will be a situation in which CS network and the above background network coexist in a period of time. During this period, users can access CS.
  • the network can also access the above IP network.
  • the core network needs to be implemented in order to not interrupt the communication. Switching between these two heterogeneous networks.
  • the signaling plane interaction and the media plane are established by using SIP signaling, and in the CS network, the handover message is transmitted using the mobile application part (MAP, Mobile Application Part) signaling.
  • the media side uses the ISDN User Part (ISUP, ISDN User Part) or the Bearer Independent Call Control (BICC) signaling to establish an inter-office bearer.
  • ISUP ISDN User Part
  • BICC Bearer Independent Call Control
  • the main object of the present invention is to provide a handover method and a handover system, which can realize the compatibility of the ICS enhanced network with the communication services of other mobile network users.
  • a switching method includes:
  • the source AG After receiving the handover request, the source AG notifies the handover agent function entity (HOPF, Handover Proxy Function) to perform heterogeneous network handover processing;
  • HOPF Handover Proxy Function
  • the HOPF notifies the target mobile switching center (MSC) to prepare to switch resources and establish a bearer required for handover;
  • the source AG notifies the source radio network controller (RNC, Radio Network Controller) to perform the handover.
  • RNC Radio Network Controller
  • the notifying the HOPF to perform the heterogeneous network switching process is: After the source AG determines that the current handover is a heterogeneous network handover, the source address of the HOPF is obtained, and the HOPF is notified by the SIP message to perform heterogeneous network handover processing.
  • the SIP message carries related parameters and/or handover identifiers of the handover.
  • the SIP message carries the relevant parameters of the handover and/or the handover identifier: the related parameters and/or the handover identifier of the bearer in the message body of the SIP message.
  • the related parameters of the handover include information of a handover target cell and a target RNC, media codec information supported by the source AG, and codec information used by the current service.
  • the SIP message carries the relevant parameter of the handover and/or the handover identifier is: the handover identifier is carried in the message header of the SIP message.
  • the SIP message is a transfer request REFER message, and/or a call invite INVITE message.
  • the bearer switching identifier in the message header of the SIP message is:
  • the handover identifier is carried in a Route header field or a Request-URI header field of the REFER message.
  • the notifying the HOPF to perform the heterogeneous network switching process is:
  • the source AG directly sends a SIP message to the HOPF, and notifies the HOPF to perform a heterogeneous network switching process.
  • the AG sends a SIP message to the HOPF through the ISCF, and notifies the HOPF to perform a heterogeneous network switching process.
  • the HOPF notifies the target MSC that the required bearer is ready to switch resources and establish a handover:
  • the HOPF sends a MAP preparation handover request MAP_Prepare_Handover_req message to the target MSC, where the MAP_Prepare_Handover_req message carries the cut in the SIP message sent by the source AG received by the HOPF.
  • the relevant parameters of the MAP_Prepare_Handover_req message carrying the handover are:
  • the HOPF maps a target cell parameter of the related parameter of the handover in the SIP message sent by the source AG to a Target Cell Id parameter in the MAP_Prepare_Handover_req message, and maps the target RNC parameter into the MAP_Prepare_Handover_req message.
  • Target RNC Id parameters
  • the HOPF notifies the target MSC to prepare a handover resource and establish a handover: after receiving the MAP_Prepare_Handover_req message, the target MSC sends a handover request to the target RNC; the target MSC receives the target RNC. After the handover request response, sending a MAP preparation handover request response message to the HOPF;
  • the HOPF After receiving the MAP preparation handover request response sent by the target MSC, the HOPF establishes an inter-office bearer with the target MSC, and notifies the target MSC to establish an inter-office bearer by initializing the address message IAM;
  • the HOPF is notified by the address full message ACM.
  • the method further includes:
  • the HOPF After receiving the ACM message, the HOPF establishes an IP bearer between the peer UE or the target AG that is in a session with the UE to be switched by the SIP message, and notifies the ISCF or the source AG to switch the preparation by using a SIP message. carry out.
  • the method further includes:
  • the HOPF After receiving the ACM message, the HOPF sends a SIP message to the source AG to notify the call progress, where the SIP message notifying the progress of the call is a call progress message 183, and the session description protocol SDP field in the call progress message 183
  • the media plane resource information reserved by the HOPF is carried in the middle.
  • the HOPF notifies the target MSC to prepare to switch resources and establish a bearer required for handover For:
  • the HOPF After receiving the SIP message for informing the heterogeneous network handover, the HOPF sends a MAP_Prepare_Handover_req message to the target MSC; where the HOPF switches the received notification to the SIP message of the heterogeneous network handover.
  • the relevant parameters are mapped to corresponding parameters in the MAP_Prepare_Handover_req message.
  • the related parameters of the handover include target cell and target RNC related information and codec information used by the current service.
  • the source AG is notified to complete the handover preparation.
  • a switching method includes:
  • the source MSC After receiving the handover request, the source MSC notifies the HOPF to prepare for handover;
  • the HOPF notifies the target AG to prepare to switch resources and establish an IP bearer
  • the HOPF notifies the source MSC that the handover preparation is completed, and the source MSC notifies the source RNC to perform handover.
  • the notification HOPF is ready to switch to:
  • the source MSC obtains the address information of the HOPF, and sends a MAP_Prepare_Handover_req message to the HOPF, where the MAP_Prepare_Handover_req message carries a handover related parameter, where the related parameters of the handover include information of the handover target cell and the target RNC, and the source AG supports Media codec information and codec information used by the current service.
  • the HOPF notifies the target AG to prepare the handover resource and establish the IP bearer: after receiving the MAP_Prepare_Handover_req message of the source MSC, the HOPF obtains the address information of the target AG and the handover related parameter, and associates the handover The parameter is mapped to the SIP message that notifies the target AG to prepare for handover, and is sent to the target AG, and the notification is sent.
  • the target AG prepares for handover.
  • the notifying the target AG by using a SIP message to prepare to switch to:
  • the HOPF directly sends a SIP message to the target AG to notify the target AG to prepare for handover;
  • the HOPF sends a SIP message to the target AG through the ISCF, and notifies the target AG to prepare for handover; wherein the notified SIP message carries the handover related parameter and the handover identifier.
  • the HOPF notifies the target AG to prepare to switch resources and establish an IP bearer: after receiving the notification of preparing for handover, the target AG sends a handover request message RELOCATION REQUEST to the target RNC, and notifies the target RNC to prepare the radio side resource;
  • the target AG After receiving the handover request response of the target RNC, the target AG notifies the HOPF or the ISCF radio side resource preparation to complete by using a SIP message.
  • the method further includes:
  • the HOPF uses the REFER message to notify the target AG to prepare for handover, the HOPF establishes an IP bearer with the target AG after receiving the handover preparation completion notification NOTIFY message;
  • the IP bearer between the HOPF and the target AG is established during the INVITE session.
  • the method further includes:
  • the HOPF establishes an IP bearer directly or indirectly with the target AG through an INVITE message.
  • the method further includes:
  • the HOPF After the IPPF is established between the HOPF and the target AG, the HOPF notifies the source MSC that the handover preparation is completed by using the MAP_Prepare_Handover_rs message.
  • the MAP_Prepare_Handover_rs message carries the handover number assigned by the HOPF.
  • the method further includes: After receiving the handover preparation completion notification of the HOPF, the source MSC establishes an inter-office bearer with the HOPF, and notifies the HOPF to establish an inter-office bearer by using the IAM;
  • the HOPF reserves resources and establishes an inter-office bearer by the same MSC, and sends an ACM message to the source MSC;
  • the source MSC After receiving the ACM message, the source MSC sends a handover command to the source RNC.
  • a handover system is applied to a wireless communication system, where the handover system includes a source AG, a source RNC, a target RNC, a target MSC, a target AG, a to-be-switched UE, and a peer UE that is in conversation with the UE to be handed over, where:
  • the source AG is configured to notify the HOPF to perform the heterogeneous network switching process after receiving the handover request, and notify the source RNC to perform the handover after receiving the handover preparation completion notification;
  • the HOPF after receiving the heterogeneous network handover notification of the source AG, notifies the target MSC to prepare to switch resources and establish a bearer required for handover.
  • the source AG is further configured to send a SIP message directly to the HOPF, and notify the HOPF to perform a heterogeneous network switching process.
  • the AG is further configured to send, by using the ISCF, a SIP message to the HOPF, and notify the HOPF to perform a heterogeneous network switching process.
  • the HOPF further sends a MAP_Prepare_Handover_req message to the target MSC, where the MAP_Prepare_Handover_req message carries the relevant parameters of the handover in the SIP message sent by the source AG received by the HOPF.
  • the target MSC after receiving the MAP_Prepare_Handover_req message, the target MSC further sends a handover request to the target RNC;
  • the target MSC After receiving the handover request response of the target RNC, the target MSC further sends a MAP preparation handover request response message to the HOPF;
  • the HOPF After the HOPF receives the MAP preparation handover request response sent by the target MSC, And establishing an inter-office bearer with the target MSC, and notifying the target MSC to establish an inter-office bearer by using an initialization address message IAM;
  • the HOPF is further notified by the ACM.
  • the HOPF further establishes an IP bearer between the peer UE or the target AG that is in a session with the UE to be switched by the SIP message, and notifies the ISCF or the SIP message through the SIP message.
  • the source AG switching preparation is completed.
  • a handover system is applied to a wireless communication system, where the handover system includes a source AG, a source RNC, a target RNC, a target MSC, a target AG, a to-be-switched UE, and a peer UE that is in conversation with the UE to be handed over, and is characterized by:
  • the source MSC is configured to notify the HOPF to prepare for the handover after receiving the handover request, and notify the source RNC to perform the handover after the handover preparation for receiving the HOPF is completed;
  • the HOPF is configured to notify the target AG to prepare to switch resources and establish an IP bearer after receiving the preparation handover notification; and notify the source MSC that the handover preparation is completed.
  • the source MSC is further configured to obtain the address information of the HOPF, and send a MAP_Prepare_Handover_req message to the HOPF, where the MAP_Prepare_Handover_req message carries a handover related parameter, where the related parameters of the handover include a handover target cell and a target RNC.
  • the HOPF further acquires address information of the target AG and handover related parameters, and maps the handover related parameter to a SIP message that notifies the target AG to prepare for handover. And sending to the target AG, notifying the target AG to prepare for handover.
  • the HOPF sends a SIP message directly to the target AG, and notifies the target AG to prepare for handover; Or, the HOPF sends a SIP message to the target AG through the ISCF, and the target AG is notified to prepare the handover.
  • the notified SIP message carries the handover related parameter and the handover identifier.
  • the target AG sends a handover request message RELOCATION REQUEST to the target RNC, and notifies the target RNC to prepare the radio side resource; after receiving the handover request response of the target RNC, the target AG passes the The SIP message notifies the HOPF or the ISCF radio side resource preparation to be completed.
  • the HOPF when the HOPF notifies the target AG to prepare for handover by using a REFER message, the HOPF establishes an IP ⁇ I load between the target and the target AG after receiving the handover preparation completion notification NOTIFY message;
  • the IP bearer between the HOPF and the target AG is established during the INVITE session.
  • the HOPF notifies the source MSC that the handover preparation is completed by using a MAP_Prepare_Handover_rs message; wherein the MAP_Prepare_Handover_rs message carries the handover number assigned by the HOPF .
  • the source MSC After receiving the handover preparation completion notification of the HOPF, the source MSC establishes an inter-office bearer with the HOPF, and notifies the HOPF to establish an inter-office bearer by using an IAM;
  • the HOPF reserves resources and establishes an inter-office bearer by the same MSC, and sends an ACM message to the source MSC;
  • the source MSC After receiving the ACM message, the source MSC sends a handover command to the source RNC.
  • the source AG after receiving the handover request, the source AG notifies the HOPF to perform the heterogeneous network handover process; the HOPF notifies the target MSC to prepare to switch resources and establish a handover required; the source AG notifies the source radio network controller RNC to perform handover.
  • the source MSC after receiving the handover request, notifies the HOPF to prepare for handover; the HOPF notifies the target AG to prepare to switch resources and establish an IP bearer; the HOPF notifies the source MSC that the handover preparation is completed, and the source MSC notifies the source RNC to perform handover.
  • the technology of the present invention simplifies the process of switching the message. Compared with the prior art, the efficiency of the system switching is improved, the user does not feel the abnormality of the service switching, the switching fluctuation problem does not exist, and the user experience of the service is improved.
  • Figure 1 is a schematic diagram of an application scenario in which a CS access mode is used to access a unified IP core network
  • Figure 2 is an architecture diagram of a CS accessing a unified IP core network
  • FIG. 3 is a schematic structural diagram of a system for switching in accordance with the present invention.
  • Embodiment 4 is a flowchart of Embodiment 1 of a handover method according to an embodiment of the present invention
  • FIG. 5 is a flowchart of Embodiment 2 of a handover method according to an embodiment of the present invention.
  • FIG. 6 is a flowchart of Embodiment 3 of a handover method according to an embodiment of the present invention.
  • FIG. 7 is a flowchart of Embodiment 4 of a handover method according to an embodiment of the present invention.
  • FIG. 8 is a flowchart of Embodiment 5 of a handover method according to an embodiment of the present invention.
  • FIG. 9 is a flowchart of Embodiment 6 of a handover method according to an embodiment of the present invention. detailed description
  • the basic idea of the present invention is that after receiving the handover request of the source RNC, the source SA notifies the target SA to prepare resources for the UE to be switched through the SIP message; after receiving the SIP message, the target SA prepares resources for the UE to be switched, and establishes a resource.
  • the bearer between the source SA and the source SA is notified that the source SA is ready for handover.
  • the source SA notifies the UE to be handed over to the target network.
  • FIG. 3 is a schematic structural diagram of a system for switching according to the present invention.
  • the system for handover of the present invention includes: a network element that initiates handover by an IP network, a HOPF, and a target MSC that is handed over.
  • the network element that initiates the handover by the IP network may be an ISCF or an AG, and may obtain a handover request and determine that it is to be switched to the CS domain, and select an appropriate HOPF according to the operator policy. The request is sent to HOPF.
  • the HOPF is a newly added logical network element located between the IP network and the CS network, and can implement the mutual conversion function between the SIP protocol and the MAP signaling related to the handover between the IP network and the CS network, that is, the IP network. Is to terminate the SIP signaling and convert it into MAP signaling and send it to the relevant network element in the CS domain.
  • the CS network is the relevant network element that terminates the MAP signaling and converts it into SIP signaling and sends it to the IP network.
  • HOPF can also As a proxy network element, the switching process between two networks is controlled.
  • the target MSC which is an existing MSC, can receive the handover request sent by the HOPF and perform the handover service.
  • the switching service of the heterogeneous network involved in the present invention is divided into two different service scenarios, that is, the user switches from the IP network to the CS network and the user switches from the CS network to the IP network.
  • the implementation flow of the two service scenarios is also different.
  • the implementation methods of the two service scenarios are respectively described below with reference to the accompanying drawings and specific embodiments.
  • FIG. 4 to FIG. 6 are flowcharts of switching an IP network to an CS network according to an embodiment of the present invention.
  • UE1 and UE2 are both parties of the call, and UE1 switches from the IP core network to the CS core network during the call, and the source RNC, the source AG, and the source ISCF are respectively before the handover of the UE1.
  • the RNC, the AG, and the ISCF, the target MSC and the target RNC are the MSC and the RNC of the target network to which the UE1 is to be handed over, and the HOPF is the handover proxy server to be used when performing the heterogeneous network handover.
  • the following describes the function of the network element and the message interaction and processing between the network elements through the following handover procedure.
  • FIG. 4 is a flowchart of Embodiment 1 of a handover method according to an embodiment of the present invention, as shown in FIG.
  • the example switching method specifically includes the following steps:
  • Step 401 The UE sends a measurement report to the source RNC.
  • Step 402 The source RNC determines, according to the measurement report, that UE1 needs to perform handover.
  • Step 403 The source RNC sends a handover request (RELOCATION REQUIRED) to the source AG, and carries parameters such as the target cell to which the handover is performed.
  • RELOCATION REQUIRED a handover request
  • Step 404 The source AG acquires the handover parameter of the target cell in the handover request, and determines that the user needs to switch to the CS network according to the target cell and the operator policy or other feasible methods, and the source AG selects an appropriate HOPF according to the operator configuration policy, and
  • the received handover request is converted into a call transfer request (REFER) and sent to the ISCF, where the message carries relevant handover parameters, including target cell and target RNC related information, user number, media codec related information supported by the AG, and the like.
  • the REFER message carries the HOPF address, which can be carried in the Request-URI header field, that is, the Request-URI header field fills in the HOPF address.
  • Step 405 After receiving the REFER, the ISCF returns a call transfer request accept message (202 Accepted) to the source AG.
  • Step 406 The ISCF forwards the REFER message to the HOPF.
  • Step 407 After receiving the REFER request, the HOPF replies with the 202 Accepted message to the ISCF.
  • Step 408 The HOPF determines that the handover needs to be performed according to the handover identifier in the REFER message, and the HOPF acquires the target MSC, and generates a MAP preparation handover request (MAP_Prepare_Handover_req), and simultaneously maps the handover related parameters in the obtained REFER message into a MAP message ready to switch.
  • MAP_Prepare_Handover_req a MAP preparation handover request
  • the corresponding parameter in the request (the MAP_Prepare_Handover _req message), the specific mapping method may refer to the specific meaning of each parameter in the message, for example, mapping the target 'J, the area parameter carried in the REFER message to the Target Cell Id parameter in the MAP preparation switching request, The target RNC parameter is mapped to the Target RNC Id parameter in the MAP preparation handover request. Of course, you need to map the parameters. The number is not limited to this parameter, but the above method can be used to perform corresponding mapping according to the meaning of the parameter.
  • the HOPF then sends a ready handover request message to the target MSC.
  • the HOPF method for obtaining the target MSC may be selected according to the target cell and the operator configuration policy, and other feasible methods may also be used.
  • Step 409 After receiving the preparation handover request, the target MSC allocates the handover number and sends a handover request (RELOCATION REQUEST) to the target RNC.
  • RELOCATION REQUEST a handover request
  • Step 410 After receiving the handover request, the target RNC starts the access network resource reservation process, and allocates corresponding radio resources for the UE1 to access the 3G network from the target RNC. The target RNC then sends a handover request response (RELOCATION REQUEST ACK) to the target MSC.
  • RELOCATION REQUEST ACK a handover request response
  • Step 411 After receiving the handover request response, the target MSC sends a preparation handover request response (MAP_Prepare_Handover_rsp) to the HOPF.
  • MAP_Prepare_Handover_rsp a preparation handover request response
  • Step 412 After receiving the preparation handover request response, the HOPF starts to establish an inter-office bearer with the target MSC. The HOPF sends an Initialization Address (IAM) message to the target MSC.
  • IAM Initialization Address
  • Step 413 The target MSC sends an address full (ACM) message to the HOPF.
  • ACM address full
  • Step 414 After receiving the address full message, the HOPF knows that the handover preparation is completed, and the HOPF converts the message into a notification (NOTIFY) message to the ISCF, and notifies the ISCF that the handover preparation is completed.
  • NOTIFY notification
  • the identity of the switch-ready completion can be carried in the reason parameter of the NOTIFY Subscription-State header field.
  • Step 415 After receiving the notification message, the ISCF returns a confirmation message (200OK) to the HOPF.
  • the process flow in the following steps 416 to 421 is a process in which the UE2 updates the remote media.
  • the process has various implementation modes. The present example is only one of them, and is not intended to limit the present invention.
  • Step 416 The ISCF initiates a call invitation (INVITE) to the HOPF, and carries the media information of the UE2 in the SDP.
  • INVITE a call invitation
  • Step 417 the HOPF updates the remote media plane information to the media information of the UE2, and then The ISCF sends a response message (200 OK), and the message carries the reserved local media information.
  • Step 418 the ISCF sends a response confirmation message (ACK) to the HOPF.
  • ACK response confirmation message
  • Step 419 the ISCF initiates a call re-invitation (REINVITE) to the UE2, and carries it in the SDP.
  • REINVITE call re-invitation
  • Step 420 The UE2 updates the remote media plane information to the HOPF media information, and then
  • the ISCF sends a response message (200 OK), which carries the local media information.
  • Step 421 The ISCF sends a response confirmation message (ACK) to the UE2.
  • ACK response confirmation message
  • Step 422 The ISCF sends a notification message ( NOTIFY ) to the AG to notify the source AG that the handover is ready.
  • Step 423 After receiving the notification message, the AG returns a confirmation message (200OK) to the ISCF.
  • step 424 the AG sends a handover command (Relocation Command) to the source RNC.
  • Step 425 The source RNC forwards the handover command to the UE1.
  • Step 426 The target RNC switches, and UE1 starts to access the radio resource of the target RNC.
  • Step 427 After detecting the UE1, the RNC sends a handover probe message to the target MSC.
  • Step 428 After receiving the handover success message sent by UE1, the target RNC exchanges a completion message (Relocation Complete) with the target MSC.
  • a completion message (Relocation Complete)
  • Step 429 The target MSC notifies the HOPF that the handover is completed through the MAP message.
  • Step 430 The target MSC sends a response message (ANM) to the HOPF, and turns on the inter-office bearer between the target MSC and the HOPF.
  • ANM response message
  • Step 431 The HOPF sends a notification message (NOTIFY) to the ISCF to notify the ISCF that the handover has been completed.
  • NOTIFY a notification message
  • the identity of the handover completion can be carried in the reason parameter of the Subscription-State header field of NOTIFY.
  • Step 432 after receiving the notification message, the ISCF returns a confirmation message (200OK) to the HOPF.
  • the ISCF forwards the notification message ( NOTIFY ) to the AG to notify the AG that the handover has been completed, and releases the session established before the handover with the AG.
  • Step 434 after receiving the notification message, the AG returns a confirmation message (200OK) to the ISCF.
  • Step 435 The AG notifies the source RNC to release the signaling link and the bearer resource.
  • FIG. 5 is a flowchart of a second embodiment of a handover method according to an embodiment of the present invention.
  • the message related to the handover in the first embodiment is The AG sends the HOPF to the HOPF through the ISCF (see steps 404 to 407).
  • the message related to the handover in the second embodiment is directly sent by the AG to the HOPF (see steps 504 to 505).
  • the process of the UE2 performing the remote media plane update in the second embodiment adopts a different implementation manner from that in the first embodiment (see steps 416 to 421 and steps 512 to 517).
  • the handover method of the example of the present invention specifically includes the following steps:
  • Step 501 to step 503 the process of the AG receiving the handover request is the same as the foregoing step 401 to step 403.
  • Step 504 The AG acquires the handover parameters of the target cell in the handover request, and determines that the user needs to switch to the CS network according to the target cell and the operator policy or other feasible methods, and the AG selects an appropriate HOPF according to the operator configuration policy, and receives the
  • the incoming handover request is converted into a call transfer request (REFER) and sent to the HOPF, and the message carries relevant handover parameters, such as including target cell and target RNC related information, user number, media codec related information supported by the AG, and the like.
  • the REFER message carries the HOPF address, which can be carried in the Request-URI header field, that is, the Request-URI header field fills in the HOPF address.
  • Step 505 After receiving the REFER, the HOPF returns a call transfer request accept message (202 Accepted) to the AG.
  • Step 506 to step 511 the target network performs the process of handover preparation and resource reservation, and synchronizes Steps 408-413.
  • the following steps 512 to 517 are processes for UE2 to update the remote media.
  • the process has various implementation modes, and only one of them is listed here.
  • Step 512 The HOPF obtains the ISCF address in the REFER message sent by the AG, and initiates a call invitation (INVITE) to the ISCF, and carries the media information of the local end in the SDP.
  • the INVITE message carries the handover identifier and the number of the UE1 to notify the ISCF user terminal UE1 to initiate the handover service.
  • the carrying mode of the handover identifier may be adopted by adding an extension in the Request-URI header field.
  • the number of UE1 can also be carried in the Request-URI by means of parameter expansion.
  • Step 513 The ISCF initiates a call re-invitation (REINVITE) to the UE2, and carries the media information of the HOPF in the SDP.
  • REINVITE call re-invitation
  • Step 514 After receiving the REINVITE, the UE2 updates the remote media plane information to the HOPF media information, and then sends a response message (200OK) to the ISCF, where the message carries the local media information.
  • Step 515 After receiving the response, the ISCF sends a response confirmation message (ACK) to the UE2.
  • Step 517 The HOPF updates the remote media information to the media information of the UE2, and then sends a response confirmation message (ACK) to the ISCF.
  • ACK response confirmation message
  • Step 518 After receiving the response confirmation message, the HOPF sends a notification message ( NOTIFY ) to the AG to notify the source AG that the handover preparation is completed.
  • the identifier of the handover preparation can be carried in the reason parameter of the Subscription-State header field of NOTIFY.
  • Step 519 After receiving the notification message, the AG returns a confirmation message (200OK) to the HOPF.
  • Step 520 to step 526 describe the process in which the core network notifies the UE1 to perform handover and notifies the HOPF after the handover is completed, as in the foregoing steps 424 to 430.
  • Step 527 After receiving the MAP message carrying the handover completion information, the HOPF sends a notification message (NOTIFY) to the AG, notifies the AG that the handover has been completed, and releases the session established before the handover with the AG.
  • NOTIFY a notification message
  • the identity of the handover complete can be carried in the reason parameter of the Subscription-State header field of NOTIFY.
  • Step 528 After receiving the notification message, the AG returns a confirmation message (200OK) to the HOPF.
  • UE1 completes the handover from the above IP network to the CS network.
  • FIG. 6 is a flowchart of Embodiment 3 of a handover method according to an embodiment of the present invention.
  • the AG or the ISCF uses the REFER message to notify the HOPF to perform the handover (see step 406 and step 504), but in this embodiment, the HOPF is used to perform the handover by using the INVITE message (see step 604); the switched media in the first two embodiments.
  • the flow is anchored on the HOPF, and no longer passes through the source AG (steps 416 to 421, and steps 512 to 517).
  • the switched media stream is anchored on the AG, that is, after the handover.
  • the media stream sent by the UE1 is sent to the UE2 through the HOPF and the AG (steps 612 to 614).
  • the switching method of this embodiment specifically includes the following steps:
  • Steps 601 to 603, the process in which the AG receives the handover request is the same as steps 401 to 403.
  • Step 604 The AG acquires the handover parameter of the target cell in the handover request, and determines that the user needs to switch to the CS network according to the target cell and the operator policy or other feasible methods, and the AG selects an appropriate HOPF according to the operator configuration policy, and receives the
  • the incoming handover request is converted into a call invitation request (INVITE) and sent to the HOPF.
  • the message carries relevant handover parameters, including target cell and target RNC related information, user number, media codec related information supported by the AG, and the like.
  • the message carries the switching identifier, and the carrying mode of the switching identifier can be adopted.
  • the REFER message carries the HOPF address, which can be carried in the Request-URI header field, that is, the Request-URI header field fills in the HOPF address.
  • the SDP of the INVITE message also carries the media plane resource information reserved by the AG.
  • Step 605 After receiving the INVITE, the HOPF determines that the handover needs to be performed according to the handover identifier, and the HOPF obtains the target MSC, and generates a MAP preparation handover request (MAP_Prepare_Handover_req), and the HOPF maps the handover related parameter in the obtained INVITE message to the MAP message.
  • the corresponding parameters in the handover request are prepared.
  • the specific mapping method may refer to the specific meaning of each parameter in the message, for example, mapping the target cell parameter carried in the INVITE message to the Target Cell Id parameter in the MAP preparation switching request, and mapping the target RNC parameter into
  • the MAP prepares the Target RNC Id parameter in the handover request.
  • the parameters to be mapped are not limited to the parameters, but the above methods can be used to perform corresponding mapping according to the meaning of the parameters.
  • the HOPF then sends a ready handover request message to the target MSC.
  • the way in which the HOPF obtains the target MSC may be selected by the AG and then placed in the INVITE message to the HOPF, or the HOPF itself may be selected according to the target cell and the operator configuration policy.
  • Step 606 Step 610, the same step 507 ⁇ Step 511.
  • Step 611 After receiving the address full message (ACM), the HOPF sends a call progress message (183 Call Progress) to the AG.
  • the SDP of the 183 message also carries the media plane resource information reserved by the HOPF.
  • Step 612 After receiving the call progress message, the AG sends a handover command (Relocation Command) to the source RNC.
  • a handover command (Relocation Command)
  • Steps 613 to 618 are the same as steps 521 to 526.
  • Step 619 After receiving the response message (ANM) sent by the target MSC, the HOPF sends a response message (200OK) to the AG.
  • NAM response message
  • the HOPF After receiving the response message (ANM) sent by the target MSC, the HOPF sends a response message (200OK) to the AG.
  • Step 620 After receiving the response message, the AG replies with a response confirmation message (200OK) to the HOPF.
  • Step 621 The AG notifies the source RNC to release the signaling link and the bearer resource, and notifies the ISCF user equipment that UE1 has switched to the target network.
  • UE1 completes the handover from the above IP network to the CS network.
  • FIG. 7 is a flowchart of a CS network handover to an IP network according to an embodiment of the present invention.
  • UE1 and UE2 are both parties of a call, and UE1 switches from the CS core network to the IP core during a call.
  • the network, the source RNC, and the source MSC are both the RNC and the MSC before the handover of the UE1, and the ISCF, the target AG, and the target RNC are the ISCF, AG, and RNC of the target network to which the UE1 is to be handed over.
  • the HOPF is used when the heterogeneous network is switched. Switch to the proxy server.
  • FIG. 7 is a flowchart of Embodiment 4 of a handover method according to an embodiment of the present invention. As shown in FIG. 7, the handover method in this embodiment specifically includes the following steps:
  • Step 701 The UE sends a measurement report (Measure Report) to the source RNC.
  • Step 702 The source RNC determines, according to the measurement report, that the UE1 needs to perform handover.
  • Step 703 the source RNC sends a handover request to the source MSC (RELOCATION REQUIRED) 0
  • Step 704 After receiving the handover request, the source MSC determines that it needs to switch to the IP network according to the target cell, and selects an appropriate HOPF according to the target cell information and the operator policy, and sends a MAP preparation handover request (MAP_Prepare_Handover_req) to the HOPF. It carries handover related parameters, such as target cell, target RNC related information, and codec related information.
  • Step 705 After receiving the preparation handover request, the HOPF allocates the handover number, and selects the target ISCF and the target AG according to the target cell and the operator policy or other suitable manner, and the HOPF converts the received MAP message into a call transfer request (REFER).
  • the message is sent to the target ISCF,
  • the destination address (refer-To) in the REFER message is the address of the target AG.
  • the message carries the handover related parameter, and the handover related parameter is mapped from the MAP preparation handover request message, and includes the target cell, the target RNC related information, and the codec related information.
  • Step 706 After receiving the call transfer request message, the ISCF returns a call transfer request accept (202 Accepted) message to the HOPF.
  • Step 707 the ISCF obtains the target AG address, and forwards the call transfer request (REFER) to the target AG.
  • the method for obtaining the target AG by the ISCF may be to obtain the target AG according to the target cell or the target RNC information and the operator policy carried in the REFER message, or may be obtained by the HOPF and then placed in the REFER message to the ISCF.
  • This step and step 706 have no strict sequence relationship and can be performed simultaneously.
  • Step 708 After receiving the call transfer request (REFER), the target AG replies to the HOPF with a call transfer request accept (202 Accepted) message.
  • REFER call transfer request
  • the target AG replies to the HOPF with a call transfer request accept (202 Accepted) message.
  • Step 709 The target AG converts the call transfer request (REFER) into a handover request (RELOCATION REQUEST) message and sends it to the target RNC.
  • REFER call transfer request
  • RELOCATION REQUEST handover request
  • Step 710 After receiving the handover request, the target RNC starts the access network resource reservation process, and allocates corresponding radio resources for the UE1 to access the 3G network from the target RNC. The target RNC then sends a handover request response (RELOCATION REQUEST ACK) to the target MSC.
  • RELOCATION REQUEST ACK a handover request response
  • Step 711 After receiving the response, the target AG sends a notification message (NOTIFY) to the ISCF to notify the AG that the handover is ready.
  • NOTIFY notification message
  • Step 712 to step 713 after receiving the notification, the ISCF forwards the notification to the HOPF, and sends a notification confirmation message (200OK) to the target AG.
  • Steps 712 and 713 can be performed simultaneously, no Strict order relationship.
  • Step 714 After receiving the notification, the HOPF replies to the ISCF with a notification confirmation message (200OK).
  • the following steps 715-720 are processes in which the HOPF establishes an IP bearer with the target AG through the ISCF. There are many implementations of this process, and only one of the implementations described in this embodiment.
  • step 715 to step 716 involves the HOPF reserved resource, and sends a call invitation (INVITE) to the ISCF, where the SDP carries the media area resource information reserved by the local end.
  • the ISCF forwards the message to the target AG upon receipt.
  • step 717 to step 718 the target AG sends a response message (200OK) to the ISCF, and carries the media information of the local end, and the ISCF forwards the media information to the HOPF.
  • a response message 200OK
  • Step 719 to step 720 the HOPF sends a response confirmation message (ACK) to the ISCF, and the ISCF forwards it to the target AG.
  • ACK response confirmation message
  • Step 721 The HOPF sends a MAP ready handover response (MAP_Prepare_Handover_rsp) message to the source MSC, and carries parameters such as a handover number assigned by the HOPF.
  • MAP_Prepare_Handover_rsp MAP ready handover response
  • Step 722 to step 723 and step 734 are a process in which the source MSC establishes an inter-office bearer with the HOPF.
  • the source MSC and the HOPF can use the signaling such as ISUP or BICC to establish an inter-office bearer.
  • signaling such as ISUP or BICC to establish an inter-office bearer.
  • ISUP ISUP message
  • other signaling is similar.
  • Step 722 The source MSC sends an Initialization Address Message (IMM) to the HOPF.
  • IMM Initialization Address Message
  • Step 723 The HOPF sends an address full message (ACM) to the source MSC.
  • ACM address full message
  • Step 724 to step 726 after the source MSC receives the handover command, the source is sent to the source RNC.
  • the RNC forwards it to UE1. After receiving the handover command, UE1 switches to the target RNC.
  • Step 727 to step 728 UE1 switches to the target RNC, and UE1 starts to access the radio resource of the target RNC.
  • the RNC After detecting the UE1, the RNC sends a handover probe message (Relocation Detect) to the target AG.
  • the target RNC After receiving the handover success message sent by UE1, the target RNC sends a handover complete message (Relocation Complete) to the target AG.
  • Step 729 After receiving the handover complete message, the target AG sends a notification message ( NOTIFY ) to the ISCF to notify the ISCF that the handover has been completed.
  • Step 730 ⁇ Step 731 after receiving the notification message, the ISCF returns a confirmation message (200OK) to the target AG. Forward the notification message to HOPF. Steps 730-731 do not have a strict order relationship.
  • Step 732 to step 733 after receiving the notification message, the HOPF returns an acknowledgement message (200OK) to the ISCF, and sends a handover completion notification to the source MSC through the AP signaling.
  • the HOPF returns an acknowledgement message (200OK) to the ISCF, and sends a handover completion notification to the source MSC through the AP signaling.
  • Step 734 the HOPF sends an acknowledgement message (ANM) to the source MSC to connect to the interoffice circuit between the source MSC and the source MSC.
  • NAM acknowledgement message
  • Step 735 The source MSC notifies the source RNC to release the signaling link and the bearer resource.
  • UE1 completes the handover from the CS network to the above IP network.
  • FIG. 8 is a flowchart of Embodiment 5 of a handover method according to an embodiment of the present invention.
  • the main difference between this embodiment and the embodiment shown in FIG. 7 is that, in the process flow in FIG. 708), and establishing an IP bearer between the subsequent HOPF and the target AG is also implemented by using the ISCF as a proxy (see steps 714 to 720).
  • the address of the target AG is directly obtained by the HOPF, and the handover related message is directly sent by the HOPF to the target AG (see steps 805 to 806), and the IP bearer is directly established between the HOPF and the target AG. See steps 811 ⁇ 813).
  • the handover method of this embodiment specifically includes the following steps:
  • Step 801 to step 804 describe the process in which the source RNC sends a handover request to the source MSC, and the source MSC sends a preparation handover request to the HOPF, as in steps 701 to 704.
  • Step 805 After receiving the preparation handover request, the HOPF allocates the handover number, and obtains the target AG address according to the target cell and the operator policy or other suitable manner, and the HOPF will receive the
  • the MAP message is converted into a call transfer request (REFER) message and sent to the target AG.
  • the destination address (Refer-To) in the REFER message is filled in with the address of the target AG.
  • the message carries the handover related parameter, and the handover related parameter is mapped from the MAP preparation handover request message, and includes the target cell, the target RNC related information, and the codec related information.
  • Step 806 After receiving the call transfer request message, the target AG replies to the HOPF with a call transfer request accept (202 Accepted) message.
  • Step 807 The target AG simultaneously converts the call transfer request (REFER) into a handover request (RELOCATION REQUEST) message and sends it to the target RNC.
  • the target AG will REFER step 808.
  • the target RNC After receiving the handover request, the target RNC starts the access network resource reservation process, and allocates corresponding radio resources for the UE1 to access the 3G network from the target RNC.
  • the target RNC then sends a handover request response (RELOCATION REQUEST ACK) to the target AG.
  • Step 809 After receiving the handover request response, the target AG sends a notification message ( NOTIFY ) to the HOPF to notify the HOPF that the handover preparation is completed.
  • a notification message ( NOTIFY )
  • Step 810 After receiving the notification, the HOPF sends a notification confirmation message (200OK) to the target AG.
  • the following steps 811 to 813 are processes for establishing an IP bearer between the HOPF and the target AG. There are many implementations of this process, and only one of them is described in this embodiment.
  • Step 811 the HOPF reserves the resource, and sends a call invitation (INVITE) to the target AG.
  • the target AG reserves the resource, completes the media plane resource negotiation process with the HOPF, and then returns a response message (200OK) to the HOPF.
  • Step 813 The HOPF sends a response confirmation message (ACK) to the target AG.
  • ACK response confirmation message
  • Step 814 The HOPF sends a preparation handover response to the source MSC (MAP_Prepare_ Handover_rsp
  • the message carries the parameters such as the switch number assigned by HOPF.
  • Step 815 to step 821 is a process in which the source MSC establishes an inter-office bearer with the HOPF and a process in which the UE1 starts the handover, and the same steps 722 to 728 are performed.
  • Step 822 After receiving the handover complete message, the target AG sends a notification message ( NOTIFY ) to the HOPF to notify the HOPF that the handover has been completed.
  • a notification message ( NOTIFY )
  • step 823 to step 824 after receiving the notification message, the HOPF returns a confirmation message (200OK) to the target AG. And transmitting a handover completion notification to the source MSC through MAP signaling.
  • Step 825 The HOPF sends an acknowledgement message (ANM) to the source MSC to connect to the interoffice circuit between the source MSC and the source MSC.
  • NAM acknowledgement message
  • Step 826 The source MSC notifies the source RNC to release the signaling link and the bearer resource.
  • UE1 completes the handover from the CS network to the above IP network.
  • FIG. 9 is a flowchart of Embodiment 6 of a handover method according to an embodiment of the present invention.
  • the main difference between this embodiment and the embodiments involved in FIG. 7 and FIG. 8 is as follows: FIG. 7 and FIG.
  • the HOPF uses the REFER message to notify the target network element to perform the handover (see steps 705 and 805, respectively), and the subsequent HOPF establishes the IP bearer between the target and the target AG through the call invitation process (see steps 713 to 720, respectively). And, steps 811 to 813).
  • the embodiment in FIG. 9 uses the call invitation (INVITE) message to notify the target AG to perform handover (see step 905).
  • ISVITE call invitation
  • the IP bearer is established between the subsequent and the target AG through the message flow (step 905, step 908, step 917, Step 918), that is, the two processes of notifying the target network to perform handover and the IP bearer of the HOPF establishment target AG in the first two embodiments are separately implemented, and in the embodiment, the two processes are implemented by an INVITE process. .
  • the switching method of this embodiment specifically includes the following steps:
  • Step 901 to step 904 describe the process in which the source RNC sends a handover request to the source MSC, and the source MSC sends a preparation handover request to the HOPF, which is identical to steps 701 to 704.
  • the following steps 905, 908, 917, and 918 implement the notification target AG. Line switching, and the process of establishing an IP load with the target AG.
  • Step 905 After receiving the preparation handover request, the HOPF allocates the handover number, and obtains the target AG address according to the target cell and the operator policy or other suitable manner, and the HOPF converts the received MAP message into a call invitation message (INVITE) message.
  • the call invitation request message carries the handover identifier
  • the target AG can determine that the handover process is to be performed subsequently.
  • the INVITE message carries the handover related parameter, and the handover related parameter is mapped from the MAP preparation handover request message, and includes the target cell, the target RNC related information, and the codec related information.
  • the SDP of the INVITE message also carries the media plane resource information reserved by the HOPF.
  • Step 906 After receiving the INVITE message, the target AG sends a handover request RELOCATION REQUEST message to the target RNC, where the message carries the necessary handover related parameters.
  • Step 907 After receiving the handover request, the target RNC starts the access network resource reservation process, and allocates corresponding radio resources for the UE1 to access the 3G network from the target RNC. The target RNC then sends a handover request response (RELOCATION REQUEST ACK) to the target AG.
  • RELOCATION REQUEST ACK a handover request response
  • Step 908 After receiving the handover request response, the target AG sends a call progress message (183 Call Progress) to the HOPF, where the SDP of the message carries the media area resource information of the target AG.
  • a call progress message (183 Call Progress)
  • Step 909 After receiving the 183 message, the HOPF sends a MAP preparation handover response message (MAP_Prepare_Handover_rsp) to the source MSC, and carries parameters such as the handover number assigned by the HOPF.
  • MAP_Prepare_Handover_rsp MAP preparation handover response message
  • Step 910 After the source MSC receives the preparation handover request response, the source MSC starts and HOPF Establish inter-office bearer and notify UE1 to start handover.
  • Step 910 to step 916 are identical to steps 722 to 728.
  • Step 917 After receiving the handover complete message, the target AG sends an acknowledgement (ACK) message to the HOPF.
  • ACK acknowledgement
  • Step 918 After receiving the response message, the HOPF replies with a response confirmation message to the target AG.
  • Step 919 The HOPF sends a handover completion notification to the source MSC by using MAP signaling.
  • Step 920 The HOPF sends an acknowledgement message (ANM) to the source MSC to connect to the interoffice circuit between the source MSC and the source MSC.
  • NAM acknowledgement message
  • Step 921 The source MSC notifies the source RNC to release the signaling link and the bearer resource.
  • UE1 completes the handover from the CS network to the above IP network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

切换方法及系统 技术领域
本发明涉及在 IP多媒体子系统( IMS , IP Multimedia Subsystem ) 网络 架构中的切换技术,尤其涉及一种基于 IMS集中业务( ICS, IMS Centralized Service ) 的切换方法及切换系统。 背景技术
从电信网络的演进和发展来看, 核心网网络架构的发展呈现出两大趋 势: 一是网络的 IP ( Internet Protocol )化, 二是各种网络的融合。 因此未来 的核心网将不再分为电路交换(CS, Circuit Switched )域、 分组交换(PS, Packet Switching )域和 IMS等多种核心网, 而将会是一个基于 IP的统一的 业务控制系统, 所有的业务(包括语音业务、 补充业务和增值业务等)都 由该统一的业务控制系统来实现。
基于 IP的统一的业务控制系统(后文称为统一的 IP核心网)有两个特 点, 一是语音等业务的实现采用会话初始协议 ( SIP , Session Initiation Protocol ); 二是该业务控制系统与接入技术无关, 即用户可以通过 PS接入 也可以通过 CS接入。 这里的 PS接入方式指的是用户可以通过通用分组无 线业务( GPRS, General Packet Radio Service )、无线局域网( WLAN, Wireless Local Area Network )等分组网络接入到核心网。 而 CS接入方式指的是用户 是通过电路域无线接入网络如基站子系统( BSS, Base Station Subsystem ) 或无线网络子系统( RNS , Radio Network Subsystem )等设备接入到核心网。 不论是采用何种接入方式, 业务都由上述统一的 IP核心网提供。
图 1为采用 CS接入方式接入到统一的 IP核心网的应用场景示意图, 如图 1所示,用户设备 ( UE, User Equipment ) 101通过电路域接入网络(如 BSS或 RNS ) 102和信令适配设备 103接入到统一的 IP核心网 104中, 信 令适配设备 103起到必要的信令转换作用, 所有的业务由统一的 IP核心网 104提供。
图 2为 CS接入统一的 IP核心网的架构图, 如图 2所示, CS接入统一 的 IP核心网的架构包括以下网元: 用户设备 ( UE , User Equipment ) 201 , 基站控制器( BSC, Base Station Controller )或无线网络控制器( RNC, Radio Network Controller ) 202, 接入网关 (AG, Access Gateway ) 203, 综合业 务控制功能实体(ISCF, Integrated Service Control Function ) 204, 其中, BSC和 RNC202包含用于实现 CS域的用户接入和无线资源的管理和控制 等功能。 BSC和 AG203之间的接口采用基站子系统应用部分( BSSAP, Base Station System Application Part )信令进行通信, RNC和 AG203之间的接口 采用无线接入网络应用部分 ( RANAP, Radio Access Network Application Part )信令进行通信, BSSAP和 RANAP信令统称为 CS接入信令。 AG203 和设备 202之间的接口采用 CS接入信令进行通信, 和 ISCF之间的接口采 用 SIP协议进行通信, AG203实现 CS接入信令和 SIP消息之间的转换功能。 此外, AG还具备建立媒体面的承载、 实现媒体流的接续和处理等功能。 ISCF204实现移动性管理、 业务路由、 呼叫控制、 业务控制、 数据存储等功 能。 它可以由一个或多个功能实体来实现。
用户设备 UE 201通过 BSC或 RNC接入到 AG 203 , AG203接收到 BSC 或 RNC发送的 CS接入信令之后将其转换为 SIP信令发送给 ISCF204, 此 时 AG相当于充当用户代理,代替用户设备 201接入到 ISCF204,由 ISCF204 进行业务路由和呼叫控制, 由此用户 UE201可以和远端用户建立连接并进 行通话。
以上便是 CS接入到统一的 IP核心网的架构描述。 网络的演进和发展 必定需要 4艮长的时间, 因此, 上述 IP核心网不会在短时期内部署完成, 而 CS网络作为目前最主要和最完善的业务平台,也会在一定时期内长期存在, 因此必然会存在一段时期内 CS网络和上述背景网络共存的局面,在这段时 期内用户既可以接入 CS网络也可以接入上述 IP网络。
当 CS用户在通话过程中从上述 IP网络漫游到传统 CS网络或者从传统 CS网络漫游到上述 IP网络时,也就意味着用户的接入信道发生改变,此时 为了不中断通信需要核心网实现这两个异构网络间的切换业务。
上述 IP网络中的切换业务,其信令面的交互和媒体面的建立都采用 SIP 信令, 而 CS网络中的切换, 其切换消息的传递采用移动应用部分(MAP, Mobile Application Part )信令,媒体面是采用 ISDN的用户部分( ISUP, ISDN User Part )或与 载无关的呼叫控制( BICC, Bearer Independent Call Control ) 信令建立局间承载, 两个网络的切换业务的实现协议和方法截然不同, 因 此对于用户在上述 IP网络和 CS网络之间切换的情况, 需要重新考虑切换 消息的传递以及切换后的媒体面承载建立等问题。 发明内容
有鉴于此, 本发明的主要目的在于提供一种切换方法及切换系统, 能 实现 ICS增强网络对其他移动网络用户的通信业务兼容。
为达到上述目的, 本发明的技术方案是这样实现的:
一种切换方法, 包括:
源 AG接收到切换请求后, 通知切换代理功能实体(HOPF, Handover Proxy Function )进行异构网切换处理;
所述 HOPF通知目标移动交换中心 ( MSC, Mobile Switching Center ) 准备切换资源并建立切换所需承载;
所述源 AG通知源无线网络控制器( RNC , Radio Network Controller ) 进行切换。
优选地, 所述通知 HOPF进行异构网切换处理为: 所述源 AG判断当前切换为异构网切换后, 获取所述 HOPF的地址, 通过 SIP消息通知所述 HOPF进行异构网切换处理。
优选地, 所述 SIP消息中携带有切换的相关参数和 /或切换标识。
优选地, 所述 SIP消息中携带有切换的相关参数和 /或切换标识为: 所述 SIP消息的消息体中承载切换的相关参数和 /或切换标识。
优选地,所述切换的相关参数包括切换目标小区以及目标 RNC的信息、 所述源 AG支持的媒体编解码信息以及当前业务采用的编解码信息。
优选地, 所述 SIP消息中携带有切换的相关参数和 /或切换标识为: 所述 SIP消息的消息头中承载切换标识。
优选地 ,所述 SIP消息为转移请求 REFER消息 ,和 /或 ,呼叫邀请 INVITE 消息。
优选地, 所述 SIP消息的消息头中承载切换标识为:
对于所述 REFER消息 ,所述切换标识 载于所述 REFER消息的 Route 头域或 Request-URI头域中。
优选地, 所述通知 HOPF进行异构网切换处理为:
所述源 AG直接向所述 HOPF发送 SIP消息, 通知所述 HOPF进行异 构网切换处理;
或者, 所述 AG通过所述 ISCF向所述 HOPF发送 SIP消息, 通知所述 HOPF进行异构网切换处理。
优选地,所述 HOPF通知所述目标 MSC准备切换资源并建立切换所需 承载为:
所述 HOPF 向所述目 标 MSC 发送 MAP 准备切换请求 MAP_Prepare_Handover _req消息 , 所述 MAP_Prepare_Handover _req消息 中携带有所述 HOPF所接收到的由所述源 AG发送的所述 SIP消息中的切 优选地,所述 MAP_Prepare_Handover _req消息中携带有切换的相关参 数为:
所述 HOPF将由所述源 AG发送的所述 SIP消息中的切换的相关参数 的目标小区参数映射为所述 MAP_Prepare_Handover _req 消息中的 Target Cell Id参数, 将目标 RNC参数映射为所述 MAP_Prepare_Handover _req消 息中的 Target RNC Id参数。
优选地, 所述 HOPF通知目标 MSC准备切换资源并建立切换为: 所述目标 MSC接收到所述 MAP_Prepare_Handover _req消息后, 向所 述目标 RNC发送切换请求;所述目标 MSC接收到所述目标 RNC的切换请 求响应后, 向所述 HOPF发送 MAP准备切换请求响应消息;
所述 HOPF接收到所述目标 MSC发送的 MAP准备切换请求响应后, 同所述目标 MSC建立局间承载, 并通过初始化地址消息 IAM通知所述目 标 MSC建立局间^ ^载;
所述目标 MSC与所述 HOPF建立局间承载后, 通过地址全消息 ACM 通知所述 HOPF。
优选地, 所述方法还包括:
所述 HOPF接收到所述 ACM消息后,通过 SIP消息建立与待切换用户 设备 UE会话的对端 UE或目标 AG之间的 IP承载, 并通过 SIP消息通知 所述 ISCF或所述源 AG切换准备完成。
优选地, 所述方法还包括:
所述 HOPF接收到所述 ACM消息后,向所述源 AG发送 SIP消息通知 呼叫进展, 其中, 通知呼叫进展的 SIP消息为呼叫进展消息 183 , 所述呼叫 进展消息 183中的会话描述协议 SDP字段中携带所述 HOPF预留的媒体面 资源信息。
优选地,所述 HOPF通知目标 MSC准备切换资源并建立切换所需承载 为:
所述 HOPF接收到通知进行异构网切换的 SIP消息后,向所述目标 MSC 发送 MAP_Prepare_Handover _req消息; 其中, 所述 HOPF将所接收到的所 述通知进行异构网切换的 SIP 消息中的切换的相关参数映射成所述 MAP_Prepare_Handover _req消息中的对应参数。
优选地, 所述切换的相关参数包括目标小区和目标 RNC相关信息以及 当前业务采用的编解码信息。
优选地, 所述 HOPF通过 SIP消息通知所述 ISCF所述源 AG切换准备 建立完成后, 通知所述源 AG切换准备完成。
一种切换方法, 包括:
源 MSC接收到切换请求后, 通知 HOPF准备切换;
所述 HOPF通知目标 AG准备切换资源并建立 IP承载;
所述 HOPF通知所述源 MSC切换准备完成, 所述源 MSC通知源 RNC 进行切换。
优选地, 所述通知 HOPF准备切换为:
源 MSC 获取所述 HOPF 的地址信息, 向所述 HOPF 发送 MAP_Prepare_Handover_req消息 ,所述 MAP_Prepare_Handover_req消息中 携带有切换相关参数, 所述切换的相关参数包括切换目标小区以及目标 RNC的信息、 所述源 AG支持的媒体编解码信息以及当前业务采用的编解 码信息。
优选地, 所述 HOPF通知目标 AG准备切换资源并建立 IP 载为: 所述 HOPF接收到所述源 MSC的 MAP_Prepare_Handover_req消息后, 获取所述目标 AG 的地址信息以及切换相关参数, 将所述切换相关参数映 射到通知所述目标 AG准备切换的 SIP消息中并发送给所述目标 AG,通知 所述目标 AG准备切换。
优选地, 所述通过 SIP消息通知所述目标 AG准备切换为:
所述 HOPF直接向所述目标 AG发送 SIP消息,通知所述目标 AG准备 切换;
或者, 所述 HOPF通过 ISCF向所述目标 AG发送 SIP消息, 通知所述 目标 AG准备切换;其中,通知的 SIP消息中携带切换相关参数和切换标识。
优选地, 所述 HOPF通知目标 AG准备切换资源并建立 IP承载为: 所述目标 AG接收到准备切换的通知后, 向目标 RNC发送切换请求消 息 RELOCATION REQUEST, 通知目标 RNC准备无线侧资源;
所述目标 AG接收到所述目标 RNC的切换请求响应后, 通过 SIP消息 通知所述 HOPF或所述 ISCF无线侧资源准备完成。
优选地, 所述方法还包括:
所述 HOPF采用 REFER消息通知所述目标 AG准备切换时,所述 HOPF 在接收到切换准备完成通知 NOTIFY消息后与所述目标 AG之间建立 IP承 载;
所述 HOPF采用 INVITE消息通知所述目标 AG准备切换时,所述 HOPF 与所述目标 AG之间的 IP承载在所述 INVITE会话过程中建立。
优选地, 所述方法还包括:
所述 HOPF通过 INVITE消息直接或间接与所述目标 AG之间建立 IP 承载。
优选地, 所述方法还包括:
所述 HOPF与所述目标 AG之间建立 IP 载后, 所述 HOPF通过 MAP_Prepare_ Handover_rs 消息通知所述源 MSC切换准备完成; 其中, 所述 MAP_Prepare_ Handover_rs 消息中携带所述 HOPF分配的切换号码。
优选地, 所述方法还包括: 所述源 MSC接收到所述 HOPF的切换准备完成通知后, 与所述 HOPF 建立局间承载, 并通过 IAM通知所述 HOPF建立局间承载;
所述 HOPF接收到所述 IAM后,预留资源并同源 MSC建立局间承载, 向所述源 MSC发送 ACM消息;
所述源 MSC接收到 ACM消息后, 向所述源 RNC发送切换命令。 一种切换系统, 应用于无线通信系统中, 所述切换系统包括源 AG、 源 RNC、 目标 RNC、 目标 MSC、 目标 AG、 待切换 UE和与待切换 UE会话 的对端 UE, 其中:
源 AG, 用于接收到切换请求后, 通知 HOPF进行异构网切换处理; 以 及, 在接收到切换准备完毕通知后, 通知源 RNC进行切换;
HOPF, 用于接收到所述源 AG的异构网切换通知后, 通知目标 MSC 准备切换资源并建立切换所需承载。
优选地, 所述源 AG, 进一步用于直接向所述 HOPF发送 SIP消息, 通 知所述 HOPF进行异构网切换处理;
或者, 所述 AG, 进一步用于通过所述 ISCF向所述 HOPF发送 SIP消 息, 通知所述 HOPF进行异构网切换处理。
优选地 , 所述 HOPF 进一 步 向 所述 目 标 MSC 发送 MAP_Prepare_Handover _req消息 , 所述 MAP_Prepare_Handover _req消息 中携带有所述 HOPF所接收到的由所述源 AG发送的所述 SIP消息中的切 换的相关参数。
优选地, 所述目标 MSC在接收到所述 MAP_Prepare_Handover _req消 息后, 进一步向所述目标 RNC发送切换请求;
所述目标 MSC接收到所述目标 RNC的切换请求响应后, 进一步向所 述 HOPF发送 MAP准备切换请求响应消息;
所述 HOPF接收到所述目标 MSC发送的 MAP准备切换请求响应后, 进一步同所述目标 MSC建立局间承载, 并通过初始化地址消息 IAM通知 所述目标 MSC建立局间承载;
所述目标 MSC与所述 HOPF建立局间承载后, 进一步通过 ACM通知 所述 HOPF。
优选地, 所述 HOPF在接收到所述 ACM消息后, 进一步通过 SIP消息 建立与待切换用户设备 UE会话的对端 UE或目标 AG之间的 IP承载, 并 通过 SIP消息通知所述 ISCF或所述源 AG切换准备完成。
一种切换系统, 应用于无线通信系统中, 所述切换系统包括源 AG、 源 RNC、 目标 RNC、 目标 MSC、 目标 AG、 待切换 UE和与待切换 UE会话 的对端 UE, 其特征在于:
源 MSC, 用于接收到切换请求后, 通知 HOPF准备切换; 以及在接收 到 HOPF的切换准备完成后通知源 RNC进行切换;
HOPF, 用于接收到准备切换通知后, 通知目标 AG准备切换资源并建 立 IP承载; 以及, 通知所述源 MSC切换准备完成。
优选地, 所述源 MSC进一步用于获取所述 HOPF的地址信息, 向所述 HOPF 发 送 MAP_Prepare_Handover_req 消 息 , 所 述 MAP_Prepare_Handover_req消息中携带有切换相关参数, 所述切换的相关 参数包括切换目标小区以及目标 RNC的信息、 所述源 AG支持的媒体编解 码信息以及当前业务采用的编解码信息。
优 选 地 , 所 述 HOPF 在 接 收 到 所 述 源 MSC 的 MAP_Prepare_Handover_req消息后, 进一步获取所述目标 AG的地址信息 以及切换相关参数, 将所述切换相关参数映射到通知所述目标 AG准备切 换的 SIP消息中并发送给所述目标 AG, 通知所述目标 AG准备切换。
优选地, 所述 HOPF直接向所述目标 AG发送 SIP消息, 通知所述目 标 AG准备切换; 或者, 所述 HOPF通过 ISCF向所述目标 AG发送 SIP消息, 通知所述 目标 AG准备切换;其中,通知的 SIP消息中携带切换相关参数和切换标识。
优选地, 所述目标 AG接收到准备切换的通知后, 向目标 RNC发送切 换请求消息 RELOCATION REQUEST, 通知目标 RNC准备无线侧资源; 所述目标 AG接收到所述目标 RNC的切换请求响应后, 通过 SIP消息 通知所述 HOPF或所述 ISCF无线侧资源准备完成。
优选地, 所述 HOPF采用 REFER消息通知所述目标 AG准备切换时, 所述 HOPF在接收到切换准备完成通知 NOTIFY消息后与所述目标 AG之 间建立 IP ^I载;
所述 HOPF采用 INVITE消息通知所述目标 AG准备切换时,所述 HOPF 与所述目标 AG之间的 IP承载在所述 INVITE会话过程中建立。
优选地, 所述 HOPF与所述目标 AG之间建立 IP承载后, 所述 HOPF 通过 MAP_Prepare_ Handover_rs 消息通知所述源 MSC切换准备完成; 其 中,所述 MAP_Prepare_ Handover_rs 消息中携带所述 HOPF分配的切换号 码。
优选地, 所述源 MSC接收到所述 HOPF的切换准备完成通知后, 与所 述 HOPF建立局间承载, 并通过 IAM通知所述 HOPF建立局间承载;
所述 HOPF接收到所述 IAM后,预留资源并同源 MSC建立局间承载, 向所述源 MSC发送 ACM消息;
所述源 MSC接收到 ACM消息后, 向所述源 RNC发送切换命令。 本发明中, 源 AG接收到切换请求后, 通知 HOPF进行异构网切换处 理; HOPF通知目标 MSC准备切换资源并建立切换所需^ ^载; 源 AG通知 源无线网络控制器 RNC进行切换。 以及, 源 MSC接收到切换请求后, 通 知 HOPF准备切换; HOPF通知目标 AG准备切换资源并建立 IP承载; HOPF 通知所述源 MSC切换准备完成, 源 MSC通知源 RNC进行切换。相对于现 有技术, 本发明简化了切换消息流程, 相对于现有技术, 提高了系统切换 的效率, 用户不会感觉到业务切换的异常, 不会存在切换震荡问题, 提升 了业务的用户体验效果。 附图说明
图 1为采用 CS接入方式接入到统一的 IP核心网的应用场景示意图; 图 2为 CS接入统一的 IP核心网的架构图;
图 3为本发明切换的系统的组成结构示意图;
图 4为本发明实施例的切换方法实施例一的流程图;
图 5为本发明实施例的切换方法实施例二的流程图;
图 6为本发明实施例的切换方法实施例三的流程图;
图 7为本发明实施例的切换方法实施例四的流程图;
图 8为本发明实施例的切换方法实施例五的流程图;
图 9为本发明实施例的切换方法实施例六的流程图。 具体实施方式
本发明的基本思想是,当源 SA接收到源 RNC的切换请求后,通过 SIP 消息通知目标 SA为待切换 UE准备资源; 接收到到 SIP消息后, 目标 SA 为待切换 UE准备资源, 并建立与源 SA之间的承载, 之后通知源 SA切换 准备完毕; 源 SA通知待切换 UE切换到目标网络。
为使本发明的目的、 技术方案和优点更加清楚明白, 以下举实施例并 参照附图, 对本发明进一步详细说明。
图 3为本发明切换的系统的组成结构示意图, 如图 3所示, 本发明切 换的系统包括: IP网络发起切换的网元、 HOPF和切换到的目标 MSC。 上 述 IP网络发起切换的网元, 具体网元可以是 ISCF或 AG等, 可获知切换 请求并判断出是要切换到 CS域, 并根据运营商策略选择合适的 HOPF, 将 该请求发送给 HOPF。 上述 HOPF是新增的一个逻辑网元, 位于 IP网络和 CS网络之间,可在 IP网络和 CS网络之间实现切换相关的 SIP协议和 MAP 信令之间的相互转换功能,即对 IP网络是终结 SIP信令并将其转换成 MAP 信令发送给 CS域相关网元,对 CS网络是终结 MAP信令并将其转换成 SIP 信令发送给 IP网络的相关网元, 同时 HOPF还可作为代理网元控制两个网 络之间的切换流程。
本发明切换的系统中各网元的功能及各网元之间交互而实现的各种功 能, 通过下述流程而描述。 本领域技术人员应当理解, 通过下述图 4至图 9 的描述, 本发明切换的系统中各组成网元以及各网元所能实现的功能, 是 容易理解的。
上述目标 MSC, 为现有的 MSC, 可以接收 HOPF发送的切换请求, 并 执行切换业务。
本发明中涉及的异构网的切换业务分为两个不同的业务场景, 分别是 用户从 IP网络切换到 CS网络和用户从 CS网络切换到 IP网络。 这两个业 务场景的实现流程也不同, 为了使本发明的目的、 技术方案和优点更加清 楚, 下面结合附图和具体实施例分别对这两种业务场景的实现方法进行描 述。
图 4至图 6均为本发明实施例提供的 IP网络切换到 CS网络的流程图。 在本发明所示的上述流程图中, UE1和 UE2是通话的双方, UE1在通话过 程中从上述 IP核心网切换到 CS核心网, 源 RNC、 源 AG和源 ISCF分别 是 UE1在切换前的 RNC、 AG和 ISCF, 目标 MSC和目标 RNC是 UE1要 切换到的目标网络的 MSC和 RNC, HOPF是进行异构网切换时要用到的切 换代理服务器。 以下通过下述的切换过程, 进一步阐明上述网元的功能以 及这些网元之间的消息交互及处理方式。
图 4为本发明实施例的切换方法实施例一的流程图, 如图 4所示, 本 示例的切换方法具体包括以下步驟:
步驟 401 , UE向源 RNC发送测量 4艮告 ( Measurement Report )。
步驟 402, 源 RNC根据测量报告, 判定 UE1需要进行切换。
步驟 403 ,源 RNC向源 AG发送切换请求( RELOCATION REQUIRED ), 携带切换到的目标小区等参数。
步驟 404, 源 AG获取切换请求中的目标小区等切换参数, 根据目标小 区及运营商策略或其他可行方法判断出用户需要切换到 CS网络后, 源 AG 根据运营商配置策略选择合适的 HOPF,并将接收到的切换请求转换成呼叫 转移请求(REFER )发送给 ISCF, 消息中携带相关的切换参数, 包括目标 小区和目标 RNC相关信息、 用户号码、 所述 AG支持的媒体编解码相关信 息等。 REFER消息中携带切换标识, 可在 Refer-to头域的 method参数中携 带,例如采取如下格式: method=handover。 REFER消息中携带 HOPF地址, 可在 Request-URI头域中携带, 即 Request-URI头域填写 HOPF地址。
步驟 405, ISCF接收到 REFER后向源 AG回复呼叫转移请求接受消息 ( 202 Accepted )。
步驟 406, ISCF将 REFER消息转发给该 HOPF。
步驟 407, HOPF接收到 REFER请求后, 向 ISCF回复 202 Accepted 消息。
步驟 408, HOPF根据 REFER消息中的切换标识判断需要进行切换, HOPF获取目标 MSC ,并产生 MAP准备切换请求( MAP_Prepare_Handover _req ), 同时将获取到的 REFER消息中的切换相关参数映射成 MAP消息准 备切换请求 ( MAP_Prepare_Handover _req消息) 中对应的参数, 具体映射 方法可以参照消息中各参数的具体含义,例如将 REFER消息中携带的目标 'J、区参数映射成 MAP准备切换请求中的 Target Cell Id参数, 目标 RNC参 数映射成 MAP准备切换请求中的 Target RNC Id参数。 当然需要映射的参 数不限于该参数, 但都可采取上述方法按照参数的含义进行对应的映射。 之后 HOPF将准备切换请求消息发送给目标 MSC。
HOPF获取目标 MSC的方法可以是根据目标小区和运营商配置策略进 行选择, 当然也可以采用其他可行的方式。
步驟 409, 目标 MSC接收到准备切换请求后, 分配切换号码, 同时向 目标 RNC发送切换请求( RELOCATION REQUEST )。
步驟 410, 目标 RNC接收到切换请求后开始接入网资源预留过程, 为 UE1从目标 RNC接入 3G网络分配相应的无线资源。 之后目标 RNC向目 标 MSC发送切换请求响应 ( RELOCATION REQUEST ACK )。
步驟 411 , 目标 MSC接收到切换请求响应后向 HOPF发送准备切换请 求响应 ( MAP_Prepare_Handover_rsp )。
步驟 412, HOPF接收到准备切换请求响应后开始和目标 MSC建立局 间承载。 HOPF向目标 MSC发送初始化地址( IAM ) 消息。
步驟 413 , 目标 MSC向 HOPF发送地址全( ACM ) 消息
步驟 414, HOPF接收到地址全消息后, 即知切换准备完毕, HOPF将 其转化成通知(NOTIFY )消息发送给 ISCF, 通知 ISCF切换准备完毕。 切 换准备完成的标识可以放在 NOTIFY的 Subscription-State头域的 reason参 数中携带。
步驟 415, ISCF接收到通知消息后,向 HOPF回复确认消息(200OK )。 以下步驟 416~步驟 421涉及的处理流程,是 UE2更新远端媒体的过程, 该过程有多种实施方式, 本示例仅示意出了其中的一种, 并非用于对本发 明的限定。
步驟 416, ISCF向 HOPF发起呼叫邀请( INVITE ),在 SDP中携带 UE2 的媒体信息。
步驟 417, HOPF将远端媒体面信息更新为 UE2的媒体信息, 之后向 ISCF发送应答消息(200OK ), 消息中携带预留的本端媒体信息。
步驟 418, ISCF向 HOPF发送应答确认消息( ACK )。
步驟 419, ISCF向 UE2发起呼叫重邀请 ( REINVITE ), 在 SDP中携带
HOPF的媒体信息。
步驟 420, UE2将远端媒体面信息更新为 HOPF的媒体信息, 之后向
ISCF发送应答消息(200OK ), 消息中携带本端媒体信息。
步驟 421 , ISCF向 UE2发送应答确认消息 ( ACK )。
上述步驟 416与步驟 415无严格顺序关系, 可以同时进行。
步驟 422, ISCF向 AG发送通知消息 ( NOTIFY ), 通知源 AG切换准 备完毕。
步驟 423 , AG接收到通知消息后, 向 ISCF回复确认消息(200OK )。 步驟 424, AG向源 RNC发送切换命令 ( Relocation Command )。
步驟 425 , 源 RNC向 UE1转发切换命令。
步驟 426, 目标 RNC切换, UE1开始访问目标 RNC的无线资源。 步驟 427, RNC检测到 UE1 之后, 向目标 MSC发送切换探测消息
( Relocation Detect )。
步驟 428, 目标 RNC接收到 UE1发送的切换成功消息之后, 向目标 MSC换完成消息 ( Relocation Complete )。
步驟 429, 目标 MSC通过 MAP消息向 HOPF通知切换完成。
步驟 430, 目标 MSC向 HOPF发送应答消息( ANM ), 接通目标 MSC 和 HOPF之间的局间承载。
步驟 431 , HOPF向 ISCF发送通知消息(NOTIFY ), 通知 ISCF切换 已完成。 切换完成的标识可以放在 NOTIFY 的 Subscription-State 头域的 reason参数中携带。
步驟 432, ISCF接收到通知消息后,向 HOPF回复确认消息( 200OK )。 步驟 433 , ISCF向 AG转发通知消息( NOTIFY )通知 AG切换已完成, 并释放和 AG在切换前建立的会话。
步驟 434, AG接收到通知消息后, 向 ISCF回复确认消息(200OK )。 步驟 435 , AG通知源 RNC释放信令链接和承载资源。
通过以上步驟, UE1完成了从上述 IP网络到 CS网络的切换过程。 图 5为本发明实施例的切换方法实施例二的流程图, 如图 5所示, 本 实施例与上述图 4 中的实施例一的主要区别在于, 实施例一中切换相关的 消息是由 AG通过 ISCF发给 HOPF (见步驟 404~步驟 407 ), 而实施例二 中切换相关的消息是由 AG直接发给 HOPF (见步驟 504~步驟 505 )。此外, 实施例二中 UE2进行远端媒体面更新的过程采用了与实施例一中不同的实 施方式(见步驟 416~步驟 421和步驟 512~步驟 517 )。
如图 5所示, 本发明示例的切换方法具体包括以下步驟:
步驟 501~步驟 503, AG接收到切换请求的过程, 同前述步驟 401~步 驟 403 。
步驟 504, AG获取切换请求中的目标小区等切换参数, 根据目标小区 及运营商策略或其他可行方法判断出用户需要切换到 CS网络后, AG根据 运营商配置策略选择合适的 HOPF,并将接收到的切换请求转换成呼叫转移 请求(REFER )发送给 HOPF, 消息中携带相关的切换参数, 如包括目标 小区和目标 RNC相关信息、 用户号码、 所述 AG支持的媒体编解码相关信 息等。 REFER消息中携带切换标识, 可在 Refer-to头域的 method参数中携 带,例如采取如下格式: method=handover。 REFER消息中携带 HOPF地址, 可在 Request-URI头域中携带, 即 Request-URI头域填写 HOPF地址。
步驟 505, HOPF接收到 REFER后向 AG回复呼叫转移请求接受消息 ( 202 Accepted )。
步驟 506~步驟 511 , 目标网络进行切换准备及资源预留的过程, 同步 驟 408-413。
以下步驟 512~步驟 517是 UE2更新远端媒体的过程,该过程有多种实 施方式, 这里列出的只是其中一种。
步驟 512 , HOPF获取 AG发送的 REFER消息中的 ISCF地址,向该 ISCF 发起呼叫邀请(INVITE ), 在 SDP 中携带本端的媒体信息。 其中 INVITE 消息中携带切换标识和 UE1的号码用来通知 ISCF用户终端 UE1发起切换 业务。切换标识的携带方式可以采取通过在 Request-URI头域中增加扩展的 方式, 例如 Request-URI可以采取如下格式: 目标地址; method = handover。 这里的 method = handover就是切换标识。当然切换标识的携带有多种方式, 以上只是给出一个例子, 但不限于此。 UE1的号码也可以放在 Request-URI 中通过参数扩展的方式携带,例如可以采取如下格式: userNumber = XXXX。
步驟 513 , ISCF向 UE2发起呼叫重邀请(REINVITE ), 在 SDP中携带 HOPF的媒体信息。
步驟 514 , UE2接收到 REINVITE后, 将远端媒体面信息更新为 HOPF 的媒体信息, 之后向 ISCF发送应答消息 (200OK ), 消息中携带本端媒体 信息。
步驟 515 , ISCF接收到应答后, 向 UE2发送应答确认消息( ACK )。 步驟 516 , ISCF获取应答消息中的 UE2媒体信息, 向 HOPF发送应答 消息 ( 200OK ) , 其中携带 UE2的媒体信息。
步驟 517 , HOPF将远端的媒体信息更新为 UE2的媒体信息, 之后向 ISCF发送应答确认消息 ( ACK )。
步驟 518 , HOPF 接收到应答确认消息后, 向 AG 发送通知消息 ( NOTIFY ) , 通知源 AG 切换准备完毕。 切换准备完成的标识可以放在 NOTIFY的 Subscription-State头域的 reason参数中携带。
步驟 519 , AG接收到通知消息后, 向 HOPF回复确认消息( 200OK )。 步驟 520~步驟 526, 描述的是核心网通知 UE1进行切换并在切换完成 后通知 HOPF的过程, 同前述步驟 424~步驟 430。
步驟 527, HOPF接收到携带切换完成信息的 MAP消息之后, 向 AG 发送通知消息 (NOTIFY ), 通知 AG切换已完成, 并释放和 AG在切换前 建立的会话。 切换完成的标识可以放在 NOTIFY的 Subscription-State头域 的 reason参数中携带。
步驟 528, AG接收到通知消息后, 向 HOPF回复确认消息(200OK )。 步驟 529, AG通知源 RNC释放信令链接和承载资源。
经过上述过程, UE1完成了从上述 IP网络到 CS网络的切换。
图 6为本发明实施例的切换方法实施例三的流程图, 如图 6所示, 本 实施例与前述图 4图以及 5 中所示的两个实施例的主要区别在于: 前两个 实施例中 AG或 ISCF是采用 REFER消息通知 HOPF进行切换(见步驟 406 和步驟 504 ), 而本实施例是采用 INVITE消息通知 HOPF进行切换(见步 驟 604 ); 前两个实施例中切换后的媒体流是锚定在 HOPF上, 且不再经过 源 AG (步驟 416~步驟 421 , 以及, 步驟 512~步驟 517 ), 而本实施例是将 切换后的媒体流锚定在 AG上, 即切换后 UE1发出的媒体流是通过 HOPF 和 AG再发给 UE2 (步驟 612~步驟 614 )。
如图 6所示, 本实施例的切换方法具体包括以下步驟:
步驟 601~步驟 603, AG接收到切换请求的过程,同步驟 401~步驟 403 。 步驟 604 , AG获取切换请求中的目标小区等切换参数, 根据目标小区 及运营商策略或其他可行方法判断出用户需要切换到 CS网络后, AG根据 运营商配置策略选择合适的 HOPF,并将接收到的切换请求转换成呼叫邀请 请求(INVITE )发送给该 HOPF, 消息中携带相关的切换参数, 包括目标 小区和目标 RNC相关信息、 用户号码、 所述 AG支持的媒体编解码相关信 息等。 消息中携带切换标识, 切换标识的携带方式可以采取通过在 Request-URI头域中增加扩展的方式,例如 Request-URI可以采取如下格式: 目标地址; method = handover。 这里的 method = handover就是切换标识。 当然切换标识的携带有多种方式, 以上只是给出一个例子, 但不限于此。 REFER 消息中携带 HOPF 地址, 可在 Request-URI 头域中携带, 即 Request-URI头域填写 HOPF地址。 此外, INVITE消息的 SDP中还携带 AG预留的媒体面资源信息。
步驟 605, HOPF接收到 INVITE后, 根据其中的切换标识判断需要进 行切换, HOPF 获取目 标 MSC , 并产生 MAP 准备切换请求 ( MAP_Prepare_Handover_req ), HOPF将获取到的 INVITE消息中的切换 相关参数映射成 MAP消息准备切换请求中对应的参数,具体映射方法可以 参照消息中各参数的具体含义,例如将 INVITE消息中携带的目标小区参数 映射成 MAP准备切换请求中的 Target Cell Id参数, 将目标 RNC参数映射 成 MAP准备切换请求中的 Target RNC Id参数。 当然需要映射的参数不限 于该参数, 但都可采取上述方法按照参数的含义进行对应的映射。 之后 HOPF将准备切换请求消息发送给目标 MSC。
HOPF获取目标 MSC的方式可以是由 AG选择之后放在 INVITE消息 中带给 HOPF,也可以是 HOPF自身根据目标小区和运营商配置策略进行选 择。
步驟 606~步驟 610, 同步驟 507~步驟 511。
步驟 611 , HOPF接收到地址全消息( ACM )之后, 向 AG发送呼叫进 展消息(183 Call Progress )。 此外, 183消息的 SDP中还携带 HOPF预留的 媒体面资源信息。
步驟 612 , AG接收到呼叫进展消息后, 向源 RNC 发送切换命令 ( Relocation Command )。
步驟 613~步驟 618, 同步驟 521~步驟 526。 步驟 619, HOPF接收到目标 MSC发送的应答消息( ANM )后, 向 AG发送应答消息(200OK )。
步驟 620 , AG 接收到应答消息后, 向 HOPF 回复应答确认消息 ( 200OK )。
步驟 621 , AG通知源 RNC释放信令链接和承载资源, 并通知 ISCF用 户设备 UE1已经切换到目标网络。
经过上述过程, UE1完成了从上述 IP网络到 CS网络的切换。
图 7至图 9是本发明实施例提供的 CS网络切换到 IP网络的流程图, 在所述流程图中 UE1和 UE2是通话的双方, UE1在通话过程中从上述 CS 核心网切换到 IP核心网, 源 RNC、 源 MSC都是 UE1在切换前的 RNC和 MSC, ISCF、 目标 AG和目标 RNC是 UE1要切换到的目标网络的 ISCF、 AG和 RNC, HOPF是进行异构网切换时要用到的切换代理服务器。
图 7为本发明实施例的切换方法实施例四的流程图, 如图 7所示, 本 实施例的切换方法具体包括以下步驟:
步驟 701 , UE向源 RNC发送测量报告 ( Measurement Report )。
步驟 702, 源 RNC根据测量报告, 判定 UE1需要进行切换。
步驟 703 , 源 RNC 向源 MSC 发送切换请求 ( RELOCATION REQUIRED )0
步驟 704, 源 MSC接收到切换请求后, 根据目标小区判断出是需要切 换到 IP网络, 并根据目标小区信息和运营商策略选择合适的 HOPF, 向该 HOPF发送 MAP准备切换请求( MAP_Prepare_Handover_req ), 消息中携 带切换相关参数,如目标小区、 目标 RNC相关信息以及编解码相关信息等。
步驟 705, HOPF接收到准备切换请求后, 分配切换号码, 并根据目标 小区和运营商策略或其他合适的方式选择目标 ISCF和目标 AG, HOPF将 接收到的 MAP消息转换成呼叫转移请求( REFER )消息发送给目标 ISCF, REFER消息中要求联系的目的地址( Refer-To )头域中填写的是目标 AG的 地址, 消息中携带切换标识, 如 method=handover。 消息中携带切换相关参 数,切换相关参数是从 MAP准备切换请求消息中映射而来,包含目标小区、 目标 RNC相关信息以及编解码相关信息等。切换相关参数携带的方法不限, 可以放在 REFER的 SDP ( Session Description Protocol, 会话描述协议 ) 中 通过 XML ( extensible markup language, 可扩展标记语言 )扩展携带等。
步驟 706, ISCF接收到呼叫转移请求消息后向 HOPF回复呼叫转移请 求接受 ( 202 Accepted ) 消息。
步驟 707, ISCF获取目标 AG地址, 向目标 AG转发呼叫转移请求 ( REFER )。 ISCF获取目标 AG的方法可以是根据 REFER消息中携带的目 标小区或目标 RNC信息及运营商策略获取目标 AG, 也可以是 HOPF获取 后放在 REFER消息中带给 ISCF。 该步驟与步驟 706无严格的先后顺序关 系, 可以同时进行。
步驟 708 , 目标 AG接收到呼叫转移请求( REFER )后向 HOPF回复呼 叫转移请求接受( 202 Accepted ) 消息。
步驟 709 , 目标 AG 将呼叫转移请求 (REFER ) 转换成切换请求 ( RELOCATION REQUEST )消息, 向目标 RNC发送。 目标 AG将 REFER 消息转换成 RELOCATION REQUEST的方法是现有技术, 在此不赘述。
步驟 710, 目标 RNC接收到切换请求后开始接入网资源预留过程, 为 UE1从目标 RNC接入 3G网络分配相应的无线资源。 之后目标 RNC向目 标 MSC发送切换请求响应 ( RELOCATION REQUEST ACK )。
步驟 711 , 目标 AG接收到该响应后向 ISCF发送通知消息(NOTIFY ), 通知 AG切换准备完毕。
步驟 712~步驟 713, ISCF接收到通知后将通知转发给 HOPF, 并向目 标 AG发送通知确认消息 (200OK )。 步驟 712和 713可以同时进行, 没有 严格的先后顺序关系。
步驟 714, HOPF接收到通知后向 ISCF回复通知确认消息( 200OK )。 下面的步驟 715-720是 HOPF通过 ISCF与目标 AG建立 IP承载的过程。 该过程有多种实现方式, 本实施例中描述的仅是其中一种实现方式。
步驟 715~步驟 716涉及的流程, 涉及的是 HOPF预留资源, 向 ISCF 发送呼叫邀请(INVITE ), SDP 中携带本端预留的媒体面资源信息。 ISCF 接收到后将该消息转发给目标 AG。
步驟 717~步驟 718, 目标 AG向 ISCF回复应答消息 ( 200OK ), 携带 本端的媒体信息, ISCF将其转发给 HOPF。
步驟 719~步驟 720, HOPF向 ISCF发送应答确认消息 (ACK ), ISCF 将其转发给目标 AG。
步驟 721 , HOPF向源 MSC发送 MAP准备切换响应 ( MAP_Prepare_ Handover_rsp ) 消息, 携带 HOPF分配的切换号码等参数。
步驟 722~步驟 723及步驟 734是源 MSC与 HOPF建立局间承载的过 程, 源 MSC与 HOPF之间可以采用 ISUP或 BICC等信令建立局间承载, 根据采用的不同信令消息流程会有所不同,这里以 ISUP消息为例这个局间 承载建立的过程和原理, 其他信令也类似。
步驟 722, 源 MSC向 HOPF发送初始化地址消息 ( IAM )。
步驟 723 , HOPF向源 MSC发送地址全消息 ( ACM )。
步驟 724~步驟 726, 源 MSC接收到之后向源 RNC发送切换命令, 源
RNC将其转发给 UE1。 UE1接收到切换命令后向目标 RNC进行切换。
步驟 727~步驟 728, UE1向目标 RNC切换, UE1开始访问目标 RNC 的无线资源。 RNC 检测到 UE1 之后, 向目标 AG 发送切换探测消息 ( Relocation Detect )。 目标 RNC接收到 UE1发送的切换成功消息之后, 向 目标 AG发送切换完成消息( Relocation Complete )。 步驟 729, 目标 AG接收到切换完成消息之后向 ISCF发送通知消息 ( NOTIFY ), 通知 ISCF切换已完成。
步驟 730~步驟 731 , ISCF接收到通知消息后, 向目标 AG回复确认消 息(200OK )。 并将通知消息转发给 HOPF。 步驟 730-731没有严格的顺序 关系。
步驟 732~步驟 733 , HOPF接收到通知消息之后向 ISCF回复确认消息 ( 200OK ), 并向源 MSC通过 AP信令发送切换完成通知。 本实施例中, 步 驟 732和 733之间没有严格的顺序关系。
步驟 734, HOPF向源 MSC发送应答消息 ( ANM )接通和源 MSC之 间的局间电路。
步驟 735 , 源 MSC通知源 RNC释放信令链接和承载资源。
经过上述过程, UE1完成了从 CS网络到上述 IP网络的切换。
图 8为本发明实施例的切换方法实施例五的流程图, 如图 8所示, 本 实施例与图 7中所示的实施例的主要区别在于, 图 7中的处理流程中, 切 驟 708 ), 且后续 HOPF和目标 AG之间建立 IP承载也是通过 ISCF做为代 理实现的(见步驟 714~步驟 720 )。 而本实施例中是由 HOPF直接获取到目 标 AG的地址,切换相关的消息是由 HOPF直接发给目标 AG (见步驟 805~ 步驟 806 ), 后续由 HOPF直接和目标 AG之间建立 IP承载(见步驟 811~ 步驟 813 )。
如图 8所示, 本实施例的切换方法具体包括以下步驟:
步驟 801~步驟 804描述的是源 RNC向源 MSC发送切换请求,源 MSC 向 HOPF发送准备切换请求的过程, 同步驟 701~步驟 704。
步驟 805 , HOPF接收到准备切换请求后, 分配切换号码, 并根据目标 小区和运营商策略或其他合适的方式获取目标 AG地址, HOPF将接收到的 MAP消息转换成呼叫转移请求( REFER )消息发送给目标 AG。 REFER消 息中要求联系的目的地址(Refer-To )头域中填写的是目标 AG的地址, 消 息中携带切换标识, 如 method=handover。 消息中携带切换相关参数, 切换 相关参数是从 MAP 准备切换请求消息中映射而来, 包含目标小区、 目标 RNC相关信息以及编解码相关信息等。 切换相关参数携带的方法不限, 可 以放在 REFER的 SDP ( Session Description Protocol, 会话描述协议 ) 中通 过 XML ( extensible markup language, 可扩展标记语言 )扩展携带等。
步驟 806, 目标 AG接收到呼叫转移请求消息后向 HOPF回复呼叫转移 请求接受( 202 Accepted ) 消息。
步驟 807, 目标 AG 同时将呼叫转移请求(REFER )转换成切换请求 ( RELOCATION REQUEST )消息, 向目标 RNC发送。 目标 AG将 REFER 步驟 808, 目标 RNC接收到切换请求后开始接入网资源预留过程, 为 UE1从目标 RNC接入 3G网络分配相应的无线资源。 之后目标 RNC向目 标 AG发送切换请求响应 ( RELOCATION REQUEST ACK )。
步驟 809, 目标 AG接收到切换请求响应后向 HOPF发送通知消息 ( NOTIFY ), 通知 HOPF切换准备完毕。
步驟 810, HOPF接收到通知后向目标 AG发送通知确认消息( 200OK )。 以下步驟 811~步驟 813是 HOPF与目标 AG之间建立 IP承载的过程。 该过程有多种实现方式, 本实施例中描述的仅是其中一种。
步驟 811 , HOPF预留资源, 并向目标 AG发送呼叫邀请(INVITE )。 步驟 812, 目标 AG预留资源, 完成与 HOPF的媒体面资源协商过程, 之后向 HOPF回复应答消息( 200OK )。
步驟 813, HOPF向目标 AG发送应答确认消息(ACK )。
步驟 814 , HOPF 向源 MSC 发送准备切换响应 ( MAP_Prepare_ Handover_rsp ) 消息, 携带 HOPF分配的切换号码等参数。
步驟 815~步驟 821是源 MSC与 HOPF建立局间承载的过程及 UE1开 始切换的过程, 同步驟 722~步驟 728。
步驟 822, 目标 AG接收到切换完成消息之后向 HOPF发送通知消息 ( NOTIFY ), 通知 HOPF切换已完成。
步驟 823~步驟 824, HOPF接收到通知消息后, 向目标 AG回复确认消 息( 200OK )。 并向源 MSC通过 MAP信令发送切换完成通知。
步驟 825, HOPF向源 MSC发送应答消息 ( ANM )接通和源 MSC之 间的局间电路。
步驟 826 , 源 MSC通知源 RNC释放信令链接和承载资源。
经过上述过程, UE1完成了从 CS网络到上述 IP网络的切换。
图 9为本发明实施例的切换方法实施例六的流程图, 如图 9所示, 本 实施例与图 7以及图 8中涉及的实施例的主要区别在于: 图 7以及图 8中 涉及的两个实施例中 HOPF是采用 REFER消息通知目标网元进行切换 (分 别参见步驟 705和步驟 805 ), 后续 HOPF再通过呼叫邀请流程建立和目标 AG之间的 IP承载(分别参见步驟 713~步驟 720,以及,步驟 811~步驟 813 )。 而图 9中的实施例是采用呼叫邀请 ( INVITE ) 消息通知目标 AG进行切换 (参见步驟 905 ),后续和目标 AG之间建立 IP承载也是通过这个消息流程 (步驟 905、 步驟 908、 步驟 917、 步驟 918 ), 即前两个实施例中将通知目 标网络进行切换和 HOPF建立目标 AG的 IP承载这两个过程分开实现了, 而在本实施例中这两个过程是通过一个 INVITE流程来实现。
如图 9所示, 本实施例的切换方法具体包括以下步驟:
步驟 901~步驟 904描述的是源 RNC向源 MSC发送切换请求,源 MSC 向 HOPF发送准备切换请求的过程, 同步驟 701 ~步驟 704完全相同。
以下步驟 905、 步驟 908、 步驟 917、 步驟 918实现了通知目标 AG进 行切换, 同时和目标 AG建立 IP 载的过程。
步驟 905, HOPF接收到准备切换请求后, 分配切换号码, 并根据目标 小区和运营商策略或其他合适的方式获取目标 AG地址, HOPF将接收到的 MAP消息转换成呼叫邀请消息( INVITE ) 消息发送给目标 AG。 该呼叫邀 请请求消息中携带切换标识, INVITE消息携带切换标识的方法可以是通过 route头域中 method参数扩展的方法来实现,例如可以采用如下格式, route: 目标地址; method=handover。 INVITE消息携带切换标识的方法还可以是通 过 Request-URI头域中对参数扩展的方法来实现, 例如可以采用如下格式: 目标地址; method=handover。 根据切换标识, 目标 AG可确定后续要进行 切换处理。 INVITE消息中携带切换相关参数, 切换相关参数是从 MAP准 备切换请求消息中映射而来, 包含目标小区、 目标 RNC相关信息以及编解 码相关信息等。 切换相关参数携带的方法不限, 可以放在 INVITE的 SDP ( Session Description Protocol , 会话描述协议) 中通过 XML ( extensible markup language,可扩展标记语言)扩展携带等。此外, INVITE消息的 SDP 中还携带 HOPF预留的媒体面资源信息。
步驟 906, 目标 AG接收到 INVITE消息后, 向目标 RNC发送切换请 求 RELOCATION REQUEST消息, 消息中携带必要的切换相关参数。
步驟 907, 目标 RNC接收到切换请求后开始接入网资源预留过程, 为 UE1从目标 RNC接入 3G网络分配相应的无线资源。 之后目标 RNC向目 标 AG发送切换请求响应 ( RELOCATION REQUEST ACK )。
步驟 908, 目标 AG接收到切换请求响应后向 HOPF发送呼叫进展消息 ( 183 Call Progress ), 该消息的 SDP中携带目标 AG的媒体面资源信息。
步驟 909 , HOPF接收到 183消息后向源 MSC发送 MAP准备切换响应 消息 ( MAP_Prepare_ Handover_rsp ), 携带 HOPF分配的切换号码等参数。
步驟 910, 源 MSC接收到准备切换请求响应后, 源 MSC开始和 HOPF 建立局间承载及通知 UE1开始切换。
步驟 910~步驟 916同步驟 722~步驟 728完全相同。
步驟 917, 目标 AG接收到切换完成消息后,向 HOPF发送应答( ACK ) 消息。
步驟 918 , HOPF接收到应答消息后向目标 AG 回复应答确认消息
( 200OK )。
步驟 919, HOPF向源 MSC通过 MAP信令发送切换完成通知
步驟 920, HOPF向源 MSC发送应答消息( ANM )接通和源 MSC之 间的局间电路。
步驟 921 , 源 MSC通知源 RNC释放信令链接和承载资源。
经过上述过程, UE1完成了从 CS网络到上述 IP网络的切换。
以上, 仅为本发明的较佳实施例而已, 并非用于限定本发明的保护范

Claims

权利要求书
1、 一种切换方法, 其特征在于, 所述方法包括:
源接入网关 AG接收到切换请求后, 通知切换代理功能实体 HOPF进 行异构网切换处理;
所述 HOPF通知目标移动交换中心 MSC准备切换资源并建立切换所需 承载;
所述源 AG通知源无线网络控制器 RNC进行切换。
2、 根据权利要求 1所述的方法, 其特征在于, 所述通知 HOPF进行异 构网切换处理为:
所述源 AG判断当前切换为异构网切换后, 获取所述 HOPF的地址信 息, 通过 SIP消息通知所述 HOPF进行异构网切换处理。
3、 根据权利要求 2所述的方法, 其特征在于, 所述 SIP消息中携带有 切换的相关参数和 /或切换标识。
4、 根据权利要求 3所述的方法, 其特征在于, 所述 SIP消息中携带有 切换的相关参数和 /或切换标识为:
所述 SIP消息的消息体中承载切换的相关参数和 /或切换标识。
5、 根据权利要求 3或 4所述的方法, 其特征在于, 所述切换的相关参 数包括切换目标小区以及目标 RNC的信息、 所述源 AG支持的媒体编解码 信息以及当前业务采用的编解码信息。
6、 根据权利要求 3所述的方法, 其特征在于, 所述 SIP消息中携带有 切换的相关参数和 /或切换标识为:
所述 SIP消息的消息头中承载切换标识。
7、 根据权利要求 1、 2、 3、 4或 6所述的方法, 其特征在于, 所述 SIP 消息为转移请求 REFER消息, 和 /或, 呼叫邀请 INVITE消息。
8、 根据权利要求 7所述的方法, 其特征在于, 所述 SIP消息的消息头 中承载切换标识为:
对于所述 REFER消息,所述切换标识 载于所述 REFER消息的 Route 头域或 Request-URI头域中。
9、 根据权利要求 7所述的方法, 其特征在于, 所述通知 HOPF进行异 构网切换处理为:
所述源 AG直接向所述 HOPF发送 SIP消息, 通知所述 HOPF进行异 构网切换处理;
或者, 所述源 AG通过 ISCF向所述 HOPF发送 SIP消息, 通知所述 HOPF进行异构网切换处理。
10、 根据权利要求 5所述的方法, 其特征在于, 所述 HOPF通知所述 目标 MSC准备切换资源并建立切换所需承载为:
所述 HOPF 向所述目 标 MSC 发送 MAP 准备切换请求 MAP_Prepare_Handover _req消息 , 所述 MAP_Prepare_Handover _req消息 中携带有所述 HOPF所接收到的由所述源 AG发送的所述 SIP消息中的切 换的相关参数。
11、 根据权利要求 10 所述的方法, 其特征在于, 所述 MAP_Prepare_Handover _req消息中携带有切换的相关参数为:
所述 HOPF将由所述源 AG发送的所述 SIP消息中的切换的相关参数 的目标小区参数映射为所述 MAP_Prepare_Handover _req 消息中的 Target Cell Id参数, 将目标 RNC参数映射为所述 MAP_Prepare_Handover _req消 息中的 Target RNC Id参数。
12、 根据权利要求 11所述的方法, 其特征在于, 所述 HOPF通知目标 MSC准备切换资源并建立切换为:
所述目标 MSC接收到所述 MAP_Prepare_Handover _req消息后, 向所 述目标 RNC发送切换请求;所述目标 MSC接收到所述目标 RNC的切换请 求响应后, 向所述 HOPF发送 MAP准备切换请求响应消息; 所述 HOPF接收到所述目标 MSC发送的 MAP准备切换请求响应后, 同所述目标 MSC建立局间承载, 并通过初始化地址消息 IAM通知所述目 标 MSC建立局间^ ^载;
所述目标 MSC与所述 HOPF建立局间承载后, 通过地址全消息 ACM 通知所述 HOPF。
13、 根据权利要求 12所述的方法, 其特征在于, 所述方法还包括: 所述 HOPF接收到所述 ACM消息后,通过 SIP消息建立与待切换用户 设备 UE会话的对端 UE或目标 AG之间的 IP承载, 并通过 SIP消息通知 所述 ISCF或所述源 AG切换准备完成。
14、 根据权利要求 12所述的方法, 其特征在于, 所述方法还包括: 所述 HOPF接收到所述 ACM消息后,向所述源 AG发送 SIP消息通知 呼叫进展, 其中, 通知呼叫进展的 SIP消息为呼叫进展消息 183, 所述呼叫 进展消息 183中的会话描述协议 SDP字段中携带所述 HOPF预留的媒体面 资源信息。
15、 根据权利要求 5所述的方法, 其特征在于, 所述 HOPF通知目标 MSC准备切换资源并建立切换所需承载为:
所述 HOPF接收到通知进行异构网切换的 SIP消息后,向所述目标 MSC 发送 MAP_Prepare_Handover _req消息; 其中, 所述 HOPF将所接收到的所 述通知进行异构网切换的 SIP 消息中的切换的相关参数映射成所述 MAP_Prepare_Handover _req消息中的对应参数。
16、 根据权利要求 15所述的方法, 其特征在于, 所述切换的相关参数 包括目标小区和目标 RNC相关信息以及当前业务采用的编解码信息。
17、 根据权利要求 13所述的方法, 其特征在于, 所述 HOPF通过 SIP 消息通知所述 ISCF所述源 AG切换准备完成时, 所述 ISCF在所述 HOPF 同与待切换 UE会话的对端 UE的 IP承载建立完成后, 通知所述源 AG切 换准备完成。
18、 一种切换方法, 其特征在于, 所述方法包括:
源 MSC接收到切换请求后, 通知 HOPF准备切换;
所述 HOPF通知目标 AG准备切换资源并建立 IP承载;
所述 HOPF通知所述源 MSC切换准备完成, 所述源 MSC通知源 RNC 进行切换。
19、 根据权利要求 17所述的方法, 其特征在于, 所述通知 HOPF准备 切换为:
源 MSC 获取所述 HOPF 的地址信息, 向所述 HOPF 发送 MAP_Prepare_Handover_req消息 ,所述 MAP_Prepare_Handover_req消息中 携带有切换相关参数, 所述切换的相关参数包括切换目标小区以及目标 RNC的信息、 所述源 AG支持的媒体编解码信息以及当前业务采用的编解 码信息。
20、 根据权利要求 19所述的方法, 其特征在于, 所述 HOPF通知目标 AG准备切换资源并建立 IP承载为:
所述 HOPF接收到所述源 MSC的 MAP_Prepare_Handover_req消息后, 获取所述目标 AG 的地址信息以及切换相关参数, 将所述切换相关参数映 射到通知所述目标 AG准备切换的 SIP消息中并发送给所述目标 AG,通知 所述目标 AG准备切换。
21、 根据权利要求 20 所述的方法, 其特征在于, 所述通知所述目标 AG准备切换为:
所述 HOPF直接向所述目标 AG发送 SIP消息,通知所述目标 AG准备 切换;
或者, 所述 HOPF通过 ISCF向所述目标 AG发送 SIP消息, 通知所述 目标 AG准备切换;其中,通知的 SIP消息中携带切换相关参数和切换标识。
22、 根据权利要求 18所述的方法, 其特征在于, 所述 HOPF通知目标 AG准备切换资源并建立 IP承载为:
所述目标 AG接收到准备切换的通知后, 向目标 RNC发送切换请求消 息 RELOCATION REQUEST, 通知目标 RNC准备无线侧资源;
所述目标 AG接收到所述目标 RNC的切换请求响应后, 通过 SIP消息 通知所述 HOPF或所述 ISCF无线侧资源准备完成。
23、 根据权利要求 22所述的方法, 其特征在于, 所述方法还包括: 所述 HOPF采用 REFER消息通知所述目标 AG准备切换时,所述 HOPF 在接收到切换准备完成通知 NOTIFY消息后与所述目标 AG之间建立 IP承 载;
所述 HOPF采用 INVITE消息通知所述目标 AG准备切换时,所述 HOPF 与所述目标 AG之间的 IP承载在所述 INVITE会话过程中建立。
24、 根据权利要求 23所述的方法, 其特征在于, 所述方法还包括: 所述 HOPF通过 INVITE消息直接或间接与所述目标 AG之间建立 IP 承载。
25、 根据权利要求 24所述的方法, 其特征在于, 所述方法还包括: 所述 HOPF与所述目标 AG之间建立 IP 载后, 所述 HOPF通过
MAP_Prepare_ Handover_rs 消息通知所述源 MSC切换准备完成; 其中, 所述 MAP_Prepare_ Handover_rs 消息中携带所述 HOPF分配的切换号码。
26、 根据权利要求 24所述的方法, 其特征在于, 所述方法还包括: 所述源 MSC接收到所述 HOPF的切换准备完成通知后, 与所述 HOPF 建立局间承载, 并通过 IAM通知所述 HOPF建立局间承载;
所述 HOPF接收到所述 IAM后,预留资源并同源 MSC建立局间承载, 向所述源 MSC发送 ACM消息; 所述源 MSC接收到 ACM消息后, 向所述源 RNC发送切换命令。
27、一种切换系统,应用于无线通信系统中,所述切换系统包括源 AG、 源 RNC、 目标 RNC、 目标 MSC、 目标 AG、 待切换 UE和与待切换 UE会 话的对端 UE, 其特征在于:
源 AG, 用于接收到切换请求后, 通知 HOPF进行异构网切换处理; 以 及, 在接收到切换准备完毕通知后, 通知源 RNC进行切换;
HOPF, 用于接收到所述源 AG的异构网切换通知后, 通知目标 MSC 准备切换资源并建立切换所需承载。
28、 根据权利要求 27所述的系统, 其特征在于, 所述源 AG, 进一步 用于直接向所述 HOPF发送 SIP消息, 通知所述 HOPF进行异构网切换处 理;
或者, 所述 AG, 进一步用于通过所述 ISCF向所述 HOPF发送 SIP消 息, 通知所述 HOPF进行异构网切换处理。
29、 根据权利要求 27所述的系统, 其特征在于, 所述 HOPF进一步向 所述 目 标 MSC 发送 MAP_Prepare_Handover _req 消 息 , 所述 MAP_Prepare_Handover _req消息中携带有所述 HOPF所接收到的由所述源 AG发送的所述 SIP消息中的切换的相关参数。
30、 根据权利要求 29所述的系统, 其特征在于, 所述目标 MSC在接 收到所述 MAP_Prepare_Handover _req消息后, 进一步向所述目标 RNC发 送切换请求;
所述目标 MSC接收到所述目标 RNC的切换请求响应后, 进一步向所 述 HOPF发送 MAP准备切换请求响应消息;
所述 HOPF接收到所述目标 MSC发送的 MAP准备切换请求响应后, 进一步同所述目标 MSC建立局间承载, 并通过初始化地址消息 IAM通知 所述目标 MSC建立局间承载; 所述目标 MSC与所述 HOPF建立局间承载后, 进一步通过 ACM通知 所述 HOPF。
31、 根据权利要求 30所述的系统, 其特征在于, 所述 HOPF在接收到 所述 ACM消息后, 进一步通过 SIP消息建立与待切换用户设备 UE会话的 对端 UE或目标 AG之间的 IP承载,并通过 SIP消息通知所述 ISCF或所述 源 AG切换准备完成。
32、 一种切换系统, 其特征在于, 应用于无线通信系统中, 所述切换 系统包括源 AG、 源 RNC、 目标 RNC、 目标 MSC、 目标 AG、 待切换 UE 和与待切换 UE会话的对端 UE, 其特征在于:
源 MSC, 用于接收到切换请求后, 通知 HOPF准备切换; 以及在接收 到 HOPF的切换准备完成后通知源 RNC进行切换;
HOPF, 用于接收到准备切换通知后, 通知目标 AG准备切换资源并建 立 IP承载; 以及, 通知所述源 MSC切换准备完成。
33、 根据权利要求 32所述的系统, 其特征在于, 所述源 MSC进一步 用 于 获取所述 HOPF 的 地址信 息 , 向 所述 HOPF 发送 MAP_Prepare_Handover_req消息 ,所述 MAP_Prepare_Handover_req消息中 携带有切换相关参数, 所述切换的相关参数包括切换目标小区以及目标 RNC的信息、 所述源 AG支持的媒体编解码信息以及当前业务采用的编解 码信息。
34、 根据权利要求 33所述的系统, 其特征在于, 所述 HOPF在接收到 所述源 MSC的 MAP_Prepare_Handover_req消息后, 进一步获取所述目标 AG的地址信息以及切换相关参数,将所述切换相关参数映射到通知所述目 标 AG准备切换的 SIP消息中并发送给所述目标 AG, 通知所述目标 AG准 备切换。
35、 根据权利要求 34所述的系统, 其特征在于, 所述 HOPF直接向所 述目标 AG发送 SIP消息, 通知所述目标 AG准备切换;
或者, 所述 HOPF通过 ISCF向所述目标 AG发送 SIP消息, 通知所述 目标 AG准备切换;其中,通知的 SIP消息中携带切换相关参数和切换标识。
36、 根据权利要求 32所述的系统, 其特征在于, 所述目标 AG接收到 准备切换的通知后, 向目标 RNC 发送切换请求消息 RELOCATION REQUEST, 通知目标 RNC准备无线侧资源;
所述目标 AG接收到所述目标 RNC的切换请求响应后, 通过 SIP消息 通知所述 HOPF或所述 ISCF无线侧资源准备完成。
37、根据权利要求 36所述的系统,其特征在于,所述 HOPF采用 REFER 消息通知所述目标 AG准备切换时, 所述 HOPF在接收到切换准备完成通 知 NOTIFY消息后与所述目标 AG之间建立 IP承载;
所述 HOPF采用 INVITE消息通知所述目标 AG准备切换时,所述 HOPF 与所述目标 AG之间的 IP承载在所述 INVITE会话过程中建立。
38、 根据权利要求 36所述的系统, 其特征在于, 所述 HOPF与所述目 标 AG之间建立 IP 载后, 所述 HOPF通过 MAP_Prepare_ Handover_rsp 消息通知所述源 MSC 切换准备完成; 其中, 所述 MAP_Prepare_ Handover_rs 消息中携带所述 HOPF分配的切换号码。
39、 根据权利要求 38所述的系统, 其特征在于, 所述源 MSC接收到 所述 HOPF的切换准备完成通知后, 与所述 HOPF建立局间承载, 并通过 IAM通知所述 HOPF建立局间承载;
所述 HOPF接收到所述 IAM后,预留资源并同源 MSC建立局间承载, 向所述源 MSC发送 ACM消息;
所述源 MSC接收到 ACM消息后, 向所述源 RNC发送切换命令。
PCT/CN2012/070625 2011-01-31 2012-01-19 切换方法及系统 WO2012103792A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201110033985.4 2011-01-31
CN2011100339854A CN102625397A (zh) 2011-01-31 2011-01-31 切换方法及系统

Publications (1)

Publication Number Publication Date
WO2012103792A1 true WO2012103792A1 (zh) 2012-08-09

Family

ID=46565033

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2012/070625 WO2012103792A1 (zh) 2011-01-31 2012-01-19 切换方法及系统

Country Status (2)

Country Link
CN (1) CN102625397A (zh)
WO (1) WO2012103792A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019140560A1 (zh) * 2018-01-16 2019-07-25 Oppo广东移动通信有限公司 一种切换方法及装置、计算机存储介质

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014082269A1 (zh) * 2012-11-29 2014-06-05 华为技术有限公司 异系统切换方法、装置及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1422326A (zh) * 2000-02-17 2003-06-04 国际壳牌研究有限公司 纯化烃类液体燃料的方法
WO2007144028A1 (en) * 2006-06-16 2007-12-21 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for controlling intersystem handover in a mobile communication system
CN101291537A (zh) * 2007-04-17 2008-10-22 阿尔卡泰尔卢森特公司 从e-utran到utran/geran cs的切换
CN101690328A (zh) * 2007-06-06 2010-03-31 交互数字技术公司 使用媒介无关切换功能实体的异构网络切换支持机制

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101472326B (zh) * 2007-12-29 2011-06-08 华为技术有限公司 一种实现异系统间语音业务切换的方法和终端
CN101472306B (zh) * 2007-12-29 2012-06-20 华为技术有限公司 一种ap间切换的方法、装置和系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1422326A (zh) * 2000-02-17 2003-06-04 国际壳牌研究有限公司 纯化烃类液体燃料的方法
WO2007144028A1 (en) * 2006-06-16 2007-12-21 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for controlling intersystem handover in a mobile communication system
CN101291537A (zh) * 2007-04-17 2008-10-22 阿尔卡泰尔卢森特公司 从e-utran到utran/geran cs的切换
CN101690328A (zh) * 2007-06-06 2010-03-31 交互数字技术公司 使用媒介无关切换功能实体的异构网络切换支持机制

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019140560A1 (zh) * 2018-01-16 2019-07-25 Oppo广东移动通信有限公司 一种切换方法及装置、计算机存储介质
US11240722B2 (en) 2018-01-16 2022-02-01 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Handover method and device and computer storage medium

Also Published As

Publication number Publication date
CN102625397A (zh) 2012-08-01

Similar Documents

Publication Publication Date Title
JP4763723B2 (ja) 回線交換無線ネットワークとパケット交換データ無線ネットワークとの間における呼ハンドオフのためのシステムと方法
JP4988338B2 (ja) 会話型ベアラネゴシエーション
US8442005B2 (en) Seamless handoff across heterogeneous access networks using a handoff controller in a service control point
RU2617438C2 (ru) Синхронизация состояний вызова сетевого компонента и мобильное устройство при переносе сеанса
US9706449B2 (en) Technique for transferring a session with changeable session state
JP2009509479A (ja) コールの継続を支援する無線通信方法およびシステム
WO2007143266A2 (en) Method and system for inter-technology handoff of an access terminal
WO2011137851A1 (zh) 反向单一无线语音呼叫连续性的处理方法、设备及系统
WO2009100609A1 (zh) 一种单无线信道语音业务连续性的域切换方法
EP2675215A2 (en) Handover Apparatus and Method in a Heterogeneous Wireless Communication System
WO2011140888A1 (zh) 一种增强单接入语音业务连续性的通信系统及方法
WO2009148173A1 (ja) 移動体通信システム、ノード装置及び網間移行制御方法
WO2011085668A1 (zh) 切换控制方法和相关设备及系统
WO2013086733A1 (zh) 软切换方法及设备
WO2012041026A1 (zh) 电路交换域业务切换到分组交换域的方法及系统
WO2010105525A1 (zh) 一种切换的优化方法、切换装置和系统
WO2010127511A1 (zh) Srvcc切换及其数据传输的方法、装置和系统
WO2008151481A1 (fr) Procédé pour commander de manière centralisée le service d'implémentation d'appel de terminal dans un sous-système de réseau central multimédia ip
WO2012149866A1 (zh) 单一无线语音呼叫连续性域的切换方法及系统
WO2011130949A1 (zh) 反向单待业务连续性实现方法及系统
WO2012103792A1 (zh) 切换方法及系统
US8908639B2 (en) Methods for handoff of an active communication connection from a macrocell to a femtocell
WO2010102475A1 (zh) 终端从家庭基站切换到宏蜂窝系统保持会话的方法和系统
WO2011023054A1 (zh) 一种ip多媒体子系统中多会话能力同步方法及系统
US9949171B2 (en) Advanced LMSD intersystem handoff

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12741737

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12741737

Country of ref document: EP

Kind code of ref document: A1