WO2007128217A1 - Method of internet protocol(ip) message transmission, negotiated bandwidth saving capability and saving network bandwidth - Google Patents

Method of internet protocol(ip) message transmission, negotiated bandwidth saving capability and saving network bandwidth Download PDF

Info

Publication number
WO2007128217A1
WO2007128217A1 PCT/CN2007/001414 CN2007001414W WO2007128217A1 WO 2007128217 A1 WO2007128217 A1 WO 2007128217A1 CN 2007001414 W CN2007001414 W CN 2007001414W WO 2007128217 A1 WO2007128217 A1 WO 2007128217A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
message
receiver
sender
capability
Prior art date
Application number
PCT/CN2007/001414
Other languages
English (en)
French (fr)
Inventor
Cheng Chen
Jiangping Feng
Peng Li
Original Assignee
Huawei Technologies Co., Ltd.
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 Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to EP07720987.2A priority Critical patent/EP1940093B1/en
Priority to CN2007800003277A priority patent/CN101317404B/zh
Priority to ES07720987.2T priority patent/ES2558020T3/es
Publication of WO2007128217A1 publication Critical patent/WO2007128217A1/zh
Priority to US12/235,876 priority patent/US8311060B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/15—Flow control; Congestion control in relation to multipoint traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/18—End to end
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/38—Flow control; Congestion control by adapting coding or compression rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/801—Real time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/824—Applicable to portable or mobile terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164—Adaptation or special uses of UDP protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18—Negotiating wireless communication parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]

Definitions

  • the present invention relates to a technique for transmitting data in an Internet Protocol (IP) bearer network of a communication system, and more particularly to a method and system for transmitting IP packets, negotiating bandwidth saving capability, and saving network bandwidth.
  • IP Internet Protocol
  • a data bearer In a communication system, such as an IP bearer network of a Wide Code Division Multiple Access (WCDMA) system, data needs to be carried in a packet, for example, a data bearer is transmitted in an IP packet.
  • 1 is a schematic diagram of a network architecture of a WCDMA system in the prior art.
  • a dotted line indicates a signaling path, and a solid line indicates a packet transmission path carrying data.
  • the Nb interface and the Iu interface negotiate the user plane parameters through the User Protocol (UP, User Protocol), and the mobile service control center server (MSCserver) uses the H.248 protocol via the Mc.
  • the interface controls the MGW.
  • the network architecture can also be applied to networks such as fixed softswitch systems, CDMA systems, or fixed network inter-media systems (IMS, IP Multimedia Subsystem).
  • the protocol stack carrying the IP packet shown in FIG. 2 is constructed: a data layer including a data to be transmitted, a Real-Time Transport Protocol (RTP) layer, and a user data temple.
  • UDP User Datagram Protocol
  • IP layer is available in IP version 4 (IPv4) or IP version 6 (IPv6).
  • the protocol used by the link layer is the Ethernet (ETHER) protocol and the POS, which performs cyclic redundancy check (CRC) verification on IP packets.
  • the RTP layer and the UDP layer are described in detail below.
  • the UDP layer is a single data-oriented transport protocol layer that uses port numbers to reserve its respective data transmission channels for different sessions.
  • the sender sends UDP data through the source port of the data transmission channel, and the receiver transmits the data through the data.
  • the destination port of the channel receives data.
  • the UDP layer does not provide reliability, that is, the sender sends UDP data, but does not guarantee that UDP data can reach the receiver.
  • the RTP layer is a protocol layer that provides end-to-end transport services for data with real-time characteristics, such as interactive voice or images.
  • the RTP layer is defined to operate in a one-to-one or one-to-many transmission with the goal of providing synchronization of time and data streams.
  • the RTP layer usually uses the UDP layer to transmit data.
  • For an RTP data two ports are used: one is set to RTP, and the other is set to Real-Time Transport Control Protocol (RTCP).
  • RTCP Real-Time Transport Control Protocol
  • the RTP layer itself does not provide a reliable transport mechanism for RTP packets transmitted in sequence, nor does it provide flow control or congestion control, which relies on RTCP to provide these services.
  • the sequence number in the IP packet allows the receiver to reconstruct the IP packet sequence sent by the sender. It is also used to determine the location of the IP packet sent by the sender in the entire IP packet sequence. The timestamp in the IP packet can be used. To calculate network transmission delay and jitter.
  • FIG. 3 is a schematic structural diagram of an RTP header of an IP packet, showing the format and content of the RTP header, where the usage of each domain value is described as: Version (V, Version): Can be version 2; Padding (P, Padding) ): If the IP message has an additional padding byte, set this flag; Extend (X, extension): Indicates an extension header after the RTP header (currently unused:); Contributor count ( CC , Contributor count ): The number of contributing source identifiers in an IP packet, up to 15 contributing source identifiers are allowed; Mark (M, Marker): The meaning is defined by the session, used to establish a boundary for dividing different data in the IP packet; (PT, Payload type): The service type of the data in the IP packet; The sequence number (SN, Sequence number): identifies the sequence number of the IP packet, which is 16 bits in length; the timestamp (timestamp): reflects an IP packet.
  • the sampling time of the first byte of data is 16 bits;
  • the synchronization source Authenticator identifies the synchronization source of the IP packet;
  • CSRC list identifies all contributing sources contained in the payload of the IP packet, the number of CSRC lists being given by the CC.
  • FIG. 4 is a schematic diagram of a structure of an IP packet carrying data compressed by using an Adaptive Multi Rate (AMR) protocol.
  • AMR Adaptive Multi Rate
  • the UP data packet of the UP layer includes a control packet and a data packet.
  • the control packet includes an initialization packet, a rate control packet, a time calibration packet, and an error event packet.
  • the UP data packet has two types. That is, PDU TypeO and PDU Typel, as shown in Figures 5a and 5b.
  • the UP data packet of the UP layer includes a control part, a detection part and a payload part, wherein, in the detecting part, the PDU TypeO performs CRC calibration on the UP header and the compressed data of the compressed data; The PDU Typel only performs CRC check on the UP header of the compressed data.
  • the whole process includes two parts: the first part performs bandwidth negotiation of the IP packet, and the second part transmits the IP packet.
  • the two sections are described in detail below.
  • the sender of the IP packet and the receiver of the IP packet need to determine the type of the IP packet that the other party transmits or that the other party wants to transmit. In this case, a bandwidth saving capability negotiation process is required. Each type of bandwidth saving capability corresponds to the type of an IP packet. After the sender of the IP packet and the receiver of the IP packet negotiate the bandwidth saving capability, the two parties determine the type of the transmitted IP packet.
  • the current negotiation process is as follows: The initiator of the IP packet sends a bandwidth saving capability supported by the IP packet to the receiver of the IP packet. The receiver of the packet determines whether it supports the bandwidth saving capability sent by the initiator of the IP packet.
  • the response message of the successful negotiation is sent to the initiator of the IP packet, and the negotiation succeeds; otherwise, the packet is sent to the IP packet.
  • the initiator sends a response message that the negotiation is unsuccessful, and the negotiation fails or the negotiation process is initiated again.
  • the bandwidth saving capability negotiation process of the IP packet has the following disadvantages:
  • the sender of the IP packet sends only one bandwidth saving capability supported by the sender to the receiver of the IP packet, which may cause negotiation failure or renegotiation.
  • the process in turn, causes waste of communication system resources.
  • the bandwidth saving capability that the sender of the IP packet can support is 0 and 1, but only the bandwidth saving capability 0 can be sent to the receiver of the IP packet, and the bandwidth saving capability supported by the receiver of the IP packet is 1 Causes negotiation failure or renegotiation process.
  • the bandwidth saving capability of the IP packet is not defined by using the H.248 protocol, such as the bandwidth saving capability of the IP packet in the non-tunnel state of the WCDMA system circuit domain.
  • the type of IP packet can be used to transmit data according to the negotiated bandwidth saving capability, so that the determined type of IP packet is used to transmit data.
  • IP 4 types of texts.
  • IP packets are currently the most commonly used.
  • the first type of IP packet uses the structure shown in Figure 3, including the compressed IP header and the compressed data, that is, the static load.
  • the Internet task group provides a variety of IP packet header compression standards, and compresses the IP packet headers of one session, that is, the IP header, the UDP header, and the RTP header.
  • IP packet header that remains unchanged or rarely changed. Some information changes, but the difference between these two IP packets changes is constant.
  • Type information is called stable information.
  • the sender will carry the message with stability information.
  • the IP packet of the IP packet header is sent to the receiver. Afterwards, the sender sends only the IP packet carrying the IP packet header with the change information to the receiver. If the stability information changes during the session, the sender needs to send the IP packet carrying the IP packet header with the stable information to the receiver again.
  • the receiver reassembles the IP packet header of each IP packet received in the conference according to the received stability information and the change information.
  • the IP packet of the IP packet type is used to transmit data.
  • the first disadvantage is that if the IP packet carrying the IP packet header with the stable information is lost or damaged, the receiver cannot be in the session. If the IP address of the IP packet is correctly updated, the two parties cannot communicate correctly. Therefore, a mechanism must be provided to detect whether the receiver receives the IP packet carrying the IP packet header with stable information. If the receiver does not receive the packet, the receiver does not receive the IP packet. The message can be sent to the sender to send again, but the round-trip time in the communication system affects the transmission efficiency of the IP packet. Second, it can only be used for multiple sessions and cannot be reused for multiple sessions. Because the IP packet header of the IP packet is compressed, the IP packet with the compressed IP packet header cannot pass the router that does not support IP header compression.
  • the second IP packet type adopts the structure shown in FIG. 6.
  • the IP packet uses a multiplexing header technology and an RTP compression technology, that is, a multiplexing header is added to each IP sub-message, and is used in the RTP layer. Compression technology.
  • the multiplexer header multiplexes multiple IP sub-messages in multiple sessions with the same source IP address and destination IP address in one IP packet, and the link layer, IP layer, and UDP layer formats are unchanged.
  • the destination port number in the UDP header is a fixed value in an IP packet that includes multiple IP sub-messages.
  • the source port number in the UDP header has no meaning.
  • a multiplexing header is encapsulated for each IP sub-packet, and the multiplexing header indicates the destination UDP port number of the IP sub-packet and the packet length.
  • the RTP compression technique in the IP sub-message achieves the purpose of reducing the length of the RTP layer by reducing or deleting certain fields in the RTP layer.
  • the length of some fields can be shortened, such as timestamps and serial numbers, and some fields are in some It is not required in the communication system networking environment. For example, in the WCDMA system network, fields such as P, M, CC, X, and CSRC in the RTP header are useless and can be deleted. After the field in the RTP header is deleted or shortened, the RTP header is compressed.
  • IP packets of the IP packet type to transmit data also has disadvantages: First, when the IP packet adopts the multiplexing header technology, the multiplexing header in each IP sub-packet is not carried. The information of the party is such that the receiver receiving the IP packet cannot determine the validity of each IP sub-packet in the IP packet, and there is a problem of reliability and security. As an example, as shown in Figure 7, first, the address is 10.110.100.100, the terminal 1 with the port 5000 and the address is 10.110.200.200, and the terminal 2 with the port 6000 establishes a bidirectional connection. The two terminals can send each other.
  • the two terminals are deleted after the transmission of the message, and the terminal 1 is successfully deleted, but the terminal 2 is not deleted for some reason, and becomes the hanged terminal; finally, the terminal 1
  • the IP address and port number are assigned to subsequent terminals. Assume that it is assigned to terminal 3. It establishes a two-way connection with terminal 4 of IP address 10.110.200.200 and port 5000, and sends and receives IP packets to each other, but hangs at this time. Terminal 2 still sends an IP packet to the IP address 10.110.100.100, port 5000, so that terminal 3 receives the IP packet from the two terminals, and the IP packet from 10.110.200.200/5000 is legal, but from 10.110.
  • IP packet of the .200.200/6000 is illegal and needs to be discarded. If the IP sub-message in the sent IP packet does not contain the source information, the receiver does not have any IP packets in IP packets legitimacy sub-judge, if the judge does not, are considered to be the legitimate child IP packets, it would have an impact on call quality, such as to generate crosstalk phenomenon.
  • the field of the IP sub-message is too short.
  • the maximum length of the IP sub-message is 255.
  • the length of the IP sub-message cannot be identified.
  • the static load length in the IP sub-message may be More than 255 bytes, this multiplexer technology cannot be applied.
  • the U header needs to be CRC-checked, but 'actually in the IP packet.
  • the link layer has performed CRC check on the IP packet to ensure the correctness of the transmitted data. If the CRC check is still performed in the UP header, the network bandwidth of the communication system is lost, and the pair is improved. Equipment processing capacity requirements. Summary of the invention
  • the embodiment of the invention provides a method and a system for transmitting IP packets, which can solve the problem that the negotiation bandwidth saving capability is easy to fail or easy to re-negotiate.
  • the embodiment of the invention further provides a method and a system for negotiating bandwidth saving capability, which can solve the problem that the negotiation bandwidth saving capability is easy to fail or easy to re-negotiate.
  • the embodiment of the invention further provides a method for guaranteeing the reliability of transmitting a message, which can ensure the reliability and security of the transmitted message.
  • the embodiment of the invention further provides a method for saving network bandwidth, which can save network bandwidth and resources of the IP bearer network in the communication system.
  • An internet protocol IP packet transmission method includes the bandwidth saving capability negotiation process of the IP packet and the IP packet transmission process, wherein the bandwidth saving capability negotiation process of the IP packet is:
  • the sender sends one or more bandwidth saving capabilities supported by the sender to the receiver.
  • the receiver selects one bandwidth saving capability from one or more bandwidth saving capabilities sent by the sender according to the bandwidth saving capability supported by the receiver, and sends the bandwidth saving capability to the sender.
  • the sender determines the type of the IP packet used for transmitting the data according to the bandwidth saving capability selected by the received receiver.
  • the transmission process of IP packets is as follows: After the sender constructs an IP packet carrying the transmission data by using the determined IP packet type, the sender sends the IP packet to the receiver.
  • a method of negotiating bandwidth saving capability comprising:
  • the sender sends one or more bandwidth saving capabilities supported by the sender to the receiver.
  • the receiver selects one bandwidth saving capability from one or more bandwidth saving capabilities sent by the sender according to the bandwidth saving capability supported by the receiver, and sends the bandwidth saving capability to the sender.
  • the receiver After the receiver receives the bandwidth saving capability selected by the receiver, it determines the bandwidth saving capability that is used.
  • a method for guaranteeing reliability of transmitting a message comprising:
  • the data to be transmitted by the sender is sent to the receiver in an IP packet, and the IP packet is a multiplexed IP packet, including at least one IP sub-packet having a multiplex header, where the IP sub-message
  • the multiplexer is provided with a source identifier that identifies the sender information, or/and an identifier that identifies the number of bytes used to indicate the length of the IP sub-message, and an identifier that identifies the length of the IP sub-message.
  • the receiver After receiving the multiplexed IP address, the receiver determines the sender according to the source identifier, and determines the identifier of the number of bytes used by the identifier to indicate the length of the IP sub-packet and the identifier of the identifier of the IP sub-packet. The length of the sub-message in the multiplexed message.
  • a method of saving network bandwidth comprising:
  • the data to be transmitted by the sender is sent to the receiver in an IP packet, and the IP packet includes an UP data packet, and the UP data packet includes the compressed data and the UP header, and the UE data packet is not processed.
  • the CRC check of the transmitted data and the CRC check of the UP header, the UP data message does not perform the CRC check of the transmitted data and the CRC check of the UP header.
  • a system for transmitting IP packets includes a sender and a receiver, where the sender is configured to send one or more bandwidth saving capabilities supported by the receiver to the receiver according to the received bandwidth selected by the receiver.
  • the receiver is configured to select one bandwidth saving capability from one or more bandwidth saving capabilities sent by the sender according to the bandwidth saving capability supported by the receiver, and send the bandwidth saving capability to the sender.
  • a system for negotiating bandwidth capability includes a sender and a receiver, where the sender is configured to send one or more bandwidth saving capabilities supported by the receiver to the receiver, according to the received bandwidth saving of the receiver
  • the capability determines the type of IP packet used to transmit the data
  • the receiver is configured to select one bandwidth saving capability from one or more bandwidth saving capabilities sent by the sender according to the bandwidth saving capability supported by the receiver, and send the bandwidth saving capability to the sender.
  • the embodiment of the present invention improves the format adopted by the two parts of the IP packet transmission process, that is, the bandwidth saving capability negotiation part and the IP packet carrying the transmitted data.
  • the embodiment of the present invention extends the bandwidth saving capability of the UP initialization message or the SDP bearer bandwidth saving capability, and can carry multiple bandwidth saving capabilities, unlike in the prior art, each negotiation process can only Carrying a bandwidth saving capability not only solves the problem that the negotiation bandwidth saving capability is easy to fail or is easy to renegotiate, but also solves the problem that the negotiation bandwidth saving capability method only adopts UP.
  • the multiplexer header technology and the RTP compression technology are still used, and the source identifier is added to the multiplexer header, and the receiver is configured to recover the IP sub-messages of the IP packet according to the received IP packet.
  • the source identifier in the header is used to determine the source of the IP sub-message, and the security and reliability are detected to ensure the reliability and security of the transmission; the length of the standard IP sub-packet is increased by more than 255 bytes in the multiplexing header;
  • the CRC check is not performed on the UP data packet using the compressed data, which saves the network bandwidth and resources of the IP bearer network in the communication system.
  • the method and system for transmitting IP packets the method and system for negotiating bandwidth saving capability, and the method and system for saving network bandwidth save the network of the IP bearer network in the communication system Bandwidth and resources.
  • FIG. 1 is a schematic diagram of a network architecture of a prior art WCDMA
  • FIG. 2 is a schematic structural diagram of a protocol stack carrying an IP packet in the prior art
  • FIG. 3 is a schematic structural diagram of an RTP header of a prior art IP packet
  • FIG. 4 is a schematic diagram of a structure of an IP packet that is compressed by the AMR protocol in the prior art
  • FIG. 5a is a schematic diagram of a format of a PDU TypeO of the UP layer data packet in the prior art
  • FIG. 5b is a PDU Typel of the UP layer data packet of the prior art.
  • Figure 6 is a schematic diagram showing the structure of an IP packet using the multiplexer header technology and the RTP technology in the prior art
  • Figure 7 is a schematic diagram of an embodiment in which the IP packet constructed by the multiplexer header technology is not reliable in the prior art;
  • FIG. 8 is a flowchart of a method for transmitting an IP packet according to an embodiment of the present invention.
  • FIG. 9 is a flowchart of a method for negotiating a bandwidth saving capability of an IP packet by using an H.248 protocol and an SDP according to an embodiment of the present invention.
  • FIG. 10 is a flowchart of a method for negotiating a bandwidth saving capability of an IP packet by using an IPBCP and an SDP according to an embodiment of the present invention
  • FIG. 11 is a flowchart of a method for negotiating a bandwidth saving capability of an IP packet by using a SIP and an SDP according to an embodiment of the present invention
  • FIG. 12 is a flowchart of a method for negotiating a bandwidth saving capability of an IP packet by using an UP according to an embodiment of the present invention
  • FIG. 13 is a flowchart of a method for negotiating a UP header compression capability by using an UP according to an embodiment of the present invention
  • FIG. 14 is a schematic diagram of a format of a UP layer data packet according to an embodiment of the present invention.
  • FIG. 15 is a schematic diagram of a format of an IP packet after multiplexing according to an embodiment of the present invention.
  • FIG. 16 is an IP diagram of an IP packet header compressed on the basis of multiplexing according to an embodiment of the present invention. Schematic diagram of text format;
  • FIG. 17 is a schematic diagram of a transmission system of an IP packet according to an embodiment of the present invention. Mode for carrying out the invention
  • the embodiment of the present invention provides a method for transmitting an IP packet, as shown in FIG. 8, the network entity involved includes an IP packet sender and
  • the receiver of the IP packet the specific steps are as follows:
  • Step 800 The sender sends more than one bandwidth saving capability supported by the sender to the receiver.
  • More than one bandwidth saving capability can be set as a bandwidth saving capability set.
  • Step 801 After receiving the bandwidth saving capability sent by the sender, the receiver selects one of the bandwidth saving capabilities according to the bandwidth saving capability supported by the receiver, and sends the selected bandwidth saving capability to the sender.
  • the receiver can set the bandwidth saving capability selection policy, so that when more than one bandwidth saving capability sent by the sender has multiple bandwidth saving capabilities supported by the receiver, the receiver can select the supported and most saved (or other settings). Saving) The bandwidth saving capability of the bandwidth is sent to the sender.
  • Step 802 After receiving the bandwidth saving capability selected by the receiver, the sender determines the IP packet type used for transmitting the data, that is, the type of the IP packet corresponding to the bandwidth saving capability selected by the receiver, and sends the acceptance to the receiver. The message of the bandwidth saving capability selected by the receiver.
  • Step 803 The sender has determined the IP packet type used to transmit the data, and after constructing the IP packet carrying the data by using the determined IP packet type, the IP packet is sent to the receiver.
  • the data can be transmitted by using the IP packet shown in FIG. 6, but the IP packet is improved.
  • the legality of the source of the IP sub-message in the IP packet cannot be determined according to the prior art.
  • the multiplexer header of the IP sub-packet in the IP packet carries the source identifier of the sender information, and the source identifier may be the UDP port number or the UDP port number of the session to which the IP sub-message belongs.
  • the receiver can determine the validity of the source identifier of the sender information carried in the IP sub-message in the IP packet.
  • the IP sub-packet in the IP packet The multiplexing header can only identify that the length of the IP sub-message is at most 255 bytes.
  • one byte is used in the multiplexing header instead of the prior art, and two bytes are used to identify The length of the IP sub-message, but this wastes the network bandwidth of the communication system. Therefore, the present invention additionally uses a bit in the multiplexing header to identify the length field using a few bytes to identify the length of the IP sub-message, such as 0.
  • the embodiment of the present invention provides an UP data packet format of the UP layer compressed data, and only the UP header is performed. Compression, but the CRC is not performed on the UP header and the compressed data, that is, the static load.
  • Step 804 After receiving the IP packet sent by the sender, the receiver parses each IP sub-message in the IP packet by using the IP packet type corresponding to the selected bandwidth saving capability to obtain the encapsulated data.
  • the bandwidth saving capability of the IP packet transmission on different interfaces in the communication system network is different.
  • the embodiments of the present invention have the following negotiation methods:
  • the IP packet is transmitted on the Iu interface of the WCDMA system, and the bandwidth saving capability negotiation is performed by using the UP, and the bandwidth extension capability is carried in the UP extension field, that is, the bandwidth saving capability set is carried.
  • IP packets are transmitted on the Nb interface of the WCDMA system, using IPBCP and session description
  • the protocol (SDP, Session Description Protocol) negotiates to carry multiple bandwidth saving capabilities in the SDP. It can also use the UP to negotiate the bandwidth saving capability and carry multiple bandwidth saving capabilities in the UP extension field.
  • the IP packet is transmitted between the receiver and the sender in the IMS, and the session initiation protocol (SIP) is used to negotiate with the SDP.
  • SIP session initiation protocol
  • the SDP carries multiple bandwidth saving capabilities.
  • the IP packet is in the IMS.
  • the media control device and the media processing device transmit, and negotiate with the H.248 protocol and the SDP, and carry multiple bandwidth saving capabilities in the SDP.
  • IP packets are transmitted in the fixed softswitch system, and SIP and SDP are negotiated between the softswitch devices, and multiple bandwidth saving capabilities are carried in the SDP; the H.248 protocol is used between the softswitch device and the media gateway.
  • the SDP negotiates and carries multiple bandwidth saving capabilities in the SDP.
  • the SDP uses this media attribute to pass parameters of a specific format, and does not care about the content.
  • the following describes the methods for using the H.248 protocol and SDP, using IPBCP and SDP, using SIP and SDP, and using UP to negotiate the bandwidth saving capability of IP packets.
  • bandwidth negotiation can not be negotiated between two media processing devices through IPBCP.
  • the media control device must control the media processing device to negotiate the bandwidth saving capability through the H.248 protocol.
  • the media control device and the media processing device interact with each other through H.248, and can use the H.248 protocol.
  • the LOCAL and REMOTE descriptors, in which multiple bandwidth saving capabilities described by SDP are used, here, a plurality of bandwidth saving capabilities are referred to as a bandwidth saving capability set. When there is no bandwidth saving capability in the SDP description, it can indicate that the bandwidth saving capability is not supported.
  • FIG. 9 is a flowchart of a method for negotiating a bandwidth saving capability of an IP packet by using the H.248 protocol and the SDP according to an embodiment of the present invention, where the network entity includes a media processing device 1, a media control device, and a media processing device 2, where the media The processing device 1 and the media processing device 2 can be the sender of the IP packet and the receiver of the IP packet, respectively.
  • the specific steps are as follows:
  • Step 900 The media control device requests the media processing device 1 to provide a supported bandwidth saving capability set.
  • Step 901 The media processing device 1 sends a supported bandwidth saving capability set to the media control device.
  • Step 902 The media control device sends the bandwidth saving capability set to the media processing device 2, and requests the media processing device 2 to select a supported bandwidth saving capability.
  • Step 9 The media processing device 2 selects a supported bandwidth saving capability and returns it to the media control device.
  • Step 904 The media control device requests the media processing device 1 to use the bandwidth saving capability selected by the media processing device 2.
  • Step 905 The media processing device 1 returns to the media control device to accept the selected bandwidth saving capability.
  • the SDP describes the set of bandwidth saving capabilities supported.
  • FIG. 10 is a flowchart of a method for negotiating a bandwidth saving capability of an IP packet by using an IPBCP and an SDP according to an embodiment of the present invention.
  • the network entity involved includes a media gateway 1 and a media gateway 2, and the specific steps are as follows:
  • Step 1000 The media gateway 1 sends an IPBCP request message to the media gateway 2, and carries a bandwidth saving capability set supported by the media gateway 1.
  • the bandwidth saving capability set is described by using an SDP.
  • Step 1001 The media gateway 2 selects a bandwidth saving capability supported by itself from the received bandwidth saving capability, and returns a response message to the media gateway 1 to carry the selected bandwidth saving capability.
  • SIP uses SDP to describe the set of bandwidth saving capabilities supported.
  • FIG. 11 is a diagram showing the bandwidth saving capability of IP packets by using SIP and SDP according to an embodiment of the present invention.
  • the negotiation method flowchart includes the network entity including the sender of the IP packet and the receiver of the IP packet. The specific steps are as follows:
  • Step 1100 The sending direction sends a SIP request message to the receiver, and carries the bandwidth saving capability set supported by the sending party.
  • the bandwidth saving capability set is described by using the SDP.
  • Step 1101 The receiver selects one of the supported bandwidth saving capabilities from the received bandwidth saving capability, and returns a response message of the SIP request message to the sender, carrying the selected bandwidth saving capability.
  • the SDP description with the wide savings set is deleted in the reply message.
  • the UP initialization message is used to negotiate the user plane parameters between the UTRAN and the MGW and between the MGW and the MGW.
  • the bandwidth saving capability negotiation can be performed by using the UP initialization request and the response message.
  • FIG. 12 is a schematic diagram of a bandwidth saving capability negotiation method for using an UP to perform IP packet transmission according to an embodiment of the present invention:
  • Step 1200 The sending direction sends a UP initialization request message to the receiver, and carries the supported bandwidth saving capability set.
  • Step 1201 The receiver selects one of the supported bandwidth saving capabilities from the received bandwidth saving capability, and returns a response message of the UP initialization request message to the sender, carrying the selected bandwidth saving capability.
  • the UP header compression capability negotiation may also be performed by using UP. As shown in FIG. 13, the specific steps are as follows: Step 1300: The sending direction sends a UP initialization request message to the receiver, and carries information about whether it supports the UP header compression capability.
  • Step 1301 If the receiver supports the UP header compression and the received sender information identifies that the sender supports the UP header compression, returns a response message of the UP initialization request message supporting the UP header compression capability to the sender; if any of the two parties One party does not support UP header compression, and returns a response message to the sender that does not support the UP header compression request capability of the UP header compression capability.
  • the UP initialization request message and the response message thereof include a plurality of idle extension fields, which can be supported by two bit bitmaps IPFmts ( bitmap ) in an idle extension field in the UP initialization request message.
  • the bandwidth saving capability set; using one bit B WS supported in one idle extension field in the response message indicates whether the receiver supports bandwidth saving capability, and one bit IPFMT indicates the bandwidth saving capability selected by the receiver.
  • one bit UPC in one idle extension field in the UP initialization request message may be used to indicate whether the sender supports UP header compression; and one bit UPC in one idle extension field in the response message indicates reception. Whether the side supports UP header compression.
  • the IPFmts ( bitmap ) field in the UP Initialization Request message is assigned according to the supported bandwidth saving capability set.
  • the receiver selects a bandwidth saving capability supported by itself from the IPFmts ( bitmap ) field in the received UP Initialization Request message, fills in the IP FMT field of the response message of the UP Initialization Request message, and sets the BWS supported field to 1, and then sends
  • the party and the receiver can process the IP packet corresponding to the same bandwidth saving capability; if the receiver does not support the bandwidth saving capability, or does not support the bandwidth saving capability in the IPFmts (map) field in the UP initialization request message,
  • the BWS supported field is set to 0 in the response message U of the UP Initialization Request message, after which the sender and the receiver can only process ordinary IP packets.
  • the sender can indicate whether the UP header compression is supported in the UP initialization request message
  • the receiver can indicate whether the UP header compression is supported in the response message of the UP initialization request message, and only the initiator and the receiver are supported.
  • Supports the compression of the UP header, and the UP header compression function can be adopted in the IP packet transmitted between the receiver and the sender.
  • the UP header compression capability can also be described by the SDP, and the UP header compression capability is negotiated through the SDP.
  • UPC yes means support for UP header compression
  • UPC no means that UP header compression capability is not supported.
  • the types of IP packets used in the embodiments of the present invention are described in detail below.
  • the link layer, the IP layer, and the UDP layer in the protocol stack carrying the IP packet remain unchanged, and multiple IP sub-messages are encapsulated in the IP packet, and each IP sub-report is encapsulated.
  • the text carries a content of a session, and the IP sub-message has a multiplexing header, as shown in FIG. 6.
  • the RTP header is compressed, and if the sender and the receiver both support the UP header compression, the UP header may also be compressed.
  • the IP header format of the IP packet is the same as that in the prior art; the UDP header is the same as in the prior art, that is, the destination UDP port number is a fixed value, and the value of the source UDP port number is not The meaning may be any value; the multiplexing header includes a multiplexing identifier, a source identifier, a length indication bit, and a length, where the multiplexing identifier is a destination UDP port number for receiving the sub-message or performing some operation on the destination UDP port number.
  • the value obtained is the source UDP port number of the sub-message or the value obtained by performing some operation on the source UDP port number.
  • the length indication bit indicates whether the length of the length field is 1 byte or 2 words.
  • the length of the section is the length of the IP sub-message; the compression process of the RTP header is the same as the compression process of the prior art RTP header.
  • the link layer since the link layer has performed CRC check on the IP packet, the correctness of the data carried in the IP packet can be ensured, so there is no need to perform CRC check on the UP layer.
  • the embodiment of the invention defines a type of a UP header that does not include a CRC check of the UP header and a CRC check of the static load, as shown in FIG. 14, wherein, in the detection portion, no CRC detection is performed.
  • IP packet header is compressed on the basis of multiplexing.
  • the following two examples are used to define two types of IP packet formats: one is to multiplex only IP packets; the other is to compress IP headers on the basis of multiplexing, as shown in Figure 15 and Figure 16 shows.
  • various IP packet formats can be set based on multiplexing technology and various IP packet header compression technologies.
  • the Length is 2 Byte, the maximum length of the identified IP sub-packet is 65535 bytes;
  • MUXID can be divided by 2 by the destination UDP port number;
  • SourcelD can be divided by 2 by the source UDP port number or source UDP port number, used by the receiver It checks the validity of the IP sub-message; Length, you can use 1 byte or 2 bytes to identify the length of the IP sub-message.
  • this IP message is not only multiplexed but also compressed by the RTP header.
  • the multiplex header includes L, MUXID, and SourcelD ⁇ Length;
  • the compressed RTP header includes P, M, Payload Type, and Time. Stamp and Sequence Number, where L indicates the number of bytes of the Length. When 0, the Length is 1 byte, and the maximum length of the IP sub-packet is 255 bytes.
  • the Length is 2 Bytes, the maximum length of the identified IP sub-message is 65535 bytes; MUXID, which can be divided by 2 by the destination UDP port number; SourcelD, can be divided by 2 by the source UDP port number or source UDP port number, the receiver Use it to check the validity of IP sub-messages; Length, you can use 1 byte or 2 bytes to identify the length of IP sub-messages; P, consistent with the usage in the standard RTP header, if IP sub-messages There is an additional padding byte, set the flag; M, consistent with the usage in the standard RTP header, defined by the session, used to establish boundaries for dividing different data in IP packets; Payload Type, and standard RTP headers Consistent usage; Sequence Number: Usage with the standard RTP header , Compressed length reduction from 16 bits to 8 bits; Time Stamp, is consistent with standard usage of the RTP header, compressed length reduction from 32 bits to 16 bits.
  • the compression mode of the RTP header can adopt the structure shown in FIG. 6.
  • the method provided by the embodiment of the present invention multiplexes the IP packet, compresses the RTP header, and compresses the carried data, thereby improving the processing efficiency of the processing device processing the IP packet in the communication system.
  • the receiver can determine the validity of the IP packet, and improve the reliability and security of the communication system.
  • the method provided by the method can carry multiple bandwidth saving capabilities at a time and improve the negotiation success rate.
  • the method provided by the embodiment of the present invention can adopt the H.248 protocol and the IPBCP when performing the bandwidth saving capability negotiation. And SIP, so that the negotiation method can be applied to the WCDMA circuit domain non-tunnel case and the fixed softswitch network.
  • a system for transmitting an IP packet is further provided. As shown in FIG. 17, the system includes a sender and a receiver, where
  • the sender is configured to send one or more bandwidth saving capabilities supported by the receiver to the receiver, determine the type of the IP packet used for transmitting the data according to the bandwidth saving capability selected by the receiver, and use the determined IP packet. After the text type constructs an IP packet carrying the transmitted data, it is sent to the receiver;
  • the receiver is configured to select one bandwidth saving capability from one or more bandwidth saving capabilities sent by the sender according to the bandwidth saving capability supported by the receiver, and send the bandwidth saving capability to the sender.
  • the sender and the receiver respectively include an RTP header compression capability negotiation module, where
  • the RTP header compression capability negotiation module of the sender is configured to send information about whether the RTP header compression capability is supported to the receiver, and receive information about whether the RTP header compression capability is supported from the receiver, and when constructing the IP packet, IP packet is subjected to RTP header compression;
  • the RTP header compression capability negotiation module of the receiver is configured to determine whether to support RTP header compression according to whether the RTP header compression capability and the received RTP header compression capability are supported, and whether the RTP header compression is supported by the sender. Capability information.
  • the receiver further includes an IP packet receiving and parsing module, configured to parse each IP sub-message in the IP packet by using the IP packet type corresponding to the selected bandwidth saving capability after receiving the IP packet sent by the sender. , get the transmitted data.
  • the embodiment of the present invention further provides a system for negotiating a bandwidth capability, where the system includes a sender and a receiver, where the sender is configured to send one or more bandwidth saving capabilities supported by the receiver to the receiver, according to the received
  • the bandwidth saving capability selected by the receiver determines the type of the IP packet used for transmitting the data.
  • the receiver is configured to select one bandwidth saving capability from one or more bandwidth saving capabilities sent by the sender according to the bandwidth saving capability supported by the receiver. To the sender.
  • the sender further includes an IP packet construction module, configured to construct a multiplexed IP packet carrying the transmission data by using the determined IP packet type, including at least one multiplex header IP sub-message, the multiplex header of the IP sub-message is provided with a source identifier identifying the sender information, or/and an identifier identifying the number of bytes used to indicate the length of the IP sub-message and an identifier identifying the length of the IP sub-message ;
  • the constructed multiplexed IP packet is sent to the receiver.
  • the sender further includes an IP packet construction module, configured to use the determined IP packet type to construct an IP packet carrying the compressed transmission data, including UP data without performing CRC check.
  • the packet and the UP header send the constructed IP packet to the receiver.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Description

IP报文传输、协商带宽节省能力和节省网络带宽的方法及系统 技术领域
本发明涉及在通信系统的网际协议 ( IP, Internet Protocol )承载网 中传输数据的技术，特别涉及一种 IP报文传输、协商带宽节省能力和节 省网络带宽的方法及系统。 发明背景
在通信系统， 如在宽度码分多址（WCDMA, Wide Code Division Multiple Access ) 系统的 IP承载网中， 数据需要承载在报文中传输， 如 数据承载在 IP报文中传输。 图 1为现有技术 WCDMA的网络架构示意 图， 图中的虚线表示信令路径， 实线表示承载数据的报文传输路径， 其 中， 媒体网关 （MGW, Media Gateway )之间的 Nb接口、 UTRAN和 MGW之间的 Iu接口传输的数据都可以使用 IP承载， Nb接口和 Iu接口 通过用户面协议（ UP, User Protocol )协商用户面参数， 移动业务控制 中心服务器（ MSCserver )使用 H.248协议经 Mc接口控制 MGW。 该网 络架构还可以应用于固定软交换系统、 CDMA系统或固网网际协议多媒 体子系统（IMS, IP Multimedia Subsystem )等网絡。
为了将数据承载在 IP报文中， 构建了图 2所示的承载 IP报文的协 议栈： 包括要传输数据的数据层、 实时传输协议 （RTP , Real-Time Transport Protocol )层、用户数据寺艮协议 ( UDP, User Datagram Protocol ) 层、 IP层和链路层。 IP层有 IP版本 4 ( IPv4 )或 IP版本 6 ( IPv6 )两种 版本。 链路层使用的协议为以太（ETHER )协议和 P0S， 对 IP报文进 行循环冗余编码（ CRC , cyclic redundancy check )校验。 以下对 RTP层 和 UDP层进行详细说明。 UDP层是一个筒单的面向数据的传输协议层， 其使用端口号为不同 会话保留其各自的数据传输通道， 发送方将 UDP数据通过数据传输通 道的源端口发送出去， 接收方通过该数据传输通道的目的端口接收数 据。 UDP层不提供可靠性， 即发送方把 UDP数据发送出去， 但是并不 保证 UDP数据能到达接收方。
RTP层是为具有实时特性的数据， 如交互式的语音或图像， 提供端 到端传输服务的协议层。 RTP层被定义为在一对一或一对多的传输情况 下工作， 目的是提供时间和数据流的同步。 RTP层通常使用 UDP层传 输数据， 对于一个 RTP数据会使用两个端口： 一个设置为 RTP, —个设 置为实时传输控制协议 ( RTCP, Real-Time Transport Control Protocol )。 RTP层本身不能为按顺序传送的 RTP数据包提供可靠的传送机制，也不 提供流量控制或拥塞控制， 其依靠 RTCP提供这些服务。 IP报文中的序 列号允许接收方重构发送方发送的 IP报文序列，也被用来确定发送方发 送的 IP报文在整个 IP报文序列中的位置， IP报文中的时间戳可以用来 计算网络传输延迟和抖动。
图 3为 IP报文的 RTP头的结构示意图， 示出了 RTP头的格式和内 容， 其中， 各域值的用法描述为： 版本（V, Version ): 可以为版本 2; 填充（P, Padding ): 如果 IP报文有附加的填充字节， 设置该标志； 扩 展（X, extension ): 指示在 RTP头之后的一个扩展头 （目前未使用：)； 贡献者计数 （ CC , Contributor count )： IP报文中贡献源标识符的数目， 最多允许有 15个贡献源标识； 标记（M, Marker ): 由会话规定其含义， 用于在 IP报文中建立划分不同数据的边界； 静荷类型 （PT, Payload type ): IP报文中数据的业务类型； 序列号（ SN, Sequence number ): 标 识 IP报文的序号， 长度为 16个比特； 时间戳（timestamp ): 反映一个 IP报文中的第一个字节数据的抽样时刻， 长度为 16个比特； 同步源标 识符（SSRC ): 标识 IP报文的同步源； 贡献源标识符列表（CSRC list ): 标识在 IP报文的静荷中所包含的所有贡献源，该 CSRC list的数目由 CC 给定。
承载在 IP报文中传输的数据一般需要经过压缩，如果承载了压缩数 据的 IP报文在 Iu接口和 Nb接口传输， 则需要将压缩的数据封装一个 UP头。 图 4为承载使用自适应多速率（ AMR, Adaptive Multi Rate )协 议压缩数据的 IP报文结构示意图，该结构与图 2所述的结构除了增加了 UP层以及数据是用 AMR压缩之外， 其他的相同。
UP层的 UP数据报文包括控制报文和数据报文， 其中， 控制报文包 括初始化报文、 速率控制报文、 时间校准报文和错误事件报文； UP数 据报文有两种类型，即 PDU TypeO和 PDU Typel，如图 5a和图 5b所示。
在图 5a和图 5b中， UP层的 UP数据报文中包括控制部分、 检测部 分和净荷部分， 其中， 在检测部分， PDU TypeO对压缩数据的 UP头和 压缩数据都进行了 CRC校 ； PDU Typel只对压缩数据的 UP头进行了 CRC校验。
当传输承载数据的 IP报文时，整个过程包括两个部分：第一个部分， 进行 IP报文的带宽节省能力协商； 第二个部分， 进行 IP报文的传输。 以下分别对这两个部分进行详细说明。
进行 IP报文的带宽节省能力协商
在传输 IP报文之前， IP报文的发送方和 IP报文的接收方需要确定 对方传输的或对方希望自身传输的 IP报文的类型，这时就需要进行一个 带宽节省能力协商的过程，每一种带宽节省能力都会对应一种 IP报文的 类型， 当 IP报文的发送方和 IP拫文的接收方协商好带宽节省能力后， 双方就确定了所传输 IP报文的类型。 目前进行协商的过程为： IP报文 的发起方将自身支持的一种带宽节省能力发送给 IP报文的接收方， IP 报文的接收方判断自身是否支持 IP报文的发起方发送的这种带宽节省 能力，如果是，向 IP报文的发起方发送协商成功的响应消息，协商成功； 否则， 向 IP报文的发起方发送协商不成功的响应消息，协商失败或再次 发起协商过程。
但是，这种 IP报文的带宽节省能力协商过程存在着缺点： IP报文的 发送方只发送自身所支持的一种带宽节省能力给 IP报文的接收方，容易 造成协商失败或进行重协商过程， 进而造成通信系统资源的浪费。 如：
IP报文的发送方可以支持的带宽节省能力为 0和 1 , 但是只能发送带宽 节省能力 0给 IP报文的接收方， 而 IP报文的接收方支持的带宽节省能 力 1 , 这样就会造成协商失败或进行重协商过程。 另外， 在 IP报文的带 宽节省能力协商过程中，没有定义使用 H.248协议如何进行 IP报文的带 宽节省能力协商， 如在 WCDMA系统电路域非隧道情况下进行 IP报文 的带宽节省能力协商。
进行 IP报文的传输
当 IP报文的带宽节省能力协商完成后，就可以根据所协商的带宽节 省能力确定采用何种类型的 IP报文来传输数据， 从而采用确定类型的 IP报文来传输数据。
目前， 有多种 IP 4艮文的类型， 以下介绍两种目前最常用的两种 IP 报文类型。
第一种 IP报文类型釆用图 3所示的结构， 包括压缩了的 IP报文头 和压缩后的数据， 即静荷。 为了节省 IP报文头所占用的通信系统资源， 互联网工作任务组提供了多种 IP报文头压缩的标准， 对一次会话的 IP 报文头， 即 IP头、 UDP头和 RTP头进行压缩。 在一次会话过程中， IP 报文头有很多信息是保持不变的或很少变化的， 还有一些信息虽然是变 化的，但相邻两个 IP报文的这些信息变化的差值是恒定的，将这两种类 型的信息称为稳定信息。 在会话开始时， 发送方将携带具有稳定信息的
IP报文头的 IP报文发送给接收方， 以后发送方就只将携带具有变化信 息的 IP报文头的 IP报文发送给接收方。 如果在会话过程中稳定信息发 生变化， 则发送方需要将携带具有稳定信息的 IP报文头的 IP报文再次 发送给接收方。 接收方根据接收到的稳定信息和变化信息重组在本次会 话中所接收到的各个 IP报文的 IP报文头。
采用这种 IP报文类型的 IP报文来传输数据， 存在着缺点： 第一， 如果携带具有稳定信息的 IP报文头的 IP报文丢失或损坏， 接收方就无 法在本次会话过程中正确的更新 IP报文的 IP 4艮文头， 导致会话的双方 无法正确通信， 所以必须提供机制检测接收方是否接收到携带具有稳定 信息的 IP报文头的 IP报文， 如果接收方没有接收到时可以发送消息请 求发送方再次发送，但是这种在通信系统中的往返时间会影响 IP报文的 传输效率； 第二， 只能针对单个会话， 不能针对多个会话进行复用； 第 三， 由于对 IP报文的 IP报文头进行了压缩， 所以具有压缩了 IP报文头 的 IP报文不能通过不支持 IP头压缩的路由器。
第二种 IP报文类型采用图 6所示的结构， 该 IP报文使用复用头技 术和 RTP压缩技术， 即在每个 IP子报文中增加了复用头， 在 RTP层中 使用了压缩技术。 复用头是将源 IP地址和目的 IP地址相同的多个会话 中的多个 IP子报文复用在一个 IP报文中发送， 链路层、 IP层和 UDP 层格式不变。 其中， 在包括了多个 IP子报文的一个 IP报文中， UDP头 中的目的端口号为固定值， UDP头中的源端口号没有意义。对于每一个 IP子报文都封装了一个复用头，该复用头指明了该 IP子报文的目的 UDP 端口号以及报文长度。 在 IP子报文中的 RTP压缩技术是通过缩减或删 除 RTP层中的某些字段来达到减小 RTP层长度的目的。 在 RTP层中， 某些字段的长度可以被缩短， 如时间戳和序列号， 还有一些字段在某些 通信系统组网环境下是不需要的， 比如在 WCDMA 系统网络中， RTP 头中的 P、 M、 CC、 X和 CSRC等字段都是无用的， 可以删除。 在进行 RTP头中的字段删除或缩短后， 再进行 RTP头的压缩。
但是， 采用这种 IP报文类型的 IP报文来传输数据， 也存在着缺点： 第一， 当 IP报文采用复用头技术时， 由于各个 IP子报文中的复用 头没有携带发送方的信息， 使得接收到 IP报文的接收方无法判断 IP报 文中的各个 IP子报文的合法性，存在可靠性和安全性的问题。举一个例 子说明， 如图 7所示： 首先， 地址为 10.110.100.100, 端口为 5000的终 端 1和地址为 10.110.200.200, 端口为 6000的终端 2建立了双向连接， 这两个终端可以互相发送接收 IP报文； 其次，传输报文结束后要删除这 两个终端， 终端 1被成功的删除了， 但是终端 2由于某些原因没有被删 掉， 成为了吊死的终端； 最后， 终端 1的 IP地址和端口号会分配给后续 的终端使用， 假设分配给了终端 3 , 其和 IP地址 10.110.200.200, 端口 5000的终端 4建立双向连接， 互相发送接收 IP报文， 但是这时吊死的 终端 2仍然向 IP地址 10.110.100.100， 端口 5000发送 IP报文， 这样终 端 3就收到了来自两个终端的 IP报文， 来自 10.110.200.200/5000的 IP 艮文是合法的， 而来自 10.110.200.200/6000的 IP报文是非法的， 需要丢 弃， 如果发送的 IP报文中的 IP子报文不包含源信息， 那么接收方就无 法对 IP报文中的 IP子报文的合法性进行判断， 如果不进行判断， 都认 为是合法 IP子报文的话，就会对通话质量产生影响，比如产生串音现象。
第二， 当 IP报文中的各个 IP子报文釆用复用头技术时， 标识 IP子 报文的字段过短， 最多只能采用 1 个字节标识 IP子报文的长度为 255 个字节， 在 IP子报文长度较长时， 无法标识 IP子报文的长短， 如传输 视频数据时或者对语音数据进行了 RTP冗余处理时， IP子报文中的静荷 长度就可能超过 255个字节， 这时这种复用头技术就无法应用。 第三， 当 IP报文的各个 IP子拫文中的数据采用 UP报头时，无论采 用两种类型中的哪一个类型， 都需要对 U 头进行 CRC校验， 但是， '实 际上在 IP报文的链路层已经进行了对 IP报文进行了 CRC校验，可以保 证所传输数据的正确性， 如果仍然在 UP头中进行 CRC校验， 既损失了 通信系统的网络带宽， 又提高了对设备处理能力的要求。 发明内容
本发明实施例提供一种 IP报文传输的方法及系统，能够解决协商带 宽节省能力易失败或易重协商的问题。
本发明实施例还提供一种协商带宽节省能力的方法及系统， 能够解 决协商带宽节省能力易失败或易重协商的问题。
本发明实施例还提供一种保证可靠性传输报文的方法， 能够保证所 传^报文的可靠性和安全性。
本发明实施例还提供一种节省网络带宽的方法， 能够节省通信系统 中 IP承载网的网络带宽和资源。
根据上述目的， 本发明实施例的技术方案是这样实现的：
一种网际协议 IP报文传输的方法， 该方法包括 IP报文的带宽节省 能力协商过程和 IP报文的传输过程， 其中， IP报文的带宽节省能力协 商过程为：
发送方将自身支持的一个以上带宽节省能力发送给接收方； 接收方根据自身支持的带宽节省能力从发送方发送的一个以上带 宽节省能力中选择一个带宽节省能力， 发送给发送方；
发送方根据接收到的接收方选择的带宽节省能力确定传输数据所 采用的 IP报文类型；
IP报文的传输过程为： 发送方采用所确定的 IP报文类型构造承载传输数据的 IP报文后， 将 IP报文发送给接收方。
一种协商带宽节省能力的方法， 该方法包括：
发送方将自身支持的一个以上带宽节省能力发送给接收方； 接收方根据自身支持的带宽节省能力从发送方发送的一个以上带 宽节省能力中选择一个带宽节省能力， 发送给发送方；
发送方接收到的接收方选择的带宽节省能力后， 确定所釆用的带宽 节省能力。
一种保证可靠性传输报文的方法， 该方法包括：
发送方将要传输的数据承载在 IP报文中发送给接收方， 该 IP报文 为复用后的 IP报文， 包括至少一个具有复用头的 IP子报文， 其中， IP 子报文的复用头设置有标识发送方信息的源标识、 或 /和标识指示 IP子 报文长度所使用字节数的标识和标识 IP子报文长度的标识，
所述接收方接收到该复用后的 IP · ^艮文后， 根据源标识确定发送方， 根据标识指示 IP子报文长度所使用字节数的标识和标识 IP子报文长度 的标识确定该复用后的报文中子报文的长度。
一种节省网络带宽的方法， 该方法包括：
发送方将要传输的数据承载在 IP报文中发送给接收方， 该 IP报文 包括 UP数据报文， 该 UP数据报文包括压缩后的所传输数据和 UP头， 该 UE数据报文不进行所传输数据的 CRC校验和 UP头的 CRC校验， 该 UP数据报文不进行所传输数据的 CRC校验和 UP头的 CRC校验。
一种 IP报文传输的系统， 该系统包括发送方和接收方， 其中， 所述发送方， 用于将自身支持的一个以上带宽节省能力发送给接收 方， 根据收到的接收方选择的带宽节省能力确定传输数据所采用的 IP 报文类型， 采用所确定的 IP报文类型构造承载传输数据的 IP报文后， 发送给接收方；
所述接收方， 用于根据自身支持的带宽节省能力从发送方发送的一 个以上带宽节省能力中选择一个带宽节省能力， 发送给发送方。
一种协商带宽能力的系统， 该系统包括发送方和接收方， 其中， 所述发送方， 用于将自身支持的一个以上带宽节省能力发送给接收 方， 根据收到的接收方选择的带宽节省能力确定传输数据所釆用的 IP 报文类型；
所述接收方， 用于根据自身支持的带宽节省能力从发送方发送的一 个以上带宽节省能力中选择一个带宽节省能力， 发送给发送方。
从上述方案可以看出， 本发明实施例提供的方法及系统分别对 IP 报文传输过程的两个部分， 即带宽节省能力协商部分和承载所传输数据 的 IP报文所采用的格式， 进行改进。 对于带宽节省能力协商过程， 本发 明实施例扩展了 UP初始化消息所承载的带宽节省能力或采用 SDP承载 带宽节省能力， 可以承载多个带宽节省能力， 不像现有技术每次协商过 程中只能承载一个带宽节省能力， 从而不仅解决了协商带宽节省能力易 失败或易重协商的问题， 而且解决了协商带宽节省能力方法只采用 UP 的问题。对于本发明实施例所采用的 IP报文格式，仍然采用复用头技术 和 RTP压缩技术， 在复用头增加源标识， 用于接收方根据接收到 IP报 文的各个 IP子报文的复用头中的源标识确定 IP子报文的来源， 进行安 全性和可靠性检测， 从而保证传输的可靠性和安全性； 在复用头增加标 的 IP子报文长度不止有 255个字节；对采用压缩数据的 UP数据报文不 进行 CRC校验， 节省了通信系统中 IP承载网的网络带宽和资源。 因此， 本发明提供的 IP报文传输的方法及系统、协商带宽节省能力的方法及系 统以及节省网络带宽的方法及系统节省了通信系统中 IP承载网的网络 带宽和资源。 附图简要说明
图 1为现有技术 WCDMA的网络架构示意图；
图 2为现有技术承载 IP报文的协议栈的架构示意图；
图 3为现有技术 IP报文的 RTP头的结构示意图；
图 4为现有技术承载使用 AMR协议压缩数据的 IP报文结构示意图； 图 5a为现有技术 UP层数据报文 PDU TypeO的格式示意图； 图 5b为现有技术 UP层数据报文 PDU Typel的格式示意图； 图 6为现有技术采用复用头技术和 RTP技术的 IP报文结构示意图； 图 7为现有技术采用复用头技术构造的 IP报文不具有可靠性的实施 例示意图；
图 8为本发明实施例 IP报文的传输方法流程图；
图 9为本发明实施例采用 H.248协议和 SDP进行 IP报文的带宽节 省能力协商方法流程图；
图 10为本发明实施例采用 IPBCP和 SDP进行 IP报文的带宽节省 能力协商方法流程图；
图 11为本发明实施例采用 SIP和 SDP进行 IP报文的带宽节省能力 协商方法流程图；
图 12为本发明实施例釆用 UP进行 IP报文的带宽节省能力协商方 法流程图；
图 13为本发明实施例采用 UP进行 UP头压缩能力协商方法流程图； 图 14为本发明实施例 UP层数据报文的格式示意图；
图 15为本发明实施例进行复用后的 IP报文格式示意图；
图 16为本发明实施例在复用基础上又进行 IP报文头压缩后的 IP报 文格式示意图；
图 17为本发明实施例 IP报文的传输系统示意图。 实施本发明的方式
以下举实施例并参照附图， 对本发明进行进一步详细说明。
为了节省通信系统的网络带宽和资源 , 本发明实施例提供了一种 IP 报文的传输方法，如图 8所示， 涉及的网络实体包括 IP报文的发送方和
IP报文的接收方， 其具体步驟为：
IP报文的带宽节省能力协商过程
步骤 800、 发送方将自身支持的一个以上带宽节省能力发送给接收 方。
一个以上带宽节省能力可以设置为带宽节省能力集。
步驟 801、 接收方接收到发送方发送的一个以上带宽节省能力后， 根据自身支持的带宽节省能力选择其中一个带宽节省能力， 将所选择的 带宽节省能力发送给发送方。
接收方可以设置带宽节省能力选择策略， 这样当发送方发送的一个 以上带宽节省能力中具有多个接收方支持的带宽节省能力时， 接收方可 以选择自身支持的并且最节省 （或设置的其他较为节省） 带宽的带宽节 省能力发送给发送方。
步骤 802、 发送方接收到接收方所选择的带宽节省能力后， 确定传 输数据釆用的 IP报文类型， 即对应于接收方所选择的带宽节省能力的 IP报文类型， 向接收方发送接受接收方所选择的带宽节省能力的消息。
IP报文的传输
步骤 803、 发送方已经确定传输数据所采用的 IP报文类型， 采用所 确定 IP报文类型构造承载数据的 IP报文后， 将 IP报文发送给接收方。 在本发明中， 可以使用图 6所示的 IP报文传输数据， 但是对该 IP 报文进行了改进： 首先， 针对现有技术无法判断 IP报文中的 IP子报文 来源的合法性问题， 在 IP报文中的 IP子报文的复用头中携带标识发送 方信息的源标识，该源标识可以是 IP子报文所属会话的用户数据报协议 UDP端口号或 UDP端口号除以 2, 这样， 接收方就可以根据 IP报文中 的 IP子报文携带的标识发送方信息的源标识进行合法性的判断； 其次， 在现有技术中 , IP报文中的 IP子报文的复用头只能标识该 IP子报文的 长度最多为 255个字节， 本发明实施例可以不像现有技术那样在复用头 使用 1个字节， 而使用 2个字节来标识 IP子报文的长度，但是这样太浪 费通信系统的网络带宽， 因此， 本发明另外在复用头使用一个比特来标 识使用几个字节的长度字段来标识 IP子报文的长度， 如 0表示使用 1 个字节标识 IP子报文的长度， 1表示使用 2个字节标识 IP子报文的长 度等； 最后， 本发明实施例提供了一种 UP层的压缩了数据的 UP数据 报文格式， 只对其中的 UP头进行压缩， 但对 UP头和压缩了的数据， 即静荷， 都不进行 CRC校验。
步骤 804、 接收方接收到发送方发送的 IP报文后， 采用所选择带宽 节省能力对应的 IP报文类型对该 IP报文中的各个 IP子报文进行解析， 得到所封装的数据。
以下具体说明如何进行 IP报文的带宽节省能力协商。
IP报文在通信系统网络中的不同接口传输所采用的带宽节省能力 协商方法不同， 本发明实施例有以下几种协商方法：
1 ) IP报文在 WCDMA系统的 Iu接口传输， 用 UP进行带宽节省能 力的协商， 在 UP扩展字段中携带多个带宽节省能力， 也就是携带带宽 节省能力集。
2 ) IP报文在 WCDMA系统的 Nb接口传输， 用 IPBCP和会话描述 协议（ SDP, Session Description Protocol )进行协商， 在 SDP中携带多 个带宽节省能力； 也可以用 UP进行带宽节省能力的协商， 在 UP扩展 字段中携带多个带宽节省能力。
3 ) IP报文在 IMS中的接收方和发送方之间传输， 用会话初始化协 议（SIP, Session initiation protocol )和 SDP进行协商， 在 SDP中携带 多个带宽节省能力； IP报文在 IMS中的媒体控制设备和媒体处理设备之 间传输， 用 H.248协议和 SDP进行协商， 在 SDP中携带多个带宽节省 能力。
4 ) IP报文在固定软交换系统中传输， 在软交换设备之间用 SIP和 SDP进行协商，在 SDP中携带多个带宽节省能力；软交换设备和媒体网 关之间用 H.248协议和 SDP进行协商， 在 SDP中携带多个带宽节省能 力。
当使用 SDP进行 IP报文的带宽节省能力协商时， SDP中定义了媒 体属性 a=fmtp, SDP使用这个媒体属性传递特定格式的参数， 并不关心 其中的内容。媒体属性 a=fmtp的格式为： a=fmtp:<format> <format specific parameters , 其中 <format specific parameters "^以为任意符合 SDP规 定的字符串 , 本发明实施例使用这个参数携带所支持的多个带宽节省能 力， 标识带宽节省能力的信息可以采用多种方式， 这里列举 2种方式： 第一种方式，在一个媒体属性 a-fintp中列出所有支持的带宽节省能 力： a=fmtp:<format> IPFmts={x,y，z，...}， 其中的 x、 y、 z表示带宽节省 能力， 按优先級逐渐降低的顺序排序。 例如： a=fmtp:4 IPFmts ={0,l}， 表示静荷类型为 4的 IP报文支持带宽节省能力为 0和 1。
第二种方式， 每个媒体属性 a=fmtp 列出一个所支持的带宽节省能 力 ： a=fmtp： <fomiat> IPFmts=x ； a=fmtp： <format> IPFmts=y ； a=fmtp:<format> IPFmts=z, 带宽节省能力按优先级逐渐降低的顺序排 W 200 序， 最希望使用的带宽节省能力放在最前面， 依此类推。
在本发明实施例中，还有一种特殊的媒体属性 a=fmtp用于表示媒体 控制设备希望媒体处理设备提供所支持的多个带宽节省能力， 可以表示 为： a=fmtp： <format> IPFmts=$。
以下分别叙述使用 H.248协议和 SDP、 使用 IPBCP和 SDP、 使用 SIP和 SDP以及使用 UP进行 IP报文的带宽节省能力协商的方法。
使用 H.248协议和 SDP进行 IP报文的带宽节省能力协商的方法 在 WCDMA系统电路域非隧道情况下或固定软交换系统中 ,两个媒 体处理设备之间不能通过 IPBCP进行带宽节省能力的协商，必须由媒体 控制设备通过 H.248协议控制媒体处理设备进行带宽节省能力的协商， 在协商过程中，媒体控制设备和媒体处理设备之间通过 H.248进行交互， 可以使用 H.248协议中的 LOCAL和 REMOTE描述符，在其中使用 SDP 描述的多个带宽节省能力， 在这里， 将多个带宽节省能力称为带宽节省 能力集。在 SDP描述中没有出现带宽节省能力时可以表示不支持带宽节 省能力。
图 9为本发明实施例釆用 H.248协议和 SDP进行 IP报文的带宽节 省能力协商方法流程图， 涉及的网络实体包括媒体处理设备 1、 媒体控 制设备和媒体处理设备 2, 其中， 媒体处理设备 1和媒体处理设备 2可 以分别为 IP报文的发送方和 IP报文的接收方， 其具体步骤为：
步骤 900、 媒体控制设备请求媒体处理设备 1提供支持的带宽节省 能力集。
步骤 901、 媒体处理设备 1给媒体控制设备发送支持的带宽节省能 力集。
步骤 902、 媒体控制设备将带宽节省能力集发送给媒体处理设备 2, 请求媒体处理设备 2选择一个支持的带宽节省能力。 步骤 9( 、 媒体处理设备 2选择一个支持的带宽节省能力返回给媒 体控制设备。
步驟 904、 媒体控制设备请求媒体处理设备 1使用媒体处理设备 2 选定的带宽节省能力。
步驟 905、 媒体处理设备 1向媒体控制设备返回接受选择的带宽节 省能力。
使用 IPBCP和 SDP进行 IP报文的带宽节省能力协商的方法 在 WCDMA系统电路域隧道方式下，两个媒体网关之间通过 IPBCP 交换接收方和发送方之间的协商参数， 这些协商参数可以为媒体流特 性、媒体流载体的 IP地址和端口号等。在本发明实施例中， IPBCP使用
SDP描述所支持的带宽节省能力集。
图 10为本发明实施例采用 IPBCP和 SDP进行 IP报文的带宽节省 能力协商方法流程图， 涉及的网络实体包括媒体网关 1和媒体网关 2, 其具体步骤为：
步骤 1000、 媒体网关 1向媒体网关 2发送 IPBCP请求消息， 携带 媒体网关 1支持的带宽节省能力集，该带宽节省能力集釆用 SDP进行描 述。
步驟 1001、媒体网关 2从接收的带宽节省能力集中选择一种自身支 持的带宽节省能力， 向媒体网关 1回应答消息， 携带选定的带宽节省能 力。
如果媒体网关 2不支持接收的任何一种带宽节省能力， 那么在应答 消息中删除带有带宽节省能力集的 SDP描述。
使用 SIP和 SDP进行 IP报文的带宽节省能力协商的方法
SIP使用 SDP描述所支持的带宽节省能力集。
图 11为本发明实施例采用 SIP和 SDP进行 IP报文的带宽节省能力 协商方法流程图， 涉及的网络实体包括 IP报文的发送方和 IP报文的接 收方， 其具体步骤为：
步骤 1100、 发送方向接收方发送 SIP请求消息， 携带其支持的带宽 节省能力集， 该带宽节省能力集釆用 SDP进行描述。
步骤 1101、接收方从接收的带宽节省能力集中选择一种其支持的带 宽节省能力， 向发送方返回 SIP请求消息的应答消息， 携带所选择的带 宽节省能力。
如果接收方不支持接收的任何一种带宽节省能力 , 那么在应答消息 中删除带有 宽节省能力集的 SDP描述。
使用 UP进行 IP报文的带宽节省能力协商的方法
在 UP支持模式下， UTRAN和 MGW之间以及 MGW和 MGW之 间使用 UP初始化消息进行用户面参数的协商， 在本发明实施例中可以 通过 UP初始化请求和应答消息进行带宽节省能力的协商。
图 12为本发明实施例采用 UP进行 IP报文的带宽节省能力协商方 其具体步驟为：
步骤 1200、 发送方向接收方发送 UP初始化请求消息， 携带支持的 带宽节省能力集。
步骤 1201、接收方从接收的带宽节省能力集中选择一种其支持的带 宽节省能力， 向发送方返回 UP初始化请求消息的应答消息， 携带所选 择的带宽节省能力。
如果接收方不支持接收的任何一种带宽节省能力， 那么在应答消息 中不携带任何带宽节省能力。
在本发明实施例中， 还可以使用 UP进行 UP头压缩能力协商， 如 图 13所示， 其具体步驟为： 步骤 1300、 发送方向接收方发送 UP初始化请求消息， 携带其是否 支持 UP头压缩能力的信息。
步骤 1301、 如果接收方支持 UP头压缩并且接收到的发送方的信息 标识发送方支持 UP头压缩，向发送方返回支持 UP头压缩能力的 UP初 始化请求消息的响应消息； 如果两方中的任意一方不支持 UP头压缩， 向发送方返回不支持 UP头压缩能力的 UP初始化请求消息的响应消息。
在本发明实施例中， UP初始化请求消息及其应答消息中包含若干 个空闲扩展字段， 可以使用 UP初始化请求报文中的一个空闲扩展字段 中的两个比特位图 IPFmts ( bitmap )携带所支持的带宽节省能力集； 使 用应答消息中的一个空闲扩展字段中的一个比特 B WS supported表示接 收方是否支持带宽节省能力，一个比特 IPFMT表示接收方选定的带宽节 省能力。
在本发明实施例中， 可以使用 UP初始化请求报文中的一个空闲扩 展字段中的一个比特 UPC表示发送方是否支持 UP头压缩；使用应答消 息中的一个空闲扩展字段中的一个比特 UPC表示接收方是否支持 UP头 压缩。
如表 1所示：
参数 IPFmts (bitmap) BWS IPFMT UPC 名称 supported 长度 2个比特 1个比特 1个比特 1个比特 含义 带宽节省能力列表 是否支持带 选定的带宽 是否支持 UP 宽节省能力 节省能力，在 头压缩
MUX
supported为 1
时才有效
取值 00:不支持带宽节省能力 0: 不支持带 0: 支持带宽 0: 不支持 01 : 支持带宽节省能力 0 宽节省能力 节省能力 0 UP头压缩 10: 支持带宽节省能力 1 1 : 支持带宽 1 : 支持带宽 1 : 支持 UP头 11:支持带宽节省能力 0、 节省能力 节能力 1 压缩 1
位置 UP初始化请求消息 UP初始化奇 UP初始化请 UP 初始化请 求消息的应 求消息的应 求消息 /UP 初 答消息 答消息 始化请求消息 的应答消息 表 1
从表 1可以看出， 如果发送方支持带宽节省能力， 就将 UP初始化 请求消息中的 IPFmts ( bitmap )字段按照支持的带宽节省能力集进行赋 值。 接收方从接收到 UP初始化请求消息中的 IPFmts ( bitmap )字段选 择一个自身支持的带宽节省能力， 填写在 UP初始化请求消息的应答消 息的 IP FMT字段， 同时将 BWS supported字段置 1 , 这以后发送方和 接收方就可以处理对应于相同带宽节省能力的 IP报文；如果接收方不支 持带宽节省能力， 或者不支持接收到 UP 初始化请求消息中的 IPFmts ( bitmap )字段中的带宽节省能力， 就在 UP初始化请求消息的应答消 息 U中将 BWS supported字段置 0, 这以后发送方和接收方就只能处理 普通的 IP报文。
从表 1还可以看出， 发送方可以在 UP初始化请求消息中指示是否 支持 UP头压缩， 接收方可以在 UP初始化请求消息的应答消息中指示 是否支持 UP头压缩， 只有发起方和接收方都支持 UP头的压缩， 才能 接收方和发送方之间传输的 IP报文中采用 UP头压缩功能。
在本发明实施例中， UP头压缩能力也可以通过 SDP描述，通过 SDP 进行 UP头压缩能力的协商。 例如： a=fmtp:<format> UPC=yes表示支持 UP头压缩能力； a=fmtp:<format> UPC=no表示不支持 UP头压缩能力。 以下对本发明实施例采用的 IP报文类型进行详细说明。 ' 在本发明实施例中，承载 IP报文的协议栈中的链路层、 IP层和 UDP 层都保持不变， 在 IP报文中封装了多个 IP子报文， 每个 IP子报文中携 带一个会话的一个内容， IP子报文中都有一个复用头， 如图 6所示。
在本发明实施例中， 对 RTP头进行压缩， 如果发送方和接收方都支 持 UP头压缩， 还可以对 UP头进行压缩。
在本发明实施例中， IP报文的 IP头格式与现有技术中的相同； UDP 头与现有技术中的相同， 即目的 UDP端口号是一个固定的值， 源 UDP 端口号的值无意义， 可以为任意值； 复用头包括复用标识、 源标识、 长 度指示位和长度， 其中， 复用标识为接收该子报文的目的 UDP端口号 或对目的 UDP端口号进行某种运算得到的值， 源标识为发送该子报文 的源 UDP端口号或对源 UDP端口号进行某种运算得到的值， 长度指示 位指示长度字段的字节数为 1个字节还是 2个字节，长度为 IP子报文的 长度； RTP头的压缩过程同现有技术的 RTP头的压缩过程。
在本发明实施例中， 由于链路层已经对 IP报文进行了 CRC校验， 可以保证承载在 IP报文的数据的正确性，所以就不需要再在 UP层进行 CRC校验， 所以本发明实施例定义了一种 UP头的类型， 该类型的 UP 头不包括 UP头的 CRC校验和静荷的 CRC校验， 如图 14所示， 其中， 在检测部分， 没有进行 CRC检测。
如果只对 IP报文的报文头进行压缩， 节省的带宽并不明显， 所以一 般都是在复用的基础上再进行 IP报文头的压缩。 下面举两个例子， 定义 两种 IP报文格式， 一种是只复用的 IP报文； 另一种为在复用的基础上 对 IP报文进行报文头的压缩， 如图 15和图 16所示。 在实际应用中， 基 于复用技术和各种 IP报文头压缩技术， 还可以设置各种 IP报文格式。
在图 15中，这个 IP报文只进行了复用，不进行 RTP头的压缩， RTP 头保持不变。在每个被复用的 IP子报文前都有一个复用头， 复用头的内 容包括长度字段指示 （L )、 复用标识（MUXID )、 源标识（SourcelD ) 和复用报文的长度 ( Length )„ 其中， L指示 Length的字节数， 当取 0 时表示 Length为 1个字节， 标识 IP子报文的最大长度为 255字节， 当 L取 1时表示 Length为 2个字节， 标识 IP子报文的最大长度为 65535 字节； MUXID, 可以使用目的 UDP端口号除以 2表示； SourcelD, 可 以使用源 UDP端口号或源 UDP端口号除以 2表示 , 接收方使用其进行 IP子报文的合法性检查； Length, 可以用 1个字节或 2个字节标识 IP子 报文的长度。
在图 16中，这个 IP报文不仅进行了复用而且进行了 RTP头的压缩。 在每个被复用的 IP子报文前都有一个复用头和压缩的 RTP头， 复用头 的包括 L、 MUXID, SourcelD ^ Length;压缩的 RTP头包括 P、 M、 Payload Type、 Time Stamp和 Sequence Number,, 其中, L指示 Length的字节数, 当取 0时表示 Length为 1个字节， 标识 IP子报文的最大长度为 255字 节， 当 L取 1时表示 Length为 2个字节， 标识 IP子报文的最大长度为 65535字节； MUXID,可以使用目的 UDP端口号除以 2表示； SourcelD, 可以使用源 UDP端口号或源 UDP端口号除以 2表示， 接收方使用其进 行 IP子报文的合法性检查； Length,可以用 1个字节或 2个字节标识 IP 子报文的长度； P, 与标准 RTP头中的用法一致， 如果 IP子报文中有附 加的填充字节， 设置该标志； M, 与标准 RTP头中的用法一致， 由会话 规定其含义， 用于在 IP报文中建立划分不同数据的边界； Payload Type, 与标准 RTP头中的用法一致； Sequence Number: 与标准 RTP头中的用 法一致， 压缩后长度从 16比特缩减至 8比特； Time Stamp, 与标准 RTP 头中的用法一致， 压缩后长度从 32比特缩减至 16比特。 RTP头的压缩 方式可以采用图 6所示的结构。 本发明实施例提供的 ^法对 IP报文进行复用、 RTP头的压缩以及所 承载数据的压缩， 提高了通信系统中的处理设备处理 IP报文的处理效 率； 本发明实施例提供的方法通过在 IP报文的每个 IP子报文的复用头 都携带源表示，使得接收方可以据此判断 IP报文的合法性，提高了通信 系统的可靠性和安全性； 本发明实施例提供的方法在进行带宽节省能力 协商过程中， 一次可以携带多个带宽节省能力， 提高了协商成功率； 本 发明实施例提供的方法在进行带宽节省能力协商时， 可以采用 H.248协 议、 IPBCP以及 SIP, 从而使协商方法可以应用于 WCDMA电路域非隧 道情况和固定软交换网络。
在本发明实施例中， 还提供了传输 IP报文的系统， 如图 17所示， 该系统包括发送方和接收方， 其中，
所述发送方， 用于将自身支持的一个以上带宽节省能力发送给接收 方， 根据收到的接收方选择的带宽节省能力确定传输数据所采用的 IP 报文类型， 釆用所确定的 IP报文类型构造承载传输数据的 IP报文后， 发送给接收方；
所述接收方， 用于根据自身支持的带宽节省能力从发送方发送的一 个以上带宽节省能力中选择一个带宽节省能力， 发送给发送方。
其中， 所述发送方和接收方分别还包括 RTP头压缩能力协商模块， 其中，
所述发送方的 RTP头压缩能力协商模块， 用于将是否支持 RTP头 压缩能力的信息发送给接收方；从接收方接收是否支持 RTP头压缩能力 信息， 支持时， 在构造 IP报文时对 IP报文进行 RTP头压缩；
所述接收方的 RTP 头压缩能力协商模块， 用于根据自身是否支持 RTP头压缩能力和接收到的是否支持 RTP头压缩能力的信息确定是否支 持 RTP头压缩， 给发送方发送是否支持 RTP头压缩能力信息。 接收方还包括 IP报文接收解析模块， 用于接收到发送方发送的 IP 报文后， 采用所选择带宽节省能力对应的 IP报文类型对该 IP报文中的 各个 IP子报文进行解析， 得到所传输的数据。
本发明实施例还提供一种协商带宽能力的系统， 该系统包括发送方 和接收方， 其中， 所述发送方， 用于将自身支持的一个以上带宽节省能 力发送给接收方， 根据收到的接收方选择的带宽节省能力确定传输数据 所采用的 IP报文类型； 所述接收方，用于根据自身支持的带宽节省能力 从发送方发送的一个以上带宽节省能力中选择一个带宽节省能力， 发送 给发送方。
在本发明实施例中，所述发送方还包括 IP报文构造模块， 用于釆用 所确定的 IP报文类型构造承载传输数据的复用后的 IP报文， 包括至少 一个具有复用头的 IP子报文， IP子报文的复用头设置有标识发送方信 息的源标识、 或 /和标识指示 IP子报文长度所使用字节数的标识和标识 IP子报文长度的标识； 将构造的复用后的 IP报文发送给接收方。
在本发明实施例中，所述发送方还包括 IP报文构造模块，用于采用 所确定的 IP报文类型， 构造承载压缩后传输数据的 IP报文， 包括未进 行 CRC校验的 UP数据报文和 UP头， 将构造的 IP报文发送给接收方。 以上所述的具体实施例， 对本发明的目的、 技术方案和有益效果进行了 进一步详细说明， 所应理解的是， 以上所述仅为本发明的具体实施例而 已， 并不用于限制本发明， 凡在本发明的精神和原则之内， 所做的任何 修改、 等同替换和改进等， 均应包含在本发明的保护范围之内。

Claims

权利要求书
1、 一种网际协议 IP报文传输的方法， 其特征在于， 该方法包括 IP 报文的带宽节省能力协商过程和 IP报文的传输过程， 其中， IP报文的 带宽节省能力协商过程为：
发送方将自身支持的一个以上带宽节省能力发送给接收方； 接收方根据自身支持的带宽节省能力从发送方发送的一个以上带 宽节省能力中选择一个带宽节省能力， 发送给发送方；
发送方根据接收到的接收方选择的带宽节省能力确定传输数据所 采用的 IP报文类型；
IP报文的传输过程为：
发送方采用所确定的 IP报文类型构造承载传输数据的 IP报文后， 将 IP报文发送给接收方。
2、 如权利要求 1 所述的方法， 其特征在于， 该方法进一步包括： 设置带宽节省能力与 IP报文类型的映射关系，所述确定传输数据所采用 的 IP报文类型的过程为：
根据映射关系确定接收到的接收方选择的带宽节省能力对应的 IP 报文类型， 将确定的 IP报文类型作为传输数据所采用的 IP报文类型。
3、 如权利要求 1 所述的方法， 其特征在于， 发送方发送的一个以 上带宽节省能力中具有多个接收方支持的带宽节省能力时， 所述接收方 根据带宽节省能力选择策略选择一个带宽节省能力。
4、 如权利要求 1 所述的方法， 其特征在于， 所述的一个以上带宽 节省能力设置为带宽节省能力集。
5、 如权利要求 1 所述的方法， 其特征在于， 所述的一个以上带宽 节省能力携带在用户面协议 UP初始化请求消息的 UP扩展字段中发送； 所述的接收方选择的一个带宽节省能力携带在 UP初始化请求消息 的应答消息中的 UP扩展字段中发送。
6、 如权利要求 1 所述的方法， 其特征在于， 所述的一个以上带宽 节省能力设置在会话描述协议 SDP中，该具有一个以上带宽节省能力的 SDP描述携带在会话初始化协议 SIP消息、 或 IP承载控制协议 IPBCP 消息或 H.248协议消息中发送；
所述的接收方选择的一个带宽节省能力设置在 SDP中，该具有接收 方选择的一个带宽节省能力的 SDP描述携带在 SIP消息的应答消息、或 IPBCP消息的应答消息或 H.248协议消息的应答消息中发送。
7、 如权利要求 1所述的方法， 其特征在于， 所述的 IP报文为复用 后的 IP报文， 包括至少一个具有复用头的 IP子报文， 其中， IP子报文 的复用头设置有标识发送方信息的源标识、 或 /和标识指示 IP子报文长 度所使用字节数的标识和标识 IP子报文长度的标识，
该方法还包括： 所述接收方接收到该复用后的 IP报文后，根据源标 识确定发送方，根据标识指示 IP子报文长度所使用字节数的标识和标识 IP子报文长度的标识确定该复用后的报文中子报文的长度。
8、 如权利要求 1或 7所述的方法， 其特征在于， 所述的 IP报文包 括 UP数据报文， 该 UP数据报文包括压缩后的所传输的数据和 UP头，
CRC校验。
9、 如权利要求 1所述的方法， 其特征在于， 在所述构造 IP报文之 前， 还包括 RTP头压缩能力的协商过程：
发送方将是否支持 RTP头压缩能力的信息发送给接收方，接收方根 据自身是否支持 RTP头压缩能力和接收到的是否支持 RTP头压缩能力 的信息确定是否支持 RTP头压缩： 如果两者都支持， 则接收方向发送方 发送支持 RTP头压缩能力信息， 发送方对 IP报文进行 RTP头压缩； 如 果两者之中有任意一者不支持，则接收方向发送方发送不支持 RTP头压 缩能力信息， 发送方不能对 IP报文进行 RTP头压缩。
10、 如权利要求 9所述的方法， 其特征在于， 所述发送方发送的是 否支持 RTP头压缩能力的信息携带在 UP初始化请求消息的 UP扩展字 段中发送；
所述接收方向发送方发送的不支持 RTP头压缩能力信息或支持 RTP 头压缩能力信息携带在 UP初始化请求消息的应答消息中的 UP扩展字 段中发送。
11、 如权利要求 10 所述的方法， 其特征在于， 所述发送方发送的 是否支持 RTP头压缩能力的信息设置在 SDP中， 该具有是否支持 RTP 头压缩能力的信息的 SDP描述携带在 SIP消息、或 IPBCP消息或 H.248 协议消息中发送；
所述接收方向发送方发送的不支持 RTP头压缩能力信息或支持 RTP 头压缩能力信息设置在 SDP中， 该具有不支持 RTP头压缩能力信息或 支持 RTP头压缩能力信息的 SDP描述携带在 SIP消息的应答消息、 或 IPBCP消息的应答消息或 H.248协议消息的应答消息中发送。
12、 一种协商带宽节省能力的方法， 其特征在于， 该方法包括： 发送方将自身支持的一个以上带宽节省能力发送给接收方； 接收方根据自身支持的带宽节省能力从发送方发送的一个以上带 宽节省能力中选择一个带宽节省能力， 发送给发送方；
发送方接收到的接收方选择的带宽节省能力后， 确定所采用的带宽 节省能力。
13、 如权利要求 12 所述的方法， 其特征在于， 发送方发送的一个 以上带宽节省能力中具有多个接收方支持的带宽节省能力时， 所述接收 方根据带宽节省能力选择策略选择一个带宽节省能力。
14、 如权利要求 12 所述的方法， 其特征在于， 所述的一个以上带 宽节省能力为带宽节省能力集。
15、 如权利要求 12 所述的方法， 其特征在于， 所述的一个以上带 宽节省能力携带在 UP初始化请求消息的 UP扩展字段中发送; .
所述的接收方选择的一个带宽节省能力携带在 UP初始化请求消息 的应答消息中的 UP扩展字段中发送。
16、 如权利要求 12 所述的方法， 其特征在于， 所述的一个以上带 宽节省能力设置在 SDP中， 该具有一个以上带宽节省能力的 SDP描述 携带在 SIP消息、 或 IPBCP消息或 H.248协议消息中发送；
所述的接收方选择的一个带宽节省能力设置在 SDP中 ,该具有接收 方选择的一个带宽节省能力的 SDP描述携带在 SIP消息的应答消息、或 IPBCP消息的应答消息或 H.248协议消息的应答消息中发送。
17、 一种保证可靠性传输报文的方法， 其特征在于， 该方法包括： 发送方将要传输的数据承载在 IP报文中发送给接收方， 该 IP报文 为复用后的 IP报文， 包括至少一个具有复用头的 IP子报文， 其中， IP 子报文的复用头设置有标识发送方信息的源标识、 或 /和标识指示 IP子 报文长度所使用字节数的标识和标识 IP子报文长度的标识，
所述接收方接收到该复用后的 IP报文后， 根据源标识确定发送方， 根据标识指示 IP子报文长度所使用字节数的标识和标识 IP子报文长度 的标识确定该复用后的报文中子报文的长度。
18、 如权利要求 17 所述的方法， 其特征在于， 所述标识发送方信 息的源标识为 IP子报文所属会话的用户数据报协议 UDP端口号或 UDP 端口号除以 2。
19、 如权利要求 17所述的方法， 其特征在于， 所述 IP报文包括 UP 数据报文，该 UP数据报文包括压缩后的所传输数据和 UP头， 该 UP数 据报文不进行所传输数据的 CRC校验和 UP头的 CRC校验。
20、 如权利要求 17所述的方法， 其特征在于， 在发送 IP报文之前， 还包括 RTP头压缩能力的协商过程：
发送方将是否支持 RTP头压缩能力的信息发送给接收方，接收方根 据自身是否支持 RTP头压缩能力和接收到的是否支持 RTP头压缩能力 的信息确定是否支持 RTP头压缩： 如果两者都支持， 则接收方向发送方 发送支持 RTP头压缩能力信息， 发送方对 IP报文进行 RTP头压缩； 如 果两者之中有任意一者不支持，则接收方向发送方发送不支持 RTP头压 缩能力信息， 发送方不能对 IP报文进行 RTP头压缩。
21、 如权利要求 20 所述的方法， 其特征在于， 所述发送方发送的 是否支持 RTP头压缩能力的信息携带在 UP初始化请求消息的 UP扩展 字段中发送；
所述接收方向发送方发送的不支持 RTP头压缩能力信息或支持 RTP 头压缩能力信息携带在 UP初始化请求消息的应答消息中的 UP扩展字 段中发送。
22、 如权利要求 20 所述的方法， 其特征在于， 所述发送方发送的 是否支持 RTP头压缩能力的信息设置在 SDP中， 该具有是否支持 RTP 头压缩能力的信息的 SDP描述携带在 SIP消息、 IPBCP消息或 H.248协 议消息中发送；
所述接收方向发送方发送的不支持 RTP头压缩能力信息或支持 RTP 头压缩能力信息设置在 SDP中， 该具有不支持 RTP头压缩能力信息或 支持 RTP 头压缩能力信息的 SDP描述携带在 SIP 消息的应答消息、 IPBCP消息的应答消息或 H.248协议消息的应答消息中发送。
23、 一种节省网络带宽的方法， 其特征在于， 该方法包括： 发送方将要传输的数据承载在 IP报文中发送给接收方， 该 IP报文 包括 UP数据报文， 该 UP数据报文包括压缩后的所传输数据和 UP头， 该 UP数据^ =艮文不进行所传输数据的 CRC校验和 UP头的 CRC校验。
24、 如权利要求 23所述的方法， 其特征在于， 所述 IP报文为压缩 了 RTP头的 IP报文。
25、 一种 IP报文传输的系统， 其特征在于， 该系统包括发送方和接 收方， 其中，
所述发送方， 用于将自身支持的一个以上带宽节省能力发送给接收 方， 根据收到的接收方选择的带宽节省能力确定传输数据所采用的 IP 报文类型 , 采用所确定的 IP报文类型构造承载传输数据的 IP报文后， 发送给接收方；
所述接收方， 用于根据自身支持的带宽节省能力从发送方发送的一 个以上带宽节省能力中选择一个带宽节省能力， 发送给发送方。
26、 如权利要求 25.所述的系统， 其特征在于， 所述发送方和接收 方分别还包括 RTP头压缩能力协商模块， 其中，
所述发送方的 RTP头压缩能力协商模块， 用于将是否支持 RTP头 压缩能力的信息发送给接收方；从接收方接收是否支持 RTP头压缩能力 信息， 支持时， 在构造 IP报文时对 IP报文进行 RTP头压缩；
所述接收方的 RTP 头压缩能力协商模块， 用于根据自身是否支持 RTP头压缩能力和接收到的是否支持 RTP头压缩能力的信息确定是否支 持 RTP头压缩， 给发送方发送是否支持 RTP头压缩能力信息。
27、 如权利要求 25或 26所述的系统， 其特征在于， 接收方还包括 IP报文接收解析模块， 用于接收到发送方发送的 IP报文后， 采用所选 择带宽节省能力对应的 IP报文类型对该 IP报文中的各个 IP子报文进行 解析， 得到所传输的数据。
28、 如权利要求 25 所述的系统， 其特征在于， 所述发送方还包括 IP报文构造模块， 用于采用所确定的 IP报文类型构造承载传输数据的 复用后的 IP报文， 包括至少一个具有复用头的 IP子报文， IP子报文的 复用头设置有标识发送方信息的源标识、 或 /和标识指示 IP子报文长度 所使用字节数的标识和标识 IP 子报文长度的标识； 将构造的复用后的 IP报文发送给接收方。
29、 如权利要求 25 所述的系统， 其特征在于， 所述发送方还包括 IP报文构造模块， 用于采用所确定的 IP报文类型， 构造承载压缩后传 输数据的 IP报文， 包括未进行 CRC校验的 UP数据报文和 UP头，将构 造的 IP报文发送给接收方。
30、 一种协商带宽能力的系统， 其特征在于， 该系统包括发送方和 接收方， 其中，
所述发送方， 用于将自身支持的一个以上带宽节省能力发送给接收 方， 根据收到的接收方选择的带宽节省能力确定传输数据所采用的 IP 报文类型；
所述接收方， 用于根据自身支持的带宽节省能力从发送方发送的一 个以上带宽节省能力中选择一个带宽节省能力， 发送给发送方。
PCT/CN2007/001414 2006-04-27 2007-04-27 Method of internet protocol(ip) message transmission, negotiated bandwidth saving capability and saving network bandwidth WO2007128217A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP07720987.2A EP1940093B1 (en) 2006-04-27 2007-04-27 Method of internet protocol(ip) message transmission, negotiated bandwidth saving capability and saving network bandwidth
CN2007800003277A CN101317404B (zh) 2006-04-27 2007-04-27 Ip报文传输、协商带宽节省能力和节省网络带宽的方法及系统
ES07720987.2T ES2558020T3 (es) 2006-04-27 2007-04-27 Método de transmisión de mensaje de protocolo Internet (IP), capacidad de economía de ancho de banda negociada y economía de ancho de banda de red
US12/235,876 US8311060B2 (en) 2006-04-27 2008-09-23 Method and system for transmitting IP message, negotiating bandwidth saving capability and saving network bandwidth

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200610076081.9 2006-04-27
CN2006100760819A CN101047711B (zh) 2006-04-27 2006-04-27 Ip报文传输、协商带宽节省能力和节省网络带宽的方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/235,876 Continuation US8311060B2 (en) 2006-04-27 2008-09-23 Method and system for transmitting IP message, negotiating bandwidth saving capability and saving network bandwidth

Publications (1)

Publication Number Publication Date
WO2007128217A1 true WO2007128217A1 (en) 2007-11-15

Family

ID=38667429

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2007/001414 WO2007128217A1 (en) 2006-04-27 2007-04-27 Method of internet protocol(ip) message transmission, negotiated bandwidth saving capability and saving network bandwidth

Country Status (5)

Country Link
US (1) US8311060B2 (zh)
EP (3) EP1940093B1 (zh)
CN (2) CN101047711B (zh)
ES (1) ES2558020T3 (zh)
WO (1) WO2007128217A1 (zh)

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101047711B (zh) 2006-04-27 2010-08-18 华为技术有限公司 Ip报文传输、协商带宽节省能力和节省网络带宽的方法
US20100091835A1 (en) * 2008-10-14 2010-04-15 Morris Robert P Method And System For Processing A Media Stream
KR101322784B1 (ko) * 2009-03-16 2013-10-29 노키아 지멘스 네트웍스 오와이 모바일 네트워크 최적화
WO2010106663A1 (ja) * 2009-03-19 2010-09-23 富士通株式会社 受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法
CN101616156B (zh) * 2009-07-24 2012-10-03 中兴通讯股份有限公司 一种实现rtp数据流多路复用的信令协商方法和装置
JP4740365B2 (ja) 2009-10-26 2011-08-03 シャープ株式会社 移動局装置、基地局装置、無線通信システム、通信制御方法、通信制御プログラム、及びプロセッサ
KR20110071835A (ko) * 2009-12-21 2011-06-29 삼성전자주식회사 이동통신시스템에서 브이오아이피 서비스를 제공하는 방법 및 장치
JP5094896B2 (ja) * 2010-02-26 2012-12-12 シャープ株式会社 移動局装置、基地局装置、通信制御方法及び集積回路
CN102546547A (zh) * 2010-12-22 2012-07-04 中兴通讯股份有限公司 Ip报文发送方法、网络测设备及终端
CN102255906B (zh) * 2011-07-08 2014-07-23 中国联合网络通信集团有限公司 数据发送和接收方法、设备及系统
CN102318289B (zh) * 2011-07-29 2014-12-10 华为技术有限公司 带宽调整方法、总线控制器及信号转换器
ES2972427T3 (es) * 2011-10-13 2024-06-12 Samsung Electronics Co Ltd Aparato y procedimiento de configuración de un mensaje de control en un sistema de difusión
CN103685426B (zh) * 2012-09-25 2017-11-03 联想(北京)有限公司 信息处理设备和信息处理方法
US9356645B2 (en) * 2012-11-16 2016-05-31 International Business Machines Corporation Saving bandwidth in transmission of compressed data
CN103618678A (zh) * 2013-11-18 2014-03-05 北京星网锐捷网络技术有限公司 自适应多链路聚合的方法、装置及系统
CN104394119B (zh) * 2014-08-27 2020-09-11 贵阳语玩科技有限公司 Rtp包的发送方法、响应方法及装置
CN105450613B (zh) * 2014-09-01 2019-03-12 展讯通信（上海）有限公司 一种数据识别系统及方法
US9991719B2 (en) 2014-09-30 2018-06-05 The Boeing Company Systems and methods for reducing circulating current and phase to phase imbalance in a parallel modular converter system
CN106301987B (zh) * 2015-06-03 2020-02-14 华为技术有限公司 一种报文丢失检测方法、装置及系统
CN106817386B (zh) * 2015-11-27 2020-03-10 华为技术有限公司 一种多会话下远程服务的数据处理方法和系统
US10498683B2 (en) 2016-07-20 2019-12-03 At&T Intellectual Property I, L.P. Compressed message sets for storage efficiency
CN107872429A (zh) * 2016-09-26 2018-04-03 中国电信股份有限公司 在 vxlan 中实现身份检验的方法和系统
CN109547467A (zh) * 2018-12-19 2019-03-29 北京东土科技股份有限公司 媒体数据纠错传输及纠错方法、装置、设备及存储介质
CN112398731B (zh) * 2019-08-15 2022-05-13 华为技术有限公司 一种处理报文的方法和第一网络设备
CN112040513B (zh) * 2020-09-10 2024-03-08 深圳市欢太科技有限公司 一种数据传输方法、数据传输装置及数据传输系统
CN112671597B (zh) * 2020-11-25 2023-03-24 紫光云技术有限公司 一种分段统计弹性公网ip在共享带宽内和外流量的方法
CN113821074B (zh) * 2021-09-06 2023-09-08 北京车和家信息技术有限公司 一种时间同步方法、装置、电子设备和存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1111847A2 (en) * 1999-12-21 2001-06-27 Alcatel USA Sourcing, L.P. System and method of telecommunications network node ethernet connectivity
WO2002015627A1 (en) 2000-08-14 2002-02-21 Nokia Corporation Communication system and method providing a mode selection procedure
EP1248431A1 (en) 2001-03-27 2002-10-09 Sony International (Europe) GmbH Method for achieving end-to-end quality of service negotiation for distributed multimedia applications
CN1578521A (zh) * 2003-07-10 2005-02-09 阿尔卡特公司 从无线移动通信终端的多个无线接口中选择接口的方法
WO2005109791A2 (en) * 2004-05-05 2005-11-17 New Jersey Institute Of Technology A sub-segment based transport layer protocol for wireless medium

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6529734B1 (en) * 1998-11-03 2003-03-04 Telefonaktiebolaget Lm Ericsson Bandwith supply dependent cell level
EP1049297A3 (en) * 1999-04-01 2003-06-18 AT&T Corp. Method of providing quality of service agreement across network boundaries
JP4068780B2 (ja) * 2000-02-24 2008-03-26 富士通株式会社 ＶｏＩＰ通信システムにおける通信状態通知装置，通信状態表示装置，通信状態通知方法及び通信状態通知プログラムを記録した媒体
US7058973B1 (en) * 2000-03-03 2006-06-06 Symantec Corporation Network address translation gateway for local area networks using local IP addresses and non-translatable port addresses
JP4405044B2 (ja) * 2000-06-21 2010-01-27 富士通株式会社 ネットワーク中継装置およびパケット結合方法
US6842463B1 (en) * 2000-07-14 2005-01-11 Nortel Networks Limited Automated and adaptive management of bandwidth capacity in telecommunications networks
JP3936290B2 (ja) * 2000-08-14 2007-06-27 ノキア コーポレイション モード選択手順を備えた通信システム及びその方法
US7171485B2 (en) * 2001-10-17 2007-01-30 Velcero Broadband Applications, Llc Broadband network system configured to transport audio or video at the transport layer, and associated method
JP4363404B2 (ja) * 2006-01-26 2009-11-11 ソニー株式会社 受信装置および方法、並びにプログラム
GB0602314D0 (en) * 2006-02-06 2006-03-15 Ericsson Telefon Ab L M Transporting packets
CN101047711B (zh) 2006-04-27 2010-08-18 华为技术有限公司 Ip报文传输、协商带宽节省能力和节省网络带宽的方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1111847A2 (en) * 1999-12-21 2001-06-27 Alcatel USA Sourcing, L.P. System and method of telecommunications network node ethernet connectivity
WO2002015627A1 (en) 2000-08-14 2002-02-21 Nokia Corporation Communication system and method providing a mode selection procedure
EP1248431A1 (en) 2001-03-27 2002-10-09 Sony International (Europe) GmbH Method for achieving end-to-end quality of service negotiation for distributed multimedia applications
CN1578521A (zh) * 2003-07-10 2005-02-09 阿尔卡特公司 从无线移动通信终端的多个无线接口中选择接口的方法
WO2005109791A2 (en) * 2004-05-05 2005-11-17 New Jersey Institute Of Technology A sub-segment based transport layer protocol for wireless medium

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1940093A4

Also Published As

Publication number Publication date
CN101047711B (zh) 2010-08-18
US8311060B2 (en) 2012-11-13
EP1940093B1 (en) 2015-10-21
ES2558020T3 (es) 2016-02-01
CN101317404B (zh) 2012-02-29
CN101047711A (zh) 2007-10-03
US20090022065A1 (en) 2009-01-22
EP2763360A1 (en) 2014-08-06
EP2763361A1 (en) 2014-08-06
CN101317404A (zh) 2008-12-03
EP2763361B1 (en) 2016-06-08
EP1940093A4 (en) 2008-12-17
EP1940093A1 (en) 2008-07-02

Similar Documents

Publication Publication Date Title
WO2007128217A1 (en) Method of internet protocol(ip) message transmission, negotiated bandwidth saving capability and saving network bandwidth
CN105743924B (zh) 无线ip网络中进行有效多媒体传递的方法和基站
EP1604535B1 (en) Telecommunications apparatuses and method for communicating internet protocol packet data
US7558247B2 (en) Optimized radio bearer configuration for voice over IP
US20090219939A1 (en) Transporting Packets
JP3690316B2 (ja) データ伝送システム及びヘッダ情報付加装置とデータフォーマット変換装置並びにデータ伝送方法
US20070280217A1 (en) Inter-nodal robust mode for real-time media streams in a network
EP1611715A1 (en) Radio telecommunications apparatus and method for communicating internet data packets containing different types of data
WO2016197800A1 (zh) 业务速率的调整方法和装置
JP2006522518A5 (zh)
WO2011153842A1 (zh) 媒体网关间的报文传输方法、媒体网关和无线通信系统
US9148257B2 (en) Method and apparatus for reducing delays in a packets switched network
JP4988039B2 (ja) 回線交換デバイスに使用するｉｍｓサービスを構成するための装置および関連する方法
WO2006026889A1 (fr) Systeme et procede de commande dynamique de debit multimedia dans un systeme ims
US8391284B2 (en) Usage of feedback information for multimedia sessions
EP1773012A1 (en) Method and apparatus for transport of circuit switched services over a transport network in packet mode
EP2226985A1 (en) A method for negotiating the redundant transmission
WO2010075794A1 (zh) 一种压缩复用报文处理方法及装置
KR100847108B1 (ko) Ａｔｍ 기반의 3 ｇｐｐ 망과 ⅰｍｓ 망간의 인터페이스시스템
KR20080015298A (ko) Ｗｃｄｍａ 통신 시스템에서 미디어 게이트웨이 간의 ｉｐ베어러를 설정하는 방법 및 이를 위한 미디어 게이트웨이
Nesser et al. Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents
KR20080094417A (ko) 무선 통신망을 이용한 실시간 멀티미디어 서비스에서 망상황 정보 전송 방법 및 장치

Legal Events

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

Ref document number: 200780000327.7

Country of ref document: CN

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

Ref document number: 07720987

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2007720987

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2007720987

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE