WO2010017781A1

WO2010017781A1 - Call release method and device

Info

Publication number: WO2010017781A1
Application number: PCT/CN2009/073277
Authority: WO
Inventors: 秦钧; 王之曦
Original assignee: 华为技术有限公司
Priority date: 2008-08-14
Filing date: 2009-08-14
Publication date: 2010-02-18
Also published as: CN101651889B; RU2473188C1; CN101651889A

Abstract

A call release method and device are provided by the embodiments of the present invention, and the method includes that: when the network element detects that the call identifier identifying a call is abnormal and/or the call is abnormal and/or an operation maintenance demand is received, the call related resources are released, and the state of the call identifier is modified from “occupied” to “idle”, the SCCP connectionless type request message is transmitted to the opposite network element; the SCCP connectionless type acknowledge message returned by the opposite network element is received, and the opposite network element is used to release the call related resources at the opposite network element side, and modify the state of the call identifier occupied by the call from “occupied” to “idle”. The call release method and device provided by the embodiments of the present invention release the call identifier identifying the call while releasing the call related resources, enable the call identifier to be used efficiently, and also improve the success rate of the processes of the call handover, the call assignment and etc.

Description

Call release method and device

The present application claims priority to Chinese Patent Application No. 200810118365.9, entitled "Calling and Disposing Method and Apparatus" on August 14, 2008, the entire contents of which are incorporated herein by reference.

Technical field

The present invention relates to the field of mobile communications, and in particular, to a call release method and apparatus. Background technique

The Global System for Mobile communication (GSM) 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. 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. Thus the Third Generation Partnership Project (3 ^rd Generation Partnership Project, referred to as 3GPP) proposed IP-based A-interface transport bearer (A interface over IP, referred AoIP), to discuss the A interface user plane IP-based solution.

When the T interface is used in the A interface, the coaxial cable is used to connect the CN to the Base Station Controller (BSC). Each call occupies a 64 kbps time slot (Timeslot) on the coaxial cable. , that is, 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. For a coaxial cable using 2M bandwidth (ie, one relay, which can be multiplexed into 32 64 kbps time slots), 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

After the AoIP is introduced, 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. When the Mobile Switching Center (MSC) or the BSC loses the Signaling Connection Control Part (SCCP) link, the Call-ID can be used to request the other party to simultaneously release the relevant call resources. . If 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

It is also possible to combine several Call-ID values into a Call-ID list, as expressed in Table 3:

table 3

The Call-ID value uniquely identifies a call on the MSC and BSC. When 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.

After the SCCP connection between the MSC and the BSC related to the specific call is interrupted, 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.

In the process of implementing the present invention, the inventor has found that the prior art has at least the following drawbacks: In the prior art, 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. Assume that the MSC Server cyclically allocates the Call-ID in the order of the value of the Call-ID from small to large. When a call is normally translated, the MSC Server and the BSC do not timely release the corresponding Call-ID value, and the call corresponds to the call. When the Call (ID) is assigned the first (i 232) call, the Call-ID value must be applied again. However, since 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 according to an aspect of the embodiments of the present invention 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;

And receiving, by the peer network element, an SCCP connectionless type confirmation message, where the peer network element is configured to release the call related resource on the opposite network element side, and the status of the call identifier of the identified call is determined by "Occupy" is changed to "Idle".

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;

Translating the resources allocated for the call of the base station controller, and changing the status of the call identifier corresponding to the call from "occupied" to "idle".

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:

When the call-related network element supports the AoIP interface function, and the call is kept in the network element, 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 according to another aspect of the present invention 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".

According to another aspect of the embodiments of the present invention, a call release device is further provided, 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.

According to another aspect of the present invention, a call release device is further provided, 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;

Corresponding to receiving the SCCP connectionless type request message, the resources of all calls corresponding to the call type cell are released.

The call release method and apparatus provided by the embodiments of the present invention 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. DRAWINGS

1 is a structural diagram of a prior art GSM system;

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;

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; A schematic diagram of the structure of the device embodiment 3. detailed description

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. As shown in FIG. 2, 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.

As shown in FIG. 3, 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.

As shown in FIG. 4, 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;

If the Call-ID1 value in the BSC has been assigned to another call, the BSC clearly fails in the handover failure message because the "call identity has been assigned";

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;

In this embodiment, 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.

As shown in FIG. 5, FIG. 5 is a flowchart of a third embodiment of a call release method according to an embodiment of the present invention. In this embodiment, 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. There is a corresponding failure reason indication value and/or an Assignment Failure message of the Call-ID1 to the MSC Server; When the Call-ID1 value in the BSC has been assigned to another call, the explicit failure reason in the allocation failure message is "call identity has been assigned";

When it is determined that the Call-ID 1 value has been assigned to other calls, the allocation fails, and the call and related resources originally identified by the Call-ID 1 value in the BSC are reserved, and the Assignment Failure message is returned;

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. Message

In this embodiment, 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.

As shown in FIG. 6, 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"; Step 402: 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 translated;

In this embodiment, 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.

In this embodiment, 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).

As shown in Table 3, for the identification mode of the Call Identifier List cell, 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. In this way, for a network element that supports the ΑθΙΡ function, 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).

Further, in order to improve the efficiency of the call release, 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.

In the mode B, 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.

In the method C, 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 new expression of the Reset message is as follows:

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:

00: All calls that do not distinguish between types;

01: All calls in the AoTDM interface mode;

10: All calls in the AoIP interface mode;

11 : Reserved (undefined).

If 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).

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.

Here, the Call type cell only uses the interface type of the A interface user plane to distinguish the call as an example. Actually, the call type can be divided according to other standards. In addition, as the corresponding call classification increases or decreases, 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.

As shown in FIG. 7, 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.

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

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.

As shown in FIG. 8, 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. For example, 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. When the MS wants to be handed over to the BSC2 by the BSC1, 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.

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.

In this embodiment, 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.

As shown in FIG. 9, 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;

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.

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.

For example, 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. 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".

In this embodiment, 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.

As shown in FIG. 10, 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, and the terminal MS is in normal call under BSC1, and 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 In the appropriate cell, in step 802, 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. 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 803: BSC2 identifies the hand-in call by the Call-ID2 value, but the resource allocation fails or the Call-ID2 value is allocated in BSC2. If the call fails due to other call instances (that is, the state of the Call-ID2 value is "occupied"), the BSC2 keeps the state of the Call-ID2 value unchanged, and returns a Handover Failure message carrying the specific failure cause value to MSC Server;

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.

Then BSC1 keeps the call of the MS identified by the Call-ID 1 value unchanged.

In this embodiment, 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.

As shown in FIG. 11, 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; 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, and after the relevant resource is successfully allocated to the BSC2, for example, creating a pairing for the BSC2 on the MGW. 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.

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.

In this embodiment, 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.

As shown in FIG. 12, 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. Step 1003, 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.

In this embodiment, 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.

As shown in FIG. 13, 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. For example, 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 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.

Or 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.

In this embodiment, 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.

As shown in FIG. 14, 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 resource release module 1 and the state modification module 2, wherein the resource release module 1 is configured to release the end of the call-related resource; the state modification module 2 is configured to modify the state of the call identifier corresponding to the call from "occupied" to "idle" " .

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.

As shown in FIG. 15, 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.

As shown in FIG. 16, 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.

It should be noted that the above embodiments are only intended to illustrate the technical solutions of the present invention and are not to be construed as limiting the embodiments of the present invention. Modifications or equivalent substitutions may be made to the technical solutions of the present invention, and such modifications or equivalents may not detract from the technical solutions of the present invention.

Claims

Rights request

A method for calling and releasing a call, comprising: translating a resource related to the call 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 Modifying the status of the call identifier from "occupied" to "idle", and sending a signaling connection control part SCCP connectionless type request message to the peer network element;

Receiving an SCCP connectionless type confirmation message returned by the peer network element, where the peer network element is used for releasing the call related resource on the opposite network element side, and the call identifier of the identified call is The status is changed from "occupied" to "idle".

The call decimation method according to claim 1, wherein the SCCP connectionless type request message is a reset resource message carrying the call identity, and the SCCP connectionless type request confirmation message is a carrying place. A reset resource response message for the call identity.

The call translation method according to claim 2, wherein the detecting the abnormality of the call specifically includes:

A notification message that the call is abnormal on the network element side and/or receives a call abnormality of the opposite network element is detected.

The call release method according to claim 3, wherein the notification message that the call abnormality of the peer network element is received specifically includes:

The call identifier that receives the identified call is a notification message that the peer network element has been allocated.

The call decimation method according to claim 1, wherein when the AoIP interface function is supported, the sending the SCCP connectionless type request message specifically includes: sending a reset message carrying a call type cell.

6. The call translation method according to claim 1, wherein said releasing said call Calling the related resource, changing the status of the call identifier from "occupied" to "idle" specifically includes: releasing all call related resources, and changing the status of the call identity of all calls from "occupied" to "idle""; or,

All the call-related resources of the same type are translated, and the status of the call identifiers of all calls of the same type is changed from "occupied" to "idle"; all calls of the same type include AOTDM based on time division multiplexing A interface transmission All calls and/or AOIPs are transmitted based on the A interface of the IP transport bearer.

The call decimation method according to claim 6, wherein the translating the call related resource, changing the status of the call identifier from "occupied" to "idle" further includes: All the resources related to the call are translated, and the peer network element is used to translate all the resources related to the call on the opposite network element side; or

Corresponding to the translation and release of all call-related resources of the same type, the peer network element releases all call-related resources of the same type on the opposite network element side.

The call decimation method according to any one of claims 1 to 7, wherein the network element is a mobile switching center, and the peer network element is a base station controller paired with the mobile switching center. Or the network element is a base station controller, and the peer network element is a mobile switching center paired with the base station controller.

9. A call release method, characterized in that:

Sending an allocation request message carrying the assigned call identifier to the base station controller, and when the base station controller fails to perform the allocation process, receiving an allocation failure message sent by the base station controller, where the allocation failure message carries a failure cause value;

Translating the resources allocated for the call of the base station controller, and calling the call corresponding to the call The status of the identity is changed from "occupied" to "idle".

10. A call release method, characterized in that:

The handover failure message carrying the failure cause value sent after the call failure of the target base station controller is received, releasing the resource allocated for the call of the terminal in the target base station controller, and the state of the call identifier corresponding to the call is occupied by "Modified to "Idle", the handover failure message carries the failure cause value.

A call identification method, comprising:

When the call-related network element supports the AoIP interface function, and the call is kept in the network element, 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.

12. A call release device, comprising:

And 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 receives an operation and maintenance request, and the resource related to the call is released, and the status of the call identifier is The "reset" is changed to "idle", and the reset resource message is sent to the peer network element; the receiving response module is configured to receive the reset resource response message returned by the peer network element, where the peer network element is used for translation The resource related to the call of the peer network side is placed, and the status of the call identifier of the identified call is changed from "occupied" to "idle".

The call release device according to claim 12, wherein the reset message sending module 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 whether the call is abnormal on the opposite network element side, and whether an operation and maintenance request is received; a decoding unit, configured to translate the call related resource, and modify the status of the call identifier from "occupied" to "idle";

The sending unit is configured to send a reset resource message to the peer network element.

14. A call release device, comprising:

The SCCP message sending module is configured to: when the network element detects that the call identifier of the identified call is abnormal, and/or the call is abnormal on the side of the local network element or on the opposite end of the network element, and/or receives an operation and maintenance request, all needs to be cleared. During the call, all the call-related resources are released, and the status of the call identifier corresponding to all the calls is changed from "occupied" to "idle", and the SCCP connectionless type request message is sent to the opposite network element;

An acknowledgement message receiving module, configured to receive the SCCP connectionless type confirmation returned by the network element

The call release device according to claim 14, wherein the SCCP message sending module specifically transmits a reset resource message carrying a call type cell.

16. A call release device, comprising:

a resource translation module, for calling related resources at the end of the release;

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 handover process, receiving a handover failure message carrying a failure cause value sent after the source base station controller fails to call handover; or, in the call handover procedure, receiving a clear request message sent by the source base station controller.

The call decoding device according to claim 16, further comprising: a clear command sending module, configured to modify a state of the call identifier, and send a clear command message to the base station controller;

And a second receiving module, configured to receive a clearing completion message returned by the base station controller, where the base station controller is configured to release the call related resource, and modify the status of the call identifier from “occupied” to “idle”.

18. A method for calling a translation, characterized in that it comprises:

Receiving a SCCP connectionless type request message, where the SCCP connectionless type request message is a reset message of a call type cell;

The method according to claim 18, wherein the resources for all calls corresponding to the paging type cell are:

The resources of all calls of the same type are translated. All calls of the same type include all calls transmitted by the AOTDM based on the time division multiplexed A interface and/or all calls transmitted by the AOIP based on the A interface of the IP transport bearer.