VoIP Overview 032105

March 2005 VoIP Overview
QUALCOMM PROPRIETARY DO NOT DISTRIBUTE
VoIP on 1xEV-DO rev. A

QUALCOMM, March 2005
Page 1
Agenda
Executive Summary Telco-Quality VoIP Requirements Network Architecture for VoIP over EV-DO rev A Voice over Wireless IP: performance enhancing features Capacity Simulation Results
Page 2
Executive Summary
VoIP capacity of 48 users per sector can be achieved on EV-DO rev A with dual-diversity handsets Capacity is comparable to 1x circuit-switched voice capacity if similar assumptions were made (e.g. 3GPP2 evaluation framework, smart blanking, MSO model, etc) Additional capacity gains can be achieved by introducing interference cancellation techniques. In this case, DO rev A can support up to 58 users per sector The VoIP over DO rev A system is reverse link limited, leaving a significant amount of unused forward link capacity. This free capacity can be used for forward link centric applications such as Gold or Platinum multicast. In order to successfully implement VoIP over DO rev A, some standards need to be revised and the corresponding features implemented. E.g. IS835-D, IS-878-A and TIA-1054
Page 3
Wireless VoIP Requirements

VoIP calls must have at least similar quality as circuit-switched voice calls
End-to-end delays for mobile-to-land and mobile-to-mobile calls should be similar to existing networks (e.g. 280 msec) Frame error rate should be controlled to no more than 2% Voice quality degradation should be minimal during handoffs
Need to support existing vocoders and possibly new enhanced ones Capacity of the wireless VoIP system must be comparable or better than existing wireless circuit-switched systems Backend solutions need to be in place to support equivalent functions as in todays systems
Authorization, Accounting, Roaming, etc
VoIP implementation should allow for the development of new integrated media services in addition to existing voice services
Page 4
Network Architecture and Protocols
Page 5
Wireless VoIP Network Elements

1. 1xEV-DO rev A RAN
Provides delay-sensitive QoS support and admission control Provides QoS reservation and activation based on enhanced multi-flow packet application (EMFPA) protocol Supports IS-835-D, IS-878-A and RoHC
2. SIP-based VoIP core elements

Registration, call setup and control Gateway for PSTN calls Codec transcoding
SIP Registrar
Location Server
PSTN
SS7
SIP Proxy
MGW
3. EV-DO rev A devices

VoIP application SIP support
R-P Interface
Internet PDSN
Edge Router QoS Domain
Page 6
VoIP App
BSC EV-DO Rev A BTS
A12
AAA
Required RAN Features for VoIP

1. PDSN sends IP packets to BSC without PPP encapsulation
Eliminates PPP overhead and allows for efficient air interface header compression Improves packet dropping efficiency and allows for seamless make-before-break handoffs between RANs One A10 between PDSN and RAN carrying PPP traffic for control functions One or more A10s between the PDSN and RAN carrying IP traffic for different QoS flows New service option introduced allowing the PDSN to send IP packets to the RAN IS-835-D in ballot resolution, Expected publication: 1Q 2005
QoS 1 IP IP Flow Flow Header / Payload Compression QoS 2 QoS 3
IP Flow
IP Flow
IP Flow
IP Flow
IP Flow
PPP in HDLC - like Framing CDMA Flow CDMA Flow ROHC Channel CDMA Flow ROHC Channel CDMA Flow ROHC Channel CDMA Flow RAN
Existing architecture
Proposed architecture
PDSN
IP Flow
Page 7
Why Air Interface Header Compression?

First, header compression needed to reduce RTP/UDP/IP header overhead of voice frames
RTP Header: 12 bytes UDP Header: 8 bytes IP Header: 20 bytes (IPv4) or 40 bytes (IPv6) Full rate frame size is only 22 bytes. Overhead even more dominant for 1/2 and 1/4 rates
Alternatively, frame bundling could lower overhead but leads to increased delays and burst error rates A robust and efficient header compression scheme requires state full operation with error recovery and acknowledgement mechanisms RAN based RoHC allows for efficient implementation
Compression algorithm can take advantage of air interface error and timing recovery Packet dropping based on air interface information done prior to header compression Simplified connected-state BSC-BSC handoff with two independents ROHC contexts
Page 8
Header Compression System View (mobile to mobile)

Uplink Header Decompressor
RAN
Core VoIP Network
Downlink Header Compressor

RAN
RL
Typical RoHC header sizes with timer-based compression mode

2 or 4 bytes on IPv4 (UDP checksum enabled or disabled) 4 bytes on IPv6 (UDP checksum must be enabled)
FL
AT_1
AT_2
Uplink Header Compressor
Downlink Header Decompressor
Page 9
Required RAN Features for VoIP (contd)

2. QoS configuration and activation using the Enhanced Multi-Flow Packet Application (EMFPA) Protocol
Streamlined process to minimize setup delays while consuming no resources until activation TIA-1054 published in January 2005. Requires appropriate QoS support in IS-835-D, IS-878-A and IS-1878-A.
Configuration
After session and PPP establishment upon power-up, VoIP application (AT) sends reservation request to setup the appropriate QoS After authorization, AN initiates QoS configuration Upon successful configuration, AT instantiates the required IP filters at the PDSN
Filters are classifiers based on source/destination IP addresses, Port numbers, etc.
Page 10
Registration / QoS Configuration

AT Power up Session establishment App starts RAN PDSN AAA SIP Reg
PPP carrying A10 setup and Sub QoS Profile
Authentication and Sub QoS Profile
RAN performs authorization by checking requested ProfileIDs wrt subscriber QoS profile downloaded from AAA
Could be Part of Session Establishme nt, repeated for each codec
EMFPA: AttributeUpdateRequest (ReservationKKQoSRequest for audio, control) Authorization wrt Sub QoS Profile EMFPA: AttributeUpdateAccept EMFPA: AttributeUpdateRequest (ReservationKKQoSResponse) EMFPA: AttributeUpdateAccept EMFPA: AttributeUpdateRequest (Link Flow Configuration) EMFPA: AttributeUpdateAccept RTCMAC SubType 3: AttributeUpdateRequest (MAC Configuration) RTCMAC SubType 3: AttributeUpdateAccept Set up A10s for carrying control, media traffic
FL IP filters sent to PDSN. ReservationLabel binds to A10 and RLP flow
Resv (TFT) ResvConfirm
SIP Registration
VoIP app ready to place or receive calls
Access to QoS for VoIP calls can be restricted to authorized subscribers and valid applications
Page 11
VoIP Call Setup

QoS activation using EMFPA Protocol (TIA-1054)
AT requests the audio flow to be activated by sending a ReservationOnRequest Control flows (SIP signaling) may be activated by default since they consume minimal resources AN performs admission control by checking BS available resources If successful, AN configures FL scheduler resources and RTCMAC resources if not already done AN sends ReservationAccept to AT. SIP call setup starts.
SIP signaling used to setup and tear down VoIP calls

SIP compression may be used to reduce amount of signaling overhead and reduce latency
RAN sends GrantedQoS indication to PDSN upon allocation and deallocation of resources to a VoIP call
Can be used to generate AAA records allowing for time-based billing If one A10 is dedicated to a VoIP flow, byte accounting may also be generated as per IS-835-D
Page 12
Call Setup (same QoSProfileID at the end points)

AT1 Call Initated RAN PDSN SIP Proxy PDSN RAN AT2 RUP: ConnectionRequest EMFPA: ReservationOnRequest (Default Codec) Connection Setup Admission Control EMFPA: ReservationAccept Granted QoS SIP: Invite (Codec List) Connection Setup SIP: Invite (Codec List) SIP: 100 Trying EMFPA: ReservationOnRequest (Default Codec) Admission Control Granted QoS EMFPA: ReservationAccept
SIP: Invite (Codec List) Call Setup Delay SIP: 100 Trying
SIP: 180 Ringing SIP: 180 Ringing SIP: PRACK SIP: PRACK User Picks SIP: 200 OK SIP: ACK Media Traffic SIP: 200 OK Ring User
Call Setup Time = 2 * Conn Setup + RTD + QoS Activation
Page 13
Voice over Wireless IP:

Speech quality enhancing techniques
Page 14
Speech Basics: Talk spurts and silence intervals
Silence intervals are produced when the user goes silence and the speech vocoder uses only 1/8 rate frames for communication of the background noise
Talk spurts are produced when the user is speaking and the vocoder uses frames different than 1/8 rate frame for communication of the speech
In a packet-switched network capacity can be improved by reducing the amount of frames used for background noise information
Page 15
Mouth-to-Ear Delay (ITU-T G.114)
285ms
Maximum acceptable end-to-end delay of 285ms for user satisfaction Commercial 3G 1x networks have 260-270ms delay Packet-switched networks allow for capacity-delay tradeoff optimization
Page 16
Voice Frame Delay Jitter

The decoder ideally receives and plays one voice frame every 20ms However, the voice frame inter-arrival time is not constant. The variance in the inter-arrival time is know as delay jitter. A de-jitter buffer is needed to allow evenly delivery of voice frames to decoder
400
Sources of jitter in a 1xEV-DO network

Reverse link MAC Forward link scheduler RF channel conditions Handoff Core network
Voice Frame Delay (ms)
350
Different jitter, Different End2End Delay Same jitter, Different End2End Delay
300
250
200
150
End2end Packet Delay

100
Running Average (20)

50
MAX Delay (20)

MIN Delay (20)
0 1 101 201 301 401 501 601 701 801 901 1001 1101
Frame Count
Page 17
Voice Quality Enhancing Features of VoIP over EV-DO
Decoder Time Warping
Smart Noise
De-jitter Buffer Lower Layers Smart Blanking
Smart blanking Smart background noise Adaptive de-jitter buffer Speech time warping Enhanced error concealment
Lower Layers Smart Blanking De-jitter Buffer Smart Noise Encoder
1xEV-DO Rev A
Decoder Time Warping
Encoder
Page 18
Smart Blanking / Background Noise

Current vocoders introduce unnecessary overhead by using a sequence of 1/8 rate frames for background noise information during silence periods
Even with RoHC, IP Packet overhead is twice the size of the payload
A single prototype 1/8 rate frame can be repeatedly played back if it has similar statistical properties as the background noise Transmitter (Smart Blanking)
Transmits the first 1/8 rate frame after the end of a talk spurt the prototype frame If background noise changes significantly during silence, sends a new 1/8 rate prototype frame
Receiver (Smart Background Noise)

Transitions to Silence state when a 1/8 rate frame is received (or time out). When in silence state, playback prototype 1/8 rate frame If a 1/8 rate frame is received during silence state, update prototype 1/8 rate frame To avoid flatness of reconstructed background noise, erasures are puncture with some probability
Page 19
Prototype 1/8 Rate Frame Update

Sometimes, first 1/8 frames during silence interval are not representative of background noise
Example: Noise from a rack of computers Beginning of several silence periods shown
50
Frame energy delta with respect to average, dB
40 30 20 10 0 -10 -20 1 2 3 4
Few first frames do not represent the average background noise
10
Frame number
Updates triggered by noise energy change Updates triggered by noise frequency content change Adaptive update algorithms optimize tradeoff between 1/8 rate overhead and noise quality reconstruction
Page 20
Speech Samples
Harvard sentences with background noise generated by an electric motor
Original recording EVRC (Silence periods only) Sending one 1/8 rate frame (Silence periods only) Smart Blanking (Silence periods only)
Counting with background noise generated by a Rack of computers

Original recording EVRC Sending one 1/8 rate frame Smart Blanking
Page 21
Adaptive De-jitter Buffer

The de-jitter buffer is an adaptive buffer that restores constant inter-packet timing prior to decoding The required amount of buffer changes dynamically for each talkspurt. It represents a tradeoff between additional end-to-end delay and frame erasure rate
Traditional de-jitter/decoder implementation
In-order delivery not guaranteed Even delivery of voice frames 20ms of voice per frame
20ms
De-jitter buffer
Variable Inter-arrival times
Decoder
20ms
If there are too many frames in the buffer, end-toend delay is increased If there are no frames in the buffer, an erasure has to be fed to the decoder
Page 22
Adaptive De-jitter Buffer with Time Warping Operation

Time Warping adjusts the playback duration of a speech segment without changing its pitch Time expansion or compression allows the de-jitter buffer size change during a talk spurt Use of Speech Time Warping greatly enhances the system ability to track variable delay and jitter, reducing the overall latency of the de-jitter operation for same target PER
De-jitter/decoder/time warping implementation
In-order delivery not guaranteed Un-even delivery of voice frames 10-35ms of voice per frame (when required)
20ms
Variable Inter-arrival times
De-jitter buffer
Decoder & TW
20ms
If there are too many frames in the buffer, playback time reduces If there are few frames in the buffer, playback time increases
Page 23
Time Warping Operation

In order to preserve pitch during time-warping, long-term similarities of the human speech must be found among samples Maximum auto-correlation algorithm determines a set of suitable samples to execute time warping
1 pitch
Small speech segments are merged to achieve compression or repeated to achieve expansion
Page 24
Additional Features of De-jitter Buffer/Time Warping

Playback time of buffered frames can be expanded prior to certain known periods of air-link unavailability
Forward link handoffs Reverse link silence periods
Reduction of conversational roundtrip delay (RTD)

The perceived RTD is defined by the delay segment of the first and last packet of speech segments Conversational RTD First packets in a talkspurt can be timeexpanded when played back No need to wait until de-jitter buffer fills up with the target number of frames Last packets in a talkspurt can be timecompressed when played back
Speech
User1
User2 One way delay
Conversational RTD
Page 25
Enhanced Erasure Concealment

Vocoders designed for circuit-switched networks perform extrapolation of erased packets purely based on the last packet For packet-switched networks, where a de-jitter buffer is present, future packets may be available for improved voice quality
Circuit
Good
Erasure
Good
VoIP Playback Time line
Simulations show that future frame is available for enhanced concealment approximately 40% of the time A good portion of the lost information can be linearly interpolated with increased accuracy
Pitch estimation Minimal dampening or fading of the speech during erasure concealment can be achieved
Page 26
Capacity Simulation Results
Page 27
Simulation Framework
QUALCOMM developed a complete network simulation model representing 19 cells / 57 sectors The model follows the 3GPP2 Simulation Strawman with minor modifications to closely match practical implementations All EV-DO rev A terminals are assumed to have dual receive diversity
Voice frames are simulated from source to destination including all possible impairments Capacity is determined based on collected statistics: mouth-to-ear delay, frame error rate (FER), rise-over-thermal (ROT), etc.
Page 28
Model Assumptions
Source traffic is modeled based on MSO model IS-871.
Full rate: 29%, rate: 4%, rate: 7%, 1/8 rate: 6%, Blanked: 54%
There is exactly one vocoder frame per IP packet (no bundling) Packet overheads:
4 bytes of RTP/UDP/IP overhead is assumed with RoHC 2 bytes of RLP and Stream layers 4 bytes of MAC trail, FCS and tail bits
Constant delay components:

Delay component Vocoder (alg., proc.) Packet Processing (turbo encod, demod, decod, MAC) RAN (BTS-PDSN) Core IP Network or PSTN * Voice frame decoding (not including de-jitter/time warper) TOTAL Circuit-to-DO or DO-to-Circuit** 35ms 5ms 10ms 15ms 3ms 68ms DO to DO 35ms 10ms 20ms 15ms 3ms 83ms
* Additional propogation delay can be added as 0.005ms/km for long distance calls [TIA/EIA TSB116] ** Additional delay is assumed for circuit network depending on characteristics (e.g., 1xRTT to DO)
Page 29
VoIP Capacity of 1xEV-DO rev A

System capacity of 48 VoIP users per sector can be achieved given maximum reverse link load criterion
Reverse link ROT should not exceed 7dB by more than 1% of time Approximately 89 MAC channels are allocated per sector
Similar capacity figure could be achieved by 1xRTT circuit-switched voice if dual diversity handsets and smart blanking were employed
Page 30
Mouth-to-Ear Delay Statistics (mobile to mobile)

Average end to end delay is approximately 100ms lower than in existing 1xRTT deployments Even at capacity, 99% of packet delays are better than typical circuit-switched delay
* 3G1x delay values are based on field measurements from commercial 1xRTT networks commercial
Page 31
Mouth-to-Ear Delay Statistics (2)

Land to DO
End-to-end delays of land to DO calls are within ITUs Very Satisfied rank (<200ms) Additional delays if calling party is 1x handset
Similar to GSM to 1xRTT case
1xRTT to DO wt. tandem (+133ms)
1xRTT to DO w/o Tandem (+95ms) DO to Land
DO to 1xRTT wt. tandem (+133ms)
DO to 1xRTT w/o Tandem (+95ms)
Note DO to land delays are not affected by sector load

Reverse link load (RoT) and not delays are affected by increasing number of users
Page 32
Capacity Enhancements: Pilot Interference Cancellation

A significant portion of reverse link interference is due to Pilot signal transmissions when a large number of VoIP users are present Hence VoIP capacity can be improved by removing this pilot interference at the base station System capacity of 58 VoIP users per sector can be achieved for 1%@7dB RoT
Approximately 100 MAC channels are allocated per sector
PIC increases VoIP capacity by 20%
QUALCOMM is offering Pilot Interference Cancellation (PIC) as an optional FPGA feature supported by the CSM6800 solution
Page 33
Mouth-to-Ear Delay Statistics with PIC
Page 34
Summary of VoIP Capacity over EV-DO Rev. A
1xEV-DO rev A with dual-antenna handsets provides a competitive alternative for wireless VoIP services
Page 35
Mixed VoIP and Platinum Multicast

Platinum Channel at 187kbps 1/8 interlace Platinum Channel at 328kbps 1/4 interlace (minus control channel)
Excess Forward Link Capacity Allows Operators to Introduce Multicast with Minimal End-to-End Delay Impact
Page 36
Mixed VoIP and Platinum Multicast (2)
Even at Voice Capacity, 95 Percentile End-to-End Delays is Below 300ms Additional Multicast Channel Capacity Can Be Available During Non Busy Hours Every DO rev A Carrier Used for VoIP Can Provide Free Multicast Capacity
Page 37
Future Simulation Work

Evaluate capacity vs. delay tradeoffs for the following scenarios
Mixed VoIP and Best Effort users Mixed VoIP, BE and Multicast
New update in 4-6 weeks
Page 38
Thank You!
Page 39
Backup Slides
Page 40
Reverse Link Modeling

Reverse Link is operated in a manner optimized for voice service
12-slot termination mode (i.e., 1% PER target after 3 sub-packets) For VoIP flow, each IP packet is sent in one MAC packet when power headroom allows (max AT TX power is 23dBm). MAC layer does not limit data rate No retransmission of failed packets (RLP disabled) DRC length of 8 slots, independent of handoff state
The AT does not drop any packets due to delay Overhead and Feedback Channels
Pilot, DRC, DSC, RRI, ACK, overheads are modeled RAB, RPC, H-ARQ channel performance also modeled
Parameters:
-6dB DRC-to-pilot -9dB / -15dB DSC-to-pilot (sho / no sho) -6dB RRI-to-pilot ACK channel load on RL is modeled as constant load
Page 41
Forward Link Modeling

Each IP packet gets a timestamp at the access network (AN) and scheduled on FL Multi-user (MU) scheduler minimizes packet delay while increasing link utilization
Uses both single-user and multi-user packets as appropriate Multi-user packets can carry data for up to 8 different users Uses the packet arrival timestamp (no knowledge of prior traffic delay)
MU scheduler may drop some packets that have experienced excessive delay (e.g., 200ms) at the FL transmission queue No retransmission of failed packets (RLP disabled) H-ARQ and D-ARQ* are modeled The DRC and ACK channels are modeled
DRC and ACK errors and erasures are taken into account DRC erasure mapping algorithm is implemented
76.8kbps Control Channel and other packet overheads are modeled
Page 42
Simulation Configurations (mobile to mobile)

DO to DO DO AT Encoder DO RAN Core IP Ntwk. DO RAN DO AT De-jitter
Circuit to DO (e.g., 1xRTT to DO) Circuit Phone Circuit RAN PSTN* DO RAN DO AT De-jitter
DO to Circuit (e.g., DO to 1xRTT) DO AT Encoder DO RAN De-jitter PSTN* Circuit RAN Circuit Phone
* PSTN and tandem encoding may not be required if both circuit and VoIP networks use same vocoder (e.g., EVRC).
Page 43
Simulation Configurations (land to/from mobile)

Circuit to DO (e.g., POTS to DO) Circuit Phone DO to Circuit (e.g., DO to POTS) DO AT Encoder DO RAN De-jitter PSTN Circuit Phone PSTN DO RAN DO AT De-jitter
Land VoIP to DO (e.g., PC client to DO) Land VoIP Phone DO to Land VoIP (e.g., DO to PC client) DO AT Encoder DO RAN Core IP Ntwk. Land VoIP Phone De-Jitter Core IP Ntwk. DO RAN DO AT De-jitter
Page 44

VoIP Overview 032105

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

VoIP Overview 032105

Transféré par

Droits d'auteur :

Formats disponibles

March 2005 VoIP Overview

QUALCOMM PROPRIETARY DO NOT DISTRIBUTE

VoIP on 1xEV-DO rev. A

March 2005 VoIP Overview

QUALCOMM PROPRIETARY DO NOT DISTRIBUTE

March 2005 VoIP Overview

QUALCOMM PROPRIETARY DO NOT DISTRIBUTE

March 2005 VoIP Overview

QUALCOMM PROPRIETARY DO NOT DISTRIBUTE

Wireless VoIP Requirements

March 2005 VoIP Overview

QUALCOMM PROPRIETARY DO NOT DISTRIBUTE

Network Architecture and Protocols

March 2005 VoIP Overview

QUALCOMM PROPRIETARY DO NOT DISTRIBUTE

Wireless VoIP Network Elements

2. SIP-based VoIP core elements

3. EV-DO rev A devices

BSC EV-DO Rev A BTS

March 2005 VoIP Overview

QUALCOMM PROPRIETARY DO NOT DISTRIBUTE

Required RAN Features for VoIP

March 2005 VoIP Overview

QUALCOMM PROPRIETARY DO NOT DISTRIBUTE

Why Air Interface Header Compression?

March 2005 VoIP Overview

QUALCOMM PROPRIETARY DO NOT DISTRIBUTE

Header Compression System View (mobile to mobile)

Downlink Header Compressor

Typical RoHC header sizes with timer-based compression mode

Uplink Header Compressor

Downlink Header Decompressor

March 2005 VoIP Overview

QUALCOMM PROPRIETARY DO NOT DISTRIBUTE

Required RAN Features for VoIP (contd)

March 2005 VoIP Overview

QUALCOMM PROPRIETARY DO NOT DISTRIBUTE

Registration / QoS Configuration

PPP carrying A10 setup and Sub QoS Profile

Authentication and Sub QoS Profile

FL IP filters sent to PDSN. ReservationLabel binds to A10 and RLP flow

Resv (TFT) ResvConfirm

VoIP app ready to place or receive calls

March 2005 VoIP Overview

QUALCOMM PROPRIETARY DO NOT DISTRIBUTE

VoIP Call Setup

SIP signaling used to setup and tear down VoIP calls

March 2005 VoIP Overview

QUALCOMM PROPRIETARY DO NOT DISTRIBUTE

Call Setup (same QoSProfileID at the end points)

Call Setup Time = 2 * Conn Setup + RTD + QoS Activation

March 2005 VoIP Overview

QUALCOMM PROPRIETARY DO NOT DISTRIBUTE

Voice over Wireless IP:

March 2005 VoIP Overview

QUALCOMM PROPRIETARY DO NOT DISTRIBUTE

Speech Basics: Talk spurts and silence intervals

March 2005 VoIP Overview

QUALCOMM PROPRIETARY DO NOT DISTRIBUTE

Mouth-to-Ear Delay (ITU-T G.114)

March 2005 VoIP Overview

QUALCOMM PROPRIETARY DO NOT DISTRIBUTE

Voice Frame Delay Jitter