Enable Sharing with Miracast

After Miracast is enabled, the Solstice Pod broadcasts that it supports Miracast along with some of its capabilities such as SSID, name of Pod, encryption method, infrastructure capability, etc. This is similar to how a Wi-Fi hotspot broadcasts SSIDs so you can connect.

After device discovery, the IP addresses of the client device and Solstice Pod are passed to the protocol layers, which initiate a TCP connection which allows a capabilities exchange and session setup. This is followed by a UDP connection for video and audio streaming.

Additionally, the way the device connects to the Pod and how it authenticates, is different depending on whether the Solstice Pod is set up to use Wi-Fi Direct or Existing Network.

If the Pod is in Wi-Fi Direct mode, the device negotiates directly with the Pod via Wi-Fi and joins as a P2P group. If Access Control for the Pod has “Enable screen key” checked, the device authenticates via WPS. (This is functionality that the WPS button on your Wi-Fi router employs to connect devices). If “Enable screen key” is not checked, the device connects without authentication.

If the Pod is in Existing Network mode, the device negotiates and connects with network port (Wi-Fi or Ethernet) and check to see if a screen key is required. If a screen key is required, then it encrypts traffic using Datagram Transport Layer Security (DTLS).

Audio and video are shared over Miracast using the Real-time Transport Protocol (RTP). You can have a maximum of four simultaneous Miracast session on a single Pod. However, depending on network bandwidth and latency, two Miracast sessions may be more practical.

Of course, all Miracast connections are concurrent with all other client connections to the Pod.

This use case offers the highest reliability for Miracast sessions, with ~0% packet loss and >95% connection success. The latency should remain in the range 100-166ms, and corruption should be non-existent. If both Ethernet and Wi-Fi are enabled, Miracast favors Ethernet. This is the least common use case because it requires an Ethernet cable connection, which in most cases means the device is a laptop.

The performance of this use case is entirely dependent on the performance of the existing wireless network. Problems such as distant access points or low signal strength can significantly decrease reliability and create packet loss as high as 10% and latency of multiple seconds.

Measuring signal strength of the existing wireless network is an important step in setting up this mode. Solstice Pods can internally measure signal strength, but this information is not available to users. Android phones and many other devices can measure Wi-Fi signal strength. Here is a table that lists expected performance based on signal strength:

The performance and latency of Miracast in this use case falls somewhere between that of Miracast via Ethernet and Miracast via Wireless Network, and is mostly determined by the quality of the wireless network, because Ethernet is highly reliable.

This use case offers reasonable reliability for Miracast sessions, generally with <1% packet loss and >90% connection success. The latency should remain in the range 100-166ms, and corruption should be limited. Wi-Fi Direct works well because a link is made directly between the device and the Solstice Pod, thereby avoiding any performance issues with the enterprise wireless network. Wi-Fi Direct depends on the device and the Pod being within approximately 150-200 feet of each other, with mobile devices typically needing to be within a 25-35-foot range. This essentially means that the device and Pod need to be in the same room.