1 Transparent GEHCO Slides for p __luc_gehco-t Lucent Technologies Tom Hiller Pete McCann

2 Contents Review –Non transparent GEHCO –0byte Transparent GEHCO –How to add transparency –Packet types Alternate Proposal: Mux PDU Note: See contribution for official cover sheet with Notice

3 Original GEHCO: Review

4 Original GEHCO: Comments Non-transparent compression –time stamp and sequence number fields not transported exactly –Relies on the underlying physical timing to transport RTP time stamp and sequence number implicitly –Uses a “full header” (re:RFC2508) to init static headers Encapsulations did not receive attention No commonality with ROHC framework –fullheader based on RFC 2507/8

5 0Byte Proposal Comment Did not state which packets should receive ROHC compression versus 0byte compression Has issues if CSRCs change at same time - for example with a nested mixer and Does not address which service instance (at the PDSN) to use for 0byte Is not transparent until the need for an update is known to the MN or PDSN (re: verifications are every sec or two) –RAN buffer under/over run –TE (relay model) does not know abouthHard handoff Requires the 171st bit -- need to verify with TSGC codec people that this is OK with them Update + full rate evrc -> blanked evrc sample

6 Transparent GEHCO Reproduces packets exactly after update is received –Sync disruption to update: non transparent –Perhaps tenth of second, but could be longer if RLP buffer is full –Packets delivered that are not transparent until update is received Assumes the codec transmits continuously –consistent with the transmitting low bit rate to achieve good power control Uses ROHC framework and RTP profile packets for full headers (IR and IR-DYN) –Defines a new ROHC profile Defines a short update packet Relies on cdma system time to synchronize

7 Internet Drafts draft-hiller-rohc-gehco-01.txt draft-mccann-rohc-gehcoarch-01.txt

8 Intuitive Idea

9 Reverse Direction Synchronization

10 Forward Direction Synchronization

11 Loss of Synchronization Issues GEHCO relies on underlying timing to increment time stamps and sequence numbers Disruption of underlying timing –Occurs after a hard handoff or when the RAN buffer over/under runs (forward direction) –Air frames now correspond to different RTP seq_no and time stamp than a simple increment Disruption Visibility –PDSN can not see fwd direction buffer under/over run –TE (with relay mode MT) can not see hard handoff –Neither know a synchronization problem exists –Proposal on next page

12 Re-synchronization Solution RAN is aware of buffering and hard handoff Proposal: –RAN sends an “RP feedback packet” to PDSN –PDSN sends IR-DYN or UPDATE to MN RAN RP feedback carries “air frame to GRE seq_no” association (just like initial synchronization) –MN responds with feedback packet (an ack) –MN sends a similar IR-DYN or update packet –PDSN responds with a feedback Other: The MT signals the TE of sync events but this does not help RAN buffer over/under run

13 Forward Direction Profile Issue Unidirectional RTP packet Internet to MN –Should the PDSN use ROHC or zero byte overhead RTP ROHC profile? –If zero byte overhead profile, then which RP connection should be used? Solution –Define reverse flow header –Provides the PDSN with the header of packets for which zero byte overhead profile should be used –Provides the connection ID (SR_ID) of the circuit voice service instance –The PDSN sees such packets; sends an IR to the MN

14 State Machine

15

16

17

18

19 Discussions and Alternatives New service option “X” ----  Raw evrc as primary traffic on a walsh code, secondary traffic with overhead runs at same time on same walsh code.  The RAN and the MN may map data to either primary or secondary  Using "mux PDU" both may be sent at same 20ms frame, so long as neither are a full frame. Up to 168 bits are possible for the secondary. Do not have 171 on the secondary.  We blank codec data when there is a full rate frame  This allows synchronous updates using ROHC packets without payloads (i.e. the evrc is on the primary and the updates are on the secondary_

20 Mux PDU - Transparency  Transparency after hard handoff or RAN buffer overflow or underflow  MN and PDSN do not know that a RAN lost a evrc in a buffer or not transmitted due to lack of radio channel  RAN may know how many are lost/gained -- could tell the PDSN  There will be a delay in any event such that the PDSN and MN do not they have lost transparency  Verifications are periodic so there is a delay (and they eat spectrum unnecessarily)  Feedback has delay but doesn't waste spectrum unnecessarily Either case there is no way to discard packets from being received that are not transparent (and often there is no reason to do so)

21 Bang for buck How much extra transparency does MuxPDU buy us? –Delay MuxPDU approach: The delay for the RAN to tell the PDSN that an update is needed plus the update to be sent via MuxPDU Action time approach: The delay for the RAN to tell the PDSN that an update is needed plus the update to be sent on PPP –Fields that change rapidly Which ones? Lucent is open minded about muxPDU approach -- this should be studied

22 Summary Two updated Internet Drafts to be presented next week in ROHC WG on GEHCO –Provides transparency once update is received –Uses ROHC framework-level and packet formats; defined an update but existing updates may be more appropriate; GEHCO-T needs an offset –Proposes mechanism to indicate ROHC vs GEHCO-T for each RTP packet –Uses only the PPP link for updates Alternative –Mux PDU approach