Google Files Patent for Telling Cell Towers What Your VR Stream Needs
A VR headset on 5G needs a fresh video frame 60 to 120 times a second, but the cell tower sending it doesn't know that. Google's patent describes a translator that tells the tower what's coming.
What Google's XR traffic translator actually does
Cloud gaming and wireless VR headsets are hard on a cell network. The video arrives in bursts, roughly 60 to 120 times a second, and each burst is a slightly different size and lands a few milliseconds early or late. Meanwhile the network behind the cell tower mostly sees a stream of packets, with little idea what they are carrying.
Google's patent describes a translator that sits in the middle. The internet side describes the video in one language (the filing names a format called SDP, which video services use to agree on settings like frame rate). The cell tower speaks a different one. So the carrier's core network converts the details, such as how often frames come, how important each one is, and how much the timing varies, and hands them to the tower.
With that heads-up, the tower can change how it schedules your headset's connection, and even decide which packets to drop first if things get crowded.
receiving, from a core network, an indication of parameters of a protocol data unit (PDU) session established between the network entity and a data network …
Translation: The cell tower gets a message from the central network about the data stream's requirements.
How the core network hands the tower video hints
The independent claims cover both ends of the handoff. In one, a core network entity (the part of the carrier's system that connects to the internet) receives traffic from a data network, such as an XR server, in its original format. It converts the traffic's parameters into a new format that describes video properties, then sends them to the radio access network, or RAN (the towers and radio equipment). In the other, the RAN receives those converted parameters for a session, updates its wireless signaling configuration, and communicates with your device using the new settings.
The claims name the converted format as time sensitive communication assistance information, or TSCAI (a standard set of hints that tells a tower about the rhythm of traffic). The details it can carry include:
- How often video frames or slices arrive, and when the first one starts
- Priority and delay budget (how late a frame can be before it's useless)
- Frame size and jitter statistics (the average, spread and range of timing wobble)
- Group of pictures information, such as full-image frames versus frames that only store changes
The conversion can be a direct mapping, like turning the SDP frame rate into a TSCAI periodicity field, or a calculation derived from it. The tower can then adjust sleep cycles for your device's radio (called C-DRX) and its scheduling grants. The description also covers an alternative route using control messages called NGAP.
The network entity updates one or more wireless signaling configurations based on the parameters. The network entity communicates with a device using the updated one or more configurations.
Translation: The tower adjusts its radio settings to match those needs and talks to your headset.
Why wireless headsets and cloud gaming care
The practical payoff is for anything that streams live video over cellular: wireless VR, AR glasses, and cloud gaming. The filing says wireless headsets could free people from cables and rooms with fast wired internet, but only if the network handles bursty, time-sensitive video well. A tower that knows each frame's deadline could also let your device's radio rest between bursts, which the filing ties to better battery life.
The approach also runs the other way. Because the network shares radio conditions like congestion or handover, a video app could adjust its encoding rate before your picture degrades. Since the filing leans on existing mobile standards, the audience that matters most is carriers, modem makers and headset makers who would need to agree on the same format.
Google's 990th filing in our Google coverage since May applies to phone interactions, continuing threads like tap-to-answer calls and selective video sharpening.
Nothing in this filing needs new hardware. It describes messages and rules that a carrier's existing equipment would send to each other, so the work is software and agreement.
The agreement is the hard part. A tower, a carrier's core network, a video server and your headset's modem all have to read the same translated format, and the filing builds on existing standard fields while adding new ones. That points to a slow route: the industry groups that write mobile standards come first, then carrier network upgrades, then devices that can use the hints.
For you, the shortest path to a visible result is a cloud game or VR call that holds up better on 5G and drains less battery. You would notice it as fewer stutters, and it would come through carrier upgrades without any new gadget.
Get our take in your Top Stories
Liked this breakdown? Add Patentlyze as a preferred source on Google, and our plain-English take shows up more often in your Top Stories the next time Google patent news breaks.
There are more where this came from
We read every patent application Big Tech publishes and send you the ones worth knowing. Plain English, free, every week.
The drawings
10 drawing sheets from US 2026/0352736 A1 · click any drawing to enlarge
Show the other 2 sheets
Want this weekly breakdown for a company we don't cover? Patentlyze Pro →
Be the first to weigh in