[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2007128217A1 - Procédé de transmission de message de protocole internet (ip), capacité d'économie de largeur de bande négociée et économie de largeur de bande de réseau - Google Patents

Procédé de transmission de message de protocole internet (ip), capacité d'économie de largeur de bande négociée et économie de largeur de bande de réseau 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)
Chinese (zh)
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/fr
Priority to CN2007800003277A priority patent/CN101317404B/zh
Priority to ES07720987.2T priority patent/ES2558020T3/es
Publication of WO2007128217A1 publication Critical patent/WO2007128217A1/fr
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
    • 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/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
    • 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)

Abstract

Procédé de transmission de message de protocole Internet (IP), capacité d'économie de largeur de bande négociée et économie de largeur de bande de réseau, ledit procédé étant le suivant: A) transmission au destinataire de plus d'une capacité d'économie de largeur de bande qu'assure l'expéditeur lui-même; B) sélection par le destinataire d'une de ces capacités spécifiques et transmission à l'expéditeur selon ces capacités spécifiques qu'il assure lui-même; C) détermination par l'expéditeur du type de message IP pour la transmission de données, selon ces capacités spécifiques reçues, sélectionnées par le destinataire; D) transmission par l'expéditeur du message IP au destinataire après constitution du message IP de données de transmission support par le biais du message IP déterminé. On économise ainsi la largeur de bande et les ressources dans le réseau support IP du système de communications.
PCT/CN2007/001414 2006-04-27 2007-04-27 Procédé de transmission de message de protocole internet (ip), capacité d'économie de largeur de bande négociée et économie de largeur de bande de réseau WO2007128217A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP07720987.2A EP1940093B1 (fr) 2006-04-27 2007-04-27 Procédé de transmission de message de protocole internet (ip), capacité d'économie de largeur de bande négociée et économie de largeur de bande de réseau
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
CN2006100760819A CN101047711B (zh) 2006-04-27 2006-04-27 Ip报文传输、协商带宽节省能力和节省网络带宽的方法
CN200610076081.9 2006-04-27

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 (fr) 2007-11-15

Family

ID=38667429

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2007/001414 WO2007128217A1 (fr) 2006-04-27 2007-04-27 Procédé de transmission de message de protocole internet (ip), capacité d'économie de largeur de bande négociée et économie de largeur de bande de réseau

Country Status (5)

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

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
EP2409519B1 (fr) * 2009-03-16 2019-12-18 Nokia Solutions and Networks Oy Optimisation d'un réseau mobile
JP5278532B2 (ja) * 2009-03-19 2013-09-04 富士通株式会社 受信装置、送信装置、受信方法、送信方法、通信システムおよび通信方法
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 中国联合网络通信集团有限公司 数据发送和接收方法、设备及系统
WO2012109857A1 (fr) * 2011-07-29 2012-08-23 华为技术有限公司 Procédé d'ajustement de bande passante, contrôleur de bus et convertisseur de signal
CA2852204C (fr) 2011-10-13 2020-03-24 Samsung Electronics Co., Ltd. Appareil et procede pour la configuration d'un message de controle dans un systeme de radiodiffusion
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 (fr) * 1999-12-21 2001-06-27 Alcatel USA Sourcing, L.P. Système et méthode de connectivité ethernet de noeud de réseau de télécommunications
WO2002015627A1 (fr) 2000-08-14 2002-02-21 Nokia Corporation Systeme de communication et procede utilisant une procedurede selection de mode
EP1248431A1 (fr) 2001-03-27 2002-10-09 Sony International (Europe) GmbH Procédé de négociation de qualité de service de bout en bout en utilisant des applications multimédia distribués
CN1578521A (zh) * 2003-07-10 2005-02-09 阿尔卡特公司 从无线移动通信终端的多个无线接口中选择接口的方法
WO2005109791A2 (fr) * 2004-05-05 2005-11-17 New Jersey Institute Of Technology Protocole de couche de transfert a base de sous-segments pour support sans fil

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 (fr) * 1999-04-01 2003-06-18 AT&T Corp. Procédé pour fournir un accord de qualité de service à travers des limites de réseau
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
AU2000267018A1 (en) * 2000-08-14 2002-02-25 Nokia Corporation Communication system and method providing a mode selection procedure
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 (fr) * 1999-12-21 2001-06-27 Alcatel USA Sourcing, L.P. Système et méthode de connectivité ethernet de noeud de réseau de télécommunications
WO2002015627A1 (fr) 2000-08-14 2002-02-21 Nokia Corporation Systeme de communication et procede utilisant une procedurede selection de mode
EP1248431A1 (fr) 2001-03-27 2002-10-09 Sony International (Europe) GmbH Procédé de négociation de qualité de service de bout en bout en utilisant des applications multimédia distribués
CN1578521A (zh) * 2003-07-10 2005-02-09 阿尔卡特公司 从无线移动通信终端的多个无线接口中选择接口的方法
WO2005109791A2 (fr) * 2004-05-05 2005-11-17 New Jersey Institute Of Technology Protocole de couche de transfert a base de sous-segments pour support sans fil

Non-Patent Citations (1)

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

Also Published As

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

Similar Documents

Publication Publication Date Title
WO2007128217A1 (fr) Procédé de transmission de message de protocole internet (ip), capacité d'économie de largeur de bande négociée et économie de largeur de bande de réseau
EP1604535B1 (fr) Appareils et procédé pour la communication de paquets de data d'internet
CN105743924B (zh) 无线ip网络中进行有效多媒体传递的方法和基站
US7558247B2 (en) Optimized radio bearer configuration for voice over IP
JP3690316B2 (ja) データ伝送システム及びヘッダ情報付加装置とデータフォーマット変換装置並びにデータ伝送方法
US20090219939A1 (en) Transporting Packets
US20070280217A1 (en) Inter-nodal robust mode for real-time media streams in a network
EP1611715A1 (fr) Appareil et procede de radiotelecommunication permettant de communiquer des paquets de donnees internet contenant differents types de donnees
WO2016197800A1 (fr) Procédé et dispositif de réglage pour un taux de service
WO2011153842A1 (fr) Procédé de transmission de message entre des passerelles multimédias, et passerelles multimédias et système de communication radio correspondant
US9332049B1 (en) Media compression for tunneled real-time communications
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
US20050073953A1 (en) Quality of service in communication systems
CN100455119C (zh) 区分业务级别发送寻呼消息的方法和系统
WO2008129408A2 (fr) Utilisation d'informations de rétroaction de sessions multimédia
RU2423013C2 (ru) СПОСОБ И УСТРОЙСТВО ДЛЯ БЫСТРОЙ УСТАНОВКИ ПОЛЬЗОВАТЕЛЬСКОГО СОЕДИНЕНИЯ ПРОТОКОЛА IP ЧЕРЕЗ 3GPP Nb-ИНТЕРФЕЙС С ПРИМЕНЕНИЕМ "ЗАДЕРЖАННОГО УСТАНОВЛЕНИЯ ОБРАТНОГО КАНАЛА-НОСИТЕЛЯ" ПРОТОКОЛА ВIСС И ПРЕДОТВРАЩЕНИЯ ОТКАЗА
EP2226985A1 (fr) Procédé de négociation de transmission redondante
EP1773012A1 (fr) Procédé et dispositif pour le transport de services en mode circuit dans un réseau de transport en mode paquet
WO2010075794A1 (fr) Procédé et appareil de traitement de messages multiplexés compressés
WO2009030151A1 (fr) Procédé, système et dispositif servant à transmettre un message de contrôle de diffusion media en mode continu
KR100847108B1 (ko) Ａｔｍ 기반의 3 ｇｐｐ 망과 ⅰｍｓ 망간의 인터페이스시스템
KR20080015298A (ko) Ｗｃｄｍａ 통신 시스템에서 미디어 게이트웨이 간의 ｉｐ베어러를 설정하는 방법 및 이를 위한 미디어 게이트웨이
Nesser et al. Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents

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