[go: up one dir, main page]

EP1371204A2 - Internet protocol header for telecommunications networks - Google Patents

Internet protocol header for telecommunications networks

Info

Publication number
EP1371204A2
EP1371204A2 EP01969767A EP01969767A EP1371204A2 EP 1371204 A2 EP1371204 A2 EP 1371204A2 EP 01969767 A EP01969767 A EP 01969767A EP 01969767 A EP01969767 A EP 01969767A EP 1371204 A2 EP1371204 A2 EP 1371204A2
Authority
EP
European Patent Office
Prior art keywords
look
header
identity
data
communication unit
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP01969767A
Other languages
German (de)
French (fr)
Inventor
Kevan Hobbis
Paul Vincent Flynn
Joseph Rinchiuso
Daniel J Declerck
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Motorola Solutions Inc
Original Assignee
Motorola Inc
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 Motorola Inc filed Critical Motorola Inc
Publication of EP1371204A2 publication Critical patent/EP1371204A2/en
Withdrawn legal-status Critical Current

Links

Classifications

    • 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
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/168—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP] specially adapted for link layer protocols, e.g. asynchronous transfer mode [ATM], synchronous optical network [SONET] or point-to-point protocol [PPP]
    • 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 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).
  • IP Internet Protocol
  • UMTS Universal Mobile Telecommunications System
  • 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).
  • IP Internet Protocol
  • TCP Transfer Control Protocol
  • IP Internet Protocol
  • 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.
  • IP radio network controller
  • IP version 4 header is a minimum of 20 bytes long
  • IP version 6 header is a minimum of 40 bytes long.
  • a method for transmitting and receiving packet data in a telecommunications network including the steps of;
  • IP internet protocol
  • 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.
  • IP internet protocol
  • 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 ).
  • 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.
  • 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.
  • 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;
  • the look up tables 6 are empty and so the maintenance techniques as described below are used to fill in the tables 6.
  • a default entry or entries are set up by downloading from a subscription database. This may be used for example for email server details.
  • 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.
  • the mobile station 1 can begin to send and receive IP packets.
  • 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.
  • 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.
  • the transfer of the new table entries needs to be protected against loss.
  • 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.
  • the operation it is preferable for the operation to be acknowledged.
  • 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.
  • 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.
  • 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.
  • 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.
  • Options 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.
  • the mobile station uses higher layer protocols in conjunction with IP, such as TCP, UDP, RTP and others.
  • 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.
  • these protocol headers there are fields that change in every packet e.g. sequence numbers.
  • 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.
  • 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).
  • LZH compression
  • 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.
  • extension headers that are not particularly variable.
  • 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 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.
  • a dynamic data field 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

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 'proxy1 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

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.
EP01969767A 2000-09-27 2001-09-24 Internet protocol header for telecommunications networks Withdrawn EP1371204A2 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US67064100A 2000-09-27 2000-09-27
US670641 2000-09-27
PCT/EP2001/011047 WO2002028056A2 (en) 2000-09-27 2001-09-24 Internet protocol header for telecommunications networks

Publications (1)

Publication Number Publication Date
EP1371204A2 true EP1371204A2 (en) 2003-12-17

Family

ID=24691220

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01969767A Withdrawn EP1371204A2 (en) 2000-09-27 2001-09-24 Internet protocol header for telecommunications networks

Country Status (5)

Country Link
EP (1) EP1371204A2 (en)
JP (1) JP2004511136A (en)
CN (1) CN1554174A (en)
AU (1) AU2001289918A1 (en)
WO (1) WO2002028056A2 (en)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2255430C1 (en) * 2001-07-05 2005-06-27 Самсунг Электроникс Ко., Лтд Device and method for voice frame transmission in mobile communication system provided with all-ip network
KR101031125B1 (en) * 2006-06-07 2011-04-27 콸콤 인코포레이티드 Efficient Address Methods, Computer-readable Media, and Attitudes for Wireless Communication
US8874793B2 (en) * 2009-11-30 2014-10-28 Qualcomm Innovation Center, Inc. Methods and apparatus for improving header compression

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6967964B1 (en) * 2000-10-03 2005-11-22 Telefonaktiebolaget Lm Ericsson (Publ) Context identification using header compression key at link layer

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
WO2002028056A2 (en) 2002-04-04
CN1554174A (en) 2004-12-08
WO2002028056A3 (en) 2003-10-09
AU2001289918A1 (en) 2002-04-08
JP2004511136A (en) 2004-04-08

Similar Documents

Publication Publication Date Title
Stallings IPv6: the new Internet protocol
FI110987B (en) Method of connecting data transfer streams
US7600039B2 (en) Label-based multiplexing
JP4467797B2 (en) Method and system for supporting quality of service of a wireless network
EP1122925B1 (en) Header compression for general packet radio service tunneling protocol (GTP)
CN1115825C (en) Interface between standard terminal equipment unit and high-speed wireless link
US6771666B2 (en) System and method for trans-medium address resolution on an ad-hoc network with at least one highly disconnected medium having multiple access points to other media
KR100865490B1 (en) Method and device for mapping network headers onto mpls headers in bearer architectures
KR100893972B1 (en) Method and System for Performing Mobile Shortcut Point-to-Point Protocol Negotiation
US20040205247A1 (en) Apparatus and method for performing traffic flow template packet filtering according to internet protocol versions in a mobile communication system
US20050163073A1 (en) Applying session services based on packet flows
US20040151155A1 (en) Method for activating a connection in a communications system, mobile station, network element and packet filter
JP3863334B2 (en) Information transfer method, communication apparatus, and data communication system
JP2001244957A (en) IP router device with TCP termination function and medium
JP3813511B2 (en) Method of operating a mobile radio network
WO2002045379A2 (en) End-user communication systems access network
CN111788812B (en) Techniques for Packet Data Transformation
EP1387533A1 (en) Communication of packet data units over signalling and traffic channels
WO2002028056A2 (en) Internet protocol header for telecommunications networks
US20020174203A1 (en) Method of forwarding data packets in communications-network routers
FI110151B (en) Method for transmitting packets over a circuit switching network
US6785731B1 (en) Methods for efficient transmission of signaling messages in a packet-based network
US20060187922A1 (en) Packet communication device
CN101197763A (en) System and method for sending data over an air interface with a reduced address header
DK1392036T3 (en) Method and device for data transmission

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

17P Request for examination filed

Effective date: 20040413

17Q First examination report despatched

Effective date: 20040915

REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1062508

Country of ref document: HK

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20060620

REG Reference to a national code

Ref country code: HK

Ref legal event code: WD

Ref document number: 1062508

Country of ref document: HK

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230520