[This is part one of a series of 3 posts about the differences between circuit switching and packet switching over mobile networks. Due to the growing number of VoIP and video calling applications that are now hitting mobile devices, it is probably time to consider the differences between the mobile data network and the mobile circuit switched network.]

• Part 1: Pipes (this post)
• Part 2: Signaling
• Part 3: Media

A short disclaimer: I don’t consider myself an expert in mobile networks or circuit switching. Whatever I write here is based on my observations, working on 3G-324M and VoIP related protocols that run on top of mobile networks. It might be inaccurate, but it should be close enough to the truth for most purposes. If I am mistaken here and there,  please feel free to comment on that. I wouldn’t want to misguide anyone.

When you deal with mobile video telephony, you learn a lot about the mobile network. It starts from the selection of the protocol to use, which dictates the network’s characteristics as well as a lot of other things.

There are three topics I’d like to cover in the following short series of 3 posts:

1. The pipe – circuit versus packet switching
2. Signaling – how is it handled in these different settings?
3. Media – what happens with it in both cases?

Circuit switching and The Pipe

Circuit switching is easy: you get a given pipe with a constant bitrate. It will be bi-directional in nature. You just need to fill it in.

Take 3G-324M as an example – a circuit switched mobile video telephony protocol. It requires a 64kbps bitrate, which means that in each direction you have 64kbps at each given second – nothing more and nothing less.

The funny thing is that you must fill in this pipe – even when you have nothing to send. For that purpose, protocols running over circuit switched connections need to have something called “stuffing” – a given sequence of bits (or bytes) that is sent instead of just sending “nothing”.

For mobile circuit switching the bitstream being sent is byte-aligned – this means that you can treat incoming data as if it is ordered by bytes – no need to sort that one out. Be aware that this isn’t always the case.

Errors in a circuit switched pipe will look like interferences – switched bits in the bit stream.

Usually, if you want to work on top of circuit switching, you will need to deal with overflows and underflows – having too much to send and having not enough to send respectively. Best way to deal with underflows is to have available data to send at all times – something that needs to be tuned versus the need to have low latencies (the more data you prepare in advance the bigger the latency you will introduce).

Another important aspect of circuit switching is that you usually rely on modem events when sending stuff in order to keep up the pace properly. Not easy to achieve – I’ve seen a lot of developers struggle with this one trying to get it just right.

Packet Switching and The Pipe

Packet switching is fiction. It doesn’t really exist as far as I can tell. It is achieved by lower level protocols that fill in the pipe in a way that allows you to get a semblance of packets as the developer on top. That said we do have packet switching over mobile, usually called the “data” channel.

Simply put, packet switching is IP communications. You can use a web browser on top of it, or run protocols such as SIP or H.323 (a.k.a VoIP).

With packet switching you don’t really know how much bitrate you have available – it fluctuates depending on the network conditions, the reception you have and the amount of users in the given cell. This unknown quantity can cause any number of problems for real-time protocols, especially when you want to send video – there’s a need to be able to estimate, in real-time, the available bitrate at each given moment.

There’s an overhead involved with sending IP packets, which means that the network utilization as a whole is lower. There are ways to overcome this by using IP header compression techniques, but in general – there is an overhead for each packet, which most IP protocols neglect to consider in their design.

Over IP networks, when bits are switched the immediate result is a lost packet. This is because the IP layers below the developer’s code throws away such packets automatically. It can be wasteful at times, but it is also easy to manage (no need to check the validity of received data).

And Here’s a Handy Table…

Here’s a short summary of what we had this time:

Next time I will discuss signaling over circuit switching and packet switching. Stay tuned.