VoIP CPE without DSPs Rick Bye Director of Marketing D2 Technologies, Inc

Embed Size (px)

DESCRIPTION

VoIP Endpoint Example: Analog Telephony Adaptor (ATA)  Ethernet to FXS adaptor  Optional second Ethernet port for bridging/routing; FXO for PSTN  Enables an analog POTS phone to make VoIP calls  May support FAX  SIP User Agent application  Uses SIP protocol to establish calls  Implements many CLASS features  Call Waiting, Caller ID, 3-way Calling, Call Transfer, Call Forwarding, etc

Citation preview

VoIP CPE without DSPs Rick Bye Director of Marketing D2 Technologies, Inc. VoIP CPE Without DSPs: Agenda VoIP Endpoint Device Software Overview VoIP Endpoint Example, Functionality, Software Blocks Traditional Software Architecture (RISC + DSP) New Software Architecture VoIP on RISC Real-time requirements in VoIP Hard Real-Time, Soft Real-Time, Best Effort Toolchain/BSP Considerations Software Design Considerations Conclusions VoIP Endpoint Example: Analog Telephony Adaptor (ATA) Ethernet to FXS adaptor Optional second Ethernet port for bridging/routing; FXO for PSTN Enables an analog POTS phone to make VoIP calls May support FAX SIP User Agent application Uses SIP protocol to establish calls Implements many CLASS features Call Waiting, Caller ID, 3-way Calling, Call Transfer, Call Forwarding, etc Other Endpoint examples Router with VoIP WiFi Router with VoIP Cordless/DECT ATA WiFi handset Dual mode phones VoIP enabled PDAs, Game Units, MP3 players Etc etc. Legacy HW/SW Architecture: RISC + DSP RISC Processor Responsible for: Voice Application, Protocol IP Stack, Data/Voice Packets DSP Driver DSP Processor Responsible for: Hard real-time telephony interface DSP algorithms (MHz intensive) Separate DSP application Required to be semi-autonomous New SW/HW Architecture: Single CPU Single CPU Advantages / Challenges Advantages: Eliminates DSP lowering overall cost Leverages existing chips No Interprocessor communication Single Tools / Development Environment Challenges: Hard real-time requirements MHz burden on RISC Data/Voice/Application software must co-exist Information Flow in VoIP Hard Real-Time in VoIP Hard Real-Time definition Deadline-based processes in which a failure to meet the deadline will result in loss of voice data and unacceptable system behavior. Hard real-time requirements in VoIP: Telephony Driver DSP Algorithms Hard Real-Time Requirement: Telephony Driver Telephony Driver: Transmits voice samples to/from the hardware codec Synchronous serial interface, 64_kbps per channel 8000 samples/s, 8 bits/sample One sample transmitted/received every 125 us Failing to copy a sample before the 125us deadline will result in a dropped voice sample Resulting impacts on voice quality Can be a noticeable click. Echo canceller can fail, resulting in perceptible echo to far end. FAX pass-through or FAX Relay can fail. Causes drift in jitter buffers, which will cause dropped packets if If subsequent deadlines are missed (domino effect), call failure and system instability can result. Hard Real-Time Requirement: DSP Algorithms DSP Algorithms process the voice stream from the Telephony Driver and from the IP stack to do: Voice Compression Echo Cancellation Tone Generation / Detection DTMF, FAX/Modem, Call Progress, Caller ID Packet Loss Compensation Nature of communication: Block based processing Typically 80 voice samples per block One block processed every 10 ms Failure to complete DSP algorithm processing by the end of the 10 ms deadline results in: Telephony driver will play out old data to hardware CODEC. Far side also gets bad data due to loss of codec data. Echo canceller can diverge, causing echo to be heard on subsequent blocks. Tone detection can fail, resulting in mis-detection of DTMF digits or FAX tones. Again, if subsequent deadlines are missed (domino effect), call failure and system instability can result. Soft Real-Time in VoIP Soft Real-Time definition: Processes which should execute in a timely manner, for which system behavior degrades (but may not be unacceptable) if the deadline is missed. Soft real-time requirements in VoIP: Voice Packetization and Transport Voice Application and Protocol Soft Real-Time Requirement: Voice Packetization and Transport Voice packetization and transport: Packetize the compressed audio and send it out the IP interface; alternatively, receive a packet from the IP interface and provide it to the VoIP software. Nature of communication: Transmission: Normally, one packet ready every 10, 20, or 30 ms. Reception: Subject to network jitter, one every 10, 20, or 30 ms. Deadline for processing: Processing should complete within the packet duration (10, 20, 30 ms), in order to keep from getting behind. Repercussions of failure to meet deadline: May be handled by the Jitter Buffer on the receiving side. Best-case Missing deadline causes jitter buffer to grow, but does not cause lost packets; Results in increased latency because of a larger jitter buffer. Worst-case Missing deadline causes jitter buffer to discard a too-late packet; Packet loss compensation used to minimize impact on voice quality. Soft Real-Time Requirement: Voice Application and Protocol Nature of communication: Responds to reception of SIP packets, telephony events, and internal timers in order to drive Telephony Application functionality. Deadline for processing: Processing should be responsive enough for successful user experience. Certain time-outs exist in SIP; however, retransmission techniques in the protocol allow recovery of some missed deadlines. Repercussions of failure to meeting deadline: Noticeable lack of responsiveness of device. Call failures are possible for excessive delays. However, voice application and protocol deadlines are typically on the order of hundreds of milliseconds to several seconds. As long as the Voice Application and Protocol are not blocked indefinitely, they should meet timing requirements. Best Effort in VoIP Best Effort definition: Processes for which there is no deadline, but for which faster execution results in better system performance. Best Effort requirements in VoIP: Data IP Packet Transport Best Effort Requirement: Data Packet IP transport Data Packet IP transport: Process the reception, transmission, forwarding, and bridging of TCP packets. Nature of communication: Packets can be received at wireline speeds (e.g. 100 Mbps). Device processes as many packets as it can, discarding others. Deadline for processing: No deadline for processing, other than TCP ACK timeout. Repercussions of failure to meeting deadline: TCP packets retransmitted. Lower data bandwidth. These repercussions are intentional and acceptable. Implications of Real-time Requirements A VoIP device has multiple processes with different MHz consumption and real-time needs. This places stringent requirements on the OS, BSP, Memory, Cache, other software running on the RISC core, and the SoC design itself. Each of these areas needs careful consideration. This requires a system-wide approach rather than ad-hoc optimization of each piece. Toolchain / BSP Considerations: RTOS OS requirements: Guaranteed worst-case task switch latency that meets the VoIP latency deadlines. A preemptive kernel. A scheduler that prioritizes real-time tasks above non real-time tasks. Examples: Wind River VxWorks MontaVista Linux (contains real-time improvements in the 2.6 Linux kernel) Others (Nucleus, SuperTask, eCOS) Final OS choice involves cost tradeoffs: License/royalty cost Flash / Memory footprint. Strong Tools Development Environment. Bundled network/application software can lower development costs. Toolchain / BSP Considerations: Optimizing Compiler Toolchain / BSP Considerations: Peripheral Drivers Peripheral drivers (Ethernet, Serial, USB, etc) may have a hard real-time impact on Voice software: Peripheral ISRs can hold off tasks past deadlines. To avoid this, peripheral drivers may have to be modified to: Separate the time critical portions of the driver from portions that can be run at lower priority. Minimize the task latency imposed on real-time VoIP processes due to ISRs. Software Design Considerations VoIP Software Partitioning VoIP software should be partitioned into different tasks based on priority, not function. This minimizes the MHz consumed in hard real-time tasks This decreases negative effects due to the latency it imposes on other tasks. Task Priority Organization Care has to be taken to make the optimal priority assignments for each task. Sub-optimal assignment of task priorities can easily result in 40% higher MHz load due to the creation of unnecessary task switching. Conclusion Single-core, RISC SoCs are the new approach for low-cost VoIP endpoints. Combining Voice, Data, and Application Software has challenges. A strong systems-level approach is required to conquer the challenges. Thank You Rick Bye Director of Marketing D2 Technologies, Inc.