Blog Post

Understanding the Anatomy of a Wireless Connection

Published
June 25, 2014
#
 mins read
By 

in this blog post

Consider your smartphone. This increasingly complicated mobile device drives internet usage around the globe. According to Statista, mobile phones (and this excludes tablets) accounted for 17.4% of all web traffic in 2013, up from 11.1% in 2012. Some of this traffic is derived from new web users, whose smartphones provided their first access to the internet, but another segment of the increased traffic represents a change in preference: namely, the preference to surf the web from mobile phones instead of desktops.

What is it that makes mobile phones so attractive? Well, the fact that they’re mobile. A cellphone is untethered, unplugged, unwired; it’s internet on the go. Using your smartphone to access the internet is no different than using your desktop, but you can put it in your pocket and walk down the street, right? Well, that’s the hope, at least from a web developer’s perspective. Web developers strive for a seamless transition where mobile end users perceive no change in performance, but many things change behind the scenes.

Let’s take a look…

Any device not physically connected to a network or router, but still capable of connecting with other network nodes (think other cellphones or Apple TV) falls under the category of wireless. A very incomplete list of wireless networks includes WiFi, 2G, 3G, and 4G LTE. While each wireless network functions in its own specific manner, focusing in on one may be helpful to understand current advantages and limitations of wireless internet access. For instance, what happens on the 4G LTE mobile network after you type a URL into your smartphone browser and click “Go”?

Here in the U.S., smartphones communicate through radio waves and frequencies determined by the Federal Communications Commission (FCC) and the National Telecommunications and Information Administration (NTIA). The FCC and NTIA allocate the radio spectrum for different purposes: lower frequencies (larger, farther traveling radio waves) better suit AM radio, while two-way cellphone communication uses higher frequencies to transfer more data, but at the sacrifice of covering a smaller geographical area or cell.

radio-frequencies

Cells are provided by cell sites, also called base stations, which are facilities that contain cellular telephone transmitters. The size of a cell can vary depending on a cell site’s transmission power and the surrounding terrain. Typically, someone using their smartphone on the go will move through a honeycomb of cells and switch from cell site to cell site as they click around a website.

But making these radio connections comes at great expense to battery life, a valuable resource for mobile phones. For this reason, different states of ‘awakeness’ exist to mitigate power drain as much as possible. Depending on recent activity, a smartphone’s state can range from disconnected to active or somewhere in between (idle); or in milliwatts, range from less than 15mW upwards of 3,500mW!

However, this, to a great extent, falls outside of the user’s control. Instead, we place our trust in the Radio Resource Controller (RRC), a protocol that masterminds all connections between your smartphone and a cell site, as well as dictates your device’s ‘awakeness’ state. So unlike a desktop computer, which enjoys a continuous network connection through an Ethernet cable, wireless devices face a constant struggle to balance connection vs. battery life. In other words, a lower power state may prolong battery life, but it introduces unavoidable latency to reestablish a connection to the radio link. The RRC resides directly in the cell tower for 4G in effort to continue to reduce this latency.

[Before we move on, a quick note to web developers: every radio transmission, regardless of size, transitions a smartphone into an active state. No amount of data is negligible because any transmission forces the device into the same battery-draining pace. Therefore, best practices prescribe delivering as much data in one shot as possible, and keeping total transmissions to a minimum.]

Following the initial negotiations of the RRC, a component named Radio Access Network (RAN) allocates radio spectrum and connects the hand-held device with the Core Network (CN), which in LTE is called the Evolved Packet Core (EPC). The RAN also speaks to the CN about the user’s location, a rather difficult and complicated duty since connections jump from tower to tower as a user moves or a cell saturates.

The CN carries the data packets from the RAN to the worldwide web and back with the help of its own components: Serving Gateway (SGW) and Packet Data Network Gateway (PGW). SGW receives the packets from the cell tower and routes them to the PGW which assigns the device an IP address. The device can now communicate with the public internet and ultimately reach the servers housing the URL’s content.

wireless connection

The desired data then begins its return journey. It first returns to the PGW, becomes encapsulated and receives scrubbing for quality of service. The packets continue back to the SGW, which in turn works with (this is last acronym, I promise!) the Mobility Management Entity (MME). The MME provides the Serving gateway with location data, allowing the SGW to route the packets to the RAN and, finally, to your phone.

One note on the return path: another battle between battery life and latency can occur if your smartphone settles into an idle state: as mentioned above, the SGW actually does not know the exact location of the device it must route the packets back to, but instead uses a logical grouping of cell towers to maintain only an idea of the user’s location, asking the MME to help it pinpoint the device. This is in order to avoid draining a device’s power.

In order to discern a device’s exact location, the radio base station must speak with the device, and as we know, that means an active state and many mW on behalf of the device. The SGW’s logical grouping process permits the smartphone to nap and save power, only waking periodically to listen for a broadcast from nearby towers. If the MME does not know the smartphone’s location, it pages the towers, asks them to broadcast, and once the device awakes, receives its exact location. The MME then informs the SGW and the packets continue on their way.

I point this out to emphasize the simple fact that tradeoffs exist, no matter how you choose to access the internet, be it via wire or via waves. Although the mobile path progression laid out above is no way comprehensive, its purpose is to highlight several of the costs and benefits of choosing mobility.

So consider your smartphone, the wireless infrastructure it relies on, and the websites it surfs. These parts must work together; and if we understand the reasoning for their designs and functions, and the resulting latencies, it may help us improve mobile experience and better address the growing trend of mobile internet usage.

Consider your smartphone. This increasingly complicated mobile device drives internet usage around the globe. According to Statista, mobile phones (and this excludes tablets) accounted for 17.4% of all web traffic in 2013, up from 11.1% in 2012. Some of this traffic is derived from new web users, whose smartphones provided their first access to the internet, but another segment of the increased traffic represents a change in preference: namely, the preference to surf the web from mobile phones instead of desktops.

What is it that makes mobile phones so attractive? Well, the fact that they’re mobile. A cellphone is untethered, unplugged, unwired; it’s internet on the go. Using your smartphone to access the internet is no different than using your desktop, but you can put it in your pocket and walk down the street, right? Well, that’s the hope, at least from a web developer’s perspective. Web developers strive for a seamless transition where mobile end users perceive no change in performance, but many things change behind the scenes.

Let’s take a look…

Any device not physically connected to a network or router, but still capable of connecting with other network nodes (think other cellphones or Apple TV) falls under the category of wireless. A very incomplete list of wireless networks includes WiFi, 2G, 3G, and 4G LTE. While each wireless network functions in its own specific manner, focusing in on one may be helpful to understand current advantages and limitations of wireless internet access. For instance, what happens on the 4G LTE mobile network after you type a URL into your smartphone browser and click “Go”?

Here in the U.S., smartphones communicate through radio waves and frequencies determined by the Federal Communications Commission (FCC) and the National Telecommunications and Information Administration (NTIA). The FCC and NTIA allocate the radio spectrum for different purposes: lower frequencies (larger, farther traveling radio waves) better suit AM radio, while two-way cellphone communication uses higher frequencies to transfer more data, but at the sacrifice of covering a smaller geographical area or cell.

radio-frequencies

Cells are provided by cell sites, also called base stations, which are facilities that contain cellular telephone transmitters. The size of a cell can vary depending on a cell site’s transmission power and the surrounding terrain. Typically, someone using their smartphone on the go will move through a honeycomb of cells and switch from cell site to cell site as they click around a website.

But making these radio connections comes at great expense to battery life, a valuable resource for mobile phones. For this reason, different states of ‘awakeness’ exist to mitigate power drain as much as possible. Depending on recent activity, a smartphone’s state can range from disconnected to active or somewhere in between (idle); or in milliwatts, range from less than 15mW upwards of 3,500mW!

However, this, to a great extent, falls outside of the user’s control. Instead, we place our trust in the Radio Resource Controller (RRC), a protocol that masterminds all connections between your smartphone and a cell site, as well as dictates your device’s ‘awakeness’ state. So unlike a desktop computer, which enjoys a continuous network connection through an Ethernet cable, wireless devices face a constant struggle to balance connection vs. battery life. In other words, a lower power state may prolong battery life, but it introduces unavoidable latency to reestablish a connection to the radio link. The RRC resides directly in the cell tower for 4G in effort to continue to reduce this latency.

[Before we move on, a quick note to web developers: every radio transmission, regardless of size, transitions a smartphone into an active state. No amount of data is negligible because any transmission forces the device into the same battery-draining pace. Therefore, best practices prescribe delivering as much data in one shot as possible, and keeping total transmissions to a minimum.]

Following the initial negotiations of the RRC, a component named Radio Access Network (RAN) allocates radio spectrum and connects the hand-held device with the Core Network (CN), which in LTE is called the Evolved Packet Core (EPC). The RAN also speaks to the CN about the user’s location, a rather difficult and complicated duty since connections jump from tower to tower as a user moves or a cell saturates.

The CN carries the data packets from the RAN to the worldwide web and back with the help of its own components: Serving Gateway (SGW) and Packet Data Network Gateway (PGW). SGW receives the packets from the cell tower and routes them to the PGW which assigns the device an IP address. The device can now communicate with the public internet and ultimately reach the servers housing the URL’s content.

wireless connection

The desired data then begins its return journey. It first returns to the PGW, becomes encapsulated and receives scrubbing for quality of service. The packets continue back to the SGW, which in turn works with (this is last acronym, I promise!) the Mobility Management Entity (MME). The MME provides the Serving gateway with location data, allowing the SGW to route the packets to the RAN and, finally, to your phone.

One note on the return path: another battle between battery life and latency can occur if your smartphone settles into an idle state: as mentioned above, the SGW actually does not know the exact location of the device it must route the packets back to, but instead uses a logical grouping of cell towers to maintain only an idea of the user’s location, asking the MME to help it pinpoint the device. This is in order to avoid draining a device’s power.

In order to discern a device’s exact location, the radio base station must speak with the device, and as we know, that means an active state and many mW on behalf of the device. The SGW’s logical grouping process permits the smartphone to nap and save power, only waking periodically to listen for a broadcast from nearby towers. If the MME does not know the smartphone’s location, it pages the towers, asks them to broadcast, and once the device awakes, receives its exact location. The MME then informs the SGW and the packets continue on their way.

I point this out to emphasize the simple fact that tradeoffs exist, no matter how you choose to access the internet, be it via wire or via waves. Although the mobile path progression laid out above is no way comprehensive, its purpose is to highlight several of the costs and benefits of choosing mobility.

So consider your smartphone, the wireless infrastructure it relies on, and the websites it surfs. These parts must work together; and if we understand the reasoning for their designs and functions, and the resulting latencies, it may help us improve mobile experience and better address the growing trend of mobile internet usage.

This is some text inside of a div block.

You might also like

Blog post

Preparing for the unexpected: Lessons from the AJIO and Jio Outage

Blog post

Learnings from ServiceNow’s Proactive Response to a Network Breakdown

Blog post

Use the Catchpoint Terraform Provider in your CI/CD workflows