KR20060067275A - A data forwarding method between legay mobile support domain and system therefore - Google Patents

Abstract

The present invention relates to a traffic processing method and system therefor in a TrFO (Transcoder Free Operation) call in a CDMA LMSD network. The traffic processing method according to the present invention checks transcoding information between mobile switching devices of each packet network. The first process and the second process of processing an RTP packet including a tone and announcement necessary for a call connection between the packet network and the transcoding method of the packet network are the same. And a third step of transferring the header of the RTP packet transmitted between the first media gateway and the second media gateway as it enters the call. The traffic processing system according to the present invention includes mobile switching center emulations for checking transcoding information between packet networks and tones and announcements necessary for call connection of the packet networks. When the RTP packet is received, when the RTP packet is completely processed and the transcoding method of the packet network is the same, when entering a TrFO (Transcoder Free Operation) call, It is characterized by passing the header as it is.

In the present invention, since the TrFO in the LMSD network is transparently transmitted in the RTP traffic processing in the BSC and the MGW, unnecessary overhead incurred during the call processing in the TrFO call when the BSC is entered is greatly reduced.

CDMA, LMSD, TrFO, Transcoder, RTP

Description

A method of data transmission between LSMS and its system {A DATA FORWARDING METHOD BETWEEN LEGAY MOBILE SUPPORT DOMAIN AND SYSTEM THEREFORE}             

1 is a view showing a general LMSD network

2 is a diagram illustrating a header of a general RTP packet.

3 is a diagram illustrating an LMSD network according to a preferred embodiment of the present invention.

4 is a diagram illustrating a signaling signal flow between LMSD networks according to the present invention.

5 is a diagram illustrating an RTP header according to an RTP packet processing method according to an exemplary embodiment of the present invention.

6 is a diagram illustrating a method of processing an RTP packet in a TrFO call according to a preferred embodiment of the present invention.

7 is a flowchart illustrating a method of establishing an RTCP session according to an embodiment of the present invention.

The present invention relates to a legacy mobile station support domain (LMSD) to code division multiple access (CDMA), and in particular, to a traffic processing method in a transcoder free operation (TrFO) call in the LMSD network. And to the system.

3GPP2 is working on standardization to support All-IP in the existing CDMA network. The All-IP Core Network (CN) is composed of two domains, a Multimedia Domain (MMD) network and the LMDS network. The MMD network represents All-IP of the CN network, and the LMSD network is a network for supporting an existing terminal in the evolution process to All-IP.

The LMSD network will now be briefly described. The LMSD network provides a bearer path connection with a Mobile Switching Center emulation (MSCe) for signaling and call control in an existing Mobile Switching Center (MSC) to support an IP network in the existing CDMA network. It was separated into a media gateway (Media GateWay: MGW) for the object. At present, the LMSD network has been performed up to Step 2.

In step 2 of the LMSD network, a transcoder is provided in the MGW and located outside the CDMA2000 radio access network, thereby supporting RTO (Remote Transcoder Operation) and TrFO (TranscoderFree Operation). The RTO is located outside the Radio Access Node (RAN) so that untranslated voice calls can be transmitted through the packet network to obtain a bandwidth gain. Function. The TrFO is a function of improving the transmission efficiency and voice call quality between terminals by passing the transcoder when the transmitting terminal and the receiving terminal use the same vocoder form.

Next, the traffic signal processing will be described using the LMSD network of FIG. 1.

Referring to FIG. 1, first, the existing MSC 111 is divided into an MSCe 107 and an MGW 109. The dotted line shown in the figure represents a path indicating the flow of a paging signal or a control signal, and the solid line indicates a bearer path through which actual data flows. Here, the TrFO call represents a bearer pass between the MS1 101 and the MS2 121. The bearer pass between the transmitting side BSC_O 105 and the receiving side BSC_T 117 uses an IP packet during the bearer pass.

Therefore, since the LMSD network needs to transmit a voice signal through an IP network, communication using the Voice over Internet Protocol (VoIP) technology is performed using the base station controller-originate (BSC_O) 105 and the base station controller-terminate (BSC_T) ( 117). In this case, the voice signal can be transmitted using a real time protocol (RTP).

 The RTP is a protocol introduced for real-time application services in an IP network, and is increasingly used as the IP network integrates all services. By using the RTP protocol, it is possible to guarantee the real time of the voice signal transmission in the packet delivery network between the BSCs 105 and 107 and the MGWs 109 and 115.

In this case, when the IP packet including the RTP packet including the voice signal in the LMSD network enters the TrFO call without passing through the IP network 130, the BSC-O 105, MGW-O 109, and MGW-T ( 113), each network component leading to the BSC-T 117 is adapted to fully handle all of the received RTPs.

Unless the MGWs 109 and 117 perform transcoding, the RTP frame processing of the MGWs 109 and 117 has little meaning, and the RTP processing in the BSCs 105 and 117 has a practical meaning. However, the TrFO call uses resources such as a header processor and a play out buffer in the MGWs 109 and 117 to process the RTP header used for real time playback. Therefore, there is a problem that unnecessary overhead occurs.

Accordingly, an object of the present invention is to provide an RTP packet processing method and system for preventing unnecessary resource waste in TrFO calls of LMSD networks.

Another object of the present invention is to provide an RTP packet processing method and system capable of guaranteeing real time by reducing voice delay as much as possible in a TrFO call of an LMSD network.

Another object of the present invention is to provide a method and system for setting a Real-time Transport Control Protocol (RTCP) that can prevent unnecessary resource waste in TrFO calls of LMSD networks.                         

The RTP processing system in the LMSD according to the present invention for achieving the above object is a Mobile Switching Center Emulation and the first to confirm the transcoding (Transcoding) information between the first packet network and the second packet network and the first Receiving an RTP packet including tones and announcements necessary for a call connection between a packet network and the second packet network, the RTP packet is completely processed and transcoding of the first packet network and the second packet network is performed. If the same method is used to enter a TrFO (Transcoder Free Operation) call that does not use a transcoding method between the first packet network and the second packet network, the RTP packet is transmitted between the first media gateway and the second media gateway. It is characterized by passing the header as it is.

The real time transport control protocol (RTCP) in the LMSD network is characterized by establishing a session with a mobile switch and a base station controller (BSC) of each packet network.

RTP packet processing method of the present invention for achieving the above object is a first process for the mobile switch of each packet network to check the transcoding information between each other and the call connection between the first packet network and the second packet network The second process of processing an RTP packet including tones and announcements necessary for the same process and the transcoding method of the first packet network and the second packet network are the same, between the first packet network and the second packet network. And a third step of transmitting a header of the RTP packet transmitted between the first media gateway and the second media gateway as it enters a TrFO (Transcoder Free Operation) call that does not use a transcoding method. It is done.

The real time transport control protocol (RTCP) in the LMSD network is characterized by establishing a session with a mobile switch and a base station controller (BSC) of each packet network.

DETAILED DESCRIPTION Hereinafter, detailed descriptions of preferred embodiments of the present invention will be described with reference to the accompanying drawings. It should be noted that the same components in the drawings represent the same numerals wherever possible. Specific details are set forth in the following description, which is provided to aid a more general understanding of the invention. In the following description of the present invention, if it is determined that a detailed description of a related known function or configuration may unnecessarily obscure the subject matter of the present invention, the detailed description thereof will be omitted.

In this detailed description, for the convenience of explanation, the RTP packet will be described first in detail, and then the apparatus and method for processing a RTP packet in an LMSD network according to a preferred embodiment of the present invention will be described.

2 is a diagram illustrating a header of the RTP packet.

Referring to FIG. 2, the RTP header has a fixed size of 12 bytes and a payload in which specific information and data are stored is attached to the header according to the multimedia information. V (Version) 301 uses 2 bits as the version field. For reference, since the latest version is 2.0, V always has a value of '2'. Padding (302) is a 1-bit field indicating that the packet contains one or more padding bytes. If the P 302 value is set, padding octets other than the payload 310 portion are included in the end of the packet to form the RTP packet in 32-bit units. Setting the X (extension) 304 bit indicates that exactly one extension header follows the fixed header. CC (CSRC Count) is a 4-bit field indicating the number of Contribute source (CRSC) identifiers in the fixed header. The CRSC is a source of RTP packet streams that contributed to the RTP mixer to make a combined stream.

In this case, the RTP mixer performs the function of receiving the RTP packets transmitted from various sources in the intermediate system and combining them appropriately to create a new type of RTP packet and delivering it to the next system while the RTP packets are transmitted through the network.

Next, M (Maker) 305 represents a frame area for multimedia information in a 1-bit field. That is, it is used to distinguish between voice and image information in the packet. The PT (Payload) field 306 is a 7-bit field that refers to the RTP payload form of the profile defined in RFC 1890 and is interpreted by the application. The profile is assigned a payload type code in payload format and a fixed correspondence. That is, when the PT 306 is '0', it indicates that the audio information is an encoding scheme, has an 800 Hz clock rate, and has one audio channel. Currently 33 payload types are defined.

Sequence Number (SN) 307 has a value that is incremented by one for each packet transmitted as a 16-bit field. The receiving side is used to detect packet loss or to order packets. Therefore, the receiver detects packet loss using this field and restores the packet order. The initial value of the SN 307 is set randomly for security. Timestamp 308 represents the point in time at which the first octet of the RTP packet was sampled. The sampling point is generated from a constantly increasing clock. This is used to synchronize real-time data and calculate jitter. SSRC 309 represents a synchronization source as a 32-bit field. The SSRC value is randomly selected so that two or more synchronization sources having the same SSRC appear in the same RTP session.

Next, an LMSD network according to a preferred embodiment of the present invention will be described.

3 is a view showing an LMSD network according to a preferred embodiment of the present invention. In FIG. 3, the solid line represents the flow of the signaling signal and the solid line represents the flow of the bearer pass through which actual traffic is transmitted. Basically, the received traffic is composed of voice frame / RTP / UDP / IP / L2 / L1.

Referring to FIG. 3, the LMSD network knows whether the received traffic enters a TrFO call by the signaling. If the incoming traffic does not enter the TrFO call, voice is generated between the BSC-O (Base Station Controller-Originate) 303-MGW (Media Gate Way) 307, 311-BSC-O (Base Station Controller-Terminate) 313 You will transcode the frame. However, when the received traffic enters the TrFO call, since no transcoding is performed for the voice frame in the interval, the RTP packet is passed between the MGW-O 307 and the MGW-T 311 without processing the RTP packet. All.

In more detail, the BSC-O (Base Station Controller-Originate) 303 generates a header of the RTP packet to match the voice frame received from the transmitting terminal. Any SSRC (Synchronization SouRCe) is used to represent the RTP source in the RTP header. When generating the RTP packet, an initial value of an RTP header such as a timestamp and a sequence number (SN) is determined, and the SN value and the timestamp are increased with each packet generation.

The header of the UDP port is generated using the UDP port number determined in the call setup procedure. In the same way, an IP header is created using the IP address determined in the call setup procedure. The voice traffic generated in this way is transmitted to the MGW-O 307, which forms the RTP session A 403 with the BSC-O 303.

The MGWs 307 and 311 generate an RTP / UDP / IP header by generating a tone and announcement necessary to connect a call before entering the TrFO call. Here, the RTP packet is generated with an initial value of any SSRC, time stamp, and SN. For example, when the MGW-O 307 generates RTP traffic and sends it to the BSC-T 313, the MGW-T 309 receives the RTP traffic to process the header of the RTP traffic and has a new RTP header. An RTP packet is generated and transmitted to the BSC-T 313. On the contrary, even when the MGW-T 309 generates traffic and transmits the traffic to the BSC-O 303, the MGW-T 309 generates an RTP packet including the tone or announcement broadcast and transmits the RTP packet to the BSC-O 303.

However, when the MGWs 307 and 311 enter the TrFO call, the MGWs 307 and 311 perform processing on the UDP / IP header without full processing of the RTP header and without modification of the RTP header. That is, the MGWs 307 and 311 replace the existing header with the new UDP / IP header having the source IP address, the UDP port number and the destination IP address, and the UDP port number. 303, 313).

The BSC-T 313 receives the RTP packet generated by the MGW-O 307 before entering the TrFO, performs a synchronization, and reproduces the RTP traffic to the receiving terminal. When entering a TrFO call, actual voice traffic is generated and transmitted from the BSC-O 303. In this case, the MGW-O 303 and the MGW-T 309 deliver the RTP packet without processing the RTP packet. The BST-T 313 receives an RTP packet having any SSRC generated by the BSC-O 313. In this case, since the BSC-T 313 becomes the SSRC of the RTP stream of the BSC-O 303, the BSC-T 313 processes differently from the RTP packet before entering the TrFO call. In other words, it processes the RTP header by synchronizing the packet as a new packet.

Next, the data processing method in the LMSD network will be described using the signaling signal flowchart of FIG. 4. 4 is a diagram illustrating a signaling signal flow in the LMSD network of the present invention. In FIG. 4, the apparatus that performs the same function in FIG. 3 is denoted by the same reference numeral. And since the terminology in the description of FIG. 4 is shown in detail in the LMSD network step 2 (STEP2) in 3GPP2, the description of the term will be omitted here.

Referring to FIG. 4, the BSC-O 303 first transmits a CM Service Request signal to the MSCe 305 to establish a call. The MSCe 305 then transmits a MGW-O. In order to know the codec information of 307 and the like, an add signal ADD is transmitted to the MGW-O 307. Receiving the ADD signal, the MGW-O 307 transmits a response signal (Reply) for informing its codec information to the MSCe 305 again. Upon receiving the information of the MGW-O 307, the MSCe 305 determines the codec information and the location of transcoding supported by the BSC-O 303 and transmits an assignment request message. At the same time, the MSCe 305 transmits an INVITE signal to the sender side information and the codec information to the receiver side MSCe 311.

Upon receiving the invite signal, the MSCe 311 transmits a paging request message (Page Request) to inform the receiving base station controller-terminate (BSC-T) 331 of the call coming. After confirming the paging request message, the BSC-T 313 transmits a paging response message (Page Response) to the MSCe 311 again. After that, the MSCe 311 transmits the ADD signal to the receiving Media MGW-T (Media Gate Way-Terminate) to inform the transmitting codec information and the ADD signal to obtain the codec information of the receiving Media MGW-T (Media Gate Way-Terminate). Send. Upon receiving the ADD signal, the MGW-T 309 transmits a response signal indicating the codec information to the MSCe 311. Upon receiving the response signal, the receiving MSCe 311 transmits a 183 session processing message (183 Session Process) to send the receiving side information and the codec information to the transmitting MSCe 305. Upon receiving the message, the transmitting MSCe 305 transmits a 200 OK message, which is a response signal. Here, a bearer pass for transmitting a tone and announcement between the BSC-O 303 and the BSC-T 313 is set. The data processing method in the bearer pass for the tone and the announcement is described later in FIG. 5 and will be omitted here.

If the transcoding methods of the transmitting side and the receiving side are the same, the MSCe 305 and the MSCe 311 receive information on the receiving side of the MGW-O 305 and the MGW-T 313 to enter a TrFO call, respectively. It transmits a MODIFY signal to inform the selected codec information. After receiving the response signal REPLY from each of the MGWs 307 and 309, a bearer pass for establishing a TrFO call is established.

The following describes the RTP packet processing method according to the present invention on the bearer pass for tone and announcement broadcast before entering the TrFO call and on the bearer pass after entering the TrFO call.

First, the method of processing the RTP packet on the bearer path for the tone and the announcement will be described with reference to FIG. 5. 5 is a view showing an example of the RTP header according to the RTP packet processing method of the present invention. Herein, the apparatus performing the same function in FIG. 3 among the reference numerals of FIG. 5 is denoted by the same reference numeral.

In FIG. 5, reference numeral 401 denotes a bearer pass for the tone and the announcement. Referring to FIG. 5, a session is established between the BSC-O 303, the MGW-O 307, the MGW-T 309, and the BSC-T 313. Each RTP session is a RTP session. Session A (403), RTP session B (405), and RTP session C (407).

The RTP session A 403 generates a header of the RTP packet so that the BSC-O 303 matches the voice frame received from the transmitting terminal. The voice traffic generated in this way is transmitted to the MGW-O 307, which forms the RTP session A 303 with the BSC-O 303. In the RTP session A 403, the RTP header has a sequence number (SN) of '5', '6', '7', a timestamp of '43', '44', '45', and SSRC. Assume that has 178.

Upon receiving the RTP packet, the MGW-O 307 performs synchronization with reference to the header of the RTP packet. The RTP packet is stored in a play out buffer, and a new SN, time stamp, and SSRC shown in the RTP session B 305 are newly generated and transmitted to the MGW-T 309. Accordingly, in the RTP session B 405, a sequence number (SN) of '15', '16', '17', a timestamp of '321', '322', '323', and SSRC of '211' Changes to After receiving the RTP packet, the MGW-T 309 performs the same operation as that of the MGW-O 307 and regenerates the header shown in the RTP session C 307 to newly generate the BSC-T 331. Send the created RTP packet. Here again, the SN, timestamp, and SSRC values are changed in the RTP session C (407).

Next, the method of processing an RTP packet on a bearer pass in a TrFO call will be described. 6 is a diagram illustrating a method of processing an RTP packet in the TrFO call according to a preferred embodiment of the present invention.

As shown in FIG. 6, when entering the TrFO call, the BSC-O 303 generates an RTP packet 409 using voice traffic transmitted from a transmitting terminal. An example of the generated RTP header is RTP. Shown in session A 411. After receiving the RTP packet, the MGW-O 307 transmits the received RTP packet to the MGW-T 309 without processing the received RTP packet. Therefore, there is no change in the RTR header in RTP session B 413. Also, the MGW-T 309 transmits the received RTP packet to the BSC-T 313 without processing the received RTP packet, so that the BSC-T 313 receives the RTP packet transmitted from the BSC-O 303. do. The RTP packet processing method of the present invention does not use a resource such as a header processor, a playout buffer, etc. for processing the header of the RTP packet when the MGWs 307 and 309 are TrFO calls, thereby enabling efficient processing. Do.

In this case, when the RTP is used, the Real-time Transport Control Protocol (RTCP) is also used. The RTCP is an auxiliary protocol of the RTP that the end points of the RTP use to exchange information about the quality of each other. . That is, the RTCO performs a function of monitoring a quality of service (QOS) required for maintaining and managing the RTP session, congestion control, inter-media synchronization, source identification, and session size estimation.

Therefore, the following describes the operation of the RTCP configuration method according to the present invention using FIG. 7.

7 is a flowchart illustrating a method of establishing an RTCP session according to an embodiment of the present invention.

Referring to FIG. 7, when entering the TrFO call, the first MSCe 305 transmits an RTCP ON signal to the BSC-O 303. Then, when the BSC-O 303 receives the RTCP ON signal, the BSC-O 303 transmits an Ack signal that is a response signal. Upon receiving the A-order signal, the MSCe 305 also sends an RTCP ON signal to the receiving MSCe 311. When the MACe 211 receiving the RTCP ON signal also sends an RTCP ON signal to the receiving side BSC-T 313 and receives an Ack signal, an RTCP session is established. That is, in the present invention, the RTCP session is opened only in the MSCe 305 and 311 and the BSCs 303 and 313. This is because, in the case of TrFO, the MGWs 307 and 309 do not process substantial RTP packets.

In the LMSD network, even when a media gateway controller (MGC) (not shown) requests jitter, an RTP packet loss, or a delay with respect to the RTP session, the RTP packets in the MGWs 307 and 309. Since BSC is not processed, BSC information alone is sufficient. Even in the case of billing issues, the information of the BSC, which is the terminal that actually handles the RTP session, is sufficient.

Meanwhile, in the detailed description of the present invention, specific embodiments have been described, but various modifications are possible without departing from the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be determined not only by the scope of the following claims, but also by the equivalents of the claims.

As described above, when the present invention is applied, since the TrFO in the LMSD network is transparently transmitted in the RTP traffic processing in the BSC and the MGW, in the call processing process upon entry into the TrFO call according to the entry into the BSC. This greatly reduces unnecessary overhead.

Claims (4)

A first packet network having a first Media Gate and a Mobile Switching Center Emulation for receiving an audio signal from at least one mobile terminal to generate an Internet Protocol (IP) packet including an RTP packet. And a second packet network interworking with the first packet network including a second MGW and a second mobile switching device, wherein the legacy mobile station support domain (LMSD) comprises: A first step in which the mobile switch of each packet network confirms transcoding information of each other; A second process of processing an RTP packet including tones and announcements necessary for call connection between the first packet network and the second packet network; When the first packet network and the second packet network have the same transcoding method, when entering a TrFO (Transcoder Free Operation) call that does not use a transcoding method between the first packet network and the second packet network, And a third step of transmitting the header of the RTP packet as it is transmitted between the second media gateways. The method of claim 1, And a real time transport control protocol (RTCP) in the LMSD network establishes a session with a mobile switch and a base station controller (BSC) of each packet network. Legacy Mobile Station Support Domain comprising a first packet network for receiving an audio signal from at least one mobile terminal and generating an IP packet including an RTP packet and a second packet network for receiving the IP packet. LMSD) data transmission system, Mobile Switching Center Emulations for checking transcoding information between the first packet network and the second packet network; When receiving the RTP packet including the tone and announcement necessary for the call connection between the first packet network and the second packet network, the RTP packet is completely processed and the first packet network and the second packet network are received. When the transcoding method of the same is the same when entering a TrFO (Transcoder Free Operation) that does not use a transcoding method between the first packet network and the second packet network is transmitted between the first media gateway and the second media gateway The system, characterized in that for transmitting the header of the RTP packet as it is. The method of claim 3, wherein The real time transport control protocol (RTCP) in the LMSD network establishes a session with a mobile switch and a base station controller (BSC) of each packet network.

Images