Tom Brannen, a colleague and frequent No Jitter contributor, recently referenced in his recent eWeekly post, “the metaverse is indeed looming before us.”
Facebook last month
announced it was changing its name to Meta, which seemed to kick off the anticipation for this next generation augmented reality (AR)-enabled online experience—at least in the consumer and B2C arena. However, at the
Microsoft Ignite 2021 developer event last week, Microsoft
touted plans to incorporate those same metaverse capabilities in Teams. So, the idea is clearly extending into the enterprise market faster than we had anticipated.
In my decades in IT, the most significant role reversal I've witnessed is how the consumer applications of our technology have come to dwarf and ultimately transform enterprise systems. The experience delivered by those popular consumer apps has now shaped user expectations. This change is for the better because I remember days when we developed a new interactive application, we’d have to establish a school to teach the operators all of the obtuse codes needed to operate it.
As we venture into virgin territory like the metaverse, it’s almost impossible to predict what tools users will gravitate to and why. Mobile apps are a good example.
Early on in the migration to unified communications, every vendor introduced a smartphone app that would allow users to make and receive calls on their business number from the smartphone. The idea died for one simple reason—the app provided another way to make a phone call that was way less convenient than the native smartphone experience. It could add some value if you wanted to keep your mobile number private, but businesses found other ways around that.
Then along came team collaboration. Users could make or receive phone calls without any special app. But when organizations started adopting team collaboration tools to manage work projects, suddenly mobile access to these platforms became indispensable, and team collaboration apps took off. New requirements call for a new assessment.
So, How Do We Network These New Requirements?
As someone who works on delivering on the sorts of promises embedded in the metaverse, my thoughts immediately shift to what these new requirements will mean for us down at the lower layers of the Open Systems Interconnection (OSI Reference Model). That’s where we wrestle with the critical details of delivering service. That mean we address issues of capacity (i.e., how many bits per second will we need), performance (consistency, latency, mobility, packet loss, etc.), in addition to availability, along with the myriad management concerns around security, expandability, troubleshooting, standards compliance and so on.
Getting your arms around the networking requirements for the metaverse is especially challenging in that we don’t know what we’ll be connecting with yet. If you’re a single user at home, a virtual reality headset with a microphone and stereo sound connected on a broadband Internet connection could be your ticket to the metaverse. But does this reflect how a business meeting is going to look?
The other challenge in modeling the metaverse is we’re talking about a five to 10-year timeframe. Do you want to count how many new products vendors have introduced in the last 10-years? Maybe realistic holograms will be an available technology 10-years down the road, and our virtual reality (VR) headsets will go the way of Google Glass. I don’t want to guess how many bits per second we’ll need to send a hologram, but maybe by then, networks will offer infinite capacity and we won’t have to worry.
What Characteristics Should We Look for in Wireless?
Networking the metaverse in a wired environment should be (fairly) straightforward, thanks to the raw carrying capacity of fiber and coaxial cable facilities. We've learned a fundamental lesson about carrying real-time voice and video traffic over IP networks. If the pipes are big enough, delay issues fade away. That means you don’t need any fancy quality of service (QoS) mechanisms to prioritize one packet stream over another because they’re all getting there with minimal forwarding delays, and the real-time protocol (RTP) can address the jitter issues.
Probably the biggest networking lesson from the pandemic was that our work from home users seemed to have more than acceptable performance, so long as they had cable or fiber broadband Internet access. In short, the improvements in basic wired Internet service have largely eliminated the need for performance guarantees—as long as the access connection is big enough. However, wireless is going to be another story.
The caveat to that ‘big pipes rule’ is that it only applies if no links exist that could cause significant propagation delays, which means satellite could pose a problem. Propagation delay or the physical one-way delay on a geosynchronous satellite (GEOS) channel is roughly 250 msec (i.e., ¼ of a second). The signal has to travel 22,300 miles up to the satellite and 22,300 miles back down. Even at the speed of light, that’s ¼ second.
For a basic voice conversation, we’re looking for maximum one-way delays in the range of 100 to 150 msec; some of the texts say 150 msec is the max, but I could notice the 60 msec delay we got on 2G cell phones. I haven’t seen any latency requirements for game controllers. In any event, real-time isn’t happening over a GEOS.
If you put a satellite in a lower orbit, you shorten the distance the signal has to travel—hence the delay. That’s the essential principle of a low earth orbit satellite (LEOS). Motorola pioneered this network type around the turn of the century with its
Iridium network—which, like its competitor
Globalstar, is still operational.
However, LEOS require multiple satellites, and packets may need to be forwarded satellite-to-satellite until they can beam down on the recipient’s location. That adds distance and can also introduce forwarding delays.
Iridium and Globalstar are primarily voice carriers, though both offer some minimal data service. For real data-oriented LEOS, we must wait for
SpaceX’s Starlink,
Amazon’s Kuiper, and other satellite constellations waiting in the wings. Starlink is clearly in the lead, as it operates a controlled pilot service.
Fully deployed, Starlink promises downstream rates of 100 M to 200 Mbps and latencies around 20 msec. In the meantime, tests on the pilot network show data rates between 50 M and 100 Mbps and latencies around 50 msec; by comparison, wired broadband Internet has latencies around 15 msec. For now, the satellite constellations are showing promise (but only “promise”) for real-time traffic. However, we are very excited about the impact this could have on rural broadband availability.
On the ground, cellular networks have been increasing data rates they can support from 2G through 3G, 4G, and now 5G, but they have also been reducing their latency. Unlike satellite systems, where the delay is directly related to the distance the signal physically has to travel, in the cellular network, the distance is short, but the upstream allocation mechanism is hairy.
Wi-Fi networks evolved from wired local area networks (LANs) and operate on a contention basis (i.e., if the channel is idle, wait a bit and let ‘er rip). In a cellular radio access network (RAN), the base station tightly controls when each user device can send. This approach greatly increases efficiency (i.e., there are no upstream collisions among users, and the base station can’t collide with itself). It also allows all manner of prioritization for access capacity and delay.
However, this comes at the expense of a phenomenally complex RAN protocol. Fortunately, those Qualcomm Snapdragon chipsets (or equivalents) do all that stuff. So, it’s primarily an issue for the chipmakers and the carriers.
Recognizing the challenges of cellular latency, the carriers have touted 5G ultra-reliable low latency communications (URLLC) services offering network latencies as low as 1 msec. While carriers may have been touting URLLC services in 5G from the outset, they only recently got around to mentioning that they must first upgrade their core networks for 5G standalone (as opposed to the current non-standalone deployments). That upgrade is still years away—maybe they scheduled it to coincide with the appearance of the metaverse?
The bigger question is—when carriers deliver URLLC, what data rates will they be able to support? The designers will have to tuck that URLLC traffic into the existing 5G frame structure, so it really shouldn’t be that hard to figure out. Rather than dwell on the non-delivery of the URLLC promise, the operators’ current strategy seems to be to highlight the latency improvements from the basic 5G mobile broadband (now around 30 msec one-way) and hope customers stop asking about the other one.
As we found with wired networks, delivering high capacity low latency services will be far easier in a LAN environment. Wireless LANs can currently deliver gigabit data rates and limited QoS mechanisms to prioritize time-sensitive data flows. Most importantly, a whole new world of opportunity has opened with the expansion of Wi-Fi into the 6 GHz band with Wi-Fi 6, effectively adding an additional 1 GHz of radio spectrum to the Wi-Fi band.
With data rates in the low single megabit rates, Bluetooth will likely be limited to small screen devices unless we get way better at audio and video compression.
The Wi-Fi Alliance has been touting that new 6 GHz band for next-gen wireless applications. But the key message is the pipes are bigger, and the propagation delays are insignificant. Therefore, the challenges will be greater on the wide area as opposed to the local side.
Never Too Soon to Prepare
We can expect the metaverse to first appear in consumer services, then bridge into enterprise platforms, based on the pattern we've seen in our field. It's also possible that we'll adopt consumer metaverse tools in the enterprise because they’re useful, and equipped with the necessary security and management systems.
Mobility has become the key differentiator in network connectivity. Meanwhile, wireless offers a range of local and wide-area alternatives we could use for the metaverse. Without a doubt, wireless technologies will continue to evolve, and planners will most likely be looking towards ideas the metaverse and vehicle-to-whatever are shaping those plans.
Unfortunately, technologies like cellular are building on a long established foundation of standards, and a lot of that foundation was based on the expectation that phone calls would be the biggest task to manage.
Phone calls will still be important to us buyers, but these next-gen visions we must focus us on network options that can deliver the goods. Looking forward, that seems to call for even bigger pipes, and most importantly—ways to control the latency for the most time-sensitive portions of that traffic.
This post is written on behalf of BCStrategies, an industry resource for enterprises, vendors, system integrators, and anyone interested in the growing business communications arena. A supplier of objective information on business communications, BCStrategies is supported by an alliance of leading communication industry advisors, analysts, and consultants who have worked in the various segments of the dynamic business communications market.
