The invention relates generally to Internet Protocol (IP) packet communication methods and apparatus and more particularly to point to point protocol (PPP) packet communication methods and apparatus.
Internet Protocol (IP) based wireless communication architectures are known. As shown in FIG. 1, in the future the link between a base transceiver station (BTS) 100 and a selection/distribution unit (SDU) 102 will be based on IP that communicates point to point protocol (PPP) packets 101. The SDU may be part of a base site controller (BSC) or other suitable network element. The TIA/EIA/IS-634 standard (e.g., Part 4. Revision A xe2x80x9cCore Protocol Detailsxe2x80x9d) defines the application protocols and the messages shared between the SDU and the BTS 100. These messages between applications 103 will be transported over an IP network 104. In the IS-634 standard, the interface between the SDU and the BTS is called the A3 interface. For the user traffic exchanged between the SDU and the BTS, IS-634 assumes that the transport layer provides the call-context information. This information is not included in the IS-634 message itself. Since the current system is circuit switched, the slot position in the connection between the BTS and the SDU provides this information and in the proposed packetized system, an AAL2 header provides the call-context information. In the IP based system, the unique call-context reference will be specified by using user datagram protocol (UDP) between the SDU and the BTS. A mobile station 105 communicates with the BTS 100 as known. The UDP port number along with the IP address will provide the unique call-context information. The protocol stack 106 between the SDU and the BTS is shown in FIG. 1. An SDU consists of multiple SDU elements. Each SDU element terminates one call. The following four tuple: (IP address of the SDU 108, Port number of the SDU 110, IP address of the BTS 112, Port number on the BTS 114), provides a unique call context for each leg of a call. The IP address and UDP port numbers provide the unique call-context for each IS-634 frames 116. A point to point protocol (PPP) header 118 and PPP CRC information 120 is also used.
In most of the current systems and systems which will be deployed for the next few years, a T1 1.544 Mbps link 122 forms the backhaul link from the BTS 100 to the core network. This link 122 is very expensive and should be able to carry data for as many calls as possible. Hence, the key problem is to compress the data and decrease the header overhead as much as possible. As known in the art, link 122 is terminated using Channel Service Units/Data Service Units (CSU/DSU) 124 and 126.
A standard way to carry IP packets over T1 links is to use point to point protocol (PPP) as a link layer protocol over the T1 link. In the default mode, PPP prepends 5 bytes of header and 2 bytes of trailer to each IP packet; thus the default PPP overhead is 7 bytes. When the two ends of the link negotiate to reduce the header of PPP, the PPP overhead can be reduced to 5 bytes: Flag byte+2-Protocol type bytes+2-CRC bytes. (it cannot be assumed that the protocol type field could be reduced to 1 byte, as the protocol byte field for compressed TCP and UDP payloads occupy 2 bytes). In addition UDP header compression is described by RFC 2508. In this case, the compressed UDP header is 2 bytes. Thus the overhead per IS-634 frame is 7 bytesxe2x80x942 bytes compressed UDP header and 5 bytes PPP overhead. There is also a checksum feature of the UDP header. However, this PPP overhead can be unnecessarily large and can unnecessarily reduce the available bandwidth over the T1.
Another type of multiplexing scheme is described in ITU-T I.363.2, B-ISDN ATM Adaptation Layer: Type AAL2. This is a multiplexing scheme for point to point asynchronous transfer mode (ATM) virtual connections, whereby voice packets from multiple users may be contained in a single ATM cell payload 200. Each AAL2 user packet 202, 204, 206 that is multiplexed onto a given AAL2 virtual connection has a unique call-context reference, a Connection Identifier (CID). An example protocol stack 208 for this scheme is shown in FIG. 2.
Also, there have been several proposals for multiplexing real time transfer protocol (RTP) streams in the Internet. In the proposed designs, interest has also been expressed for reusing the RTP multiplexing scheme for improving the efficiency of transporting data on the BTS backhaul link. In the Internet, RTP multiplexing schemes have been proposed as methods to multiplex a number of low bit rate audio streams into a single RTP/UDP/IP connection between IP telephony gateways 300 and 302. The telephony gateways 300 and 302 may couple to Public telephone Networks (PTNs) 304.
The deployment scenario for these multiplexing schemes is shown in FIG. 3. The RTP multiplexing schemes are used to multiplex traffic between the two gateways 300 and 302 to transport data efficiently over the Internet. A requirement for the multiplexing schemes is that all the RTP streams 306, 308 being multiplexed originate and terminate at the same end-points, i.e. the IP address in the IP/UDP headers 310, 312 are the same. In all the proposals, each multiplexed stream is identified by a channel identifier 314 which is used to identify the payload belonging to that stream. The format and placement of the channel identifier differs between the different scenarios. A lookup table 316 can be used as a mechanism to multiplex or demultiplex IP packets.
One possible case of reusing the RTP multiplexing scheme for the BTS backhaul link is shown in FIG. 4. Much like in the AAL2 multiplexing case, there is an initial level of signaling which involves the SDU, packet control unit 400 PCU and the BTS (BTS includes the network interface board (NIB). This signaling sets up the two maps 402, 404 as shown in FIG. 4. In the upstream direction, the map 404 at the NIB enables the NIB to map from the multi-channel carrier card (MCC) (signal processor and channel coding card) device address that it receives in the packet from the BTS to the C_ID. At the packet control unit (PCU), a mapping is used to the SDU device address from the C_ID received on the link from the BTS. A router 406 suitably routes IS-634 packets to the appropriate SDU. The opposite occurs for downstream traffic. If the SDU sits on an IP network, this would mean recreating the UDP/IP header for the SDU device. This is very different from the process occurring in the Internet RTP multiplexing scheme. Recreating IP/UDP headers is a more complicated task than using the C_ID to identify one stream in a multiplexed RTP stream.
Another possibility of using RTP Multiplexing is shown in FIG. 5. In this scheme the SDU multiplexes the user information destined to one BTS into one multiplexed RTP stream 500 using routers 502 and 504. The disadvantages of this scheme are that the scheme cannot multiplex traffic destined to one BTS from different SDUs. In addition, the multiplexing gain may not be very high at the SDU. Typically there are two or three SDU serving 100 BTSs. Also, unless an RTP header is used for achieving synchronization between the SDU and the BTS, the RTP header is useless and one might have to implement real-time transfer control protocol (RTCP) at the SDU and the BTS to be able to use RTP.
Accordingly a need exists for a method and apparatus for reducing PPP packet sizes communicated over a communication link.