WO2010139214A1 - 基于移动交换中心容灾的呼叫处理方法及位置寄存器 - Google Patents

基于移动交换中心容灾的呼叫处理方法及位置寄存器 Download PDF

Info

Publication number
WO2010139214A1
WO2010139214A1 PCT/CN2010/072114 CN2010072114W WO2010139214A1 WO 2010139214 A1 WO2010139214 A1 WO 2010139214A1 CN 2010072114 W CN2010072114 W CN 2010072114W WO 2010139214 A1 WO2010139214 A1 WO 2010139214A1
Authority
WO
WIPO (PCT)
Prior art keywords
msc
mscid
called party
location
request
Prior art date
Application number
PCT/CN2010/072114
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 WO2010139214A1 publication Critical patent/WO2010139214A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/30—Network data restoration; Network data reliability; Network data fault tolerance
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/04—Arrangements for maintaining operational condition

Definitions

  • the present invention relates to the field of mobile communications technologies, and in particular, to a call processing method and a location register based on a disaster tolerance of a mobile switching center.
  • a mobile user's information is downloaded from a user's home location register (HLR) to a visitor location register (VLR) where the user is currently located.
  • HLR home location register
  • VLR visitor location register
  • MSC Mobile Switch Center
  • the primary MSC processes the service and backs up the MSC. Idle, the Signaling Transfer Point (STP) sends signaling to the primary MSC. When the primary MSC fails, the backup MSC takes over the service. The STP finds that the link to the primary MSC is unreachable. Order to send to the backup MSC.
  • MSC disaster recovery backup if the user is to be called immediately after the disaster recovery, there are mainly two processing strategies. One is to synchronize the user information from the primary MSC to the backup MSC, and the other is Broadcast paging.
  • the user data needs to be synchronized in real time, and since the location of the user is constantly changing, and the amount of user data is relatively large, the user data between the primary MSC and the backup MSC cannot be completely synchronized. 2
  • Step 201 the calling O-MSC receives the base station controller (Base a station controller, called a BSC) 1 call request;
  • Step 202 the O-MSC sends an assignment request to the BSC1, requesting to allocate a traffic channel;
  • Step 203 The O-MSC receives the assignment completion message of the BSCl, and determines that the called party is a mobile user according to the called number.
  • Step 204 The O-MSC sends a location request to the called HLR.
  • the HLR finds the MSCID currently registered by the called user. Different from the MSCID of the location request initiator;
  • Step 205 The HLR sends a routing request to the MSC where the called user is currently located.
  • Step 206 the backup MSC finds that there is no called user information, and the system does not support the broadcast paging, and then responds to the HLR loop, indicating that the terminal is abrupt;
  • Step 207 the HLR sends a location response to the calling O-MSC, indicating the rejection
  • Step 208 The O-MSC sends a clear request message to the BSC1.
  • the O-MSC receives the clear complete message of the BSC 1, and the call is released.
  • FIG. 3 is a call flow diagram in this case, as shown in FIG.
  • the call in the case mainly includes the following steps: Step 301 - Step 305, which is the same as Step 201 - Step 205; Step 306, the backup MSC finds that there is no called user information, and the system supports broadcast paging, and the called user is allocated a temporary The local number (Temporary Local Directory Number, TLDN for short) is sent to the HLR loop to carry the assigned TLDN; Step 307, the HLR sends a location response to the O-MSC, and the location response carries the TLDN; Step 308, O-MSC analysis The TLDN performs the call connection, and the call setup request is routed to the backup MSC.
  • Step 301 - Step 305 which is the same as Step 201 - Step 205
  • Step 306 the backup MSC finds that there is no called user information, and the system supports broadcast paging, and the called user is allocated a temporary The local number (Temporary Local Directory Number, TLDN for short) is sent to the HLR loop to carry the assigned TLDN
  • Step 309 the backup MSC receives the call setup request, and finds that the TLDN is allocated by the system, but without the called user information, it is determined that all the backup MSC needs to be hanged.
  • BSC sends a page The request, assuming that all the BSCs connected to the backup MSC include: BSC2 and BSC3, the backup MSC sends a paging request to the BSC2;
  • Step 310 the backup MSC sends a paging request to the BSC3;
  • Step 311 the backup MSC receives the paging response, and finds There is no called user data locally;
  • Step 312 The backup MSC sends a registration request to the HLR, carrying the MSCID where the current location of the called user is located;
  • Step 313, the backup MSC receives the registration response of the HLR, and continues the call connection.
  • the present invention provides a call processing method based on MSC disaster tolerance, and a location register, which is used to solve the problem of call failure in the prior art due to incomplete synchronization of user data of the primary standby MSC. Broadcast paging is required within the scope of the MSC, resulting in a problem of relatively large consumption of radio resources.
  • a call processing method based on MSC disaster tolerance including: the called party's HLR receives a location request from an MSC where the calling party is located, where the location request carries the primary The first MSCID corresponding to the current location of the calling party; if the HLR determines that the second MSCID currently registered by the called party is different from the first MSCID, sending a routing request carrying the second MSCID to the MSC where the called party is located; In the case of the user data of the party, when the backup MSC where the called party is located performs the connection of the called party, the paging is performed in the range corresponding to the second MSCID.
  • a location register comprising: a receiving module, a storage module, an obtaining module, a determining module, and a transmitting module.
  • the receiving module is configured to receive a location request from the MSC where the calling party is located, where the location request is used to request location information of the called party, and carries the first MSCID corresponding to the current location of the calling party; a module, configured to store a MSCID currently registered by a user managed by the location register; an obtaining module, configured to acquire a second MSCID currently registered by the called party stored by the storage module; and a determining module, configured to determine the first MSCID And the sending module is configured to send a routing request to the MSC where the called party is located, where the routing module carries the second MSCID.
  • the called party's HLR when the called party's HLR receives the location request from the MSC where the autonomous calling party is located, it sends a routing request carrying the MSCID currently registered by the called party to the MSC where the called party is located, thereby
  • the backup MSC of the called party can perform paging only within the range identified by the MSCID when there is no user data of the called party, thereby solving the call in the prior art that the user data of the primary standby MSC is not completely synchronized.
  • the problem of failure, as well as the large consumption of radio resources due to the need for broadcast paging within the scope of the MSC reduces the consumption of system resources, improves the performance of the primary MSC, and ensures the stability of the system.
  • FIG. 1 is a schematic diagram of a network structure in which the primary and secondary MSCs are disaster-tolerant in the related art
  • FIG. 2 is a call flow diagram in the related art
  • FIG. 3 is another call flow diagram in the related art
  • 4 is a flowchart of an MSC disaster tolerance-based call processing method according to an embodiment of the present invention
  • FIG. 5 is a flowchart of an intra-office call according to an embodiment of the present invention
  • FIG. 6 is a flow of an inter-office call according to an embodiment of the present invention.
  • Figure 7 is a block diagram showing the structure of a location register in accordance with an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • the embodiments in the present application and the features in the embodiments may be grouped with each other. Hehe.
  • the preferred embodiments of the present invention are described with reference to the accompanying drawings, and the preferred embodiments of the present invention are intended to illustrate and explain the invention.
  • FIG. 4 is a flowchart of a MSC disaster tolerance based call processing method according to an embodiment of the present invention.
  • the MSC disaster tolerance based call processing method mainly includes the following steps (steps).
  • Step S405 In the case that there is no user data of the called party, when the backup MSC where the called party is located performs the connection of the called party, the MSCID carried in the routing request corresponds to The range is paged.
  • An embodiment of the present invention provides an improved MSC disaster tolerance-based call processing method, in order to enable a user to be called immediately after a disaster recovery, thereby causing a large amount of hardware resource consumption, or a large consumption of radio resources.
  • the called party's HLR when the called party's HLR receives the location request sent by the MSC where the autonomous calling party is located, it determines the calling party and the called party according to the MSCID of the calling party carried in the location request. Whether it is in the same MSCID, if yes (that is, the current call is an intra-office call, the calling party and the called party are in the same MSCID, and at this time, the MSC where the called party is located is the MSC where the calling party is located), then the master The calling party returns the corresponding indication.
  • the HLR carries the MSCID where the called party is currently located in the routing request sent to the MSC where the called party is located, so that there is no user data of the called party in the backup MSC where the called party is located.
  • the backup MSC can page within the range identified by the MSCID.
  • a physical MSC is generally divided into multiple MSCIDs, each MSCID identifies an area within a certain range, and each MSCID may correspond to multiple BSCs, or may correspond to a certain BSC.
  • Location area (LAC) and the area identified by each MSCID does not change due to the large local networking of the MSC. Therefore, in the embodiment of the present invention, the MSCID It is reasonable to perform paging under the corresponding range, and the impact on wireless resources is small. Details of each of the above processing steps are further described below.
  • Step S401 the MSC (which may be the primary MSC or the backup MSC) where the calling party is located sends a finger to the BSC after receiving the call request sent by the BSC where the calling party is located. With the request, the service channel is required to be allocated. After the BSC is completed, the BSC returns an assignment completion message to the MSC where the calling party is located, and the MSC of the calling party receives the assignment completion message to the BSC, and analyzes the called party. If the number is found to be a mobile user, the process of step S401 is triggered.
  • Step S403 In the specific implementation process, when the location change occurs, the called user will register with the HLR the MSCID where the location is updated. Specifically, the process mainly includes the following steps: Step 1: The called party initiates The location update, the BSC where the BSC is located receives the location update; Step 2, the MSC corresponding to the BSC receives the location update request of the BSC; Step 3, the MSC returns a location update response to the BSC; Step 4, the BSC returns to the called party a location update response; Step 5, the MSC determines that a registration request needs to be initiated to the called party's HLR (eg, when the called party's location changes greatly, the called party's MSCID changes, and the called party's terminal is powered on) Registration;); Step 6, the called party's HLR receives the registration request, updates the called party's user information, including: the MSCID information of the called user, and returns a registration response to the MSC.
  • Step 1 The called party initiates The location update, the BSC where
  • the HLR recorded by the called party is the latest location information of the called party.
  • the HLR of the called party can determine whether the MSCID corresponding to the current location of the calling party and the current MSCID of the called party are carried in the location request after receiving the location request of the MSC where the calling party is located. the same.
  • the HLR of the called party After receiving the location request sent by the MSC where the calling party is located, the HLR of the called party carries the identifier of the called party (for example, the number of the called party) in the specific implementation process.
  • the MSCID of the locally stored called party is obtained, and the MSCID is compared with the MSCID carried in the location request to determine whether the two MSCIDs are consistent. If yes, the current call is an intra-office call.
  • the calling party and the called party are in the same MSCID (the MSC where the called party is located at this time is the MSC where the calling party is located). If not, the current call is an interoffice call, and the calling party and the called party are absent. For the same MSCID, the following two cases are described separately.
  • the HLR sends a location response to the MSC where the calling party is located (the MSC where the calling party is located is the MSC where the called party is located), the location The response carries an identifier indicating that the calling party and the called party are in the same MSCID.
  • the LocTerm may be carried in the location response (Locreq), indicating that the calling party and the called party are in the same MSCID jurisdiction. If the primary MSC of the calling party fails and is taken over by the backup MSC, the backup MSC receives the location response returned by the called party's HLR, and the backup MSC determines the called party according to the identifier carried in the location response.
  • the backup MSC If the backup MSC has no user data (including service information and location information) of the called party, the backup MSC initiates paging within the range corresponding to the MSCID of the calling party, corresponding to the MSCID.
  • One or more BSCs send a page request.
  • the BSC of the called party After receiving the paging request, the BSC of the called party returns a paging response to the backup MSC, and after receiving the paging response, the backup MSC sends a registration request message of the called party to the HLR of the called party.
  • the backup MSC saves the location information and the service information of the called party, so that the subsequent call connection no longer needs to be paged according to the MSCID; after the called party's HLR registers, the registration response message is returned to the backup MSC, and the backup is performed.
  • the MSC After receiving the registration response message, the MSC sends an assignment request to the BSC managing the called party, and then receives the assignment response returned by the BSC, and the primary called party enters the call.
  • the calling party and the called party are not in the same MSCID:
  • the called party's HLR sends a routing request carrying the MSCID where the called party is currently located to the MSC where the called party is located.
  • the backup MSC takes over, and after receiving the routing request, the backup MSC allocates a TLDN to the call according to the MSCID carried in the routing request, and saves the correspondence between the MSCID and the allocated TLDN.
  • Step S405 After the MSC of the calling party sends the call setup request, the backup MSC of the called party receives the call setup request, obtains the TLDN, and determines that the TLDN is allocated by the local office, and then obtains the save.
  • the MSCID corresponding to the TLDN if the backup MSC of the called party determines that it has no user data (including service information and location information) of the called party, obtains location information corresponding to the MSCID according to the MSCID, and The one or more BSCs corresponding to the location information send a paging request, and the BSC that currently manages the called party returns a paging response to the backup MSC of the called party after receiving the paging request, and the backup MSC receives the paging.
  • the registration request is sent to the HLR, so that the location information and the service information of the called party are saved in the backup MSC, and the paging is not required to be performed according to the MSCID in the subsequent call connection, and the HLR returns to the backup MSC after registration.
  • the backup MSC receives the registration response message and continues the connection call.
  • FIG. 5 is a flowchart of performing an intra-office call in the embodiment.
  • the BSC1 is a BSC that manages the calling party
  • the MSC is a backup MSC of the calling party.
  • the intra-office is performed.
  • the call mainly includes the following steps: Step 501: After receiving the faulty primary MSC, the MSC receives the setup call request of the BSC1. Step 502: The MSC sends an assignment request to the BSC1 to request to allocate a service channel. Step 503: After the BSC1 allocates the service channel, Returning the assignment completion message to the MSC,
  • the MSC receives the assignment completion message returned by the BSC1, and determines that the called party is a mobile user by using the called number; Step 43 ⁇ 4 504, the MSC sends a location request to the called user's HLR (LOCATION) REQUEST) to request the location information of the called user, the location request carries the MSCID corresponding to the location of the calling user; Step 505, the HLR of the called party obtains the MSCID currently registered by the saved called user, and the MSCID and the location The MSCID carried in the request is compared to determine that the MSCID currently in the request is the same as the MSCID carried in the location request, and the location request response is directly returned to the MSC.
  • HLR LOCATION
  • the type of the TERMLIST carried in the location request response is LOCTERM, which is marked as intra-office.
  • Step 506 The MSC receives the location response, and determines that the called user is the local user, but the local office does not have the service information and the location information of the called user, and the MSC determines the location corresponding to the MSCID of the calling user (in this embodiment). It is assumed that the location corresponding to the MSCID includes BSC1 and BSC2), and the paging request for paging the called user is sent to the BSC1; Step 507, the MSC sends a paging request for paging the called user to the BSC2.
  • one MSCID may correspond to multiple BSCs, and may also correspond to some LACs of the BSC.
  • Step 508 The MSC receives the paging response of the BSC1.
  • the called user is the user under the BSC1 of the local office.
  • Step 509 The MSC sends a called registration request message to the HLR of the called user. Thereafter, the backup MSC stores the location information and service information of the called user, and the M-home MSCID is no longer needed for subsequent call connection.
  • Step 510 The HLR of the called user returns a registration response message to the MSC; Step 511, the MSC sends an assignment request to the BSC1 (the BSC where the called user is located); Step 512, the MSC receives the assignment response returned by the BSC1, The called party enters the call.
  • the second embodiment of the present invention uses the inter-office call as an example to describe the foregoing MSC disaster tolerance-based call processing method provided by the embodiment of the present invention.
  • FIG. 6 is a flowchart of performing an intra-office call in the embodiment.
  • BSC1 is a management main.
  • Step 601 The O-MSC receives the setup call request sent by the BSC1.
  • Step 602 The O-MSC sends an assignment request to the BSC1 to request to allocate a service channel.
  • Step 603 after the BSC1 allocates the service channel, the O- The MSC returns an assignment completion message, and after receiving the assignment completion message sent by the BSC1, the O-MSC determines that the called user is a mobile user by analyzing the called number; Step 604, the O-MSC sends a location request to the HLR of the called user ( The location information of the called user is requested by the LOCATION REQUEST. The location request carries the MSCID corresponding to the location of the calling user.
  • Step 606 sending a routing request to the MSC where the called user is located, where the routing request carries the MSCID where the called user is located; Step 606, the primary MSC where the called user is located fails, and the backup MSC (ie, the S-MSC) takes over.
  • the MSC receives the above-mentioned routing request sent by the HLR, allocates a TLDN to the call according to the MSCID carried in the routing request, records the MSCID, and returns a loop response to the HLR of the called user, where the routing response carries the assigned
  • the TLDN is as follows: Step 607: The HLR of the called user receives the routing response, and returns a location response to the O-MSC, where the location response carries a TLDN that is obtained from the routing response. Step 608, the O-MSC receives the foregoing The location response, the TLDN number carried in the location response is analyzed to perform the call continuation, and the call setup request is sent.
  • Step 609 the backup MSC receives the incoming call request (that is, the call setup request), and finds that the TLDN in the incoming call request is allocated by the local office. Obtaining the MSCID corresponding to the TLDN, and the backup MSC finds that there is no user data (including service information and location information) of the called user in the local office, and then the M is in the MSCID, and obtains the current location information of the called user. If the called user is currently at BSC2, the backup MSC sends a paging request to the BSC2. In step 610, the backup MSC receives the paging response returned by the BSC2.
  • Step 611 The backup MSC sends a registration request of the called user to the HLR of the called user, so that the backup MSC stores the location information and service information of the called user, and the subsequent call connection no longer needs to be paged according to the MSCID.
  • Step 612 The backup MSC receives the registration response returned by the called user's HLR, and continues the connection call.
  • a location register is also provided. The location register can be used as the home location register of the called user, and is used to implement the foregoing MSC disaster tolerance based call processing method provided by the embodiment of the present invention.
  • FIG. 7 is a schematic structural diagram of a location register according to an embodiment of the present invention. As shown in FIG.
  • a location register mainly includes: a receiving module 71, a storage module 73, an obtaining module 75, a determining module 77, and a sending Module 79.
  • the receiving module 71 is configured to receive a location request from the MSC where the calling party is located, where the location request is used to request the location information of the called party, and carries the first MSCID corresponding to the current location of the calling party;
  • the storage module 73 is configured to store the location register as the MSCID currently registered by the user managed by the home location register.
  • the obtaining module 75 is connected to the receiving module 71 and the storage module 73, and is configured to acquire the currently registered party of the called party stored by the storage module 73.
  • the second MSCID is connected to the obtaining module 75 and the receiving module 71 for determining whether the first MSCID and the second MSCID are the same.
  • the sending module 79 is connected to the determining module 77 for determining the result of the determining module 77. If no, the routing request is sent to the MSC where the called party is located, where the routing request carries the second MSCID, so that the called party is in the backup without the user data of the called party.
  • paging is performed in the range corresponding to the second MSCID.
  • the determining module 77 determines that the first MSCID and the second MSCID are the same, it indicates that the calling party and the called party have the same MSCID, and belongs to the inter-office call. Therefore, the determination result of the determining module 77 is yes.
  • the sending module 79 is further configured to return a location response message to the MSC where the calling party is located, where the location response message carries an identifier indicating that the calling party and the called party are in the same MSCID, so that the called party is not called. In the case of the user record of the party, when the backup MSC where the calling party is located performs the connection of the called party, the paging is performed in the range corresponding to the first MSCID.
  • the location register provided by the embodiment of the present invention may send a routing request carrying the MSCID where the called user is located to the MSC where the called user is located, when receiving the location request sent by the calling MSC, so that the location request may be
  • the backup MSC where the user is located does not have the number of users of the called user, the called user is immediately called as the called party, and does not consume too much wireless resources.
  • the present invention is described by taking the active/standby disaster recovery of the MSC as an example, the present invention is not limited to the active/standby disaster recovery. The present invention is equally applicable to other various types of MSC disaster tolerance.
  • the MSCID of the calling party carried in the location request is located. Determine whether the calling party and the called party are in the same MSCID. If yes, return the corresponding indication to the calling party. Otherwise, the HLR carries the MSCID where the called party is currently located in the routing request sent to the MSC where the called party is located. Therefore, when there is no user data of the called party in the backup MSC where the called party is located, the backup MSC can perform paging within the range identified by the MSCID.
  • the problem that the user immediately makes the called party after the disaster recovery switching can be solved, and the technical solution provided by the embodiment of the present invention does not consume too much hardware resources and radio resources, and can ensure the performance of the active MSC and improve the system. stability.
  • the above is only the preferred embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes can be made to the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and scope of the present invention are intended to be included within the scope of the present invention.

Landscapes

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

Abstract

本发明公开了一种基于移动交换中心容灾的呼叫处理方法及位置寄存器。其中，该方法包括：被叫方的HLR接收来自主叫方所在的MSC的位置请求，其中，该位置请求中携带有主叫方当前所在位置对应的第一 MSCID；如果HLR 确定被叫方当前登记的第二MSCID与第一MSCID不同，则向被叫方所在的MSC发送携带第二MSCID的路由请求；在没有被叫方的用户数据的情况下，被叫方所在的备份MSC进行被叫接续时，在第二MSCID对应的范围进行寻呼。 根据本发明，可以减少对无线资源的消耗，提高主用MSC的性能，保证系统 的稳定性。

Description

基于移动交换中心容灾的呼叫处理方法及位置寄存器 技术领域 本发明涉及移动通信技术领域，尤其涉及一种基于移动交换中心容灾的 呼叫处理方法及位置寄存器。 背景技术 在移动电信网络中，移动用户的信息是从用户的归属位置寄存器（ Home Location Register， 筒称为 HLR ) 下载到用户当前所在的拜访位置寄存器 ( Visitor Location Register,简称为 VLR )中，当移动交换中心（ Mobile Switch Center, 简称为 MSC )发现需要寻呼用户时， 根据 VLR中记录的用户的位 置信息进行寻呼。 目前， 为了避免由于 MSC发生故障而导致呼叫不能进行， 需要进行容 灾处理， 以一个 MSC的主备容灾为例， 如图 1所示， 在正常情况下， 主用 MSC处理业务， 备份 MSC空闲， 信令传输点 （ Signaling Transfer Point, 筒 称为 STP )将信令发送到主用 MSC, 当主用 MSC发生故障时， 备份 MSC 接管业务， STP发现到主用 MSC的链路不通， 将信令发送到备份 MSC。 在 MSC容灾备份的情况下， 如果要使容灾后用户能够立即作为被叫， 目前主要有两种处理策略， 一种是从主用 MSC 上将用户信息同步到备份 MSC上， 另一种就是进行广播寻呼。 如果采用第一种方式， 需要实时同步用户数据， 而由于用户的位置是经 常变化的， 且用户数据量会比较大， 因此， 不能保证主用 MSC和备份 MSC 之间的用户数据完全同步， 图 2为主用 MSC和备份 MSC之间的用户数据没 有完全同步的情况下的呼叫流程图， 如图 2所示， 主要包括以下步骤： 步骤 201， 起呼 O-MSC接收到基站控制器（ Base Station Controller, 筒 称为 BSC ) 1的呼叫请求； 步骤 202， O-MSC向 BSC1发送指配请求， 要求分配业务信道； 步骤 203 , O-MSC接收到 BSCl的指配完成消息，根据被叫号码确定被 叫为移动用户； 步骤 204 , O-MSC向被叫的 HLR发送位置请求； HLR发现被叫用户当 前登记的 MSCID与位置请求发起方的 MSCID不同； 步骤 205， HLR给被叫用户当前所在的 MSC发路由请求， 此时， 被叫 所在的主用 MSC故障， 由备份 MSC (即 S-MSC )接收该路由请求消息； 步骤 206， 备份 MSC发现没有被叫用户信息， 且系统不支持广播寻呼， 则给 HLR回路由响应， 指示 4巨绝； 步骤 207， HLR向起呼 O-MSC发位置响应， 指示拒绝； 步驟 208 , O-MSC向 BSC1发清除请求消息； 步骤 209， O-MSC接收到 BSC 1的清除完成消息， 呼叫释放。 由上述流程可知， 如果主备用 MSC的用户数据不完全同步， 则可能导 致呼叫失败， 并且， 采用这种方式需要消耗较多的硬件资源， 比如， 较大的 带宽及内存， 同时由于需要处理数据同步， 从而还将影响主用 MSC的性能。 如果采用第二种方式， 则当备份 MSC中没有被叫的用户数据时， 在备 份 MSC的网络内进行广播寻呼， 图 3为这种情况下的呼叫流程图， 如图 3 所示， 该种情况下进行的呼叫主要包括以下步骤： 步驟 301 -步驟 305 , 与步骤 201 -步骤 205相同； 步骤 306， 备份 MSC发现没有被叫用户信息， 系统支持广播寻呼， 则 为被叫用户分配临时本地号码 ( Temporary Local Directory Number , 简称为 TLDN ), 给 HLR回路由响应， 携带分配的 TLDN; 步骤 307 , HLR 向 O-MSC发送位置响应， 该位置响应携带有 TLDN; 步骤 308, O-MSC分析 TLDN进行呼叫接续， 呼叫建立请求被路由到 备份 MSC; 步骤 309 ,备份 MSC收到呼叫建立请求，发现 TLDN是本系统分配的， 但是没有被叫用户信息， 则确定需要给备份 MSC下挂的所有 BSC发送寻呼 请求， 假定备份 MSC下挂的所有 BSC包括： BSC2和 BSC3 , 则备份 MSC 向 BSC2发送寻呼请求； 步骤 310 , 备份 MSC向 BSC3发送寻呼请求； 步骤 311 , 备份 MSC接收到寻呼响应， 发现其本地没有被叫用户数据； 步驟 312 , 备份 MSC向 HLR发送登记请求， 携带被叫用户当前位置所 在的 MSCID; 步骤 313， 备份 MSC接收到 HLR的登记响应， 继续进行呼叫接续。 由上述流程可知，由于需要在备份 MSC下挂的所有 BSC进行广播寻呼， 从而导致对无线资源的消耗比较大， 特别是在现有大本地网组网的模式下， 一个 MSC管理范围 艮大的情况下， 无线资源的消耗更大， 从而将影响系统 的稳定性。 发明内容 有鉴于此， 本发明提供了一种基于 MSC容灾的呼叫处理方法、 及位置 寄存器， 用以解决现有技术中由于主备用 MSC 的用户数据不完全同步而导 致呼叫失败的问题或由于需要 MSC 的范围内进行广播寻呼而导致对无线资 源的消耗比较大的问题。 才艮据本发明的一个方面， 提供了一种基于 MSC容灾的呼叫处理方法， 包括： 被叫方的 HLR接收来自主叫方所在的 MSC的位置请求， 其中， 该位 置请求中携带有主叫方当前所在位置对应的第一 MSCID; 如果 HLR确定被 叫方当前登记的第二 MSCID与第一 MSCID不同， 则向被叫方所在的 MSC 发送携带第二 MSCID的路由请求； 在没有被叫方的用户数据的情况下， 被 叫方所在的备份 MSC进行被叫接续时，在第二 MSCID对应的范围进行寻呼。 根据本发明的另一个方面， 提供了一种位置寄存器包括： 接收模块、 存 储模块、 获取模块、 判断模块、 和发送模块。 其中， 接收模块， 用于接收来 自主叫方所在的 MSC 的位置请求， 其中， 该位置请求用于请求被叫方的位 置信息， 且携带有主叫方当前所在位置对应的第一 MSCID; 存储模块， 用于 存储位置寄存器所管理的用户当前登记的 MSCID; 获取模块， 用于获取存储 模块存储的被叫方当前登记的第二 MSCID;判断模块，用于判断第一 MSCID 与第二 MSCID是否相同； 发送模块， 用于在判断模块的判断结果为否的情 况下， 向被叫方所在的 MSC发送路由请求， 其中， 该路由请求中携带有第 二 MSCID。 通过本发明的上述至少一个方案， 被叫方的 HLR在接收到来自主叫方 所在的 MSC的位置请求时， 向被叫方所在的 MSC发送携带被叫方当前登记 的 MSCID的路由请求，从而使得被叫方的备份 MSC在没有被叫方的用户数 据时， 可以只在该 MSCID所标识的范围内进行寻呼， 从而解决现有技术中 由于主备用 MSC 的用户数据不完全同步而导致呼叫失败的问题， 以及由于 需要 MSC 的范围内进行广播寻呼而导致对无线资源的消耗比较大的问题， 减少了对系统资源的消耗， 提高了主用 MSC的性能， 保证了系统的稳定性。 本发明的其它特征和优点将在随后的说明书中阐述， 并且，部分地从说 明书中变得显而易见， 或者通过实施本发明而了解。 本发明的目的和其他优 点可通过在所写的说明书、 权利要求书、 以及附图中所特别指出的结构来实 现和获得。 附图说明 附图用来提供对本发明的进一步理解， 并且构成说明书的一部分， 与本 发明的实施例一起用于解释本发明， 并不构成对本发明的限制。 在附图中： 图 1为相关技术中采用主备 MSC容灾的网络结构示意图； 图 2为相关技术中的一种呼叫流程图； 图 3为相关技术中的另一种呼叫流程图； 图 4为 #居本发明实施例的基于 MSC容灾的呼叫处理方法的流程图； 图 5为根据本发明实施例的局内呼叫的流程图； 图 6为根据本发明实施例的局间呼叫的流程图； 图 7为根据本发明实施例的位置寄存器的结构示意图。 具体实施方式 在不冲突的情况下， 本申请中的实施例及实施例中的特征可以相互组 合。 以下结合附图对本发明的优选实施例进行说明，应当理解， 此处所描述 的优选实施例仅用于说明和解释本发明， 并不用于限定本发明。 冲艮据本发明实施例， 首先提供了一种基于 MSC容灾的呼叫处理方法。 图 4为才 据本发明实施例的基于 MSC容灾的呼叫处理方法的流程图， 如图 4所示， #>据本发明实施例的基于 MSC容灾的呼叫处理方法主要包括 以下步骤 (步樣 S401 -步骤 S405 ): 步驟 S401 : 被叫方的 HLR接收来自主叫方所在的 MSC的位置请求， 其中， 该位置请求中携带有主叫方当前所在位置对应的 MSCID; 步驟 S403 : 如果 HLR确定被叫方当前登记的 MSCID与主叫方当前所 在位置对应的 MSCID不同 （即当前进行的呼叫为局间呼叫， 主叫方与被叫 方不在同一 MSCID ), 则向被叫方所在的 MSC发送携带被叫方当前登记的 MSCID的路由请求； 步骤 S405:在没有被叫方的用户数据的情况下，被叫方所在的备份 MSC 进行被叫接续时， 在上述路由请求中携带的 MSCID对应的范围进行寻呼。 针对相关技术中为使容灾后用户能够立即作被叫从而导致硬件资源消 耗较多， 或无线资源消耗较大的问题， 本发明实施例提供了一种改进的基于 MSC容灾的呼叫处理方法。 在本发明实施例中， 被叫方的 HLR在接收到来 自主叫方所在的 MSC发送的位置请求时， 根据该位置请求中携带的主叫方 所在的 MSCID, 判断主叫方与被叫方是否在同一 MSCID, 如果是（即当前 进行的呼叫为局内呼叫， 主叫方与被叫方在同一 MSCID, 此时， 被叫方所在 的 MSC即为主叫方所在的 MSC ), 则向主叫方返回相应的指示， 否则， HLR 在向被叫方所在的 MSC发送的路由请求中携带被叫方当前所在的 MSCID, 以使得在被叫方所在的备份 MSC中没有被叫方的用户数据时，备份 MSC可 以在该 MSCID所标识的范围内进行寻呼。 在大本地网组网的情况下， 物理上的一个 MSC—般分为多个 MSCID, 每个 MSCID标识一定范围内的区域， 每个 MSCID可能对应多个 BSC, 也 可能对应一个 BSC的某几个位置区域（LAC ) , 并且， 每个 MSCID标识的 区域不会因为 MSC的大本地组网而改变，因此，在本发明实施例中在 MSCID 对应的范围下进行寻呼是比较合理， 对无线资源的影响较小。 以下进一步描述上述各处理步骤的细节。
(一） 步骤 S401 在具体实施过程中， 主叫方所在的 MSC (可以是主用 MSC, 也可以是 备份 MSC )在接收到主叫方所在的 BSC发送的呼叫请求后， 给该 BSC发送 指配请求， 要求分配业务信道， 该 BSC在分配业务信道完成后， 向主叫方所 在的 MSC返回指配完成消息， 主叫方所在的 MSC接) 到该 BSC的指配完 成消息， 分析被叫号码发现被叫是移动用户， 则触发步骤 S401的处理。
(二） 步骤 S403 在具体实施过程中， 被叫用户在发生位置变更时， 将向其 HLR登记其 位置更新后所在的 MSCID, 具体地， 该流程主要包括以下步驟： 步驟 1 , 被叫方发起位置更新， 其所在的 BSC接收该位置更新； 步骤 2， 该 BSC对应的 MSC接收到该 BSC的位置更新请求； 步骤 3 , MSC向该 BSC返回位置更新响应； 步骤 4， BSC向被叫方返回位置更新响应； 步驟 5 , MSC确定需要向被叫方的 HLR发起登记请求（比如， 在被叫 方的位置变化较大， 被叫方所在的 MSCID发生了变化、 以及被叫方终端开 机时进行登记；)； 步骤 6， 被叫方的 HLR接收到登记请求， 更新被叫方的用户信息， 其 中包括： 被叫用户所在的 MSCID信息， 并向 MSC返回登记响应。 因此， 在被叫方的 HLR记录的为被叫方最新的位置信息。 这样， 被叫 方的 HLR才能在接收到来自主叫方所在的 MSC的位置请求后， 判断该位置 请求中携带的主叫方当前所在位置对应的 MSCID 与被叫方当前登 ΐ己的 MSCID是否相同。 被叫方的 HLR在接收到上述主叫方所在的 MSC发送的位置请求后， 在具体实施过程中， 该位置请求中携带有被叫方的标识 （例如， 被叫方的号 码）， 获取本地保存的被叫方当前登记的 MSCID, 将该 MSCID与位置请求 中携带的 MSCID进行比较， 判断这两个 MSCID是否一致， 如果是， 则说明 当前进行的呼叫为局内呼叫， 主叫方与被叫方在同一 MSCID (此时被叫方所 在的 MSC即为主叫方所在的 MSC ),如果不是，则说明当前进行的呼叫为局 间呼叫，主叫方与被叫方不在同一 MSCID,下面分别对这两种情况进行说明。
1. 主叫方与被叫方在同一个 MSCID: 在这种情况下， HLR向主叫方所在的 MSC (主叫方所在的 MSC即为 被叫方所在的 MSC )发送位置响应， 该位置响应中携带有指示主叫方与被叫 方在同一 MSCID 的标识， 在具体实现过程中， 可以在位置响应 （Locreq ) 中携带 LocTerm, 指示主叫方和被叫方在同一个 MSCID的管辖范围内， 如 果此时主叫方的主用 MSC发生故障， 由备份 MSC接管， 则备份 MSC接收 被叫方的 HLR返回的上述位置响应， 该备份 MSC根据该位置响应中携带的 标识， 确定被叫方为本局用户， 如果该备份 MSC 内没有被叫方的用户数据 (包括业务信息和位置信息；)， 则该备份 MSC在主叫方所在 MSCID对应的 范围内发起寻呼， 向该 MSCID对应的一个或多个 BSC发送寻呼请求。 管理 被叫方的 BSC在接收到该寻呼请求后， 向该备份 MSC返回寻呼响应， 该备 份 MSC接收到该寻呼响应后，向被叫方的 HLR发送被叫方的登记请求消息， 从而使得备份 MSC 中保存被叫方的位置信息和业务信息， 以使后续的呼叫 接续不再需要根据 MSCID进行寻呼； 被叫方的 HLR进行登记后， 向备份 MSC返回登记响应消息， 该备份 MSC接收到该登记响应消息后， 向管理被 叫方的 BSC发送指配请求， 然后接收该 BSC返回的指配响应， 主被叫方进 入通话。
2. 主叫方与被叫方不在同一个 MSCID: 在这种情况下， 被叫方的 HLR向被叫方所在的 MSC发送携带被叫方 当前所在的 MSCID的路由请求， 此时， 如果被叫方所在的主用 MSC发生故 障， 由备份 MSC接管， 则备份 MSC接收到上述路由请求后， 根据该路由请 求中携带的 MSCID为呼叫分配 TLDN,并保存该 MSCID与分配的 TLDN的 对应关系， 然后向被叫方的 HLR返回路由响应， 该路由响应中携带有分配 的上述 TLDN;被叫方的 HLR接收到上述路由响应后，向主叫方所在的 MSC 返回位置响应， 该位置响应中携带有上述 TLDN; 主叫方所在的 MSC接收 到该位置响应后， 获取该位置响应中携带的 TLDN, 并 #居该 TLDN进行呼 叫， 发送携带该 TLDN的呼叫建立请求。 (三） 步聚 S405 主叫方所在的 MSC在发送上述呼叫建立请求后， 被叫方的备份 MSC 接收到该呼叫建立请求，获取其中的 TLDN，并确定该 TLDN是本局分配的， 则获取保存的与该 TLDN对应的 MSCID,如果被叫方的备份 MSC确定其没 有被叫方的用户数据 （包括业务信息和位置信息）， 则根据该 MSCID， 获取 与该 MSCID对应的位置信息， 并向与该位置信息对应的一个或多个 BSC发 送寻呼请求， 当前管理被叫方的 BSC在接收到上述寻呼请求后， 向被叫方的 备份 MSC返回寻呼响应， 该备份 MSC接收到寻呼响应后， 向 HLR发送登 记请求， 从而将被叫方的位置信息和业务信息保存在备份 MSC 中， 在后续 的呼叫接续中不再需要根据 MSCID进行寻呼， HLR在登记后向备份 MSC 返回登记响应消息， 备份 MSC接收该登记响应消息， 继续接续呼叫。 冲艮据本发明实施例的提供的上述方法， 通过被叫方的 HLR在路由请求 中携带被叫方当前所在的 MSCID, 可以在被叫方的备份 MSC中没有被叫方 的用户数据时， 缩小备份 MSC寻呼的范围， 从而减少无线资源的消耗。 为进一步理解本发明实施例提供的上述方法，下面分别以局内呼叫和局 间呼叫为例， 对本发明实施例提供的上述方法进行说明。 实施例一 本实施例以局内呼叫为例， 对本发明实施例提供的上述基于 MSC容灾 的呼叫处理方法进行说明。 图 5为本实施例中进行局内呼叫的流程图， 在图 5中， BSC1为管理主 叫方的 BSC, MSC为主叫方的备份 MSC, 如图 5所示， 在本实施例中进行 局内呼叫主要包括以下步骤： 步骤 501 , MSC接管故障主用 MSC后，接收到 BSC1的建立呼叫请求； 步骤 502 , MSC向 BSC1发送指配请求， 要求分配业务信道； 步骤 503 , BSC1分配业务信道完成后， 向 MSC返回指配完成消息，
MSC接收到 BSC1返回的指配完成消息，通过被叫号码确定被叫方是移动用 户； 步 4¾ 504 , MSC 向被叫用户的 HLR 发送位置请求 （LOCATION REQUEST ) 以请求被叫用户的位置信息， 该位置请求中携带有主叫用户所 在位置对应的 MSCID; 步骤 505 , 被叫方的 HLR获取保存的被叫用户当前登记的 MSCID, 将 该 MSCID与位置请求中携带的 MSCID进行比较，确定被叫用户当前所在的 MSCID与位置请求中携带的 MSCID相同， 直接给 MSC返回位置请求响应， 该位置请求响应中携带的 TERMLIST的类型为 LOCTERM,即标 为局内呼 叫； 步驟 506 , MSC接收到上述位置响应， 确定被叫用户为本局用户， 但 本局没有被叫用户的业务信息和位置信息， MSC才艮据主叫用户所在 MSCID 对应的位置（在本实施例中，假定该 MSCID对应的位置包括 BSC1和 BSC2 ), 向 BSC1发送寻呼被叫用户的寻呼请求； 步骤 507 , MSC向 BSC2发送寻呼被叫用户的寻呼请求。 在具体实施过程中， 一个 MSCID可能对应多个 BSC, 也可能对应 BSC 的某几个 LAC。 步骤 508 , MSC接收到 BSC1的寻呼响应； 本实施例中， 被叫用户为本局 BSC1下的用户。 步骤 509， MSC向被叫用户的 HLR发送被叫的登记请求消息； 此后， 该备份 MSC中保存有被叫用户的位置信息和业务信息， 在后续 的呼叫接续中不再需要 M居 MSCID进行寻呼； 步骤 510 , 被叫用户的 HLR向 MSC返回登记响应消息； 步骤 511 , MSC向 BSC1 (被叫用户所在的 BSC )发送指配请求； 步骤 512 , MSC接收到 BSC1返回的指配响应， 主被叫进入通话。 实施例二 本实施例以局间呼叫为例， 对本发明实施例提供的上述基于 MSC容灾 的呼叫处理方法进行说明。 图 6为本实施例中进行局内呼叫的流程图， 在图 6中， BSC1为管理主 叫方的 BSC, O-MSC为主叫方所在的 MSC, S-MSC为被叫方所在的 MSC， 该 MSC为备份 MSC, 如图 6所示， 在本实施例中进行局间呼叫主要包括以 下步驟： 步骤 601 , O-MSC接收到 BSC1发送的建立呼叫请求； 步骤 602， O-MSC向 BSC1发送指配请求， 要求分配业务信道； 步樣 603 , BSC1分配业务信道完成后， 向 O-MSC返回指配完成消息， O-MSC接收到 BSC1发送的指配完成消息后，通过分析被叫号码确定被叫用 户为移动用户； 步骤 604 , O-MSC 向被叫用户的 HLR发送位置请求 （LOCATION REQUEST ) 以请求被叫用户的位置信息， 该位置请求中携带了主叫用户所 在位置对应的 MSCID; 步骤 605 ,被叫用户的 HLR发现被叫用户当前所在的 MSCID与位置请 求中携带的 MSCID不同， 向被叫用户所在的 MSC发送路由请求， 该路由请 求中携带有被叫用户所在的 MSCID; 步骤 606，被叫用户所在的主用 MSC发生故障，备份 MSC (即 S-MSC ) 接管， 备份 MSC接收到 HLR发送的上述路由请求， 根据该路由请求中携带 的 MSCID为呼叫分配 TLDN, 并记录该 MSCID, 同时， 向被叫用户的 HLR 返回回路由响应， 该路由响应中携带有分配的上述 TLDN; 步骤 607 , 被叫用户的 HLR接收到上述路由响应， 向 O-MSC返回位置 响应， 该位置响应中携带有从路由响应中获耳又的 TLDN; 步骤 608 , O-MSC接收到上述位置响应，分析位置响应中携带的 TLDN 号码进行呼叫继续， 发送呼叫建立请求； 步骤 609, 备份 MSC接收到入呼请求（即上述呼叫建立请求）， 发现该 入呼倚求中的 TLDN是本局分配的， 获取与该 TLDN对应的 MSCID, 并且， 备份 MSC发现本局内没有被叫用户的用户数据（包括业务信息和位置信息）， 则才 M居该 MSCID, 得到被叫用户当前所在位置信息， 定被叫用户当前在 BSC2, 则备份 MSC向 BSC2发送寻呼请求； 步 610 , 备份 MSC接收到 BSC2 返回的寻呼响应； 步骤 611 , 备份 MSC向被叫用户的 HLR发送被叫用户的登记请求， 从 而使得该备份 MSC 中保存有被叫用户的位置信息和业务信息， 在后续的呼 叫接续不再需要根据 MSCID进行寻呼； 步骤 612 , 备份 MSC接收到被叫用户的 HLR返回的登记响应， 继续接 续呼叫。 才艮据本发明实施例，还提供了一种位置寄存器。 该位置寄存器可以作为 被叫用户的归属位置寄存器， 用于实现本发明实施例提供的上述基于 MSC 容灾的呼叫处理方法。 图 7为根据本发明实施例的位置寄存器的结构示意图， 如图 7所示，根 据本发明实施例的位置寄存器主要包括： 接收模块 71、 存储模块 73、 获取 模块 75、 判断模块 77、 和发送模块 79。 其中， 接收模块 71， 用于接收来自 主叫方所在的 MSC 的位置请求， 其中， 该位置请求用于请求被叫方的位置 信息， 且携带有主叫方当前所在位置对应的第一 MSCID; 存储模块 73， 用 于存储该位置寄存器作为归属位置寄存器所管理的用户当前登记的 MSCID; 获取模块 75与接收模块 71和存储模块 73连接， 用于获取存储模块 73存储 的被叫方当前登记的第二 MSCID; 判断模块 77与获取模块 75和接收模块 71连接， 用于判断上述第一 MSCID与上述第二 MSCID是否相同； 发送模 块 79与判断模块 77连接， 用于在判断模块 77的判断结果为否的情况下， 向被叫方所在的 MSC发送路由请求， 其中， 该路由请求中携带有上述第二 MSCID , 以使在没有被叫方的用户数据的情况下， 被叫方所在的备份 MSC 进行被叫接续时， 在第二 MSCID对应的范围进行寻呼。 并且，如果判断模块 77判断得到上述第一 MSCID和第二 MSCID相同， 则说明主叫方与被叫方所在的 MSCID相同， 属于局间呼叫， 因此， 在判断 模块 77的判断结果为是的情况下，发送模块 79还用于向主叫方所在的 MSC 返回位置响应消息， 其中， 该位置响应消息中携带有指示主叫方与被叫方在 同一个 MSCID的标识， 以使在没有被叫方的用户记录的情况下， 主叫方所 在的备份 MSC进行被叫接续时， 在第一 MSCID对应的范围进行寻呼。 冲艮据本发明实施例提供的上述位置寄存器， 可以在接收到主叫 MSC发 送的位置请求时， 向被叫用户所在的 MSC 发送携带有被叫用户所在的 MSCID的路由请求， 从而可以在被叫用户所在的备份 MSC没有被叫用户的 用户数椐时， 立即将被叫用户作为被叫， 并且， 不会消耗太多的无线资源。 虽然本发明实施例以 MSC的主备容灾为例来描述本发明， 但本发明并 不限于主备容灾， 对于其它各种方式的 MSC容灾， 本发明同样适用。 如上所述， 借助本发明实施例提供的技术方案， 被叫方的 HLR在接收 到来自主叫方所在的 MSC发送的位置请求时， #居该位置请求中携带的主 叫方所在的 MSCID， 判断主叫方与被叫方是否在同一 MSCID, 如果是， 则 向主叫方返回相应的指示， 否则， HLR在向被叫方所在的 MSC发送的路由 请求中携带被叫方当前所在的 MSCID, 以使得在被叫方所在的备份 MSC中 没有被叫方的用户数据时，备份 MSC可以在该 MSCID所标识的范围内进行 寻呼。 从而可以解决容灾倒换后用户立即做被叫的问题， 并且， 采用本发明 实施例提供的技术方案， 不会消耗太多的硬件资源及无线资源， 可以保证主 用 MSC的性能， 提高系统的稳定性。 以上所述仅为本发明的优选实施例而已， 并不用于限制本发明， 对于本 领域的技术人员来说， 本发明可以有各种更改和变化。 凡在本发明的精神和 原则之内， 所作的任何修改、 等同替换、 改进等， 均应包含在本发明的保护 范围之内。

Claims

权 利 要 求 书
1. 一种基于移动交换中心 MSC容灾的呼叫处理方法， 其特征在于， 包括： 被叫方的归属位置寄存器 HLR接收来自主叫方所在的 MSC的位置 请求， 其中， 所述位置请求中携带有所述主叫方当前所在位置对应的第 一 MSCID;
如果所述 HLR确定所述被叫方当前登记的第二 MSCID与所述第一 MSCID不同， 则向所述被叫方所在的 MSC发送携带所述第二 MSCID 的路由请求；
在没有所述被叫方的用户数据的情况下， 所述被叫方所在的备份 MSC进行被叫接续时， 在所述第二 MSCID对应的范围进行寻呼。
2. 根据权利要求 1所述的方法， 其特征在于， 在所述 HLR发送所述路由请 求之后， 所述方法还包括：
所述被叫方所在的备份 MSC接收所述路由请求， 并^^据所述第二 MSCID , 为呼叫分配临时本地号码 TLDN, 将所述 TLDN携带在路由响 应中返回给所述 HLR;
所述 HLR将接收到的所述 TLDN携带在位置响应中返回给所述主 叫方所在的 MSC;
所述主叫方所在的 MSC 艮据所述 TLDN继续进行呼叫， 发送携带 所述 TLDN的呼叫建立请求。
3. 根据权利要求 2所述的方法， 其特征在于， 所述备份 MSC在所述第二 MSCID对应的范围进行寻呼包括：
所述备份 MSC接收到所述呼叫建立请求， 获取与所述 TLDN对应 的所述第二 MSCID;
所述备份 MSC获取所述第二 MSCID对应的位置信息， 并向与所 述位置信息对应的一个或多个基站控制器发送寻呼请求；
所述备份 MSC接收所述一个或多个基站控制器中的一个基站控制 器返回的寻呼响应。 根据权利要求 3所述的方法， 其特征在于， 在所述备份 MSC接收到所 述寻呼响应之后， 所述方法还包括：
所述备份 MSC向所述 HLR发送所述被叫方的登记请求； 所述备份 MSC接收所述 HLR返回的登记响应， 继续接续呼叫。 根据权利要求 1所述的方法， 其特征在于， 所述方法还包括：
如果所述 HLR确定所述第二 MSCID与所述第一 MSCID相同， 则 向所述主叫方所在的 MSC 返回位置响应， 其中， 所述位置响应中携带 有指示主叫方与被叫方在同一个 MSCID的标识；
在没有所述被叫方的用户记录的情况下， 所述主叫方所在的备份 MSC进行被叫接续时， 在所述第一 MSCID对应的范围进行寻呼。 根据权利要求 5所述的方法， 其特征在于， 所述主叫方所在的备份 MSC 在所述第一 MSCID对应的范围进行寻呼包括：
所述主叫方所在的备份 MSC获取所述第一 MSCID对应的位置信 息， 并向与所述位置信息对应的一个或多个基站控制器发送寻呼请求； 所述主叫方所在的备份 MSC接收所述一个或多个基站控制器中的 一个基站控制器返回的寻呼响应。 根据权利要求 6所述的方法， 其特征在于， 所述主叫方所在的备份 MSC 接收到所述寻呼响应之后， 所述方法还包括：
所述主叫方所在的备份 MSC向所述 HLR发送所述被叫方的登记请 求；
所述主叫方所在的备份 MSC接收所述 HLR返回登记响应，继续接 续呼叫。 根据权利要求 1至 7中任一项所述的方法，其特征在于，在如果所述 HLR 确定所述被叫方当前登记的第二 MSCID与所述第一 MSCID不同，则向 所述被叫方所在的 MSC发送携带所述第二 MSCID的路由请求之前， 所 述方法还包括：
所述被叫方所在的 MSC在接收到被叫方所在的基站控制器发送的 位置更新请求后， 向所述 HLR发送所述被叫方的登记请求， 该登记请求 中携带有所述被叫方当前所在位置对应的 MSCID; 所述 HLR接收到所述登记请求后， 更新所述被叫方的用户信息， 其中， 所述用户信息包括所述 MSCID。
9. 一种位置寄存器， 其特征在于， 包括：
接收模块， 用于接收来自主叫方所在的 MSC的位置请求， 其中， 所述位置请求用于请求被叫方的位置信息， 且携带有所述主叫方当前所 在位置对应的第一 MSCID;
存储模块， 用于存储所述位置寄存器所管理的用户当前登记的 MSCID;
获取模块，用于获取所述存储模块存储的所述被叫方当前登记的第 二 MSCID;
判断模块， 用于判断所述第一 MSCID与所述第二 MSCID是否相 同；
发送模块， 用于在所述判断模块的判断结果为否的情况下， 向所述 被叫方所在的 MSC发送路由请求， 其中， 所述路由请求中携带有所述 第二 MSCID。
10. 根据权利要求 9所述的位置寄存器， 其特征在于， 在所述判断模块的判 断结果为是的情况下， 所述发送模块还用于向所述主叫方所在的 MSC 返回位置响应消息， 其中， 所述位置响应消息中携带有指示所述主叫方 与所述被叫方在同一个 MSCID的标识。
PCT/CN2010/072114 2009-06-02 2010-04-23 基于移动交换中心容灾的呼叫处理方法及位置寄存器 WO2010139214A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200910140605.X 2009-06-02
CNA200910140605XA CN101577885A (zh) 2009-06-02 2009-06-02 基于移动交换中心容灾的呼叫处理方法及位置寄存器

Publications (1)

Publication Number Publication Date
WO2010139214A1 true WO2010139214A1 (zh) 2010-12-09

Family

ID=41272633

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2010/072114 WO2010139214A1 (zh) 2009-06-02 2010-04-23 基于移动交换中心容灾的呼叫处理方法及位置寄存器

Country Status (2)

Country Link
CN (1) CN101577885A (zh)
WO (1) WO2010139214A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101577885A (zh) * 2009-06-02 2009-11-11 中兴通讯股份有限公司 基于移动交换中心容灾的呼叫处理方法及位置寄存器
CN108513019B (zh) * 2017-02-27 2020-09-29 北京京东尚科信息技术有限公司 一种实现自动呼叫分配服务集群的方法和系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101001465A (zh) * 2006-12-30 2007-07-18 华为技术有限公司 一种寻呼被叫用户的方法、系统和msc/vlr
CN101132635A (zh) * 2006-03-11 2008-02-27 华为技术有限公司 一种漫游号码的分配方法
CN101577885A (zh) * 2009-06-02 2009-11-11 中兴通讯股份有限公司 基于移动交换中心容灾的呼叫处理方法及位置寄存器

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101132635A (zh) * 2006-03-11 2008-02-27 华为技术有限公司 一种漫游号码的分配方法
CN101001465A (zh) * 2006-12-30 2007-07-18 华为技术有限公司 一种寻呼被叫用户的方法、系统和msc/vlr
CN101577885A (zh) * 2009-06-02 2009-11-11 中兴通讯股份有限公司 基于移动交换中心容灾的呼叫处理方法及位置寄存器

Also Published As

Publication number Publication date
CN101577885A (zh) 2009-11-11

Similar Documents

Publication Publication Date Title
US11871295B2 (en) Registration management method for terminal accessing 5G network on non-3GPP access
JP6651633B2 (ja) データスケジューリング方法、基地局およびシステム
EP2783538B1 (en) Paging off-line state terminals
US11716703B2 (en) Paging method and paging device
US10555273B2 (en) Mobile wireless communication device and method
JP3801982B2 (ja) 組合せモバイルｉｐシステム及びこれを用いたモビリティ管理方法
WO2012126437A2 (zh) 寻呼终端的方法和装置及系统
WO2008000123A1 (fr) Système, dispositif et procédé pour gérer une défaillance d'un noeud de commutation mobile
WO2012079518A1 (zh) 一种获取终端位置信息的方法、系统和设备
GB2497073A (en) A virtual mobility manager stores context information for an offline communications terminal
WO2007045138A1 (fr) Procede et systeme de prevention d'une defaillance d'un appel mobile demande
WO2009049515A1 (fr) Procédé, dispositif et système de récupération appelée dans un groupement de centres de commutation mobiles
CN110463295B (zh) 一种寻呼方法及装置
WO2018041100A1 (zh) 一种网络侧位置区更新的方法和装置
WO2010139214A1 (zh) 基于移动交换中心容灾的呼叫处理方法及位置寄存器
US8868114B2 (en) Network entity for mobile communications
WO2012072013A1 (zh) 下发寻呼的方法、核心网设备和接入网设备
WO2014086208A1 (zh) 电路域交换网络业务的处理方法、装置及mme
WO2013149427A1 (zh) 短消息业务提供方法及装置
KR20120124359A (ko) 기지국의 통신 방법, 단말의 통신 방법 및 중계국의 통신 방법
WO2006097028A1 (fr) Procede de connexion d’un centre de commutation pour le trafic des mobiles appelant avec un terminal mobile appele

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: 10782918

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: 10782918

Country of ref document: EP

Kind code of ref document: A1