WO2000011849A1

WO2000011849A1 - Method and apparatus for providing user multiplexing in a real-time protocol

Info

Publication number: WO2000011849A1
Application number: PCT/US1999/017389
Authority: WO
Inventors: Baranitharn Subbiah
Original assignee: Nokia Networks Oy
Priority date: 1998-08-20
Filing date: 1999-08-05
Publication date: 2000-03-02
Also published as: AU5771199A; EP1106008A1; JP2002523981A

Abstract

An efficient real-time transport protocol multiplexing method and apparatus for transporting compressed speech between IP telephony gateways. The protocol eliminates bandwidth usage inefficiencies in transporting short packets between nodes connected by an IP network, wherein the method and apparatus enables a number of users to share a single RTP/UDP/IP connection. The protocol 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.

Description

METHOD AND APPARATUS FOR PROVIDING USER MULTIPLEXING IN A REAL-TIME PROTOCOL

BACKGROUND OF THE INVENTION

1. Field of the Invention.

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.

2. Description of Related Art.

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.

During the early years of network computing, proprietary networking protocols were the standard. However, the development of the Open Systems

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.

During the last decade, LANs have been proliferating. This has created a recurring problem of how to minimize congestion and optimize throughput that must be solved by network managers. An early solution was to simply divide Local Area Networks into multiple smaller networks serving smaller populations. These segments were connected by bridges to form a single Local Area Network with traffic being segregated locally to each segment.

An Internet is a set of networks connected by gateways, which are sometimes referred to as routers. The Internet Protocol (IP) is a network layer protocol that routes data across an Internet. 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".

The Internet not only provides a medium for data transport, but also has developed as a medium for telecommunications. In fact, 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.

However, while IP telephony, or voice-over-IP, has great potential to compete against the traditional public voice network, many obstacles must first be overcome. For example, the quality of Internet telephone calls is not as good as public network calls. Customer interest in the United States-where long-distance prices have consistently fallen-is uncertain. Further, IP telephony network equipment is new and lacks features that carriers desire.

Consequently, only a handful of small telephone companies now offer IP telephony services, and the amount of traffic they carry is minimal. However, equipment vendors and carriers are moving quickly to overcome these problems and, according to analysts, the number of established carriers beginning IP telephony trials is rising rapidly, new carriers are jumping into the market and the number of services being offered is expected to increase dramatically. In fact, analysts predict that users will embrace the new IP-based voice services. Accordingly, the success of Internet has further consolidated the notion that

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. At present, IP networks offer a single class of service called best effort, which can not guarantee any Quality of Service (QoS) to applications. To support delay sensitive applications such as voice and interactive multimedia, there have been many proposals submitted to the Internet Engineering Task Force (IETF) on how to integrate QoS in IP networks. These proposals include differentiated service (diff-serv), Integrated services (Int-serv) and Multi Protocol Label Switching (MPLS). Despite these efforts, QoS in IP is still elusive and could take some time before it is deployed over global Internet.

As mentioned above, 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. There are a large number of equipment vendors offering 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. Even though, IP telephone is not a reality in public Internet today, it has been successful in Intranet and Virtual Private Networks (VPN) environments.

There is a strong indication that IP telephone will be a niche service once QoS issues in IP networks become a reality. However, 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. As can be seen then, this lack of QoS guarantee in IP networks is touted as the major problem to provide real time services such as IP telephone over Internet. To overcome the delay problem in the 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. As a result, the growth of IP telephone gateways in corporate and ISP environments is expected to increase exponentially in the coming years. Traditionally voice is carried in a circuit switched network with connection oriented model. The explosive growth of data traffic in the network has changed the notion of service specific networks (single network for single service). Voice over IP network enables the voice traffic from public branch exchanges (PBX) and public switched telephone network (PSTN) users to share the data network thus improving the network utilization and lowering the cost associated with long distance telephone network. 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. In a IP telephony connection, two sides of the PSTN/PBX users (two branches of the same company) are interconnected by IP telephone gateways. In such application, a telephone call between PSTN/PBX users located at either side of the gateways is carried by a separate Real-time Transport Protocol/User Datagram Protocol/Internet Protocol (RTP/UDP/IP) connection. 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. Typically, 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. 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. For example, G.723.1 (the most popular IP telephony codec and the

International Multimedia Teleconferencing Consortium's (IMTC) Voice over IP (VoIP) mandatory low bit-rate codec), generates a 20 byte speech packet at 30 ms intervals. 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). The RTP/UDP/IP overhead is 40 bytes (12+8+20) for a simple speech packet. For example, a 10 byte packet transferred via RTP/UDP/IP increases the overhead to 80% (40 byte overhead/50 byte overhead plus packet). In addition, for each call request 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. In traditional RTP method, 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.

It can be seen then that there is a need for a method and apparatus for eliminating inefficiencies in transporting short packets between IP telephony gateways connected by an IP network.

It can also be seen that there is a need for a method and apparatus that enables a number of users to share a single RTP/UDP/IP connection.

SUMMARY OF THE INVENTION To overcome the limitations in the prior art described above, and to overcome other limitations that will become apparent upon reading and understanding the present specification, 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.

Another aspect of the present invention is that the identification of a user further comprises a unique channel identifier for each of the two or more users. Another aspect of the present invention is that the channel identifier is assigned to packets from a user when the user requests access to the IP telephone network.

Another aspect of the present invention is that the header comprises a length indicator, the length indicator indicating the size of the data packet associated with the header. Another aspect of the present invention is that the length indicator comprises six bits for allowing a maximum of a thirty-two byte data packet.

Another aspect of the present invention is that the header further comprises a sequence number, the sequence number marking data packets transmitted from a user to identify data packet loss.

Another aspect of the present invention is that the 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.

Another aspect of the present invention is that the protocol further includes de-assembling the RTP payload back into the data packets.

Another aspect of the present invention is that 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.

Another aspect of the present invention is that 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. Another aspect of the present invention is that 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. Another aspect of the present invention is that 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.

Another aspect of the present invention is that the protocol further includes replying to the local gateway with a rejection message when a problem allocating the connection occurs. Another aspect of the present invention is that 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.

Another aspect of the present invention is that the protocol further includes controlling the multiplexing and transmitting of the RTP payload using a timer. Another aspect of the present invention is that the data packets include compressed voice data.

An IP telephone network according to the present invention 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 according to the present invention 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 according to the present invention 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.

These and various other advantages and features of novelty which characterize the invention are pointed out with particularity in the claims annexed hereto and form a part hereof. However, for a better understanding of the invention, its advantages, and the objects obtained by its use, reference should be made to the drawings which form a further part hereof, and to accompanying descriptive matter, in which there are illustrated and described specific examples of an apparatus in accordance with the invention. BRIEF DESCRIPTION OF THE DRAWINGS Referring now to the drawings in which like reference numbers represent corresponding parts throughout:

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; and

Fig. 12 illustrates a comparison of the percent overhead verses the number of users for different methods.

DETAILED DESCRIPTION OF THE INVENTION In the following description of the exemplary embodiment, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration the specific embodiment in which the invention may be practiced. It is to be understood that other embodiments may be utilized as structural changes may be made without departing from the scope of the present invention.

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. To identify individual users on a single RTP/UDP/IP connection, a unique Channel Identifier (CID), as a part of the header, is proposed. Channel ID negotiations between the peer gateway entities is carried out by a new signaling procedure called MLNI-IP signaling. Analytical results show that 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.

Traditionally voice is carried in a circuit switched network with connection oriented model. The explosive growth of data traffic in the network has changed the notion of service specific networks (single network for single service). Voice over IP network enables the voice traffic from PBX and PSTN users to share the data network thus improving the network utilization and lowering the cost associated with long distance telephone network. 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. Fig. 1 shows an application scenario 100 in which two sides of the

PSTN/PBX 100, 112 (two branches of the same company) are interconnected by IP telephone gateways 120, 122. In such an application, 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.

For example, 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).

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. In addition, for each call request 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. In a traditional RTP method, 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 large overhead to transfer a small packets (compressed speech) through RTP/UDP/IP has been one of the drawbacks of IP telephone. In order to minimize the overhead, RTP/UDP/IP header compression is applied for slow speed links. However, 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. According to the present invention, 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. Alternatively, overhead may be reduce using the MLNI-IP header 204 illustrated in Fig. 2b. However, those skilled in the art will recognize that the present invention is not meant to be limited to the particular MLNI-IP headers illustrated in Figs. 2a-b, but that 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.

To identify a single user among the number of users sharing the RTP connection, each user is allocated an unique Channel Identifier (CID) which is negotiated during connection setup. 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.

To identify mini packets multiplexed on a single RTP payload, MINI-IP uses a two byte header, called MLNI-IP header, for each mini packet. The MINI-IP header 202, as shown in Fig. 2a includes a Channel Identifier (CID) 210, a Length Indicator (LI) 212, and a Sequence Number (SN) 214. 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.

As illustrated in Fig. 2a, 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, as shown in Fig. 2b 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. Notification of such changes occurs by toggling the bit. Finally, 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). As mentioned above, those skilled in the art will recognize that the above illustration of MINI-IP headers is not meant to limit the invention, but that other MINI-IP header configurations and sizes could be used in accordance with the present invention. For example, the length of the fields could be modified within the 2 byte format. Further, 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. For example, the reserved bit illustrated in Fig. 2b may be set to " 1 " to indicate an extension head is included in the MINI-IP header thereby providing an overall length for the MINI-IP header of 3 bytes. Alternatively, the reserved bit may be set to "0" to indicate that an extension header is not included in the MINI-IP header. Nevertheless, those skilled in the art will recognize that increases in the overall size of the MINI-IP header will proportionally increase the total overhead when multiple MINI-IP packets are multiplexed together in accordance with the invention. Thus, those skilled in the art will recognize that any MINI-IP header that enables multiplexing of multiple small size packets, is added to each mini packet before it is assembled with other mini packets as an RTP payload as illustrated in Fig. 3, and which allows proper processing of the multiple mini packets may be used without departing from the scope of the present invention.

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. Because 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.

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:

i. Negotiate channel identifier with remote gateway upon a connection request ii. Multiplex speech packets from a number of users into a single

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 location of the MINI-IP controller 410 in a IP telephone layered model

400 as shown in Fig. 4. 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. For example, 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. First, 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.

6, 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.

Referring again to Fig. 5, if the remote gateway 560 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. 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. At the time of assembling mini packets into an RTP payload, 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. In Fig. 7, 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. Upon expiration of the TIMER_MUX 730, 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. Communication media are not error free and any data transmitted needs some sort of protection. Existing protocols such as ATM, IP and AAL2 specify a Header Error Correction (HEC) to detect errors in the headers at the receiver. Protocols such as UDP offers both header and payload protection. The UDP checksum is calculated for the entire UDP packet including header and payload. The MINI-IP header is 2 byte long and does not have any HEC field because MINI-IP packets are encapsulated within an RTP/UDP payload thus protected by the UDP checksum. Packet loss is another problem that is prevalent in any packet switching network. Since MINI-IP enables many users to share a single RTP/UDP/IP connection, MINI-IP can not use the RTP sequence number to identify packet loss of a single user. To solve this problem, the MINI-IP header consist of a two bit Sequence Number (SN) field. This two bit SN allows for a modulo 4 style sequence numbering at the transmitter. In general, SN could start at 0 and follow the sequence of 1,2,3,0,1,2.

Accordingly, if there is a packet loss, then 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.

Fig. 9 illustrates the application of a MINI-IP controller in a RAN 900. In this scenario, 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. The conversations of a number of GSM telephone users will be transported using IP telephony along with data traffic in the same IP network. Those skilled in the art will recognize that the present invention is not meant to be limited the particular components of the cellular system illustrated in Fig. 9. Rather, the MINI-IP is meant to be utilized in MINI-IP controllers in any component connected through a wireline or wireless IP network.

As mentioned above, the important reason for multiplexing small packets into a single RTP payload is to reduce the RTP/UDP/IP overhead for each packet. For example, 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). Considering that IP telephone gateways transfer hundreds of user at any given time, the overhead for all these users could very will exceed the total capacity of the link. However, 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, whereas 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. In addition, as the number of users on a single connection increases, 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.

In summary, 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. As shown above, 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. The assembly and de-assembly processing is compensated in case of MINI-IP because it does not require any separate UDP connection and complex signaling. 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.

The foregoing description of the exemplary embodiment of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the invention be limited not with this detailed description, but rather by the claims appended hereto.

Claims

WHAT IS CLAIMED IS:

1. A protocol for increasing the bandwidth usage efficiency of a IP telephone network comprising: 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.

2. The protocol of claim 1 wherein the plurality of data packets are received from two or more users.

3. The protocol of claim 2 wherein the identification of a user further comprises a unique channel identifier for each of the two or more users.

4. The protocol of claim 3 wherein the channel identifier is assigned to packets from a user when the user requests access to the IP telephone network.

5. The protocol of claim 2 wherein the header comprises a length indicator, the length indicator indicating the size of the data packet associated with the header.

6. The protocol of claim 5 wherein the length indicator comprises six bits for allowing a maximum of a thirty-two byte data packet.

7. The protocol of claim 1 wherein the header further comprises a sequence number, the sequence number marking data packets transmitted from a user to identify data packet loss.

8. The protocol of claim 7 wherein the sequence number further comprises two bits, the two bits identifying a maximum of three consecutive data packet losses.

9. The protocol of claim 1 wherein the header of each data packet multiplexed into the RTP payload is transparent to intermediate IP routers.

10. The protocol of claim 1 further comprising de-assembling the RTP payload back into the data packets.

11. The protocol of claim 1 further comprising: 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.

12. The protocol of claim 11 further comprising: 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, and channel identifier.

13. The protocol of claim 12 further comprising : 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.

14. The protocol of claim 13 wherein the accepting the connection further comprises: updating a channel identifier table at the remote gateway; replying to the local gateway with a connect message.

15. The protocol of claim 14 further comprising replying to the local gateway with a rejection message when a problem allocating the connection occurs.

16. The protocol of claim 14 further comprising : receiving at the local entity the connect message; confirming at the local entity the channel identifier; and informing the user requesting access.

17. The protocol of claim 1 further comprising controlling the multiplexing and transmitting of the RTP payload using a timer.

18. The protocol of claim 1 wherein the data packets comprise compressed voice data.

19. An IP telephone network, comprising: a remote IP gateway; and a local IP gateway; wherein the remote and local IP gateways communicate using a protocol, the protocol comprising: creating a header for a plurality of data packets received from a plurality of users at the local IP gateway, 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 to the remote IP gateway.

20. The IP telephone network of claim 19 wherein the identification of a user further comprises a unique channel identifier for each of the two or more users.

21. The IP telephone network of claim 20 wherein the channel identifier is assigned to packets from a user when the user requests access to the remote IP gateway.

22. The IP telephone network of claim 19 further comprising: receiving at the local IP gateway an access request from a user at the 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.

23. The IP telephone network of claim 22 further comprising: after receiving an access request from a user, determining whether an existing RTP/UDP/IP connection between the local and remote IP gateways 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.

24. The IP telephone network of claim 23 further comprising: recovering, at the remote IP gateway, a local UDP port number, remote port number, channel identifier from the setup message; verifying at the remote IP gateway whether the channel identifier is free; and accepting the connection when the channel identifier is free.

25. The IP telephone network of claim 24 wherein the accepting the connection further comprises: updating a channel identifier table at the remote IP gateway; replying to the local IP gateway with a connect message.

26. The IP telephone network of claim 25 further comprising replying to the local IP gateway with a rejection message when a problem allocating the connection occurs.

27. The IP telephone network of claim 25 further comprising: receiving at the local IP gateway the connect message; confirming at the local IP gateway the channel identifier; and informing the user requesting access.

28. The IP telephone network of claim 19 wherein the data packets comprise compressed voice data.

29. A MINI-IP controller, comprising: means for providing control plane signaling, control plane signaling being used to setup a connection to a remote peer MLNI-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 a MINI-IP protocol, the MINI-IP protocol comprising: 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.

30. The MINI-IP controller of claim 29 wherein the data packets comprise compressed voice data.

31. An RTP payload, comprising: 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 MINI-IP payloads being multiplexed together to form a RTP packet.

32. The RTP payload of claim 31 further comprising a UDP header.

33. The RTP payload of claim 32 further comprising an IP header.

34. The RTP payload of claim 31 wherein the identifier of a user further comprises a unique channel identifier for each of the two or more users.

35. The RTP payload of claim 34 wherein the channel identifier is assigned to packets from a user when the user requests access to an IP telephone network.

36. The RTP payload of claim 35 wherein the MINI-IP header comprises a length indicator, the length indicator indicating the size of the data packet associated with the header.

37. The RTP payload of claim 36 wherein the length indicator comprises six bits for allowing a maximum of a thirty-two byte data packet.

38. The RTP payload of claim 31 wherein the MINI-IP header further comprises a sequence number, the sequence number marking data packets transmitted from a user to identify data packet loss.

39. The RTP payload of claim 38 wherein the sequence number further comprises two bits, the two bits identifying a maximum of three consecutive data packet losses.

40. The RTP payload of claim 31 wherein the MINI-IP header of each data packet multiplexed into the RTP payload is transparent to intermediate IP routers.

41. The RTP payload of claim 31 wherein the data packets comprise compressed voice data.

42. An IP network, comprising: a base station having a MINI-IP controller; and a RNC having a MINI-IP controller; wherein the base station and the RNC communicate using a protocol, the protocol comprising: creating a header for a plurality of data packets received from a plurality of users at the RNC, 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 to the base station.

43. The IP network of claim 42 wherein the identification of a user further comprises a unique channel identifier for each of the two or more users.

44. The IP network of claim 43 wherein the channel identifier is assigned to packets from a user when the user requests access to the base station.

45. The IP network of claim 42 further comprising: receiving at the RNC an access request from a user at the base station; transmitting a setup message to the base station using an IP connection; and establishing a user plane connection for receiving data packets from a user after successful completion of a connection setup.

46. The IP network of claim 45 further comprising: after receiving an access request from a user, determining whether an existing RTP/UDP/IP connection between the RNC and base station 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.

47. The IP network of claim 46 further comprising: recovering, at the base station, a local UDP port number, remote port number, channel identifier from the setup message; verifying at the base station whether the channel identifier is free; and accepting the connection when the channel identifier is free.

48. The IP network of claim 47 wherein the accepting the connection further comprises: updating a channel identifier table at the base station; replying to the RNC with a connect message.

49. The IP network of claim 48 further comprising replying to the RNC with a rejection message when a problem allocating the connection occurs.

50. The IP network of claim 48 further comprising: receiving at the RNC the connect message; confirming at the RNC the channel identifier; and informing the user requesting access.

51. The IP network of claim 42 wherein the data packets comprise compressed voice data.

52. A base station having a MINI-IP controller for increasing the efficiency of bandwidth usage in a cellular network, the MINI-IP controller comprising means for providing control plane signaling, control plane signaling being used to setup a connection to a base station controller having a peer MINI-IP controller and means for providing user plane signal, user plane signaling being used to transmit data packets to a the base station controller using a MINI-IP protocol, the MINI-IP protocol creating a header for a plurality of data packets, each header providing identification of a mobile 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.

53. The base station of claim 52 wherein the data packets comprise compressed voice data.

54. A base station controller having a MINI-IP controller for increasing the efficiency of bandwidth usage in a cellular network, the MLNI-IP controller comprising means for providing control plane signaling, control plane signaling being used to setup a connection to a base station having a peer MINI-IP controller and means for providing user plane signal, user plane signaling being used to transmit data packets to a the base station using a MINI-IP protocol, the MINI-IP protocol creating a header for a plurality of data packets, each header providing identification of a mobile 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.

55. The base station controller of claim 52 wherein the data packets comprise compressed voice data.

56. A mobile switching center having a MINI-IP controller for increasing the efficiency of bandwidth usage in a cellular network, the MINI-IP controller comprising means for providing control plane signaling, control plane signaling being used to setup a connection to a base station controller having a peer MINI-IP controller and means for providing user plane signal, user plane signaling being used to transmit data packets to a the base station controller using a MINI-IP protocol, the MINI-IP protocol creating a header for a plurality of data packets, each header providing identification of a mobile 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.

57. The mobile switching center of claim 52 wherein the data packets comprise compressed voice data.