WO2009146664A1 - 呼叫切换、处理方法及装置与系统 - Google Patents

呼叫切换、处理方法及装置与系统 Download PDF

Info

Publication number
WO2009146664A1
WO2009146664A1 PCT/CN2009/072172 CN2009072172W WO2009146664A1 WO 2009146664 A1 WO2009146664 A1 WO 2009146664A1 CN 2009072172 W CN2009072172 W CN 2009072172W WO 2009146664 A1 WO2009146664 A1 WO 2009146664A1
Authority
WO
WIPO (PCT)
Prior art keywords
call
endpoint
message
value
base station
Prior art date
Application number
PCT/CN2009/072172
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 华为技术有限公司
Priority to BRPI0914796A priority Critical patent/BRPI0914796A2/pt
Priority to RU2011127660/07A priority patent/RU2520573C9/ru
Priority to CN2009801217304A priority patent/CN102282888B/zh
Priority to EP09757098A priority patent/EP2291025A4/en
Publication of WO2009146664A1 publication Critical patent/WO2009146664A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0033—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/103—Media gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1096—Supplementary features, e.g. call forwarding or call holding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/10—Reselecting an access point controller
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/16—Gateway arrangements

Definitions

  • the present invention relates to the field of mobile communications, and in particular, to a call handover, processing method, and apparatus and system. Background technique
  • the Global System for Mobile communication was originally based on Time Division Multiple (TDM) transmission to transmit signals. Later, with the continuous development and popularization of Internet Protocol (IP) technology, the core network (Core Network, referred to as CN) has been fully IP-enabled, and introduced the A-interface signaling plane IP between the CN and the access network.
  • IP Internet Protocol
  • Transmission SI GTRAN the architecture diagram of the GSM system is shown in Figure 1, where the dotted line indicates the signaling plane (Signing) and the solid line indicates the user plane (User plane).
  • the user interface of the A interface still uses the T-style, which becomes the last obstacle to the IP of the whole network.
  • 3GPP Third Generation Partnership Project
  • 3GPP proposed IP-based A-interface transport bearer (A interface over IP, referred AoIP), to discuss the A interface user plane IP-based solution.
  • the coaxial cable is used to connect the CN to the Base Station Controller (BSC).
  • BSC Base Station Controller
  • Each call occupies a 64 kbps time slot (Timeslot) on the coaxial cable. That is, the user plane transmission of a call must occupy a fixed time slot resource, so the original protocol uses a Call ID Code (CIC) to uniquely identify a call.
  • the length of the CIC cell is 2 bytes.
  • 5 bits XXXXX can be used to identify the specific time of use. Gap number, use ak a total of 11 bits to identify the relay number used: CIC expression ⁇ Table 1: Table 1
  • the route between the CN and the BSC is no longer a fixed link. Since the call identification code and the slot number of the fixed link are no longer corresponding, the circuit identification code CIC may no longer be used to identify A call, and then a Call Identifier (Call IID) is introduced to identify the call.
  • Call IID Call Identifier
  • MSC Mobile Switching Center
  • SCCP Signaling Connection Control Part
  • the Call-ID can be used as the object to request the other party to release the relevant call resources synchronously. .
  • the network is configured as MSC pool A-flex (MSC in Pool), some of the CaU-ID lists are exceptionally efficient when the call is in error due to an abnormal address.
  • Call-ID When the network supports AoIP, the call can be uniquely identified by the Call-ID on the relevant BSC and MSC; and the BSC needs to return the MSC in the Assignment Complete message (Assignment Complete message) and the Handover Request Acknowledge message.
  • Assignment Complete message Assignment Complete message
  • Handover Request Acknowledge message The value of Call-ID of Xihexin.
  • IP address + UDP port number For the mode of (IP address + UDP port number) pair, if the version used is IPv4, the IP address overhead is 4 bytes, plus 2 bytes of the port (port), then the address pair is needed. At least 12 bytes; for IPv6, the IP address overhead is 16 bytes, plus 2 bytes identifying the port, the address pair needs at least 36 bytes.
  • the element identification code is 1 byte (8 bits) and the element entity is 4 bytes (32 bits).
  • the MSC can use the Call-ID value to identify the call and the Assignment Request.
  • the message carries the Call-ID cell, and the BSC uses the same Call-ID value, but at the same time, the BSC may also choose to use the TDM method, that is, the BSC must provide a CIC cell to the MSC and use a specific CIC value.
  • the assigned TDM endpoint is identified, at which point the MSC and BSC still allow the call to be identified using the Call-ID.
  • the MSC Server (MSC-S) can only be the target first.
  • the BSC applies for both TDM and IP endpoints on the MGW.
  • the handover process is shown in Figure 1.
  • the handover request message (Handover Request message) carries the MSC- Preferred Codec List
  • the Channel Type cell cannot be carried at the same time, so that the CIC cannot be carried in the handover request message.
  • the cell (even if the request message is switched objectively enough to carry the CIC).
  • the target BSC may allocate and return a value of the CIC that does not match the TDM endpoint that has been created on the MGW.
  • the MSC Server will be the MGW side and the target BSC. Side The CIC does not match and enters the exception handling process and releases the call.
  • the inventor has found that at least the following defects exist in the prior art: UP address + UDP port number)
  • the identification mode byte cost of the pair is too large, and the IP and UDP information in the AoIP Conta iner cell are redundant. Otherwise, the actual resources (IP, por t values) after switching may not match the indicated values.
  • the handover request message cannot carry the MSC-PCL and the CIC cell at the same time, so that the CIC value allocated by the target BSC may not match the CIC value corresponding to the TDM endpoint that the MGW has created, resulting in a defect of the call failure.
  • the embodiment of the present invention provides a call handover and processing method, a device, and a system, to solve the defect that the TOM endpoint of the target BSC and the TDM endpoint allocated by the MGW may not match in the call handover process of the prior art, resulting in a call failure.
  • a call handover method is provided according to an embodiment of the present invention, including:
  • the embodiment of the invention further provides a call switching system, including:
  • Adding an endpoint response receiving module configured to receive an increased endpoint response message sent by the media gateway;
  • a handover request message module configured to: when the add endpoint response message indicates that the media gateway successfully establishes a TDM endpoint and an IP endpoint, send a handover request message carrying a circuit identifier and an IP type endpoint information to the target base station controller;
  • a handover confirmation message module configured to receive the handover request acknowledgement message returned by the target base station controller, and when the handover request acknowledgement message carries the IP type endpoint information, indicating that the target base station controller selects an IP port mode.
  • the embodiment of the invention further provides a call handover method, including:
  • a handover request acknowledgement message is returned after receiving the call identified by the target base station controller with the Call-ID value.
  • the embodiment of the invention further provides a call processing method, including:
  • the failure message or the handover failure message is sent to the mobile switching center, and the failure reason indication value includes a Call-ID already existing or a Call-ID format error.
  • the embodiment of the invention further provides a call switching device, including:
  • a second handover requesting module configured to receive an increase endpoint response message sent by the media gateway to complete the establishment of the IP endpoint, and send a handover request message carrying the call identity Call-ID consisting of the network element identifier and the network element call identifier to the target base station control Or selecting an unoccupied Call-ID value from the CaU-ID value interval allocated for the mobile switching center, and transmitting a handover request message carrying the selected Call-ID value to the target base station controller; Assigned between mobile switching centers The Call-ID value intervals do not overlap each other;
  • the acknowledgment receiving module is configured to receive a handover request acknowledgement message returned after the target base station controller establishes a call identified by the Call-ID value.
  • the embodiment of the invention further provides a call processing device, including:
  • a message receiving module configured to receive an allocation request message carrying a call identifier CaU-ID, or receive a handover request message carrying a call identifier Call-ID;
  • a failure message sending module configured to return an allocation failure message carrying the failure cause indication value to the mobile switching center when the call fails to be allocated according to the allocation request message carrying the call identifier Call-ID received by the message receiving module,
  • the failure reason indication value includes that the Call-ID already exists or the Call-ID format is incorrect;
  • the indication value includes the Call-ID already existing or the Call-ID format error.
  • the embodiment of the present invention carries the CIC value and the IP endpoint information in the handover request message sent to the target BSC, so that when the target BSC selects the TDM type endpoint, the CIC value allocated by the MSC can be directly used, thereby avoiding the target BSC and The TOM endpoints that are independently assigned on the MGW side do not match, resulting in a call failure, which improves the call success rate.
  • FIG. 1 is a schematic diagram of a prior art GSM network architecture
  • FIG. 3 is a flowchart of Embodiment 1 of a call handover method according to an embodiment of the present invention
  • FIG. 4 is a flowchart of Embodiment 2 of a call handover method according to an embodiment of the present invention.
  • FIG. 5 is a flowchart of Embodiment 3 of a call handover method according to an embodiment of the present invention.
  • FIG. 6 is a flowchart of Embodiment 4 of a call handover method according to an embodiment of the present invention
  • FIG. 7 is a flowchart of Embodiment 5 of a call handover method according to an embodiment of the present invention
  • FIG. 8 is a schematic structural diagram of a call handover system according to an embodiment of the present invention
  • FIG. 9 is a schematic structural diagram of a call switching apparatus according to an embodiment of the present invention.
  • FIG. 10 is a flowchart of a call setup method according to an embodiment of the present invention.
  • FIG. 11 is a schematic structural diagram of a call setup apparatus according to an embodiment of the present invention.
  • FIG. 12 is a flowchart of Embodiment 1 of a call processing method according to an embodiment of the present invention.
  • FIG. 13 is a flowchart of Embodiment 2 of a call processing method according to an embodiment of the present invention.
  • FIG. 14 is a schematic structural diagram of a call processing apparatus according to an embodiment of the present invention. detailed description
  • the embodiment of the present invention provides a call handover method, including: receiving an add endpoint response message sent by a media gateway; when the add endpoint response message indicates that the media gateway successfully establishes a time division multiplexing TDM endpoint and an internet protocol IP endpoint, Sending a handover request message carrying the circuit identification code and the IP type endpoint information to the target base station controller; and receiving the handover request acknowledgement message returned by the target base station controller, when the handover request acknowledgement message carries the IP type port information Indicates that the target base station controller selects the IP port mode, otherwise it indicates that the target base station controller selects the TDM port mode.
  • the MSC Server may also first send an Add Endpoint Request message to the MGW, and the added Endpoint Response message is obtained.
  • FIG. 3 a schematic diagram of a call handover method according to an embodiment of the present invention is shown in FIG. 1.
  • the source BSC of the embodiment is BSC1
  • the target BSC of this embodiment is BSC2
  • BSC1 and BSC2 belong to the same MSC.
  • the specific steps include:
  • Step 111 Send an end point request message that carries the TDM type end point information and the encoding information corresponding to the TDM type, and the IP type end point information and the encoding information corresponding to the IP type to the MGW.
  • the encoding information may also include Calling the recommended coding information;
  • Step 113 When receiving an increased endpoint response indicating that the MGW successfully establishes a TDM endpoint and an IP endpoint
  • the handover request message carrying the circuit identification code and the IP endpoint information is sent to the target base station to control the crying.
  • Step 115 Receive a handover request acknowledgement message that carries the TDM type endpoint information or the IP type endpoint information returned by the target BSC.
  • the call handover method and apparatus in the embodiment of the present invention by carrying the CI C value and the IP endpoint information in the handover request message sent to the target BSC, so that when the target BSC selects the endpoint of the Ty type, the CIC allocated by the MSC can be directly used.
  • the value of the TDM endpoints that are independently assigned by the target BSC and the MGW side does not match, resulting in a call failure, which improves the call success rate, and saves resource overhead by creating TDM endpoints and IP endpoints respectively.
  • the speed of the switch by carrying the CI C value and the IP endpoint information in the handover request message sent to the target BSC, so that when the target BSC selects the endpoint of the Ty type, the CIC allocated by the MSC can be directly used.
  • FIG. 4 it is a schematic diagram of a second embodiment of a call handover method according to an embodiment of the present invention; in this embodiment, a TDM port mode is selected by a target BSC as an example; a source BSC in this embodiment is a BSC1, and a target BSC in this embodiment.
  • BSC1 and BSC2 belong to the same MSC.
  • the specific steps include: Step 211: The BSC1 sends a handover request (Handover Requ i red ) message to the MSC Server; the handover request message carries the voice coding RanCl (Ran Codec, access network voice coding) currently used by the user MS and the BSC1;
  • RanCl Real Codec, access network voice coding
  • Step 21 After receiving the handover request message, the MSC Server sends an addend request message (ADD.Req) to the MGW, where the message carries the recommended voice coding information ( prefer red RanC, pRanC for short) and carries the endpoint information.
  • the endpoint information may include an endpoint type that needs to be created by the MGW, that is, a TDM endpoint and an IP endpoint;
  • the user MS uses the AoIP interface to perform normal voice services under BSC1. Both BSC1 and BSC2 belong to the same MSC.
  • the MS wants to be handed over to the BSC2 by the BSC1, since the MSC Server does not know the current (dynamic) voice coding support capability and the related A interface type of the BSC2, in order to ensure fast and successful handover, before cutting into the BSC2, at the MGW
  • the IP endpoint and TDM endpoint paired with BSC2 need to be created for BSC2 first.
  • Step 215 The MGW creates a TDM endpoint and an IP endpoint paired with the BSC2 according to the received addendum request message, and returns an add endpoint response message (ADD.Reply), where the message carries the created Endpoint type, this embodiment is a TDM endpoint and an IP endpoint;
  • ADD.Reply add endpoint response message
  • Step 217 the MSC Server receives the add endpoint response message, and sends a handover request message (Handover Reques t ) to the BSC2;
  • the handover request message carries MSC-PCL1 (the speech coding is arranged in the recommended order, wherein the updated pRanC is the optimal recommended speech coding), the TDM endpoint and the IP endpoint, and the TOM endpoint information may include the CIC cell.
  • the value of the CIC cell may be the CIC1 value corresponding to the TDM endpoint created by the MGW;
  • Step 219 The BSC2 receives the handover request message, accepts the CIC1 value, selects the voice coding RanC2 from the MSC-PCL1, and carries the RanC2, the CI C1 value, and the currently supported voice coding list of the BSC2 in the handover request acknowledgement message, and returns it to the MSC Server;
  • the MSC Server can learn that the BIC2 selects the A interface of the TDM transmission mode according to the CIC cell carried in the message. Therefore, the endpoint type selected by the BSC2 is the same as the TDM endpoint type that has been created on the MGW, because the TDM endpoint has been created on the MGW;
  • the value of the CIC carried is CIC1, that is, the value of the CI C cell is the same as the value of the CI C cell in the handover request message.
  • the MSC Server must carry the CIC cell and explicitly indicate the value of the CIC in the handover request message sent to the BSC2.
  • Step 221 The MSC Server receives the handover request acknowledgement message, and determines that the BSC2 selects the TDM transmission mode, and sends a modified endpoint request message (MOD.Req) carrying the RanC2 coding type selected by the BSC2 to the MGW.
  • MOD.Req modified endpoint request message
  • Step 223 The MGW modifies the created TDM endpoint, so that the TDM endpoint can use the coding type.
  • the TDM endpoint is activated at the same time, so that the TDM link between the MGW and the BSC2 is established, the call service can be performed, and then the MGW returns a modified endpoint response message (MOD.Reply) to the MSC Server;
  • MOD.Reply modified endpoint response message
  • Step 225 The MSC Server sends a Delete Endpoint Request message (SUB.Req) carrying the IP endpoint information created by the MGW to the MGW.
  • SUB.Req Delete Endpoint Request message
  • the IP endpoint created by the previous MGW is not guaranteed. It is necessary to leave, so the endpoint can be released.
  • Step 227 The MGW deletes the previously created IP port, and returns a Delete Endpoint Response message (SUB.Reply) to the MSC Server.
  • Step 229 The MSC Server sends a handover command message (Handover Command) to the BSC1, where the handover command message carries the coding type RanC2 selected by the BSC2.
  • Handover Command a handover command message
  • Step 231 The BSC1 sends the handover command message to the MS.
  • the RanC2 By switching the command message, the RanC2 is notified to the MS, and the handover of the MS is triggered.
  • the MS adjusts the handover to the allocated channel of the BSC2 according to the handover command message, and simultaneously modifies its own voice coding type to RanC2, and then can use RanC2; RanC2 is the same as RanCl, then the MS continues to use RanCl.
  • steps 225-227 and steps 229-231 are not limited to this embodiment, and steps 225-227 may be performed before steps 229-231 or after steps 229-231. .
  • the embodiment of the present invention can ensure that when the target BSC selects the A interface of the TDM transmission mode, the target BSC can select the same CIC value that is allocated in advance with the core network, thereby ensuring the normal progress of the call after the handover, and optimizing the call handover procedure.
  • FIG. 5 it is a flowchart of a third embodiment of a call handover method according to an embodiment of the present invention.
  • This example is an example of a method in which a target BSC selects a TDM port, which specifically includes:
  • Step 311 The BSC1 sends a handover request message to the MSC Server, where the handover request message carries the voice coding RanCl currently used by the user MS and BSC1;
  • Step 31 After receiving the handover request message, the MSC Server sends an addend request message to the MGW.
  • the message carries the voice code pRanC recommended by the MSC, and carries the endpoint information.
  • the endpoint information may include the type of the endpoint that needs to be created by the MGW. This embodiment is an IP endpoint;
  • Step 315 The MGW creates an IP endpoint paired with the BSC2 according to the received endpoint request message, and returns an endpoint response message, where the message carries the created IP endpoint information.
  • Step 317 The MSC Server receives the add endpoint response message, and sends a handover request message to
  • the handover request message carries MSC-PCL1 (the speech coding is arranged in the recommended order, the updated pRanC is the optimal recommended speech coding), the IP endpoint information, and the like;
  • Step 319 The BSC2 receives the handover request message, selects the TDM type endpoint, assigns the value to CIC1, and selects the corresponding voice coding type RanC2 from the MSC-PCL1, and carries the value of the RanC2 and the CICl and the currently supported voice coding list of the BSC2 in the handover.
  • the request confirmation message is returned to the MSC Server; the CIC1 value in the message indicates that the BSC2 selects the TDM transmission mode, so the TDM endpoint needs to be created correspondingly on the MGW;
  • Step 321 The MSC Server determines that the TDM type endpoint selected by the BSC2 is inconsistent with the created IP endpoint type on the MGW, and sends an add endpoint request message carrying the TDM endpoint information and the RanC2 created on the BSC2 to the MGW.
  • the MGW has created a corresponding IP endpoint for the BSC2, the BSC2 finally selects the TDM transmission mode. Therefore, the MSC Server also needs to notify the MGW to establish a corresponding TDM endpoint for the BSC2.
  • Step 323 The MGW creates a TDM endpoint paired with the BSC2 according to the voice coding type RanC2 and the TDM endpoint information in the endpoint message, and returns an endpoint response message to the MSC Server after the TDM endpoint is successfully created.
  • Step 325 the MSC Server sends a handover command message (Handover Command) to the BSC1, and the message carries the voice coding type RanC2;
  • Handover Command handover command message
  • Step 327 The BSC1 sends the handover command message to the MS.
  • Step 329 The MSC Server sends a delete endpoint request message carrying the information of the previously created IP endpoint to the MGW.
  • Step 331 The MGW deletes the corresponding IP endpoint, and returns the delete endpoint response message to the MSC.
  • This embodiment does not limit the order of steps 325-327 and steps 329-331, and steps 325-327 may be before steps 329-331. It can also be performed after steps 329-331.
  • the handover request message sent by the MSC Server to the BSC2 does not carry the channel type (Channe l Type) cell and the CIC cell, that is, the core network does not allocate the TDM endpoint first, and the BSC2 receives the handover request message.
  • the CIC value assigned by the BSC2 is carried in the returned handover request acknowledgement message, and then the MSC Server receives the handover request acknowledgement message, and then notifies the MGW to allocate the TDM paired with the BSC2 according to the CIC value. Endpoint, and release the previously created IP endpoint;
  • the handover request message sent by the MSC Server to the BSC2 does not carry the Channe l Type cell, but carries the CIC cell, that is, the core network first allocates the TDM endpoint while assigning the IP endpoint, BSC2
  • the CIC value of the core network is accepted, and the CIC value is explicitly used in the CIC cell carried in the returned handover request acknowledgement message, that is, the value of the CIC must be consistent with the CIC value carried in the handover request message.
  • the MSC Server then notifies the MGW to modify and activate the TDM endpoint on the MGW, while releasing the previously created IP endpoint.
  • the embodiment of the present invention can ensure that when the target BSC selects the A interface of the TDM transmission mode, the target BSC can select the same CIC value that is allocated in advance with the core network, thereby ensuring the normal progress of the call after the handover, and optimizing the call handover procedure. Further, the embodiment of the present invention firstly creates an endpoint, and when the created endpoint is inconsistent with the endpoint type selected by the target BSC, the endpoint of the type selected by the target BSC is created and matched with the endpoint selected by the BSC, thereby solving the existing In the technology, all types of endpoints are created first, resulting in slow switching speed and waste of resources.
  • FIG. 6 it is a flowchart of a fourth embodiment of a call handover method according to an embodiment of the present invention.
  • an IP transmission mode is selected by a target BSC as an example. Steps 411-415 of the embodiment and step 211 of the second embodiment. -215 is the same, the difference is that BSC2 selects the IP transmission mode as follows:
  • Step 417 the MSC Server receives the add endpoint response message, and sends a handover request message (Handover Reques t) to the BSC2;
  • the handover request message carries MSC-PCL1 (the speech coding is arranged in the recommended order, the updated pRanC is the optimal recommended speech coding), the TDM endpoint and the IP endpoint, and the TDM endpoint information.
  • the information may include a CIC cell, and the value of the CIC cell may be a CIC1 value corresponding to the TDM endpoint created by the MGW;
  • Step 419 The BSC2 receives the handover request message, selects the voice coding RanC2 from the MSC-PCL, and carries information such as the IP endpoint created by the RanC2 and the BSC2 in the handover request acknowledgement message to the MSC Server;
  • the IP endpoint information carried in the message indicates that the BSC2 selects the A interface of the IP transmission mode, so that the IP address created in advance on the MGW can be modified and activated according to the RanC2 selected by the BSC2, and the IP routing link can be activated.
  • Step 421 The MSC Server receives the handover request acknowledgement message, and learns that the BSC2 selects the IP transmission mode and is consistent with the created IP endpoint type, and therefore sends the modified endpoint request message (MOD. Req) carrying the IP endpoint information of the BSC2 and the RanC2.
  • MOD. Req modified endpoint request message
  • Step 423 The MGW modifies the created IP endpoint, so that the IP endpoint can use the coding type RanC2, and activate the IP endpoint, so that the IP routing link between the MGW and the BSC2 is established, the call service can be performed, and then the MGW returns to modify the endpoint response.
  • Step 425 If the MGW creates a TDM type endpoint, the MSC Server sends a Delete Endpoint Request message (SUB.Req) carrying the TDM endpoint information created by the MGW to the MGW;
  • the TOM endpoint created by the previous MGW has no reservation, so the endpoint can be released.
  • Step 427 The MGW deletes the previously created TDM endpoint, and returns a delete endpoint response message.
  • Step 429 The MSC Server sends a handover command message (Handover Command) to the BSC1, where the handover command message carries the coding type RanC2 selected by the BSC2.
  • Handover Command a handover command message
  • Step 431 The BSC1 sends the handover command message to the MS.
  • the RanC2 By switching the command message, the RanC2 is notified to the MS, and the handover of the MS is triggered.
  • the MS adjusts the handover to the channel allocated by the BSC2 according to the handover command message, and simultaneously modifies its own voice coding type. For RanC2, then RanC2 can be used; if RanC2 and RanCl are the same, MS continues to use RanCl.
  • the handover request message sent to the BSC2 in step 417 still needs to carry the CIC value allocated for the TDM endpoint created by the MGW, because the MSC Server is not yet Know which endpoint type BSC2 will choose.
  • Steps 425-427 may be before steps 429-431 or after steps 429-431.
  • the embodiment of the present invention carries the CIC value of the TDM endpoint created for the MGW in the message sent to the target BSC, thereby effectively ensuring that when the target BSC selects the TDM transmission mode, the target BSC and the core network select the same CIC, thereby optimizing the CIC. Call switching process.
  • FIG. 7 is a flowchart of Embodiment 5 of a call handover method according to an embodiment of the present invention. This embodiment includes:
  • Step 711 The BSC1 sends a handover request message to the MSC Server, where the message carries the voice coding RanCl currently used by the BSC1.
  • Step 713 After receiving the handover request message, the MSC Server sends an Add Endpoint Request message (ADD.Req) to the MGW, where the message carries the recommended voice coding (preferred RanC, pRanC for short), and carries the endpoint information, for example, the endpoint.
  • the information may include an endpoint type that needs to be created by the MGW, that is, an IP endpoint;
  • Step 715 The MGW creates an IP endpoint paired with the BSC2 according to the received addendum request message, and returns an Add Endpoint Response message (ADD.Reply), where the message carries the created endpoint information, that is, the IP endpoint information.
  • ADD.Reply Add Endpoint Response message
  • Step 717 The MSC Server receives the addend response message, and sends a handover request message (Handover Reques t) to the BSC2.
  • the handover request message carries the Ca l l- ID2 allocated by the MSC Server.
  • Step 719 The BSC2 receives the handover request message, accepts the Call_ID2, selects the voice code RanC2 from the MSC-PCL, and carries the created IP endpoint information, RanC2, and Call-ID2 in the handover request acknowledgement message, and returns the message to the MSC Server.
  • the MSC Server receives the handover request acknowledgement message, and learns that the BSC2 selects the IP transmission mode, and sends the IP endpoint information carrying the BSC2 and the modified endpoint request message (MOD.Req) of the RanC2 to the MGW.
  • the MGW modifies the created IP endpoint.
  • the BSC is connected to multiple MSC Servers. Different MSC Servers cannot guarantee the allocation of Call-IDs with different values.
  • the method of assigning a range of Call-ID values to each MSC Server in the entire network can be used.
  • the value of the 32-bit length of the Call-ID may be segmented according to the number of network elements in the network, for example, the number of MSC Servers, and each MSC Server uses a segment of Call-ID; or MSC in each pool. Server shares a range of values for Cal 1-ID.
  • MSC Server 1, MSC Server2, and MSC Server 3 form a shared pool.
  • MSC Server2 assigns a Call-ID with a value of 3 to a call
  • MSC Server 2 notifies MSC Server1 and MSC Server3, and MSC Server1 and MSC Server3 are no longer.
  • Assign a Call-ID call with a value of 3 similarly, when MSC Server 2 releases a call with a Call-ID of value 3, it also notifies MSC Server1 and MSC Server 3, then MSC Server1 and MSC Server 3 A Ca l l-ID with a value of 3 can be assigned.
  • the "network element identifier" can use the signaling point code, the IP address that uniquely identifies the network element, and the network element number assigned internally by the entire network.
  • the "network element identifier” can uniquely identify the network element within the entire network. For example, the identity of the MSC Server.
  • the "network element call identifier" indicates the number that the network element can assign to the call. It can be a call identifier value that is uniformly assigned within the network element. A specific range of values can be used to indicate the specific call identifier value. The specific assignment of the number can be The network element is controlled. The network element can not only uniformly allocate the call identification value, but also manage and delete the assigned call identification values.
  • the call handover method in the embodiment of the present invention uses a combination of a network element identifier and a network element call identifier to represent a Ca l l-ID, or assigns a different Ca l l-ID value range to the network element in advance, from the respective
  • the value of the Ca l l-ID is assigned to the call, so that the uniqueness of the Ca 11 _ ID is guaranteed, so that the BSC does not receive the same value of the Ca l l-ID; Success rate.
  • An embodiment of the present invention provides a call handover system, including an endpoint response receiving module, configured to receive an increased endpoint response message sent by a media gateway, and a handover request message module, configured to: when the add endpoint response message indicates the media gateway When the TDM endpoint and the IP endpoint are successfully established, the handover request message carrying the circuit identifier and the IP type endpoint information is sent to the target base station controller, and the handover confirmation message module is configured to receive the handover request acknowledgement message returned by the target base station controller. When the handover request acknowledgement message carries the IP type endpoint information, it indicates that the target base station controller selects an IP port mode.
  • FIG. 8 is a schematic structural diagram of a call handover system according to an embodiment of the present invention.
  • the embodiment includes: adding an endpoint request module 1, a first handover request module 2, and a handover confirmation module 3.
  • the addend request module 1 is configured to send coded information carrying the TDM type endpoint information and the call recommendation corresponding to the TDM type, and the IP type endpoint information and the call recommendation code corresponding to the IP type.
  • Adding an Endpoint Request message to the media gateway; the first handover requesting module 2 is configured to: when receiving the added endpoint response message of the TDM endpoint and the IP endpoint successfully, the media gateway transmits the information carrying the circuit identification code cell and the IP endpoint information
  • the handover request message is sent to the target base station controller.
  • the handover confirmation module 3 is configured to receive a handover request acknowledgement message that carries the TDM type endpoint information or the IP type endpoint information returned by the target base station controller.
  • the embodiment further includes a deletion module 4, configured to notify the deletion and the TDM type endpoint information or the IP type endpoint information carried in the handover request acknowledgement message returned by the target base station controller when the TDM endpoint and the IP endpoint are successfully established.
  • the successfully established endpoint that has different endpoint types indicated by the endpoint information carried in the handover request acknowledgement message.
  • the module 5 is further configured to determine whether the type of the endpoint indicated by the endpoint information carried in the handover request acknowledgement message is the same as the endpoint type indicated in the established endpoint information carried by the endpoint response message.
  • the embodiment further includes an establishment endpoint module 6 configured to establish a TDM endpoint and an IP endpoint according to the received enhanced endpoint request message, and return an increased endpoint response message that the TDM endpoint and the IP endpoint have been successfully established.
  • the endpoint type selection module 7 is configured to receive a handover request message, and send a handover request acknowledgement message carrying the selected endpoint information.
  • FIG. 9 is a schematic structural diagram of a call switching apparatus according to an embodiment of the present invention.
  • the embodiment includes: a second handover requesting module 8 configured to receive, after receiving, an end point response message sent by a media gateway to complete establishment of an IP endpoint, Sending a handover request message carrying the call identity Ca U-ID composed of the network element identifier and the network element call identifier to the target base station controller; or selecting one of the Ca l l-ID value intervals allocated for the mobile switching center is not selected The value of the occupied value of the Ca l l-ID is sent to the target base station controller, and the value ranges of the Ca l l-IDs allocated by the mobile switching centers do not overlap each other.
  • the acknowledgment receiving module 9 may be further configured to receive a handover request acknowledgement message carrying the value of the Ca 11 - 1 D returned after the target base station controller establishes the call identified by the Ca U-ID value.
  • Step 611 The BSC1 sends a Layer 3 (Complete Layer 3) message to the MSC Server, where the message carries the BSC-SCL1, which indicates the voice coding information currently supported by the BSC1, and also indicates that the BSC1 supports the IP type on the A interface.
  • Layer 3 Complete Layer 3
  • Step 613 The MS sends a Direct Transfer Application Part (DTAP) message to the MSC Server, where the message carries the MS-SCL1, which indicates the voice coding information supported by the MS.
  • DTAP Direct Transfer Application Part
  • Step 615 The MSC Server receives the layer 3 message and the DTAP message, selects the best recommended code from the intersection of the coded information supported by the BSC1 and the MS, and then sends an addend request message to the MGW, where the message carries the best recommendation. Encoding, indicating that the MGW establishes an IP endpoint according to the code of the optimal recommendation;
  • Step 617 The MGW receives the add endpoint request message, establishes an IP endpoint according to the best recommended code in the message, and then returns an add endpoint response message to the MSC Server.
  • Step 619 The MSC Server sends an Assignment Request message (BSC1), where the message carries the established IP end point information of the Call-ID1 and the MGW allocated by the MSC Server to the BSC1;
  • BSC1 Assignment Request message
  • Step 621 The BSC1 establishes a connection between the MS and the BSC1, and sends an Assignment Complete message (Assignment Complete) to the MSC Server, where the message carries the created IP endpoint, the coding type selected for the IP endpoint, and the Call-ID1 information.
  • Step 623 The MSC Server sends a modify endpoint request message to the MGW, where the message carries the IP endpoint allocated by the BSC1 and the selected coding information.
  • Step 625 The MGW receives the modified endpoint request message, and modifies the created IP endpoint, so that the IP endpoint can use the encoding type carried in the modified endpoint request message, and activate the IP endpoint, so that the IP link between the MGW and the BSC1 is established. Finish, then return to modify the endpoint response message.
  • the BSC is connected to multiple MSC Servers.
  • the MSC Server cannot guarantee the allocation of a Call-ID with a different value.
  • the method for allocating a range of Call-ID values for each MSC Server in the entire network can be used.
  • the value of the 32-bit length of the Call-ID may be segmented according to the number of network elements in the network, for example, the number of MSC Servers, and each MSC Server uses a segment of Call-ID; or the MSC Server in each pool. Share the range of values for a Call-ID.
  • MSC Server1, MSC Server2, and MSC Server 3 form a shared pool.
  • MSC Server2 assigns a Call-ID with a value of 3 to a call
  • MSC Server 2 notifies MSC Server1 and MSC Server3, and MSC Server1 and MSC Server3 are no longer. Assigning a Call-ID with a value of 3;
  • the "network element identifier” can use the signaling point code, the IP address that uniquely identifies the network element, and the network element number assigned internally by the entire network.
  • the "network element identifier” can uniquely identify the network element within the entire network. That is, the identity of the MSC Server.
  • the "network element call identifier” indicates the number that the network element can assign to the call.
  • a specific range of values can be used to indicate the specific call identifier value.
  • the specific allocation of the number can be controlled by the network element, for example, "network element identifier”.
  • the signalling point is coded, and the Call-ID is expressed as shown in Table 3: table 3
  • the "network element call identifier” is a call identifier value uniformly allocated within the network element, and uses a length of 4 bytes as shown in Table 2, which is enough for a single network element to allocate a call, and the expression of the "network element call identifier" part The method is shown in Table 4:
  • n is the byte length of the "signaling point coded address information" portion of Table 4.
  • 0/E is an odd/even flag:
  • the bit 8 of the octet 3 indicates the odd/even of the number of address signals contained in the address information, specifically:
  • Bits 1-7 of octet 3 representing the attributes of the address information, specifically:
  • each address signal occupies 4 bits, and its expression is as shown in Table 6:
  • the Call-ID is represented by a combination of the network element identifier and the network element call identifier, or a different Call-ID value range is assigned to the network element in advance, from the respective The Call_ID value is assigned to the call in the Call_ID value range, so that the uniqueness of the Cal 1-ID is guaranteed, so that the BSC does not receive the same Call-ID; the call setup success rate is improved.
  • FIG. 11 it is a schematic structural diagram of a call setup apparatus according to an embodiment of the present invention.
  • This embodiment includes: an allocation requesting module 10, configured to receive an add endpoint response message sent by a media gateway after completing establishment of an IP endpoint, and then The call identifier Ca 11 - 1 D composed of the meta identifier and the network element call identifier is carried in the allocation request message and sent to the base station controller; or an unoccupied Call is selected from the Call-ID value interval allocated for the mobile switching center.
  • the -ID value transmitting an allocation request message carrying the selected Call-ID value to the base station controller.
  • the embodiment may further include a completion message receiving module 11 for receiving an allocation completion message carrying the Call-ID value returned after the base station controller establishes the call identified by the CaU-ID value.
  • Steps 811-819 of the embodiment are the same as steps 611-619 of the embodiment shown in FIG. 8, and the difference is as follows:
  • Step 821 The BSC1 receives the allocation request message sent by the MSC Server, and obtains the value of the Call-ID carried in the message.
  • the BSC1 determines whether the value of the Call-ID already exists in the BSC1 and determines whether the identification mode of the Call-ID is valid. And if the existing and/or the identification mode is invalid, sending an allocation failure message carrying the Call-ID and/or the corresponding failure reason indication value to the MSC Server; the reason for the call setup failure in this embodiment includes the BSC receiving the duplicate value.
  • Call-ID value, voice coding type is not supported, resources are unavailable, Call-ID identification mode is invalid, etc. These reasons may also cause the call to fail.
  • the Call-ID ID is invalid.
  • the cause indication value contains "Call-ID format error" to indicate that the Call-ID is invalid.
  • the BSC receives the Call-ID value of the duplicate value, and the failure cause indication value includes "Call-ID already exists”.
  • Step 823 The MSC Server terminates the call process corresponding to the value of the Call-ID.
  • Step 919 The BSC2 receives the handover request message, obtains the value of the Call-ID in the handover request message, and the BSC2 determines whether the value of the Call-ID already exists in the BSC2, and determines whether the identification mode of the Call-ID is valid. If the existing and/or the identification mode is invalid, sending a handover failure message carrying the Cal 1-ID and/or the corresponding failure reason indication value to the MSC Server;
  • the reason for the call handover failure in this embodiment includes that the BSC receives the Call-ID value of the duplicate value, the voice coding type is not supported, the resource is unavailable, and the CaU-ID identification mode is invalid. These reasons all cause the call to fail. If the Call-ID is invalid, for example, if the Call-ID is one bit less, the BSC2 can determine that the format of the Call-ID is in error, and then notify the MSC Server of the failure cause indication value including "Call-ID format error". If the BSC receives the Cal 1-ID value of the duplicate value, it notifies the MSC Server of the failure cause indication value including "Call_ID already exists".
  • Step 921 The MSC Server terminates the handover process corresponding to the value of the Call-ID.
  • the call processing method of the embodiment of the present invention can effectively process the call of the BSC receiving the repeated value of the Call-ID. Specifically, the MSC Server is notified by carrying the Call-ID with the same value in the allocation failure message or the handover failure message, so that the MSC Server can terminate the abnormal call flow caused by the repeated Ca 11 - 1 D according to the value of the Call-ID.
  • FIG. 14 is a schematic structural diagram of an embodiment of a call processing apparatus according to an embodiment of the present invention.
  • the embodiment includes a message receiving module 12, configured to receive an allocation request message carrying a call identity Call-ID, or receive a call identification identifier CaU.
  • the failure message sending module 13 is configured to receive an allocation request message carrying the call identifier CaU-ID, and when the assignment fails according to the received assignment request message carrying the call identifier Call-ID, the return carries the The value of the Call-ID and/or the failure indication of the corresponding failure reason indication value is sent to the mobile switching center, and the failure reason indication value includes a Call-ID existing or a Call-ID format error; or, for receiving the call identification identity Call a handover request message of the ID, when the call fails to be allocated according to the received handover request message carrying the call identity Call-ID, returning a handover failure message carrying the value of the Call-ID and/or the corresponding failure cause indication value to the
  • the mobile switching center can also send a failure cause indication value that contains "Call-ID format error" or "Call-ID already exists".
  • the method may further include: a handover response module 14 configured to: when the value of the Ca l l-ID does not exist in the target base station controller and the identification mode is valid, return a handover request acknowledgement message after the call assignment is completed; and/or allocate the response module 15 . For returning the allocation completion message after the call allocation is completed, when the value of the Ca l l-ID does not exist in the target base station controller and the identification mode is valid.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

呼叫切换、 处理方法及装置与系统 技术领域
本发明涉及移动通信领域， 尤其涉及一种呼叫切换、 处理方法及装置 与系统。 背景技术
全球移动通信系统 ( Global System for Mobile communication, 简称 GSM)最初是基于时分复用 （Time Division Multiple, 简称 TDM)传输方式 来传输信号。 后来随着互联网协议（ Internet Protocol, 简称 IP )技术的 不断发展和普及， 核心网 （Core Network, 简称 CN ) 已全面实现 IP化， 并 引入了 CN和接入网间的 A接口信令面 I P传输 S I GTRAN , GSM系统的架构图如 图 1所示，其中虚线表示信令面（ Signaling ),实线表示用户面（User plane )。 该架构中只剩下 A接口用户面仍釆用 T丽方式， 成为全网 IP化的最后障碍。 于是第三代合作伙伴计划 ( 3rd Generation Partnership Project, 简称 3GPP) 提出了基于 IP传输承载的 A接口 （A interface over IP, 简称 AoIP), 来 讨论 A接口用户面 IP化的解决方案。
在 A接口釆用 TDM传输方式时，使用同轴电缆固定链路来连接 CN和基站 控制器 （Base Station Controller, 简称 BSC), 每一个呼叫占用该同轴电 缆上的一个 64kbps 时隙 （Timeslot ), 即一个呼叫的用户面传输必定占用固 定的一个时隙资源， 因此原协议使用呼叫标识码 I电路识别码 （ Ca 11 Identifier Code or Circuit Identifier Code, 简称 CIC ) 来唯一标识一 个呼叫。 CIC信元的长度为 2个字节， 对于使用 2M带宽的同轴电缆（即一个 中继， 其可以复用为 32个 64kbps时隙）， 可以用 5个比特位 XXXXX来标识使 用的具体时隙编号， 用 a-k共 11个比特位来标识使用的中继号： CIC的表达 方式 ^表 1所示： 表 1
Figure imgf000004_0001
当引入 AoIP以后， CN和 BSC之间的路由不再是固定链路， 由于呼叫标 识码和固定链路的时隙号不再——对应， 因此也就可能无法再使用电路标识 码 CIC 来标识一个呼叫， 于是引入了呼叫标识 （Call Identifier, 简称 Call-ID) 来标识呼叫。 当移动交换中心 (Mobile Switching Center, 简称 MSC)或 BSC失去了对方的信令连接控制部分（ Signaling Connect ion Control Part, 简称 SCCP)链接时， 可以以 Call-ID为对象要求对方同步释放相关呼 叫资源。 如果网络配置为 MSC池 A-flex (MSC in Pool ), 有些由于地址异常 而导致呼叫出错， 从而需要批量释放呼叫时， CaU-ID 的列表就显得格外高 效了。
当网络支持 AoIP时，在相关的 BSC和 MSC上可以使用 Call-ID唯一标识 一个呼叫； 且 BSC 需要在 Assignment Complete 消息 （分配完成消息）和 Handover Request Acknowledge消息、 （切换请求确认消息 中返回 MSC分西己 的 Call-ID数值。 Call-ID的表达方式有两种：
1、 （ IP地址 +UDP端口号）对
对于 （IP地址 +UDP端口号）对的方式， 如果釆用的版本为 IPv4, 则一 个 IP地址开销为 4字节， 再加上标识端口 （ port )的 2字节， 则该地址对就 需要至少 12字节； 而对于 IPv6,—个 IP地址开销为 16字节，加上标识 port 的 2字节， 则该地址对至少需要 36字节。
1、 与承载无关的数值 ( a bearer- independent number )
对于该方式， 为了保证同一时刻该标识值的唯一性， 目前有如下用 32比 特位的数值来表达的方案， 具体如下表所示:
表 2
Figure imgf000005_0001
其中元素标识码为 1个字节（8比特位）， 元素实体为 4个字节（ 32比特 位）。
当 BSC 在层三消息 ( Complete Layer3 消息） 中携带了 BSC-SCL (BSC- Supported Codec List, 能够表示 BSC支持 AoIP), 那么 MSC就可以 用 Call-ID数值方式来标识该呼叫， 并在 Assignment Request 消息中携带 Call-ID信元， BSC也就使用相同的 Call-ID值， 但同时 BSC也可能会因为最 终选择使用 TDM方式， 即 BSC必须向 MSC提供一个 CIC信元并用一个具体的 CIC数值来标识分配的 TDM端点， 这时 MSC和 BSC还是允许使用 Call-ID标 识该呼叫。
呼叫过程中当用户终端在属于同一 MSC的两个 BSC之间切换， 由于目标 BSC并没有向 MSC上才艮其当前对 A接口的支持能力， 因此 MSC Server ( MSC-S ) 只能先为目标 BSC在 MGW上同时申请 TDM、 IP两种类型的端点， 其切换流程 如图 1所示。 由于在目前的方案中规定， 切换请求消息 （Handover Request 消息） 中携带 MSC-PCL (MSC- Preferred Codec List ) 的情况下就不能再同 时携带 Channel Type信元， 从而导致切换请求消息中不能携带 CIC信元（即 使客观上切换请求消息足够携带 CIC )。 目标 BSC在接收到该切换请求消息后 如果选择 TDM端点， 就艮可能分配并返回 MSC Server一个与 MGW上已创建的 TDM端点不匹配的 CIC的值， 这时 MSC Server会因为 MGW侧和目标 BSC侧的 CIC不匹配而进入异常处理流程并释放该呼叫。
在发明人实现本发明的过程中， 发现现有技术至少存在以下缺陷： UP 地址 +UDP端口号）对的标识方式字节开销太大， 与 AoIP Conta iner信元中 的 IP、 UDP信息存在冗余， 且发生切换后实际的资源 （IP、 por t值）可能与 指示值不一致。 而且切换请求消息中存在不能同时携带 MSC-PCL和 CIC信元 的限制， 从而导致目标 BSC分配的 CIC值可能与 MGW已创建的 TDM端点对应 的 CIC值不匹配， 导致呼叫失败的缺陷。
此外与承载无关的数值的标识方式中，例如在同一 BSC连接多个 MSC (即 MSC in Pool ) 的情况下， Pool 中的多个 MSC如果不能合理且及时地协调分 配 Ca l l-ID值； 则在某一时刻给同一 BSC分配了数值相同的 Ca l l-ID的可能 性较大， 而且现有技术中没有针对 BSC收到重复 Ca l l-ID值的处理流程。 发明内容
本发明实施例提供一种呼叫切换、 处理方法及装置与系统， 以解决现 有技术呼叫切换过程中目标 BSC的 TOM端点与 MGW分配的 TDM端点可能不匹 配， 导致呼叫失败的缺陷。
根据本发明实施例提供一种呼叫切换方法， 包括：
接收媒体网关发送的增加端点响应消息；
当所述增加端点响应消息指示所述媒体网关成功建立时分复用 TDM端点 和因特网协议 IP端点时， 发送携带有电路识别码和 IP类型端点信息的切换 请求消息至目标基站控制器；
接收所述目标基站控制器返回的切换请求确认消息， 当所述切换请求确 认消息中携带 IP类型端点信息时， 表明所述目标基站控制器选择的是 IP端 口方式。
本发明实施例还提供了一种呼叫切换系统， 包括：
增加端点响应接收模块， 用于接收媒体网关发送的增加端点响应消息； 切换请求消息模块， 用于当所述增加端点响应消息指示所述媒体网关成 功建立 TDM端点和 IP端点时， 发送携带有电路识别码和 IP类型端点信息的 切换请求消息至目标基站控制器；
切换确认消息模块， 用于接收所述目标基站控制器返回的切换请求确认 消息， 当所述切换请求确认消息中携带 IP类型端点信息时， 表明所述目标基 站控制器选择的是 IP端口方式。
本发明实施例还提供了一种呼叫切换方法， 包括：
接收到媒体网关发送的指示完成建立 IP端点的增加端点响应消息； 发送携带有网元标识和网元呼叫标识组成的呼叫标识 Call-ID的切换请 求消息至目标基站控制器； 或者， 从为移动交换中心分配的 CaU-ID取值区 间中选择一个没有被占用的 Call-ID值， 发送携带有所述选择的 Call-ID值 的切换请求消息至目标基站控制器； 各移动交换中心分配到的 CaU-ID取值 区间互不重叠；
接收所述目标基站控制器建立以所述 Call-ID值标识的呼叫之后返回切 换请求确认消息。
本发明实施例还提供了一种呼叫处理方法， 包括：
接收携带呼叫标识 CaU-ID的分配请求消息或切换请求消息， 当根据所 述携带呼叫标识 Call-ID的分配请求消息或切换请求消息分配呼叫失败时， 返回携带有所述失败原因指示值的分配失败消息或切换失败消息给移动交换 中心， 所述失败原因指示值包括 Call-ID已存在或 Call-ID格式错误。
本发明实施例还提供了一种呼叫切换装置， 包括：
第二切换请求模块，用于接收到媒体网关发送的完成建立 IP端点的增加 端点响应消息；发送携带有网元标识和网元呼叫标识组成的呼叫标识 Call-ID 的切换请求消息至目标基站控制器；或者，从为移动交换中心分配的 CaU-ID 取值区间中选择一个没有被占用的 Call-ID 值， 发送携带有所述选择的 Call-ID值的切换请求消息至目标基站控制器； 各移动交换中心之间分配到 的 Call-ID取值区间互不重叠；
确认接收模块， 用于接收所述目标基站控制器建立以所述 Call-ID值标 识的呼叫之后返回的切换请求确认消息。
本发明实施例还提供了一种呼叫处理装置， 包括：
消息接收模块， 用于接收携带呼叫标识 CaU-ID的分配请求消息， 或者 接收携带呼叫标识 Call-ID的切换请求消息；
失败消息发送模块， 用于当根据所述消息接收模块接收的携带呼叫标识 Call-ID 的分配请求消息分配呼叫失败时， 返回携带有所述失败原因指示值 的分配失败消息给移动交换中心， 所述失败原因指示值包括 Call-ID 已存在 或 Call-ID格式错误；
或，用于当根据所述消息接收模块接收的携带 Ca 1 ID的切换请求消息分 配呼叫失败时， 返回携带有所述失败原因指示值的切换失败消息给所述移动 交换中心， 所述失败原因指示值包括 Call-ID已存在或 Call-ID格式错误。
本发明实施例通过在发送给目标 BSC的切换请求消息中携带 CIC值和 IP 端点信息， 使得当目标 BSC选择 TDM类型的端点时， 可以直接使用 MSC分配 的该 CIC值， 从而避免了目标 BSC和 MGW侧各自独立分配的 TOM端点不匹配 而导致呼叫失败的情况， 提高了呼叫成功率。
附图说明
图 1为现有技术 GSM网络架构示意图；
图 2为现有技术呼叫切换流程图；
图 3为本发明实施例提供的呼叫切换方法实施例一流程图
图 4为本发明实施例提供的呼叫切换方法实施例二流程图
图 5为本发明实施例提供的呼叫切换方法实施例三流程图
图 6为本发明实施例提供的呼叫切换方法实施例四流程图 图 7为本发明实施例提供的呼叫切换方法实施例五流程图； 图 8为本发明实施例提供的呼叫切换系统结构示意图；
图 9为本发明实施例提供的呼叫切换装置结构示意图；
图 10为本发明实施例提供的呼叫建立方法流程图；
图 11为本发明实施例提供的呼叫建立装置结构示意图；
图 12为本发明实施例提供的呼叫处理方法实施例一流程图；
图 13为本发明实施例提供的呼叫处理方法实施例二流程图；
图 14为本发明实施例提供的呼叫处理装置结构示意图。 具体实施方式
本发明实施例提供了一种呼叫切换方法， 包括： 接收媒体网关发送的增 加端点响应消息； 当所述增加端点响应消息指示所述媒体网关成功建立时分 复用 TDM端点和因特网协议 IP端点时， 发送携带有电路识别码和 IP类型端 点信息的切换请求消息至目标基站控制器； 并接收所述目标基站控制器返回 的切换请求确认消息， 当所述切换请求确认消息中携带 IP类型端口信息时， 表明所述目标基站控制器选择的是 IP端口方式，否则表明所述目标基站控制 器选择的是 TDM端口方式。
在上述实施例的基础上， MSC Server还可以首先向 MGW发送增加端点请 求消息， 已获取增加端点响应消息。
如图 3所示， 为本发明实施例提供的呼叫切换方法实施例一示意图； 本实 施例的源 BSC为 BSC1 , 本实施例的目标 BSC为 BSC2 , BSC1和 BSC2属于同一 MSC。 具体步骤包括：
步骤 111、发送携带有 TDM类型端点信息及该 TDM类型对应的编码信息， 和 IP类型端点信息及该 IP类型对应的编码信息的增加端点请求消息给 MGW,优选 的， 所述编码信息也可以包括呼叫推荐的编码信息；
步骤 113、当接收到指示 MGW成功建立 TDM端点和 IP端点的增加端点响应消 息时， 发送携带有电路识别码和 IP端点信息的切换请求消息至目标基站控制 哭口.？
步骤 115、接收目标 BSC返回的携带 TDM类型端点信息或 IP类型端点信息的 切换请求确认消息。 本发明实施例的呼叫切换方法和装置， 通过在发送给目 标 BSC的切换请求消息中携带 CI C值和 IP端点信息， 使得当目标 BSC选择 T丽类 型的端点时， 可以直接使用 MSC分配的 C I C值， 从而避免了目标 BSC和 MGW侧各 自独立分配的 TDM端点不匹配而导致呼叫失败的情况， 提高了呼叫成功率， 同 时通过分别创建 TDM端点和 IP端点的方式， 节省了资源开销， 提高了切换的速 度。
如图 4所示， 为本发明实施例提供的呼叫切换方法实施例二示意图； 本 实施例以目标 BSC选择了 TDM端口方式为例； 本实施例的源 BSC为 BSC1 , 本 实施例的目标 BSC为 BSC2 , BSC1和 BSC2属于同一 MSC。 具体步骤包括： 步骤 211、 BSC1发送切换申请（Handover Requ i red )消息给 MSC Server ; 该切换申请消息中携带用户 MS和 BSC1当前使用的语音编码 RanCl ( Ran Codec , 接入网语音编码）；
步骤 21 3、 MSC Server收到该切换申请消息后， 向 MGW发送增加端点请 求消息 ( ADD. Req ), 该消息中携带推荐的语音编码信息 ( prefer red RanC , 简称 pRanC ), 同时携带端点信息， 例如， 端点信息可以包括需要 MGW创建的 端点类型， 即 TDM端点和 IP端点；
用户 MS在 BSC1下使用 AoIP接口进行正常的语音业务， BSC1和 BSC2都 属于同一 MSC。 当 MS要由 BSC1切换进入 BSC2 , 由于此时 MSC Server并不知 道 BSC2当前（动态）的语音编码的支持能力和相关的 A接口类型， 因此， 为 保证快速并成功切换， 切入 BSC2之前， 在 MGW上需要先为 BSC2创建与 BSC2 配对的 IP端点和 TDM端点。
步骤 215、 MGW根据接收到的增加端点请求消息创建与 BSC2配对的 TDM 端点和 IP端点， 并返回增加端点响应消息（ADD. Rep ly ), 该消息中携带创建 的端点类型， 本实施例为 TDM端点和 IP端点；
步骤 217、 MSC Server 接收到增加端点响应消息， 发送切换请求消息 ( Handover Reques t )给 BSC2 ;
该切换请求消息中携带 MSC-PCL1 (语音编码按推荐的次序排列， 其中更 新的 pRanC为最优推荐的语音编码）、 TDM端点和 IP端点等信息， 其中 TOM 端点信息可以包含 CIC信元， 该 CIC信元的值可以为 MGW创建的 TDM端点对 应的 CIC1值；
步骤 219、 BSC2接收到切换请求消息， 接受 CIC1值， 从 MSC-PCL1中选 择语音编码 RanC2 , 将 RanC2、 CI C1值和 BSC2当前支持的语音编码列表携带 在切换请求确认消息中返回给 MSC Server ;
MSC Server根据该消息中携带的 CIC信元可以得知 BSC2选择了 TDM传 输方式的 A接口， 因此 BSC2选择的端点类型与 MGW上已创建的 TDM端点类型 一致， 因为 MGW上已创建 TDM端点； 当该消息中需要携带 C IC信元时， 携带 的 CIC的值为 CIC1 ,即 CI C信元的值与切换请求消息中的 CI C信元的值一样。 当核心网分配了与 BSC2 配对的 TDM端点资源， 则本实施例中， MSC Server 在发给 BSC2的切换请求消息中就必须携带 CIC信元并明确指示 CIC的值。
步骤 221、 MSC Server接收到切换请求确认消息， 判断出 BSC2选择了 TDM传输方式， 发送携带有 BSC2选择的 RanC2编码类型的关于 TDM端点的修 改端点请求消息 ( MOD. Req )给 MGW;
步骤 223、 MGW修改创建的 TDM端点， 使得该 TDM端点能够使用编码类型
RanC2 , 同时将该 TDM端点激活， 使得 MGW和 BSC2间的 TDM链路建立完成， 可以进行呼叫业务， 然后 MGW返回修改端点响应消息 （MOD. Rep ly )给 MSC Server ;
步骤 225、 MSC Server发送携带有 MGW创建的 IP端点信息的删除端点请 求消息 ( SUB. Req )给 MGW;
由于 BSC2最终选择了 TDM传输方式， 之前 MGW创建的 IP端点就没有保 留的必要了， 所以可以释放该端点。
步骤 227、 MGW将之前创建的 IP 端口删除， 并返回删除端点响应消息 ( SUB. Rep ly )给 MSC Server。
步骤 229、 MSC Server发送切换命令消息 ( Handover Command )给 BSC1 , 该切换命令消息中携带 BSC2选用的编码类型 RanC2 ;
步骤 231、 BSC1将该切换命令消息发送给 MS。
通过切换命令消息， 将 RanC2通知给 MS , 并触发 MS的切换， MS根据该 切换命令消息调整切换到 BSC2的分配信道上， 同时修改自身的语音编码类型 为 RanC2 , 然后就可以使用 RanC2了； 如果 RanC2和 RanCl相同， 则 MS继续 使用 RanCl。
本实施例中，本实施例对步骤 225-227与步骤 229-231的顺序不 ^1限制， 步骤 225-227可以是在步骤 229-231之前也可以在步骤 229-231之后执行。。
本发明实施例能够保证当目标 BSC选择 TDM传输方式的 A接口时， 目标 BSC能够选用与核心网事先分配的相同的 CIC值， 从而保证了切换以后呼叫 的正常进行， 优化了呼叫切换流程。
如图 5所示， 为本发明实施例提供的呼叫切换方法实施例三流程图， 本 实施例以目标 BSC选择了 TDM端口方式为例， 具体包括：
步骤 311、 BSC1发送切换申请消息给 MSC Server , 该切换申请消息中携 带用户 MS和 BSC1当前使用的语音编码 RanCl ;
步骤 31 3、 MSC Server收到该切换申请消息后， 向 MGW发送增加端点请 求消息； 该消息中携带 MSC推荐的语音编码 pRanC , 同时携带端点信息， 例 如， 端点信息可以包括需要 MGW创建的端点类型， 本实施例为 IP端点；
步骤 315、 MGW根据接收到的增加端点请求消息创建与 BSC2配对的 IP端 点， 并返回增加端点响应消息， 该消息中携带创建的 IP端点信息；
步骤 317、 MSC Server接收到增加端点响应消息， 发送切换请求消息给
BSC2 ; 该切换请求消息中携带 MSC-PCLl (语音编码按推荐的次序排列， 更新的 pRanC为最优推荐的语音编码）、 IP端点信息等；
步骤 319、 BSC2接收到切换请求消息， 选择 TDM类型端点，赋值为 CIC1 , 并从 MSC-PCL1中选择相应的语音编码类型 RanC2 ,将 RanC2、CICl的值和 BSC2 当前支持的语音编码列表携带在切换请求确认消息中返回给 MSC Server; 该消息中携带 CIC1值表示 BSC2选择了 TDM传输方式， 因此 MGW上相应 地需要创建 TDM端点；
步骤 321、 MSC Server判断得出 BSC2选择的 TDM类型端点与 MGW上已创 建的 IP端点类型不一致，则发送携带有 BSC2上创建的 TDM端点信息和 RanC2 的增加端点请求消息给 MGW;
虽然之前 MGW为 BSC2创建了对应的 IP端点， 但是 BSC2最终选择的是 TDM传输方式， 因此 MSC Server还需要通知 MGW再为 BSC2建立一个对应的 TDM端点；
步骤 323、 MGW根据增加端点消息中的语音编码类型 RanC2和 TDM端点信 息创建与 BSC2配对的 TDM端点；并在创建 TDM端点成功后返回增加端点响应 消息给 MSC Server;
步骤 325、 MSC Server发送切换命令消息 ( Handover Command )给 BSC1 , 消息中携带语音编码类型 RanC2;
步骤 327、 BSC1将该切换命令消息发给 MS;
步骤 329、 MSC Server发送携带有事先创建的 IP端点的信息的删除端点 请求消息给 MGW;
步骤 331、 MGW将对应的 IP端点删除， 并返回删除端点响应消息给 MSC 本实施例对步骤 325-327与步骤 329-331的顺序不做限制，步骤 325-327 可以是在步骤 329-331之前也可以在步骤 329-331之后执行。
由实施例二和实施例三可得， BSC2决定使用 TDM传输方式的 A接口时， 分配 CIC的方式有两种：
( 1 )如实施例三， MSC Server发送给 BSC2的切换请求消息中不携带信 道类型 （ Channe l Type )信元和 CIC信元， 即核心网不先行分配 TDM端点， BSC2接收到切换请求消息， 决定使用 T丽传输方式的 A接口电路之后， 在返 回的切换请求确认消息中携带 BSC2指派的 CIC值， 然后 MSC Server收到该 切换请求确认消息之后根据该 CIC值通知 MGW分配与 BSC2配对的 TDM端点， 并释放之前创建的 IP端点；
( 2 )如实施例二， MSC Server 发送给 BSC2 的切换请求消息中不携带 Channe l Type信元， 但是携带 CIC信元， 即核心网先行在分配了 IP端点的 同时也分配了 TDM端点， BSC2收到切换请求消息后， 接受核心网分配的 CIC 值， 在返回的切换请求确认消息携带的 CIC信元中明确使用该 CIC值， 即该 CIC的值必须与切换请求消息中携带的 CIC值一致。然后 MSC Server通知 MGW 修改并激活 MGW上的 TDM端点， 同时释放之前创建的 IP端点。
本发明实施例能够保证当目标 BSC选择 TDM传输方式的 A接口时， 目标 BSC能够选用与核心网事先分配的相同的 CIC值， 从而保证了切换以后呼叫 的正常进行， 优化了呼叫切换流程。 进一步地， 本发明实施例通过先创建一 个端点， 当该创建的端点与目标 BSC选择的端点类型不一致时， 再创建目标 BSC选择的类型的端点并与 BSC选择的端点匹配， 从而解决了现有技术中先 创建所有类型的端点造成的切换速度慢和资源浪费。
如图 6所示， 为本发明实施例提供的呼叫切换方法实施例四流程图， 本 实施例以目标 BSC选择 IP传输方式为例，本实施例的步骤 411-415与实施例 二的步骤 211-215相同， 其区别在于 BSC2选择 IP传输方式， 如下：
步骤 417、 MSC Server 接收到增加端点响应消息， 发送切换请求消息 ( Handover Reques t )给 BSC2;
该切换请求消息中携带 MSC-PCL1 (语音编码按推荐的次序排列， 更新的 pRanC为最优推荐的语音编码）、 TDM端点和 IP端点等信息， 其中 TDM端点信 息可以包含 CIC信元，该 CIC信元的值可以为 MGW创建的 TDM端点对应的 CIC1 值；
若 MGW只创建了 I P端点，则本步骤中的切换请求消息中不携带 C I C信元。 步骤 419、 BSC2接收到切换请求消息 ,从 MSC-PCL中选择语音编码 RanC2 , 将 RanC2和 BSC2创建的 IP端点等信息携带在切换请求确认消息中返回给 MSC Server ;
该消息中携带的 IP端点信息表示 BSC2选择了 IP传输方式的 A接口， 因 此只要根据 BSC2选择的 RanC2修改并激活 MGW上事先创建的 IP端点并激活 IP路由链路即可；
步骤 421、 MSC Server接收到切换请求确认消息， 获知 BSC2选择了 IP 传输方式， 与已创建的 IP端点类型一致， 因此发送携带有 BSC2的 IP端点信 息和 RanC2的修改端点请求消息 ( MOD. Req )给 MGW;
步骤 423、 MGW修改创建的 IP端点， 使得该 IP端点能够使用编码类型 RanC2 , 同时将该 IP端点激活， 使得 MGW和 BSC2之间 IP路由链路建立， 可 以进行呼叫业务，然后 MGW返回修改端点响应消息（ MOD. Rep ly ) ^ MSC Server ; 步骤 425、 若之前 MGW创建了 TDM类型的端点， 则 MSC Server发送携带 有 MGW创建的 TDM端点信息的删除端点请求消息 ( SUB. Req )给 MGW;
由于 BSC2选择了 IP传输方式， 所以之前 MGW创建的 TOM端点就没有保 留的必要了， 所以可以释放该端点。
步骤 427、 MGW将之前创建的 TDM端点删除， 并返回删除端点响应消息
( SUB. Rep ly )给 MSC Server
步骤 429、 MSC Server发送切换命令消息 ( Handover Command )给 BSC1 , 该切换命令消息中携带 BSC2选用的编码类型 RanC2 ;
步骤 431、 BSC1将该切换命令消息发送给 MS;
通过切换命令消息， 将 RanC2通知给 MS , 并触发 MS的切换， MS根据该 切换命令消息调整切换到 BSC2分配的信道上， 同时修改自身的语音编码类型 为 RanC2 , 然后就可以使用 RanC2了； 如果 RanC2和 RanCl相同， 则 MS继续 使用 RanCl。
本实施例的步骤 417之前若 MGW创建了 TDM类型的端点， 则步骤 417中 发送给 BSC2的切换请求消息中仍需携带为 MGW创建的 TDM端点分配的 C I C值， 是因为此时 MSC Server还不知道 BSC2会选择哪种端点类型。
本实施例对步骤 425-427与步骤 429-431的顺序不做限制，步骤 425-427 可以在步骤 429-431之前也可以在步骤 429-431之后。
本发明实施例通过在发给目标 BSC的消息中携带为 MGW创建的 TDM端点 的 CIC值， 从而有效保证了当目标 BSC选择 TDM传输方式时， 目标 BSC和核 心网选用相同的 CIC , 从而优化了呼叫切换流程。
如图 7所示， 为本发明实施例提供的呼叫切换方法实施例五流程图； 本 实施例包括：
步骤 711、 BSC1发送切换申请消息给 MSC Server , 该消息中携带有 BSC1 当前使用的语音编码 RanCl；
步骤 713、 MSC Server收到该切换申请消息后， 向 MGW发送增加端点请 求消息 （ADD. Req ), 该消息中携带推荐的语音编码（ preferred RanC , 简称 pRanC ), 同时携带端点信息， 例如， 端点信息可以包括需要 MGW创建的端点 类型， 即 IP端点；
步骤 715、 MGW根据接收到的增加端点请求消息创建与 BSC2配对的 IP端 点， 并返回增加端点响应消息（ADD. Rep ly ), 该消息中携带创建的端点信息， 即 IP端点信息；
步骤 717、 MSC Server 接收到增加端点响应消息， 发送切换请求消息 ( Handover Reques t )给 BSC2; 该切换请求消息中携带 MSC Server分配的 Ca l l- ID2 ;
为了避免 BSC1 同时收到来自不同 MSC Server分配的相同数值 Ca l l-ID 的呼叫请求， 应该 4巴来自不同 MSC Server的 Ca l l-ID加以区分。 由于在一个 PLMN网络中， MSC Server的数量远远少于 BSC的数量， 且 MSC Server负责 具体的呼叫业务控制， 因此本实施例中的 Cal 1-ID只能由 MSC Server进行分 配， BSC无权分配。 当某一 MSC Server分配了 Call-ID并建立了相应的呼叫， 只要该呼叫没有切换到其他的 MSC Server或者该呼叫没有被删除， 则该呼叫 的 Call-ID始终有效， 且数值不能被修改。
步骤 719、 BSC2接收到切换请求消息， 接受 Call_ID2, 从 MSC-PCL中选 择其语音编码 RanC2, 将创建的 IP端点信息、 RanC2和 Call-ID2携带在切换 请求确认消息中返回给 MSC Server; 步骤 721、 MSC Server接收到切换请求 确认消息， 获知 BSC2选择了 IP传输方式， 发送携带有 BSC2的 IP端点信息 和 RanC2的修改端点请求消息 （MOD. Req)给 MGW; 步骤 723、 MGW修改创建 的 IP端点， 使该 IP端点能够使用编码类型 RanC2, 同时将该 IP端点激活， 使得 MGW 和 BSC2 之间可以进行呼叫业务， 然后 MGW返回修改端点消息 (MOD. Reply )给 MSC Server; 步骤 725- 727: 与步骤 429- 431对应相同。
本实施例中 Call-ID的表达方式有两种：
(1 )为全网中的各个 MSC Server分别分配一段 Cal 1-ID的取值范围 对于网络中使用了共享池（MSC in Pool )方式的配置的情况下， 即 BSC 连接了多个 MSC Server, 不同的 MSC Server 不能保证分配不同数值的 Call-ID, 这时就可以釆用本实施例的为全网中的各个 MSC Server分别分配 一段 Call-ID 的取值范围的方法。 可以根据网络中网元的个数， 例如 MSC Server的个数，将 Call-ID的 32比特长度的取值范围分段，每个 MSC Server 使用一段 Call-ID; 也可以每个 Pool 中的 MSC Server共享一段 Cal 1-ID的 取值范围。 例如 MSC Server 1、 MSC Server2和 MSC Server 3组成一个共享 Pool, 当 MSC Server2为一个呼叫分配了数值为 3的 Call- ID, MSC Server 2 通知 MSC Serverl和 MSC Server3, MSC Serverl和 MSC Server3就不再分配 数值为 3的 Call- ID的呼叫；同样地当 MSC Server2释放了数值为 3的 Call- ID 的呼叫，也会通知 MSC Serverl和 MSC Server 3,则 MSC Serverl和 MSC Server 3 可以分配数值为 3的 Ca l l-ID。
( 2 )用 "网元标识" 和 "网元呼叫标识" 的组合来表示 Ca l l-ID
"网元标识" 可以釆用信令点编码、 唯一标识网元的 IP地址、 全网内部 分配的网元编号等方式， "网元标识" 为能在全网范围内唯一标识该网元， 例 如 MSC Server的标识。
"网元呼叫标识" 表示该网元为呼叫能够分配的编号， 可以为网元内部 统一分配的呼叫标识值， 可以用一定范围的数值来表示具体的呼叫标识值， 编号的具体分配可以由该网元来控制。 网元内部不仅可以统一分配该呼叫标 识值， 还对分配的这些呼叫标识值进行管理、 删除。
具体实施例可参见上述呼叫建立方法实施例的描述。
本发明实施例的呼叫切换方法， 通过用网元标识和网元呼叫标识的组合 来表示 Ca l l-ID, 或事先为网元分配不同的 Ca l l-ID 取值范围， 从各自的
Ca l l-ID取值范围中选取 Ca l l-ID分配给呼叫， 使得 Ca 11 _ I D的唯一性得到 保证， 从而保证 BSC不会收到数值相同的 Ca l l-ID; 提高了呼叫切换的成功 率。
本发明实施例提供了一种呼叫切换系统， 包括增加端点响应接收模块， 用于接收媒体网关发送的增加端点响应消息； 切换请求消息模块， 用于当所 述增加端点响应消息指示所述媒体网关成功建立 TDM端点和 IP端点时，发送 携带有电路识别码和 IP类型端点信息的切换请求消息至目标基站控制器；切 换确认消息模块， 用于接收所述目标基站控制器返回的切换请求确认消息， 当所述切换请求确认消息中携带 IP类型端点信息时，表明所述目标基站控制 器选择的是 IP端口方式。
图 8为本发明实施例提供的呼叫切换系统结构示意图， 本实施例包括： 增加端点请求模块 1 , 第一切换请求模块 2和切换确认模块 3。 其中增加端点 请求模块 1用于发送携带有 TDM类型端点信息及所述 TDM类型对应的呼叫推 荐的编码信息， 和 IP类型端点信息及所述 IP类型对应的呼叫推荐的编码信 息的增加端点请求消息给媒体网关； 第一切换请求模块 2用于当接收到媒体 网关成功建立 TDM端点和 IP端点的增加端点响应消息时，发送携带有电路识 别码信元和 IP端点信息的切换请求消息至目标基站控制器； 切换确认模块 3 用于接收目标基站控制器返回的携带 TDM类型端点信息或 IP类型端点信息的 切换请求确认消息。
本实施例还进一步包括删除模块 4 , 用于当成功建立了 TDM端点和 IP端 点时， 根据目标基站控制器返回的切换请求确认消息中携带的 TDM类型端点 信息或 IP类型端点信息，通知删除与切换请求确认消息中携带的端点信息指 示的端点类型不同的已成功建立的端点。 还可以进一步判断模块 5 , 用于判 断切换请求确认消息中携带的端点信息指示的端点类型， 与增加端点响应消 息携带的已建立的端点信息中指示的端点类型是否相同。
另外， 本实施例还包括建立端点模块 6 , 用于根据接收到的增加端点请 求消息建立 TDM端点和 IP端点， 并返回已成功建立所述 TDM端点和 IP端点 的增加端点响应消息。 端点类型选择模块 7 , 用于接收切换请求消息， 发送 携带有选择的端点信息的切换请求确认消息。
如图 9所示， 为本发明实施例提供的呼叫切换装置结构示意图， 本实施 例包括： 第二切换请求模块 8 , 用于接收到媒体网关发送的完成建立 IP端点 的增加端点响应消息之后， 发送携带有网元标识和网元呼叫标识组成的呼叫 标识 Ca U-ID的切换请求消息至目标基站控制器； 或从为移动交换中心分配 的 Ca l l-ID取值区间中选择一个没有被占用的 Ca l l-ID值， 发送携带有选择 的 Ca U-ID值的切换请求消息至目标基站控制器， 各移动交换中心分配到的 Ca l l-ID取值区间互不重叠。 还可以包括确认接收模块 9 , 用于接收所述目标 基站控制器建立以所述 Ca U-ID 值标识的呼叫之后返回的携带有所述 Ca 11 - 1 D值的切换请求确认消息。
如图 10所示， 为本发明实施例提供的呼叫建立方法流程图， 本实施例包 括： 步骤 611、 BSC1发送层 3 (Complete Layer3) 消息给 MSC Server, 该消 息中携带 BSC-SCL1, 表示 BSC1 当前支持的语音编码信息， 也表示 BSC1在 A 接口上支持 IP类型；
步骤 613、 MS 发送直接传输应用部分（Direct Transfer Application Part, 简称 DTAP ) 消息给 MSC Server, 该消息中携带 MS-SCLl , 表示 MS支 持的语音编码信息；
步骤 615、 MSC Server接收到层 3消息和 DTAP消息， 从 BSC1和 MS支持 的编码信息的交集中选出最优推荐的编码， 然后发送增加端点请求消息给 MGW, 该消息中携带最优推荐的编码， 指示 MGW根据该最优推荐的编码建立 IP端点；
步骤 617、 MGW接收到增加端点请求消息， 根据消息中的最优推荐的编码 建立 IP端点， 然后返回增加端点响应消息给 MSC Server;
步骤 619、 MSC Server发送分配请求消息（ Assignment Request )^BSC1, 该消息中携带 MSC Server分配给 BSC1的 Call-IDl和 MGW上已建立的 IP端 点信息；
为了避免 BSC1 同时收到来自不同 MSC Server分配的相同数值 Call-ID 的呼叫请求， 应该 4巴来自不同 MSC Server的 Call-ID加以区分。 由于在一个 公众陆地移动电话网 (Public Land Mobile Network, 简称 PLMN) 网络中， MSC Server的数量远远少于 BSC的数量， 且 MSC Server 负责具体的呼叫业 务控制， 因此本实施例中的 Call- ID只能由 MSC Server进行分配， BSC1无 权分配。 当某一 MSCServer分配了 Call-ID并建立了相应的呼叫， 只要该呼 叫没有切换到其他的 MSC Server或者该呼叫没有被删除，则该呼叫的 Cal 1-ID 始终有效， 且数值不能被修改。
步骤 621、 BSC1 建立 MS 和 BSC1 之间的连接， 发送分配完成消息 (Assignment Complete )给 MSC Server, 该消息中携带有创建的 IP端点、 为 IP端点选择的编码类型和 Call-IDl等信息； 步骤 623、 MSC Server发送修改端点请求消息给 MGW,该消息中携带 BSC1 分配的 IP端点和选用的编码信息；
步骤 625、 MGW接收到该修改端点请求消息， 修改创建的 IP端点， 使该 IP端点能够使用修改端点请求消息中携带的编码类型， 并激活 IP端点， 使 得 MGW和 BSC1之间的 IP链路建立完成， 然后返回修改端点响应消息。
本实施例中 Call-ID的表达方式有两种：
(1 )为全网中的各个 MSC Server分别分配一段 Call-ID的取值范围 对于网络中使用了共享池（MSC in Pool )方式的配置的情况下， 即 BSC 连接了多个 MSC Server, 不同的 MSC Server 不能保证分配不同数值的 Call-ID, 这时就可以釆用本实施例的为全网中的各个 MSC Server分别分配 一段 Call-ID的取值范围的方法。可以根据网络中网元个数，例如 MSC Server 的个数， 将 Call-ID的 32比特长度的取值范围分段， 每个 MSC Server使用 一段 Call-ID; 也可以每个 Pool中的 MSC Server共享一段 Call-ID的取值 范围。 例如 MSC Serverl、 MSC Server2和 MSC Server 3组成一个共享 Pool , 当 MSC Server2为一个呼叫分配了数值为 3的 Call-ID, 则 MSC Server 2通 知 MSC Serverl和 MSC Server3, MSC Serverl和 MSC Server3就不再分配数 值为 3的 Call- ID; 同样地当 MSC Server2释放了 Call- ID=3的呼叫， 也通 知 MSC Serverl和 MSC Server3, 则 MSC Serverl和 MSC Server3可以分配 数值为 3的 Call_ID。
(2)用 "网元标识" 和 "网元呼叫标识" 的组合来表示 Call-ID
"网元标识" 可以釆用信令点编码、 唯一标识网元的 IP地址、 全网内部 分配的网元编号等方式， "网元标识" 为能在全网范围内唯一标识该网元， 即 MSC Server的标识。
"网元呼叫标识" 表示该网元能够为呼叫分配的编号， 可以用一定范围 的数值来表示具体的呼叫标识值， 编号的具体分配可以由该网元来控制， 例如 "网元标识" 釆用信令点编码， 则 Call-ID的表达方式如表 3所示： 表 3
Figure imgf000022_0001
"网元呼叫标识" 为所述网元内部统一分配的呼叫标识值， 如表 2所示 使用 4个字节长度， 就足够单个网元用来分配呼叫， "网元呼叫标识"部分的 表达方式如表 4所示：
表 4
Figure imgf000022_0002
其中， n为表 4中 "信令点编码地址信息" 部分的字节长度；
0/E为奇 /偶标志： 八位位组 3的比特 8 , 表示地址信息中所含地址信号 数目的奇 /偶， 具体为：
0： 偶数个地址信号
1 : 奇数个地址信号
地址性质表示语： 八位位组 3 的比特 1-7 , 表示地址信息的属性， 具体 为：
比特 7654321
0000000 ( 0 ) 空闲 0000001 ( 1 ) 用户号码
0000010 ( 2 ) 国内备用
0000011 ( 3 ) 国内有效号码
0000100 ( 4 ) 国际号码
0000101 ( 5 )至 1111111 ( 127 ) 空闲
地址信息： 八位位组 4及其以后的信息都是地址信号， 其格式为： 0/Ε=1, 即 K为奇数且 K= n/2-l; 每个地址信号占 4个比特， 其表达方式如 表 5所示：
表 5
Figure imgf000023_0001
若 0/Ε=0, 1即 Κ为偶数且 Κ=η/2; 每个地址信号占 4个比特， 其表达方式如 表 6所示：
表 6
Figure imgf000023_0002
本发明实施例的呼叫建立方法， 通过用网元标识和网元呼叫标识的组合 来表示 Call-ID, 或事先为网元分配不同的 Call-ID取值范围， 从各自的 Call_ID取值范围中选取 Call_ID数值分配给呼叫，使得 Cal 1-ID的唯一性得到 保证， 从而保证 BSC不会收到数值相同的 Call-ID; 提高了呼叫建立的成功率。
如图 11所示， 为本发明实施例提供的呼叫建立装置结构示意图； 本实施 例包括： 分配请求模块 10, 用于接收到媒体网关发送的完成建立 IP端点的 增加端点响应消息之后，将网元标识和网元呼叫标识组成的呼叫标识 Ca 11 - 1 D 携带在分配请求消息中发送给基站控制器； 或从为移动交换中心分配的 Call-ID取值区间中选择一个没有被占用的 Call-ID值， 发送携带有选择的 Call-ID值的分配请求消息至基站控制器。 本实施例还可以包括完成消息接 收模块 11, 用于接收基站控制器建立以 CaU-ID值标识的呼叫之后返回的携 带有该 Call-ID值的分配完成消息。
如图 12所示， 为本发明实施例提供的呼叫处理方法实施例一流程图， 本 实施例的步骤 811-819与图 8所示实施例的步骤 611-619相同， 区别在于以 下步骤：
步骤 821、 BSC1接收到 MSCServer发送的分配请求消息， 获得该消息里 携带的 Call-ID的值， BSC1判断该 Call-ID的值是否已经存在于 BSC1 中并 判断该 Call-ID的标识方式是否有效， 若已存在和 /或标识方式无效， 则发送 携带有该 Call-ID和 /或相应失败原因指示值的分配失败消息给 MSC Server; 本实施例呼叫建立失败的原因包括 BSC收到重复数值的 Call-ID值， 语 音编码类型不支持、 资源不可用、 Call-ID 标识方式无效等， 这些原因也会 导致呼叫失败。 Call-ID标识方式无效比如 Call-ID少了一个字节， 则失败 原因指示值中包含" Call-ID格式错误"，以指示该 Call-ID的标识方式无效。 BSC收到重复数值的 Call-ID值，则失败原因指示值中包含" Call-ID已存在"。
步骤 823、 MSC Server终止与该 Call-ID的值对应的呼叫进程。
如图 13所示， 为本发明实施例提供的呼叫处理方法实施例二流程图， 本 实施例的步骤 911-917与图 9所示实施例的步骤 711-717相同， 区别在于以 下步骤： 步骤 919、 BSC2接收到切换请求消息，获得该切换请求消息中的 Call-ID 的值， BSC2判断该 Call-ID的值是否已经存在于 BSC2中， 并判断该 Call-ID 的标识方式是否有效，若已存在和 /或标识方式无效，则发送携带有该 Cal 1-ID 和 /或相应失败原因指示值的切换失败消息给 MSC Server;
本实施例呼叫切换失败的原因包括 BSC收到重复数值的 Call-ID值， 语 音编码类型不支持、 资源不可用、 CaU-ID 标识方式无效等， 这些原因均会 导致呼叫失败。 Call-ID标识方式无效比如 Call-ID少了一个比特位，则 BSC2 可以判断出该 Call-ID的格式出错， 进而将包含 "Call-ID格式错误" 的失 败原因指示值通知给 MSC Server。 若 BSC收到重复数值的 Cal 1-ID值， 则将 包含 "Call_ID已存在" 的失败原因指示值通知给 MSC Server。
步骤 921、 MSC Server终止与该 Call-ID的值对应的切换流程。
本发明实施例呼叫处理方法能够有效处理 BSC 接收到重复数值的 Call-ID的呼叫。 具体地通过将已存在同样数值的 Call-ID携带在分配失败 消息或切换失败消息中告知 MSC Server,使得 MSC Server可以根据该 Call-ID 的值终止重复 Ca 11 - 1 D导致的异常呼叫流程。
如图 14所示， 为本发明实施例提供的呼叫处理装置实施例结构示意图， 本实施例包括消息接收模块 12, 用于接收携带呼叫标识 Call-ID的分配请求 消息， 或者接收携带呼叫标识 CaU-ID的切换请求消息； 失败消息发送模块 13, 用于接收携带呼叫标识 CaU-ID的分配请求消息， 当根据接收到的携带 呼叫标识 Call-ID的分配请求消息分配呼叫失败时， 返回携带有该 Call-ID 的值和 /或相应失败原因指示值的分配失败消息给移动交换中心，该失败原因 指示值包括 Call-ID已存在或 Call-ID格式错误； 或， 用于接收携带呼叫标 识 Call-ID的切换请求消息， 当根据接收到的携带呼叫标识 Call-ID的切换 请求消息分配呼叫失败时，返回携带有该 Call-ID的值和 /或相应失败原因指 示值的切换失败消息给所述移动交换中心， 还可以发送携带包含 "Call-ID 格式错误" 或 "Call-ID 已存在" 的失败原因指示值的分配失败消息或切换 失败消息给移动交换中心。 还可以包括： 切换响应模块 14 , 用于当 Ca l l-ID 的值不存在于目标基站控制器中且标识方式有效时， 在呼叫分配完成后返回 切换请求确认消息； 和 /或分配响应模块 15 , 用于当 Ca l l-ID的值不存在于 目标基站控制器中且标识方式有效时，在呼叫分配完成后返回分配完成消息。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤 是可以通过程序来指令相关的硬件完成， 所述的程序可以存储于计算机可读 存储介质中， 该程序在执行时包括上述实施例中的步骤。 相应的存储介质可 以是只读存储器， 磁盘或光盘等。
最后应说明的是： 以上实施例仅用以说明本发明的技术方案而非对其进 行限制， 尽管参照较佳实施例对本发明进行了详细的说明， 本领域的普通技 术人员应当理解： 其依然可以对本发明的技术方案进行修改或者等同替换， 而这些修改或者等同替换亦不能使修改后的技术方案脱离本发明技术方案的 ^"神和范围。

Claims

权 利 要 求
1、 一种呼叫切换方法， 其特征在于， 包括：
接收媒体网关发送的增加端点响应消息；
当所述增加端点响应消息指示所述媒体网关成功建立时分复用 TDM端点 和因特网协议 IP端点时， 发送携带有电路识别码和 IP类型端点信息的切换 请求消息至目标基站控制器；
接收所述目标基站控制器返回的切换请求确认消息， 当所述切换请求确 认消息中携带 IP类型端点信息时， 表明所述目标基站控制器选择的是 IP端 口方式。
2、 根据权利要求 1所述的方法， 其特征在于， 还包括：
当所述增加端点响应消息指示所述媒体网关成功建立 IP端点时，发送携 带有 IP类型端点信息的切换请求消息至目标基站控制器；
接收所述目标基站控制器返回的切换请求确认消息， 当所述切换请求确 认消息中携带电路识别码 CIC时， 表明所述目标基站控制器选择的是 TDM端 口方式， 通知所述媒体网关新建对应所述 CIC的 TMD端点； 当所述切换请求 确认消息中携带 IP类型端点信息时， 表明所述目标基站控制器选择的是 IP 端口方式。
3、 根据权利要求 1所述的方法， 其特征在于， 还包括：
发送携带有 TDM类型端点信息及所述 TOM类型对应的编码信息， 和互联 网协议 IP类型端点信息及所述 IP类型对应的编码信息的增加端点请求消息 给所述媒体网关。
4、 根据权利要求 1-3任一所述的呼叫切换方法， 其特征在于， 还包括： 根据所述目标基站控制器返回的切换请求确认消息， 通知所述媒体网关 删除与所述目标基站控制器选择的端点类型不同的已成功建立的端点。
5、 一种呼叫切换系统， 其特征在于包括：
增加端点响应接收模块， 用于接收媒体网关发送的增加端点响应消息； 切换请求消息模块， 用于当所述增加端点响应消息指示所述媒体网关成 功建立 TDM端点和 IP端点时， 发送携带有电路识别码和 IP类型端点信息的 切换请求消息至目标基站控制器；
切换确认消息模块， 用于接收所述目标基站控制器返回的切换请求确认 消息， 当所述切换请求确认消息中携带 IP类型端点信息时， 表明所述目标基 站控制器选择的是 IP端口方式。
6、根据权利要求 5所述的呼叫切换系统，其特征在于还包括：删除模块， 用于根据所述目标基站控制器返回的切换请求确认消息， 通知所述媒体网关 删除与所述目标基站控制器选择的端点类型不同的已成功建立的端点。
7、 根据权利要求 5所述的呼叫切换系统， 其特征在于还包括： 建立端点 模块， 用于根据接收到的增加端点请求消息建立 TDM端点和 IP端点， 并返回 指示成功建立所述 TDM端点和 I P端点的增加端点响应消息。
8、 根据权利要求 5所述的呼叫切换系统， 其特征在于还包括： 端点类型 选择模块， 用于接收所述切换请求消息， 发送携带有选择的端点信息的切换 请求确认消息。
9、 一种呼叫切换方法， 其特征在于包括：
接收到媒体网关发送的指示完成建立 IP端点的增加端点响应消息； 发送携带有网元标识和网元呼叫标识组成的呼叫标识 Ca l l-ID的切换请 求消息至目标基站控制器； 或者， 从为移动交换中心分配的 Ca U-ID取值区 间中选择一个没有被占用的 Ca l l-ID值， 发送携带有所述选择的 Ca l l-ID值 的切换请求消息至目标基站控制器； 各移动交换中心分配到的 Ca U-ID取值 区间互不重叠；
接收所述目标基站控制器建立以所述 Ca l l-ID值标识的呼叫之后返回切 换请求确认消息。
10、 根据权利要求 9所述的呼叫切换方法， 其特征在于所述网元标识为 全网络中对所述网元的唯一标识， 所述网元标识包括： 信令点编码， 或网元 IP地址， 或全网内部统一分配的网元编号； 所述网元呼叫标识包括： 为所述 网元内部统一分配的呼叫标识值。
11、 根据权利要求 9所述的方法， 其特征在于， 所述 Call-ID值基站控 制器无权分配； 当某一移动交换中心分配了 Call-ID并建立了相应的呼叫， 只要该呼叫没有切换到其他的移动交换中心或者该呼叫没有被删除， 则该呼 叫的 Call-ID始终有效， 且数值不能被修改。
12、 一种呼叫处理方法， 其特征在于， 包括：
接收携带呼叫标识 CaU-ID的分配请求消息或切换请求消息， 当根据所 述携带呼叫标识 Call-ID的分配请求消息或切换请求消息分配呼叫失败时， 返回携带有所述失败原因指示值的分配失败消息或切换失败消息给移动交换 中心， 所述失败原因指示值包括 Call-ID已存在或 Call-ID格式错误。
13、 根据权利要求 12所述的呼叫处理方法， 其特征在于， 所述根据携带 呼叫标识 Call-ID的分配请求消息或切换请求消息分配呼叫失败具体包括： 当所述 Call-ID的值已存在于所述基站控制器中，和 /或所述 Call-ID的值无 效时， 则分配呼叫失败。
14、 根据权利要求 12所述的呼叫处理方法， 其特征在于， 所述发送携带 有所述失败原因指示值的分配失败消息给移动交换中心之后还包括：
所述移动交换中心根据所述失败原因指示值终止与该 Call-ID值对应的 呼叫。
15、 根据权利要求 12所述的呼叫处理方法， 其特征在于， 所述方法进一 步包括：
当所述 Call-ID的值不存在于基站控制器中， 且被基站控制器判断为有 效， 则在成功分配呼叫后返回分配完成消息或切换请求确认消息。
16、 一种呼叫切换装置， 其特征在于包括：
第二切换请求模块，用于接收到媒体网关发送的完成建立 IP端点的增加 端点响应消息；发送携带有网元标识和网元呼叫标识组成的呼叫标识 Call-ID 的切换请求消息至目标基站控制器；或者，从为移动交换中心分配的 CaU-ID 取值区间中选择一个没有被占用的 Call-ID 值， 发送携带有所述选择的 Call-ID值的切换请求消息至目标基站控制器； 各移动交换中心之间分配到 的 Call-ID取值区间互不重叠；
确认接收模块， 用于接收所述目标基站控制器建立以所述 Call-ID值标 识的呼叫之后返回的切换请求确认消息。
17、 一种呼叫处理装置， 其特征在于， 包括：
消息接收模块， 用于接收携带呼叫标识 CaU-ID的分配请求消息， 或者 接收携带呼叫标识 Call-ID的切换请求消息；
失败消息发送模块， 用于当根据所述消息接收模块接收的携带呼叫标识 Call-ID 的分配请求消息分配呼叫失败时， 返回携带有所述失败原因指示值 的分配失败消息给移动交换中心， 所述失败原因指示值包括 Call-ID 已存在 或 Call-ID格式错误；
或， 用于当根据所述消息接收模块接收的携带 CaU-ID的切换请求消息 分配呼叫失败时， 返回携带有所述失败原因指示值的切换失败消息给所述移 动交换中心，所述失败原因指示值包括 Call-ID已存在或 Call-ID格式错误。
18、 根据权利要求 17所述的呼叫处理装置， 其特征在于， 还包括： 切换响应模块， 用于当所述 Call-ID的值不存在于目标基站控制器中且 为有效时， 在完成呼叫分配后返回切换请求确认消息；
和 /或分配响应模块，用于当所述 Call-ID的值不存在于基站控制器中且 为有效时， 在完成呼叫分配后返回分配完成消息。
PCT/CN2009/072172 2008-06-07 2009-06-08 呼叫切换、处理方法及装置与系统 WO2009146664A1 (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
BRPI0914796A BRPI0914796A2 (pt) 2008-06-07 2009-06-08 método, dispositivo e sistema para transferência intercelular de chamada e processamento
RU2011127660/07A RU2520573C9 (ru) 2008-06-07 2009-06-08 Способ, устройство и система хэндовера и обработки вызовов
CN2009801217304A CN102282888B (zh) 2008-06-07 2009-06-08 呼叫切换、处理方法及装置与系统
EP09757098A EP2291025A4 (en) 2008-06-07 2009-06-08 METHOD, APPARATUS AND SYSTEM FOR CALL TRANSFER AND PROCESSING

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN2008101093879A CN101600179B (zh) 2008-06-07 2008-06-07 呼叫切换、建立、处理方法及装置与系统
CN200810109387.9 2008-06-07

Publications (1)

Publication Number Publication Date
WO2009146664A1 true WO2009146664A1 (zh) 2009-12-10

Family

ID=41397744

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/072172 WO2009146664A1 (zh) 2008-06-07 2009-06-08 呼叫切换、处理方法及装置与系统

Country Status (5)

Country Link
EP (1) EP2291025A4 (zh)
CN (2) CN101600179B (zh)
BR (1) BRPI0914796A2 (zh)
RU (1) RU2520573C9 (zh)
WO (1) WO2009146664A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102572980B (zh) * 2011-12-22 2014-12-03 华为技术有限公司 移动台切换方法、设备和系统
CN110647683B (zh) * 2019-09-17 2022-04-19 北京邮电大学 一种信息推荐方法、装置
CN116746210A (zh) * 2021-01-05 2023-09-12 联想(北京)有限公司 用于报告切换相关信息的方法及设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1901742A (zh) * 2006-07-21 2007-01-24 华为技术有限公司 一种信道切换方法
CN101115029A (zh) * 2007-03-05 2008-01-30 中兴通讯股份有限公司 一种基站与核心网的混合连接方法
CN101170807A (zh) * 2006-10-23 2008-04-30 华为技术有限公司 一种切换过程中的承载更新方法、系统及装置

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100520141B1 (ko) * 2000-10-26 2005-10-10 삼성전자주식회사 이동통신 시스템에서 고정 주소를 가지는 이동단말의 핸드오버 방법
KR100689508B1 (ko) * 2003-09-04 2007-03-02 삼성전자주식회사 통신 시스템에서 핸드오버 수행 방법
FI20040280A0 (fi) * 2004-02-23 2004-02-23 Nokia Corp Menetelmä pakettikytkentäisen kanavanvaihdon suorittamiseksi matkaviestinjärjestelmässä
CN101018198A (zh) * 2007-01-12 2007-08-15 华为技术有限公司 一种ip地址信息传递方法及移动交换中心
RU2421940C2 (ru) * 2007-01-30 2011-06-20 ЗетТиИ Корпорейшн Способ установления ip-канала в системе мобильной связи
CN101127740B (zh) * 2007-09-11 2011-07-13 中兴通讯股份有限公司 一种支持局间混合连接的方法
CN101141423B (zh) * 2007-10-12 2012-05-23 中兴通讯股份有限公司 支持局间ip和tdm混合组网的服务质量控制方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1901742A (zh) * 2006-07-21 2007-01-24 华为技术有限公司 一种信道切换方法
CN101170807A (zh) * 2006-10-23 2008-04-30 华为技术有限公司 一种切换过程中的承载更新方法、系统及装置
CN101115029A (zh) * 2007-03-05 2008-01-30 中兴通讯股份有限公司 一种基站与核心网的混合连接方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group GSM/EDGE Radio Access Network; Mobile Switching Centre - Base Station System (MSC-BSS) interface; Layer 3 specification (Release 8). TS 48.008 v8.2.0.", 3GPP, 31 March 2008 (2008-03-31), XP050379538 *
See also references of EP2291025A4 *

Also Published As

Publication number Publication date
BRPI0914796A2 (pt) 2015-10-27
EP2291025A4 (en) 2011-08-10
EP2291025A1 (en) 2011-03-02
RU2520573C9 (ru) 2014-09-10
CN102282888B (zh) 2013-08-28
CN102282888A (zh) 2011-12-14
CN101600179A (zh) 2009-12-09
RU2011127660A (ru) 2013-01-20
RU2520573C2 (ru) 2014-06-27
CN101600179B (zh) 2011-10-26

Similar Documents

Publication Publication Date Title
EP3413622B1 (en) Handover apparatus and method in a heterogeneous wireless communication system
JP5356517B2 (ja) マルチコンポーネント通信セッションでのセッション連続性情報の伝達
JP4612107B2 (ja) 呼制御とベアラ制御とが分離された通信ネットワークの柔軟性を増加させる方法
WO2009012685A1 (fr) Contrôleur, serveur et procédé de commutation de domaine
JP2000324174A (ja) パケット交換型セルラー無線ネットワークでマルチメディア関連情報の送信準備を行なうための方法および構成
WO2007118380A1 (fr) Procédé, système et dispositif de négociation du codage/décodage vocal dans un système de communication
KR20080086781A (ko) 이종의 무선 통신 네트워크에서 핸드오버 장치 및 방법
EP1525765A1 (en) Routing method and network element
JP5027297B2 (ja) 移動通信ネットワークにおける呼のハンドリング
RU2473188C1 (ru) Способ разъединения вызова и устройство для его осуществления
WO2009146664A1 (zh) 呼叫切换、处理方法及装置与系统
WO2010054586A1 (zh) 一种bbs本地交换的实现方法、装置和系统
CN102497396B (zh) 通信方法、基站、基站控制器和移动交换中心
WO2010121521A1 (zh) 实现业务连续性的方法、系统、msc服务器及会话终端
WO2010078678A1 (zh) 跨Iur口传递小区能力的方法、系统及DRNC
CN101453752B (zh) 通信网中实现业务优先级的方法、系统及设备
WO2011069375A1 (zh) 控制本地交换的方法、装置和系统
WO2010102585A1 (zh) 一种在呼叫建立过程中对本地通话建立本地交换的方法、设备及系统
RU2496260C2 (ru) Способ, контроллер базовой станции и подсистема базовой станции для контроля качества обслуживания
WO2008037208A1 (fr) Procédé et système pour gestion d'un circuit d'interface a et passerelle media
KR20060116268A (ko) 더블유씨디엠에이 시스템에서 에스알엔스 재배치/핸드오버방법
CN102395124B (zh) 呼叫切换、建立方法及装置
WO2013091579A1 (zh) 移动台切换方法、设备和系统
KR100463522B1 (ko) 차세대 통신망에서의 핸드오프 방법
WO2011137858A1 (zh) 在基站之间建立接口、实现小区切换的方法和相关装置

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200980121730.4

Country of ref document: CN

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

Ref document number: 09757098

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2009757098

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2011127660

Country of ref document: RU

ENP Entry into the national phase

Ref document number: PI0914796

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20101207