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

En-tete de protocole internet pour reseaux de telecommunications Download PDF

Info

Publication number
WO2002028056A2
WO2002028056A2 PCT/EP2001/011047 EP0111047W WO0228056A2 WO 2002028056 A2 WO2002028056 A2 WO 2002028056A2 EP 0111047 W EP0111047 W EP 0111047W WO 0228056 A2 WO0228056 A2 WO 0228056A2
Authority
WO
WIPO (PCT)
Prior art keywords
look
header
identity
data
communication unit
Prior art date
Application number
PCT/EP2001/011047
Other languages
English (en)
Other versions
WO2002028056A3 (fr
Inventor
Kevan Hobbis
Paul Vincent Flynn
Joseph Rinchiuso
Daniel J Declerck
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
Priority to JP2002531715A priority Critical patent/JP2004511136A/ja
Priority to EP01969767A priority patent/EP1371204A2/fr
Priority to AU2001289918A priority patent/AU2001289918A1/en
Publication of WO2002028056A2 publication Critical patent/WO2002028056A2/fr
Publication of WO2002028056A3 publication Critical patent/WO2002028056A3/fr

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

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2002531715A JP2004511136A (ja) 2000-09-27 2001-09-24 通信ネットワークのためのインターネット・プロトコル・ヘッダ
EP01969767A EP1371204A2 (fr) 2000-09-27 2001-09-24 En-tete de protocole internet pour reseaux de telecommunications
AU2001289918A AU2001289918A1 (en) 2000-09-27 2001-09-24 Internet protocol header for telecommunications networks

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US67064100A 2000-09-27 2000-09-27
US09/670,641 2000-09-27

Publications (2)

Publication Number Publication Date
WO2002028056A2 true WO2002028056A2 (fr) 2002-04-04
WO2002028056A3 WO2002028056A3 (fr) 2003-10-09

Family

ID=24691220

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2001/011047 WO2002028056A2 (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)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003005657A1 (fr) * 2001-07-05 2003-01-16 Samsung Electronics Co., Ltd Appareil et procede de transmission d'une trame vocale dans un systeme de communication mobile base sur le tout ip

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2030419B1 (fr) * 2006-06-07 2017-07-19 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

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002030043A2 (fr) * 2000-10-03 2002-04-11 Telefonaktiebolaget Lm Ericsson (Publ) Identification de contexte a l'aide d'une cle de compression d'en-tete sur la couche de liaison

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002030043A2 (fr) * 2000-10-03 2002-04-11 Telefonaktiebolaget Lm Ericsson (Publ) Identification de contexte a l'aide d'une cle de compression d'en-tete sur la couche de liaison

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
CASNER S ET AL: "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links" RFC 2508, February 1999 (1999-02), pages 1-21, XP002121319 *
M. DEGERMARK, B. NORDGREN: "IP Header Compression" RFC 2507, [Online] 28 February 1999 (1999-02-28), pages 1-32, XP002210847 Retrieved from the Internet: <URL:http://www.faqs.org/rfcs/rfc2507.html > [retrieved on 2002-08-22] *
SVANBRO K ET AL: "Wireless Real-Time IP Services Enabled by Header Compression" VTC 2000-SPRING. 2000 IEEE 51ST. VEHICULAR TECHNOLOGY CONFERENCE PROCEEDINGS. TOKYO, JAPAN, MAY 15-18, 2000, IEEE VEHICULAR TECHNOLGY CONFERENCE, NEW YORK, NY: IEEE, US, vol. 2 OF 3. CONF. 51, 15 May 2000 (2000-05-15), pages 1150-1154, XP002164596 ISBN: 0-7803-5719-1 *
V. JACOBSON: "Compressing TCP/IP Headers for Low-Speed Serial Links" RFC 1144, [Online] 28 February 1990 (1990-02-28), pages 1-35, XP002210848 Retrieved from the Internet: <URL:http://www.faqs.org/rfcs/rfc1144.html > [retrieved on 2002-08-22] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003005657A1 (fr) * 2001-07-05 2003-01-16 Samsung Electronics Co., Ltd Appareil et procede de transmission d'une trame vocale dans un systeme de communication mobile base sur le tout ip
US7292554B2 (en) 2001-07-05 2007-11-06 Samsung Electronics Co., Ltd. Apparatus and method for transmitting a voice frame in an ALL-IP-based mobile communication system

Also Published As

Publication number Publication date
WO2002028056A3 (fr) 2003-10-09
EP1371204A2 (fr) 2003-12-17
CN1554174A (zh) 2004-12-08
JP2004511136A (ja) 2004-04-08
AU2001289918A1 (en) 2002-04-08

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&#39;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
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) 分组交换网络上的服务质量的自动适配
US20060187922A1 (en) Packet communication device
WO2002028056A2 (fr) En-tete de protocole internet pour reseaux de telecommunications
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
US8488629B2 (en) Specialized data transfer in a wireless communication system

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2001969767

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 018161383

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 2002531715

Country of ref document: JP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWP Wipo information: published in national office

Ref document number: 2001969767

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2001969767

Country of ref document: EP