Method, apparatus and system for bearing voice data

A method for bearing voice data includes: a) a calling MSCe and the called MSCe determining that a calling MS and a called MS support the same voice coding and decoding type and that a call is a point-to-point call; b) the calling MSCe and the called MSCe sending Bearer Update Requests to the calling BSC and the called BSC, respectively; and c) the calling BSC and the called BSC setting up a voice bearer path between the calling MS and the called MS according to the requests from the MSCes. As a result, transparent transmission of voice data in a MGW is avoided so that transmission delay can be reduced and additional loading of the MGW can be avoided.

FIELD OF THE INVENTION

The present invention relates to voice bearing technology in a wireless communication system, and in particular to a method, apparatus, and system for bearing voice data.

BACKGROUND OF THE INVENTION

In a wireless communication system, an A interface provides an interface between a radio access network and a core network. A base station controller (BSC) communicates with mobile switching center (MSC) through an A1 interface or an A2 interface of the A interface. The A1 interface is a signaling interface used to transmit signaling information between the BSC and the MSC, and the A2 interface is the service interface used to transmit voice information between the BSC and the MSC.

IP transformation is a current trend in network development. The A interface over IP is defined in the Interoperability Specification (IOS) 5.0 of the Third Generation Partnership Project 2 (3GPP2).

FIG. 1shows the reference model of the A interface over IP in a prior wireless communication system. As shown inFIG. 1, the MSC is divided into an MSC Emulation (MSCe) and a media gateway (MGW) based on the principle of separating bearer and control in the core network, and defines the A interface over IP as the A1p/A2p interface in IOS 5.0.

The MSCe fulfills the function of a control plane and the A1p interface is the interface between the BSC and the MSCe.

The MGW fulfills the function of a service plane, and the A2p interface is the interface between the BSC and the MGW.

FIG. 2shows the signaling flow between a calling mobile station (MS) and a called MS during a call in the system shown inFIG. 1. The dashed line inFIG. 2indicates the flow of service information, and the solid lines indicate the flow of control information. The flow as illustrated includes the following steps.

Step201: The calling MS and called MS set up a call connection based on the flow specified by the IOS.

Step202: The MGW plays a call progress indication to the calling MS.

Step203: The called MS rings.

Step204: The called MS answers the call and sends a response message to MSCe.

Step205: The MSCe notifies the MGW to set up a voice path between the calling MS and the called MS after receiving the response message. The calling MS then communicates with the called MS.

In this step, because a transcoder (TC) is moved to the MGW from the BSC after the A interface is enabled over IP, the BSC encapsulates received voice data according, for example, to the Real-Time Transport Protocol (RTP), and sends the data to the MGW through the A2p interface. The MGW then sends the voice data processed by the TC to terminal through the corresponding BSC. If the calling MS and the called MS support the same voice coding and decoding types, the MGW can send the voice data directly to the BSC, as indicated by the arrow inFIG. 1. In this case, the TC need not process voice data between the called MS and the calling MS such as rate matching and code conversion. In this case, voice data is transparently transmitted in the MGW.

Analyzing, by the inventor of the application, the above method for transmitting voice data revealed that when the calling MS and the called MS support the same voice coding and decoding type, no processing of voice data is needed in the MGW, but the transparent transmission of the voice data in the MGW adds to the transmission delay of the voice data and wastes the processing capability of the MGW.

SUMMARY OF THE INVENTION

The embodiments of the present invention described herein provide a method for bearing voice data so that the transmission delay can be reduced and that the load of the MGW can be mitigated.

The embodiments of the present invention also provide a system for bearing voice data so that the transmission delay can be reduced and that the load of the MGW can be mitigated.

The embodiments of the present invention further provide an MSCe so that the transmission delay can be reduced and that the load of the MGW can be mitigated.

The embodiments of the present invention provide a method for bearing voice data, including:

a) the calling MSCe and the called MSCe determine that the calling MS and the called MS support the same voice coding and decoding type and that the call between the calling MS and the called MS is a point-to-point call;

b) the calling MSCe and the called MSCe each send a Bearer Update Request to the calling BSC and the called BSC respectively; and

c) the calling BSC and the called BSC set up a voice bearer path between the calling MS and the called MS according to the requests from the calling MSCe and the called MSCe.

The embodiments of the present invention described herein also provide a system for bearing voice data, including a calling BSC, a calling MSCe, a called BSC, and a called MSCe, wherein:

a) the calling MSCe and the called MSCe are configured to judge whether the calling MS and the called MS support the same voice coding and decoding type and whether the call is a point-to-point call, and to send a Bearer Update Request to the calling BSC and the called BSC respectively; and

b) the calling BSC and the called BSC are configured to set up a voice bearer path between the calling MS and the called MS according to the requests from the calling MSCe and the called MSCe.

The embodiments of the present invention described herein provide an MSCe, including a judgment module and a communication module, wherein:

a) the judgment module is configured to judge whether the calling MS and the called MS support the same voice coding and decoding type and whether the call is a point-to-point call, and to notify the communication module of the judgment result; and

b) the communication module is configured to send a Bearer Update Request to the BSC according to the notification from the judgment module.

In the technical solution provided in the embodiments of the present invention described herein, after the called MS answers the call from the calling MS, the calling MSCe and the called MSCe respectively judge whether the calling MS and the called MS support the same voice coding and decoding type, and whether the call is a point-to-point call. If the calling MS and the called MS support the same voice coding and decoding type and the call is a point-to-point call, the calling MSCe and the called MSCe each send a Bearer Update Request to the calling BSC and the called BSC respectively; then the calling BSC and the called BSC set up a voice bearer path between the calling MS and the called MS accordingly. The transparent transmission of voice data in the MGW is avoided. Hence, the transmission delay of voice data is reduced and the load of the MGW is mitigated.

DETAILED DESCRIPTION OF THE INVENTION

The present invention is hereinafter described in detail with reference to the embodiments and accompanying drawings.

In the technical solution provided in the embodiments of the present invention, if a calling MS and a called MS support the same voice coding and decoding type, and a call between the calling MS and the called MS is a point-to-point call, a voice bearer path is set up between the calling BSC and the called BSC.

The BSC does not have resources for functions such as tone playing and number receiving, and cannot play call progress indications such as ring back tone. Therefore, in the embodiments of the present invention, functions such as tone playing and number receiving are fulfilled by the MGW. Before the called MS answers the call, a voice bearer path is set up between the BSC and the MGW. After the called MS answers the call, if calling MSCe and called MSCe determine that the calling MS and the called MS support the same voice coding and decoding type and that the call between the calling MS and the called MS is a point-to-point call, each MSCe sends a Bearer Update Request to its corresponding BSC, which sets up a voice bearer path between the calling MS and the called MS. The voice data is transmitted between the two BSCs instead of between the BSC and the MGW. In this way, the transparent transmission of the voice data in the MGW is avoided.

In the above technical solution, the following methods may be used to judge whether the calling MS and the called MS support the same voice coding and decoding type:

method 1: Judge whether there are voice coding and decoding types supported by both the calling MS and the called MS;

method 2: Judge whether there are voice coding and decoding types supported by both the calling MS and the called MGW;

method 3: Judge whether there are voice coding and decoding types supported by both the calling MGW and the called MS; and

method 4: Judge whether there are voice coding and decoding types supported by both the calling MGW and the called MGW.

In the technical solution provided in the embodiments of the present invention, the calling BSC and the called BSC may or may not be the same. If the calling BSC and the called BSC are not the same, an IP connection between the two BSCs is needed to implement the technical solution provided in the embodiments of the present invention described herein.

Further, the calling MSCe and the called MSCe may or may not be the same. If the calling MSCe and the called MSCe are not the same, the calling MSCe and the called MSCe respectively judge whether the voice data between the calling MS and the called MS needs to be processed by the TC in local MGW, and whether the call between the calling MS and the called MS is a point-to-point call. After that, the calling MSCe and the called MSCe each send a Bearer Update Request to the calling BSC and the called BSC respectively.

FIG. 3shows the structure of a system for bearing voice data according to an embodiment of the present invention. In this embodiment, it is assumed that the calling MS and the called MS are under the same MSCe, MGW, BSC, and base transceiver station (BTS). The system shown inFIG. 3includes calling MS301, called MS302, BTS303, BSC304, MSCe305, and MGW306.

MSCe305is configured to judge whether the calling MS and the called MS support the same voice coding and decoding type, and whether the call between the calling MS and the called MS is a point-to-point call. If the calling MS and the called MS support the same voice coding and decoding type and the call is a point-to-point call, MSCe305is configured to send a notification to the BSC. For example, MSCe305may send a Bearer Update Request to BSC304so that MGW306no longer forwards voice data between the calling MS and the called MS. Instead, the BSC304may bear the voice data between the calling MS and the called MS.

BSC304is configured to set up a voice bearer path between the calling MS and the called MS upon receiving the notification (for example, the Bearer Update Request, from MSCe305) and to send a response to the MSCe305. BSC304is also configured to bear the voice data between the calling MS and the called MS and the call progress indication such as ring back tone played before MS302answers the call from MS301.

MGW306is configured to fulfill functions such as tone playing and number receiving, and to play a call progress indication such as ring back tone before MS302answers the call from MS301.

MSCe305in the system shown inFIG. 3includes a judgment module (not shown) and a communication module (not shown).

The judgment module is configured to judge whether the calling MS and the called MS support the same voice coding and decoding type, and whether the call between the calling MS and the called MS is a point-to-point call. If the calling MS and the called MS support the same voice coding and decoding type and the call between the calling MS and the called MS is a point-to-point call, the judgment module is configured to send a notification to the communication module.

The communication module is then configured to send a Bearer Update Request to the BSC according to the notification from the judgment module.

The communication module is also configured to send Bearer Update Requests to the BSC and to receive responses from the BSC.

MSCe305further includes a BSC information exchange module (not shown), which is configured to exchange BSC information with another MSCe through the communication module.

The technical solution provided in the embodiments of the present invention may also be implemented in an inter-BSC hard handoff of the calling MS or the called MS.

Based on the system inFIG. 3, the following describes a detailed implementation of the embodiments of the present invention in the process of a voice call. In signaling flowcharts provided for three examples of the present invention, dashed lines and solid lines indicate service information and control information respectively.

FIG. 4shows the signaling flow of a voice call in example 1 of the present invention. In this example, the calling BSC and the called BSC are not the same, but the calling MSCe and the called MSCe are the same. BSC1and BSC2, joined by an IP connection in between, are the calling BSC and the called BSC respectively. The flow illustrated byFIG. 4includes the following steps:

Step401: The calling MS and the called MS set up a call based on the flow specified by IOS 5.0.

The originated call message sent by the calling MS and a paging response message sent by the called MS contain the voice coding and decoding types supported by the calling MS and the called MS respectively. In this step, the voice coding and decoding types are recorded by the MSCe.

Step402: The MGW plays a call progress indication to the calling MS.

Step403: The called MS rings.

Step404: The called MS answers the call and sends a response message to the MSCe.

Step405: After receiving the response message from the called MS, the MSCe judges whether the calling MS and the called MS support the same voice coding and decoding voice type and whether the call is a point-to-point call. If the calling MS and the called MS support the same voice coding and decoding type and the calling is a point-to-point call, the MSCe executes step406; otherwise, a voice path is set up between the calling MS and the called MS as shown in step205ofFIG. 2and the flow ends.

In this step, the MSCe judges whether the calling MS and the called MS support the same voice coding and decoding type based on the supported voice coding and decoding types recorded in step401. The MSCe also determines that the call is a point-to-point call instead of a three-party call or a conference call. If the calling MS and the called MS support the same voice coding and decoding type and the call is a point-to-point call, the MSCe executes step406.

The method for judging whether the calling MS and the called MS support the same voice coding and decoding type and whether the call is a point-to-point call is omitted here.

Step406: The MSCe sends to BSC1a Bearer Update Request, which contains the IP address of BSC2and the User Datagram Protocol (UDP) port number of BSC2.

In this step, the MSCe requests BSC1to change the destination IP address and UDP port number of the voice bearer path of BSC1to the IP address and UDP port number of BSC2.

Step407: BSC1updates the voice bearer path between the calling MS and the called MS based on the request of the MSCe, and returns a Bearer Update Response to the MSCe.

Step408: The MSCe sends to BSC2a Bearer Update Request, which contains the IP address and UDP port number of BSC1.

In this step, the MSCe requests BSC2to change the destination IP address and UDP port number of the voice bearer path of BSC2to the IP address and UDP port number of BSC1.

Step409: BSC2updates the voice bearer path between the calling MS and the called MS based on the request of the MSCe and returns a Bearer Update Response to the MSCe.

A voice bearer path between the calling MS and the called MS is set up between BSC1and BSC2.

Step410: A voice path is set up between the calling MS and the called MS for a conversation.

Thereafter, the signaling flow of a voice call between the calling MS and the called MS in example 1 ends.

In the signaling flow shown inFIG. 4, step408and step409may alternatively be executed before or simultaneously with step406and step407.

In the embodiment shown inFIG. 4, after the bearer is updated in steps406to409, a new voice bearer path between the calling MS and the called MS is set up between the calling BSC and the called BSC. With transparent transmission in the MGW avoided, transmission delay is reduced, and added loading of the MGW is avoided.

The calling MSCe and the called MSCe are the same in embodiment 1. In actual practice, the technical solution provided in the embodiments of the present invention may apply to networks where the calling MSCe and the called MSCe are not the same. Embodiment 2 describes this case in detail.

FIG. 5shows the signaling flow of a voice call in example 2 of the present invention. In this example, the calling BSC and the called BSC are not the same, the calling MSCe and the called MSCe are not the same. As a result, the calling MS and the called MS are associated with different MSCes and BSCs. BSC1and BSC2, joined by an IP connection in between, are the calling BSC and the called BSC respectively. In this example, MSCe1/MGW1is the calling MSCe/MGW, and MSCe2/MGW2is the called MSCe/MGW. The method illustrated byFIG. 5includes the following steps:

Steps501to505are similar to steps401to Step405inFIG. 4. The calling MS and the called MS set up a call based on the flow specified by the IOS. In the process, MSCe1records the voice coding and decoding types supported by the calling MS and obtains, and records the voice coding and decoding types supported by the called MS or the called MGW from MSCe2. MSCe2records the voice coding and decoding types supported by the called MS, and obtains and records the voice coding and decoding types supported by the calling MS from MSCe1.

After the called MS answers the call, MSCe1judges whether both the calling MS and the called MGW or both the calling MS and the called MS support the same voice coding and decoding type according to the records and whether the call between the calling MS and the called MS is a point-to-point call.

If the calling MS and the called MS support the same voice coding and decoding type and the call is a point-to-point call, MSCe1executes step506; otherwise, a voice path is set up between the calling MS and the called MS as in step205ofFIG. 2and the flow ends.

Step506: MSCe1sends to MSCe2an INVITE message, which contains the IP address and UDP port number of BSC1.

In this step, MSCe1and MSCe2exchange the IP address and UDP port number of the local BSC based, for example, on the Session Initiation Protocol (SIP).

Step507: MSCe2judges whether the calling MS and the called MS support the same voice coding and decoding voice type, that is, whether the TC in the called MGW needs to process the voice coding and decoding data between the calling MS and the called MS, and whether the call is a point-to-point call.

In this step, MSCe2judges whether the calling MS and the called MS support the same voice coding and decoding type based on the recorded voice coding and decoding types.

Step508: MSCe2returns a response message (200 OK) to MSCe1based on the judgment in step507.

In this step, MSCe2determines the information to be contained in the response message according to whether the TC needs to process the voice data and whether the call is a point-to-point call.

If the voice data needs to be processed by the TC in MGW2or the call is not a point-to-point call, the 200 OK message returned to MSCe1contains the IP address and UDP port number of MGW2, and a voice bearer path is set up between the calling BSC and the called MGW for the calling MS and the called MS.

If the voice data does not need to be processed by the TC in MGW2and the call is a point-to-point call, the 200 OK message returned to MSCe1contains the IP address and UDP port number of BSC2, and a voice bearer path is set up between the calling BSC and the called BSC.

The Bearer Update Request message MSCe1sends to BSC1carries the IP address and UDP port number that are contained in the 200 OK message MSCe1receives in step508. The Bearer Update Request message MSCe2sends to BSC2carries the IP address and UDP port number that are contained in the INVITE message MSCe2receives in step506. After setting up a new voice bearer path according to the requests from MSCe1and MSCe2, BSC1and BSC2send a Bearer Update Response to MSCe1and MSCe2respectively.

Step513: A voice bearer path is set up between the calling MS and the called MS for a conversation.

Thereafter, the signaling flow of a voice call between the calling MS and the called MS in example 2 ends.

In the signaling flow shown inFIG. 5, step511and step512may alternatively be executed before or simultaneously with step509and step510.

In the foregoing example, if the calling MSCe and the called MSCe are not the same, the two MSCes respectively judge whether the voice coding and decoding data of the calling MS or the called MS needs to be processed by the TC in the local MGW, that is, whether the local MGW is unnecessary on the voice bearer link. Then the calling MSCe and the called MSCe send a Bearer Update Request to the calling BSC and the called BSC respectively. If the voice coding and decoding data does not need to be processed by the TCs in both MGWs, a voice bearer path is set up between the calling BSC and the called BSC for the calling MS and the called MS according to the method provided in the embodiments of the present invention. If transparent transmission in the MGW is done at one MGW and TC processing is needed at the other MGW, a voice bearer path is set up between the BSC at the transparent transmission MGW side and the MGW in which the TC processes the voice coding and decoding data. The transparent transmission of the voice coding and decoding data in the MGW is avoided. Thus, transmission delay is reduced and added loading of the MGW is avoided.

In example 1 and example 2, the serving BSC of the calling MS and the called MS doesn't change. In actual practice, an inter-BSC hard handoff of the calling MS or the called MS is possible because of the mobility of users. Example 3 describes the implementation of the technical solution provided in the embodiments of the present invention in this case.

FIG. 6shows the signaling flow of an inter-BSC hard handoff of the calling MS in example 3. S-BSC and T-BSC are the source BSC and target BSC of the calling MS for the hard handoff, respectively. BSC2is the called BSC, connected over IP to the S-BSC and the T-BSC. In this example, the voice bearer path has been updated following the method shown inFIG. 4and there is an ongoing voice bearer path between the S-BSC and BSC2. A hard handoff is performed according to the flow inFIG. 6if the S-BSC determines that an inter-BSC hard handoff is required. The method includes the following steps:

Step601: The S-BSC sends to MSCe a Handoff Required message carrying related target cell information of the T-BSC.

Step602: The MSCe locates the T-BSC according to the target cell information in the Handoff required message and sends a Handoff Request to the T-BSC to request resources of air interface and terrestrial links. The request also carries the IP address and UDP port number of BSC2.

In this step, the MSCe sends a Handoff Request to the T-BSC according to the standard handoff flow. The IP address and UDP port number in the request are the IP address and UDP port number of BSC2instead of the IP address and UDP port number of the MGW. The voice data from T-BSC is sent to BSC2without transparent transmission in the MGW because the destination IP address and UDP port number of the voice bearer path of T-BSC are the IP address and UDP port number of BSC2.

Step603: The T-BSC returns to the MSCe a Handoff Request Ack, which carries its own IP address and UDP port number.

Step604: The MSCe sends to S-BSC a Handoff Command to notify S-BSC of performing the hard handoff.

Step605: The MSCe sends to BSC2a Bearer Update Request, which contains the IP address and UDP port number of the T-BSC.

In this step, the MSCe requests BSC2to change the destination IP address and UDP port number of the voice bearer path of BSC2to the IP address and UDP port number of the T-BSC.

Step606: BSC2updates the voice bearer path between the calling MS and the called MS based on the request of the MSCe and returns a Bearer Update Response to the MSCe.

Step607: After receiving the Handoff Command from the MSCe, the S-BSC sends a Handoff Direction message to the MS to notify the MS of performing the hard handoff.

Step608: The MS returns an MS Ack Order message to the S-BSC in response to the Handoff Direction message.

Step609: The S-BSC sends to the MSCe a Handoff Commenced message, indicating that the hard handoff is ongoing.

Step610: After the MS is handed off to the T-BSC, the T-BSC sends a Handoff Complete message to the MSCe.

A voice bearer path between the calling MS and the called MS is set then up between the T-BSC and the BSC2.

Step611: The release procedure between the MSCe and S-BSC is performed and resources of S-BSC are released.

Step612: The call between the calling MS and the called MS continues.

Thereafter, the signaling flow of a voice call between the calling MS and the called MS in example 3 ends.

The handoff between the S-BSC and the T-BSC inFIG. 6follows the standard handoff flow. The difference lies mainly in step602, in which the IP address and UDP port number in the Handoff Request sent by the MSCe to the T-BSC are the IP address and UDP port number of BSC2instead of the IP address and UDP port number of the MGW. Another difference is that when the MSCe sends a Handoff Command to the S-BSC, it also sends to BSC2a Bearer Update Request, which carries the IP address and UDP port number of the T-BSC, to request BSC2to change the destination IP address and port number. In this way, a voice bearer path is set up between the calling BSC and the called BSC for the calling MS and the called MS. The transparent transmission in the MGW is avoided. Thus, the transmission delay is reduced and the load of the MGW is mitigated.

Although the invention has been described through some embodiments, the invention is not limited to such embodiments. It is apparent that those skilled in the art can make various modifications and variations to the invention without departing from the spirit and scope of the invention. The invention is intended to cover the modifications and variations provided that they fall in the scope of protection defined by the following claims or their equivalents. It is within the scope of the present invention to include all foreseeable equivalents to the elements and structure as described with reference toFIGS. 1-6.