CN100542177C - A negotiation method and system - Google Patents

Abstract

The invention discloses a kind of redundant ability machinery of consultation.This method is: transmitting terminal sends and carries frame message with redundant ability label; Receiving terminal detects the redundant ability label position after receiving described frame message; Receiving terminal returns the relative set frame message with redundant ability label to transmitting terminal.Accordingly, the present invention discloses a kind of redundant ability negotiating system.The present invention can realize the redundant ability negotiation under to the smaller situation of existing network influence.

Description

A negotiation method and system

technical field

The present invention relates to the field of communication technology, in particular to a method and system for negotiating redundant capabilities.

Background technique

With the development of traditional communication networks, the Internet and mobile communication networks, the integration of various networks is an inevitable trend. The next generation network NGN (Next Generation Nerwork) uses the Internet Protocol IP (Internet Protocol) packet switching network as the core network to control and carry Separation, various access technologies coexist, and a new generation network that integrates various existing networks.

IP-based service transmission can use a variety of encoding methods, such as the G.729 and G.711 protocols defined by the ITU-T (International Telecommunication Union Telecommunications Standardization Sector) of the International Telecommunication Union. The data rate in the G.711 protocol is 64Kbit/s. In theory, data and fax services can be transmitted. However, due to the unreliability of IP transmission, if packet loss occurs, data transmission and fax cannot be normally realized, resulting in G. .711 redundant (G.711Redundant, referred to as "G.711Red") codec scheme. G.711Red codec actually performs redundancy processing on G.711 RTP messages according to the RFC2198 protocol, which has high reliability due to the introduction of the redundancy mechanism.

Generally, in network service transmission, it is necessary to know the service support capability of the other party, that is, perform capability negotiation before data transmission. At present, in the prior art, capability negotiation is performed through a signaling plane, and specifically, the negotiation may be performed through BICC signaling. The media gateway controller MGC (Media Gateway Controller) configures whether the media gateway MGW (Media Gateway) supports G.711 redundancy through the configuration file, and then the MGC extends the codec (Codec) type in the BICC signaling to G.711red, and the call is established , the MGC sends G.711red as a codec to another MGC through Bicc signaling. If the other MGC supports this redundancy, it returns a response message carrying the G.711red type identifier, indicating that the codec negotiation is successful. , if not supported, the response message does not carry the G.711red type identifier, indicating that the negotiation is unsuccessful.

However, after the MGC extends the codec (Codec) type in the BICC signaling to G.711red, it needs to notify the MGW of the corresponding codec type, and then the MGW performs codec according to the codec type. The way for the MGC to notify the MGW is through the H.248 interface. At present, the H.248 interface protocol has G.711, adaptive multi-rate AMR and other voice codec description methods, but there is no G.711red description method, so it is necessary to expand the H. 248 for the description of the G.711red codec, so that the MGC can notify the MGW. Therefore, in the existing technology, there is a compatibility problem in negotiating redundancy capabilities through signaling plane extension, that is, in order to support G.711red, extensions between MGCs and between MGCs and MGWs are required, which has a great impact on the existing network. It will be more complicated and troublesome when deploying and implementing it.

Contents of the invention

The technical problem to be solved by the present invention is to provide a negotiation method and system to realize redundancy capability negotiation with relatively little impact on the existing network.

The purpose of the present invention is achieved through the following technical solutions:

The present invention provides a negotiation method, comprising: the sending end sends a frame message carrying a redundancy capability identifier related to data redundancy according to the user plane protocol; the receiving end detects the redundancy capability identifier bit after receiving the frame message; the receiving end In the returned frame message, a redundancy capability identifier related to data redundancy is correspondingly set, and then sent to the sending end, wherein the sending end and the receiving end are media gateways.

Optionally, the redundancy capability identifier is set in the idle extension field or the idle field of the initialization frame.

Optionally, the redundancy capability identifier is set in an idle extension field or an idle field of the data frame.

Optionally, the data frame includes PDU type 0 or PDU type 1.

Optionally, the setting is set in the idle extension field or any bit of the idle field.

Optionally, the redundancy capability identifier uses different symbols to indicate that redundancy is supported or not supported.

The present invention correspondingly provides a negotiation system, including: a sending end and a receiving end, the sending end and the receiving end are media gateways; wherein, the sending end is used to send a redundancy capability identifier carrying data redundancy according to a user plane protocol the frame message; the receiving end is used to detect the redundancy capability flag after receiving the frame message; correspondingly set the redundancy capability flag related to data redundancy in the returned frame message and then send it to the sending end.

Optionally, the sending end includes a first extension unit and a sending unit; wherein, the first extension unit is configured to set a redundant capability identifier in an idle extension field or idle field of an initialization frame or a data frame; the sending unit uses to send the frame message after the redundancy capability flag is set by the first extension unit.

Optionally, the receiving end includes a detection unit, a second extension unit, and a response unit; wherein the detection unit is configured to detect a redundant capability flag after receiving the frame message; the second extension unit is configured to The idle extension field or the idle field of the initialization frame or the data frame is correspondingly set with a redundancy capability flag; the response unit is used to return the frame message after the redundancy capability flag is set by the second extension unit to the sending end.

It can be seen from the above technical scheme that:

First of all, the existing technology performs redundancy capability negotiation through the signaling plane, and there is a compatibility problem. Extensions between MGCs, and between MGCs and MGWs are required, which has a great impact on the existing network. However, the present invention performs redundancy through the user plane Redundant capability negotiation, specifically, the sending end sends a frame message carrying a redundant capability identifier; the receiving end detects the redundant capability identifier bit after receiving the frame message; Therefore, it is only necessary to extend the MGW so that the MGWs can use the user plane protocol message to perform redundancy capability negotiation;

Further, the redundancy capability identifier carried in the frame message may be set in the idle extension field or the idle field of the initialization frame, or may be set in the idle extension field or the idle field of the data frame, and may be set in the idle extension field or the idle field Any bit of the idle field can be set. When the sending end or the receiving end supports redundancy, the redundancy capability flag can be set to 1. When redundancy is not supported, the redundancy capability flag can be set to 0.

Description of drawings

Fig. 1 is a flowchart of the negotiation method of the present invention;

Fig. 2 is a flowchart of Embodiment 1 of the negotiation method of the present invention;

Fig. 3 is a schematic diagram of the format of the UP protocol data unit type 14 after the negotiation method of the present invention is extended;

Fig. 4 is a flow chart of Embodiment 2 of the negotiation method of the present invention;

5 is a schematic diagram of the format of the UP protocol data unit type 0 after the negotiation method of the present invention is extended;

6 is a schematic diagram of the format of the UP protocol data unit type 1 after the negotiation method of the present invention is extended;

Fig. 7 is a schematic structural diagram of the negotiation system of the present invention;

FIG. 8 is a schematic structural diagram of the sending end in the negotiation system of the present invention;

FIG. 9 is a schematic structural diagram of a receiving end in the negotiation system of the present invention.

Detailed ways

The purpose of the present invention is to provide a method for negotiating redundant capabilities in a wireless network, and to be well compatible with existing networks. This method mainly utilizes the corresponding idle extended field or idle field in the user plane UP protocol message to carry out capability negotiation, so the participation of the signaling plane and the media gateway controller MGC are not required, only the media gateway MGW is required. expand and negotiate.

The UP protocol is a user plane protocol used in the 3GPP R4 core network, which is used to negotiate user plane functions, including UP initialization, time adjustment, rate control and other functions. When initializing, it carries corresponding voice codec information, UP mode, version and other information.

The present invention will be described in detail below in conjunction with the accompanying drawings and specific embodiments.

It should be noted that the sending end and receiving end devices in the content described below refer to the MGW.

Please refer to Fig. 1, which is a flowchart of the negotiation method of the present invention, including steps:

A1. Send a frame message carrying a redundancy capability identifier;

Set the redundancy capability flag in the idle extension field in the frame of the UP protocol message, that is, use the last bit in the idle extension field as a redundancy bit, and set the redundancy bit to 1, indicating that the local end supports redundancy. If the redundancy bit is 0, it means that the local end does not support redundancy. It should be noted that any bit in the idle extension field can be used as a redundant bit. The frame mentioned here can be an initialization frame or a data frame.

In addition, the above operations may also be performed in the idle field in the frame of the UP protocol message.

After setting the redundancy capability identifier, the sending end sends a frame message carrying the redundancy capability identifier to the receiving end.

A2. The receiving end detects the redundancy capability flag after receiving the frame message;

After receiving the frame message, the receiving end detects the corresponding bit of the frame message, that is, the idle extension field or the free field. If the redundant bit is 1, it is considered that the sending end supports redundancy. If the redundant bit is 0, it is considered to be sending end does not support redundancy.

A3. The receiving end returns the frame message correspondingly set with the redundancy capability flag to the sending end.

If the receiving end also supports redundancy, in the frame message to be returned, the redundancy bit of the idle extension field or the idle field is also set with a redundancy capability flag, that is, the redundancy bit is set to 1, indicating that the local end supports redundancy , and then returned to the sender. In this way, both the sending end and the receiving end know that the other party supports redundancy, and subsequent messages can use redundant messages.

It should be noted that if the receiving end does not support redundancy, the redundancy bit identifier in the received frame message is ignored, and the idle extension field or the idle field redundancy bit is set to 0 in the returned frame message.

Please refer to Figure 2, which is a flowchart of Embodiment 1 of the present invention, specifically including:

B1. Send the frame message carrying the redundancy capability identifier in the initialization frame;

Before sending the frame message, the frame message is extended, that is, the idle extension field of the initialization frame is extended, and the last bit of the idle extension field in the initialization frame is used as a redundant bit, and the redundant bit is set to 1, indicating that the original end supports redundancy. It should be noted that other bits of the idle extension field may also be used as redundant bits.

In addition, the above operations may also be performed in the idle field in the initialization frame.

The initialization frame of UP refers to UP protocol data unit type 14. Please refer to Figure 3. The UP protocol data unit type 14 mainly includes three parts: Frame Control Part, Frame Checksum part, and Frame payload part. The frame control part includes protocol data unit type PDU Type (=14), response Ack/Nack (=0.I.e.Procedure), protocol data unit frame number PDU Type 14 Frame Number, mode version Iu UP Mode version, process indication Procedure Indicator ( =0); the frame check part includes Header CRC, payload cyclic redundancy check Payload CRC; the frame payload part includes supported IU UP mode version number (bit pattern) IuUP Mode Versions supported(bitmap ), data unit type Data PDU type, spare domain Spare, spare extension domain Spare Extension, redundant RED. The spare field Spare generally has a fixed length. In FIG. 3, the last bit of the idle extension field is used as a redundancy bit RED to identify the redundancy capability, and other bits of the idle extension field may also be used as redundancy bits. It should be noted that the spare field Spare in FIG. 3 can also be used for expansion, that is, select any bit in the spare field Spare as the redundancy bit RED to identify the redundancy capability.

The above redundancy capability can be 5ms packet redundancy capability in G.711 UP support mode, or 20ms packet redundancy capability in G.711 UP support mode. In addition, other codec types can also be used, such as clear mode (clear mode), or the T.38 codec type for transmitting fax services, and only need to add the corresponding codec identifier.

It should be noted that the present invention does not limit which redundancy capabilities are supported by the sending end or the receiving end, and how to distinguish and express these redundancy capabilities, and may be indicated in other ways.

After the sending end sets the redundancy capability identifier in the initialization frame, it sends a frame message carrying the redundancy capability identifier to the receiving end.

B2. The receiving end detects the redundancy capability flag after receiving the frame message;

After receiving the frame message, the receiving end detects the idle extension field or idle field of the initialization frame. If the redundancy bit is 1, it is considered that the sending end supports redundancy. If the redundancy bit is 0, it is considered that the sending end does not support redundancy. .

B3. The receiving end returns to the sending end the frame message correspondingly set with the redundancy capability flag.

If the receiving end also supports redundancy, in the frame message to be returned, the redundancy bit of the idle extension field or idle field of the initialization frame will also be set with a redundancy capability flag, that is, the redundancy bit is set to 1, indicating that the local end supports redundant, and then returned to the sender. In this way, both the sending end and the receiving end know that the other party supports redundancy, and subsequent messages can use redundant messages.

It should be noted that if the receiving end does not support redundancy, the redundant bit identifier in the received frame message is ignored, and the redundant bit of the idle extension field or idle field of the initialization frame is set to 0 in the returned frame message , so that redundancy is not turned on.

In addition, for the sake of protocol compatibility, if the subsequent UP protocol uses the idle extension field or idle field of the initialization frame, you can use the UP protocol version to identify whether the extended function can be performed, or according to the configured UP protocol version, know whether it can Use idle extended domains or idle domains as negotiation domains. That is to say, if the subsequent UP protocol version is added, and the method of performing capability negotiation through the idle extension field or idle field is added, it can be identified through the UP protocol version, but if the subsequent UP protocol version does not increase, but uses this function, it cannot be identified through the UP protocol version.

Please refer to Figure 4, which is a flow chart of Embodiment 2 of the present invention, specifically including:

C1. Send the frame message carrying the redundancy capability identifier in the data frame;

Before sending the frame message, the frame message is extended, that is, the idle extension field of the data frame is extended, and the last bit of the idle extension field in the data frame is used as a redundant bit, and the redundant bit is set to 1, indicating that the end supports redundancy. It should be noted that other bits of the idle extension field may also be used as redundant bits.

In addition, the above operations may also be performed in the idle field in the data frame.

Specifically, the idle extension field or idle field of UP protocol data unit type 0 or UP protocol data unit type 1, namely PDUtype0 and PDU Type1, can be used for corresponding extension. The difference between PDU Type0 and PDUType1 is that PDU Type0 has CRC check. Because UP’s PDU Type0 and PDUType1 are used for data transmission, not UP’s control frames, when using UP’s PDU Type0 and PDU Type1 for capability negotiation, you need to wait until the other party’s data frame arrives to know whether the other party supports the corresponding ability.

Please refer to Figure 5 and Figure 6, UP protocol data unit type 0 and UP protocol data unit type 1 also mainly include three parts: Frame Control Part, Frame Checksumpart, and Frame payload part.

In Fig. 5, the frame control part of the UP protocol data unit type 0 includes the protocol data unit type PDUType (=0), the protocol data unit frame number Frame Number, the frame quality classification information FQC, and the radio access bearer RAB subflow combination indication RFCI; The frame check part includes header cyclic redundancy check HeaderCRC and payload cyclic redundancy check Payload CRC; the frame payload part includes payload field Payload Fields, padding, spare extension field Spare Extension, and redundancy RED. In FIG. 5, the last bit of the idle extension field is used as the redundancy bit RED to identify the redundancy capability, and other bits of the idle extension field may also be used as the redundancy bits.

In Fig. 6, the frame control part of UP protocol data unit type 1 comprises protocol data unit type PDUType (=1), protocol data unit frame number Frame Number, frame quality classification information FQC, RAB subflow combination indication RFCI; Frame checking part Including header cyclic redundancy check Header CRC, spare field Spare; frame payload part includes payload field Payload Fields, padding, spare extension field SpareExtension, redundant RED. In FIG. 6, the last bit of the idle extension field is used as the redundancy bit RED to identify the redundancy capability, and other bits of the idle extension field may also be used as the redundancy bits. It should be noted that the spare field Spare in FIG. 6 can also be used for expansion, that is, select any bit in the spare field Spare as the redundancy bit RED to identify the redundancy capability.

The above redundancy capability can be 5ms packet redundancy capability in G.711 UP support mode, or 20ms packet redundancy capability in G.711 UP support mode. In addition, other codec types can also be used, such as clear mode (clear mode), or the T.38 codec type for transmitting fax services, and only need to add the corresponding codec identifier.

It should be noted that the specific redundancy capabilities supported by the sending end or the receiving end, and how to differentiate and represent these redundancy capabilities are not limited by the present invention.

After the sending end sets the redundancy capability identifier in the data frame, it sends a frame message carrying the redundancy capability identifier to the receiving end.

C2. The receiving end detects the redundancy capability flag after receiving the frame message;

After receiving the frame message, the receiving end detects the free extension field or free field of the data frame, that is, UP protocol data unit type 0 or UP protocol data unit type 1. If the redundancy bit is 1, it is considered that the sending end supports redundancy. If the redundancy bit is 0, it is considered that the sender does not support redundancy.

C3. The receiving end returns the frame message correspondingly setting the redundancy capability flag to the sending end.

If the receiving end also supports redundancy, then in the frame message that is about to be returned, the redundancy bit of the idle extension field or the idle field of the data frame, that is, the UP protocol data unit type 0 or the UP protocol data unit type 1, is also set to be redundant accordingly. Capability identification, that is, setting the redundancy bit to 1 indicates that the local end supports redundancy, and then returns it to the sending end. In this way, both the sending end and the receiving end know that the other party supports redundancy, and subsequent messages can use redundant messages.

It should be noted that if the receiving end does not support redundancy, the redundant bit identifier in the received frame message is ignored, and the data frame, that is, the UP protocol data unit type 0 or the UP protocol data unit The type 1 idle extension field or the redundancy bit of the idle field is set to 0, so that the redundancy function will not be turned on.

The method and embodiment of the redundancy capability negotiation of the present invention have been introduced in detail above. It should be noted that the present invention utilizes but is not limited to the above-mentioned initialization frame or data frame for extension and redundancy capability negotiation, and can also be used in other UP Some frames carry capability negotiation indications, and the principle is the same.

The negotiation system of the present invention is introduced below. Please refer to FIG. 7 , which is a schematic structural diagram of the negotiation system of the present invention.

The negotiation system 10 in FIG. 7 includes a sending end 100 and a receiving end 200 . Among them, the sending end 100 is used to send the frame message carrying the redundant capability identification; the receiving end 200 is used to detect the redundant capability identification bit after receiving the frame message; and return the corresponding set redundant capability identification to the sending end 100 frame message.

Please refer to FIG. 8 , which is a schematic structural diagram of the sending end in the negotiation system of the present invention.

The sending end 100 includes a first extension unit 101 and a sending unit 102; wherein, the first extension unit 101 is configured to set a redundant capability identifier in an idle extension field or an idle field of an initialization frame or a data frame; the sending unit 102 is configured to Send the frame message after the redundancy capability flag is set by the first extension unit 101.

Before the sending end 100 sends the frame message to the receiving end 200, the frame message is extended, that is, the first extension unit 101 extends the initialization frame or the idle extension field or the idle field of the data frame, and the idle extension field or the idle field The last bit of is used as a redundancy bit, and setting the redundancy bit to 1 indicates that the local end supports redundancy. It should be noted that, the idle extension field or other bits of the idle field may also be used as redundant bits.

The initialization frame of UP refers to UP protocol data unit type 14. The UP protocol data unit type 14 mainly includes a frame control part Frame Control Part, a frame check part Frame Checksum part, and a frame payload part Frame payload part total three parts, wherein contains spare domain Spare and idle extension domain Spare Extension, the present invention is to The idle extension field or the idle field is extended, and any bit is used as a redundant bit, and different symbols are used to indicate whether redundancy is supported or not.

The data frame of UP can specifically be UP protocol data unit type 0 or UP protocol data unit type 1, that is, PDU type0 or PDU Type1. PDU Type0 and PDU Type1 also mainly include frame control part Frame Control Part, frame checking part Frame Checksum part, frame payload part Framepayload part total three parts, wherein contain spare domain Spare and idle expansion domain SpareExtension, the present invention is wherein The idle extension field or the idle field is extended, and any bit in it is used as a redundant bit, and different symbols are used to indicate support or non-support of redundancy. Because PDUType0 and PDU Type1 of UP are used for data transmission, not UP control frames, so when using PDU Type0 and PDU Type1 of UP for capability negotiation, you need to wait until the other party’s data frame arrives to know whether the other party supports the corresponding ability.

After the sending end 100 sets the redundancy capability identifier in the initialization frame or data frame by the first extension unit 101 , the sending unit 102 sends a frame message carrying the redundancy capability identifier to the receiving end 200 .

Please refer to FIG. 9 , which is a schematic diagram of the structure of the receiving end in the negotiation system of the present invention.

The receiving end 200 includes a detection unit 201, a second extension unit 202, and a response unit 203; wherein, the detection unit 201 is used to detect the redundant capability identification bit after receiving the frame message; the second extension unit 202 is used to The idle extension field or the idle field of the initialization frame or the data frame correspondingly sets the redundancy capability flag; the response unit 203 is used to return the frame message after the redundancy capability flag is set by the second extension unit 202 to the sending end 100 .

After the receiving end 200 receives the frame message, the detection unit 201 detects the idle extension field or the idle field of the initialization frame or the data frame. If the redundant bit is 1, it is considered that the sending end 100 supports redundancy. If the redundant bit is 0 , it is considered that the sending end 100 does not support redundancy.

If the receiving end 200 also supports redundancy, then the second extension unit 202 will initialize the idle extension field of the frame or the data frame or the redundant bit of the idle field in the frame message to be returned by the second extension unit 202. If the redundancy bit is set to 1, it indicates that the local end supports redundancy. Then the response unit 203 returns the frame message with the redundant capability flag set to the sending end 100 . In this way, both the sending end 100 and the receiving end 200 know that the other party supports redundancy, and then subsequent messages can use redundant messages. It should be noted that if the receiving end 200 does not support redundancy, then ignore the redundant bit identifier in the received frame message, and the second extension unit 202 will initialize the frame or data frame in the frame message to be returned. The idle extension field or the redundancy bit of the idle field is set to 0, so that the redundancy function will not be turned on.

The above is a detailed introduction to a negotiation method and system provided by the present invention. In this paper, specific examples are used to illustrate the principle and implementation of the present invention. The description of the above embodiments is only used to help understand the method and methods of the present invention. Its core idea; at the same time, for those of ordinary skill in the art, according to the idea of the present invention, there will be changes in the specific implementation and application scope. limit.

Claims (9)

1. A negotiation method, characterized in that it comprises: The sending end sends a frame message carrying a redundancy capability identifier related to data redundancy according to the user plane protocol; After receiving the frame message, the receiving end detects the redundancy capability identification bit; The receiving end correspondingly sets a redundancy capability identifier related to data redundancy in the returned frame message and sends it to the sending end, wherein the sending end and the receiving end are media gateways. 2. The negotiation method according to claim 1, characterized in that: The redundancy capability identifier is set in the idle extension field or the idle field of the initialization frame. 3. The negotiation method according to claim 1, characterized in that: The redundancy capability identifier is set in the idle extension field or the idle field of the data frame. 4. The negotiation method according to claim 3, characterized in that: The data frame includes PDU type 0 or PDU type 1 . 5. The negotiation method according to claim 2 or 3, characterized in that: The setting is set in the free extension field or any bit of the free field. 6. The negotiation method according to any one of claims 1 to 5, characterized in that: The redundancy capability identifier uses different symbols to indicate that redundancy is supported or not. 7. A negotiation system, characterized by comprising: A sending end and a receiving end, wherein the sending end and the receiving end are media gateways; wherein, The sending end is configured to send a frame message carrying a redundancy capability identifier related to data redundancy according to a user plane protocol; The receiving end is configured to detect the redundancy capability flag after receiving the frame message; correspondingly set the redundancy capability flag related to data redundancy in the returned frame message and send it to the sending end. 8. The negotiation system according to claim 7, characterized in that: The sending end includes a first extension unit and a sending unit; wherein, The first extension unit is configured to set a redundancy capability identifier in an idle extension field or an idle field of an initialization frame or a data frame; The sending unit is configured to send the frame message after the redundancy capability flag is set by the first extension unit. 9. The negotiation system according to claim 7, characterized in that: The receiving end includes a detection unit, a second extension unit and a response unit; wherein, A detection unit, configured to detect the redundancy capability flag after receiving the frame message; The second extension unit is configured to correspondingly set the redundancy capability identifier in the idle extension field or the idle field of the initialization frame or the data frame; The response unit is configured to return the frame message after the redundancy capability flag is set by the second extension unit to the sending end.

Images