Cross-Room Casting & Privacy Leak Risks: Dual Protection Solution of All-Optical Network + Casting Reflector Under MPS Order No.176

A guest streaming private video in one room suddenly sees the output show up on the TV in another room; when an internal proposal is displayed in an enterprise meeting room, screens in nearby areas may receive unintended casting requests. Accidental cross-room casting is not just an embarrassing social mishap. It can trigger privacy disclosure, leakage of confidential corporate documents, customer complaints and operational disputes.

This issue is often mistakenly attributed to user misoperation. In essence, it stems from unclear network zoning, over-broad device discovery scope and inadequate casting permission control. Since MPS Order No.176, Measures for Cyberspace Security Supervisory Inspection by Public Security Organs, came into force on October 1, 2026, network service providers must strengthen network security governance, personal information management and mandatory log retention. For hotel guest rooms, enterprise reception zones, staff dormitories and meeting spaces, casting services must be incorporated into the overall cybersecurity framework instead of prioritising convenience alone.

I. Root Causes of Cross-Room Casting: More Than Wrong TV Selection

1. Devices across multiple rooms are discoverable on an unsegmented network
   Mobile casting works by first discovering available display devices before establishing a session. If mobile terminals and TVs share an inadequately isolated network, multicast discovery packets can be received by unintended zones. Users may browse TVs belonging to other rooms and trigger accidental casting.

To enable casting smoothly, many networks loosen multicast forwarding and cross-domain access rules. While this simplifies device discovery, it expands the attack and exposure surface. Such configurations are unsuitable for venues with clear physical boundaries such as hotel rooms and corporate meeting rooms.

1. Full network isolation may break normal casting functionality
   Isolating the guest Wi-Fi network from the IoT TV network can block unwanted intercommunication, yet many casting protocols rely on multicast discovery. Strict isolation often results in users being unable to locate target TVs.

A balanced approach is required. The network domains should remain logically separated, while a controlled mechanism handles authorised device discovery and casting forwarding. Simply opening up cross-VLAN traffic or fully blocking all discovery packets both create drawbacks.

1. Lack of binding rules and audit trails hinders incident investigation
   Even without cross-room leakage, users may select the wrong display endpoint without device binding. Without session logging, administrators cannot quickly trace connection timestamps, senders and receivers once an incident occurs.

Secure casting covers pre-connection discovery control, runtime permission enforcement and forensic records for abnormal events.

II. All-Optical Network + Casting Reflector: Dual-Layer Defence at Network and Application Levels

1. All-optical network zoning builds a solid security foundation
   Built on AINOPOL all-optical infrastructure, the solution divides office networks, visitor networks, TV IoT networks and other service domains via VLAN planning and access control policies to block unnecessary cross-domain traffic.

For hotels, guest mobile networks, TV IoT networks and management networks are assigned to independent VLANs. For enterprise parks, staff networks, meeting device networks and management planes are segmented separately. Meeting room TVs and visitor terminals are prevented from gaining access to core business systems merely to support casting.

All-optical cabling provides high-capacity multi-service bearer, but fibre alone does not equal isolation. Security boundaries are realised through coordinated VLAN design, ACL rules and device configuration.

1. Casting reflector proxy forwarding for controlled discovery
   The AINOPOL multi-protocol cross-VLAN casting reflector deploys in bypass mode. It avoids fully bridging guest networks, TV IoT networks and management networks. Using proxy forwarding and address rewriting, it processes casting discovery and session establishment.

The core principle: multicast discovery packets are not broadcast across VLANs. The reflector centrally manages discovery requests and forwarding, so mobile phones only discover TVs within their authorised scope rather than exposing all casting endpoints across the entire venue.

Compared with unrestricted cross-VLAN multicast, this model strictly limits discovery boundaries and reduces overexposure of display devices.

1. QR binding and session management lower mis-casting risks
   Each TV displays a QR code containing the room ID and a time-limited Token on its standby screen, valid for 5 minutes. After connecting to guest Wi-Fi and completing SMS Portal authentication, users scan the QR code to bind their mobile device to the designated TV before starting casting.

The gateway enforces casting rules based on binding relationships, so only the matched TV appears on the casting list. Once casting stops, the session is automatically terminated, ports are released, and audit records are generated to eliminate stale hanging sessions.

The reflector supports mainstream protocols including AirPlay, DLNA and Miracast. Huawei Cast+ is currently unsupported, so protocol compatibility verification is required before deployment according to end-user mobile devices.

III. Real-Name Authentication and Session Auditing for Forensic Traceability

For public internet service scenarios, AINOPOL combines Portal SMS authentication, QR binding and casting session auditing to record the full connection lifecycle, providing evidence for troubleshooting accidental casting incidents.

Administrators can retrieve records including sender, receiver and connection timestamp, and correlate casting logs with other network records for investigation. This removes reliance on user recollection and manual inspection of every terminal.

Important reminder: casting session logs support incident reconstruction, but they do not replace other statutorily required cybersecurity operation logs. Retention periods, data fields, storage and access permissions must comply with local regulatory requirements. Real-name authentication alone cannot satisfy all compliance obligations under MPS Order No.176.

Cross-room casting risks cannot be mitigated merely by user prompts. Effective protection requires controls spanning network boundaries, device discovery, casting permissions and audit management.

Leveraging AINOPOL’s Communication-Security Integrated all-optical solution that unifies transmission, audio-video services and embedded security, the casting reflector delivers managed discovery, QR binding and session tracking. The design combines network isolation and application-level casting governance.

Suitable for hotel guest rooms, corporate meeting rooms, staff apartments and training venues, the solution adapts to existing network conditions. It preserves user experience while suppressing cross-room casting and privacy leakage, simplifying O&M and supporting compliance with cybersecurity supervision requirements.

FAQ

Q: Does the casting reflector require TV replacement or rewiring?
A: No. The casting reflector is an embedded software module of the Dream Gateway. It can be enabled with one click in the gateway web console under Value-Added Apps, by assigning corresponding ports or VLANs for each network domain. Existing TVs and cabling remain unchanged, and deployment has minimal disruption to daily hotel operations.

Q: How long must casting logs be retained under MPS Order No.176?
A: No less than 6 months (180 days). Casting session logs are classified as cybersecurity operation logs. Mandatory fields include sender endpoint, display endpoint, protocol type, start time, end time and data volume. The default retention cycle is 180 days, and logs can be searched and exported by room number, time window or real-name account.

Q: Are casting logs and internet access logs stored separately?
A: The AINOPOL Dream Gateway stores casting logs and internet access logs within the same unified system, eliminating the need for two independent audit platforms. Records are categorised and archived, supporting separate filtering for casting behaviour or surfing behaviour, or combined export for full compliance reports. Equipment operation logs, link logs and security operation logs required by MPS Order No.176 are retained on the same platform and can be cross-referenced with authentication and casting records.