EP1371204A2 - En-tete de protocole internet pour reseaux de telecommunications - Google Patents

En-tete de protocole internet pour reseaux de telecommunications

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)
English (en)
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/fr
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

L'invention concerne l'utilisation d'une « table de recherche » pour éliminer la nécessité de transporter des en-têtes de protocole Internet (IP) via l'interface hertzienne (et par liaison terrestre dans certains cas) lors du transport de paquets IP vers et à partir de dispositifs de communication mobiles (1). Cela résout certains problèmes d'efficacité d'utilisation du spectre liés au transport de paquets IP.
EP01969767A 2000-09-27 2001-09-24 En-tete de protocole internet pour reseaux de telecommunications Withdrawn EP1371204A2 (fr)

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 (fr) 2000-09-27 2001-09-24 En-tete de protocole internet pour reseaux de telecommunications

Publications (1)

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

Family

ID=24691220

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01969767A Withdrawn EP1371204A2 (fr) 2000-09-27 2001-09-24 En-tete de protocole internet pour reseaux de telecommunications

Country Status (5)

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

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100442611B1 (ko) 2001-07-05 2004-08-02 삼성전자주식회사 올 아이피 망을 기반으로 하는 이동통신시스템에서 음성전송장치 및 방법
WO2007143679A2 (fr) * 2006-06-07 2007-12-13 Qualcomm Incorporated procédés et appareil d'adressage efficaces en liaison radio
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
CN1554174A (zh) 2004-12-08
WO2002028056A2 (fr) 2002-04-04
JP2004511136A (ja) 2004-04-08
AU2001289918A1 (en) 2002-04-08
WO2002028056A3 (fr) 2003-10-09

Similar Documents

Publication Publication Date Title
Stallings IPv6: the new Internet protocol
US7600039B2 (en) Label-based multiplexing
JP4467797B2 (ja) ワイヤレスネットワークのサービスクオリティをサポートする方法及びシステム
FI114132B (fi) Tiedonsiirron laatutason tukeminen langattomassa tiedonsiirrossa
EP1122925B1 (fr) Compression d'en-tête pour service général de radiocommunication par paquets dans un protocole tunnel (GTP)
FI110987B (fi) Menetelmä tiedonsiirtovirtausten kytkemiseksi
US5781534A (en) Method and apparatus for determining characteristics of a path
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
KR100893972B1 (ko) 이동국 단축 포인트 대 포인트 프로토콜 교섭을 수행하는방법 및 시스템
US20050201412A1 (en) Communication of packet data units over signalling and data traffic channels
JP3863334B2 (ja) 情報転送方法、通信装置及びデータ通信システム
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
JP2001244957A (ja) Ｔｃｐ終端機能付きｉｐルータ装置および媒体
JP3813511B2 (ja) 移動無線ネットワークの作動方法
KR100865490B1 (ko) 베어러 아키텍처들에서 네트워크 헤더들을 ｍｐｌｓ 헤더들에 맵핑하기 위한 방법 및 장치
US11165893B2 (en) Techniques for packet data conversion
CN1954561B (zh) 分组交换网络上的服务质量的自动适配
WO2002028056A2 (fr) En-tete de protocole internet pour reseaux de telecommunications
US20060187922A1 (en) Packet communication device
US20020174203A1 (en) Method of forwarding data packets in communications-network routers
US6785731B1 (en) Methods for efficient transmission of signaling messages in a packet-based network
FI110151B (fi) Menetelmä pakettien siirtämiseksi piirikytkentäisen verkon yli
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