WO2008071034A1 - Procédé de transformation d'option de service en données de circuit - Google Patents

Procédé de transformation d'option de service en données de circuit Download PDF

Info

Publication number
WO2008071034A1
WO2008071034A1 PCT/CN2006/003398 CN2006003398W WO2008071034A1 WO 2008071034 A1 WO2008071034 A1 WO 2008071034A1 CN 2006003398 W CN2006003398 W CN 2006003398W WO 2008071034 A1 WO2008071034 A1 WO 2008071034A1
Authority
WO
WIPO (PCT)
Prior art keywords
base station
service
circuit data
bearer
source base
Prior art date
Application number
PCT/CN2006/003398
Other languages
English (en)
French (fr)
Inventor
Zhihui Zhang
Bifeng Xie
Donghua Lu
Jian Cao
Wanchun Zhang
Original Assignee
Zte Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Zte Corporation filed Critical Zte Corporation
Priority to US12/518,080 priority Critical patent/US8199694B2/en
Priority to CN2006800565373A priority patent/CN101558670B/zh
Priority to PCT/CN2006/003398 priority patent/WO2008071034A1/zh
Publication of WO2008071034A1 publication Critical patent/WO2008071034A1/zh

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/12Setup of transport tunnels
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/65Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/11Allocation or use of connection identifiers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18Service support devices; Network management devices
    • H04W88/181Transcoding devices; Rate adaptation devices

Definitions

  • the present invention relates to an implementation method for changing SO (Service Option service option) to circuit data during a CDMA2000 legacy mobile terminal i or (Legacy Mobile Station Domain: LMSD) voice call, and More specifically, it relates to a method of negotiating such voice-to-circuit data switching between a BSS (Base Station Subsystem) and a VISS (Mobile Switching Subsystem) and such switching in BSS and MS ( Negotiation method between Mobile Station, mobile station).
  • BSS Base Station Subsystem
  • VISS Mobile Switching Subsystem
  • MS Negotiation method between Mobile Station, mobile station.
  • a packet-based CDMA2000 BSS (Base Station Subsystem) can be accessed by using an IP (Internet Protocol) switching technology to implement a softswitch-based CDMA2000 core network.
  • the biggest change of the softswitch-based CDMA2000 core network is the separation of call control and bearer, and the replacement of TDM (Time Division Multiplexing by packet network technology).
  • Time-division multiplexing technology the traditional MSC (Mobile Switching Center) network element evolved into MSCe (Mobile Switching Center emmulation) and MGW (Media Gate Way).
  • MSCe provides call control and mobility management functions.
  • the MGW provides media control functions and provides transmission resources with media stream manipulation.
  • the media gateway MGW needs to establish a bearer connection with the Select and Distribution Unit (SDU) in the base station system according to the obtained related information under the control of the MSCe. This process is called bearer parameter negotiation.
  • SDU Select and Distribution Unit
  • the CDMA access network In the original TDM transmission mode, when the circuit data service is implemented, the CDMA access network needs to convert the circuit data transmitted from the air port into a Pulse Coded Modulation (PCM) code stream through the TDM circuit through the vocoder. Media gateway. With the transmission mode of IP switching technology, the CDMA access network can directly convert the circuit data into RTP (Real-Time Transport Protocol) packets transmitted over the IP network, which corresponds to the circuit data service protocol.
  • RTP Real-Time Transport Protocol
  • the stack structure is shown in Figure 1. Whether it is the original TDM transmission method or the transmission method of the existing IP switching technology, When the circuit data is transmitted, it is impossible for the user to switch between the voice and the circuit data freely when implementing the circuit data.
  • the operation code must be added before the number when sending the fax.
  • the process of the user to perform a fax is very cumbersome, so it is easy to make mistakes, which is not conducive to the promotion of wireless fax under the CDMA2000 system. Therefore, under the CDMA2000 network, there is a strong demand for changing SO to circuit data during voice calls in all regions of the world where CDMA2000 systems use wireless fax.
  • the present invention has been made in view of the above problems, and it is therefore a primary object of the present invention to provide a method of changing service options to circuit data.
  • the method for changing the service option to the circuit data provided by the embodiment of the present invention includes the following steps: First step: During the session, the mobile station notifies the source base station and/or the target base station to change the service option to the circuit data.
  • the second step the source base station And/or the destination base station and the mobile switching subsystem perform the negotiation of changing the service option to the circuit data, and determine the bearer format parameter of the session by negotiation; the third step: after successfully negotiating with the mobile switching subsystem, the source base station and/or Or the destination base station performs secondary service negotiation with the mobile station; and the fourth step, after the negotiation with the mobile station is successful, the source base station and/or the target base station complete the user interface service layer encapsulation according to the determined payload format, and then package the package The real-time transport protocol packet is transmitted to the opposite base station.
  • the method preferably includes the fifth step: after receiving the real-time transport protocol packet, the source base station and/or the destination base station decrypts the user plane service layer user data and processes according to the payload format to obtain the circuit data payload.
  • the process of determining, by the source base station and/or the target base station, the bearer format parameter of the session includes the following steps: Step A: The source base station and/or the target base station send a bearer update to the mobile switching center simulator.
  • the request message carries the bearer format parameter of the circuit data to be used in the bearer update request message;
  • Step B The mobile switching center simulator determines that the session can change the service option to the circuit data according to the bearer format parameter and the capability of the media gateway.
  • the source base station and/or the destination base station determines that the session uses circuit data coding, establishes a corresponding channel resource, and moves to the mobile terminal after negotiating with the corresponding mobile terminal
  • the switching center simulator sends a bearer update response message.
  • the source base station and/or the destination base station perform secondary service negotiation with the mobile station to inform the mobile station to change the service option to the circuit data, or to inform the mobile station base station side that the negotiation of changing the service option to the circuit data has been completed.
  • the secondary service negotiation process includes the following steps: Step A: The source base station and/or the destination base station send a service connection message to the mobile station, agreeing that the mobile station is in the service request message.
  • the secondary service negotiation process includes the following steps: Step A: The source base station and/or the destination base station send a service request message to the mobile station, and the requested circuit data needs to be used.
  • the service configuration is sent to the mobile station;
  • Step B The mobile station determines, according to the received service configuration parameter and the capability of the mobile station itself, that the session can change the service item to the circuit data, to the source base station and/or the destination base station.
  • Sending a service response message accepting a service configuration sent by the source base station and/or the target base station;
  • Step C In response to the service response message, the source base station and/or the target base station determine the circuit data coding used in the session, and establish corresponding channel resources, And transmitting a service connection message to the mobile station;
  • step D in response to the service connection message, the mobile station returns a service connection completion message to the source base station and/or the destination base station, and starts to use the new service configuration.
  • the present invention realizes the function of changing the service option to the circuit data in the CDMA2000 traditional mobile terminal domain voice call process, and the user only needs to operate like the fixed network fax when performing the G3 fax, simplifying the operation of transmitting/receiving the fax.
  • the problem of changing SO to speech after the completion of circuit data can be effectively solved.
  • FIG. 1 A schematic diagram of a protocol stack structure according to a service
  • 2 is a schematic diagram of an A2p bearer session level parameter according to the related art
  • FIG. 3 is a schematic diagram of an A2p bearer specific format parameter according to the related art
  • FIG. 4 is a flowchart of a method for changing a service option to circuit data according to an embodiment of the present invention
  • 5 is a flowchart of a process in which a source base station and/or a destination base station determines a bearer format parameter
  • FIG. 6 is a schematic diagram of an A2p bearer format extended ID field with an extended ID of 7 according to an embodiment of the present invention
  • FIG. 7 is a schematic diagram of an A2p bearer format extended ID field according to an embodiment of the present invention
  • FIG. 8 is a flow chart of an example of secondary service negotiation between a source base station and/or a destination base station and a mobile station
  • FIG. 9 is a source base station and/or a destination base station and a mobile station.
  • FIG. 10 is a schematic diagram of a negotiation process of switching to circuit data during a voice call in the first embodiment of the present invention
  • FIG. 11 is a voice call process in the second embodiment of the present invention.
  • FIG. 12 is a negotiation process for switching to circuit data during a voice call in Example 3 of the present invention
  • FIG. DETAILED DESCRIPTION OF THE INVENTION The inventive principle of the present invention will first be described.
  • CDMA2000 LMSD must solve two problems: First, during the call, when to initiate the negotiation of voice change SO to circuit data, how to make the call sending and receiving ends Knowing that this session needs to change the parameters related to the circuit data and the circuit data. Second, how to change the SO to the circuit data between the BSS and the MSS in the CDMA2000 LMSD.
  • the protocol (such as SDP) is used to negotiate the bearer format parameters.
  • the 3G IOS V5.0 and above protocols do not directly use the SDP protocol on the Alp interface, but extend the A1 (signaling structure between the traditional BSC and the MSC) interface.
  • the control message carries the corresponding bearer format parameter to specify the selected code for a particular session.
  • the specific bearer session level parameters and the bearer specific format parameters are defined in FIG. 2 and FIG. 3.
  • the method for changing service options to circuit data includes the following steps: Step S402: During a session, the mobile station notifies the source base station and/or the destination base station to change service options to the circuit. Data: Step S404: The source base station and/or the destination base station and the mobile switching subsystem perform a negotiation to change the service option to the circuit data, and determine the bearer format parameter of the session by negotiation; Step S406: Successfully negotiate with the mobile switching subsystem.
  • Step S418 After the negotiation with the mobile station succeeds, the source base station and/or the target base station complete the user interface service layer encapsulation according to the determined payload format. And then transmitting the encapsulated real-time transport protocol packet to the opposite base station; and step S410: after receiving the real-time transport protocol packet, the source base station and/or the target base station, the user plane service layer user data is solved, and processed according to the payload format, Circuit data payload.
  • step S402 is described.
  • the source base station or/and the destination base station determines that the code used in the session is voice (EVRC/8K/13K), and determines the bearer format parameter of the session by negotiating with the MSS;
  • the format parameter the format ID value is 2 (13K) / 3 (EVRC) / 4 (EVRC0) and other voice call 7
  • EVRC/8K/13K voice
  • the format ID value is 2 (13K) / 3 (EVRC) / 4 (EVRC0) and other voice call 7
  • the MS notifies the BS (Base Station) that the SO to circuit data needs to be changed.
  • the MS determines whether to change the SO according to the CNG (Calling tone)/CED (Called Terminal Identification) tone coming from the fax machine.
  • CNG Calling tone
  • CED Called Terminal Identification
  • the change is initiated by the user pressing the start button (or the confirmation button, the name of each fax machine may be different) on the fax machine or the user sets the fax machine to automatically answer, and the MS notifies the service request message through the air interface.
  • the BS, the service request message contains the circuit data service options supported by the current MS and the required RC (Radio Configuration) configuration.
  • the BS determines whether the current system supports the SO and RC configurations requested in the MS service request message, and if so, starts to perform the circuit data operation on the base station side. At the same time, negotiate with the MSS, otherwise, reject the MS's change SO to circuit data operation request.
  • the above circuit data may also be asynchronous data. If it is asynchronous data, the method for the MS to determine whether to change the SO to the circuit data is different from the above processing, for example, in a specific case, it may be > according to the opposite calling number To judge. Next, step S404 is described. As shown in FIG.
  • the process of determining the bearer format parameter of the current session by the source base station and/or the target base station includes the following steps: Step S502: The source base station and/or the target base station send a bearer update request to the mobile switching center simulator (Beard Update) The message carries the bearer format parameter of the circuit data to be used in the bearer update request message. Step S504: The mobile switching center simulator determines, according to the bearer format parameter and the capability of the media gateway, that the session can change the service option to the circuit data.
  • step S506 in response to the assignment request message, the source base station and/or the target base station determine that the session uses circuit data coding, and establishes a corresponding The channel resource, after negotiating with the corresponding mobile terminal, sends a 7-load update response message to the mobile switching center simulator.
  • the source base station and / or transmitted to the destination base station MSCe First, in addition to carrying circuit data format parameter in the bearer update request message required to be used in the transmission
  • the SO information used in the circuit data must also be brought to the MSCe, and the SO information used in the circuit data is carried by the extended domain; in addition, an ear-reset value is added to the bearer update request message.
  • 0x2D A2p Service Option Change to Circuit Data Service
  • the Bearer Format ID field in the message ranges from 8-15.
  • step S406 the source base station and/or the destination base station perform secondary service negotiation with the mobile station to Knowing that the mobile station changes the service option to the circuit data, or informs the mobile station that the base station side has completed the negotiation of changing the service option to the circuit data.
  • the BSS compares the current RC configuration with the RC configuration requested by the MS. If the two are consistent, the RC is not replaced. If not, the RC switching is performed once.
  • the secondary service negotiation process in step S406 includes the following steps: Step S802: The source base station and/or the target base station send a service connection message to the mobile station. And agreeing to the service configuration proposed by the mobile station in the service request message; and step S804: the mobile station returns a service connection complete message to the source base station and/or the target base station, and starts to use the new service configuration.
  • the secondary service negotiation process in step S406 includes the following steps: Step S902: The source base station and/or the target base station send a service request message to the mobile station, Transmitting the service configuration to be used by the requested circuit data to the mobile station; Step S904: The mobile station determines, according to the received service configuration parameter and the capability of the mobile station itself, that the session can change the service item to the circuit data, The source base station and/or the destination base station send a service response message, and accept the service configuration sent by the source base station and/or the target base station; Step S906: In response to the service response message, the source base station and/or the target base station determine the circuit data coding used in the session.
  • Example 1 As shown in Figure 10, the source BS and the destination BS complete the ten-carrier with the parameters in accordance with the standard IOS 5.0 protocol. After the negotiation is completed, the system enters a normal voice call. During the call, the source BS receives the request from the MS to change the SO.
  • the service request to the circuit data determines that the BS side supports the SO required by the MS, and the source BS carries the bearer format negotiation by carrying the A2p bearer parameter through the Bearer Update Required message on the BS side, and the destination BS passes the bearer update on the MSS side.
  • the request message (Bearer Update Request) carries the A2p bearer parameters to complete the negotiation of the bearer format. Specifically, the following processing is included: In the first step, the source BS and the MSCe complete the negotiation of the bearer format.
  • the source BS sends the bearer format parameter of the required circuit data to the MSCe in the bearer update request message of the BS side, and carries the A2p bearer specific format parameter (A2p Bearer Format-Specific Paramaters)
  • the RTP payload type and the bearer format ID determine the correspondence between the circuit data encoding frame format and the RTP payload type; the fixed source BS determines that the current session requires ⁇ : the encoding used is circuit data, and the reserved bearer format is used.
  • MSCe receives the 7 sent by the source BS
  • the update request message is determined to change the SO to the circuit data.
  • the MSCe determines that the session can change the SO to the circuit data according to the bearer format parameter sent by the source BS and the MGW capability and the resource condition, and sends the bearer parameter to the source BS.
  • the bearer update request message is sent; (cl) after receiving the bearer update request message delivered by the MSCe, the source BS determines the session according to the bearer format therein.
  • the source BS After using the circuit data, establishing a corresponding channel resource and negotiating with the corresponding MS, sending a bearer update response message to the MSCe; (dl) the source BS determines whether to change the RC according to the current RC configuration and the RC configuration requested by the MS, and if so, Change the RC switch once.
  • the MSCe and the destination BS complete the negotiation of the bearer format, specifically: (a2) During the call, the MSCe receives the bearer update request message sent by the source BS, and determines that the SO to circuit data is changed, and the MSCe sends according to the source BS.
  • the bearer format parameter and the MGW capability and the resource situation determine that the session can change the SO to the circuit data, and send the bearer update request message carrying the bearer parameter to the source BS.
  • the MSCe After receiving the bearer update response message sent by the source BS, the MSCe Sending, to the destination BS, a bearer update request message carrying the 7th-loaded parameter; (b2) after receiving the update request message delivered by the MSCe, the destination BS determines, according to the bearer format, that the current bearer needs to change the bearer format to be a circuit.
  • Data after establishing a corresponding channel resource and negotiating with the corresponding MS, sending a bearer update response message to the MSCe;
  • the destination BS After receiving the bearer update request message sent by the MSCe, the destination BS determines that the current bearer needs to change the bearer format to circuit data according to the bearer format, and sends a service request message to the MS to notify the MS to change the SO to the circuit data, and the MS determines Supporting circuit data, after completing the relevant configuration, returning the service response message to the destination BS, accepting the service configuration proposed by the base station, and after receiving the destination BS, determining the circuit data coding used in the session, establishing corresponding channel resources, and returning the service connection to the MS.
  • the message returns the service connection completion message to the destination BS, starts to use the new service configuration, and sends a fax tone to the connected fax machine to notify the user that the opposite party user has changed SO to circuit data; (d2) the destination BS receives the MSCe.
  • the bearer update request message is sent, it is determined whether to change the RC according to the RC configuration corresponding to the SO in the current RC configuration and the bearer update request message, and if so, the RC switch is performed once.
  • the third step MSCe according to its bearer format negotiated with the source BS and its negotiation with the destination BS
  • the corresponding format of the IWF resource is allocated, and the related work inside the MSS side of the circuit data is completed, including the allocation of new resources, the release of old resources, and the connection of circuit data links.
  • Step 4 After the SO is changed to the circuit data, the source BS and the destination BS complete the encapsulation of the user traffic (User Traffic) layer according to the determined payload format, and then encapsulate the data into RTP packets respectively.
  • the network is sent to the MGW.
  • Step 5 After completing the change of the SO to the circuit data, the MGW receives the RTP packet sent by the source BS and the destination BS, and extracts the received RTP packet from the User Traffic user data, and then processes the data according to the payload format to obtain circuit data.
  • the payload is processed by the IWF module, and the processed circuit data is encapsulated by the User Traffic layer according to the determined payload format, and then encapsulated into an RTP packet and sent to the opposite BS through the IP network.
  • Step 6 The source BS and the destination BS extract the User Traffic user data from the received RTP packet, and process the User Traffic user data according to the payload format, obtain the corresponding circuit data payload, and then send the corresponding data to the corresponding MS through the air interface.
  • Example 2 As shown in Figure 11, the source BS and the destination BS complete the negotiation of the bearer parameters in accordance with the standard IOS 5.0 protocol. After the negotiation is completed, the system enters a normal voice call. During the call, the destination BS receives the request from the MS to change the SO to The service connection request of the circuit data determines that the BS side supports the SO required by the MS, and the destination BS completes the bearer format negotiation by carrying the A2p bearer parameter by using the Bearer Update Required message on the BS side, and the source BS passes the bearer on the MSS side.
  • the Bearer Update Request carries the A2p bearer parameters to complete the negotiation of the bearer format.
  • Step 1 The destination BS and the MSCe complete the negotiation of the 7-load format. Specifically: (al) During the call, the destination BS sends the bearer format parameter of the circuit data to be used to the MSCe in the bearer update request message of the BS side, and carries the A2p bearer Format-Specific Paramaters.
  • the RTP payload type and the bearer format ID determine the correspondence between the circuit data encoding frame format and the RTP payload type; assuming that the source BS determines that the encoding to be used for the session is circuit data, the reserved bearer format ID value is used.
  • the value ranges from 8 to 15, which is defined as 9, the code name is circuit data, the load type is the dynamic bearer type value, and the frame format uses the load format of the circuit data; ( bl ) the MSCe receives the bearer update request message sent by the destination BS.
  • the MSCe determines that the session can change the SO to the circuit data according to the bearer format parameter sent by the destination BS and the MGW capability and the resource condition, and sends a bearer update request message carrying the bearer parameter to the destination BS;
  • the BS After receiving the bearer update request message sent by the MSCe, the BS determines, according to the bearer format, the current session as the used circuit data, establishes the corresponding channel resource, and negotiates with the corresponding MS, and sends a bearer update response message to the MSCe;
  • the destination BS decides whether to change the RC according to the current RC configuration and the RC configuration requested by the MS. If yes, it performs a RC switch.
  • Step 2 The MSCe and the source BS complete the negotiation of the bearer format. Specifically: (a2) during the call, the MSCe receives the bearer update request message sent by the destination BS, and determines that the SO to circuit data is changed, and the MSCe determines the session according to the bearer format parameter sent by the source BS and the MGW capability and resources. After the SO to the circuit data is changed, the bearer update request message carrying the bearer parameter is sent to the destination BS. After receiving the bearer update response message from the destination BS, the MSCe sends the bearer update request message carrying the bearer parameter to the source BS.
  • the source BS After receiving the bearer update request message sent by the MSCe, the source BS determines, according to the bearer format, that the current bearer needs to change the bearer format to circuit data, establish a corresponding channel resource, and negotiate with the corresponding MS. And updating the response message to the MSCe; (c2) after receiving the bearer update request message sent by the MSCe, the source BS determines, according to the bearer format, that the current bearer needs to change the bearer format to circuit data, and sends a service dependency message to the MS to notify the MS.
  • the MS determines the support circuit data, and returns the service response message to the destination BS after completing the relevant configuration
  • the source BS determines that the session uses the circuit data coding, establishes the corresponding channel resource, returns the service connection message to the MS, and the MS returns the service connection completion message to the source BS, and starts to use the new message.
  • the service configuration sends a fax tone to the connected fax machine to notify the user that the peer call user has changed the SO to the circuit data; (d2) after the source BS receives the bearer update request message sent by the MSCe, according to the current RC configuration and bearer
  • the RC configuration corresponding to the SO in the update request message determines whether to change the RC, and if so, the RC switch is changed once.
  • the subsequent processing is the same as the processing of the third to sixth steps in the example 1, and for this reason, the repeated description thereof is omitted.
  • Example 3 As shown in Figure 12, the source BS and the destination BS complete the negotiation of the parameters according to the standard IOS5.0 protocol. After the negotiation is completed, the system enters a normal voice call.
  • both the source BS and the destination BS receive the MS transmission request.
  • the service connection request of the SO to the circuit data is changed, and the SO required by the MS side to support the MS is determined, and the source BS and the destination BS both pass the bearer update request message on the BS side (Beard Update) Required: Carrying the A2p bearer parameter to complete the negotiation of the bearer format, and the source BS and the destination BS complete the bearer format negotiation by carrying the A2p bearer parameter by using the Bearer Update Request message on the MSS side.
  • the packet: ⁇ is processed as follows: Step 1: The source BS and the MSCe complete the negotiation of the bearer format.
  • the source BS sends the bearer format parameter of the required circuit data to the MSCe in the bearer update request message of the BS side, and carries the A2p bearer specific format parameter (A2p Bearer Format-Specific Paramaters)
  • the RTP payload type and the bearer format ID determine the correspondence between the circuit data encoding frame format and the RTP payload type;
  • the MSCe receives the bearer update request message sent by the source BS, and determines that the SO to circuit data is changed, MSCe Determining, according to the carrier format parameter sent by the source BS, the MGW capability and the resource situation, the session may change the SO to the circuit data, and send the bearer update request message carrying the bearer parameter to the source BS;
  • the source BS receives the MSCe After the bearer update request message is sent, the current session is determined to use the circuit data according to the bearer format, and the corresponding channel resource is established and negotiated with the corresponding
  • Step 2 The destination BS and the MSCe complete the negotiation of the bearer format. Specifically: 2) During the call, the destination BS sends the bearer format parameter of the required circuit data to the MSCe in the bearer update request message of the BS side, and carries the A2p Bearer Format-Specific Paramaters.
  • the RTP payload type and the ⁇ format ID determine the correspondence between the circuit data encoding frame format and the RTP payload type; (b2) the MSCe receives the destination BS; and the update request message is determined to change the SO to the circuit data.
  • the MSCe determines, according to the bearer format parameter sent by the source BS, the MGW capability and the resource condition, that the session can change the SO to the circuit data, and sends the bearer update request message carrying the bearer parameter to the destination BS; (c2) the destination BS After receiving the bearer update request message sent by the MSCe, determining, according to the bearer format, the session is the use circuit data, establishing the corresponding channel resource, and negotiating with the corresponding MS, sending a bearer update response message to the MSCe; The destination BS determines whether to change the RC according to the current RC configuration and the RC configuration of the MS clearing. If yes, the RC switching is performed once.
  • the subsequent processing is the same as the processing of the third to sixth steps in the example 1, and for this reason, the repeated description thereof is omitted.
  • the values of the extended ID and the extended parameters mentioned in the above respective examples are merely exemplary, and the present invention may use values of other extended IDs and extended parameters. Of course, the present invention may also have other implementations. For example, when the calling party is a circuit data call, the called party receives the voice change SO to the circuit data, and the source BS manages the service request message or the subsequent assignment completion message through the connection.
  • the destination BS sends the bearer format parameter of the circuit data to be used to the MSCe by using the bearer update request message on the BS side.
  • the source BS sends the bearer format parameter of the circuit data to be used to the MSCe through the bearer update request message on the BS side, and the destination BS passes the paging response message or the subsequent assignment completion message.
  • the supported circuit data bearer format parameters are sent to the MSCe.
  • the new embodiment can be obtained by freely combining the manner in which the source BS and the destination BS of the above example complete the negotiation of the bearer format.

Landscapes

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

Description

改变业务选项到电 教据的方法 技术领域 本发明涉及一种在 CDMA2000传统移动终端 i或 ( Legacy Mobile Station Domain: LMSD )语音通话过程中改变 SO ( Service Option 业务选项)到电路 数据的实现方法,并且更具体地,涉及这种语音到电路数据的切换在 BSS( Base Station Subsystem, 基站子***)和] VISS ( Mobile Switching Subsystem, 移动 交换子*** ) 间的协商方法以及这种切换在 BSS和 MS ( Mobile Station, 移动 台) 间的协商方法。 背景技术 基于分组的 CDMA2000 BSS ( Base Station Subsystem, 基站子***)可以 采用 IP ( Internet protocol 网际协议) 交换技术接入到实现基于软交换的 CDMA2000核心网。 与传统的电路 i或 MSS ( Mobile Switching Subsystem, 移动 交换子***) ***相比, 基于软交换的 CDMA2000核心网最大的变化在于呼 叫控制和承载的分离, 用分组网技术替换 TDM ( Time Division Multiplexing , 时分多路复用)技术, 传统的 MSC ( Mobile Switching Center, 移动交换中心) 网元演进成 MSCe ( Mobile Switching Center emmulation,移动交换中心模 4以器 ) 和 MGW ( Media Gate Way, 媒体网关), MSCe提供呼叫控制和移动性管理功 能, MGW提供媒体控制功能, 并提供传输资源, 具有媒体流操纵功能。 媒体网关 MGW需要在 MSCe的控制下, 根据得到的相关信息与基站系 统内的选择器单元(Selection and Distribution Unit, SDU )建立承载连接, 此 过程称为承载参数协商。 在原来的 TDM传输方式下, 实现电路数据业务时, CDMA接入网需要将 从空中口传来的电路数据通过声码器转换成脉冲编码调制 ( Pulse Coded Modulation, PCM )码流通过 TDM电路传输到媒体网关。 采用 IP交换技术的 传输方式, CDMA接入网可以不需要进行编解码的转换 , 直接将电路数据做为 RTP ( Real-Time Transport Protocol 实时传输协议)分组通过 IP网络传输, 对 应电路数据业务的协议栈结构如附图 1所示。 不管是原来的 TDM传输方式还是现有的 IP交换技术的传输方式, 在实 现电路数据传输时, 都无法让用户在实现电路数据时自由地在语音和电路数据 之间切换, 比如, 用户要在 CDMA2000下实现无线 G3传真, 则在发送传真时 必须在号码前加操作码以区分是语音业务还是传真业务, 在接收传真时必须先 对固定台设置传真接收操作码, 把固定台设为传真接收模式, 接收完传真后必 须再对固定台设置一次操作码, 让固定台回到语音模式以接听电话, 这样, 用 户要进行一次传真的过程非常繁瑣, 因此很容易出错, 非常不利于 CDMA2000 ***下无线传真的推广。 因此, 在 CDMA2000网络下, 实现语音通话过程中改变 SO到电路数据 在全世界所有使用 CDMA2000***无线传真的地区都有强烈的需求。 发明内容 考虑到上述问题而做出本发明, 因此,本发明的主要目的在于提供一种改 变业务选项到电路数据的方法。 本发明实施例提供的改变业务选项到电路数据的方法包括以下步骤:第一 步骤: 在会话过程中,移动台通知源基站和 /或目的基站改变业务选项到电路数 据; 第二步骤: 源基站和 /或目的基站与移动交换子***进行改变业务选项到电 路数据的协商, 并通过协商确定本次会话的承载格式参数; 第三步驟: 在与移 动交换子***协商成功后, 源基站和 /或目的基站与移动台进行二次业务协商; 以及第四步骤, 在与移动台协商成功后, 源基站和 /或目标基站将电路数据按照 确定的载荷格式完成用户界面业务层封装, 然后将封装成的实时传输协议分组 传输到对端基站。 此夕卜, 该方法优选地包括第五步骤: 源基站和 /或目的基站接收到实时传 输协议分组后, 解出用户面业务层用户数据并按照载荷格式处理, 获取电路数 据净荷。 具体而言, 在第二步骤中, 源基站和 /或目的基站确定本次会话的承载格 式参数的处理包括以下步驟: 步骤 A: 源基站和 /或目的基站向移动交换中心模拟器发送承载更新请求 消息, 在承载更新请求消息中携带有需要使用的电路数据的承载格式参数; 步 驟 B: 移动交换中心模拟器根据承载格式参数以及媒体网关的能力确定本次会 话可以改变业务选项到电路数据,并向源基站和 /或目的基站发送携带有承载格 式参数的指派请求消息; 以及步 C: 响应于指派请求消息, 源基站和 /或目的 基站确定本次会话使用电路数据编码, 建立相应的信道资源, 在与相应的移动 终端协商后, 向移动交换中心模拟器发送承载更新响应消息。 在第三步骤中, 源基站和 /或目的基站与移动台进行二次业务协商, 以通 知移动台更改业务选项到电路数据, 或通知移动台基站侧已完成更改业务选项 到电路数据的协商。 在第三步驟中,如果是语音转传真的发起方,则二次业务协商过程包括以 下步骤: 步驟 A: 源基站和 /或目的基站向移动台发送业务连接消息, 同意移动 台在业务请求消息中提出的业务配置; 以及步骤 B: 移动台向源基站和 /或目的 基站返回业务连接完成消息, 开始使用新的业务配置。 在第三步骤中,如果不是语音转传真的发起方,则二次业务协商过程包括 以下步骤: 步骤 A: 源基站和 /或目的基站向移动台发送业务请求消息, 将请求 的电路数据需要使用的业务配置发送给移动台; 步骤 B: 移动台在根据接收到 的业务配置参数以及移动台本身的能力确定本次会话可以改变业务项目到电 路数据的情况下, 向源基站和 /或目的基站发送业务响应消息, 接受源基站和 / 或目的基站发送的业务配置; 步骤 C: 响应于业务响应消息, 源基站和 /或目的 基站确定本次会话使用的电路数据编码, 建立相应的信道资源, 并向移动台发 送业务连接消息; 以及步骤 D: 响应于业务连接消息, 移动台向源基站和 /或目 的基站返回业务连接完成消息, 开始使用新的业务配置。 通过上述技术方案, 本发明实现了 CDMA2000传统移动终端域语音通话 过程中改变业务选项到电路数据的功能, 用户在进行 G3传真时只须和固网传 真一样操作, 简化了发送 /接收传真的操作, 另外, 采用同样的方式, 也能有效 解决电路数据完成后改变 SO到语音的问题。 附图说明 此处所说明的附图用来提供对本发明的进一步理解, 构成本申请的一部 分, 本发明的示意性实施例及其说明用于解释本发明, 并不构成对本发明的不 当限定。 在附图中:
据业务的协议栈结构的示意图; 图 2是根据相关技术的 A2p承载会话级别参数示意图; 图 3是根据相关技术的 A2p承载特定格式参数示意图; 图 4是根据本发明实施例的改变业务选项到电路数据的方法的流程图; 图 5是源基站和 /或目的基站确定承载格式参数的处理的流程图; 图 6是根据本发明实施例的扩展 ID为 7的 A2p承载格式扩展 ID字段示 意图; 图 7是根据本发明实施例的扩展 ID为 7的 A2p承载格式扩展参数字段示 意图; 图 8 是源基站和 /或目的基站与移动台进行二次业务协商的实例的流程 图; 图 9是源基站和 /或目的基站与移动台进行二次业务协商的另一实例的流 程图; 图 10是在本发明实例 1中的语音通话过程中切换到电路数据的协商过程 的示意图; 图 11是本发明实例 2中的语音通话过程中切换到电路数据的协商过程的 示意图; 以及 图 12是本发明实例 3中的语音通话过程中切换到电路数据的协商过程的 示意图。 具体实施方式 首先介绍本发明的发明原理。
CDMA2000 LMSD要实现由语音改变 SO到电路数据, 必须解决两个方 面的问题: 第一, 在通话过程中, 何时发起由语音改变 SO到电路数据的协商, 如何使通话的发送和接收端都知道本次会话需改变 so到电路数据以及电路数 据有关的参数; 第二, CDMA2000 LMSD中 BSS与 MSS间如何就语音改变 SO 到电路数据进行协商, 一般来说, 在发送端和接收端, 可以使用高层的控 制协议 (例如 SDP )来进行承载格式参数的协商, 3G IOS V5.0及以上版本协 议在 Alp接口没有直接使用 SDP协议, 而是通过扩展 A1 (传统 BSC和 MSC 之间的信令结构)接口控制消息来携带相应的承载格式参数来对特定的会话指 定所选择的编码, 具体的承载会话级别参数和承载特定格式参数的定义参见附 图 2和附图 3。 为此,如图 4所示,本发明实施例提供的改变业务选项到电路数据的方法 包括以下步骤: 步骤 S402: 在会话过程中, 移动台通知源基站和 /或目的基站改变业务选 项到电路数据; 步骤 S404: 源基站和 /或目的基站与移动交换子***进行改变 业务选项到电路数据的协商, 并通过协商确定本次会话的承载格式参数; 步骤 S406: 在与移动交换子***协商成功后, 源基站和 /或目的基站与移动台进行二 次业务协商; 步骤 S418: 在与移动台协商成功后, 源基站和 /或目标基站将电 路数据按照确定的载荷格式完成用户界面业务层封装, 然后将封装成的实时传 输协议分组传输到对端基站; 以及步骤 S410: 源基站和 /或目的基站接收到实 时传输协议分组后, 解出用户面业务层用户数据并按照载荷格式处理, 获取电 路数据净荷。 以下将具体描述上述的各个步骤。 首先, 描述步骤 S402。 会话建立过程中, 源基站或 /和目的基站确定本次会话使用的编码为语音 ( EVRC/8K/13K), 并通过与 MSS进行协商确定本次会话的承载格式参数; 其 中, 在确定的 载格式参数中, 载格式 ID值为 2(13K)/3(EVRC)/4(EVRC0) 等语音呼叫 7|载格式 ID。
MS通知 BS ( Base Station 基站) 需要改变 SO到电路数据, 其中, 当电 路数据为 G3传真时, MS是根据传真机过来的 CNG( Calling tone )/CED( Called terminal identification )音来决定是否更改 SO到 G3传真, 更改是由用户在传 真机上按开始键(或叫确认键, 各传真机命名可能有所不同 )发起或用户设置 好传真机自动应答发起的, MS通过空中口的业务请求消息通知 BS , 业务情求 消息中包含当前 MS 支持的电路数据业务选项和所需的 RC ( Radio Configuration 无线配置) 配置。 at匕外, BS判断当前***是否支持 MS业务清 求消息中请求的 SO和 RC配置, 若支持, 则开始执行基站侧的转电路数据操 作, 同时与 MSS进行协商, 否则, 拒绝 MS的改变 SO到电路数据操作请求。 此外, 上述的电路数据还可能是异步数据, 如果是异步数据, 则 MS判断 是否更改 SO到电路数据的方法与上述处理有所不同, 例如, 在特定情况下, 可能 >据对端主叫号码来判断。 其次, 描述步骤 S404。 如图 5所示, 源基站和 /或目的基站确定本次会话的承载格式参数的处理 包括以下步骤: 步骤 S502: 源基站和 /或目的基站向移动交换中心模拟器发送承载更新请 求 ( Bearer Update Required ) 消息, 在承载更新请求消息中携带有需要使用的 电路数据的承载格式参数; 步骤 S504: 移动交换中心模拟器根据承载格式参数 以及媒体网关的能力确定本次会话可以改变业务选项到电路数据, 并向源基站 和 /或目的基站发送携带有承载格式参数的指派请求消息; 以及步骤 S506: 响 应于指派请求消息, 源基站和 /或目的基站确定本次会话使用电路数据编码, 建 立相应的信道资源, 在与相应的移动终端协商后, 向移动交换中心模拟器发送 7?载更新响应消息。 以下将描述在步骤 S502中源基站和 /或目的基站向 MSCe发送的 7 载更新 请求( Bearer Update Required ) 消息: 首先, 除了在承载更新请求消息中将所 需使用的电路数据的承载格式参数发送给 MSCe外, 还必须将本次电路数据所 使用的 SO信息带给 MSCe,本次电路数据所使用的 SO信息通过扩展域来携带; 另外, 在承载更新请求消息中增加一种耳又值, 例如: 0x2D ( A2p Service Option Change to 电路数据 Service ),表示 BS请求承载更新的原因为语音通话过程中 SO改变到电路数据业务; 其次, 消息中的 Bearer Format ID字段取值范围为 8-15 , 这里 定为 9(电路数据 :), 表示请求的 7|载格式为电路数据, RTP PayloadType=60H - 7FH (dynamically assigned = IWF)。 另外, 如图 6所示, 上述的扩展域包括 A2p承载格式参数中的扩展 ID、 扩展长度和扩展参数; 另外, 如图 7所示, 扩展域中增加了确定本次会话将采 用的电路数据的 SO。 接下来, 描述步骤 S406。 在步驟 S406中, 源基站和 /或目的基站与移动台进行二次业务协商, 以通 知移动台更改业务选项到电路数据, 或通知移动台基站侧已完成更改业务选项 到电路数据的协商。 可选地, 在该步驟中, BSS还将当前的 RC配置和 MS请 求的 RC配置进行比较, 如果二者一致, 则不更换 RC,. 如果不一致, 则进行 一次换 RC切换。 其中, 如果是语音转传真的发起方, 则如图 8所示, 该步骤 S406中的二 次业务协商过程包括以下步驟: 步驟 S802: 源基站和 /或目的基站向移动台发 送业务连接消息, 同意移动台在业务请求消息中提出的业务配置; 以及步骤 S804: 移动台向源基站和 /或目的基站返回业务连接完成消息, 开始使用新的业 务配置。 相反, 如果不是语音转传真的发起方, 则如图 9所示, 该步骤 S406中的 二次业务协商过程包括以下步骤: 步骤 S902: 源基站和 /或目的基站向移动台 发送业务请求消息, 将请求的电路数据需要使用的业务配置发送给移动台; 步 骤 S904:移动台在根据接收到的业务配置参数以及移动台本身的能力确定本次 会话可以改变业务项目到电路数据的情况下,向源基站和 /或目的基站发送业务 响应消息, 接受源基站和 /或目的基站发送的业务配置; 步骤 S906: 响应于业 务响应消息, 源基站和 /或目的基站确定本次会话使用的电路数据编码, 建立相 应的信道资源, 并向移动台发送业务连接消息; 以及步驟 S908: 响应于业务连 接消息, 移动台向源基站和 /或目的基站返回业务连接完成消息, 开始使用新的 业务配置。 以下 ,将结合具体实例来描述上述实施例中提供的改变业务选项到电路数 据的方法。 实例 1 如图 10所示, 源 BS和目的 BS遵照标准 IOS5.0协议完成 载参数的十办 商, 协商完成后***进入正常语音通话, 在通话过程中源 BS收到 MS过来的 要求改变 SO到电路数据的业务请求, 确定 BS侧支持 MS所要求的 SO, 源 BS通过 BS侧的承载更新请求消息( Bearer Update Required )携带 A2p承载参 数完成承载格式的协商, 目的 BS 通过 MSS 侧的承载更新请求消息 (Bearer Update Request )携带 A2p承载参数完成承载格式的协商。 具体包括以下处理: 第一步, 源 BS与 MSCe完成承载格式的协商。 具体为: (al )通话过程 中, 源 BS在 BS侧的承载更新请求消息中将所需使用的电路数据的承载格式 参数发送给 MSCe,携带的 A2p承载特定格式参数 ( A2p Bearer Format-Specific Paramaters ) 中的 RTP栽荷类型与承载格式 ID确定了电路数据编码帧格式和 RTP载荷类型的对应关系; £定源 BS确定本次会话需要 ^:用的编码为电路数 据, 则使用保留的承载格式 ID值, 取值范围为 8〜15 , 这里假定为 9 , 编码名 称是电路数据,载荷类型为动态承载类型值,帧格式使用电路数据的载荷格式; ( b l ) MSCe收到源 BS发送的 7|载更新请求消息, 经判断为更改 SO到电路数 据, MSCe根据源 BS发送来的承载格式参数以及 MGW能力和资源情况确定 本次会话可以改变 SO到电路数据, 向源 BS发送携带有承载参数的承载更新 请求消息; (cl )源 BS收到 MSCe下发的承载更新请求消息后, 根据其中的承 载格式确定本次会话为使用电路数据, 建立相应的信道资源并与对应的 MS协 商后, 发送承载更新响应消息给该 MSCe; ( dl ) 源 BS根据当前的 RC配置和 MS请求的 RC配置决定是否换 RC , 如是则进行换一次换 RC切换。 第二步, MSCe与目的 BS完成承载格式的协商, 具体为: (a2 )通话过程 中, MSCe收到源 BS发送的承载更新请求消息,经判断为更改 SO到电路数据, MSCe根据源 BS发送来的承载格式参数以及 MGW能力和资源情况确定本次 会话可以改变 SO到电路数据, 向源 BS发送携带有承载参数的承载更新请求 消息, 在收到源 BS发送的承载更新响应消息后, MSCe向目的 BS发送携带有 所述 7|载参数的承载更新请求消息; ( b2 )目的 BS收到 MSCe下发的 载更新 请求消息后, 根据其中的承载格式确定本次会话需更改承载格式为电路数据, 建立相应的信道资源并与对应的 MS协商后,发送承载更新响应消息给该 MSCe;
( c2 ) 目的 BS收到 MSCe下发的承载更新请求消息后, 根据其中的承载格式 确定本次会话需更改承载格式为电路数据, 向 MS发送业务请求消息通知 MS 更改 SO到电路数据, MS确定支持电路数据, 在完成相关配置后向目的 BS回 业务响应消息, 接受基站提议的业务配置, 目的 BS收到后, 确定本次会话使 用电路数据编码, 建立相应的信道资源, 给 MS 回业务连接消息, MS向目的 BS 返回业务连接完成消息, 开始使用新的业务配置, 同时向连接的传真机发 送传真音通知用户对端通话用户已更改 SO 为电路数据; ( d2 ) 目的 BS 收到 MSCe下发的承载更新请求消息后, 根据当前的 RC配置和承载更新请求消息 中 SO对应的 RC配置决定是否换 RC , 如是则进行换一次换 RC切换。 第三步: MSCe根据其与源 BS协商的承载格式和其与目的 BS协商的承 载格式分配相应的 IWF资源, 完成 SO更改到电路数据 MSS侧内部的相关工 作, 包括新资源的分配, 旧资源的释放, 电路数据链路的连接等。 第四步: SO更改到电路数据完成后, 源 BS和目的 BS将从空口接收的电 路数据分别按照确定的载荷格式完成用户业务(User Traffic )层的封装, 然后 分别封装成 RTP分组, 通过 IP网络发送给 MGW。 第五步: 在完成 SO到电路数据的改变后, MGW接收到源 BS和目的 BS 发送的 RTP分組, 并将接收到的 RTP分组解出 User Traffic用户数据, 然后按 照载荷格式处理, 获取电路数据净荷, 由 IWF模块进行电路数据处理, 再将处 理后的电路数据按照确定的载荷格式完成 User Traffic层的封装, 然后封装成 RTP分组通过 IP网络发送给对端 BS。 第六步: 源 BS和目的 BS将接收到的 RTP分组解出 User Traffic用户数 据, 并按照载荷格式处理 User Traffic用户数据, 获取对应的电路数据净荷, 然 后通过空口发送给对应的 MS。 实例 2 如图 11所示, 源 BS和目的 BS遵照标准 IOS5.0协议完成承载参数的协 商, 协商完成后***进入正常语音通话, 在通话过程中, 目的 BS收到 MS过 来的要求改变 SO到电路数据的业务连接请求, 确定 BS侧支持 MS所要求的 SO, 目的 BS通过 BS侧的承载更新倚求消息 ( Bearer Update Required )携带 A2p承载参数完成承载格式的协商, 源 BS通过 MSS侧的承载更新请求消息 ( Bearer Update Request )携带 A2p承载参数完成承载格式的协商。 具体而言, 包括以下处理: 第一步: 目的 BS与 MSCe完成 7|载格式的协商。 具体为: (al )通话过 程中, 目的 BS在 BS侧的承载更新请求消息中将所需使用的电路数据的承载 格式参数发送给 MSCe , 携带的 A2p 载特定格式参数 ( A2p Bearer Format-Specific Paramaters )中的 RTP 载荷类型与承载格式 ID确定了电路数据 编码帧格式和 RTP载荷类型的对应关系; 假定源 BS确定本次会话需要使用的 编码为电路数据, 则使用保留的承载格式 ID值, 取值范围为 8〜15, 这里 定 为 9, 编码名称是电路数据, 栽荷类型为动态承载类型值, 帧格式使用电路数 据的载荷格式; ( bl ) MSCe收到目的 BS发送的承载更新请求消息, 经判断为 更改 SO到电路数据, MSCe根据目的 BS发送的承载格式参数以及 MGW能力 和资源情况确定本次会话可以改变 SO到电路数据, 向目的 BS发送携带有承 载参数的承载更新请求消息; (cl ) 目的 BS收到 MSCe下发的承载更新请求消 息后, 根据其中的承载格式确定本次会话为使用电路数据, 建立相应的信道资 源并与对应的 MS协商后, 发送承载更新响应消息给该 MSCe; ( dl ) 目的 BS 根据当前的 RC配置和 MS请求的 RC配置决定是否换 RC, 如果是, 则进行换 一次换 RC切换。 第二步: MSCe与源 BS完成承载格式的协商。具体为:( a2 )通话过程中, MSCe收到目的 BS发送的承载更新请求消息, 经判断为更改 SO到电路数据, MSCe根据源 BS发送的承载格式参数以及 MGW能力和资源情况确定本次会 话可以改变 SO到电路数据, 则向目的 BS发送携带有承载参数的承载更新请 求消息, 在收到目的 BS过来的承载更新响应消息后, MSCe向源 BS发送携带 有承载参数的承载更新婧求消息; ( b2 )源 BS收到 MSCe下发的承载更新请求 消息后, 根据其中的承载格式确定本次会话需更改承载格式为电路数据, 建立 相应的信道资源并与对应的 MS协商后, 发送 载更新响应消息给该 MSCe; ( c2 ) 源 BS收到 MSCe下发的承载更新请求消息后, 根据其中的承载格式确 定本次会话需更改承载格式为电路数据, 向 MS发送业务倚求消息通知 MS更 改 SO到电路数据, MS确定支持电路数据, 在完成相关配置后向目的 BS回业 务响应消息, 接受基站提议的业务配置, 源 BS收到后, 确定本次会话使用电 路数据编码, 建立相应的信道资源, 给 MS回业务连接消息, MS给源 BS回业 务连接完成消息, 开始 4吏用新的业务配置, 同时向连接的传真机发送传真音通 知用户对端通话用户已更改 SO为电路数据; ( d2 )源 BS收到 MSCe下发的承 载更新请求消息后,根据当前的 RC配置和承载更新请求消息中 SO对应的 RC 配置决定是否换 RC, 如是则进行换一次换 RC切换。 后续的处理与实例 1 中的第三步至第六步的处理相同, 为此,省略对其重 复描述。 实例 3 如图 12所示, 源 BS和目的 BS遵照标准 IOS5.0协议完成 载参数的协 商, 协商完成后***进入正常语音通话, 在通话过程中源 BS和目的 BS都收 到 MS发送的要求改变 SO到电路数据的业务连接请求, 确定 BS侧支持 MS 所要求的 SO,源 BS和目的 BS均通过 BS侧的承载更新请求消息( Bearer Update Required )携带 A2p承载参数完成承载格式的协商,源 BS和目的 BS通过 MSS 侧的承载更新请求消息 (Bearer Update Request )携带 A2p承载参数完成承载 格式的协商。 具体而言, 包:^以下处理: 第一步: 源 BS与 MSCe完成承载格式的协商。 具体为: (al )通话过程 中, 源 BS在 BS侧的承载更新请求消息中将所需使用的电路数据的承载格式 参数发送给 MSCe,携带的 A2p承载特定格式参数 ( A2p Bearer Format-Specific Paramaters ) 中的 RTP载荷类型与承载格式 ID确定了电路数据编码帧格式和 RTP载荷类型的对应关系; ( bl ) MSCe收到源 BS发送的承载更新请求消息 , 经判断为更改 SO到电路数据, MSCe根据源 BS发送来的 载格式参数以及 MGW能力和资源情况确定本次会话可以改变 SO到电路数据,向源 BS发送携 带有所述承载参数的承载更新请求消息; (cl )源 BS收到 MSCe下发的承载更 新请求消息后, 根据其中的承载格式确定本次会话为使用电路数据, 建立相应 的信道资源并与对应的 MS协商后, 发送承载更新响应消息给该 MSCe; ( dl ) 源 BS根据当前的 RC配置和 MS请求的 RC配置决定是否换 RC, 如果是, 则 进行换一次换 RC切换。 第二步: 目的 BS与 MSCe完成承载格式的协商。 具体为: 2 )通话过 程中, 目的 BS在 BS侧的承载更新请求消息中将所需使用的电路数据的承载 格式参数发送给 MSCe , 携带的 A2p 承载特定格式参数 ( A2p Bearer Format-Specific Paramaters )中的 RTP载荷类型与^载格式 ID确定了电路数据 编码帧格式和 RTP载荷类型的对应关系;( b2 ) MSCe收到目的 BS过来的;^载 更新请求消息, 经判断为更改 SO到电路数据, MSCe根据源 BS发送来的承载 格式参数以及 MGW能力和资源情况确定本次会话可以改变 SO到电路数据, 则向目的 BS发送携带有所述承载参数的承载更新请求消息; ( c2 ) 目的 BS收 到 MSCe下发的承载更新请求消息后, 根据其中的承载格式确定本次会话为使 用电路数据, 建立相应的信道资源并与对应的 MS协商后, 发送承载更新响应 消息给该 MSCe; ( d2 ) 目的 BS根据当前的 RC配置和 MS清求的 RC配置决 定是否换 RC, 如果是, 则进行换一次换 RC切换。 后续的处理与实例 1 中的第三步至第六步的处理相同, 为此,省略对其重 复描述。 值得注意的是, 上述各个实例中提及的扩展 ID和扩展参数的数值仅是示 例性的, 本发明可以使用其他扩展 ID及扩展参数的数值。 当然, 本发明还可有其他多种实现方式, 例如, 当主叫为电路数据起呼, 被叫接收采用语音改变 SO到电路数据时, 源 BS通过连接管理业务请求消息 或之后的指派完成消息将该 BS支持的电路数据承载格式参数发送给 MSCe, 目的 BS通过 BS侧的承载更新请求消息将所需使用的电路数据的承载格式参 数发送给 MSCe; 同理, 当主叫采用语音改变 SO到电路数据, 被叫为电路数 据接收时, 源 BS通过 BS侧的承载更新请求消息将所需使用的电路数据的承 载格式参数发送给 MSCe, 目的 BS通过寻呼响应消息或之后的指派完成消息 将所支持的电路数据承载格式参数发送给 MSCe。 可以将上述实例的源 BS和目的 BS完成承载格式的协商的方式自由组合 而得到新的实施例。 以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领 域的技术人员来说, 本发明可以有各种更改和变化。 凡在本发明的 4青神和原则 之内, 所作的任何修改、 等同替换、 改进等, 均应包含在本发明的保护范围之 内。

Claims

权 利 要 求 书
1. 一种改变业务选项到电路数据的方法, 其特征在于, 包括以下步骤: 第一步骤: 在会话过程中, 移动台通知源基站和 /或目的基站改变 业务选项到电路数据;
第二步骤: 所述源基站和 /或目的基站与移动交换子***进行改变 业务选项到电路数据的协商,并通过†办商确定本次会话的 7?^载格式参数; 第三步驟: 在与所述移动交换子***协商成功后, 所述源基站和 / 或目的基站与所述移动台进行二次业务协商; 以及
第四步骤: 在与所述移动台协商成功后, 所述源基站和 /或目标基 站将电路数据按照确定的载荷格式完成用户界面业务层封装, 然后将封 装成的实时传输协议分组传输到对端基站。
2. 根据权利要求 1所述的方法, 其特征在于, 在所述第一步骤中, 在所述 会话的建立过程中, 所述源基站和 /或目的基站确定本次通话使用的编码 为语音, 在所述第二步骤中, 在确定的所述承载格式参数中, 承载格式 ID值为语音呼叫 7 载格式 ID。
3. 根据权利要求 1所述的方法, 其特征在于, 在所述第一步骤中, 当所述 电路数据为 G3传真时, 所述移动台根据传真机的 CNG/CED音决定是 否更改所述业务选项到 G3传真。
4. 根据权利要求 1所述的方法, 其特征在于, 在所述第一步骤中, 当所述 电路数据为异步数据时, 所述移动台根据对端主叫号码来判断是否更改 所迷业务选项到异步数据。
5. 根据权利要求 1所述的方法, 其特征在于, 在所述第二步骤中, 所述源 基站和 /或目的基站确定本次会话的承载格式参数的处理包括以下步骤: 步骤 A: 所述源基站和 /或目的基站向移动交换中心模拟器发送承 载更新请求消息, 在所述承载更新请求消息中携带有需要使用的电路数 据的承载格式参数; 步驟 B: 所述移动交换中心模拟器根据所述承载格式参数以及媒体 网关的能力确定本次会话可以改变业务选项到电路数据, 并向所述源基 站和 /或目的基站发送携带有所述承载格式参数的指派请求消息; 以及 步骤 C: 响应于所述指派请求消息,所述源基站和 /或目的基站确定 本次会话使用电路数据编码, 建立相应的信道资源, 在于相应的移动终 端协商后, 向所述移动交换中心模拟器发送承载更新相应消息。
6. 根据权利要求 5所述的方法, 其特征在于, 在所述步骤 A中, 所述承载 更新请求消息中还承载有电路数据所使用的业务选项信息。
7. 根据权利要求 6所述的方法, 其特征在于, 所述业务选项信息通过扩展 域来携带, 所述扩展域包括承载格式参数种的扩展 ID、 扩展长度、 和扩 展参数。
8. 根据权利要求 1所述的方法, 其特征在于, 在所述第三步 中, 所述源 基站和 /或目的基站与所述移动台进行二次业务十办商, 以通知所述移动台 更改业务选项到电路数据, 或通知所述移动台基站侧已完成更改业务选 项到电路数据的协商。
9. 根据权利要求 1所述的方法, 其特征在于, 在所述第三步骤中, 基站子 ***将当前的 RC配置和所述移动台请求的 RC配置进行比较, 并且在 二者不一致的情况下进行 RC切换。
10. 根据权利要求 1所述的方法, 其特征在于, 在所述第三步驟中, 如果是 语音转传真的发起方, 则所述二次业务协商过程包括以下步骤:
步骤 A: 所述源基站和 /或目的基站向所述移动台发送业务连接消 息, 同意所述移动台在业务请求消息中提出的业务配置; 以及
步骤 B: 所述移动台向所述源基站和 /或目的基站返回业务连接消 息, 开始使用新的业务配置。
11. 根据权利要求 1 所述的方法, 其特征在于, 在所述第三步驟中, 如果不 是语音转传真的发起方, 则所述二次业务切、商过程包括以下步驟: 步驟 A: 所述源基站和 /或目的基站向所述移动台发送业务请求消 息, 将请求的电路数据需要使用的业务配置发送给所述移动台; 步骤 Β: 所述移动台在根据接收到的业务配置参数以及所述移动台 本身的能力确定本次会话可以改变业务项目到电路数据的情况下, 向所 述源基站和 /或目的基站发送业务响应消息,接受所述源基站和 /或目的基 站发送的业务配置;
步骤 C: 响应于所述业务响应消息,所述源基站和 /或目的基站确定 本次会话使用的电路数据编码, 建立相应的信道资源, 并向所述移动台 发送业务连接消息; 以及
步驟 D: 响应于所述业务连接消息, 所述移动台向所述源基站和 / 或目的基站返回业务连接完成消息, 开始使用新的业务配置。 根据权利要求 1所述的方法, 其特征在于, 进一步包括以下步顰:
第五步骤: 所述源基站和 /或目的基站接收到所述实时传输协议分 组后 , 解出用户面业务层用户数据并按照载荷格式处理, 获取电路数据 净荷。
PCT/CN2006/003398 2006-12-13 2006-12-13 Procédé de transformation d'option de service en données de circuit WO2008071034A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US12/518,080 US8199694B2 (en) 2006-12-13 2006-12-13 Method for switching service option to circuit data
CN2006800565373A CN101558670B (zh) 2006-12-13 2006-12-13 改变业务选项到电路数据的方法
PCT/CN2006/003398 WO2008071034A1 (fr) 2006-12-13 2006-12-13 Procédé de transformation d'option de service en données de circuit

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2006/003398 WO2008071034A1 (fr) 2006-12-13 2006-12-13 Procédé de transformation d'option de service en données de circuit

Publications (1)

Publication Number Publication Date
WO2008071034A1 true WO2008071034A1 (fr) 2008-06-19

Family

ID=39511231

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2006/003398 WO2008071034A1 (fr) 2006-12-13 2006-12-13 Procédé de transformation d'option de service en données de circuit

Country Status (3)

Country Link
US (1) US8199694B2 (zh)
CN (1) CN101558670B (zh)
WO (1) WO2008071034A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10798041B2 (en) * 2018-07-25 2020-10-06 Verizon Patent And Licensing Inc. Systems and methods for classification and/or transmission of messages
US10979892B2 (en) * 2019-07-30 2021-04-13 At&T Intellectual Property I, L.P. Efficient device capabilities enquiry for 5G or other next generations wireless network

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6990119B2 (en) * 2001-02-07 2006-01-24 Qualcomm, Inc. Method and apparatus to facilitate a transparent service option transition
CN1801874A (zh) * 2005-01-07 2006-07-12 华为技术有限公司 实现语音业务向传真业务切换的方法
CN1870710A (zh) * 2005-10-20 2006-11-29 华为技术有限公司 一种固定网络到移动网络发送传真的方法

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6393008B1 (en) * 1997-12-23 2002-05-21 Nokia Movile Phones Ltd. Control structures for contention-based packet data services in wideband CDMA
KR100270376B1 (ko) * 1998-08-19 2000-11-01 윤종용 무선데이터 서비스장치의 기능시험을 위한 회선 호 발생기 및기능시험 방법
US6091969A (en) * 1998-08-21 2000-07-18 Motorola, Inc. Method and apparatus for inband signaling control of vocoder bypass
KR100294704B1 (ko) * 1998-12-15 2001-07-12 서평원 데이터통신시스템및데이터통신운용방법
KR100400734B1 (ko) * 1999-12-30 2003-10-08 엘지전자 주식회사 Wll 시스템에서 팩스 서비스 방법
KR20020023579A (ko) * 2000-09-23 2002-03-29 구자홍 이동통신 서비스 옵션 변경에 따른 교환국에 보고 방법
US20020098865A1 (en) * 2000-12-04 2002-07-25 Nortel Networks Limited Method and system to transition from a facsimile communications session to a voice communications session
US6708031B2 (en) * 2000-12-05 2004-03-16 Nokia Corporation Session or handoff methods in wireless networks
US6760602B2 (en) * 2000-12-22 2004-07-06 Motorola, Inc. Mobile communication system with improved base station control
US20020085514A1 (en) * 2000-12-28 2002-07-04 Illidge William E. Method for switching between high-speed packet data service option and non-high-speed circuit switched or packet data service options without disrupting user data flow
US6914891B2 (en) * 2001-01-10 2005-07-05 Sk Teletech Co., Ltd. Method of remote management of mobile communication terminal data
US7417968B2 (en) * 2002-12-06 2008-08-26 Motorola, Inc. Method and apparatus for improving hard handoffs in CDMA systems
US7586868B2 (en) * 2003-07-14 2009-09-08 Motorola, Inc Method and apparatus for controlling distributed transcoders
KR20050018295A (ko) * 2003-08-16 2005-02-23 삼성전자주식회사 이동통신시스템에서 보코더 선택 방법
US7860046B2 (en) * 2003-12-08 2010-12-28 Motorola Mobility, Inc. Method and apparatus for providing bearer format type information in a cellular communication system
US8660527B2 (en) * 2005-02-17 2014-02-25 Qualcomm Incorporated Control of data call origination based on prior origination attempts

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6990119B2 (en) * 2001-02-07 2006-01-24 Qualcomm, Inc. Method and apparatus to facilitate a transparent service option transition
CN1801874A (zh) * 2005-01-07 2006-07-12 华为技术有限公司 实现语音业务向传真业务切换的方法
CN1870710A (zh) * 2005-10-20 2006-11-29 华为技术有限公司 一种固定网络到移动网络发送传真的方法

Also Published As

Publication number Publication date
US8199694B2 (en) 2012-06-12
CN101558670A (zh) 2009-10-14
US20100316023A1 (en) 2010-12-16
CN101558670B (zh) 2011-07-06

Similar Documents

Publication Publication Date Title
KR100576390B1 (ko) 모드 선택 과정을 제공하는 통신 시스템 및 방법
JP4334802B2 (ja) インターネット・プロトコル移動通信ネットワークの技術分野で呼設定を行うための手法
TWI488533B (zh) 系統架構演進/長程演進之行動性管理及會議管理
CN101816206B (zh) 针对服务gprs支持节点使用电路交换承载的***间切换
WO2017071309A1 (zh) 视频通话***、装置和方法
WO2018230728A1 (ja) 端末装置、基地局装置、通信方法、および、集積回路
WO2006025789A1 (en) Method and system for frame size adaptation in real-time transport protocol
WO2008098501A1 (fr) Procede, appareil et systeme de reglage de relevement gsm
JP7199798B2 (ja) 端末装置、基地局装置、通信方法、および、集積回路
WO2013155981A1 (zh) 数据分流的方法和装置
CN110771256A (zh) 终端装置、基站装置、通信方法以及集成电路
WO2009067912A1 (fr) Procédé et dispositif de commutation pour mettre en œuvre une commutation
CN101431514A (zh) 用于在电信***中建立语音承载的方法和装置
WO2011044802A1 (zh) 能力信息上报方法和装置
WO2008071034A1 (fr) Procédé de transformation d'option de service en données de circuit
WO2006026889A1 (fr) Systeme et procede de commande dynamique de debit multimedia dans un systeme ims
WO2009046594A1 (fr) Procédé de négociation de codec entre un réseau sans fil et un réseau central dans un système de télécommunication mobile
KR100414921B1 (ko) 올 아이피 망에서의 핸드오프 방법
CN101166300B (zh) 业务切换方法和***
EP2468048B1 (en) Using a common media gateway node and a coordinated codec by an originating and a terminating call control node
WO2007054020A1 (fr) Méthode pour commuter un service vocal en un service iwf
WO2010102584A1 (zh) 一种基站***内的呼叫切换方法及移动通信***
KR20060009433A (ko) 이동통신 시스템에서 헤더 압축을 이용한 패킷 서비스 방법
WO2010102586A1 (zh) 一种基站***间的呼叫切换方法及移动通信***
JP7271766B2 (ja) 端末装置、基地局装置、通信方法、および、集積回路

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200680056537.3

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 06828316

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2150/KOLNP/2009

Country of ref document: IN

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 12518080

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 06828316

Country of ref document: EP

Kind code of ref document: A1