Download presentation
Presentation is loading. Please wait.
Published byLauren Austin Modified over 9 years ago
1
Rhys W. Robinson (Rhys.Robinson@terrestar.com), TerreStar NetworksRhys.Robinson@terrestar.com Sourabh Gupta (Sourabh.gupta@ico.com), DBSD North America (ICO)Sourabh.gupta@ico.com Eric Jacks (Eric.Jacks@lightsquared.com), LightSquared Communications Orlett Pearson (orlett.pearson@alcatel-lucent.com), Alcatel-Lucentorlett.pearson@alcatel-lucent.com Ravindra Patwardhan, Jun Wang, George Cherian (ravindra, jwang, gcherian@qualcomm.com), Qualcomm Incorporated Sept 13, 2010 Page 1 xHRPD Header Removal Support Notice © 2010. All rights reserved. Contributors grant a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner ’ s name any Organizational Partner ’ s standards publication even though it may include all or portions of this contribution; and at the Organizational Partner ’ s sole discretion to permit others to reproduce in whole or in part such contribution or the resulting Organizational Partner ’ s standards publication. Contributors are also willing to grant licenses under such contributor copyrights to third parties on reasonable, non- discriminatory terms and conditions for purpose of practicing an Organizational Partner ’ s standard which incorporates this contribution. This document has been prepared by the contributors to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on contributors. Contributors specifically reserve the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of the contributors other than provided in the copyright statement above.
2
Why Need a New Header Compression Mechanism in xHRPD? ROHC as specified in (e)HRPD for sending compressed headers contains 1 or more bytes: Context ID (CID), Sequence Number (SN), CRC etc. xHRPD reverse link may need to operate under severe link budget constraints. It does so using dedicated narrowband channel and low bit rate (2 kbps) codec for VoIP. 2 kbps encoder generates 5 bytes of payload every 20 ms during active speech. Even 1 or 2 bytes of header overhead resulting from ROHC is not acceptable. Complete Header Stripping and Generation (HSG) mechanism is needed. Page 2
3
Field Classification: IPv4 total length IP fragment offset IP_ID VersionIHLtype-of-service TTL ProtocolIP checksum IP source address IP destination address normally constant redundant (link layer) Frequent change fragments force increment++ 081624 Flag Page 3
4
Field Classification: IPv6 Flow Label Hop Limit Payload Length VersionPriority IP source address (16 Octets) IP destination address (16 Octets) normally constant redundant (link layer) Frequent change fragments force increment++ 081624 Next Header Type Page 4
5
Field Classification : UDP destination portsource port UDP checksumUDP length constant redundant (link layer) always transmitted (if used) 081624 Page 5
6
Field Classification : RTP RTP sequence numberV timestamp synchronization source (SSRC) PXCC Mpayload type contributing source (CSRC) CC = 0-15 constanttransmitted upon change (rare) redundant for EVRC/SMV payload increment ++ 081624 Page 6
7
Design Overview Design only applies to xHRPD air interface But both HRPD and eHRPD core network can be reused On Reverse link, reuse the concept of cdma1x Header Removal Design (SO60) as much as possible: Option 1: The header stripping and generation performed between MS and AN MS removes Air-Interface/RTP/UDP/IP headers Air-Interface/RTP/UDP/IP headers are recovered at the AN Transparent to the PDSN/HSGW Option 2: The header stripping and generation performed between MS and PDSN/HSGW MS removes Air-Interface/RTP/UDP/IP headers Air-Interface headers are recovered at the AN RTP/UDP/IP headers are recovered at the PDSN/HSGW The AN may need to provide link layer information to assist IP headers recovered at the PDSN/HSGW On Forward link: Uses ROHC U mode because: AT can not distinguish between packet loss and no packets received. There is limited bandwidth to send the feedback on reverse link Current ROHC design can be reused ROHC U mode Compressor is located either in AN or PDSN/HSGW Page 7
8
Option 1: HSG performed between MS and AN (Reverse Link) Page 8
9
Option 1: HSG Protocol Stack Reverse Link (HSG Performed Between MS and AN) Page 9
10
Header Compression Protocol Context Setup - ICI (Initial Context Info): Initializes the de-compressor context in the AN HRU in AT sends ICI message to AN HRU in AN sends ICI Ack to AT User Bearer HRU: HRU in AT removes headers (Compressor function) HRU in AN adds a header to each received codec frame (Decompressor function) HRL: HRL in AT makes sure in-order delivery of data frames over the air link every 20 ms HRL in the AN detects silent frame or packet loss over the wireless link and then indicates it to HRU in the AN 2 new Higher-Layer Protocol IDs defined for Flow Protocol 0x09 – Zero Header Compression (Bearer) 0x0A – Zero Header Compression (Initial Context) By default link flow 2 is bound to flow protocol 0x0A Page 10
11
How to Reconstruct VoIP headers? The HRU (Decompressor module) in the AN reconstructs the VoIP header based on: The static information of the Air-Interface/ RTP/UDP/IP header sent by the HRU (ICI) in the AT during the context setup Reconstruct header information: Air Interface header is reconstructed using context information provided by AT. RTP sequence number is reconstructed using link layer-assistance from the RLP layer. The HRL in RNC provides indication for good packet and packet received in error during the voice conversation. HRU increments the sequence number for every new packet (both good and error packets) received, with the initial RTP sequence number obtained from the Initial Context Setup. The HRU uses the error indication to increment the RTP sequence number, but no packet is sent to the higher layer. IP-ID is filled with the same value as the RTP sequence number. (Since the payload size of VoIP packets generated by the vocoder fits exactly into one physical layer packet, there is no IP fragmentation done on a VoIP packet and the IP-ID field can be set to any unique value for each packet.) RTP Time stamp: The HRL provides the HRU the CDMA timestamp (in units of 12 slots or 20 ms) for every new packet received. The HRU uses this information to compute the RTP timestamp. The RTP timestamp increases by 160 (8 K samples/sec * 20 ms) for consecutive packets. Page 11
12
Compressor State Machine Page 12 Context Update mode Optimistic Compression mode Reliable Compression mode Send ‘n’ ICI packets Timeout waiting for ACK ACK received for ICI packet Send compressed packets New Context / Reset State
13
Decompressor State Machine Page 13 Null Context mode Received a ICI packet / Initialize context and Send ACK Decompression mode Received ICI packet / Store Context and Send ACK Received compressed packet / Decompress it
14
Call Flow (Reverse Link) Page 14
15
ICI details FieldLengthComment MessageID8 RLPLinkFlowNumber8 SourceIPv4Address32IPv6 will use different ICI message (Plan to bring to the next revision) DestinationIPv4Address32 SourceUDPPortAddress16 DestinationUDPPortAddress16 RTPSequenceNumber16 PayloadType7 Reserved1 Page 15
16
Air Interface Header Reconstruction Page 16 Header How AN sets the Header MAC Trailer (2 bits)Set to indicate Format A connection layer packet Connection header (0 bits)No header for Format A packet Stream Layer (2 bits)Stream ID (Set to default value of EMPA) RLP header (14 bits)LinkFlowNumber (5 bits) = from ICI Route (1 bit) = Always 0 SEQ (6 bits) = Always 0 when CRC passed FirstDataUnit (1 bit) – Always 1 LastDataUnit(1 bit) – Always 1
17
Recommendations Review and adopt the concept Create a separate document for xHRPD header compression mechanism either in TSG-C or in TSG- X for Option 1 Decide which TSG will be a primary working group Regardless it should be a joint effort of both TSGs Option 2 can be added in the next revision of the specification if operator requests it Page 17
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.