Using Voice over IP (VoIP) in Mobile Networks

Early in the last decade, service providers viewed VoIP as a threat to their traditional revenue streams. This has turned out to be true and is made possible by VoIP and the Internet, which is not distance-sensitive with respect to the cost of access. It is clear that VoIP will play an even more prominent role in all telecommunications networks moving forward and will completely replace circuit-switched voice.

VoIP has been around since the mid-1990s. The International Telecommunications Union (ITU) standardized the first signaling protocol for VoIP. The protocol, classified as a conferencing standard, is referred to as H.323.

The Internet Engineering Task Force (IETF) entered the scene in the late 1990s with what became a competing protocol called the Session Initiation Protocol (SIP). In 2003 the IETF released an updated version that fixed many issues with the original protocol. Since that time, SIP has become widespread in supporting the signaling functions for most real-time applications today.

There is one other key ingredient for VoIP that involves the packaging of the bits that make up the real-time voice or video communication. The protocol that accomplishes this is called the Real-time Transport Protocol (RTP). The IETF was also responsible for developing this protocol. Apparently it never seemed necessary to develop another competing protocol to RTP, so this has been the sole standard for media transport from the beginning.

To summarize the protocols, we have these two key ingredients that are used for signaling (SIP) and transport (RTP) of real-time communications over IP packet-based networks.

One thing to bear in mind is that these same protocols are used for voice or video traffic over IP networks, which both represent time-sensitive traffic (from end-to-end ). The biggest difference between voice and video IP traffic is the volume of data, or bits. Obviously, video demands a higher throughput than voice (exactly how much, depends on the resolution of the video and the compression method used). A voice or audio channel is necessary in conjunction with a video stream (i.e., silent video conferencing is not something desired by users).

The key difference between voice and video traffic versus transferring ordinary data files is the necessity to deliver a steady stream of traffic because it is time-sensitive. This is best achieved by allowing time-sensitive traffic to have priority, or right-of-way, over other types of non-time-sensitive data traffic. The term that defines this process is typically called Quality of Service (QoS).

There are three different groups of standards that have evolved over time that represent the majority of mobile cellular communications today.

Referencing back to 2nd generation (digital) mobile cellular networks, there were two key standards that became global standards. First, Global System for Mobile communications (GSM) was developed by the European Telecommunications Standards Institute (ETSI). This has become the most widely deployed mobile cellular voice technology in the world. The other 2nd Generation Standard is called Code Division Multiple Access (CDMA). This standard was initially developed by Qualcomm. An industry trade group was formed to provide an eco system for the cdma-One standard.

At the turn of the millennium, 2nd generation mobile standards began their evolution to 3rd generation standards. The move to 3G mobile networks would take a herculean effort on the part of engineers to accomplish the task. Therefore, regional standards bodies throughout the world formed standards partnerships in order to accomplish the task.

ETSI passed the torch to the 3rd Generation Partnership Project (3GPP), which transformed GSM into a new 3G standard called Universal Mobile Telecommunications System (UMTS) that used, what was at that time, a new air interface called Wideband CDMA, or W-CDMA.

The torch-bearer for the 3G standards development involving cdmaOne is the 3rd Generation Partnership Project 2 (3GPP2). Two 3G standards were created out of this partnership. The first became known as 1x Radio Transmission Technology (RTT) and the second was 1x Evolution Data Optimized (EV-DO). 1x stood for the original CDMA channel size of 1.25 MHz (as opposed to the W-CDMA, which was 5 MHz). The former (1xRTT) supported voice and lower-speed data traffic. The later (1xEV-DO) supported only data but at much higher data rates versus 1xRTT.

Recall that at the beginning of this section three groups of standards were mentioned. The third mobile cellular standard comes from the Institute of Electrical and Electronic Engineers (IEEE). The IEEE has created a whole series of standards involving both Local Area Networks (LANs) and Metropolitan Area Networks (MANs). These IEEE standards are formed under a group called the 802 committee, which was formed in February of 1980.

The standard that evolved into a mobile cellular standard is known as 802.16. A group of interested parties that wanted to promote 802.16 standards was formed, called Worldwide Interoperability for Microwave Access (WiMAX). That is why the 802.16 standards are also known as WiMAX. In 2004, the IEEE combined several standards documents that loosely formed the 802.16 framework into one cohesive standard, called 802.16-2004. This standard provided capability for creating a fixed-point microwave access network that provided broadband wireless connections.

View the original article here

Network Operating System Evolution Juniper Networks Junos OS: Architectural Choices at the Forefront of Networking

This paper discusses the requirements and challenges inherent in the design of a carrier-class network operating system (OS). Key facets of Juniper Networks? Junos? operating system, Juniper's network operating system, are used to illustrate the evolution of OS design and underscore the relationship between functionality and architectural decisions.

The challenge of designing a contemporary network operating system is examined from different angles, including flexibility, ability to power a wide range of platforms, nonstop operation, and parallelism. Architectural challenges, trade-offs and opportunities are identified, as well as some of the best practices in building state-of-the-art network operating systems.

Modern network devices are complex entities composed of both silicon and software. Thus, designing an efficient hardware platform is not, by itself, sufficient to achieve an effective, cost-efficient and operationally tenable product. The control plane plays a critical role in the development of features and in ensuring device usability.

Although progress from the development of faster CPU boards and forwarding planes is visible, structural changes made in software are usually hidden, and while vendor collateral often offers a list of features in a carrier-class package, operational experiences may vary considerably.

Products that have been through several generations of software releases provide the best examples of the difference made by the choice of OS. It is still not uncommon to find routers or switches that started life under older, monolithic software and later migrated to more contemporary designs. The positive effect on stability and operational efficiency is easy to notice and appreciate.

However, migration from one network operating system to another can pose challenges from nonoverlapping feature sets, noncontiguous operational experiences and inconsistent software quality. These potential challenges make it is very desirable to build a control plane that can power the hardware products and features supported in both current and future markets.

Developing a flexible, long-lasting and high-quality network OS provides a foundation that can gracefully evolve to support new needs in its height for up and down scaling, width for adoption across many platforms, and depth for rich integration of new features and functions. It takes time, significant investment and in-depth expertise.

Most of the engineers writing the early releases of Junos OS came from other companies where they had previously built network software. They had firsthand knowledge of what worked well, and what could be improved. These engineers found new ways to solve the limitations that they'd experienced in building the older operating systems. Resulting innovations in Junos OS are significant and rooted in its earliest design stages. Still, to ensure that our products anticipate and fulfill the next generation of market requirements, Junos OS is periodically reevaluated to determine whether any changes are needed to ensure that it continues to provide the reliability, performance and resilience for which it is known.

Contemporary network operating systems are mostly advanced and specialized branches of POSIX-compliant software platforms and are rarely developed from scratch. The main reason for this situation is the high cost of developing a world-class operating system all the way from concept to finished product. By adopting a general purpose OS architecture, network vendors can focus on routing-specific code, decrease time to market, and benefit from years of technology and research that went into the design of the original (donor) products.

For example, consider Table 1, which lists some operating systems for routers and their respective origins (the Generation column is explained in the following sections).

Generally speaking, network operating systems in routers can be traced to three generations of development, each with distinctively different architectural and design goals.

Typically, first-generation network operating systems for routers and switches were proprietary images running in a flat memory space, often directly from flash memory or ROM. While supporting multiple processes for protocols, packet handling and management, they operated using a cooperative, multitasking model in which each process would run to completion or until it voluntarily relinquished the CPU.

All first-generation network operating systems shared one trait: They eliminated the risks of running full-size commercial operating systems on embedded hardware. Memory management, protection and context switching were either rudimentary or nonexistent, with the primary goals being a small footprint and speed of operation. Nevertheless, first-generation network operating systems made networking commercially viable and were deployed on a wide range of products. The downside was that these systems were plagued with a host of problems associated with resource management and fault isolation; a single runaway process could easily consume the processor or cause the entire system to fail. Such failures were not uncommon in the data networks controlled by older software and could be triggered by software errors, rogue traffic and operator errors.

Legacy platforms of the first generation are still seen in networks worldwide, although they are gradually being pushed into the lowest end of the telecom product lines.

View the original article here