WO2000011849A1 - Procede et appareil assurant un multiplexage utilisateur dans un protocole en temps reel - - Google Patents

Procede et appareil assurant un multiplexage utilisateur dans un protocole en temps reel - Download PDF

Info

Publication number
WO2000011849A1
WO2000011849A1 PCT/US1999/017389 US9917389W WO0011849A1 WO 2000011849 A1 WO2000011849 A1 WO 2000011849A1 US 9917389 W US9917389 W US 9917389W WO 0011849 A1 WO0011849 A1 WO 0011849A1
Authority
WO
WIPO (PCT)
Prior art keywords
mini
connection
rtp
header
user
Prior art date
Application number
PCT/US1999/017389
Other languages
English (en)
Inventor
Baranitharn Subbiah
Original Assignee
Nokia Networks Oy
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 Nokia Networks Oy filed Critical Nokia Networks Oy
Priority to AU57711/99A priority Critical patent/AU5771199A/en
Priority to EP99945006A priority patent/EP1106008A1/fr
Priority to JP2000567001A priority patent/JP2002523981A/ja
Publication of WO2000011849A1 publication Critical patent/WO2000011849A1/fr
Priority to US11/234,594 priority patent/US7674466B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H04L65/104—Signalling gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/103—Media gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • 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]
    • 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
    • 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/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • H04L2012/6472—Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • H04L2012/6481—Speech, voice
    • 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/22—Parsing or analysis of headers

Definitions

  • This invention relates in general to a IP telephone, and more particularly to a method and apparatus for providing efficient user multiplexing in a real-time protocol payload for transporting compressed speech between IP telephony gateways.
  • An organization's computer network has become its nervous system. Organizations have combined desktop work stations, servers, and hosts into Local Area Network (LAN) communities. These Local Area Networks have been connected to other Local Area Networks and to Wide Area Networks (WANs). It has become a necessity of day-to-day operation that pairs of systems must be able to communicate when they need to, without regard to where they may be located in the network.
  • LAN Local Area Network
  • WAN Wide Area Network
  • Interconnection Reference Model introduced by the International Organization for Standardization (ISO) has led to an impressive degree of interworking, which generally allows end-user applications to work very well between systems in a network. Implementations are based on written standards that have been made available by volunteers from dozens of computer vendors, hardware component vendors and independent software companies.
  • IP Internet Protocol
  • the Internet Protocol was designed to accommodate the use of host and routers built by different vendors, encompass a growing variety of growing network types, enable the network to grow without interrupting servers, and support higher-layer of session and message-oriented services.
  • the IP network layer allows integration of Local Area Network "islands".
  • IP telephony is maturing as a technology and a service, which places it in direct conflict with the conventional public telephone network. New types of IP telephony equipment are being introduced and small Internet service providers and niche carriers are beginning to offer IP telephony services.
  • IP telephony or voice-over-IP
  • voice-over-IP has great potential to compete against the traditional public voice network
  • many obstacles must first be overcome.
  • the quality of Internet telephone calls is not as good as public network calls.
  • IP telephony network equipment is new and lacks features that carriers desire.
  • IP is the dominant transport protocol in access networks.
  • the penetration of Internet and subsequent IP connectivity to homes and businesses have given impetus to integrated services over IP which means voice, data and video over a single IP network.
  • IP networks offer a single class of service called best effort, which can not guarantee any Quality of Service (QoS) to applications.
  • QoS Quality of Service
  • IETF Internet Engineering Task Force
  • IP telephone has emerged as a potential application to challenge the traditional phone companies by offering long distance telephone service over Internet for low prices.
  • IP telephone gateways and accessories to provide IP telephony service to corporate customers and Internet Service Providers (ISPs).
  • IP telephone standards such as H.323, H.225 and H.245 have been standardized to enhance the rapid deployment of IP telephone services in global Internet.
  • IP telephone is not a reality in public Internet today, it has been successful in Intranet and Virtual Private Networks (VPN) environments.
  • VPN Virtual Private Networks
  • IP telephone will be a niche service once QoS issues in IP networks become a reality.
  • IP networks offer only best effort service, whereas delay sensitive applications such as voice and interactive video require a deterministic guarantee on the delay, delay variation and packet loss from the network.
  • this lack of QoS guarantee in IP networks is claimed as the major problem to provide real time services such as IP telephone over Internet.
  • IP telephone providers over provision the links (networks) that interconnect IP telephone gateways. This additional bandwidth enables the IP packets to be transmitted with less delay thus providing a reasonable voice quality. It has been demonstrated in Intranet as well as VPNs that IP telephone services can match the voice quality offered by traditional telephone networks.
  • IP telephone gateways act as an interface between the existing PSTN and PBX networks and IP networks. This method allows one PSTN user to call another PSTN user connected through IP telephone gateways thus eliminating the need for long distance telephone network.
  • RTP Real-time Transport Protocol/User Datagram Protocol/Internet Protocol
  • RTP is an Internet protocol for transmitting real-time data such as audio and video.
  • RTP itself does not guarantee real-time delivery of data, but it does provide mechanisms for the sending and receiving applications to support streaming data.
  • RTP runs on top of the UDP protocol, although the specification is general enough to support other transport protocols.
  • the User Datagram Protocol is a connectionless protocol that, like TCP, runs on top of IP networks. Unlike TCP/IP, UDP/IP provides very few error recovery services, offering instead a direct way to send and receive datagrams over an IP network.
  • IP telephony gateways provide an interface between the existing circuit switched telephone networks (such as PSTN and GSM) and the packet switched IP data networks.
  • PSTN and GSM circuit switched telephone networks
  • IP telephony gateways In traditional IP telephony applications, telephone calls between PSTN users interconnected by a pair of IP telephony gateways to compress incoming PSTN speech samples generate packets with sizes ranging from 5 to 20 bytes per speech sample.
  • G.723.1 the most popular IP telephony codec and the
  • VoIP Voice over IP
  • IMTC International Multimedia Teleconferencing Consortium's
  • VoIP Voice over IP
  • IMTC Voice over IP
  • Many codecs used in cellular environment generate less than 10 byte packet per speech sample.
  • Small size packets are subjected to large overhead when transferred using the Real time Transport Protocol (RTP).
  • RTP/UDP/IP overhead is 40 bytes (12+8+20) for a simple speech packet.
  • a 10 byte packet transferred via RTP/UDP/IP increases the overhead to 80% (40 byte overhead/50 byte overhead plus packet).
  • a single UDP/IP connection (a pair of UDP ports) is established between the gateways requiring a large state (memory) to be maintained at the telephony gateways, thereby making these less scaleable.
  • Congestion in IP networks results in packet loss at routers and UDP does not have any retransmission mechanism to recover lost packets. Also, real time applications such as speech is intolerant to delay caused by re-transmission.
  • each individual speech packet is transmitted as a IP packet, which generates a large number of packets between gateways. This heavy traffic volume is a potential situation for congestion and packet loss at IP routers.
  • the present invention discloses an efficient real-time transport protocol multiplexing method and apparatus for transporting compressed speech between IP telephony gateways.
  • the present invention solves the above-described problems by providing a method and apparatus for eliminating inefficiencies in transporting short packets between IP telephony gateways connected by an IP network, wherein the method and apparatus enables a number of users to share a single RTP/UDP/IP connection.
  • a protocol in accordance with the principles of the present invention includes creating a header for a plurality of data packets, each header providing identification of a user associated with a packet, adding each header to the data packet associated therewith to form mini-IP payloads, multiplexing the mini-IP payloads into a RTP payload and transmitting the RTP payload over a single RTP/UDP/IP connection.
  • Other embodiments of a system in accordance with the principles of the invention may include alternative or optional additional aspects.
  • One such aspect of the present invention is that the plurality of data packets are received from two or more users.
  • the identification of a user further comprises a unique channel identifier for each of the two or more users.
  • the channel identifier is assigned to packets from a user when the user requests access to the IP telephone network.
  • the header comprises a length indicator, the length indicator indicating the size of the data packet associated with the header.
  • the length indicator comprises six bits for allowing a maximum of a thirty-two byte data packet.
  • the header further comprises a sequence number, the sequence number marking data packets transmitted from a user to identify data packet loss.
  • sequence number further comprises two bits, the two bits identifying a maximum of three consecutive data packet losses.
  • Another aspect of the present invention is that the header of each data packet multiplexed into the RTP payload is transparent to intermediate IP routers.
  • the protocol further includes de-assembling the RTP payload back into the data packets.
  • the protocol further includes receiving at a local gateway an access request from a user at a remote IP gateway, transmitting a setup message to the remote IP gateway using an IP connection and establishing a user plane connection for receiving data packets from a user after successful completion of a connection setup.
  • the protocol further includes, after receiving an access request from a user, determining whether an existing RTP/UDP/IP connection is available, using an existing RTP/UDP/IP connection when an existing RTP/UDP/IP connection is determined to be available, creating a new RTP/UDP/IP connection when an existing RTP/UDP/IP connection is determined not to be available and creating a setup message using a local UDP port number, remote port number, channel identifier.
  • the protocol further includes recovering, at the remote gateway, a local UDP port number, remote port number, channel identifier from the setup message, verifying at the remote gateway whether the channel identifier is free and accepting the connection when the channel identifier is free.
  • the accepting the connection further includes updating a channel identifier table at the remote gateway and replying to the local gateway with a connect message.
  • the protocol further includes replying to the local gateway with a rejection message when a problem allocating the connection occurs.
  • the protocol further includes receiving at the local entity the connect message, confirming at the local entity the channel identifier and informing the user requesting access.
  • the protocol further includes controlling the multiplexing and transmitting of the RTP payload using a timer.
  • the data packets include compressed voice data.
  • An IP telephone network includes a remote IP gateway and a local IP gateway, wherein the remote and local IP gateways communicate using the protocol.
  • a MINI-IP controller includes means for providing control plane signaling, control plane signaling being used to setup a connection to a remote peer MINI-IP controller and means for providing user plane signal, user plane signaling being used to transmit data packets to a user associated with the remote peer MINI-IP controller using the protocol.
  • An RTP payload includes an RTP header, a plurality of data packets representing data from a plurality of users and a plurality of MINI-IP headers, each of the plurality of packets having a MINI-IP header attached thereto, each of the MINI-IP headers comprising a user identifier for identifying one of the plurality of users being associated with each of the packets, and each MINI-IP header and packet combination forming a MINI-IP payload, the MLNI-IP payloads being multiplexed together to form a RTP packet.
  • a base station, base station controller and mobile switching center according to the present invention include a MINI-IP controller that eliminates inefficiencies in transporting packets using the MLNI-IP protocol.
  • Fig. 1 shows an application scenario in which two sides of the PSTN/PBX are interconnected by IP telephone gateways;
  • Figs. 2a-b illustrate MINI-IP headers according to the present invention
  • Fig. 3 illustrates the multiplexing of MINI-IP payloads in a RTP packet using the MINI-IP header
  • Fig. 4 illustrates the location of the MINI-IP controller in a IP telephone layered model
  • Fig. 5 illustrates the user plane and control plane in a MINI-IP gateway environment
  • Fig. 6 illustrates an example of a CID table
  • Fig. 7 illustrates the use of the TIMER_MUX according to the present invention
  • Fig. 8 illustrates the application of MINI-IP being restricted to transport voice users between IP telephony gateways
  • Fig. 9 illustrates the application of a MINI-IP controller in a radio access network
  • Fig. 10 is a plot of the number of users on a single RTP/UDP/IP connection versus the bandwidth in Kbps for G.723.1 ;
  • Fig. 11 is a plot of the number of users on a single RTP/UDP/IP connection versus the bandwidth in Kbps for G.729;
  • Fig. 12 illustrates a comparison of the percent overhead verses the number of users for different methods.
  • the present invention provides a an efficient method and apparatus for transporting short packets such as compressed speech packets between IP telephony gateways connected by a IP network.
  • the present invention enables a number of low bit rate connections (compressed speech) to share a single RTP/UDP/IP connection, thus reducing the RTP/UDP/IP overhead.
  • a MINI-IP header (2 byte) is added to each packet from an user before it is assembled with packets from other users into an RTP payload.
  • a unique Channel Identifier (CID) is proposed to identify individual users on a single RTP/UDP/IP connection.
  • Channel ID negotiations between the peer gateway entities is carried out by a new signaling procedure called MLNI-IP signaling.
  • the MINI-IP method reduces the overhead for short packets by 60% thus improving the bandwidth efficiency.
  • Other advantages of the present invention include a decrease in the number of UDP/TP connections between gateways and a decrease in the traffic congestion at intermediate IP routers.
  • the present invention may be implemented, for example, in IP telephone gateways, Radio Access Network (RAN) access nodes, and IP access nodes by simply adding an external MINI-IP control module.
  • the MLNI-IP method uses the existing bearer protocols such as RTP, TCP, UDP ad IP and does not require any changes to the traditional IP network functionalities.
  • Fig. 1 shows an application scenario 100 in which two sides of the
  • PSTN/PBX 100, 112 are interconnected by IP telephone gateways 120, 122.
  • IP telephone gateways 120, 122 a telephone call between PSTN/PBX users 110, 112 located at either side of the gateways 120, 122 is carried by a separate RTP/UDP/IP connection.
  • the codecs used at the telephone gateway to compress incoming PSTN/PBX voice calls generates packets with a size ranging from 5 to 20 bytes.
  • the IP telephone standard G.723.1 specifies a codec that generates a 20 byte packet at the interval of 30 ms speech sample.
  • Many codecs used in cellular environments generate a small packet, e.g., on the average a 10 byte packet per speech sample. This small size packets require a large overhead when they are transferred using the Real time Transport Protocol (RTP).
  • RTP Real time Transport Protocol
  • the RTP/UDP/IP overhead is 40 bytes (12+8+20) for each speech packet. For example, if a 10 byte packet is transferred via RTP/UDP/IP then the overhead is 80%, i.e., 40/50.
  • a single UDP/IP connection is established between the gateways 120, 122 requiring a large number of states (memory) to be maintained at the telephone gateways 120, 122.
  • Congestion in IP networks results in packet loss at routers and UDP does not have any retransmission mechanism to recover lost packets. Also, real time applications such as speech are intolerant to delay caused by re-transmission.
  • each individual speech packet is transmitted as a IP packet, which generates a large number of packets between gateways. This heavy traffic volume is a potential situation for congestion and packet loss at IP routers.
  • RTP/UDP/IP header compression is applied for slow speed links.
  • this method requires compressing/decompressing at routers as well as some additional processing overhead.
  • Figs. 2a-b and 3 illustrate the use of MLNI-IP headers to reduce header overhead according to the MLNI-IP protocol.
  • no compression is utilized, yet an equal or better bandwidth efficiency is achieved.
  • Overhead is reduced by multiplexing two or more (e.g., up to 256) low bit rate connections in a single RTP/IP/UDP connection using a MINI-IP header 202 as illustrated in Fig. 2a.
  • overhead may be reduce using the MLNI-IP header 204 illustrated in Fig. 2b.
  • the present invention is not meant to be limited to the particular MLNI-IP headers illustrated in Figs.
  • the MINI-IP headers 202, 204 illustrated in Figs. 2a-b are presented for illustration only. Rather, those skilled in the art will recognize that the MINI-IP headers 202, 204 enables multiplexing of multiple small size packets, and is added to each mini packet before it is assembled with other mini packets as an RTP payload, as illustrated in Fig. 3.
  • each user is allocated an unique Channel Identifier (CID) which is negotiated during connection setup.
  • CID Channel Identifier
  • the CID negotiation procedures is carried out by MINI-IP signaling, which uses a TCP/IP connection for reliable transport.
  • the most suitable application scenarios for MINI-IP method include IP telephone gateways connecting PSTN/PBX/GSM users.
  • the MINI-IP header 202 uses a two byte header, called MLNI-IP header, for each mini packet.
  • the MINI-IP header 202 includes a Channel Identifier (CID) 210, a Length Indicator (LI) 212, and a Sequence Number (SN) 214.
  • CID Channel Identifier
  • LI Length Indicator
  • SN Sequence Number
  • the MINI-IP header 202 allows many users to share a single RTP/UDP/IP connection thus reducing the RTP/UDP/IP overhead per packet.
  • the MINI-IP header includes a CID field 210, which identifies a single user among users haring a single RTP/UDP/IP connection.
  • a CID 210 is assigned at the time of the request for access to the IP network and it is unchanged throughout the connection time.
  • the length of the CID field 210 is 8 bits, which limits the number of users per single RTP connection to 256.
  • the LI field 212 indicates the size of the payload (speech packet) and the 6 bits allow a maximum of 64 byte payload.
  • the variable size of the LI field 212 allows different codecs to share a single connection and offers the flexibility to transport any low bit rate connection using MINI-IP method.
  • the size of the LI field 212 is limited to 64 bytes since most of the codes available today (G.723.1, G.729) generates packets less than 20 bytes per speech sample.
  • the 2 bit Sequence Number (SN) field 214 is used for marking the voice packets transmitted from a single user in modulo 4 method, which can be used at the receiver to identify any packet loss. The module 4 scheme will be able to identify up to 3 consecutive packet losses at IP layer.
  • the MINI-IP header 204 includes a Channel Identifier (CID) 210, a Length Indicator (LI) 212, a Transition bit (T) 216 and a Reserved bit (X) 218.
  • the Channel Identification (CID) 210 in Fig. 2b is an 8 bit field which allows a maximum of 256 users to share a single RTP/UDP/IP connection. When the total number of users exceeds 256, a new RTP/UDP/IP connection is established.
  • the LI field 212 is a 6 bit field which allows a maximum payload size of 64 bytes.
  • the Transition bit (T) 216 is used to identify any change in processing that was applied to a mini-packet.
  • the Reserved bit (X) 218 is currently undefined, but may be used, for example, as an indication of a header extension and Dual Tone Multi-Frequency (DTMF).
  • DTMF Dual Tone Multi-Frequency
  • the length of the fields could be modified within the 2 byte format.
  • other fields could be substituted and the length of the fields is not meant to be limited to provide a MINI-IP header of 2 bytes.
  • the assembly of mini packets into a single RTP/UDP/IP payload 300 is shown in Fig. 3.
  • the mini packets 310 follow the RTP header 312 and each mini packet 320 is delineated by the two byte MINI-IP header 312.
  • This approach requires a simple de-multiplexing algorithm at the receiver.
  • the MINI-IP header 312 in the RTP payload 300 is transparent to the intermediate IP routers, the MINI-IP according to the present invention does not cause any problems in terms of IP packet forwarding and other functionalities at the IP layer.
  • the traditional Header Error Controls (HEC) found in many protocols is excluded because MINI-IP relies on the higher layer checksum (UDP checksum) to protect the headers and payload from any transmission errors.
  • HEC Header Error Controls
  • the MINI-IP controller is the key element which will be added to a IP telephone gateways to implement the MINI-IP method.
  • the major function of the MINI-IP controller are:
  • RTP payload iii De-assemble MINI-IP packets from the RTP payload iv. Communicate to the remote controller to forward any request and/or control message
  • the MLNI-IP controller 410 is inserted between the IWF function (not shown) of the PSTN/GSM/PBX network 420 and the RTP module 422 in the IP telephone gateway.
  • the MINI-IP controller 410 is capable of receiving connection request from PSTN/GSM/PBX users 420 and setting up a channel on an existing or a new RTP/UDP/IP connection.
  • the MINI-IP controller 410 acts as an application to the layers below 422, 424, 426, 428 (RTP/UDP/IP) and uses the bearer services offered by the lower layers for effective multiplexing. Other functions of the controller include open and close RTP/UDP connections, keep track of the active users on all UDP connections, and provide inter-working with PSTN/GSM/PBX call control features.
  • the user plane 510 and control plane 520 in a MINI-IP gateway environment 500 are shown in Fig. 5.
  • the control plane signaling 520 is needed because peer entities required to negotiate a channel for an "incoming call request" on an existing or on a new RTP/UDP connection.
  • a setup message will be transmitted upon receiving a call request from a PSTN/GSM/PBX user 530.
  • the setup message include UDP connection identifiers and CID.
  • the control signaling 520 is carried by a TCP/IP connection 540 for assured data transfer.
  • the user plane 510 association is made after a successful connection setup.
  • the user plane 510 data is carried over RTP/UDP/IP layers 542 similar to the audio and video transport over IP networks.
  • the MINI-IP signaling works as follows.
  • a call request from PSTN/PBX/GSM user 530 triggers a CID setup sequence between the peer MINI-IP controllers 550, 552.
  • the MINI-IP controller 550 verifies if there is any existing RTP/UDP/IP connection to the remote gateway 560. If there is none or any existing connection(s) is full (no free CID) then the MINI-IP controller 520 establishes a new RTP/UDP/IP connection. The new UDP connection is established throughout UDP sockets. If there exists a UDP connection and free CIDs for the call request, then MINI-IP uses the same UDP port number.
  • a setup message is created with the local UDP port number, remote UDP port number, and CID number, and is transmitted to the remote gateway.
  • the remote gateway 560 recovers the information within the setup message and verifies that the requested CID is still free on its local table. If the call can be accepted then the local gateway 562 updates its local CID table and replies with a connect message.
  • Fig. 6 illustrates an example of a CID table 600. In the CID table 600 of Fig.
  • CID 25 610 is assigned and CID 26 612 is idle.
  • the local UDP port number 620, remote port number 622, local user ID 624 and remote user ID 626 are provided for each CID that has been assigned.
  • the remote gateway 560 if it experiences any problem in allocating the connection, such as CID collision, then it transmits a reject message.
  • the CID collision problem can be solved by existing schemes used in other protocols.
  • the local entity 562 Upon receiving a connect message, the local entity 562 confirms the CID association and informs the corresponding user 530.
  • the MINI-IP signaling is closely associated with the call control signaling used in PSTN/GSM/PBX networks.
  • the MINI-IP controller 550 establishes a user channel only within the IP network. Those skilled in the art will recognize that the call control signaling outside the IP network is beyond the scope of MINI-IP controller.
  • a timer controls the waiting time between the placement of a first packet in the RTP payload and the time to transmit the first packet to the remote peer.
  • This timer (TIMER_MUX) is essential to control the delay accumulated at the multiplexing end for voice packets.
  • Fig. 7 illustrates the use of the TIMER MUX 700 according to the present invention.
  • mini-packets 710 are received at a scheduler 712.
  • the scheduler schedules packets for assembly into an RTP payload by placing packets into a packet assembly buffer 720.
  • an RTP packet is transmitted.
  • the TIMER_MUX value depends on the link speed and transfer delay. The higher the TIMER_MUX value the better the bandwidth efficiency. However, higher TIMER_MUX value could increase the delay for voice packets. Speech is somewhat tolerant to packet loss when compared to data. But, beyond a certain limit, packet loss renders the speech inaudible and causes inconvenience to the user.
  • the MINI-IP header consist of a two bit Sequence Number (SN) field.
  • SN Sequence Number
  • This two bit SN allows for a modulo 4 style sequence numbering at the transmitter.
  • SN could start at 0 and follow the sequence of 1,2,3,0,1,2.
  • the MINI-IP controller could detect the loss at individual user level and take appropriate actions specified by the operator. As can be seen, this 2 bit field allows packet loss protection of up to 3 consecutive packets at IP layer.
  • Fig. 8 illustrates the application 800 of MINI-IP being restricted to transport voice users between IP telephony gateways.
  • Some of the most obvious scenarios 800 are shown in Fig. 8.
  • Traditional telephony users such as PSTN 810 and PBX 820 interconnected by IP telephone gateways 830 is an ideal scenario where MLNI- IP improves me bandwidth efficiency of the IP network.
  • MINI-IP can also be used in Radio Access Network (RAN) of a wireless network.
  • RAN Radio Access Network
  • Fig. 9 illustrates the application of a MINI-IP controller in a RAN 900.
  • MINI-IP controller 910 is part of the BS 912 connected through IP network 920 to another MINI-IP controller 930 at the radio network controller/base station controller (RNC/BSC) 932.
  • the base station controller 932 is coupled to a mobile switching center (MSC) 940 that includes a MINI-IP controller 942.
  • MSC mobile switching center
  • the conversations of a number of GSM telephone users will be transported using IP telephony along with data traffic in the same IP network.
  • the MINI-IP is meant to be utilized in MINI-IP controllers in any component connected through a wireline or wireless IP network.
  • the important reason for multiplexing small packets into a single RTP payload is to reduce the RTP/UDP/IP overhead for each packet.
  • the overhead is 66.7% in case of 20 byte G.723.1 packet (40 byte overhead/60 byte overhead + packet) and 80% for a 10 byte G.729 packet (40 byte overhead/50 byte overhead + packet).
  • the overhead for all these users could very will exceed the total capacity of the link.
  • the MINI-IP protocol described above reduces the overhead dramatically.
  • Figs. 10-12 illustrate the differences in bandwidth requirement of MINI-IP and IP.
  • the bandwidth requirement for a traditional scheme (RTP/UDP/IP) is compared to MINI-IP and the results are shown in Figs. 10 and 11.
  • Fig. 10 is a plot 1000 of the number of users 1010 on a single RTP/UDP/IP connection versus the bandwidth in Kbps 1020 for G.723.1
  • Fig. 11 is a plot 1100 of the number of users 1110 on a single RTP/UDP/IP connection versus the bandwidth in Kbps 1120 for G.729.
  • the rate of G.723.1 is 5.6 Kbps and the rate of G.729 is 8 Kbps.
  • the actual bandwidth requirement for increasing number of users is calculated by simply multiplying the number of users and the peak bandwidth. For example, the actual bandwidth requirement for 10 G.723.1 users is 56 Kbps.
  • the bandwidth required by the traditional IP telephone method is calculated by adding the overhead of 66.7% (G.723.1) and 80% (G.729) per user.
  • the bandwidth requirement for MINI-IP is calculated by adding the percentage of overhead due to multiplexing the number of users in a single UDP connection. The results indicate that the bandwidth requirement for transporting the same number of users through MINI-IP 1030, 1130 is very low compared to the traditional IP (RTP/UDP/IP).
  • the overhead 1200 of different speech codecs are shown in Fig. 12.
  • the overhead due to RTP/UDP/IP is constant for both codecs since the RTP/UDP/IP overhead for each packet is constant.
  • MINI-IP method is able to multiplex small packets into a single RTP/UDP /IP payload thus reducing the overhead to a minimum.
  • the overhead due to MINI-IP 1230, 1240 on both codecs provides that MINI-IP is efficient in utilizing the bandwidth of the output link.
  • the overhead reduces further. Since MINI-IP utilize the bandwidth efficiently and does not generate as many individual IP packets, it avoids the congestion at intermediate IP routers. Also, high bandwidth efficiency allows the IP packets to be forwarded quickly within the network thus reducing the overall delay for speech packets.
  • MINI-IP provides an increase in bandwidth efficiency between IP telephone gateways.
  • MINI-IP allows many users to share a single RTP/UDP/IP connection, thus reducing the IP overhead for each packet.
  • the codecs used in telephone applications today generate an average packet size of 10 byte per speech sample.
  • the RTP/UDP/IP overhead per speech packet ranges from 66% to 80%. This enormous overhead lowers the bandwidth efficiency as well as causes congestion by generating large number of short IP packets.
  • Traditional IP telephony gateways that interconnects PSTN/GSM/PBX systems do not utilize the bandwidth efficiently, whereas MINI-IP allows a number of users to share a single connection thereby reducing the overhead per packet transmitted.
  • MINI-IP provides a second advantage of reducing the number of UDP connections between gateways by sharing a single RTP/UDP/IP
  • the third advantage is that the MINI-IP method reduces the changes for congestion at intermediate IP routers.
  • MINI-IP reduces the number of IP packets by multiplexing mini packets in a single RTP payload, which helps to lower the congestion at the routers as well as reduces the complexity of IP packet forwarding.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)
  • Communication Control (AREA)

Abstract

L'invention porte sur un procédé de multiplexage efficace de protocole de transport en temps réel et sur un appareil destiné à acheminer des paroles comprimées entre des passerelles téléphoniques de protocole Internet. Le protocole élimine les inefficacités d'usage de largeur de bande dans l'acheminement de paquets brefs entre des noeuds connectés par un réseau de protocole Internet. Le procédé et l'appareil de cette invention permettent à un nombre d'utilisateurs de partager une connexion unique Protocole de transport en temps réel/Protocole de datagrammes utilisateur/Protocole Internet (RTP/UDP/IP connexion). Le protocole consiste à créer une en-tête pour une pluralité de paquets de données, chaque en-tête générant une indication concernant un utilisateur associé à un paquet, ajouter chaque en-tête au paquet de données associé de façon à obtenir des charges utiles MINI-IP, multiplexer ces charges utiles MINI-IP en une charge utile RTP et transmettre la charge utile RTP sur une connexion unique RTP/UDP/IP.
PCT/US1999/017389 1998-08-20 1999-08-05 Procede et appareil assurant un multiplexage utilisateur dans un protocole en temps reel - WO2000011849A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
AU57711/99A AU5771199A (en) 1998-08-20 1999-08-05 Method and apparatus for providing user multiplexing in a real-time protocol
EP99945006A EP1106008A1 (fr) 1998-08-20 1999-08-05 Procede et appareil assurant un multiplexage utilisateur dans un protocole en temps reel -
JP2000567001A JP2002523981A (ja) 1998-08-20 1999-08-05 リアルタイム・プロトコルにおけるユーザ・マルチプレクシングを供給する方法及び装置
US11/234,594 US7674466B2 (en) 1999-08-05 2005-09-23 Targeting and prolonging association of drugs to the luminal surface of the pulmonary vascular endothelial cells using antibodies that bind to ICAM-1

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13727698A 1998-08-20 1998-08-20
US09/137,276 1998-08-20

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/234,594 Continuation US7674466B2 (en) 1999-08-05 2005-09-23 Targeting and prolonging association of drugs to the luminal surface of the pulmonary vascular endothelial cells using antibodies that bind to ICAM-1

Publications (1)

Publication Number Publication Date
WO2000011849A1 true WO2000011849A1 (fr) 2000-03-02

Family

ID=22476609

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/017389 WO2000011849A1 (fr) 1998-08-20 1999-08-05 Procede et appareil assurant un multiplexage utilisateur dans un protocole en temps reel -

Country Status (4)

Country Link
EP (1) EP1106008A1 (fr)
JP (1) JP2002523981A (fr)
AU (1) AU5771199A (fr)
WO (1) WO2000011849A1 (fr)

Cited By (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000072532A1 (fr) * 1999-05-24 2000-11-30 Rutgers, The State University Of New Jersey Systeme et procede pour reduire le trafic de paquets dans un reseau
WO2000072537A1 (fr) * 1999-05-24 2000-11-30 Nokia Corporation Passerelle pour systeme radio
WO2001058187A1 (fr) * 2000-01-31 2001-08-09 Telefonaktiebolaget Lm Ericsson (Publ) Systeme de station de base ip
WO2001058074A2 (fr) * 2000-02-04 2001-08-09 Telefonaktiebolaget Lm Ericsson (Publ) Remplacement des totaux de controle de couches de transport dans une compression d'en-tete a base de totaux de controle
WO2001074099A1 (fr) * 2000-03-28 2001-10-04 Simoco International Limited Infrastructure de radiocommunications utilisant un protocole de communication par paquets
WO2002009454A2 (fr) * 2000-07-26 2002-01-31 Telefonaktiebolaget Lm Ericsson Systeme et procede pour combiner plusieurs synchroniseurs de mise a jour periodique
WO2002035863A2 (fr) * 2000-10-27 2002-05-02 Nortel Networks Limited Protocole ip de couche d'adaptation permettant d'optimiser la transmission de paquets d'information sur une connexion de liaison terrestre de reseau cellulaire
EP1215859A1 (fr) * 2000-12-14 2002-06-19 Siemens Aktiengesellschaft Methode et dispositif pour transmettre des données d'utilisation different sur un réseau à commutation de paquet
WO2002060152A2 (fr) * 2001-01-26 2002-08-01 Pogo Mobile Solutions Limited Ameliorations se rapportant a des systemes de communication sans fil
EP1296488A2 (fr) * 2001-09-20 2003-03-26 Lucent Technologies Inc. Multiplexage de paquets de donneés de IP dans une trame de donneés de MPLS
WO2003088614A1 (fr) * 2002-04-15 2003-10-23 Veraz Networks Ltd. Procede et appareil de transmission efficace de trafic voip
WO2003101073A1 (fr) 2002-05-21 2003-12-04 General Instrument Corporation Association de parametres de securite pour ensemble de protocoles de flux connexes
EP1443733A2 (fr) * 2003-01-30 2004-08-04 Avaya, Inc. Identification de flux de données par paquets pour multiplexage
EP1494425A1 (fr) 2003-07-03 2005-01-05 Microsoft Corporation Format de charge utile de RTP
EP1525690A1 (fr) * 2002-08-02 2005-04-27 NMS Communications Procedes et appareil de regroupement de signaux reseau et de reduction de largeur de bande
US7107354B2 (en) 2003-02-07 2006-09-12 Avaya Technology Corp. Multiplexer discovery and parameter exchange
WO2006104772A1 (fr) * 2005-03-31 2006-10-05 Lucent Technologies Inc. Procede et dispositif d'augmentation de l'efficacite de la radiofrequence pour combinaison de systeme vocal sur internet et de trafic de donnees
KR100689473B1 (ko) * 2000-08-29 2007-03-08 삼성전자주식회사 통신시스템에서 프로토콜 헤더 압축장치 및 방법
US7237108B2 (en) 2001-09-26 2007-06-26 General Instrument Corporation Encryption of streaming control protocols and their headers
US7243366B2 (en) 2001-11-15 2007-07-10 General Instrument Corporation Key management protocol and authentication system for secure internet protocol rights management architecture
US7251328B2 (en) 2003-01-14 2007-07-31 General Instrument Corporation System for secure decryption of streaming media using selective decryption of header information and decryption of reassembled content
GB2444096A (en) * 2006-11-22 2008-05-28 Adam Hill Improved voice over IP systems
US7437457B1 (en) 2003-09-08 2008-10-14 Aol Llc, A Delaware Limited Liability Company Regulating concurrent logins associated with a single account
US7447211B1 (en) 2004-03-23 2008-11-04 Avaya Inc. Method and apparatus of establishing a communication channel using protected network resources
WO2009026845A1 (fr) * 2007-08-23 2009-03-05 Huawei Technologies Co., Ltd. Procédé d'émission et de réception de données, appareil de point d'accès sans fil, passerelle et système de communication
US7634816B2 (en) 2005-08-11 2009-12-15 Microsoft Corporation Revocation information management
US7680100B1 (en) 2004-09-30 2010-03-16 Avaya Inc. Internet protocol appliance manager
US7720096B2 (en) 2005-10-13 2010-05-18 Microsoft Corporation RTP payload format for VC-1
US7769880B2 (en) 2005-07-07 2010-08-03 Microsoft Corporation Carrying protected content using a control protocol for streaming and a transport protocol
DE10085160B4 (de) * 1999-11-03 2011-08-11 Telefonaktiebolaget Lm Ericsson (Publ) Sprachpakete in IP-Netz
US8255989B2 (en) 2001-09-26 2012-08-28 General Instrument Corporation Access control and key management system for streaming media
US8364951B2 (en) 2002-12-30 2013-01-29 General Instrument Corporation System for digital rights management using distributed provisioning and authentication
CN103327030A (zh) * 2013-07-10 2013-09-25 上海庆科信息技术有限公司 一种利用Wi-Fi报文长度进行信息传输的方法
CN103841523A (zh) * 2014-03-14 2014-06-04 上海庆科信息技术有限公司 一种基于多播物理地址进行Wi-Fi报文长度的信息传输方法
US10135720B2 (en) 2016-08-03 2018-11-20 Anchorfree Inc. System and method for virtual multipath data transport
US10938786B2 (en) 2017-12-01 2021-03-02 Twingate Inc. Local interception of traffic to a remote forward proxy

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
B. SUBBIAH, S. SENGODAN: "User Multiplexing in RTP payload between IP Telephony Gateways", INTERNET DRAFT, 21 August 1998 (1998-08-21), XP002127741, Retrieved from the Internet <URL:http://www.fokus.gmd.de/research/cc/glone/projects/ipt/players/ietf/draft-ietf-avt-mux-rtp-00.txt> [retrieved on 20000114] *
J.ROSENBERG, H.SCHULZRINNE: "An RTP Payload Format for User Multiplexing", INTERNET DRAFT, 6 May 1998 (1998-05-06), pages 1 - 10, XP002127739, Retrieved from the Internet <URL:http://ee.mokwon.ac.kr/%7Ejspark/rtp/standard/internet-drafts/draft-ietf-avt-aggregation-00.txt> [retrieved on 20000114] *
K.TANIGAWA, T.HOSHI, K.TSUKADA: "An RTP Simple Multiplexing Transfer Method for Internet Telephony Gateway", INTERNET DRAFT, 16 June 1998 (1998-06-16), XP002127740, Retrieved from the Internet <URL:ftp://ftp.bbnplanet.com/internet-drafts/draft-tanigawa-rtp-multiplex-00.txt> [retrieved on 20000114] *

Cited By (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7068620B1 (en) 1999-05-24 2006-06-27 Nokia Corporation Method and apparatus for efficiently encoding wireless data packet headers
WO2000072537A1 (fr) * 1999-05-24 2000-11-30 Nokia Corporation Passerelle pour systeme radio
WO2000072532A1 (fr) * 1999-05-24 2000-11-30 Rutgers, The State University Of New Jersey Systeme et procede pour reduire le trafic de paquets dans un reseau
DE10085160B4 (de) * 1999-11-03 2011-08-11 Telefonaktiebolaget Lm Ericsson (Publ) Sprachpakete in IP-Netz
WO2001058187A1 (fr) * 2000-01-31 2001-08-09 Telefonaktiebolaget Lm Ericsson (Publ) Systeme de station de base ip
US6996092B1 (en) 2000-01-31 2006-02-07 Telefonaktiebolaget Lm Ericsson (Publ) IP-based base station system
WO2001058074A2 (fr) * 2000-02-04 2001-08-09 Telefonaktiebolaget Lm Ericsson (Publ) Remplacement des totaux de controle de couches de transport dans une compression d'en-tete a base de totaux de controle
WO2001058074A3 (fr) * 2000-02-04 2002-01-17 Ericsson Telefon Ab L M Remplacement des totaux de controle de couches de transport dans une compression d'en-tete a base de totaux de controle
US6609224B1 (en) 2000-02-04 2003-08-19 Telefonaktiebolaget Lm Ericsson (Publ) Replacement of transport-layer checksum in checksum-based header compression
WO2001074099A1 (fr) * 2000-03-28 2001-10-04 Simoco International Limited Infrastructure de radiocommunications utilisant un protocole de communication par paquets
WO2002009454A3 (fr) * 2000-07-26 2002-05-30 Ericsson Telefon Ab L M Systeme et procede pour combiner plusieurs synchroniseurs de mise a jour periodique
WO2002009454A2 (fr) * 2000-07-26 2002-01-31 Telefonaktiebolaget Lm Ericsson Systeme et procede pour combiner plusieurs synchroniseurs de mise a jour periodique
KR100689473B1 (ko) * 2000-08-29 2007-03-08 삼성전자주식회사 통신시스템에서 프로토콜 헤더 압축장치 및 방법
WO2002035863A2 (fr) * 2000-10-27 2002-05-02 Nortel Networks Limited Protocole ip de couche d'adaptation permettant d'optimiser la transmission de paquets d'information sur une connexion de liaison terrestre de reseau cellulaire
WO2002035863A3 (fr) * 2000-10-27 2002-07-11 Nortel Networks Ltd Protocole ip de couche d'adaptation permettant d'optimiser la transmission de paquets d'information sur une connexion de liaison terrestre de reseau cellulaire
WO2002049297A1 (fr) * 2000-12-14 2002-06-20 Siemens Aktiengesellschaft Procede de transmission de donnees de differentes applications par l'intermediaire d'un reseau de transmission par paquets, unites correspondantes et programme correspondant
EP1215859A1 (fr) * 2000-12-14 2002-06-19 Siemens Aktiengesellschaft Methode et dispositif pour transmettre des données d'utilisation different sur un réseau à commutation de paquet
WO2002060152A3 (fr) * 2001-01-26 2003-06-05 Pogo Technology Ltd Ameliorations se rapportant a des systemes de communication sans fil
WO2002060152A2 (fr) * 2001-01-26 2002-08-01 Pogo Mobile Solutions Limited Ameliorations se rapportant a des systemes de communication sans fil
EP1296488A3 (fr) * 2001-09-20 2003-05-14 Lucent Technologies Inc. Multiplexage de paquets de donneés de IP dans une trame de donneés de MPLS
EP1296488A2 (fr) * 2001-09-20 2003-03-26 Lucent Technologies Inc. Multiplexage de paquets de donneés de IP dans une trame de donneés de MPLS
US7237108B2 (en) 2001-09-26 2007-06-26 General Instrument Corporation Encryption of streaming control protocols and their headers
US8255989B2 (en) 2001-09-26 2012-08-28 General Instrument Corporation Access control and key management system for streaming media
US7243366B2 (en) 2001-11-15 2007-07-10 General Instrument Corporation Key management protocol and authentication system for secure internet protocol rights management architecture
WO2003088614A1 (fr) * 2002-04-15 2003-10-23 Veraz Networks Ltd. Procede et appareil de transmission efficace de trafic voip
US7356687B2 (en) 2002-05-21 2008-04-08 General Instrument Corporation Association of security parameters for a collection of related streaming protocols
WO2003101073A1 (fr) 2002-05-21 2003-12-04 General Instrument Corporation Association de parametres de securite pour ensemble de protocoles de flux connexes
EP1525690A1 (fr) * 2002-08-02 2005-04-27 NMS Communications Procedes et appareil de regroupement de signaux reseau et de reduction de largeur de bande
EP1525690A4 (fr) * 2002-08-02 2008-08-06 Nms Comm Procedes et appareil de regroupement de signaux reseau et de reduction de largeur de bande
US8364951B2 (en) 2002-12-30 2013-01-29 General Instrument Corporation System for digital rights management using distributed provisioning and authentication
US7251328B2 (en) 2003-01-14 2007-07-31 General Instrument Corporation System for secure decryption of streaming media using selective decryption of header information and decryption of reassembled content
EP1443733A2 (fr) * 2003-01-30 2004-08-04 Avaya, Inc. Identification de flux de données par paquets pour multiplexage
EP1443733A3 (fr) * 2003-01-30 2004-11-17 Avaya, Inc. Identification de flux de données par paquets pour multiplexage
US7525994B2 (en) 2003-01-30 2009-04-28 Avaya Inc. Packet data flow identification for multiplexing
US7107354B2 (en) 2003-02-07 2006-09-12 Avaya Technology Corp. Multiplexer discovery and parameter exchange
EP1494425A1 (fr) 2003-07-03 2005-01-05 Microsoft Corporation Format de charge utile de RTP
US7876896B2 (en) 2003-07-03 2011-01-25 Microsoft Corporation RTP payload format
US7483532B2 (en) 2003-07-03 2009-01-27 Microsoft Corporation RTP payload format
US7437457B1 (en) 2003-09-08 2008-10-14 Aol Llc, A Delaware Limited Liability Company Regulating concurrent logins associated with a single account
US7447211B1 (en) 2004-03-23 2008-11-04 Avaya Inc. Method and apparatus of establishing a communication channel using protected network resources
US7680100B1 (en) 2004-09-30 2010-03-16 Avaya Inc. Internet protocol appliance manager
US7489702B2 (en) 2005-03-31 2009-02-10 Alcatel-Lucent Usa Inc. Method and apparatus for increasing radio frequency efficiency for mixed voice over internet protocol and data traffic
WO2006104772A1 (fr) * 2005-03-31 2006-10-05 Lucent Technologies Inc. Procede et dispositif d'augmentation de l'efficacite de la radiofrequence pour combinaison de systeme vocal sur internet et de trafic de donnees
CN101379792B (zh) * 2005-03-31 2016-04-06 朗迅科技公司 提高基于互联网协议的混合语音和数据业务的射频效率的方法
US7769880B2 (en) 2005-07-07 2010-08-03 Microsoft Corporation Carrying protected content using a control protocol for streaming and a transport protocol
US7634816B2 (en) 2005-08-11 2009-12-15 Microsoft Corporation Revocation information management
US7720096B2 (en) 2005-10-13 2010-05-18 Microsoft Corporation RTP payload format for VC-1
GB2444096B (en) * 2006-11-22 2009-10-14 Adam Hill Audio communications system using networking protocols
GB2444096A (en) * 2006-11-22 2008-05-28 Adam Hill Improved voice over IP systems
WO2009026845A1 (fr) * 2007-08-23 2009-03-05 Huawei Technologies Co., Ltd. Procédé d'émission et de réception de données, appareil de point d'accès sans fil, passerelle et système de communication
CN103327030A (zh) * 2013-07-10 2013-09-25 上海庆科信息技术有限公司 一种利用Wi-Fi报文长度进行信息传输的方法
CN103841523A (zh) * 2014-03-14 2014-06-04 上海庆科信息技术有限公司 一种基于多播物理地址进行Wi-Fi报文长度的信息传输方法
US10135720B2 (en) 2016-08-03 2018-11-20 Anchorfree Inc. System and method for virtual multipath data transport
US10511521B2 (en) 2016-08-03 2019-12-17 Anchorfree Inc. System and method for virtual multipath data transport
US10938786B2 (en) 2017-12-01 2021-03-02 Twingate Inc. Local interception of traffic to a remote forward proxy
US11088994B2 (en) 2017-12-01 2021-08-10 Twingate Inc. Local interception of traffic to a remote forward proxy
US11190492B2 (en) 2017-12-01 2021-11-30 Twingate, Inc. Local interception of traffic to a remote forward proxy

Also Published As

Publication number Publication date
EP1106008A1 (fr) 2001-06-13
AU5771199A (en) 2000-03-14
JP2002523981A (ja) 2002-07-30

Similar Documents

Publication Publication Date Title
EP1106008A1 (fr) Procede et appareil assurant un multiplexage utilisateur dans un protocole en temps reel -
US6366961B1 (en) Method and apparatus for providing mini packet switching in IP based cellular access networks
US6918034B1 (en) Method and apparatus to provide encryption and authentication of a mini-packet in a multiplexed RTP payload
EP1247420B1 (fr) Procede et dispositif assurant une commutation efficace au niveau d&#39;application pour des flux de media a protocole internet multiplexes
EP1604535B1 (fr) Appareils et procédé pour la communication de paquets de data d&#39;internet
US7558240B2 (en) Radio telecommunications apparatus and method for communications internet data packets containing different types of data
US6993021B1 (en) Lightweight internet protocol encapsulation (LIPE) scheme for multimedia traffic transport
EP2763361B1 (fr) Procédé de transmission de message de protocole internet (ip), capacité d&#39;économie de largeur de bande négociée et économie de largeur de bande de réseau
AU754522B2 (en) Real time data transmission systems and methods
US7307968B2 (en) Method and system for communicating data between a mobile communications architecture and a packet switched architecture
JP3813511B2 (ja) 移動無線ネットワークの作動方法
US9148257B2 (en) Method and apparatus for reducing delays in a packets switched network
US20090135809A1 (en) Method and apparatus for establishing a voice bearer in a telecommunications system
US6904034B2 (en) Method and system for communicating data between a mobile communications architecture and a packet switched architecture, each utilizing a different mode of communication
US7792092B1 (en) Data transmission method and a network element
US8059660B2 (en) Communications routing systems and methods
US20020131447A1 (en) System and method for wireless packet data content switch
US20020018471A1 (en) Method and system for voice-over-IP communication
US20050232235A1 (en) Method and system for providing an interface between switching equipment and 2G wireless interworking function
WO2002047328A2 (fr) Systeme et procede de commutation d&#39;un contenu de donnees radiotransmises par paquets

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ CZ DE DE DK DK EE EE ES FI FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SK SL TJ TM TR TT UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 1999945006

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1999945006

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWW Wipo information: withdrawn in national office

Ref document number: 1999945006

Country of ref document: EP