1. VoIP CPE without DSPs Rick Bye Director of Marketing D2 Technologies, Inc. rbye@d2tech.com www.d2tech.com rbye@d2tech.com www.d2tech.com

2. 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

3. 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

4. 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.

5. 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

6. New SW/HW Architecture: Single CPU

7. 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

8. Information Flow in VoIP

9. 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

10. 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.

11. 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.

12. 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

13. 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.

14. 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.

15. 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

16. 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.

17. 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.

18. 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.

19. Toolchain / BSP Considerations: Optimizing Compiler

20. Toolchain / BSP Considerations: Peripheral Drivers  Peripheral drivers (Ethernet, Serial, USB, etc) may have a hard real-time impact on Voice software:  Peripheral ISR’s 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 ISR’s.

21. 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.

22. Conclusion  Single-core, RISC SoC’s 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.

23. Thank You Rick Bye Director of Marketing D2 Technologies, Inc. rbye@d2tech.com