USOO894.8206B2
`
`(12) United States Patent
`Pelletier et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 8,948,206 B2
`Feb. 3, 2015
`
`(54)
`
`INCLUSION OF QUALITY OF SERVICE
`INDICATION IN HEADER COMPRESSION
`CHANNEL
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`(75)
`
`Inventors: Ghyslain Pelletier, Boden (SE);
`Kristofer Sandlund, Gammelstad (SE)
`
`(73)
`
`Assignee: Telefonaktiebolaget LM Ericsson
`(publ), Stockholm (SE)
`
`(*)
`
`Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 530 days.
`
`(21)
`
`Appl. No.: 11/846,880
`
`(22)
`
`Filed:
`
`Aug. 29, 2007
`
`(65)
`
`Prior Publication Data
`US 2008/OO56273 A1
`Mar. 6, 2008
`
`(60)
`
`(51)
`
`(52)
`
`(58)
`
`Related U.S. Application Data
`Provisional application No. 60/824,242, filed on Aug.
`31, 2006.
`
`(2006.01)
`(2006.01)
`(2006.01)
`
`Int. C.
`H04.3/18
`H04L 29/06
`H04L 29/08
`U.S. C.
`CPC ................ H04L 69/04 (2013.01); H04L 67/04
`(2013.01); H04L 69/22 (2013.01)
`USPC .......................................................... 370/477
`Field of Classification Search
`CPC .......... H04L 69/04: HO4L 69/22: HO4L 67/04
`USPC .......................................................... 370/477
`See application file for complete search history.
`
`6,618,397 B1 * 9/2003 Huang .......................... 370/474
`6,882,637 B1 * 4/2005 Le et al. .........
`370,349
`2002/0003787 A1* 1/2002 Hayama et al.
`370,335
`2002/0038385 A1* 3/2002 Kalliokulu ...
`TO9,247
`2002/O126675 A1* 9, 2002 Yoshimura et al.
`370,395.21
`2003/0198226 A1* 10/2003 Westberg ...................... 370,393
`2004/0066764 A1* 4/2004 Koodli et al. ................. 370,331
`(Continued)
`
`FOREIGN PATENT DOCUMENTS
`
`EP
`
`1, 2003
`1271886 A2
`OTHER PUBLICATIONS
`
`Degermark, M. RFC 2507 IP Header Compression. Feb. 1999.*
`(Continued)
`Primary Examiner — Jason Mattis
`Assistant Examiner — Stephen J Clawson
`(74) Attorney, Agent, or Firm — Nixon & Vanderhye, P.C.
`(57)
`ABSTRACT
`Quality of service information (QoS) is included with a
`compressed header of a data packet and can be utilized by
`nodes Supporting the header compression channel to perform
`QoS enforcements at a sub-flow granularity level. A basic
`mode of a method comprises (1) processing a packet using a
`process having a process-associated quality of service
`requirement to form a processed packet, and (2) including,
`with a compressed header for the processed packet, the
`header-included quality of service information which is
`derived using information indicative of the process-associ
`ated quality of service requirement. In another mode the
`header-included quality of service information is derived
`both from the process-associated quality of service require
`ment and quality of service information extracted from the
`received packet.
`28 Claims, 13 Drawing Sheets
`
`
`
`
`
`
`
`INCLUDER NODE
`46
`EXTRACTOR
`
`22 r -
`
`30
`
`INTERMEDIATE
`NODE
`
`RECEIVER
`
`38:
`
`36 || PROCESSOR
`1 uosP
`HEADER
`ASSEMBLER/OOS
`INCLUDER
`
`
`
`y
`
`H
`
`VMWARE 1010
`
`

`

`US 8,948,206 B2
`
`Page 2
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`OTHER PUBLICATIONS
`
`Bormann, Robust Header Compression (ROHC) over PPP, IETF
`
`Pelletier et al, Robust Header Compression (ROHC): A Profile for
`
`7/2006 Hwang et al.
`
`
`2006/0153227 Al *
`9/2007 Lee et al.
`
`2007 /0206545 Al *
`
`
`11/2008 Zhang et al.
`
`2008/0285501 Al *
`1/2010 Jones
`
`2010/0020820 Al *
`
`Jonsson et al, RObust Header Compression (ROHC): A compression
`
`
`
`profile for IP, IETF RFC 3843, Jun. 2004.
`
`
`
`
`
`Pelletier, RObust Header Compression (ROHC): Profiles for UDP­
`Lite, IETF RFC 4019, Apr. 2005.
`370/465
`
`
`
`
`370/338
`RFC 3241, Apr. 2002.
`370/315
`
`
`
`370/465
`
`TCP/IP (ROHC-TCP), RFC 4996, Jul. 2007.
`
`
`
`
`Pelletier, Proposal for Invention Disclosures-Many Slides Secure
`
`
`
`
`
`RoHC, Internal Limited Slideware Presentation supporting this docu­
`Bormann, C. et. al. Network Working Group. RFC 3095-Robust
`
`
`ment, Apr. 2006.
`
`
`
`
`
`Header Compression Standard. Jul. 2001.*
`RFC 4995, Jul. 2007.
`
`
`
`
`
`
`International Search Report and Written Opinion mailed Feb. 8, 2008
`
`
`
`
`
`in corresponding PCT application PCT/SE2007/050597.
`IETF RFC 3711, Mar. 2004.
`
`
`
`
`Fortuna et al, "Robust Header Compression in 4G Networks with
`
`
`
`
`
`
`
`QoS Support", 2005 IEEE 16th International Symposium on Per­
`Jan. 2003.
`
`
`
`
`sonal, Indoor and Mobile Radio Communications, 2005, pp. 1835-
`
`
`
`1839.
`Dec. 1998.
`
`
`
`
`Van Jacobson,. "Compressing TCP/IP Headers for Low-Speed Serial
`
`
`
`
`
`
`
`Links", IETF RFC 1144, IETF Network Working Group, Feb. 1990.
`Dec. 1998.
`
`
`
`Degermark et al, IP Header Compression. IETF RFC 2507, IETF
`Pelletier et al, Robust Header Compression Version 2 (ROHCv2):
`
`
`
`
`
`
`
`Network Working Group, Feb. 1999.
`
`Profiles for RTP, UDP, IP, ESP and UDP-Lite.
`
`
`
`Casner et al,. Compressing IP/UDPIRTP Headers for Low-Speed
`
`
`
`
`Pelletier et al, Robust Header Compression (ROHC): ROHC over
`
`
`
`
`
`Serial Links. IETF RFC 2508, IETF Network Working Group, Feb.
`
`
`
`Channels that can reorder packets, IETF RFC 4224, Jan. 2006.
`1999.
`
`
`
`
`M. Degermark, et al., "IP Header Compression," Standards Track,
`
`
`
`Koren et al, Enhanced Compressed RTP ( CRTP)for Links with High
`
`RFC 2507, Feb. 1999.
`
`
`
`
`Delay, Packet Loss and Reordering. IETF RFC 3545, IETF Network
`Chinese Office Action issued in Application No. 200780032178.2,
`
`
`
`
`Working Group, Jul. 2003.
`
`dated Oct. 10, 2012 with English Translation.
`
`
`Bormann et al, RObust Header Compression (ROHC): Framework
`
`
`and four profiles: RTP, UDP, ESP and uncompressed. IETF RFC
`
`3095, Apr. 2001.
`
`Pelletier et al, The Robust Header Compression (ROHC)Framework,
`
`Baugher et al., The Secure Real-time Transport Protocol (SRTP),
`
`Price et al., Signalling Compression (SigComp), IETF RFC 3320,
`
`
`
`Pereira, IP Payload Compression Using DEFLATE, IETF RFC 2394,
`
`Friend et al, IP Payload Compression Using LZS, IETF RFC 2395,
`
`* cited by examiner
`
`

`

`U.S. Patent
`
`Feb. 3, 2015
`
`Sheet 1 of 13
`
`US 8,948,206 B2
`
`20
`1’
`
`34
`-------
`
`|
`
`INTERMEDIATE
`
`30
`
`INCLUDER NODE
`36
`
`PROCESSOR
`
`-QoSPY
`
`40
`
`HEADER
`ASSEMBLER/
`OOS
`INCLUDER
`
`42
`
`\
`
`H
`
`Fig. 1
`
`
`
`PROCESSING A PACKET USING A PROCESS HAVING
`A PROCESS-ASSOCATED OUALITY OF SERVICE
`RECUREMENT TO FORMA PROCESSED PACKET
`
`INCLUDING IN A COMPRESSED HEADER FOR THE
`PROCESSED PACKET, HEADER-INCLUDED QUALITY
`OF SERVICE INFORMATION WHICH IS DERVED
`USING INFORMATION INDICATIVE OF THE PROCESS -
`ASSOCATED QUALITY OF SERVICE RECUREMENT
`
`3-2
`
`Fig. 3
`
`

`

`U.S. Patent
`
`Feb. 3, 2015
`
`Sheet 2 of 13
`
`US 8,948,206 B2
`
`36
`
`PROCESSOR
`
`INCLUDER NODE
`
`PROCESSOR PERFORMS ONE OR
`MORE PROCESSES HAVING
`PROCESS-ASSOCIATED OOS
`REOUIREMENT:
`o HEADER COMPRESSION
`o PAYLOAD COMPRESSION
`SIGNALING COMPRESSION
`ENCRYPTION
`AUTHENTICATION
`CHECKSUMMING FOR
`VERIFICATION
`o SEQUENCING
`
`
`
`22'
`
`46
`
`EXTRACTOR
`
`INCLUDER NODE
`
`EXTRACTOR CAN OBTAIN
`EXTRACTED QOS INFORMATION
`FROM:
`o APPLICATION LAYER
`o APPLICATION TRANSPORT
`PROTOCOL
`o TRANSPORT PROTOCOL
`o NETWORK PROTOCOL
`
`

`

`U.S. Patent
`
`Feb. 3, 2015
`
`Sheet 3 of 13
`
`US 8,948,206 B2
`
`8
`
`CID
`
`to Gyepie3d
`
`
`
`s
`
`SMALLCIDs
`to C
`1stoctet base hdr
`Remainder base hdr
`
`'s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s
`
`A d C
`
`e
`
`service&
`
`general formal
`1st octet base hdr
`for 2 octets of CID ox
`Remainder base hdr \
`
`n \, see
`
`
`
`
`
`stoctet base hdr
`. .
`1 or 2 octets of CD?
`Remainder base hdr Y.to CD
`CID
`CID
`
`.
`
`Fig. 4A
`
`

`

`U.S. Patent
`
`Feb. 3, 2015
`
`Sheet 4 of 13
`
`US 8,948,206 B2
`
`QOS-enabled ROHC Channel
`
`;
`
`:
`
`fox,
`
`Aisi inieriesiae
`Before Processing Processing optional
`o
`gos
`iii.30S 28iai i880s&d
`-'t kala wo
`ii. xi. No is:iisati
`Cix i3 isshead
`: “ .
`.
`.
`| | | | |
`Gos
`Aidosoceremoved
`of CID 145 ~~.
`CD 145
`
`SMALL CIDs,
`
`saaaa--------as-as-a----as-a-sataaaaaa-aa
`
`o S
`
`III"
`stoctet base her
`|
`stocerate a
`ti Remainder base hdr
`
`Sesssssssssssssssssssssssssssssssssssssssssssssss
`
`
`
`asso'.
`
`general format
`Si
`| Add-QoS Octet
`w
`Add-CDoctet
`st cease cir
`Before Processing After intermediate
`1 or 2 octets of CIDA LARGE CIDS,
`Processing optional
`Remainder base her \ with QOS enabled
`to Qos - to cos - See"
`st cetessed
`is teased
`is: octet base heir
`for 2 octets of CID
`or 2 octets of CID,
`or 2 octets of CID
`Remainder base hd.
`Remainder base hdr.
`Remainder base hd.
`Fig. 4B
`
`

`

`U.S. Patent
`
`Feb. 3, 2015
`
`Sheet 5 of 13
`
`US 8,948,206 B2
`
`INCLUDER NODE
`EXTRACTOR
`
`22 r - - - - - - - 34
`-
`
`20'
`1.
`
`30
`
`
`
`
`
`
`
`
`
`INTERMEDIATE
`NODE
`
`RECEIVER
`
`HEADER
`ASSEMBLER/OOS
`INCLUDER
`
`y
`
`
`
`
`
`EXTRACTING OUALITY OF SERVICE INFORMATION
`FROMA RECEIVED PACKET AND DERVING THE
`HEADER-INCLUDED OUALITY OF SERVICE
`INFORMATION USING BOTH THE OUALITY OF
`SERVICE INFORMATION EXTRACTED FROM THE
`RECEIVED PACKET AND THE INFORMATION
`INDICATIVE OF THE PROCESS-ASSOCATED
`OUALITY OF SERVICE REOUREMENT
`
`PROCESSING A PACKET USING A PROCESS HAVING 6-1
`A PROCESS-ASSOCATED OUALITY OF SERVICE
`RECQUIREMENT TO FORMA PROCESSED PACKET
`
`INCLUDING IN A COMPRESSED HEADER FOR THE
`PROCESSED PACKET, HEADER-INCLUDED QUALITY
`OF SERVICE INFORMATION WHICH IS DERVED
`USING INFORMATION INDICATIVE OF THE PROCESS
`ASSOCIATED OUALITY OF SERVICE RECUREMENT
`
`Fig. 6
`
`

`

`U.S. Patent
`
`Feb. 3, 2015
`
`Sheet 6 of 13
`
`US 8,948,206 B2
`
`
`
`
`
`
`
`
`
`
`
`s e.g. Video- e.g. i-frame
`i e.g. RTP H e.g. application-specific header
`e.g. VDP - e.g. port
`e.g. P4H. e.g. ToS Octet, next protocol type
`Link - e.g. nr ?ty, HARQ, etc
`Physical- e.g. BER target, ts power,
`
`
`
`
`
`
`
`.
`
`.
`
`.
`
`. . . . . .
`
`.
`
`.
`
`.
`
`.
`
`. . . . . . . . .
`
`.
`
`.
`
`.
`
`.
`
`. . .
`
`reliability, delay, etc
`
`e. H e.g. S
`packet, rt, etc
`C, SYNIFN packet, rt, et
`..C.
`e.g, IPv6 H e.g. Traffic Class Octet, next protocol type
`Link H. e.g. MPLS (see also RC3270)
`Physical H e.g. reliability, delay
`
`YM
`
`Fig. 8
`
`

`

`U.S. Patent
`
`Feb. 3, 2015
`
`Sheet 7 of 13
`
`US 8,948,206 B2
`
`
`
`EXTRACOR 5
`QoSEM 49
`
`PROCESSOR
`
`7
`HEADER 48
`ASSEMBLER/QOS
`INCLUDER
`
`INTERMEDIATE
`NODE
`
`NSPECTING A CHANNEL PART OF A COMPRESSED
`HEADER OF A PACKET RECEIVED FROM ANOTHER
`NODE TO OBTAIN OUALITY OF SERVICE
`INFORMATION FOR THE PACKET
`
`PERFORMING A FUNCTION AT A SUB-FLOW
`GRANULARITY LEVEL USING THE COMBINED
`OUALITY OF SERVICE INFORMATION OF THE
`PACKET
`
`INTERMEDIATE NODE
`
`

`

`U.S. Patent
`
`Feb. 3, 2015
`
`Sheet 8 of 13
`
`US 8,948,206 B2
`
`
`
`INTERMEDIATE
`NODE
`
`52
`
`PROCESSOR
`
`Fig. 10
`
`PROCESSOR PERFORMS ONE ORMORE
`INTERMEDIATE NODE FUNCTIONS:
`o OUEUE MANAGEMENT FUNCTION
`SCHEDULING FUNCTION
`POWER SETTING FUNCTION
`TARGET NUMBER OF
`ul TRANSMISSIONS FUNCTION
`o HYBRD AUTOMATIC REPEAT
`REQUEST (HARO) FUNCTION
`o BITERROR RATE (BER) FUNCTION
`o SEGMENTATION AND
`CONCATENATION FUNCTION
`o MULTI-USER FRAME FUNCTION
`
`INTERMEDIATE NODE OPERATES INDIFFERENT
`SCENARIOS:
`O FOR EACH OF PLURAL PROCESSED PACKETS OF A
`SAME PACKET FLOW, USING THE HEADER-INCLUDED
`QUALITY OF SERVICE INFORMATION INCLUDED IN
`THE COMPRESSED HEADER OF A RESPECTIVE
`PROCESSED PACKET BEARING THE HEADER
`INCLUDED OUALITY OF SERVICE INFORMATION
`WHEN PERFORMING THE INTERMEDIATE NODE
`FUNCTION FOR THE RESPECTIVE PROCESSED
`PACKET
`FOR EACH OF PLURAL PROCESSED PACKETS
`BELONGING TO DIFFERENT PACKET FLOWS FOR A
`SAME USER, USING THE HEADER-INCLUDED
`OUALITY OF SERVICE INFORMATION INCLUDED IN
`THE COMPRESSED HEADER OF A RESPECTIVE
`PROCESSED PACKET BEARING THE HEADER
`INCLUDED OUALITY OF SERVICE INFORMATION
`WHEN PERFORMING THE INTERMEDIATE NODE
`FUNCTION FOR THE RESPECTIVE PROCESSED
`PACKET
`USING THE HEADER-INCLUDED QUALITY OF SERVICE
`INFORMATION INCLUDED IN THE COMPRESSED
`HEADER WHEN PERFORMING THE INTERMEDIATE
`NODE FUNCTION FOR A PROCESSED PACKET
`DESTINED FOR PLURAL. USERS
`
`

`

`U.S. Patent
`
`Feb. 3, 2015
`
`Sheet 9 of 13
`
`US 8,948,206 B2
`
`
`
`TTTTTTTTTTTT INCLUDER NODE
`EXTRACTING OUALITY OF SERVICE INFORMATION
`FROMA RECEIVED PACKET AND DERIVING THE
`HEADER-INCLUDED OUALITY OF SERVICE
`INFORMATION USING BOTH THE QUALITY OF
`SERVICE INFORMATION EXTRACTED FROM THE
`RECEIVED PACKET AND THE INFORMATION
`INDICATIVE OF THE PROCESS-ASSOCATED
`OUALITY OF SERVICE RECQUIREMENT
`
`PROCESSING A PACKET USING A PROCESS HAVING
`A PROCESS-ASSOCATED OUALITY OF SERVICE
`RECUREMENT TO FORMA PROCESSED PACKET
`
`INCLUDING IN A COMPRESSED HEADER FOR THE
`PROCESSED PACKET, HEADER-INCLUDED QUALITY
`OF SERVICE INFORMATION WHICH IS DERVED
`USING INFORMATION INDICATIVE OF THE PROCESS
`ASSOCATED OUALITY OF SERVICE RECUREMENT
`
`USING THE HEADER-INCLUDED OUALITY OF
`SERVICE INFORMATION TO PERFORMAN
`INTERMEDIATE NODE FUNCTION AT AN
`INTERMEDIATE NODE OF THE NETWORK
`
`INTERMEDIATE NODE
`
`

`

`U.S. Patent
`
`Feb. 3, 2015
`
`Sheet 10 of 13
`
`US 8,948,206 B2
`
`
`
`Service
`Application
`Transport
`
`Fi9. 1 3
`
`
`
`
`
`e.g. encryption
`ciphering
`authentication
`header compression - e.g. RoHC
`
`
`
`
`
`RoC Channel
`(encrypted or not
`
`^ -
`
`
`
`------ sessessessessess-s-s-s-s-s-s-s-s
`
`-
`
`fication
`
`

`

`U.S. Patent
`
`Feb. 3, 2015
`
`Sheet 11 of 13
`
`US 8,948,206 B2
`
`
`
`
`
`
`
`Example general
`Compressed header
`format (non-R)
`Qossupport - Add-QoS octet
`Multiplexing (small) - Add-CDoctet
`Packet type D - 1st Octet base hdr
`Multiplexing largel- 1 or 2 octets of CID
`Sequencing - 12 octets wish SN
`Congressio:
`on
`Renaisses of
`aid
`base header
`Nerseas...rssssseau.
`Encryption
`Xerxes
`
`M.M.
`
`ressess-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-s-sx
`
`----------------------------------
`
`res
`
`:
`
`
`
`Authentication
`and Verification
`
`

`

`U.S. Patent
`
`Feb. 3, 2015
`
`Sheet 12 of 13
`
`US 8,948,206 B2
`
`
`
`f
`
`Adaptation
`layer
`
`
`
`
`
`
`
`
`
`YYYYYYYYYYYYYYYYYYYYY
`
`YYYYYYYYYYYYYYYYYYYYYYY
`
`PFlow. PFlow
`
`YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
`
`Bik
`
`YYYYYYYYYYYYYYYYYYYYYYY,
`
`IP Flown
`
`exy as
`
`Flowcastication
`
`six- ex
`
`Cassification
`
`
`
`Header Compression
`CIDOCID.CDCDoCD.CIDk
`
`-----
`
`MAC Multiplexing
`MAC Multiplexing
`layer 2 - -
`
`
`
`

`

`U.S. Patent
`
`Feb. 3, 2015
`
`Sheet 13 of 13
`
`US 8,948,206 B2
`
`Application
`Transport
`x
`Network
`-. -
`i.....................
`ciphering
`
`
`
`
`
`
`
`
`
`xe
`
`.
`
`
`
`e.g. encryption?
`authentication
`e.g. RoHC
`
`
`
`RoHC Channel
`(encrypted or not)
`
`
`
`Fig. 17
`
`

`

`US 8,948,206 B2
`
`1.
`INCLUSION OF QUALITY OF SERVICE
`INDICATION IN HEADER COMPRESSION
`CHANNEL
`
`BACKGROUND
`
`10
`
`15
`
`25
`
`35
`
`40
`
`2
`Low-Speed Serial Links, IETF RFC 1144, IETF Network
`Working Group, February 1990; RFC 2507 (IPHC) Mikael
`Degermark, Björn Nordgren, Stephen Pink. IP Header Com
`pression, IETF RFC 2507, IETF Network Working Group,
`This application claims the benefit and priority of U.S. 5 February 1999; RFC 2508 (CRTP) Steven Casner, Van Jacob
`son, Compressing IP/UDP/RTP Headers for Low-Speed
`provisional patent application 60/824,242, filed Aug. 31,
`Serial Links, IETF RFC 2508, IETF Network Working
`2006, entitled “METHODS FOR COMBINING QUALITY
`Group, February 1999; Koren, T., Casner, S., Geevarghese, J.,
`OF SERVICE (QoS) AND HEADER COMPRESSION
`Thompson B. and P. Ruddy, Enhanced Compressed RTP
`CHANNEL, which is incorporated by reference herein in its
`entirety.
`(CRTP) for Links with High Delay, Packet Loss and Reorder
`ing. IETF RFC 3545, IETF Network Working Group, July
`2003; Carsten Bormann, et al. RObust Header Compression
`(ROHC). Framework and four profiles. RTP, UDP ESP and
`uncompressed. IETF RFC 3095, April 2001); Jonsson, L. and
`G. Pelletier, RObust Header Compression (ROHC). A com
`pression profile for IP, IETF RFC 3843, June 2004; Pelletier,
`G., RObust Header Compression (ROHC). Profiles for UDP
`Lite, IETF RFC 4019, April 2005; Pelletier, G., Sandlund, K.
`and L. Jonsson, Robust Header Compression (ROHC). A
`Profile or TCP/IP. Internet Draft (work in progress),
`<RFC4996, July 2007 http://tools.ietforg/rfc/rfc4996.txtd,
`June 2006; and Pelletier, G. et Sandlund, K., Robust Header
`Compression Version 2 (ROHCv2). Profiles for RTP, UDP, IP
`ESP and UDP-Lite, Internet Draft (work in progress), draft
`pelletier-rohc-rohcV2-profiles-01.txt, May 2007 http://tool
`s.ietforg/id/draft-ietf-rohc-rfc3095bis-rohcV2-profiles
`01.txt, June 2006. All the foregoing are incorporated herein
`by reference in their entirety. Any of these types of compres
`sion may be designed to make use of sequence numbers and
`checksums.
`Traditionally, the UTRAN architecture has separated func
`tionalities into different nodes as follows: the Radio Network
`Control (RNC) function handles sequencing when lossless
`relocation is Supported (optional). The ciphering (e.g.,
`encryption) occurs in the NodeB (i.e. radio base station trans
`mitter), and requires in-order delivery of each Service Data
`Units (SDUs) to maintain the ciphering context. In order to
`ensure that the ciphering does not loose synchronization, a
`Layer 2 (L2) Frame Checksum Sequence (FCS) is normally
`used, adding additional octets for transmission over the air
`interface. The decision about what quality of service would be
`applied to a packet is mainly performed in the RNC, while it
`is enforced at the transmission point, the NodeB.
`The state-of-the-art in terms of QoS in wireless systems is
`to first establish a Radio Bearer (RB) (or “connection') for a
`specific service, for one or more combinations of e.g. IP
`Source and destination addresses, UDP source and destina
`tion ports. The RB includes a set of parameters or traffic
`handling requirement that the transmitter should fulfill. This
`same processing is applied for any packet belonging to that
`service and being routed to the same RB, independently of
`other possible QoS differentiation. Packets belonging to the
`same service may be “routed to different radio bearers by
`Some selector process, but this is done independently from the
`transmitter state (queue managements, scheduling, CIR, cell
`load and other possible factors that could influence the treat
`ment of a packet) and not in the transmitting node, as the RB
`edges are not located in the transmitting node per definition.
`The above limits the NodeB in its capability to adjust its
`transmission mechanisms, e.g. Hybrid Automatic Retrans
`mission request (H-ARO), Scheduling and queue manage
`ment, to a finer granularity for each packet and also between
`multiple receivers being served within a cell. The NodeB is
`often limited to its static knowledge of the radio bearer (i.e.
`the connection) and of the QoS parameters associated to it and
`to which the SDU belongs to, and possibly from some other
`information propagated over the (standardized) interface
`
`I. Technical Field
`This technology pertains to wireless communications, and
`particularly to compression of packet headers transmitted in a
`radio access network.
`II. Related Art and Other Considerations
`Due to the tremendous success of the Internet, it has
`become a challenging task to make use of the Internet Proto
`col (IP) over all kinds of links. However, because of the fact
`that the headers of the IP protocols are rather large, it is not
`always a simple task to make this come true for narrow band
`links, for example wireless cellular links. As an example,
`consider ordinary speech data transported by the protocols
`(IP, UDP, RTP) used for Voice-over-IP (VoIP), where the
`header may represent about 70% of the packet resulting in
`a very inefficient usage of the link.
`The term header compression (HC) comprises the art of
`minimizing the necessary bandwidth for information carried
`30
`in headers on a per-hop basis over point-to-point links. The
`techniques in general have a more than ten-year-old history
`within the Internet community; several commonly used pro
`tocols exist such as RFC 1144 (VJ) Van Jacobson, Compress
`ing TCP/IP Headers for Low-Speed Serial Links, IETF RFC
`1144, IETF Network Working Group, February 1990; RFC
`2507 (IPHC) Mikael Degermark, Björn Nordgren, Stephen
`Pink. IP Header Compression. IETF RFC 2507, IETF Net
`work Working Group, February 1999; and RFC 2508 (CRTP)
`Steven Casner, Van Jacobson. Compressing IP/UDP/RTP
`Headers for Low-Speed Serial Links, IETF RFC 2508, IETF
`Network Working Group, February 1999.
`Header compression takes advantage of the fact that some
`fields in the headers are not changing within a flow, or change
`with small and/or predictable values. Header compression
`schemes make use of these characteristics and send static
`information only initially, while changing fields are sent with
`their absolute values or as differences from packet to packet.
`Completely random information has to be sent without any
`compression at all.
`Header compression is thus an important component to
`make IP services over wireless, such as voice and video
`services, economically feasible. Header compression Solu
`tions have been developed by the Robust Header Compres
`sion (ROHC) Working Group of the IETF to improve the
`efficiency of such services.
`Other optimizations, such as other types of compression,
`can also be used to further increase the performance of band
`width-limited systems. These include payload compression
`see, e.g., Pereira, R., IP Payload Compression Using
`DEFLATE, IETF RFC 2394, December 1998; and Friend, R.
`et R. Monsour, IP Payload Compression Using LZS, IETF
`RFC 2395, December 1998; signaling compression see,
`e.g., Baugher M. et al., The Secure Real-time Transport Pro
`tocol (SRTP), IETF RFC 3711, March 2004; header removal
`and regeneration, and header compression see, e.g., RFC
`1144 (VJ) Van Jacobson, Compressing TCP/IP Headers for
`
`45
`
`50
`
`55
`
`60
`
`65
`
`

`

`US 8,948,206 B2
`
`5
`
`10
`
`15
`
`25
`
`30
`
`3
`between the RNC and the NodeB associated to the packet.
`Some NodeBs may inspect the SDU before transmission to
`try to extract further information, however little is available as
`SDUs at this point have already been processed by e.g. header
`compression and/or encryption functions.
`In contrast, the current proposal for the SAE/LTE architec
`ture is to remove the RNC, which leads to that the ciphering
`function and the PDCP function, which hosts the header
`compression function, are now located in the same node
`(access gateway—aGW). Both the ciphering and the PDCP
`functions terminate into the User Equipment (UE) on the
`other end. In other words, the interface between the a0W
`node and the eNB node is deemed to be untrusted. The S1
`interface thus requires that ciphering be applied to the user
`traffic, and this propagates up to the user equipment unit
`(UE). A secure tunnel over the S1 interface would not solve
`the problem of trust of the eNB node. Finally, the mapping of
`the QoS to radio bearer (i.e. connection) remains, as the
`limitations attached to it.
`Often QoS is defined in a connection-oriented fashion (per
`flow/receiver or per physical channel), or because the tradi
`tional distribution of functions (e.g. encryption and header
`compression) prevents this combination. Such traditional
`definition/usage of QoS is illustrated by FIG. 16. In FIG. 16,
`the L2 ciphering traditionally occurs in a different node than
`that where the enforcement of the QoS occurs, i.e., the entire
`compressed header is encrypted.
`Header compression “hides the QoS information carried
`in upper layers, while it adds its own “sensibility” to how
`individual header compressed packets are QoS handled. The
`same applies with security. As shown in FIG. 17, the state
`of-the-art often uses an interface between the L2 and upper
`layers, and when multiple L2 are traversed, each L2 has to
`interface with each other to translate the QoS requirement of
`each packet.
`One problem is how to derive and how to propagate the
`QoS information that is the most suitable for a Protocol Data
`Unit (PDU), and how this information can be propagated to
`the transmitter so that more flexible algorithms to enforce
`QoS requirements may be implemented. Traditionally, this
`has not been possible to do within the header compression
`channel, as functions where often separated into different
`physical nodes and “interfering with each other.
`
`4
`following: header compression; payload compression; sig
`naling compression; encryption; authentication; checksum
`ming for verification; and sequencing. The basic mode can be
`performed at a network node such as an access gateway node.
`A second mode of the method further comprises extracting
`quality of service information from a received packet and
`deriving the header-included quality of service information
`using both the quality of service information extracted from
`the received packet and the information indicative of the
`process-associated quality of service requirement. In an
`example implementation, the extracted quality of service
`information can be supplied by a network layer or higher
`layer of the telecommunications system. The quality of Ser
`vice information can be extracted ordeduced from a received
`packet at a packet inspector of a network node (e.g., access
`gateway node). The received packet can comprise, for
`example, a Protocol Data Unit (PDU).
`The acts of the first mode and the second mode can be
`performed at a first node of a network. A third mode of the
`method, usable with either the first mode or the second mode,
`further comprises using the header-included quality of Ser
`Vice information to perform an intermediate node function at
`an intermediate node of the network. The intermediate node
`being intermediate the first node and a receiver. The first node
`can be, for example, an access gateway node.
`In example implementations, the intermediate node func
`tion can be at least one of the following: a queue management
`function; a scheduling function; a power setting function; a
`target number of transmissions function; a hybrid automatic
`repeat request (HARQ) function; a bit error rate (BER) func
`tion; a segmentation and concatenation function; a multi-user
`frame function.
`The third mode can operate in various scenarios. A first
`scenario of the third mode further comprises, for each of
`plural processed packets of a same packet flow (e.g., RoHC
`CID or radio bearer), using the header-included quality of
`service information included with the compressed header of a
`respective processed packet bearing the header-included
`quality of service information when performing the interme
`diate node function for the respective processed packet.
`A second scenario of the third mode further comprises, for
`each of plural processed packets belonging to different packet
`flows for a same user, using the header-included quality of
`service information included with the compressed header of a
`respective processed packet bearing the header-included
`quality of service information when performing the interme
`diate node function for the respective processed packet
`A third scenario of the third mode further comprises, using
`the header-included quality of service information included
`with the compressed header when performing the intermedi
`ate node function for a processed packet destined for plural
`USCS
`Another aspect of the technology concerns a node of a
`telecommunications system which is configured to include,
`with a compressed header for a data packet handled by the
`node, header-included quality of service information derived
`using information indicative of a process-associated quality
`of service requirement of a process performed by the node.
`In an example first embodiment, the node comprises a
`processor and a header assembler. The processor is config
`ured to process the packet using the process having the pro
`cess-associated quality of service requirement and to form a
`processed packet. The header assembler is configured to
`include, in the compressed header for the processed packet,
`the header-included quality of service information.
`In an example second embodiment, the header-included
`quality of service information is derived by the node using
`
`35
`
`40
`
`SUMMARY
`
`45
`
`50
`
`The technology generally concerns methods, apparatus,
`systems, and techniques to derive, include, and propagate
`Quality of Service (QoS) information found in headers and/or
`payload of upper protocol layers (IP protocols) for a Protocol
`Data Units (PDU), or information related to optimization
`algorithms applied to the PDU, within the header compres
`sion channel (e.g. RoHC).
`In one of its aspects the present technology concerns a
`packet handling method for a telecommunications system. A
`55
`basic mode of the method comprises (1) processing a packet
`using a process having a process-associated quality of service
`requirement to form a processed packet and (2) including,
`with a compressed header for the processed packet, header
`included quality of service information which is derived
`using information indicative of the process-associated quality
`of service requirement.
`An example implementation of the basic mode further
`comprises including the header-included quality of service
`information in a channel part of the compressed header of the
`processed packet. The process having the process-associated
`quality of service requirement can comprise at least one of the
`
`60
`
`65
`
`

`

`5
`both quality of service information supplied by a network
`layer or higher layer of the telecommunications system and
`information indicative of a process-associated quality of Ser
`Vice requirement of a process performed by the node. In an
`example implementation of the second embodiment, the node
`further comprises an extractor configured to extract the qual
`ity of service information from a received packet.
`In accordance with either the first example embodiment or
`the second example embodiment, the node is configured to
`include the combined quality of service information in a
`channel part of the compressed header of the processed
`packet.
`In accordance with either the first example embodiment or
`the second example embodiment, the process having the pro
`cess-associated quality of service requirement can comprise
`at least one of the following: header compression; payload
`compression; signaling compression; encryption; authentica
`tion; checksumming for verification; and sequencing.
`In accordance with either the first example embodiment or
`the second example embodiment, the node can be an access
`gateway node.
`Another aspect of the technology concerns an intermediate
`node of a telecommunications system which is configured to
`handles a flow of data packets traveling from another node to
`a receiver. In an example embodiment, the intermediate node
`comprises a packet inspector and a processor. The packet
`inspector is configured to inspect a channel part of a com
`pressed header of a packet received from the other node to
`obtain quality of service information for the packet. The
`processor is configured to perform a function at a Sub-flow
`granularity level using the combined quality of service infor
`mation of the packet.
`In example embodiments, the function of the intermediate
`node can be at least one of the following: a queue manage
`ment function; a scheduling function; a power setting func
`tion; a target number of transmissions function; a hybrid
`automatic repeat request (HARQ) function; a bit error rate
`(BER) function; a segmentation and concatenation function;
`a multi-user frame function
`The processor of the intermediate node can be configured
`to operate upon various scenarios. For a first scenario, the
`processor of the intermediate node is configured to use, for
`each of plural processed packets of a same packet flow (e.g.,
`RoHCCID or radio bearer), the quality of service information
`included with the compressed header of a respective packet
`45
`bearing the combined quality of service information when
`performing the function for the respective packet
`For a second scenario, the processor of the intermediate
`node is configured to use, for each of plural processed packets
`belonging to different packet flows for a same user, the quality
`of service information included with the compressed header
`of a respective packet bearing the combined quality of service
`information when performing the intermediate node function
`for the respective packet.
`For a third scenario, the processor of the intermediate node
`is configured to use the quality of service information
`included with the compressed header when performing the
`function for a packet destined for plural users.
`Preferably, the processor of the intermediate node is con
`figured to use the quality of service information included with
`the compressed header to perform the function at a per-packet
`granularity level.
`In another of its aspects, the technology further concerns a
`method of operating an intermediate node of a teleco