1 transparent gehco slides for p00-20010312-006__luc_gehco-t lucent technologies tom hiller pete...

1

Transparent GEHCO Slides for

p00-20010312-006__luc_gehco-t

Lucent TechnologiesTom 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

M obile Station

IPNetw ork

PDSNRN

M N sends a fu ll header to the PD SN ; the PD SN acks the fu ll header PD SN sends a fu ll header to the M N ; the M N acks the fu ll header Full header is based on R FC 2508; G EH C O has its ow n protocol ID so

thatheaders for G EH C O are d is tinguishable G EH C O fu ll header inc ludes a c ircu it id so the decom pressor can identify

SR _ID that carries the c ircu it vo ice and an optional IP -ID if thecom pressor w ishes the decom pressor to use a reserved range

G EH C O com pression negotia tion occurs during IPC P per R FC 2509, justlike it w ould be for R FC 2508

C hanges in s tatic header in form ation results in a new fu ll header beingsent by the com pressor to the decom pressor

Ack

Full Header

Ack

Full Header

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

RN

IPNetw ork

PDSN

Pretend that the M N connects v ia a G R E tunnel to the PD SN The M N te lls the PD SN that som e R P G R E sequence num ber is

associated w ith a som e R TP tim estam p and sequence num ber The M N te lls the PD SN that som e R P G R E sequence num ber is

associated w ith a som e R TP tim estam p and sequence num ber The M N and PD SN can then determ ine fu ture tim estam ps and sequence

num bers from received G R E sequence num ber This w ill w ork unless/until the 20m s tim ing is d isrupted Transparent G EH C O then re lies on the R AN to help b ind the num ber of

20m s a ir fram es from action tim e in term s of the G R E sequence num bers This a llow s the PD SN to th ink in term s of G R E and the M N in term s of a ir

fram e counts

X M N

9

Reverse Direction Synchronization

M obile Station

IPNetw ork

PDSNRN

R N te lls M N cdm a system tim e to begin to transm it on the a ir channel The M N and R N from that po int go ing forw ard count 20m s in terva ls The R N num bers R P G R E seq_nos starting at one such that one

m atches the firs t a irfram e The M N sends an IR , IR -D YN , or Feedback packet over PPP to the

PD SN that has an offset that is the num ber of 20m s in terva ls s inceaction tim e

The offset ind icates the tim e at w hich the g iven header in form ation isva lid . This w ill correspond to the G R E seq_no from the R N that conta insan evrc sam ple w hich should have the g iven header (i.e . R TP tim e stam pand seq_no)

Action tim e

Send codec sam plesRP packets,GRE=air fram e count

IR , IR-DN, Feedback w/ offset

Ack

10

Forward Direction Synchronization

M obile Station

IPNetw ork

PDSNRN

R N te lls M N cdm a system tim e to begin to transm it on the a ir channel.The R N also starts sending fram es

The M N and R N from that po int go ing forw ard count 20m s in terva ls The PD SN starts to send R P packets w ith evrc The R AN sends a feedback R P packet to the PD SN that specifies an a ir

fram e num ber (20m s in terva l) s ince action tim e that coresponds to aG R E seq_no the PD SN sent: "G R E packet N sent on 20m s num ber M "

PD SN sends IR , IR -D YN , or feedback w ith header and an offset (num berof 20m s in terva ls) from action tim e that the header applies

The M N then know s a g iven a ir fram e has the particu lar R TP seq_no andtim estam p. The M N then increm ents from then on

Action tim e

Send codec sam plesRP packets,GRE=som e num ber, e.g. 0

RAN sends RP m esage: G RE equals som eforward air fram e count relative to action tim e

IR, IR-DYN, Feedback

ack

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

IR +------->------------>------------>----------+ | | | | | | | | | | | | | | Context v +-----------+ +-----------+ Update +-----------+ |IR State | |FO State | -------> |SO State | +-----------+ +-----------+ +-----------+ ^ | | | | | | IR-DYN | +----------------------+

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

1 transparent gehco slides for p00-20010312-006__luc_gehco-t lucent technologies tom hiller pete...

Documents

byte overhead rtp rohc

pdsn use rohc

rtp profile packets

rohc frameworkfullheader

rohc compression

rtp time stamp

zero byte overhead profile

update packetpdsn