INTERNET PROTOCOL HEADER FOR TELECOMMUNICATIONS NETWORKS

Abstract: The invention uses a 'look-uptable' to elimiate the need to transport IP headers across the air interface (and terrestrial backhaul in some cases) when transporting IP packets to and from mobile communication devices 1. This resolves some of the spectrum efficiency issues related to transport of IP packets.

Description: Internet Protocol Header for telecommunications networks Background of the Invention This invention relates to Internet Protocol (IP) transmissions in telecommunications networks and has particular application to third generation telecommunication networks; the so called UMTS (Universal Mobile Telecommunications System). Present day communications systems, both wireless and wire-line, have a requirement to transfer data between communications units. Data, in this context, includes speech communication. Such data transfer needs to be effectively and efficiently provided for, in order to optimise use of limited communication resources. For data to be transferred across communications networks, a communication unit addressing protocol is required. The communication units are generally allocated addresses that are read by a communication bridge, gateway and/or router, in order to determine how to transfer the data to the addressed unit. The interconnection between networks is generally known as internetworking (or internet). Networks are often divided into sub-networks, with protocols being set up to define a set of rules that allow the orderly exchange of information. Currently, the two most popular protocols used to transfer data in communications systems are: Transfer Control Protocol (TCP) and Internet Protocol (IP). In all but the simplest of communications systems, these two protocols often work as a complementary pair. The IP portion corresponds to data transfer in the network layer of the well-known OSI model and the TCP portion to data transfer in the transport layer of the OSI model. Their operation is transparent to the physical and data link layers and can thus be used on any of the standard cabling networks such as Ethernet, FDDI or token ring. The Internet Protocol adds a data header on to the information passed from the transport layer. The resultant data packet is known as an Internet datagram. The header of the datagram contains information such as destination and source IP addresses, the version number of the IP protocol etc. An IP address is assigned to each node on the internet. It is used to identify the location of the network and any sub-networks. There is currently a strong trend for third generation systems to move toward 'All-IP' solutions. In many cases this is seen as end-to-end i.e. from the communication unit through to the network server. The use of IP for network connections i.e. between base transceiver station (BTS) (or node B) and the base station controller (BSC) (or radio network controller) (RNC) is also planned. There are spectrum efficiency issues that are related to the transport of IP headers across the air, and on internal Radio network interfaces. An IP version 4 header is a minimum of 20 bytes long, and an IP version 6 header is a minimum of 40 bytes long. Clearly when transporting short packets such as voice this may prove to be very inefficient. A solution is required that allows IP to be used, but whereby the header information is somehow compressed or the need to transport it is eliminated. Summary of the Invention According to a first aspect of the present invention there is provided a method for transmitting and receiving packet data in a telecommunications network, the method including the steps of; receiving internet protocol (IP) header contents and a corresponding look-up table identity at a communication unit and a network control station, storing the received IP header contents and their corresponding identity in look-up tables located at the communication unit and the network control station, and exchanging data packets between the communication unit and the network control station in which the data packets include a look-up table identity. According to a second aspect of the present invention, there is provided an apparatus for transmitting and receiving packet data, the apparatus including; means for receiving internet protocol (IP) header contents and a corresponding look-up table identity, a look-up table for storing the received IP header contents and corresponding identity, and means for attaching a look-up table identity to a data packet and transmitting said data packet over an air interface. Hence the invention proposes the use of dynamic look up tables in the communication unit and the network infrastructure in order to allow elimination of the need to transport the full IP header over the air ( and potentially, in some cases over the BTS to BSC/RNC interface ). In a preferred embodiment, the protocol and method described below may be used in place of the current PDCP protocol in the existing UMTS specifications.the invention can be applied to IP version 4 or version 6 and is also suitable for simplex links. The invention exploits the principle that most of the content of an IP header does not change from one packet to the next. For example the source address is most often the same (although it is possible to have more than one source address) when transmitting, but this may also be true when receiving ( e.g. a file transfer or download from an email server ). A similar argument can be made for the destination address. Much of the IP header information is not required on a point to point link, or will be the same due to the nature of the connection. The solution proposed by the present invention involves an exchange from the communication unit to the network infrastructure ( and vice versa ) to set up an IP Header Look Up table. The size of the table can be varied dependent on the level and variety of services that the communication unit is likely to use. The exchange takes place in both directions on the air interface. The contents of the transfer is a table consisting of a Look UP ID ( LUID ), and the full IP header contents . The header contents are stored in a look up table, and cross-referenced against the LUID. The communication unit and network infrastructure then transport packets across the air interface using only this LUID rather than the full IP header. There may also be other data from the header that is dynamic that may need to be transported over the air occasionally. The look up table may be located either in the BTS or the BSC/RNC. If the table is stored at the BSC/RNC then the bandwidth efficiency will also be saved on the BTS to BSC/RNC backhaul link(s). This would however preclude the use of a routed IP network ( although it could still use an IP tunnelling technique to allow this ) between the BTS and RNC, hence it may be preferable to store the table at the BTS. The techniques described below will work in either case. Brief Description of the Drawings An embodiment of the invention will now be described by way of example only, with reference to the drawings of which; Fig. 1 is a schematic diagram of a telecommunications network operating in accordance with the invention, Fig. 2 is an illustration of the known IP version 4 header and Fig. 3a and 3b illustrate packets for a header set-up procedure in accordance with the invention. Detailed Description of the Preferred Embodiment In Fig. 1 a communication unit, which in this example is a mobile station (e.g. cellphone) 1 , is in communication with a base station transceiver BTS 2 over an air interface 3. The BTS 2 is linked to a radio network controller 4 by which means, communications between an internet protocol core network 5 and the mobile station 1 can be established. The core network 5 may have further connections to other networks and network elements (not shown), such as an internet packet data network , internet service provider or telephone networks via appropriate signalling gateways. Both the mobile station 1 and the BTS 2 are provided with a look-up table 6. The look- up tables 6 are maintained in the BTS 2 and mobile station 1 for the duration of a context for the particular mobile station 1 existing in the network 5,4,2. Initialisation of the table can take place in a number of ways, as follows; In a first instance, the look up tables 6 are empty and so the maintenance techniques as described below are used to fill in the tables 6. In a second instance, a default entry or entries are set up by downloading from a subscription database. This may be used for example for email server details. In a third instance, the mobile station 1 and/or the BTS 2 sends a number of headers at initialisation time based on some prior knowledge of the data and destinations that are to be contacted in the call. This is similar to the maintenance techniques described below, with the difference that multiple headers are initialised in a single message. Certain table entries may be marked as fixed (e.g. the default entry or entries) so that they are not overwritten by the maintenance techniques described below. Once the initialisation has taken place, the mobile station 1 can begin to send and receive IP packets. When a packet is to be sent by the mobile station 1 or the BTS 2 across the air interface 3, the look- up table 6 is consulted to determine if one of the standard configurations is referenced. If so then the packet is sent with the IP header removed and replaced by the LUID which can be much smaller than 20 bytes (probably one byte or less). Maintenance techniques are as follows. If the entry does not appear in the look up table then there are a number of choices as follows; i) send the packet with the full header ii) create an entry and communicate this across the air interface 3 ( which will be the header plus allocated LUID ). Then use this newly allocated LUID for subsequent transfers. iii) replace an existing entry with the new one, and communicate this across the air interface 3 as for the creation of a new entry. The selection criteria of the entry to be replaced is not specified, but could use a number of techniques e.g. select the least used, or the oldest entry. In some cases changed fields are sent when they are only slightly different or temporarily different but without updating the look up table. Preferably, the transfer of the new table entries needs to be protected against loss. For example a "replace entry" operation that fails to arrive at its destination will cause the mobile station's or BTS's receiver to incorrectly route subsequent packets using that LUID. Hence it is preferable for the operation to be acknowledged. The header fields of IP version 4 header and the relation to LUID will now be described with reference to Fig. 2. VERS : This defines version 4 or version 6 etc. of the IP protocol. It can be eliminated on the air interface either by negotiation that all transfers will use a particular version, or merely by entering the version in the appropriate look up table entry. It may not need to be transferred for a given look up table entry ( a default value can be used ). HLEN : This is the length of the header. In cases where no options are used this can be a fixed entry in the look up table for a particular entry, so will not need to be exchanged in the look up table transfer ( i.e. a default value can be used). In IPversion 6, this field is not needed, as the length of a basic IP header is always the same. Service Type : This indicates quality of service and has a number of sub- fields. It can be eliminated by the look up table entry. It may generate more than one look up table entry for a given destination address if, for instance a voice over IP channel and a web browser channel are open to the same address. The mapping could also be done within the network based on the service requested by the mobile. In IP version 6, the flow label serves a similar purpose, and can be compressed in a similar manner with a lookup table. Total Length : This identifies the full length of the IP packet ( header plus data part ). It does not need to be transferred across the air interface, nor stored in the look up table. In fact this will be transferred across the air interface as the RLC layer does perform segmentation and re-assembly and should transfer total length of the transported information. The IP layer Total Length can then be re-constructed. ID, Flags, Fragment Offset : These fields are used for IP level fragmentation. In general fragmentation is not used at the IP level, and restricting operation to not allow it would not be an issue. This field would therefore always be unused and not transferred over the air ( even in a look up table set up message transfer ). TTL : This effectively defines the maximum number of hops before this packet can be discarded. A default value could be used, and/or it may be set up in the look up table entry set up. A default value could work quite often in the uplink (mobile station to BTS), since the mobile station is probably the last hop. A small range of values would probably work in the downlink (BTS to mobile station) and could be augmented in maintenance mode as new values appear. Protocol : This indicates the type of protocol that this IP packet is carrying e.g. ICMP, IGMP, GGP, IP, TCP, UDP This may change even for a particular destination address, but it is likely that there are a set number of options for each combination of source and destination address, and a number of look up table entries could be constructed to cover the options. In IP version 6, the Next Header field serves a similar purpose and can be compressed in the same way. Header Checksum : Data transferred across the air interface will have its own checks, so this can be regenerated within the network or mobile based on the header contents ( it is effectively not being used ). For example, the checksum will be effectively terminated by the network element in the downlink direction. This field is eliminated in IP version 6. Source IP Address : This is set up in the look up table entry. Destination IP Address : This is set up in the look up table entry. Options : The options fields can be varied in length and number used in any one packet. Some are specific to certain applications. These fields could be avoided where possible but potentially require the transfer of data across the air interface when necessary. With regard to higher layer protocols; the mobile station uses higher layer protocols in conjunction with IP, such as TCP, UDP, RTP and others. The protocol field in the header indicates this and is used to set up the look up table appropriately. In many of these protocol headers there are fields that change in every packet e.g. sequence numbers. There is the possibility for these protocols to be terminated in the network at the look-up tables location. The BTS then acts as if it had the IP address of the mobile station (it acts as a proxy) and generates and terminates the IP and other protocols. This minimises the data that needs to be transmitted on air. The protocols across the air are then utilised to transport user data without being encumbered by many layers of headers. In cases where HTTP headers are used, the lookup table solution of the present invention is preferably used on the stable, lower layers such as IP or TCP in conjunction with compression ( e.g. LZH) on the upper layers (as HTTP). The air interface packets that constitute the setting up of headers are constructed as illustrated in Fig. 3a and 3b. The LUID Entry message ( Figure 3a )shows a general structure for an air interface packet used to set up a LUID entry. This can be used in either direction, and has a corresponding acknowledge message. The packet is very simple, consisting of a Type ( used to identify this packet from a Data Message and Acknowledge packets ), and LUID ( the entry number that this should be associated with) and then the IP header information that should be stored. Note that although not shown, it is also possible that certain parts of the IP header can be indicated as variable, and that they will therefore be transmitted in the Data Message when necessary. IP version 6 is very amenable to this approach, because it is structured with a basic header and extension headers. The basic IP version 6 header can be compressed using the lookup table approach, as can extension headers that are not particularly variable. For example, a routing extension header, which allows the source to specify a route through a network, could be quite large and would likely remain the same throughout a session. Lookup table entries would be a good way to compress such extensions. An authentication extension header, on the other hand, changes in an unpredictable way with each datagram, and would best be transmitted in the data message. The Data message of Fig. 3b consists of a Type field ( identifying it as a Data Transfer ) and an LUID identifying the table entry that should be used to generate the appropriate header. This may include a reference to higher layer protocols such as UDP, RTP etc. which can be used to remove the need to transfer these headers as part of the data, and allow a 'proxy 1 entity in the BTS to generate the full packet along with sequences numbers etc. There is an option of a dynamic data field. It will be appreciated from the foregoing that the present invention allows a minimisation of the data to be passed over the capacity- limited air interface (and in fact the BTS backhaul links) when IP based protocol stacks are used in the communication unit and the network infrastructure.

Claims: CLAIMS 1. A method for transmitting and receiving packet data in a telecommunications network, the method including the steps of; receiving internet protocol (IP) header contents and a corresponding look-up table identity at a communication unit and a network control station, storing the received IP header contents and their corresponding identity in look-up tables located at the communication unit and the network control station, and exchanging data packets between the communication unit and the network control station in which the data packets include a look-up table identity. 2. A method according to claim 1 in which the step of receiving IP header contents and corresponding look-up table identity comprises an exchange of same between the communication unit and the network control station. 3. A method according to claim 1 in which the step of receiving IP header contents and corresponding look-up table identity comprises down-loading same from a remote database. 4. A method according to any preceding claim including the further step of acknowledging receipt of a look-up table identity. 5. A method according to any preceding claim in which the look-up table identity corresponds to at least one of the following; (i) a quality of service, (ii) type of protocol carried by a given data packet, (iii) source IP address, (iv) destination IP address. 6. An apparatus for transmitting and receiving packet data, the apparatus including; means for receiving internet protocol (IP) header contents and a corresponding look-up table identity, a look-up table for storing the received IP header contents and corresponding identity, and means for attaching a look-up table identity to a data packet and transmitting said data packet over an air interface. 7. An apparatus according to claim 6 in which the look-up table includes a stored value for at least one of the following; (i) IP header length, (ii) IP version, (iii) Maximum number of hops each of said stored values being associated with a look-up table identity. 8. An apparatus according to either of claims 6 or 7 in which said apparatus comprises a mobile communication unit. 9. An apparatus according to either of claim 6 or 7 in which said apparatus comprises a telecommunications network control station. 10. An apparatus according to claim 9 and adapted to terminate a protocol.

Inventors: DECLERCK DANIEL J, FLYNN PAUL VINCENT, HOBBIS KEVAN, RINCHIUSO JOSEPH, DECLERCK, DANIEL, J, FLYNN, PAUL, VINCENT, HOBBIS, KEVAN, RINCHIUSO, JOSEPH
Applicants: DECLERCK DANIEL J, FLYNN PAUL VINCENT, HOBBIS KEVAN, MOTOROLA INC, RINCHIUSO JOSEPH, DECLERCK, DANIEL, J, FLYNN, PAUL, VINCENT, HOBBIS, KEVAN, RINCHIUSO, JOSEPH
Application year: 2001
Main classification: H04L29
IPC codes: H04L12, H04L29