WO2010017781A1 - Procédé et dispositif de libération d'appels - Google Patents

Procédé et dispositif de libération d'appels Download PDF

Info

Publication number
WO2010017781A1
WO2010017781A1 PCT/CN2009/073277 CN2009073277W WO2010017781A1 WO 2010017781 A1 WO2010017781 A1 WO 2010017781A1 CN 2009073277 W CN2009073277 W CN 2009073277W WO 2010017781 A1 WO2010017781 A1 WO 2010017781A1
Authority
WO
WIPO (PCT)
Prior art keywords
call
message
network element
idle
occupied
Prior art date
Application number
PCT/CN2009/073277
Other languages
English (en)
Chinese (zh)
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 RU2011131539/08A priority Critical patent/RU2473188C1/ru
Publication of WO2010017781A1 publication Critical patent/WO2010017781A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/30—Connection release

Definitions

  • the present invention relates to the field of mobile communications, and in particular, to a call release method and apparatus. Background technique
  • GSM Global System for Mobile communication
  • IP Internet Protocol
  • CN Core Network
  • A-interface signaling plane IP A-interface signaling plane IP between the CN and the access network.
  • Figure 1-3 shows the architecture of the GSM system.
  • the dotted line indicates the signaling plane (Signaling) and the solid line indicates the user.
  • User plane In this architecture, only the A-interface user plane still uses the TDM method, which becomes the last obstacle for the entire network IP.
  • 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.
  • AoIP IP-based A-interface transport bearer
  • 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.
  • the user plane transmission of a call must occupy the solid A time slot resource is determined, so the original protocol uses a Call Identifier Code or Circuit Identifier 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 is shown in 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-ID) is introduced to identify the call.
  • Call-ID Call Identifier
  • MSC Mobile Switching Center
  • SCCP Signaling Connection Control Part
  • the Call-ID can be used to request the other party to simultaneously release the relevant call resources. .
  • the network is configured as MSC pool A-flex (MSC in Pool)
  • some call errors occur due to abnormal address, so the call-ID list is particularly efficient when you need to release the call in batches.
  • the existing Call-ID is a 32-bit value independent of the bearer, and its expression is as shown in Table 2: Table 2
  • the Call-ID value uniquely identifies a call on the MSC and BSC.
  • the MSC supports and uses the IPized A interface
  • the MSC allocates a specific Call-ID value to the call during the call distribution process and the handover process, and passes the Assignment Request message and the Handover Request message. Carrying the Call-ID value in the Call Identifier cell to notify the relevant BSC, and After this, both the MSC and the BSC identify the call with the Call-ID value before the call is released.
  • the other party detecting the interrupt sends a Reset Resource message, and the message carries the Call-ID value indicating the specific call, and notifies the other party of the translation. Resource and reference, etc.; return the Reset Resource Acknowledge message after the operation succeeds, and carry the Call-ID list of the call that the resource has been successfully translated.
  • the Call-ID can only be allocated by the MSC Server, and is notified to the BSC by being carried in the allocation request message and the handover request message.
  • the MSC Server cyclically allocates the Call-ID in the order of the value of the Call-ID from small to large.
  • the MSC Server and the BSC do not timely release the corresponding Call-ID value, and the call corresponds to the call.
  • the Call (ID) is assigned the first (i 232) call, the Call-ID value must be applied again.
  • the status of the Call-ID value is "Occupied"
  • the call assignment fails. In this way, the Call-ID values on both sides of the BSC and the MSC Server cannot be synchronized, which not only causes waste of Call-ID resources, but also reduces the success rate and efficiency of call distribution and call handover. Summary of the invention
  • An embodiment of the present invention provides a call release method, which effectively solves the defects of the prior art call distribution, low call handover success rate, and the like.
  • Another aspect of the present invention provides a call release device, which effectively solves the defects of prior art call distribution, low call handover success rate and the like.
  • a call release method includes: When the network element detects that the call identifier of the identified call is abnormal and/or the call is abnormal and/or receives an operation and maintenance request, the resource related to the call is released, and the status of the call identifier is changed from "occupied" to ""Idle", send signaling connection control part SCCP connectionless type request message to the peer network element;
  • An aspect of the present invention further provides a call release method, including: sending an allocation request message carrying an allocated call identifier to a base station controller, and when the base station controller fails to perform an allocation process, receiving the base station An allocation failure message sent by the controller, where the allocation failure message carries a failure cause value;
  • An aspect of the present invention further provides a call release method, including: a handover failure message carrying a failure cause value sent after receiving a target cell controller call handover failure, and releasing the terminal as a target base station controller
  • the resource allocated by the call in the call changes the status of the call identifier corresponding to the call from "occupied" to "idle".
  • An aspect of the present invention further provides a call identification method, including:
  • the time-division multiplexing TDM mode or the Internet Protocol IP mode is used regardless of the current A-interface user plane link of the call.
  • the call is identified using only the call identification value.
  • a call decoding device includes: a reset message sending module, configured to: when the network element detects that the call identifier of the identified call is abnormal and/or the call is abnormal and/or received
  • the operation and maintenance request is: releasing the resource related to the call, modifying the status of the call identifier from "occupied” to "idle”, sending a reset resource message to the peer network element, and receiving a response module, configured to receive the pair The reset resource response message returned by the end network element, where the peer network element is used for releasing the resource related to the call of the opposite network element side, and modifying the status of the call identity of the identified call from "occupied" to "Idle".
  • a call release device including:
  • the SCCP message sending module is configured to: when it is detected that the call identifier of the identified call is abnormal, and/or the call is abnormal on the local network side or on the opposite network element side, and/or when the operation and maintenance request is required to clear all the calls Translating all the call-related resources, modifying the status of the call identifier corresponding to all the calls from "occupied" to "idle", and sending an SCCP connectionless type request message to the peer network element;
  • the acknowledgment message receiving module is configured to receive the SCCP connectionless type confirmation message returned by the peer network element, where the peer network element is used for releasing all the call related resources on the network element side.
  • a call release device including: a resource release module, configured to release a call related resource;
  • a state modification module configured to change the state of the call identifier corresponding to the call from "occupied” to "idle";
  • a first receiving module configured to receive, in a call distribution process, an allocation failure message sent by the base station controller; or, in a call handover process, a handover failure message that carries a failure cause value sent after the target base station controller fails to perform call handover Or, in the call switching process, receiving the source base The handover failure message carrying the failure cause value sent after the station controller fails to switch the call; or, in the call handover procedure, receiving the clear request message sent by the source base station controller.
  • An aspect of the present invention further provides a call release method, including: receiving an SCCP connectionless type request message, where the SCCP connectionless type request message is a reset message of a call type cell;
  • the resources of all calls corresponding to the call type cell are released.
  • the call release method and apparatus modify the state of the call identifier corresponding to the call from "occupied" to "idle” by releasing the call related resources, so that the mobile switching center and the base station controller The status of the call identity remains the same.
  • the call identifier of the deciphered call can be vacated in time to identify other calls. Therefore, the problem of wasted call identity is solved, and the success rate of call setup and call handover is improved.
  • FIG. 1 is a structural diagram of a prior art GSM system
  • FIG. 2 is a structural diagram of a GSM system according to the present invention.
  • FIG. 3 is a flowchart of Embodiment 1 of a call release method according to an embodiment of the present invention
  • Embodiment 4 is a flowchart of Embodiment 2 of a call release method according to an embodiment of the present invention.
  • FIG. 5 is a flowchart of Embodiment 3 of a call release method according to an embodiment of the present invention.
  • FIG. 6 is a flowchart of Embodiment 4 of a call release method according to an embodiment of the present invention.
  • FIG. 7 is a flowchart of Embodiment 5 of a call release method according to an embodiment of the present invention.
  • FIG. 8 is a flowchart of Embodiment 6 of a call release method according to an embodiment of the present invention
  • FIG. 9 is a flowchart of Embodiment 7 of a call release method according to an embodiment of the present invention
  • FIG. 10 is a flowchart of Embodiment 8 of a call release method according to an embodiment of the present invention
  • FIG. 11 is a flowchart of Embodiment 9 of a call release method according to an embodiment of the present invention.
  • FIG. 12 is a flowchart of Embodiment 10 of a call release method according to an embodiment of the present invention.
  • FIG. 13 is a flowchart of Embodiment 11 of a call release method according to an embodiment of the present invention.
  • FIG. 14 is a schematic structural diagram of Embodiment 1 of a call release device according to an embodiment of the present invention
  • FIG. 15 is a schematic structural diagram of Embodiment 2 of a call release device according to an embodiment of the present invention
  • FIG. 16 is a schematic diagram of a call release provided by an embodiment of the present invention
  • the Call-ID of the embodiment of the present invention refers to a unique identifier of a specific call on the A-interface connection between the MSC and the corresponding BSC, and the Call-ID is uniformly managed and allocated by the MSC.
  • FIG. 2 is a structural diagram of a GSM system according to the present invention. The following embodiments are all based on the GSM system after the full introduction of IP transmission.
  • FIG. 3 is a flowchart of Embodiment 1 of a call release method according to an embodiment of the present invention; this embodiment includes the following steps:
  • Step 101 When the network element detects that the call identifier of the identified call is abnormal and/or the call is abnormal and/or receives an operation and maintenance request, the resource related to the call is released, and the status of the call identifier is changed from “occupied” to “idle”. Sending an SCCP connectionless type request message to the peer network element;
  • Step 102 Receive an SCCP connectionless type confirmation message returned by the peer network element, where the peer network element is used to release the resource related to the call of the local network side, and modify the state of the call related call identifier by using “occupied” It is "idle".
  • the call release method provided by the embodiment of the present invention changes the state of the call identifier corresponding to the call from "occupied” to "idle” by releasing the call related resources, so that the call of the mobile switching center and the base station controller The status of the identifier is consistent.
  • the call identifier corresponding to the translated call can be vacated in time to identify subsequent calls. Therefore, the problem of resource waste is solved, and the success rate of call setup and call handover is improved.
  • FIG. 4 is a flowchart of Embodiment 2 of a call release method according to an embodiment of the present invention; in this embodiment, an example in which a target BSC detects a Call-ID abnormality and translates a call corresponding to the Call-ID is taken as an example. Specifically, the following steps are included:
  • Step 201 The MSC Server sends a Handover Request message to the BSC, where the message carries the Call-ID 1 value assigned to the call under the B SC;
  • Step 202 The BSC receives the handover request message, and obtains a Call-ID1 value.
  • the BSC determines whether the Call-ID1 value has been allocated to other calls, that is, determines whether the state of the Call-ID1 value is "occupied", and determines the Call- Whether the ID1 identification mode is valid; if the BSC has already assigned the Call-ID1 value to other calls before receiving the handover request message, that is, the state of the Call-ID1 value is already "occupied” before the BSC receives the handover request message, and If the call mode of the Call-ID1 is invalid, the BSC keeps the call and related resources that are originally identified by the Call-ID1 value, and sends a handover failure with the corresponding failure cause indication value and/or the Call-ID1 value. Handover Failure) message to the MSC Server;
  • Step 203 The MSC Server learns that the handover fails and the value of the Call-ID1 value is abnormal according to the cause value in the received Handover Failure message, and the state of the Call-ID1 value is changed to "idle". And releasing the call-related resource, and sending a Reset Resource message to the BSC, where the message carries the Call-ID 1 value;
  • Step 204 After receiving the indication message, the BSC modifies the value of the Call-ID1 value to "Idle", and translates the related resource corresponding to the call identified by the Call-ID 1 value, and returns a Reset Resource Acknowledge message carrying the Call-ID 1 value. MSC Server.
  • the Reset Resource message in this embodiment is a SCCP connectionless type request message, and the Reset Resource Acknowledge message is an SCCP connectionless type confirmation message;
  • the MSC Server modifies the state of the Call-ID1 value, and has no timing relationship restriction on the resource related to the call of the Call-ID 1 value marked on the local network element and the Reset Resource message.
  • FIG. 5 is a flowchart of a third embodiment of a call release method according to an embodiment of the present invention.
  • an allocation failure caused by an assigned Call-ID value has been assigned.
  • the specific steps include:
  • Step 301 The MSC Server sends an Assignment Request message to the BSC, where the message carries the information such as the Call-ID1 assigned by the MSC Server to the BSC and the established IP endpoint and/or TDM endpoint on the MGW.
  • Step 302 The BSC receives the allocation request message to obtain Call-ID1, and the BSC determines whether the Call-ID1 value has been allocated to other calls, that is, determines whether the state of the Call-ID1 value is "occupied", and determines the Call-ID1. Whether the identification mode is valid. If the BSC has assigned the Call-ID1 to other calls, that is, the state of the Call-ID1 value is already "occupied" before the BSC receives the allocation request message, and/or the identification mode is invalid, then the bearer is sent.
  • Step 303 The MSC Server learns that the call setup fails and the Call-ID1 value assignment is abnormal according to the cause value in the received Assignment Failure message, and the MSC Server changes the Call-ID1 value status to "Idle", and translates and calls. Related resources, sending a Reset Resource message to the BSC, where the message carries the Call-ID 1 value;
  • Step 304 After receiving the Reset Resource message, the BSC modifies the status of the indicated Call-ID1 value to "Idle", and translates the related resource corresponding to the call identified by the Call-ID1 value, and returns a Reset Resource Acknowledge carrying the Call-ID1 value.
  • the MSC Server modifies the state of the Call-ID 1 value and the resources of the release itself and the Reset Resource message have no timing restrictions.
  • FIG. 6 is a flowchart of Embodiment 4 of a call release method according to an embodiment of the present invention; in this embodiment, the MSC Server receives an operation and maintenance instruction or finds a major fault, and further needs to clear all calls under the network element or Take all the calls of the same type on the NE as an example.
  • the specific steps include:
  • Step 401 When the MSC Server receives the operation and maintenance instruction, or detects that a major fault occurs, and needs to clear all the calls under the local network element or all the calls of the same type under the local network element, send a signaling connection control part (Signing Connection and Control Part (SCCP for short) is a connectionless type of request message to each BSC under its jurisdiction; to indicate that the resources of all relevant calls in the BSC are translated and the state of the Call-ID value corresponding to these calls is modified to be "idle";
  • SCCP Signaling Connection and Control Part
  • Each BSC receives the request message of the SCCP connectionless type, successfully translates the related call related resources, and changes the state of the Call-ID value corresponding to the calls from "occupied" to "idle", and returns to the SCCP.
  • a connection-free acknowledgment message is sent to the MSC Server, indicating that all calls related to the MSC Server in the BSC or all call-related resources and Call-IDs of the same type in the local network element have been successfully
  • the SCC when the BSC receives the maintenance operation command or detects a major fault, and needs to clear all the calls under the local network element or all the calls of the same type under the local network element, the SCC also sends an SCCP to each associated MSC.
  • the connection message of the connectionless type is the same as steps 401 and 402 except that the execution entities MSC Server and BSC are replaced with each other.
  • the SCCP connectionless type request message that the MSC Server interacts with the BSC has the following three modes:
  • the mode A, SCCP connectionless type request message may be a Reset Resource message, and the acknowledged SCCP connectionless type acknowledgement message is a Reset Resource Acknowledge message; a call identifier list in the two messages (Call Identifier) List)
  • the cell needs to indicate the Call-ID(s) of all calls under the network element initiating the request, or all calls of the same type under the local network element, and it is not necessary to enumerate the Call-ID(s).
  • the call identifier length (Best MSB) and the call ID length (Length LSB) can be assigned to 0, and do not carry subsequent specific "Call Identifier” indicates that the Call Identifier List cell length is 3 Octet (bytes), or the other indicator unit indicates that the number of "Call Identifier” is 0, and does not carry the subsequent specific "Call Identifier” indication. That is, the Call Identifier List cell length is 2 Octet, which is expressed as all Call-ID(s) occupied by the call under the requesting network element.
  • this method is used to translate all the calls of the local network element, and the opposite network element is notified to release all the calls related to the local network element; and for the network element that does not support the AoIP function, Only the A interface of the AoTDM mode can still use the Reset message to request the peer network to translate all the calls related to the requesting network element (that is, only the AoTDM interface types only), because the Reset Resource and Reset Resource Acknowledge messages are not recognized. Call).
  • the method can be used to translate all calls in the AoIP interface mode on the BSC and the MSC, and the existing reset (Reset) and reset confirmation are used for the translation of all calls in the AoTDM interface mode. ( Reset Acknowledge ) message.
  • the SCCP connectionless type request message and the corresponding SCCP connectionless type confirmation message in the embodiment of the present invention may also be a newly created pair of SCCP connectionless type messages (ie, the existing Reset/Reset is not used).
  • Acknowledge message, Reset Resource/Reset Resource Acknowledge message used to indicate that the peer network element is reset, requesting to initiate all calls of the AoIP interface mode associated with the network element; and for the AoTDM interface mode, all calls are still used by the existing release.
  • Reset, Reset Acknowledge message used to indicate that the peer network element is reset, requesting to initiate all calls of the AoIP interface mode associated with the network element; and for the AoTDM interface mode, all calls are still used by the existing release.
  • the SCCP connectionless type request message and the corresponding SCCP connectionless type acknowledgment message in the embodiment of the present invention still use the existing Reset Resource message and the Reset Resource Acknowledge message, but add a new indication in the Reset Resource message.
  • the information unit is used to instruct the peer network element to reset all AoIP interface-related calls related to the requesting network element and all the calls related to the requesting network element in the AoTDM interface mode, and all the interface-initiating networks that do not distinguish the interface mode. Meta-related calls.
  • the newly added Call type cell is carried when the network element supports the AoIP interface function, and the peer network element also supports the AoIP function to recognize the Call type cell.
  • the cell definition can be as follows:
  • the Reset message carries a Call type cell, it indicates that the sender NE supports the AoIP interface function. Yes, otherwise, the sender network element does not carry the Call type cell in the Reset message, that is, the request sender sends a Reset message that does not carry the Call type cell. If the receiver does not support the Reset message carrying the Call type cell, the same The prior art receiver translates all calls related to the sender (in fact, the receiver also has only AoTDM mode calls), but if the receiver supports a Reset message carrying a Call type cell, it is determined that the sender only has AoTDM. In the case of a call, all calls related to the sender are translated (actually, the call related to the sender and the sender is in AoTDM mode).
  • the receiver network element If the Reset message carries the Call type cell, but the receiver network element cannot identify the Call type cell in the Reset message, it indicates that the receiver network element can only support the AoTDM interface mode, and therefore only translates its own sender-related information. All calls can be made; the call related to the sender and the receiver should also be AoTDM, so both ends can keep the call translation consistent. If the receiving network element can identify the Call type cell in the Reset message, the call is translated by type according to the indication of the Call type cell.
  • the Call type cell only uses the interface type of the A interface user plane to distinguish the call as an example.
  • the call type can be divided according to other standards.
  • the bit of the Call Type indication unit also needs to be increased. If the network element at both ends needs to understand the call type, it can be consistent.
  • FIG. 7 is a flowchart of Embodiment 5 of a call release method according to an embodiment of the present invention.
  • This embodiment takes the normal release call flow after the terminal MS has established a successful call as an example.
  • the specific steps are as follows:
  • Step 501 The MS sends a Disconnect message to the MSC Server through the BSC, requesting to remove the call link, and the BSC forwards the received Disconnect message to the MSC Server.
  • Step 502 After receiving the Disconnect message, the MSC Server sends a release request ( Release) The message is sent to the BSC, and the BSC forwards the Release message to the MS;
  • Step 503 After receiving the Release message, the MS stops all the call control timers, translates the Mobility Management (MM) link, and returns a Release Complete message to the MSC Server through the BSC.
  • MM Mobility Management
  • Step 504 After receiving the Release Complete message, the MSC Server also stops all call control timers, and releases the MM link; and releases the call related resources of the MS, such as clearing the TDM endpoint resources allocated for the call on the MGW or IP endpoint resource, and change the state of the Call-ID value corresponding to the call from "occupied" to "idle", and send the Base Station Subsystem Management Application Part (BSSMAP) clear command to the BSC. Command ) message
  • BSSMAP Base Station Subsystem Management Application Part
  • Step 505 After receiving the BSSMAP Clear Command message sent by the MSC Server, the BSC releases and connects all the connections of the MS and translates the air interface and the ground resource corresponding to the call, and modifies the state of the Call-ID value corresponding to the call from the “occupied” state. "Idle" and return a BSSMAP Clear Complete message to the MSC Server;
  • Step 506 The MSC Server sends a delete endpoint request message to the MGW.
  • Step 507 The MGW translates the resource allocated for the call, such as a TDM endpoint or an IP endpoint, and returns a delete endpoint response message to the MSC Server.
  • the MSC Server in step 504 of this embodiment sends a Clear Command message to the BSC, and the state of the Call-ID corresponding to the modified call in step 504 has no timing relationship limitation; and the resources related to the release call are deleted, for example, in steps 506 and 507. There are also no timing relationship restrictions for TDM endpoints and IP endpoints created for calls on the MGW.
  • the call release process of this embodiment may also be initiated by the MSC Server, and the specific steps include: Step 511: The MSC Server sends a Disconnect message to the MS through the BSC, requesting to remove the call link, and the BSC forwards the received Disconnect message to the MS.
  • Step 512 After receiving the Disconnect message, the MS sends a release request message to the BSC, and the BSC forwards the Release message to the MSC Server.
  • Step 513 After receiving the Release message, the MSC Server stops all the call control timers, translates the MM link, and returns a release completion message to the MS through the BSC;
  • Step 514 After receiving the Release Complete message, the MS stops all the call control timers and releases the MM link; then the MS releases the call related resources, such as releasing the TDM or IP endpoint resources allocated for the call on the MGW. And change the state of the call-occupied Call-ID value from "occupied" to "idle";
  • Step 515 The MSC Server sends a BSSMAP Clear Command message to the BSC, and the subsequent steps are the same as the foregoing steps 505-507.
  • FIG. 8 is a flowchart of Embodiment 6 of a call release method according to an embodiment of the present invention; in this embodiment, after a handover between BSCs belonging to the same MSC is completed, a normal BCC side translation call is taken as an example. For example, the terminal MS talks under the BSC1 and identifies the call with the Call-ID1 value, and the terminal MS successfully switches to the target BSC2.
  • the specific steps include:
  • Step 601 The BSC1 sends a Handover Required message to the MSC Server, requesting to switch the call of the MS to a more suitable cell.
  • the handover request message carries the voice coding RanCl (Ran Codec, access network voice coding) currently used by the user MS and BSC1;
  • Step 602 After receiving the handover request message, the MSC Server selects a cell under the BSC2 from the recommended cell as the target cell that the MS cuts in, and sends an add endpoint request message to the MGW. ( ADD.Req ), the message carries the recommended voice coding information (preferred RanC, pRanC for short), and carries the endpoint information paired with the BSC2.
  • the endpoint information may include the type of the endpoint that needs to be created by the MGW, that is, the TDM endpoint and/or Or IP endpoint;
  • the user MS performs normal voice service under BSC1, and both BSC1 and BSC2 belong to the same MSC.
  • the MSC Server does not know the current (dynamic) voice coding support capability and the related A interface type of the BSC2. Therefore, in order to ensure fast and successful handover, before cutting into the BSC2, at the MGW The IP endpoint and/or TDM endpoint paired with BSC2 needs to be created for BSC2 first.
  • Step 603 The MGW creates a TDM endpoint and/or an IP endpoint that is paired with the BSC2 according to the received addendum request message, and returns an addendend response message (ADD.Reply), where the message carries the created endpoint information.
  • ADD.Reply addendend response message
  • Step 604 the MSC Server receives the add endpoint response message, and sends a handover request message (Handover Request) to the BSC2;
  • the handover request message carries the Call-ID2 value assigned by the MSC to the call of the MS in the BSC2, and the MSC Server changes the state of the Call-ID2 value from "idle" to "occupied”; the message also carries the MSC-PCL (voice)
  • the coding is arranged in the recommended order, wherein the updated pRanC is the best recommended speech coding), the MGW side has allocated TDM endpoints and/or IP endpoints, and the like, wherein the TDM endpoint information may include CIC cells, the CIC cells
  • the value may be a CIC value corresponding to the TDM endpoint created by the MGW;
  • Step 605 After receiving the handover request message, the BSC2 can identify the Call-ID cell carried in the message, and identify the call that is cut in by using the Call-ID2 value carried in the message, and the status of the Call-ID2 value is "Idle" is modified to "occupied”; allocate call related resources, At the same time, a Handover Request Acknowledge message is returned; optionally, as long as the BSC2 can identify the Call-ID cell carried in the Handover Request message, and the call remains in the BSC2, regardless of the current A-interface user plane link, the TDM mode is used or In the IP mode, the call is identified by the value of the Call-ID2 carried in the message, and the CIC number or IP endpoint pair of the current A-interface user plane link only indicates the current physical link of the call;
  • Step 606 The MSC Server sends a Handover Command message to the BSC1, where the handover command message carries the coding type RanC2 selected by the BSC2.
  • Step 607 The BSC1 forwards the handover command message to the MS.
  • Step 608 The MS successfully switches to the designated cell in the target BSC2, and the BSC2 sends a Handover Complete message confirming the successful handover to the MSC Server.
  • Step 609 The MSC Server performs the resource allocation originally allocated for the MS under the BSC1, such as clearing the TDM endpoint or the IP endpoint allocated for the call under the BSC1 on the MGW, and the value of the Call-ID 1 corresponding to the call of the BSC1 is taken from the occupation. "The state is changed to the "idle” state, and a BSSMAP Clear Command message is sent to the BSC1;
  • Step 610 The BSC1 receives the BSSMAP Clear Command message, releases all connections of the MS and translates the relevant air interface and ground resources, and changes the state of the Call-ID1 value corresponding to the call from "occupied" to "idle” to the MSC.
  • the Server returns a BSSMAP Clear Complete message, indicating that the release is complete;
  • Step 611 The MSC Server confirms the type of the endpoint carried in the message according to the handover request returned by the BSC2 in step 605, and notifies the MGW to delete the created endpoint that is different from the type selected by the terminal MS in the BSC2.
  • the MSC Server sends a Clear Command message to the BSC1, and modifies the call.
  • the state of the corresponding Call-ID 1 has no limitation on the timing relationship; and the associated resources associated with the BSC1 are released, such as notifying the MGW to delete the TDM endpoints and/or IP endpoints created for the call, and there is no limitation on the timing relationship.
  • FIG. 9 is a flowchart of Embodiment 7 of a call release method according to an embodiment of the present invention. This embodiment is described by taking a call release when a call setup fails as an example. The specific steps include:
  • Step 701 The BSC sends a Layer 3 (Complete Layer 3) message to the MSC Server, where the message carries 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 user plane;
  • Layer 3 Complete Layer 3
  • Step 702 The MS sends a Direct Transfer Application Part (DTAP) Setu message to the MSC Server, where the message carries the MS-SCL, indicating the voice coding information supported by the MS.
  • DTAP Direct Transfer Application Part
  • Step 703 The MSC Server receives the layer 3 message sent by the BSC and the Setup message sent by the MS, and allocates resources for the call.
  • the TDM endpoint and/or the IP endpoint resource are allocated to the call on the MGW, and the state of the Call-ID value assigned to the call is changed from "idle" to "occupied", and an allocation request message (Assignment Request) is sent to the BSC.
  • Assignment Request a message carrying the Call-ID value assigned by the MSC Server for the call, a recommended code list, TDM endpoint information created by the MGW, and/or IP endpoint information;
  • Step 704 The BSC receives the allocation request message, optionally, as long as the BSC can identify the Call-ID cell carried in the allocation request message, and the call remains in the BSC, regardless of whether the current A-interface user plane link uses the TDM mode or the IP mode.
  • the call is identified by only the Call-ID value carried in the message, and the CIC number or IP endpoint pair of the current A interface user plane link only represents The current physical link of the call; however, if the BSC performs the allocation process fails, the BSC keeps the assigned Call-ID value as "idle" and returns an Assignment Failure message to the MSC Server;
  • Step 705 The MSC Server receives the allocation failure message, and decrypts the resource originally allocated for the call of the MS in the BSC, such as releasing the TDM endpoint resource and/or the IP endpoint resource allocated for the call on the MGW, and the Call-ID to be allocated for the call. The status of the value is changed from "occupied" to "idle".
  • the MSC Server sends a Clear Command message to the BSC, and the state of the Call-ID corresponding to the modified call has no timing relationship restriction; and the resources related to the release call, such as informing the MGW to delete the TDM endpoint and the IP endpoint created for the call. There is also no limitation on the timing relationship.
  • FIG. 10 is a flowchart of Embodiment 8 of a call release method according to an embodiment of the present invention; in this embodiment, a handover between BSCs belonging to the same MSC fails because the target BSC does not accept call hand-in, as an example.
  • the source BSC is recorded as BSC1
  • the target BSC is recorded as BSC2
  • the terminal MS is in normal call under BSC1
  • the call of the BSC1 is identified by the Call-ID1 value.
  • the specific steps include:
  • Step 801 The BSC1 sends a Handover Required message to the MSC Server, where the handover request message carries the voice coding RanCl (Ran Codec) of the current use of the MS and the BSC1; requesting to switch the call of the MS to more
  • the MSC Server selects a cell under the BSC2 as the target cell to be cut by the MS from the recommended cell according to the information reported by the BSC1, and after the relevant resource is successfully allocated to the BSC2, for example, creating a pairing for the BSC2 on the MGW.
  • RanCl Random Codec
  • the TDM endpoint and the IP endpoint send a Handover Request message to the BSC2, which carries the Call-ID2 value assigned to the call under the BSC2, that is, the state of the Call-ID2 value is changed from "idle" to "occupied”” ,
  • the message also carries the recommended code list, the created TDM endpoint information, and the IP endpoint information.
  • Step 804 The MSC Server receives the handover failure message, releases the resources such as the endpoint allocated to the BSC2, and changes the state of the Call-ID2 value allocated for the BSC2 from "occupied" to "idle", optionally, simultaneously sends a handover to the BSC1.
  • the Handover Required Reject message indicates that the handover failed.
  • BSC1 keeps the call of the MS identified by the Call-ID 1 value unchanged.
  • the MSC Server sends a Clear Command message to the BSC2, and the state of the Call-ID2 corresponding to the modified call has no timing relationship restriction; and the related resources established for the call-cutting BSC2 on the MGW, for example, notify the MGW to delete the call creation. There are also no timing relationship restrictions for TDM endpoints and IP endpoints.
  • FIG. 11 is a flowchart of Embodiment 9 of a call release method according to an embodiment of the present invention; wherein a source BSC is recorded as BSC1, a target BSC is recorded as BSC2, and a terminal MS is normally called under BSC1, and Call-ID1 is used.
  • the value identifies the call at BSC1, and the specific steps include:
  • Step 901 The BSC 1 sends a handover request (Handover Required) message to the MSC Server, where the handover request message carries the voice coding RanCl (Ran Codec) of the current use of the user MS and the BSC1; requesting to switch the call of the MS To a more suitable cell;
  • the handover request message carries the voice coding RanCl (Ran Codec) of the current use of the user MS and the BSC1; requesting to switch the call of the MS To a more suitable cell
  • Step 902 The MSC Server selects a cell under the BSC2 as the target cell cut by the MS from the recommended cell according to the information reported by the BSC1 through the handover request message
  • TDM endpoint and IP endpoint send a Handover Request message to BSC2, which carries the Call-ID2 value assigned to the call under BSC2, and changes the state of the Call-ID2 value from "idle" to "occupied”
  • the message also carries the recommended code list, the created TDM endpoint information and the IP endpoint information;
  • Step 903 The BSC2 identifies the cut-in call by using the Call-ID2 value, that is, changing the state of the Call-ID2 value from "idle” to "occupied", allocating resources, and returning a Handover Request Acknowledge message; the message indicates the MS Switch to the designated cell under the target BSC2;
  • Step 905 After the MS receives the handover command, the handover is performed, but if the handover fails, the handover failure (Handover Failure) message is sent to the BSC1.
  • the handover failure Haandover Failure
  • Step 906 The BSC1 maintains a call corresponding to the Call-ID 1 value, and sends a Handover Failure message to the MSC Server.
  • Step 907 The MSC Server receives the handover failure message, and notifies the MGW to release the resources allocated to the BSC2, such as the created TDM endpoint resource and the IP endpoint resource, and modify the state of the Call-ID2 value from "occupied" to "idle".
  • BSC2 sends a Clear Command message;
  • Step 908 The BSC2 receives the Clear Command message, translates all air interfaces and ground resources prepared for the call of the MS, and changes the state of the call-occupied Call-ID2 value from "occupied" to "idle", and returns Clear to the MSC Server. Complete message.
  • the MSC Server sends a Clear Command message to the BSC2, and the modification is performed.
  • the state of Call-ID2 corresponding to the call has no limitation on the timing relationship; and the MGW is notified to release the related resources established for the call-in BSC2, such as notifying the MGW to delete the TDM endpoint and the IP endpoint created for the call, and there is no limitation on the timing relationship.
  • FIG. 12 is a flowchart of Embodiment 10 of a call release method according to an embodiment of the present invention; in this embodiment, a handover between BSCs belonging to the same MSC is required, because the source BSC requests a translation call during the handover process.
  • the failure is taken as an example, where the source BSC is recorded as BSC1, the target BSC is recorded as BSC2, the terminal MS is normally in the BSC1, and the Call-ID1 value is used to identify the call at the BSC1.
  • the specific steps include:
  • Step 1001 The BSC 1 sends a Handover Required message to the MSC Server, requesting to switch the call of the MS to a more suitable cell.
  • Step 1002 The MSC Server selects a cell under the BSC2 as a target cell cut by the MS from the recommended cell according to the BSC1 information, and sends a handover request (Handover Request) message to the BSC2.
  • the message carries the Call-ID2 value assigned to the call under BSC2, and the state of the Call-ID2 value is changed from "idle" to "occupied”.
  • the message also carries the recommended code list, created TDM endpoint information and IP.
  • BSC2 receives the handover request message, identifies the call that is cut in by the Call-ID2 value, and changes the state of the Call-ID2 value from "idle” to "occupied", allocates resources, and returns a handover request confirmation. (Handover Request Acknowledge ) message;
  • Step 1004 The MSC Server sends a Handover Command message to the MS through the BSC 1 to instruct the MS to switch to the designated cell under the target BSC2.
  • Step 1005 After receiving the handover command, the MS performs the handover, but during the execution, the BSC1 sends a Clear Request message to the MSC Server for some reason, for example, the BSC1 expires after the T8 timer expires. After receiving the Handover Failure message reported by the MS, the BSCl sends a Clear Request message to the MSC Server. At this time, the BSCl also needs to retain the Call-ID1 and related resources allocated for the call.
  • Step 1006 After receiving the Clear Request request message, the MSC Server determines that the call cannot be continued; the MSC Server translates all the resources allocated by the MS, and sets the value of the Call-ID 1 value and the Call-ID2 value from the "occupied" state. Modified to "idle"; the MSC Server sends a Clear Command message to BSC1 and BSC2 respectively;
  • Step 1007 BSC1 and BSC2 receive the Clear Command message, and release all the resources prepared for the MS, and respectively change the state of the Call-ID1 value and the Call-ID2 value corresponding to the call from "occupied" to "idle", BSC1 and Both BSC2 return a Clear Complete message to the MSC Server.
  • the MSC Server sends a Clear Command message to the BSCl and the BSC2, and the state of the Call-ID1 and the Call-ID2 corresponding to the modified call has no timing relationship restriction; and the related resources established for the call-cutting BSC2 on the MGW are released, such as a notification.
  • the MGW deletes the TDM endpoints and IP endpoints created for the call and also has no timing relationship restrictions.
  • FIG. 13 is a flowchart of Embodiment 11 of a call release method according to an embodiment of the present invention; in this embodiment, a handover between BSCs belonging to the same MSC fails due to an abnormality of the MSC Server during the handover process.
  • the source BSC is recorded as BSC1
  • the target BSC is recorded as BSC2
  • the terminal MS is normally in the BSC1
  • the Call-ID1 value is used to identify the call in the BSC1.
  • the specific steps include:
  • Step 1101 The BSC1 sends a Handover Required message to the MSC Server, requesting to switch the call of the MS to a more suitable cell.
  • Step 1102 The MSC Server checks the information reported by the application message according to the BSC1, and recommends A cell in the BSC2 is selected as the target cell for the MS to be handed over. After the relevant resource is successfully allocated to the BSC2, a handover request (Handover Request) message is sent to the BSC2, and the message carries the Call-ID2 value assigned to the call under the BSC2. Modifying the state of the Call-ID2 value from "idle" to "occupied", the message also carries the recommended code list, the created TDM endpoint information and the IP endpoint information;
  • Step 1103 The BSC2 receives the handover request message, and identifies the hand-in call by using the Call-ID2 value, that is, changing the state of the Call-ID2 value from "idle” to "occupied", allocating resources, and returning a handover request acknowledgement (Handover Request Acknowledge) Message
  • Step 1104 The MSC Server sends a handover command (Handover Command) message to the MS through the BSC 1 to instruct the MS to switch to the designated cell under the BSC2.
  • a handover command Handover Command
  • the MSC Server finds that the fault occurs before sending the Handover Command message, and therefore needs to release all the resources allocated for the MS, and then changes the state of the Call-ID 1 value and the Call-ID2 value from "occupied" to "idle.”
  • the MSC Server sends a Clear Command message to BSC1 and BSC2, respectively;
  • Step 1105 BSC1 and BSC2 are translated into all the resources prepared by the MS, and the state of the Call-ID1 value and the Call-ID2 value corresponding to the call are respectively changed from "occupied" to "idle", and both BSC1 and BSC2 return Clear to the MSC Server. Complete message.
  • the MSC Server sends a Clear Command message to the BSC1 and the BSC2, and the state of the Call-ID1 and Call-ID2 corresponding to the modified call has no timing relationship restriction; and the resource related to the release of the call, for example, the notification deletes the call on the MGW. There are also no timing relationship restrictions for the created TDM endpoints and IP endpoints.
  • FIG. 14 is a schematic structural diagram of Embodiment 1 of a call release device according to an embodiment of the present invention. Intention, this embodiment includes:
  • the embodiment further includes a first receiving module 3, configured to receive an allocation failure message sent by the base station controller in the call distribution process, or a carrier failure reason sent after receiving the target base station controller call handover failure in the call handover process. a handover failure message of the value; or a handover failure message carrying a failure cause value sent after the source base station controller fails to call handover in the call handover procedure; or in the call handover procedure, receiving a clear request message sent by the source base station controller .
  • the clear command sending module 4 is configured to modify the status of the call identifier and send a clear command message to the base station controller.
  • the embodiment further includes a second receiving module 5, configured to receive, by the base station controller, the resource related to the call, and modify the status of the call identifier from "occupied" to "free” or a clearing message returned later.
  • FIG. 15 is a schematic structural diagram of a second embodiment of a call release apparatus according to an embodiment of the present invention.
  • the embodiment includes: a reset message sending module 6 and a receiving response module 7, where the reset message sending module 6 is configured to detect The call identification identity to the identified call is abnormal and/or the call is abnormal and/or an operation maintenance request is received, the call related resource is released, the status of the call identification is changed from "occupied" to "idle", and a reset resource message is sent.
  • the receiving response module 7 is configured to receive the resource related to the call by the peer network element, and modify the status of the call identifier of the identified call from "occupied" to "idle” simultaneously or after returning Reset resource response message.
  • the reset message sending module 6 of this embodiment specifically includes: a detecting unit, configured to detect whether the call identifier of the identified call is abnormal, and/or whether the call is abnormal on the local network side, and/or the call is on the opposite network element side Whether it is abnormal, whether an operation and maintenance request is received; a decoding unit, configured to release the resource related to the call, and modify the state of the call identifier from "occupied" to "idle”; the sending unit is configured to send a reset resource message to the pair End network element.
  • the deciphering unit is specifically configured to: when the call identifier of the identified call is detected abnormal, and/or the call is abnormal on the local NE side or on the opposite network element side, and/or the operation and maintenance request is received, the call is released. Related resources.
  • FIG. 16 is a schematic structural diagram of a third embodiment of a call release apparatus according to an embodiment of the present invention.
  • the embodiment includes: an SCCP message sending module 8 and an acknowledgment message receiving module 9, wherein the SCCP message sending module 8 is used to When all calls need to be cleared, all the call-related resources are released, and the status of the call identifier corresponding to all calls is changed from "occupied" to "idle", and the SCCP connectionless type request message is sent to the peer network element; the acknowledgement message is received.
  • the module 9 is configured to receive the returned SCCP connectionless type confirmation message after the network element successfully releases all call related resources simultaneously or after.
  • the SCCP message sending module 8 specifically sends a reset resource message carrying a call type cell.

Landscapes

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

Abstract

Dans un mode de réalisation, l'invention concerne un procédé et un dispositif de libération d'appel. Ledit procédé consiste en: dans le cas où l'élément réseau détecte une anomalie dans l'identifiant d'appel et/ou l'appel est anormal et/ou une demande d'opération de maintenance est reçue, la libération des ressources relatives à l'appel, le changement du statut de l'identifiant d'appel de "occupé" à "en attente" et l'envoi d'un message de demande de type sous-système de commande de connexions sémaphore (SSCS) sans fil à l'élément réseau opposé; la réception du message de confirmation SSCS sans fil émanant de l'élément réseau opposé, lequel libère les ressources relatives à l'appel vers le côté élément réseau opposé et change le statut de l'identifiant de l'appel en cours de "occupé" à "en attente". Le procédé et le dispositif de libération d'appel proposés dans un mode de réalisation de la présente invention libèrent l'identifiant de l'appel en même temps que les ressources relatives à l'appel, permettant ainsi une utilisation efficace de l'identifiant d'appel et améliorant de ce fait, entre autres, le taux de réussite de transfert ou de répartition d'appels.
PCT/CN2009/073277 2008-08-14 2009-08-14 Procédé et dispositif de libération d'appels WO2010017781A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
RU2011131539/08A RU2473188C1 (ru) 2008-08-14 2009-08-14 Способ разъединения вызова и устройство для его осуществления

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN2008101183659A CN101651889B (zh) 2008-08-14 2008-08-14 呼叫释放方法及装置
CN200810118365.9 2008-08-14

Publications (1)

Publication Number Publication Date
WO2010017781A1 true WO2010017781A1 (fr) 2010-02-18

Family

ID=41668716

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/073277 WO2010017781A1 (fr) 2008-08-14 2009-08-14 Procédé et dispositif de libération d'appels

Country Status (3)

Country Link
CN (1) CN101651889B (fr)
RU (1) RU2473188C1 (fr)
WO (1) WO2010017781A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102612165B (zh) * 2012-03-21 2015-05-20 大唐移动通信设备有限公司 一种释放资源的方法及装置
CN102625474A (zh) * 2012-03-21 2012-08-01 大唐移动通信设备有限公司 一种释放资源的方法及装置
ES2913928T3 (es) 2015-09-15 2022-06-06 Huawei Tech Co Ltd Método de procesamiento de servicios, dispositivo de red de acceso de procesamiento de servicios, medio de almacenamiento legible por ordenador y sistema de comunicaciones para procesamiento de servicios de VoLTE
CN112202975B (zh) * 2020-12-08 2021-04-06 深圳追一科技有限公司 通话数据的管理方法、装置、计算机设备和存储介质
CN113301598B (zh) * 2021-05-24 2021-12-21 中国电信集团系统集成有限责任公司 一种基站及核心网的资源管理方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6292463B1 (en) * 1998-07-06 2001-09-18 Alcatel Canada Inc. Method and apparatus for recovering from a signalling failure in a switched connection data transmission network
US20070071202A1 (en) * 2005-06-30 2007-03-29 Kabushiki Kaisha Toshiba Server apparatus
CN101212807A (zh) * 2006-12-30 2008-07-02 中兴通讯股份有限公司 一种漂移无线网络控制器内的硬切换方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2068056C (fr) * 1991-05-07 1998-06-16 Kazuo Sakagawa Noeud de commutation de reseau a commutation du type a multiplexage d'etiquettes
US6104926A (en) * 1995-07-31 2000-08-15 Gte Airfone, Incorporated Call handoff
KR100326330B1 (ko) * 1998-05-08 2002-06-26 윤종용 이동통신시스템의핸드오프장치및방법
US20050089007A1 (en) * 2003-10-28 2005-04-28 Samsung Electronics Co., Ltd. System and method for performing handoffs of mobile station-to-mobile station packet data calls in a wireless network
JP2005142766A (ja) * 2003-11-05 2005-06-02 Matsushita Electric Ind Co Ltd 基地局装置及び基地局装置におけるリソースの割り当て方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6292463B1 (en) * 1998-07-06 2001-09-18 Alcatel Canada Inc. Method and apparatus for recovering from a signalling failure in a switched connection data transmission network
US20070071202A1 (en) * 2005-06-30 2007-03-29 Kabushiki Kaisha Toshiba Server apparatus
CN101212807A (zh) * 2006-12-30 2008-07-02 中兴通讯股份有限公司 一种漂移无线网络控制器内的硬切换方法

Also Published As

Publication number Publication date
CN101651889B (zh) 2011-12-21
RU2473188C1 (ru) 2013-01-20
CN101651889A (zh) 2010-02-17

Similar Documents

Publication Publication Date Title
JP4040975B2 (ja) セッション開始プロトコルによる、マルチメディア呼を可能にするための方法および装置
US7787444B2 (en) Enhancement of dual transfer mode when circuit switched resources are released
WO2014124558A1 (fr) Procédé, dispositif et système de transfert intercellulaire d'un groupe d'équipements utilisateur
WO2007078159A1 (fr) Procede et appareil pour emettre des donnees sip d'equipement utilisateur en mode repos dans un systeme de communications mobiles
KR20160021262A (ko) 전송 방식 전환 방법, ue 및 기지국
WO2012025001A1 (fr) Procédé et système de traitement de services antérieurs
WO2010017781A1 (fr) Procédé et dispositif de libération d'appels
CN102238664B (zh) 基站切换中无线资源连接重建拒绝的方法和系统
WO2009067912A1 (fr) Procédé et dispositif de commutation pour mettre en œuvre une commutation
KR20070060414A (ko) 이동통신 시스템에서 호 설정 지연의 최소화를 위한 호설정 방법 및 장치
KR101012004B1 (ko) 이동통신 시스템에서 핵심망과 제어국 사이의 자원 절약을 위한 장치 및 방법
WO2012019490A1 (fr) Procédé et dispositif de transfert inter-système pour service de commutation par paquets dans un appareil de commande de réseau radio bimode
WO2013079019A1 (fr) Procédé de communication, station de base, contrôleur de station de base et centre de commutation de communications mobiles
WO2015058520A1 (fr) Dispositif et procédé de traitement de service pour communications sans fil
JP2020504956A (ja) コンテキスト解放方法、機器及びシステム
WO2010102585A1 (fr) Procédé, dispositif et système d'établissement de commutateur local pour une conversation locale durant un établissement d'appel
WO2011069375A1 (fr) Procédé, appareil et système destinés à commander une commutation locale
WO2010078678A1 (fr) Procédé, système et drnc pour transmettre une capacité de cellule à travers une interface iur
WO2009046594A1 (fr) Procédé de négociation de codec entre un réseau sans fil et un réseau central dans un système de télécommunication mobile
WO2009146664A1 (fr) Procédé, appareil et système de transfert et de traitement d'appel
WO2006045244A1 (fr) Procede et dispositif de mise en place d'un service d'appel secret
WO2010091612A1 (fr) Procédé, dispositif de coeur de réseau et sous-système de station de base pour établir un central local
JP2013546278A (ja) トンネルをリダイレクションするための方法およびインターワーキング機能エンティティ
EP2568746B1 (fr) Système, terminal et procédé destinés à transmettre des messages 1x
EP2408233B1 (fr) Procédé de transfert d'appel et système de communication mobile entre systèmes de station de base

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

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: 976/KOLNP/2011

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 2011131539

Country of ref document: RU

122 Ep: pct application non-entry in european phase

Ref document number: 09806384

Country of ref document: EP

Kind code of ref document: A1