Separate VLANs for Hotel Guest-room Wi-Fi and TVs: How Casting Transmitters Enable Private Cross-VLAN Screen Casting

In hotel network construction, deploying separate VLANs for guest-room Wi-Fi and TV networks has become a common practice.
Mobile phones connect to the guest Wi-Fi, while TVs access the TV service network. The two networks are isolated via VLANs. This prevents interference between different services and mitigates security risks where guest terminals directly access TV devices.

However, a challenge arises:
After network isolation, can mobile phones still discover the in-room TV?

Many hotels encounter this issue during actual casting deployment. Casting protocols including AirPlay, DLNA and Lelink rely on device discovery mechanisms. Once mobile phones and TVs reside on different VLANs, the casting links dependent on broadcast, multicast or LAN discovery may malfunction.

Hotels are then forced to choose between opening VLAN isolation or compromising casting experience.

In fact, hotels do not need to dismantle existing network isolation. With a screen casting reflector, cross-VLAN casting discovery can be achieved without bridging the guest network and TV network. Combined with room-level binding, genuine private screen casting is realized.

I. Why Screen Casting Fails When Wi-Fi and TVs Use Separate VLANs

For cybersecurity, guest Wi-Fi and the IoT network for TVs are normally assigned to different VLANs and subnets with strict isolation. This is the baseline for security compliance.

Nevertheless, AirPlay, DLNA and other casting protocols depend on mDNS and SSDP multicast discovery. A mobile phone sends a broadcast query within the LAN to search for devices, and the TV responds. Multicast only works within the same broadcast domain. Once network segments are isolated, discovery packets cannot reach the TV.

The mobile phone cannot “see” the TV, hence casting fails.

Previously, hotels only had three options: enable full-network multicast and bear the risk of cross-room casting; maintain strict isolation and sacrifice casting experience for Apple users; or let TVs broadcast their own Wi-Fi hotspots, which creates loopholes in real-name authentication.

No perfect solution existed among these three choices.

II. Screen Casting Reflector: Enable Casting Without Bridging Network Segments

The core principle of AINOPOL’s screen casting reflector: keep network segments isolated and block multicast forwarding, and implement application-layer proxy inside the gateway.

1. TV announcement registration: After power-on, the TV sends mDNS/SSDP multicast announcements within the TV network. The reflector captures these announcements on the TV network side and completes device registration. Multicast packets are never broadcast across VLANs.
2. Response to mobile queries: When a mobile phone on the guest network sends a casting query, the reflector matches devices according to room binding rules and replies via unicast. It rewrites the real IP and port in the response to the gateway proxy address. The mobile phone only sees the gateway proxy address.
3. Bidirectional media stream proxy: Casting control signals and audio/video streams are forwarded bidirectionally following the path: Mobile Phone → Gateway → TV. Encrypted payloads are forwarded without decryption. Image quality and latency are nearly identical to casting within a single network segment.

Layer 3 routing remains closed throughout the whole process, multicast will not cross VLANs, and the original network isolation architecture is fully preserved.

III. How to Ensure Casting Is Restricted to the Same Room After Cross-VLAN Deployment

Cross-VLAN casting solves the basic requirement of “successful casting”. The next question: how to guarantee guests only cast content to the TV inside their own room?

• Room-level access control: The TV standby screen displays a QR code containing the room number and binding token, which refreshes automatically every 5 minutes by default. After guests complete Portal real-name authentication and scan the QR code, a binding relationship is established between the mobile phone and the TV in the same room. The mobile phone can only discover the approved TV in its own room; TVs in adjacent rooms will not appear in the casting list.
• One-to-one binding: Each screen allows only one mobile phone to scan and bind at a time. To switch to another mobile phone, the previous session exits, and the new phone rescans the QR code for binding.
• Automatic unbinding upon check-out: Bindings expire automatically after 24 hours by default and become invalid after guest check-out, requiring no manual unbinding at the front desk. When integrated with the hotel PMS system, the platform automatically unbinds on check-out and refreshes QR codes upon new check-in.
• Three-state device audit: Every TV is marked with one of three statuses: Approved / Pending Review / Blacklisted. Only validated legitimate devices are permitted casting services; unreviewed devices are hidden from the casting list. Combined with MAC/IP whitelists & blacklists and configurable casting time windows, hotels can implement fine-grained management of casting permissions.

IV. Cross-VLAN Casting Log Auditing to Meet Compliance Requirements

Decree No.176 issued by the Ministry of Public Security, effective October 1, 2026, mandates network log retention of no less than six months. Screen casting activity logs fall within the scope of supervision.

• Real-name association: Guests must finish Portal real-name authentication before using screen casting. The authenticated username is linked to binding relationships, casting sessions and audit logs. Casting logs record: an authenticated user, at a specific time, from a specific room, using a specific device, casting for a specific duration.
• Complete records: The system automatically records casting device information, operation timestamp, corresponding guest room and session duration. Audit log fields include timestamp, event type, room, authenticated username, mobile IP, TV IP, protocol, duration and traffic volume.
• Real-time query: Active sessions support real-time inspection of session ID, room number, authenticated username, mobile IP, TV IP, protocol, start time, elapsed duration and traffic statistics, with one-click session termination available.
• 180-day log retention: Logs are stored locally with encryption and rolling overwrite for 180 days by default. No gaps, no automatic clearing and no tampering. Integration with cloud log platforms is supported to satisfy 180-day retention compliance.

V. Deployment: No Network Modification, Go-Live Within Hours

The screen casting reflector is a built-in software value-added module of the Dream Gateway and is provided free of charge with the gateway. No separate hardware or license purchase is required.

Enable it with one click in the Value-added Applications / Function Center on the gateway web portal. Simply assign network ports or VLANs corresponding to each network domain to complete deployment.

No changes to existing VLANs, no global multicast activation, no client installation on each TV. TVs retain their factory operating systems, and guests can use native mobile casting functions. Renovation can be performed during off-peak hours without disrupting hotel operations.

FAQ

Q: Why does screen casting fail when guest Wi-Fi and TVs are on separate VLANs?
A: AirPlay, DLNA and other casting protocols rely on mDNS and SSDP multicast discovery. Multicast functions only within the same broadcast domain. After VLAN isolation, multicast packets cannot cross network segments, so the mobile phone cannot “see” the TV.

Q: How does the casting reflector enable casting without opening VLANs?
A: The reflector implements application-layer proxy inside the gateway. It captures and registers mDNS/SSDP announcements from TVs. When mobile phones send discovery queries, the reflector replies via unicast and rewrites the real IP/port to the gateway proxy address. Media streams are forwarded bidirectionally through the gateway.

Q: What information is recorded in casting logs?
A: The system automatically records casting device information, operation time, corresponding guest room and session duration, associated with the authenticated internet user name. Audit log fields include timestamp, event type, room, authenticated username, mobile IP, TV IP, protocol, duration and traffic.