method for codec negotiatio

8/9/2019 Method for Codec Negotiatio..

1/19

Inventors list Agents list Assign

Classification tree browser Top 100 Inventors Top

Usenet FAQ Index Documents

Patent application title: METHOD FOR CODECNEGOTIATION AND SELECTION

Inventors: Karl Hellwig Dirk Kampmann

Henning Buhr

Agents: ERICSSON INC.Assignees:

Origin: PLANO, TX US

IPC8 Class: AH04M342FI

USPC Class: 4554141

Ads by Google

Dual SIM Card Adapter- Keep 2 SIM cards in a Phone. GSM/3G Saveroaming charges. Agent wanted. - www.DuoSIM.com

GSM Tutorial - Learn About GSM Technology Radio, Network, andOperation - www.Althos.com

GPS GSM & AMPS Antennas - GPS antennas with gsm, amps, gprs

available. Starting at $22/unit oem - www.mightygps.com

Abstract:

A method of modifying a call setup message for a call from a firstterminal to a second terminal, the call setup message being sent from thefirst terminal to a network node via an intermediate node which handlesat least some signaling or traffic associated with the call, wherein thenetwork node is responsible for negotiating call setup requirements forthe call to the second terminal, the method comprising the steps of:intercepting the call setup message at the intermediate node; identifying

one or more preferences or capabilities associated with the intermediatenode which may impact the way in which the intermediate node can

s by Google

gotiation Skills

courage better success byproving your negotiation skills

ww.NextLevelPurchasing.com

SM Gateway

od solutions using GSM GatewayT, VOIP, PRI AND SIM Server

ww.eurotech-communication.com

ofessional GSM Gateway

SM gateway 4-72 ports & 1-288 SIMpports: ISDN E1/T1 BRI PRI & VoIP

ww.hyperms.com/gsm-gateway

dio Planning ToolsDTM is automatically generated to


2/19

handle signaling or traffic associated with the call; modifying the callsetup message based on information relating to said preferences orcapabilities; and sending the modified call setup message to the networknode, in order that the node can effect said negotiations based on themodified message.

Claims:

1. A method of modifying a call setup message for a call from a firstterminal to a second terminal, the call setup message being sent from thefirst terminal to a network node via an intermediate node which handles

signaling or traffic associated with the call, wherein the network node isresponsible for negotiating call setup requirements for the call to thesecond terminal, the method comprising the steps of:intercepting the callsetup message at the intermediate node;identifying one or morepreferences or capabilities associated with the intermediate node whichmay impact the way in which the intermediate node can handle signalingor traffic associated with the call;modifying the call setup message basedon information relating to said preferences or capabilities; andsending themodified call setup message to the network node, so that the networknode can effect negotiations based on the modified call setup message.

2. The method of claim 1, wherein the step of modifying the call setupmessage comprises adding an appendix to the call setup messageincluding said one or more preferences or capabilities.

3. The method of claim 1, wherein the step of modifying the call setup

message comprises deleting content in the call setup message inaccordance with said one or more preferences or capabilities.

4. The method of claim 1, wherein the step of modifying the call setupmessage comprises adding content in the call setup message inaccordance with said one or more preferences or capabilities.

5. The method of claim 1, wherein the step of modifying the call setupmessage comprises ordering content in the call setup message inaccordance with said one or more preferences or capabilities.

6. The method of claim 1, wherein the step of modifying the call setup

message comprises inserting one or more separators in the call setupmessage to indicate which content in the message is in accordance withsaid one or more preferences or capabilities.

7. The method of claim 1, wherein the step of intercepting the call setupmessage comprises intercepting a message associated with Codec

types supported by the first terminal.

8. The method of claim 7, wherein the step of modifying the call setupmessage comprises modifying the call setup message to includeinformation relating to the Codec types supported by the intermediatenode, the intermediate node being an originating BSC.

9. The method of claim 1, further comprising effecting the call in atranscoding free manner based on said one or more preferences orcapabilities.

10. The method of claim 1, further comprising modifying a call setup

message in a GSM and Edge Radio Network (GERAN).

culate in any part of the worldww.radiatio.com

7/C7 Signaling Solution

7/C7 Signaling Interop ExpertsW2200 International Deployments

ww.pgw2200.com


3/19

11. The method of claim 1, further comprising modifying a call setupmessage in a UMTS terrestrial radio access node (UTRAN) network.

12. A module, in an intermediate node in a network, for modifying a callsetup message for a call from a first terminal to a second terminal, thecall setup message being sent from the first terminal to a network nodevia said intermediate node, which handles signaling or traffic associatedwith the call, wherein the network node is responsible for negotiating callsetup requirements for the call to the second terminal, the modulecomprising:a receiver for receiving the call setup message at theintermediate node prior to the network node commencing negotiations for

call setup requirements;a processor module for identifying one or morepreferences or capabilities associated with the intermediate node whichmay impact the way in which the intermediate node can handle signalingor traffic associated with the call and modifying the call setup messagebased on information relating to said preferences or capabilities; andatransmitter for sending the modified call setup message to the networknode, so that the node can effect said negotiations based on themodified call setup message.

13. The module of claim 12, wherein the call setup message is modified

based on one or more of a list comprising:adding an appendix to the callsetup message including said one or more preferences orcapabilities;deleting content in the call setup message in accordance withsaid one or more preferences or capabilities;adding content in the callsetup message in accordance with said one or more preferences orcapabilities;ordering content in the call setup message in accordance withsaid one or more preferences or capabilities; andinserting a separator inthe call setup message to indicate which content in the message is inaccordance with said one or more preferences or capabilities.

14. The module of claim 12, wherein the call setup message comprises amessage associated with Codec types supported by the first terminal.

15. The module of claim 14, wherein modification in the call setupmessage includes information relating to the Codec types supported bythe intermediate node.

16. The module of claim 12, wherein the intermediate node is one of anoriginating BSC or a terminating BSC.).

17. The module of claim 12, wherein the module is in communication with

at least one of said first or second terminals.

18. A module, in a network operating in a transcoding manner or a

transcoding free manner, for modifying a call setup message for a callfrom a first terminal to a second terminal, the call setup message beingsent from the first terminal to a network node via said intermediate node,which handles at least some signaling or traffic associated with the call,wherein the network node is responsible for negotiating call setuprequirements for the call to the second terminal, the module comprising:areceiver for receiving the call setup message at the intermediate nodeprior to the network node (MSC-S) commencing negotiations for callsetup requirements;a processor module for identifying one or morepreferences or capabilities associated with the intermediate node whichmay impact the way in which the intermediate node can handle signalingor traffic associated with the call and modifying the call setup message

based on information relating to said preferences or capabilities; andatransmitter for sending the modified call setup message to the network


4/19

node, so that the node can effect said negotiations based on themodified message.

19. The module of claim 18, wherein the call setup message is modifiedbased on one or more of a list comprising:adding an appendix(tBSC-SCL) to the call setup message including said one or morepreferences or capabilities;deleting content in the call setup message inaccordance with said one or more preferences or capabilities;addingcontent in the call setup message in accordance with said one or morepreferences or capabilities;ordering content in the call setup message inaccordance with said one or more preferences or capabilities;

andinserting a separator in the call setup message to indicate whichcontent in the message is in accordance with said one or morepreferences or capabilities.

20. The module of claim 19, the appendix is a tBSC-SCL, or content isdeleted from, added to, or ordered in the tMS-SCL, or the separator isinserted into the tBSC-SCL or tMS-SCL

21. The module of claim 18, wherein the call setup message comprises a

message associated with Codec types supported by the secondterminal.

22. The module of claim 21, wherein modification in the call setupmessage includes information relating to the Codec types supported bythe intermediate node.

23. The module of claim 18, wherein the intermediate node is a BaseStation Controller (BSC).

24. The module of claim 18, wherein the module is in communication withat least one of said first or second terminals.

25. The module of claim 19, wherein the intermediate node is one of an

originating BSC or a terminating BSC

Description:

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001]This application claims the benefit of U.S. Provisional Application

No. 60/955,696 filed Aug. 14, 2007, the disclosure of which isincorporated herein by reference.

BACKGROUND OF THE INVENTION

[0002]The present invention relates to improvements in or relating to

Codec negotiation and selection, particularly but not exclusively in a radioaccess network.

[0003]For both, Tandem Free Operation (TFO) and Transcoder FreeOperation (TrFO) by using Out-of-Band Transcoder Control (OoBTC),there is a continual effort to avoid speech quality impairment caused byunnecessary transcoding steps along the speech path. In order toachieve this both technologies rely on an exchange of lists of Codectypes to be used on each sub-link of the speech path. Tandem Free

Operation (TFO) is an in-band procedure used to pass compressedspeech through a pulse code modulation (PCM) connection. TFO is


5/19

applied after call setup and includes the exchange of Codec informationbetween TFO-peers using an in-band protocol. The optimal commonCodec is determined according to a predetermined set of rules by bothpeer nodes. Out-of-Band Transcoder Control (OoBTC) is a procedurebetween call control nodes (CCN), where a Codec is negotiated using anout-of-band protocol. This is applied before or at call setup and theselection of the optimal Codec is made by the terminating node. Thereare no fixed or predetermined selection rules.

[0004]In the call setup procedure of a call originating from a GSM mobile(also called the Mobile station (MS) or the GSM terminal) the Mobile

Switching Center (MSC) server (MSC-S) at the originating side of the callreceives information about the terminal supported Codec types of theMS. This information is sent from the MS to the MSC within a directtransfer application part (DTAP) message during the early call setupsignaling. This message passes physically through the base stationcontroller (BSC), although the BSC is not functionally involved in thecommunication. The originating MSC-S then performs Codec negotiationwith the peer terminating MSC-S in order to determine an appropriateCodec to be used in the core network. This is generally referred to asthe OoBTC procedure and generates the selected Codec (SC). Theterminating MSC-S selects the SC, determines an available Codec list(ACL) and sends these (SC and ACL) back in a message to theoriginating MSC-S. The originating MSC-S then builds a list of possiblespeech Codec versions in the form of a speech Codec version list(SCVL) which is ordered in accordance with the originating MSC-Spreferences. If any of the speech Codec versions are identical orcompatible with the SC used in the core network, these are preferredover other Codec versions. This is due to the fact that this allows TFOoperation on the GSM signal interface between the BSC and the MSC(A-Interface). The originating MSC-S then enables TFO in a mediaGateway (MGW) node that connects to the A-interface. The originatingMSC-S also requests channel assignment from the originating BSC sothat the BSC can seize the radio bearer. The request includes the SCVL

of possible Codec types. At the same time the originating BSC choosesan appropriate Codec type from the list and the core network bearer isseized using the negotiated Codec type (SC). The MSC-S may benotified that the bearer setup procedure has been performedsuccessfully. A first transcoding unit within the originating base stationsystem (BSS) and a second transcoder unit within the originating MGWperform the TFO negotiation. If the Selected Codec used in the corenetwork and the Codec chosen by the originating BSC are compatiblethen TFO becomes operational and transcoding free operation isachieved at least on the originating side of the call. A complementaryseries of actions is performed by the terminating MSC, MGW, BSC andMS and if the Selected Codec used in the core network and the Codec

chosen by the terminating BSC are compatible, then TFO becomesoperational and transcoding free operation also on the terminating side ofthe call is achieved. If TFO becomes operational on both sides thenend-to-end transcoding free operation is achieved, which is the ultimategoal.

[0005]If the call setup originates or terminates from different types ofradio access network, there are variations of the above describedprocess which may apply. However, there are a number of problemswhich exist with the above described process. Thestandardized/specified procedure for call setup requires the originating

MSC-S to perform Codec negotiations within the core network prior tocommunicating an assignment message with the originating BSC. This


6/19

assignment message is used to request the seizure of the relevant radiochannel and can provide a preferred speech version list (PSVL) defininga set of speech Codecs that can be used for the call. Within the list thefirst Codec is generally the most preferred. The BSC is now free toselect any speech Codec from this PSVL. The BSC decision occurs afterthe Codec is selected in the core network and based on the fact that theBSC does not know about the Codec negotiations or any end-to-endproblems in the network. Accordingly, the BSC decision is based simplyon a local view. This often results in the situation that the BSC isselecting a Codec that is not compatible with the Codec selected in thecore network or in any other (terminating) BSC along the path of the call.

[0006]Alternatively, the BSC may select the Codec that is preferred bythe MSC-S, but not one that supports TFO or transcoding free operation(TrFO). As a consequence TFO cannot be achieved on the A-interface(in general: on the interface between Core Network and Radio AccessNetwork) and transcoding has to be performed which has negativeimpact on the speech quality of the call and/or increases the costs ofMedia Gateway resources.

[0007]There are a number of possible reasons why the BSC selects aCodec that is incompatible with the core network (i.e. does not select thefirst element in the received PSVL), these include:

[0008]The transcoding resources for the first Codec are not currently

available to the BSC. [0009]The transcoding resources are available butTFO support is not available. [0010]Due to temporarily or locally limitedradio channel capacity the BSC may select a half rate channel instead ofa preferred full rate channel.

[0011]It is possible to correct for incompatibility and failed TFO setupthrough a change of the selected Codec in the core network. This can beachieved by means of an OoBTC mid-call modification or negotiationprocedure. However, this brings about the following disadvantages:

[0012]Changing the Selected Codec in the core network cannot occurwithout negative impact on the speech connection thereby reducing theoverall speech quality of the call. [0013]Any change of the SelectedCodec in the core network may trigger a change of the Codec used inthe radio access on the other side of the call. In addition the other side ofthe call has the freedom to reject the new Selected Codec and as suchthe attempt to change the Selected Codec may completely fail.[0014]Any change of the Selected Codec in the core network may leadto a mismatch towards the Codecs used in the radio access on the otherside of the call, thereby reducing speech quality of the call. [0015]Any

change in the Selected Codec in the core network requires additional

signaling and therefore additional network resources. [0016]An OoBTCmid-call modification or negotiation procedure can be rejected by theterminating side resulting in unnecessary use of signaling resources.[0017]An OoBTC mid-call modification or negotiation procedure may failcompletely in mixed vendor or mixed configurations environments.

BRIEF SUMMARY OF THE INVENTION

[0018]One object of the present invention is to provide a method andapparatus for selecting and negotiating the Codec type in a radio accessnetwork, which overcomes at least some of the problems associated

with the prior art.

[0019]Another object of the present invention is to provide a method and


7/19

apparatus for improved coordination of Codec negotiation between thecore network and the radio access network.

[0020]A still further object of the present invention is to provide a methodand apparatus for improving TFO and TrFO operation in a combinedradio access and Core network.

[0021]The present invention provides a method and system as describedin the accompanying claims.

[0022]In accordance with one aspect of the present invention, there is

provided a method of modifying a call setup message for a call from afirst (originating) terminal to a second (terminating) terminal, the callsetup message being sent from the first terminal to a network node viaan intermediate node (e.g. originating BSC) and further on to a secondintermediate node (e.g. the terminating BSC) which handles at leastsome signaling or traffic associated with the call, wherein the secondintermediate network node is responsible for negotiating call setuprequirements for the call to the second terminal, the method comprisingthe steps of: intercepting the call setup message at the intermediatenode; identifying one or more preferences or capabilities associated withthe intermediate node which may impact the way in which theintermediate node can handle signaling or traffic associated with the call;modifying the call setup message based on information relating to saidpreferences or capabilities; and sending the modified call setup messageto the network node, in order that the node can effect said negotiationsbased on the modified message.

[0023]According to a second aspect of the present invention there isprovided a module in an intermediate node in a network for modifying acall setup message for a call from a first terminal to a second terminal,the call setup message being sent from the first terminal to a networknode via said intermediate node, which handles at least some signaling ortraffic associated with the call, wherein the network node is responsible

for negotiating call setup requirements for the call to the second terminal,the module comprising: a receiver for receiving the call setup message atthe intermediate node prior to the network node commencingnegotiations for call setup requirements; a processor module foridentifying one or more preferences or capabilities associated with theintermediate node which may impact the way in which the intermediatenode can handle signaling or traffic associated with the call and modifyingthe call setup message based on information relating to said preferencesor capabilities and a transmitter for sending the modified call setupmessage to the network node, in order that the node can effect saidnegotiations based on the modified message.

[0024]In an embodiment of the invention, the step of modifying the callsetup message comprises adding an appendix to the call setup messageincluding said one or more preferences or capabilities.

[0025]In an embodiment of the invention, the step of modifying the callsetup message comprises deleting content in the call setup message inaccordance with said one or more preferences or capabilities.

[0026]In an embodiment of the invention, wherein the step of modifying

the call setup message comprises adding content in the call setupmessage in accordance with said one or more preferences or

capabilities.


8/19

[0027]In an embodiment of the invention, the step of modifying the callsetup message comprises ordering content in the call setup message inaccordance with said one or more preferences or capabilities.

[0028]In an embodiment of the invention, the step of modifying the callsetup message comprises inserting one or more separators in the callsetup message to indicate which content in the message is in accordancewith said one or more preferences or capabilities.

[0029]In an embodiment of the invention, the step of intercepting the call

setup message comprises intercepting a message associated with

Codec types supported by the first terminal.

[0030]In an embodiment of the invention, the step of modifying the callsetup message comprises modifying the call setup message to includeinformation relating to the Codec types supported by the intermediatenode.

[0031]In an embodiment of the invention this may be computerimplemented.

[0032]There are a number of advantages provided by the various

aspects of the present invention. Irrespective of the particularembodiment of the invention, the present invention provides a dynamicmeans by which an originating MSC can be appraised of resources andcapabilities in respect of the base station or base station controller (BSC)or any other element in the network that impact the ability of the MSC toefficiently negotiate Codecs with other network elements. This isimportant in ensuring the efficient operation of the network and preventsover provisioning and the consequential cost implications as well asspeech quality degradation.

[0033]Coordinating the selection of the relevant Codec at or before call

setup ensures that any unusual local occurrences will be taken into

consideration: for example, short-term peak load problems, poolshortages, geographical restrictions etc. . . . The improved coordinationin Codec selection between the radio network and the core networkimproves the amount of speech calls where speech quality is optimizedand media gateway resources are minimized. Also unnecessary andexpensive OoBTC mid-call procedures are avoided when the Codectypes cannot be matched. In addition, by adding SIP or SDP parametersthe negotiation of Codec configuration and packaging can be establishedat an early point in the process. The invention leads to substantiallyimproved end-to-end Codec selection and is an important step inremoving transcoding from GERAN and transferring it to the mediaGateway.

[0034]As previously indicated, in the prior art the DTAP message passesthrough the BSC but the BSC is not functionally involved in anyprocessing of this message. The message is essentially obscured fromthe BSC. On the other hand the present invention makes the DTAPmessage available and visible to the BSC. In this way the BSC caninfluence the subsequent negotiation of the Codecs by the MSC-S.

BRIEF DESCRIPTION OF THE DRAWINGS

[0035]Reference will now be made, by way of example, to theaccompanying drawings, in which:


9/19


10/19

informs the MSC-S will now be described in greater detail.

[0043]The information relating to which Codecs are supported by theGSM terminal is sent to the MSC-S during call setup in any of thefollowing messages at the originating side: setup, emergency setup andat the terminating side: call confirmed. There are a number ofstandardized manners in which this can be effected, for example theSpeech version list (SVL) or the mobile station's Codec list (CL), but forsimplicity all are referred to herein as the mobile station's supportedCodec list (MS-SCL). This SVL is generally ordered in accordance withthe preferences of the GSM terminal. The CL has no preference order

and is an unordered bit map.

[0044]In an embodiment of the present invention the BSC is capable ofmodifying the Codec information in the MS-SCL even before informationarrives at the MSC-S. The BSC can re-order the MS-SCL list accordingto TFO capabilities and preferences and also according to resourceavailability. The BSC is not forbidden to read the messages from theGSM terminal nor is it forbidden for the BSC to modify them inaccordance with the relevant technology standards or specifications.Once the BSC has modified the Codec information in the MS-SCL themodified message can then be used by the MSC to improve thesubsequent OoBTC Codec negotiation procedure as is described ingreater detail below.

[0045]There are a number of different alternatives on how the BSC can

indicate preferences or restrictions in the speech Codec selection. In anumber of alternatives this can be accomplished by modifying or updatingthe MS-SCL message.

[0046]The BSC may delete a Codec from the MS-SCL based on its ownpreferences and capabilities, whilst essentially ignoring the preferencesgiven by the GSM terminal. This method will work even when only theBSC has been upgraded in accordance with the present invention. It is

not necessary to upgrade the MSC in order for this embodiment of thepresent invention to have a number of advantages. If the GSM terminalindicates a GSM full rate version 1, as is mandatory, this may not beincluded in the MS-SCL from the GSM terminal. In this case the MSC if itwere not upgraded would automatically assume it is still mandatory and itwould be necessary to use an alternative embodiment as indicated belowin order for the BSC to modify the list if this full rate version 1 is notavailable for the BSC.

[0047]In order to separate the BSC supported Codec types from thosethat are not supported by the BSC, lack TFO functionality or for anyother reason are currently not allowed, the BSC may include the GSM fullrate version 1 as a separator in the MS-SCL. Any Codecs listed belowthe separator would be marked as not supported by the BSC, the TFOor currently not be allowed for whatever reason.

[0048]Similarly the BSC may use a GSM speech half rate version 2 asanother separator between the Codecs that are supported and notsupported by the BSC, TFO or not allowed for any other reason. TheGSM speech half rate version 2 is not utilized in the 3GPP specificationand as such would serve well as a separator. In addition, since theseparator is not currently defined or used in the 3GPP specification itcould also serve as an indicator for the MSC-S that the MS-SCL has

been modified by the BSC in accordance with the present invention. It ispossible that several different separators can be used in the list of


11/19

Codecs supported by the BSC to indicate different capabilities. Forexample, a different separator to indicate Codecs which support:[0049]a. Transcoding to PCM; [0050]b. Transcoding to PCM plus TFO;[0051]c. No transcoding.

[0052]In a further embodiment of the present invention the BSC may

receive the MS-SCL from the GSM terminal only in form of the unorderedCL and may then insert a speech version list (SVL) to indicate the BSCpreferences and capabilities. The BSC may re-set entries in the CL whichrelate to Codecs that are either not BCS-supported, TFO-supported orfor any other reason are currently not allowed. In order to indicate which

entries in the GSM terminal MS-SCL list are supported by the BSC theBSC many introduced a separator (for example GSM speech full rateversion 1 or GSM speech half rate version 2 as indicated above) in theadded SVL. As above, the separator indicates that any Codecs listedbelow the separator are not supported by the BSC, TFO or disallowedfor any other reason.

[0053]In a further advantageous embodiment of the present invention theBSC may add an appendix to the MS-SCL and then transmit the originalunmodified MS-SCL and the appendix to the MSC. The appendixcontains the currently supported BSC Codecs (BSC-SCL) listed in apriority order and may including a separator for example, as previouslymentioned above. A third separator in the BSC-SCL may be the G.711Codec (aLaw or uLaw), in short herein called "PCM". PCM in theBSC-SCL has the advantage that in can be used to indicate that PCM issupported on the A-interface, i.e. that the BSC supports transcoding toPCM. This ensures that the MSC receives dynamic and locally importantBSC capabilities and preferences as early as possible thereby allowingthe BSC to influence subsequent Codec negotiation. The process in theBSC is relatively simple because it does not need to analyze theindividual messages received from the GSM terminal. Since differenttypes of messages may be received from different GSM terminal theremay be a number of different schemes by which the BSC adds and

indicates the appendix. The BSC can prepare the appendix BSC-SCL inadvance of receipt of a message from the GSM terminal. This may be inpart or in total as at the time of receipt of the MS-SCL the preparedappendix may not longer be relevant due to changes relating to time,location, cell load etc. and may require an update. However, as theappendix is prepared in advance this embodiment has the advantage thatit will speed up the process of adding the appendix to the MS-SCL. Theexistence of the appendix is an indication that the MS-SCL has beenupdated and the BSC is an upgraded BSC capable of carrying out thepresent invention.

[0054]In a still advantageous embodiment of the present invention theBSC adds an appendix to the MS-SCL as it is transmitted from the GSMterminal to the MSC. The appendix is built and structured as defined forthe OoBTC process and the 3GPP technical specifications 23.153 and26.103. This means that the BSC Codecs are listed in order of priorityfor the BSC and each Codec is defined with all parameters necessary forthe OoBTC process between originating MSC and terminating MSC. Thisembodiment has a number of advantages including the fact that the BSCcan communicate with the MSC directly and dynamically and includes allinformation that the MSC will require to carry out the OoBTC process,not just the Codec type, but also the Codec Configuration or even therange of Codec Configurations the BSC supports.

[0055]In an alternative embodiment the BSC adds an appendix to the


12/19

MS-SCL as indicated above. However, the appendix is built andstructured as defined for a session initiation protocol (SIP) as sessiondescription parameter (SDP). The appendix includes the BSC supportedCodecs listed in priority order along with all additional parameters inSIP/SDP as may be required for ongoing processing; for example,packetisation time etc.

[0056]As can be seen from the embodiment there are many differentways in which the BSC can indicate to the MSC preferences andcapabilities of the BSC exactly at the time of call setup. An importantelement of the present invention is that this is BSC capability and

preference is indicated before the MSC starts any Codec negotiation andselection processes. In similar ways as described above the BSC maysend the BSC-SCL also later during the call, e.g. for handover purposes.

[0057]In the embodiments presented above the BSC generally modifiesthe MS-SCL message in order to indicate the Codec preferences andcapabilities of the BSC. However, it will be appreciated that othermessages may be amended in order to communicate this information.For example the BSC-SCL message may be included in a layer 3container message. The BSC Codec preferences and capabilities couldbe inserted into any relevant message in the layer 3 container messageor in fact in any other appropriate message which passes through theBSC from the GSM terminal to the MSC or which is send directly fromthe BSC to the MSC.

[0058]FIG. 3 shows an example of an appendix in accordance with an

embodiment of the present invention. This example describes how onearbitrary Codec list can be coded and sent between the originating andterminating MSCs in the OoBTC process. The example list includes 4Codecs in a priority order:--UMTS_AMR; FR_AMR; HR_AMR;GSM_EFR.

[0059]Once the BSC Codec preferences and capabilities are indicated to

the MSC the call setup process continues as follows and with referenceto FIG. 1. The MSC-S goes on to start Codec negotiations by building asupported Codec list (SCL) 114 which is transmitted to the peerterminating MSC-S (not shown) for the call in a message 116. Theterminating MSC-S (tMSC-S) contacts the terminating BSC (tBSC) andthe terminating MS (tMS) sends a tMS-SCL and potentially a tBSC-SCLreturn message is added by the tBSC in a similar manner to thatdescribed with respect to the originating side. The tMSC-S determinesthe most suitable Codec for the terminating RAN, considering thereceived SCL, the TFO options on the terminating side, the tMS-SCL andthe tBSC-SCL. The tMSC-S then also selects the SC taking allinformation into account. The tMSC-S also determines the commonavailable Codec list (ACL). An alternative embodiment is: The tMSC-Sdetermines the most suitable Codec SC for the core network,considering the received SCL, the TFO options on the terminating side,the tMS-SCL and the tBSC-SCL. The tMSC-S also determines thecommon available Codec list (ACL). The tMSC-S then also selects themost suitable Codec for the terminating RAN, taking the SC, the TFOoptions on the terminating side, the tMS-SCL and the tBSC-SCL intoaccount.

[0060]Both (SC and ACL) are communicated in an APM (Applicationtransport Mechanism) 118, from the terminating MSC-S back to the

originating MSC-S. The originating MSC-S then evaluates the TFOoptions at the originating side and compares the SC with the speech


13/19

versions supported by the GSM terminal 100 (oMS-SCL) and the BSC108 (120) (oBSC-SCL). The originating MSC-S determines the mostsuitable Codec for the originating RAN. The originating MSC-S sends thedetermined RAN Codec to the MGW and enables TFO in media gatewaynode as shown by arrow 122. The originating MSC-S requests channelassignment from the originating BSC, including the Speech CodecVersion List (SCVL) of possible Codec type for the BSC that can beused to seize the radio bearer. This includes channel type informationand is shown by arrow 124. The SCVL is in priority order of the MSC-Sand includes the determined RAN Codec at the top of the list, as themost preferred. The BSC then chooses an appropriate Codec type from

the received SCVL list. Generally this is the first and most preferredCodec on the list and due to the fact that the BSC has already indicatedpreferences and capabilities earlier to the MSC-S the BSC will now beable to support the preferred Codec on the list. This maximizes thelikelihood that TFO will establish between the BSC and the MGW. At thesame time the MSC instructs the media gateway to seize the bearer forthe core network using the negotiated Selected Codec type (SC) arrows126 and 128. The next MSC-S in the chain may be notified that thebearer setting procedure has successfully been performed. An attempt toestablish TFO operation is then carried out by the BSS and a connectionis made by the MSC via an APM connect message, both are shown asarrows 130.

[0061]This enables the BSS to optimize radio resources dynamicallybased on load and also allows a high success rate for TFO for each call.This avoids the need for unnecessary over provisioning and very highcosts associated with additional signaling.

[0062]If an embodiment operates with existing MSC-S's, i.e. the oneswhich do not recognize the appended BSC-SCL, it is possible that theMSC-S will not recognize some or all of the changes implemented by theBSC and so the MSC-S could still offer Codecs in the SCL that the BSCdoes not support. This could be improved if the BSC deletes all Codecs

that it cannot support from the MS-SCL (as described above). In thisway the MSC receives the list that only includes Codecs that can besupported by the BSC and only uses this for the subsequent OoBTCnegotiation procedure. In this way it is possible to operate the presentinvention with a modified and upgraded BSC, but maintaining apresent-day MSC-S. It may be possible, in certain situations, to upgradethe BSC by means of a hand-administration process.

[0063]The above described techniques relate to a call setup originating

and terminating in a GSM and EDGE radio access network (GERAN),which supports transcoding of the RAN Codec to PCM, with or withoutTFO for some or all of these Codecs. The above described techniquesare even more important once the transcoders are moved out of GERANand into the Core Network.

[0064]The above described techniques relate to a call setup originatingand terminating in a GSM and EDGE radio access network (GERAN)although it may equally apply to other types of radio access network(RAN). For example a UMTS terrestrial radio access node (UTRAN)implementation, a WLAN implementation, a WiMAX implementation orany other wireless or wireline access methods for example DSL.

[0065]At present the problems with an UTRAN implementation are less

severe as typically only one Codec type and configuration are used.However, it is likely in the future that UTRAN will have many more speech


14/19

Codecs and options and that the radio network controller (RNC) will atsome time in the future need the ability to indicate preferences as is thecase with the BSC. The present invention provides this capability and theRNC will be able to communicate in the same way as the BSC to expresslocal, temporal or any other kind of preference in respect of Codec orany other option.

[0066]Another example of this is the standardization/specification ofSIP-I for OoBTC in core networks, which will benefit from the presentinvention as well.

[0067]The present invention is also beneficial in the recently defined IMSarchitecture.

[0068]Irrespective of the particular embodiment of the invention, the

present invention provides a dynamic means by which an originating MSCcan be appraised of resources and capabilities in respect of the basestation or base station controller (BSC) or any other element in thenetwork (e.g. MGW) that impact the ability of the MSC to efficientlynegotiate Codecs with other network elements. This is important inensuring the efficient operation of the network and prevents overprovisioning and the consequential cost implications.

[0069]It should be noted that the functions of the invention may becarried out in different network elements than those described herein.For example, in the future some of the transcoding may be shifted to theCore Network and carried out in the media gateway in the future. Thepresent invention could be adapted to accommodate this. The BSC-SCLwill then indicate to the MSC-S which Codecs are supported by the BSCa) with transcoding to PCM, or b) with transcoding to PCM plus TFO orc) without transcoding. In the latter case the MSC-S may select thisCodec only if the selected MGW has sufficient transcoding capability forthis Codec.

[0070]Coordinating the selection of the relevant Codec at or before callsetup ensures that any unusual local occurrences will be taken intoconsideration: for example, for short-term peak load problems, poolshortages or geographical restrictions. The improved coordination inCodec selection between the BSC and the MSC inside the core networkimproves the amount of speech calls where speech quality is optimizedand media gateway resources are minimized. Also unnecessary andexpensive OoBTC mid-call procedures are avoided when the Codectypes in GERAN and Core Network (CN) cannot be matched.

[0071]In addition, by adding SIP or SDP parameters the negotiation ofCodec configuration and packaging can be established at an early pointin the process. The invention leads to substantially improved end-to-endCodec selection and is an important step in removing transcoding fromGERAN and transferring it to the media Gateway.

[0072]Referring now to FIG. 4, a block diagram of an intermediate node

in the network (such as a BSC) is shown at 400. The intermediate nodeincludes a receiver module 402, a processing module 404 and thetransmitting module 406. The call setup signal 408 is received at thereceiver module 402. In the processing module 404 the preferences andcapabilities of the intermediate node identified and used to modify the callsetup message as has previously been described above. The modified

call setup message 410 is then transmitted by the transmitter 406towards the network node (for example the MSC).


15/19

[0073]Similarly, in FIG. 5 the method steps at this intermediate node areillustrated. The intermediate node receives the call setup message atstep 500. At step 502 the preferences and capabilities of theintermediate node are identified. This leads to a modification of the callsetup message in step 504. There is then an onward transmission of themodified call setup message towards the network node in step 506. Theprocess stops at step 508

[0074]In order to demonstrate further elements and advantages of thepresent invention the following examples are now presented. In all the

examples it is assumed that the GSM terminal indicates support for thefollowing Codecs: [0075]FR-AMR hereinafter referred to as C1;

[0076]GSM-EFR hereinafter referred to as C2; [0077]GSM-FRhereinafter referred to as C3 (this is also the separator Codec mentionedabove); and [0078]GSM-HR hereinafter referred to as C4.

[0079]The GSM terminal sends an MS-SCL in the following form {C1,C2, C3, C4}.

[0080]In a first example it is assumed that the BSC prefers the selection

of Codec type C2 and supports this in TFO but the C1 Codec type is

currently not allowed or supported by TFO. Accordingly the BSCreorders the MS-SCL as follows {C2, C3, C1, C4}, where C3 is aseparator as indicated above. The MSC uses the information provided inthe Codec sequence to build the supported Codec list for OoBTC Codecnegotiation in the following form: {C2, PCM; C3, Configuration . . . }. In asecond example it is assumed that the BSC prefers selection of C2Codec type above C1 Codec type although both support TFO. In thiscase the BSC reorders the list as {C2, C1, C3, C4} and the MSC buildsan appropriate supported Codec list. In the third example it is assumedthat selection of C4 is necessary due to the fact that all full rate channeltypes are currently not allowed. In this case the BSC reorders the list as{C4, C3, C1, C2}. Due to knowledge in the MSC the supported Codec

list built by the MSC-S cannot include C4, as this is not a viable choicefor OoBTC; also C1 may offer a compromised speech quality andadditional compression in the core network and should similarly beavoided. Accordingly the supported Codec list takes one of the followingforms {PCM, C2, C1} or {PCM}. The later forces pulse code modulation(PCM) and forbids any other form of compression. Clearly there aremany other examples that could be illustrated; all result in a modification(if required) of the message received by the MSC prior to the starting ofCodec negotiations with the core network. Modification can includeadding data, deleting data, reordering date and any other appropriatetype of change.

[0081]Referring now to FIG. 2, the method steps in accordance with anembodiment the present invention are described. A call setup procedureis initiated at the GSM terminal in response to a requirement for a call(step 200). This results in a call setup message being generated by theGSM terminal for onward transmission to the MSC (step 202). The callsetup message may be of any type identified above or used in futuredevelopments of wireless network signaling. The BSC intercepts the callsetup message before the MSC commences negotiations as part of thecall setup routine (step 204). The interception can take place in anyappropriate manner. It will be appreciated that for other types of radioaccess network it may be a device other than the BSC that intercepts the

call setup message and effects the modification. The call setup message(in whatever form; for example, a MS-SCL message) is then updated or


16/19

modified by the BSC to include an indication of the preferences andcapabilities of the BSC at that time (step 206). The manner in which themessage is updated, it is in accordance with any of the exampleshighlighted above or any other appropriate manner. The updated ormodified message is then received at the MSC (step 208). The MSCthen proceeds to setup Codec negotiations with other network elementsin order to determine a match in the optimized Codec for the call inquestion (step 210). After this the call may proceed as indicated above.

[0082]It will be appreciated that the steps in the method may take placein a different order, without losing the many advantages of the present

invention.

[0083]It will be further appreciated that the above describedembodiments relate to the call originating side of a call setup, howeverequivalent actions may be carried out in the terminating side of the call asdescribed above.

[0084]There may be other variations and alternatives for all or any

element of the method and apparatus described above, which would fallwithin the scope and spirit of the present invention.

[0085]Although described with reference to a 3GPP compliant network,the invention may be employed in similar networks as well.

[0086]Furthermore, a person skilled in the art will understand that someor all of the functional entities as well as the processes themselves maybe embodied in software or one or more software-enabled modulesand/or devices.

Patent applications by ERIC

Patent applications by Ka


17/19

Patent applications by Dirk

Patent applications in class S


18/19

Patent applications in all subclass

User Contributions:

Comment about this patent or add new information about this topic:

Comment: (50-4000 characters)


19/19

Name: E-mail: Display my email:

Inventors list Agents list Assign

Classification tree browser Top 100 Inventors Top

Usenet FAQ Index Documents