Demystifying Voice & Data -- Part 3

As an IT/telecom professional, you are likely to have a good understanding about the theory and principles of voice and data. However, even if you are an expert, at some point in time, you will need to discuss or explain voice, data and wireless principles to your nontechnical, line-of-business colleagues. The intent of this, and my two previous No Jitter posts, is to help you demystify technical concepts for nontechnical colleagues, customers, clients, and so on.

Each article covers a couple of topics, and tries to explain these in nontechnical terms. While the examples and analogies may not always be 100% applicable, they should provide some perspective -- i.e., highlight the differences and advantages.

For my previous posts in my "Demystifying Voice & Data" series, see:

In this article, I will demystify the topic of packet switching (versus circuit switching).

What Is Packet Switching?
Prior to packet switching's arrival on the networking scene, voice communications occurred over circuit- switched networks. So, let's take a look at each of these.

Circuit Switching - In this mode of communications, the switch establishes a dedicated circuit or channel for the duration of the transmission or call. Once the call ends, the switch relinquishes the dedicated circuit so it is available for use by the next voice call. By dedicated, I mean no other call shares the circuit. Switch vendors developed circuit switching primarily as a means of carrying voice communications.

Packet Switching - In this mode of communications, a switch breaks the message into a number of parts (packets) and sends each independently over the most optimal route. At the destination, a switch reassembles the packets at the final destination. Packet-switching networks do use dedicated circuits. Rather, packets travel over shared circuits; they are not affected by other packets. The need to carry data communications drove the development of packet switches.

To help explain how packet switching works to a nontechnical audience, you might rely on examples from outside the IT/telecom world. I've provided a few examples below.

Non-IT Examples of 'Packet Switching'

Example #1: Reassembling the London Bridge - In 1967, the city of London sold the London Bridge, which had been in need of updating, to an American for relocation at Lake Havasu in Arizona, where it would serve as a tourist attraction. The logistical problem was how to move the bridge, which dated to 1831, from London to Arizona. No boat was large enough to carry the bridge intact -- and even if such a ship existed, transporting the bridge in one piece would have been cost prohibitive and impractical. The obvious answer was to deconstruct the bridge into individual numbered granite blocks (or, for your purposes, packets). Normal ships would then transport these blocks (packets) as cargo.

The blocks (packets) could be distributed among any number of ships, and did not need to be placed sequentially. While Ship A might have carried 1,000 non-sequential blocks (packets) -- Block #243, Block #14,843, Block #97, Block #7,003, and so on -- Ship B might have carried 1,200 non-sequential blocks. After several months, when all the blocks (packets) arrived at Lake Havasu, workers there reassembled them back into the London Bridge.

Example #2: Traveling to the Rose Bowl - On Jan. 4, 2006, the Texas Longhorns and the USC Trojans played in the college football championship game at the Rose Bowl in Pasadena, Calif. For their trip, each Longhorns player received a fixed dollar amount and a week's time to get to California for the first practice session in Pasadena. The players (packets) made their own travel arrangements. Most players (packets) flew on different flights with different airlines. Some chose to drive to California. About a week before the game, the team managers "reassembled" all the players (packets) and started their practices... eventually leading to a thrilling 41-to-38 victory over USC.

Key Observation: As these two examples show, sequential timeliness is not a major requirement. While delivery timeframes are set, the order in which the packets arrive is not critical. In the London Bridge example, Block #494 could arrive three days later than Block #3,083 without any consequence. The important factor is that all blocks arrive by a certain date.

The same is true for the Texas football squad. While some players came early to Los Angeles to spend time sightseeing, others preferred to spend time in Austin and arrive right before the first practice. No player needed to arrive sooner than any other, nor did the players need to arrive in any particular sequence.

Non-IT Analogy to Packet Switching
Perhaps the packet-switching/IP revolution in IT/telecom was presaged by the revolution in the shipping industry brought on by the innovation of the container.

Prior to 1956, sending goods over water was done via a break-bulk system in which cargo was loaded onto ships as individual pieces. Different types of ships handled specific types of goods. The loading and unloading of goods was time-consuming and expensive. The ships themselves were relatively small and crew-related overhead was high given the amount of goods shipped.

Enter the container, which revolutionized the shipping industry in 1956. Instead of moved individually, goods could be placed in containers for shipment. It didn't matter the nature of the goods. Container A could contain corn, Container B electronics, Container C stuffed toys, Container D food products -- and one ship could carry them all. The important factor was that each container was of uniform size and could be handled in an efficient manner -- i.e., mechanized, stacked onto ships with minimal handling and requiring little waterfront space.

Over the years, container ships became larger and the relative costs of shipping goods continued to drop. To put this in an IT/telecom perspective, substitute "packets" for "containers."

Just as containers revolutionized the shipping industry, packet switching (and IP) has revolutionized the IT/voice industry.

Next up in my "Demystifying Voice & Data" series will be more on data communications.

"SCTC Perspectives" is written by members of the Society of Communications Technology Consultants, an international organization of independent information and communication technology professionals serving clients in all business sectors and government worldwide.