country_code

Network setup#

Network setup, monitoring and troubleshooting

Setup#

CloudXR streaming to the Apple Vision Pro requires a stable connection between the server and the Apple Vision Pro, and requires sufficient bandwidth to support high quality streaming.

The following table summarizes the recommended and minimum network requirements:

Metric

Recommended

Minimum

Downstream Available Bandwidth

200Mbps

100Mbps

Pose to Frame Received Latency

30ms

100ms

Downstream/Upstream Jitter

1ms

4ms

Downstream Packet Loss

0%

1%

Wifi Channel

5GHz/6GHz

5GHz

Wifi Channel Width

80Mhz

40Mhz

Router recommendations

Any Modern WiFi router that supports 5GHz over 802.11ac and manual channel selection. A good candidate is the Acer Predator Connect W6 Wi-Fi 6E Gaming Router, which is also a GeForce NOW certified router.

Internet connection

For streaming from GDN, in addition to a stable local WiFi setup, a stable connection to the Internet is required. A minimum of 200 Mbps downstream and 20 Mbps upstream is recommended. Your mileage may vary on slower connections, but a minimum of 100 Mbps downstream is required. Your internet connection must also support IPv4 as GDN does not currently support IPv6.

WiFi configuration

We only recommend using 5GHz channels 44 or 149 with a 80MHz channel width for streaming to Apple Vision Pro. These specific channels are used by Apple devices to discover each other on the network and the use of other channels can result in the device frequency hopping and degrading the streaming experience. If you are streaming to an iPad we recommend 6GHz channels. Each band should have a distinct SSID to avoid devices connecting to the wrong bands and you can turn off the 2.4GHz channel entirely. Each device should be configured to use the SSID matching the WiFi band it should be using and other SSIDs should be deleted to prevent them from hopping between bands. In addition, ensure that there aren’t other nearby wireless networks that could potentially cause interference or, if that is not possible, change the channel on your router to avoid interfering with the other networks.

Firewall configuration

The CloudXR server will attempt to open the required ports on the workstation firewall when it is started. Doing so requires users to respond to an elevated prompt on the workstation. In case that is not possible manual port configuration may be required or the firewall be turned off entirely. Similarly the WiFi network should also be configured to allow traffic on these ports.

Here is the list of ports that must be open:

Channel

Type

Server

Client

Connect

TCP

48010

49007

Video

UDP

47998, 48005, 48008, 48012

49005, 50000-55000

Input

UDP

47999

49006

Audio

UDP

48000

49003

Mic

UDP

48002

49004

Network topology

Due to the bandwidth requirements for streaming high quality world locked XR content it is ideal to dedicate the WiFi for the use of the Apple Vision Pro and have other devices connect to the router over ethernet. If that is not possible consider using the 6GHz channel on the router for any other devices. This is especially critical when streaming content from a local workstation. It is best to ensure that the router is in the same room as the client device and it has a clear line of sight to the device. We recommend no more than two Vision Pro devices per router especially if you are also using Vision Pro screen mirroring. For iPad streaming we recommend no more than four devices.

_images/network-topology.png

Note

In cases where you are doing local streaming and you do not control your router settings, for example a corporate WiFi network which is configured to block certain ports, you can also use Windows Mobile Hotspot to broadcast a WiFi network from your workstation directly to the client device. Make sure you select 5GHz for the band.

Monitoring#

The CloudXR library for the Apple Vision Pro provides an API to get network quality reports. In addition to that, there is a HUD provided that provides real-time information about end-to-end fps, latency and bandwidth. These built-in tools will help identify problems during streaming.

_images/client-hud.png

The HUD displays three charts providing the following information: 1. FPS - Shows Pose (Green), Frame (Yellow) and Reprojection (Red) rates in hz.

The Pose Rate is how often the device is sending poses to the server, the Frame Rate is how often the server is sending rendered frames back and the Reprojection Rate is how often the device is updating RealityKit with those frames.

The server will render at most one frame per received pose meaning Frame Rate can be at most Pose Rate. Typically the Pose Rate should be a solid 90hz for Apple Vision Pro and 60Hz for iPad or the Simulators. The server will attempt to render as many frames as it can while maintaining a constant interval between frames so Frame Rate will always be Pose Rate divided by an integer. For example a 90hz Pose Rate will result in a Frame Rate of 90/45/30/22.5/15hz. The Reprojection rate is at most the Frame rate and they typically match unless the device is forced to drop frames. High variation in the Pose or Reprojection rate typically indicate some kind of performance issue on the client however some variation in the Frame rate is expected and can be absorbed by the dejitter buffer. If that variation is too high it can result in frame skips as the device drops late frames. These conditions can be identified by looking at the p10/5/1 values of these metrics.

  1. Bandwidth - Shows Average Streaming Rate (Green) and Available Bandwidth (Blue) in Mbps.

    These show how much of the available bandwidth is being used for CloudXR streaming

    As noted above we recommend a minimum Available Bandwidth of 100Mbps to maintain a high quality stream. The utilized bandwidth is highly content dependent and may be lower than that figure however that does not indicate that a lower bandwidth would result in an acceptable user experience.

  2. Latency - Shows Pose Sent to Pose Received (Green), Frame Received (Yellow), Frame Dequeued (Orange) and Frame Submitted (Red) in ms.

    These show the durations between a pose being sent and received at the server, a rendered frame for that pose arriving at the client, being dequeued from the dejitter buffer and finally being submitted to the display.

    For the best and most responsive streaming experience a Pose to Frame Received latency of 30ms is ideal. Values up to 100ms can still result in a usable experience provided the network jitter is low however it is not recommended to attempt streaming at any higher latencies. The more interactive the content the lower the latency tolerance. To measure uplink and downlink jitter look for high variation in the Pose Upload and Pose to Frame Received values respectively by checking the p90/95/99 values of these metrics.

If any of these numbers are outside the stated ranges consult the troubleshooting section below to identify possible causes.

Troubleshooting#

  1. Ensure your server is reachable from the network your client devices connect to.

    Network Analyzer is an app on iOS that will allow you to run some basic tests like validating your network info, scanning for local servers and checking if their address and ports are reachable. Connect an iOS device to the network you are using to stream and check the Information, LAN and Tools tabs as shown below.

    • The Information tab will give you general info about your network connection.

    • The LAN tab will allow you to scan for local servers.

    • The Tools tab can be used to ping a server and ensure its RTSP port (40810) is reachable.

    Note

    In order for an iPad or Vision Pro app to access a server on the local network they must display a permissions prompt to the user to proceed. This prompt is automatically shown when a local connection attempt is made. If the prompt is not shown or accidentally dismissed this can prevent the app from connecting. In this situation you can try to navigate to the app settings and manually grant the permission or re-install it to bring back the prompt.

  2. Run a basic packet loss, latency, and jitter test from the Apple Vision Pro, and from another device that is wired to the network.

    packetlosstest.com is a nice tool, but you can use any other test that provides packet loss, latency and jitter tests. Use the settings as shown below. The latency chart must be mostly flat (occasional spikes are acceptable, but may result in occasional streaming hiccups).

    _images/packet-loss-settings.png
    _images/packet-loss-clean.png

    If these tests look good when running from the Vision Pro, but the streaming quality is poor, there might not be enough bandwidth available. See below for additional steps. For GDN streaming, it’s also possible there is a networking issue upstream, unrelated to the local networking setup (e.g. ISP transit, or data center network issue). In that case, please submit a feedback report.

    If the tests from the wired connection are good, but the tests from the Vision Pro are bad, there might be potential issues with the Wireless setup. See below for additional steps.

    If the test results are bad even over the Wired connection, please contact your ISP to troubleshoot.

  3. Run a basic bandwidth test from the Apple Vision Pro, and from another device that is wired to the network.

    • If streaming from GDN, speedtest.net and speed.cloudflare.com are good options to test the network bandwidth. See the bandwidth recommendations in the Setup section

      If the tests from the wired connection are good, but the tests from the vision pro are bad, there might be potential issues with the Wireless setup. See below for additional steps.

      If the test results are bad even over the Wired connection, please contact your ISP to troubleshoot.

      Note

      Generic speed testing tools and GDN streaming will transmit traffic on, at least partially, disjoint network paths. In some occurrences, the transit network used in GDN streaming may cause loss and latency build-up downstream/upstream that may not be observable in speed tests outputs.

      If you have a 4K monitor attached to a PC, you can also try running the GeForce Now network test using a GFN account.

    • If streaming from a local workstation, iPerf is a good option to test the bandwidth between your workstation and the client device. See the bandwidth recommendations in the Setup section

      If the tests from the wired connection are good, but the tests from the vision pro are bad, there might be potential issues with the Wireless setup. See below for additional steps.

      To run this test download and run the iPerf server on your local workstation and get the iPerf client from the App store. Note that there is only an iPad version of the app but it can also be installed on the Vision Pro and will show up in the Compatible Apps section of the home screen. Enter the IP address of your server and connect from the client to measure the peer to peer bandwidth available.

  4. Check for channel interference.

    Other routers in the vicinity may conflict with the channel selected on your WiFi router. Use an app like WiFi Explorer or similar on a MacBook connected to the same network to identify other routers on the same channel. If there are interfering routers, turn them off or change the channel of your own router. Alternatively, try shielding the area by closing doors/windows to reduce interference.

    _images/wifi-explorer.png
  5. Check the channel and the channel bandwidth.

    This can be done using WiFi Explorer, logging into your router settings page under wireless settings or, if you have a Mac, pressing <Option>+<click> on the wireless menu will show the current channel and bandwidth. See the channel recommendations in the Setup section

  6. If you see really high, periodic network latency spikes similar to what is shown below, it might be Apple’s Wireless Direct Link (AWDL) protocol causing channel hopping.

    _images/packet-loss-spikes.png

    This feature cannot be turned off however, to mitigate its impact, you can manually configure your router to use channel 44 or 149 which are the channels used by AWDL. If that is not possible, you can try to reduce how often the device channel hops by turning off Airplay, Bluetooth, Handoff (Universal Clipboard), Location Services, and other such features.