WO2009039676A1

WO2009039676A1 - Method and system for implementing codec transition for voice service

Info

Publication number: WO2009039676A1
Application number: PCT/CN2007/002801
Authority: WO
Inventors: Yuezheng Zhao; Meng Zhao; Weiwen Gong
Original assignee: Lucent Technologies Inc.
Priority date: 2007-09-24
Filing date: 2007-09-24
Publication date: 2009-04-02
Also published as: CN101803451B; CN101803451A

Abstract

A method and system for implementing codec transition for voice service is provided. The method comprises setting up a traffic path on a channel in response to receiving a request for a first service, the channel having capability of handling at least a first codec for the first service; determining whether the channel supports the codec transition from the first codec to a second codec, in response to receiving a request for a second service via the traffic path; and responding to the request for the second service based on results of the determining step. The method and system realize the voice codec transition seamlessly without the hard handoff to switch the channel, so as to avoid the failure of channel allocation and to lower down the call dropped rate due to codec transition.

Description

METHOD AND SYSTEM FOR IMPLEMENTING CODEC TRANSITION

FOR VOICE SERVICE

FIELD OF THE INVENTION

The present invention generally relates to the field of codec transition and, more particularly, the invention relates to a method and system for implementing codec transition for voice service.

BACKGROUND OF THE INVENTION

"Voice Transparency service" provides voice security service for a special type of mobiles, such as, cell phone. Essentially after a normal traffic channel is set up between the calling and the called parties, for example, two subscribers will push a special button to inform their service provider to set up a new application upon the traffic channel with ISLP (Inter-System Link Protocol) codec. This will provide voice security between the two subscribers and once the two set switch to ISLP, nobody can "hear" them in CDMA (Code Division Multiplex Access) network.

Some telecom service providers have requested Voice Transparency service for their network, such as, CDMA network. The voice transparency feature provides end-to-end encrypted voice service. The voice transparency service may be activated from a regular EVRC (Enhanced Variable Rate Codec) voice conversation (for example, Service Option (SO): 0x0003) by switching the voice call to a new service option (for example, SO: OxδOaOh) - ISLP protocol. ISLP protocol carries encrypted voice on 64K carriers without corrupting the encrypted data. It can ensure MS (Mobile Station, i.e. cell phone) to parse the received encrypted data correctly.

The existing implementation to the service in CDMA network is to follow the traditional procedure of call setup and then to have a hard handoff to realize the call switch from one codec to another codec, for example, from EVRC codec to ISLP codec. Fig. 1 shows schematically a system 100 for realizing a hard handoff from EVRC to ISLP call. System 100 comprises a network element for controlling and switching, and a network element for providing interface between the mobile units and the network element for controlling and switching. In Fig. 1, the network element for controlling and switching is shown as MSC (Mobile Switch Center) 120, and the network element for providing interface between the mobile units and the network element for controlling and switching is shown as Cell site 110. The hard handoff from EVRC to ISLP call involves information exchanges between the MSC 120 and the Cell site 110, and corresponding functional configurations. MSC 120 comprises a call control module 121, an EVRC codec 122, an ISLP codec 123, and peripheral interfaces 124 and 125. By the peripheral interfaces 124 and 125, the codec in the MSC 120 is accessible. Cell site 110 may communicate with the MSC 120 through the call control module 121 via a signaling path 141, e.g., informing the MSC 120 to set up a call path or change codec. Via an EVRC traffic path 142 and an ISLP traffic path 143 respectively, the EVRC codec 122 and the ISLP codec 123 may receive information from the Cell site 110 through the peripheral interface 124 and send the processed information on 64K carriers 130 through the peripheral interface 125. The basic description of the traditional procedure of a call setup and then a hard handoff for implementing codec transition from EVRC codec to ISLP codec is as below.

Via the signaling path 141, the Cell site 110 informs the MSC 120 through the call control module 121 to set up a regular traffic path (i.e., voice path, which is the path to receive/transmit voice traffic data) on EVRC codec channel. After the traffic path is set up successfully, two subscribers can be at a talk state. In this way, the voice traffic data is encoded/decoded by the EVRC codec 122.

When two subscribers request a new application, for example by pushing a special button, the Cell site 110 is informed by air interface. If two subscribers select Voice Transparency service, then the Cell site 110 informs the MSC 120 via the signaling path 141 to set up another traffic path on ISLP codec channel for Voice Transparency service.

After performing successfully some operations related to codec transition, such as allocating channel resources and configuring functional modules, the MSC 120 will have a hard handoff to switch the traffic path (i.e. from the EVRC traffic path 142 to the ISLP traffic path 143) and release the EVRC traffic path 142.

When the codec transition is completed and the traffic path requested has been set up on ISLP codec channel, two subscribers can talk at such a traffic path to realize the voice transparency service.

In Fig. 1 , only the half call path is shown, the another half call is the same as it, which has the same call setup procedure to set up the traffic paths of EVRC codec and ISLP codec as described above.

There are several disadvantages of the above method for implementing codec transition, for example, it could be apt to failure to set up the traffic path on ISLP channel if there is no more resource of ISLP channel in MSC. In addition, hard handoff could contribute higher call dropped rate which can make service provider unhappy.

SUMMARY OF THE INVENTION

The objective of the present invention is to provide an improved method and system for realizing codec transition seamlessly without the hard handoff to switch the channel, so as to avoid the failure of channel allocation and to lower down the call dropped rate due to codec transition.

In one aspect of the present invention, there is provided a method for implementing codec transition for voice service. The method comprises setting up a traffic path on a channel in response to receiving a request for a first service, the channel having capability of handling at least a first codec for the first service; determining whether the channel supports the codec transition from the first codec to a second codec, in response to receiving a request for a second service via the traffic path; and responding to the request for the second service based on results of the determining step.

In another aspect of the present invention, there is provided a system for implementing codec transition for voice service. The system comprises a first network element and a second network element communicating with the first network element, wherein the second network element is configured to receive a request for a first service from the first network element, set up a traffic path on a channel having capability of handling at least a first codec for the first service, receive a request for a second service from the first network element via the traffic path, determine whether the channel supports the codec transition from the first codec to a second codec, and respond to the request for the second service based on the determination.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, further objectives, and advantages thereof, will be best understood by reference to the following detailed description of the preferred embodiments when read in conjunction with the accompanying drawings, wherein:

Fig. 1 shows schematically codec transition for voice service by a hard handoff in the prior art;

Fig. 2 shows schematically codec transition on the existing traffic path in accordance with an embodiment of the present invention; and

Fig. 3 depicts a message flow diagram which illustrates switching from EVRC to ISLP codec on the existing traffic path in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Fig. 1 shows schematically codec transition for voice service by a hard handoff in the prior art, which has been discussed above in connection with the background of the present invention. Reference will now be made in detail to the preferred embodiments of the invention.

Fig. 2 shows schematically codec transition on the existing traffic path in accordance with an embodiment of the present invention. Specifically, Fig. 2 illustrates a system 200 for realizing the codec transition from EVRC to ISLP call on the existing traffic path. As depicted, system 200 may comprise a network element for controlling and switching, and a network element for providing interface between the communication devices and the network element for controlling and switching. In an exemplary embodiment, the network element for controlling and switching can be MSC (Mobile Switch Center) 220, and the network element for providing interface between the communication devices and the network element for controlling and switching can be Cell site 210. MSC 220 may comprise a call control module 221, peripheral interfaces 224 and 225, and a combo codec having at least one codec mode, such as EVRC/ISLP combo codec 226. By the peripheral interfaces 224 and 225, the combo codec in the MSC 220 is accessible and the traffic data can be input/output. The combo codec may encode/decode traffic data in different codec modes, such as EVRC, 13K, 8K, EVRCB and ISLP, for voice service according to the requirement of subscribers.

Moreover, in the present invention, a kind of new channel with combo codec can be defined in MSC, which means the channel has capability of handling at least one codec. Thus, the traffic data encoded/decoded by the combo codec may be transmitted on this channel as long as the channel can handle the same type of codec as that of the codec mode adopted currently by the combo codec. As an example, a kind of new channel with combo EVRC/ISLP codec can be defined in the MSC 220, and the channel has capability of handling both EVRC and ISLP codec. In this case, without introducing EVRC traffic path and ISLP traffic path with respect to EVRC codec and ISLP codec respectively, as shown in Fig.2, via a traffic path 246 on this channel the combo EVRC/ISLP codec 226 may receive information from the Cell site 210 through the peripheral interface 224 and send the processed information on 64K carriers 230 through the peripheral interface 225.

In an exemplary embodiment according to the present invention, the procedure of a call setup and then the codec transition from EVRC to ISLP call on the existing traffic path is as below.

Via a signaling path 241, the Cell site 210 informs the MSC 220 (e.g. through the call control module 221) to set up a regular traffic path on the allocated channel. It is noted that the traffic path may be set up on the channel with or without combo codec, as long as the channel has capability of handling the codec for the service requested (i.e. EVRC codec in this example). After the traffic path 246 is set up successfully, two subscribers can be at a talk state, and the voice traffic data is encoded/decoded in EVRC mode by the combo codec 226 according to the requirement of two subscribers.

When two subscribers request a new service, for example by pushing a special button, the Cell site 210 is informed by air interface. In this example, two subscribers select Voice Transparency service, then the Cell site 210 informs the MSC 220 via service request message on current traffic path 246 (not signaling path 241, which differs from that in the prior art) to see if the call can be converted from EVRC codec to ISLP codec. The prototype of messages exchange between Cell Site and MSC will be further described in Fig.3.

If the channel can support such codec transition, that is, the channel has capability of handling ISLP codec, the Cell site 210 will receive a message from the MSC 220, which indicates that the codec transition is permitted, and then the Cell site 210 can inform MS to transmit/receive the ISLP traffic data on current traffic path 246 without switching to another traffic path.

If the channel can not support such codec transition, that is, the channel has no capability of handling ISLP codec, the Cell site 210 will receive a message from the MSC 220, which indicates that the codec transition is not permitted, and then the Cell site 210 can determine to keep the call on EVRC mode or to tear down the call in accordance with the requirement from service provider.

Reference is now made to Fig.3, which depicts the new prototype of messages exchange on the traffic path between MSC and Cell site for the codec transition in accordance with an embodiment of the present invention. More specifically, Fig.3 depicts a flow of information in the procedure of switching from EVRC to ISLP codec on the existing traffic path. The messages exchange on the existing traffic path between MSC and Cell site for codec transition can be performed in the context of the inventive system, such as the system 200 in Fig.2. Accordingly, the flow of information can include a MSC 220, a Cell site 210, and a communication device such as MS 350 (for the half call path).

The prerequisites for this information flow are that two subscribers have already had a normal EVRC voice call in talking 370. When codec transition is initiated, that is, subscribers request a new service other than current service, a special button of MS 350 may be pushed 371 to inform the service provider to set up a new application. Upon receiving a service request message 372 from the MS 350, the Cell site 210 sends a service request 373 to the MSC 220 via existing traffic path rather than signaling path. The SO in the service request 373 can indicate which kind of codec transition is requested, for example, SO=0x80a0 for a request to switch from EVRC to ISLP codec. In response to the request for a new service, the MSC 220 makes a determination as to whether the current channel supports the codec transition requested. The results of determination depend on whether the current channel has capability of handling the codec for the new service requested, which is ISLP codec in this example. If the current channel has capability of handling ISLP codec, then the following operations 374 of preparing for connecting the new service need to be done on the channel: stopping encoding/decoding of EVRC codec, releasing the resource of EVRC codec, and initializing ISLP codec such as allocating the resource of ISLP codec and getting ready for encoding/decoding with ISLP codec. After the above operations are performed successfully, a positive ACK of service request 375 is sent back to the Cell site 210 from the MSC 220, and then by a service connect message 376, the Cell site 210 can inform the MS 350 to transmit/receive the ISLP traffic data on current traffic path without switching to another traffic path. Then the service connect is completed 377 and two subscribers can have an ISLP voice call in talking 378.

If the current channel has no capability of handling ISLP codec, a negative ACK of service request is sent back to the Cell site 210 from the MSC 220 (not shown in Fig.3). In particular, the reasons which make a negative ACK of service request may be hardware failure on the channel with combo codec, failure of stopping encoding/decoding of EVRC codec, failure of releasing the resource of EVRC codec and failure of allocating the resource of ISLP codec, etc. In response to receiving a negative ACK of service request from the MSC 220, Cell site 210 can determine to keep the call on EVRC mode or to tear down the call in accordance with the requirement from service provider.

It can be seen from the above description that there is no call setup for a second traffic path any more in the procedure of codec transition under the present invention, which can save the network resource and avoid the failure of channel allocation if there is no more additional ISLP resource. The present invention also can save the signaling resource by transmitting service request massage via existing traffic path rather than signaling path. Moreover, it can realize the voice codec transition seamlessly without the hard handoff to switch the channel, and can lower down the call dropped rate.

The method of the present invention is not only applicable to codec transition from EVRC to ISLP for voice transparency service, but also to all any other kinds of codec transition among EVRC, 13K, 8K, EVRCB, etc. if service provider want it. An example is described herein to demonstrate codec transition from 13K to EVRC.

In an embodiment according to the present invention, some channels with combo EVRC/13K codec are defined in MSC. As an example, in the environment of CDMA network, MS may be dynamically requested to change the codec mode. Assuming that MS originates a 13K call which can provide better voice quality, via signaling path, Cell site informs MSC to set up a traffic path for this 13K call on the channel with at least 13K codec. Then two subscribers can be at a talk state, which is similar to the procedure shown in Fig.2, and the voice data is encoded/decoded by 13K codec. During a conversation, the MS may be informed to change codec from 13K to EVRC due to heavy call load or any other reason. When the Cell site is informed by air interface, it then informs the MSC via service request message on current traffic path (not signaling path any more) to see if the call can be converted from 13K codec to EVRC codec, which is similar to the procedure shown in Fig.3. If the channel can support the codec transition, the following things need to be done on the channel: stopping encoding/decoding of 13K codec, releasing the resource of 13K codec, allocating the resource of EVRC codec and getting ready for encoding/decoding with EVRC codec. After they are handled successfully, a positive ACK of service request is sent back to the Cell site, and then the Cell site can inform the MS to transmit/receive the EVRC traffic data on the current traffic path without switching to another traffic path. If the channel can not support the codec transition, a negative ACK of service request is sent back to the Cell cite, and then the Cell site can determine to keep the call on 13K mode or to tear down the call in accordance with the requirement from service provider.

After the successful codec transition, the reversed codec transition can happen at any time per request. In another embodiment according to the present invention, the reversed codec transition from EVRC to 13K during a conversation can be implemented by sending a service request for 13K call to MSC via the existing traffic path and determining that the current channel has capability of handling 13K codec. The detailed operational procedure is similar to that shown in Fig.2 and Fig.3, and the corresponding descriptions are not repeated here. Besides the codec transition between two types of codec, the present invention is also applicable to the codec transition among more than two types of codec, which depends on many factors, such as requirements of service provider, configurations of combo codec, hardware supports for combo channel and costs of implementation, etc. Moreover, the described features, structures, or characteristics of the invention may be combined in any suitable manner in one or more embodiments.

The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the claims appended hereto and their equivalents.

Claims

CLAIMSWhat is claimed is:

1. A method for implementing codec transition for voice service, the method comprising the steps of: setting up a traffic path on a channel in response to receiving a request for a first service, the channel having capability of handling at least a first codec for the first service; determining whether the channel supports the codec transition from the first codec to a second codec, in response to receiving a request for a second service via the traffic path; and responding to the request for the second service based on results of the determining step.

2. The method according to claim 1, wherein the step of setting up the traffic path on the channel comprises the steps of: receiving a request for the channel via a signaling path; allocating the channel for the first service; and using the first codec to encode and decode data of the first service on the traffic path.

3. The method according to claim 1, wherein the step of determining whether the channel supports the codec transition from the first codec to the second codec comprises the step of: checking whether the channel has capability of handling the second codec for the second service.

4. The method according to claim 3, wherein if the channel has capability of handling the second codec, the step of responding to the request for the second service further comprises the steps of: preparing for connecting the second service; and sending a positive ACK of the request for the second service.

5. The method according to claim 4, wherein the step of preparing for connecting the second service comprises performing on the channel the steps of: stopping encoding and decoding of the first codec; releasing resources of the first codec; allocating resources of the second codec; and getting ready for encoding and decoding with the second codec.

6. The method according to claim 5, wherein the step of responding to the request for the second service further comprises the steps of: connecting the second service on the channel after sending the positive ACK of the request for the second service; and using the second codec to encode and decode data of the second service on the traffic path.

7. The method according to claim 3, wherein if the channel has no capability of handling the second codec, the step of responding to the request for the second service comprises the steps of: sending a negative ACK of the request for the second service; and keeping encoding and decoding data of the first service on the traffic path by the first codec.

8. The method according to claim 3, wherein if the channel has no capability of handling the second codec, the step of responding to the request for the second service comprises the steps of: sending a negative ACK of the request for the second service; and tearing down the traffic path for the first service.

9. The method according to any one of claims 1 to 8, wherein the first codec provides regular voice service and the second codec provides voice security service.

10. The method according to claim 1, further comprising the steps of: receiving a new request for the first service via the traffic path; determining whether the channel supports the reversed codec transition from the second codec to the first codec; and responding to the new request for the first service based on results of the determining step.

1 1. The method according to claim 1 or 10, further comprising the steps of: receiving a request for a third service via the traffic path; determining whether the channel supports the codec transition from a current codec to a third codec for the third service; and responding to the request for the third service based on results of the determining step.

12. A system for implementing codec transition for voice service, the system comprising: a first network element; and a second network element communicating with the first network element, wherein the second network element is configured to receive a request for a first service from the first network element, set up a traffic path on a channel having capability of handling at least a first codec for the first service, receive a request for a second service from the first network element via the traffic path, determine whether the channel supports the codec transition from the first codec to a second codec, and respond to the request for the second service based on the determination.

13. The system according to claim 12, wherein the first network element is a cell cite, and the second network element is a mobile switch center.

14. The system according to claim 12, wherein the second network element further comprises: a call control module, wherein the call control module is configured to receive a request for the channel from the first network element via a signaling path, and allocate the channel for the first service; and a combo codec having at least a first codec mode, wherein the combo codec is configured to use the first codec to encode and decode data of the first service on the traffic path.

15. The system according to claim 12, wherein the second network element is further configured to check whether the channel has capability of handling the second codec for the second service.

16. The system according to claim 15, wherein if the channel has capability of handling the second codec, the second network element is further configured to: prepare for connecting the second service; and send a positive ACK of the request for the second service to the first network element.

17. The system according to claim 16, wherein the combo codec is further configured to perform on the channel the operations of: stopping encoding and decoding of the first codec; releasing resources of the first codec; allocating resources of the second codec; and getting ready for encoding and decoding with the second codec.

18. The system according to claim 17, wherein the second network element is further configured to connect the second service on the channel after sending the positive ACK of the request for the second service, and the combo codec is further configured to use the second codec to encode and decode data of the second service on the traffic path.

19. The system according to claim 15, wherein if the channel has no capability of handling the second codec, the second network element is further configured to send a negative ACK of the request for the second service to the first network element, and the first network element is configured to keep the first service on the traffic path.

20. The system according to claim 15, wherein if the channel has no capability of handling the second codec, the second network element is further configured to send a negative ACK of the request for the second service to the first network element, and the first network element is configured to tear down the traffic path for the first service.

21. The system according to any one of claims 12 to 20, wherein the first codec provides regular voice service and the second codec provides voice security service.

22. The system according to claim 12, the second network element is further configured to: receive a new request for the first service from the first network element via the traffic path; determine whether the channel supports the reversed codec transition from the second codec to the first codec; and respond to the new request for the first service based on results of the determination.

23. The system according to claim 12 or 22, the second network element is further configured to: receive a request for a third service from the first network element via the traffic path; determine whether the channel supports the codec transition from a current codec to a third codec for the third service; and respond to the request for the third service based on results of the determination.