Guestroom Control Network Segmentation: VLAN and Port Plan

Guestroom control devices belong on their own VLAN, separate from guest Wi-Fi, IPTV, voice and back-office traffic, with a default-deny firewall rule set that opens only the named ports between room controllers, the control server, the BMS and the PMS interface. One building-services VLAN per floor or riser, sized for roughly twice the installed device count, keeps broadcast traffic small and lets a fault be isolated to a single switch stack.

This engineering note is written by Singapore-based AV and IPTV integrator Prestige Solutions for hotel facility managers and IT teams preparing the network for a smart room control installation. It covers which devices actually need an IP address, how to size and number the VLANs, the port matrix to hand to the firewall administrator, and the tests that prove the segmentation before rooms are handed over. Port numbers are the registered defaults for each protocol as of 2026; the controller vendor's network guide decides what a specific product uses.

Which guestroom control devices need an IP address at all?

Usually only one or two per room. The room control unit (RCU) or gateway is the IP endpoint; keypads, thermostats, door contacts, occupancy sensors and dimmers normally sit behind it on a field bus such as RS-485, KNX twisted pair or DALI, or on a low-power radio such as Zigbee (IEEE 802.15.4, 2.4 GHz).

That distinction sets the scale of the network design. A 300-room hotel may have more than 3,000 control devices in total but only 300 to 600 IP addresses to plan. Count IP endpoints from the vendor's device schedule, not from the room drawings, and record for each one whether it is wired Ethernet, PoE-powered or wireless.

How many VLANs does a guestroom control system need?

Plan three at minimum: one for in-room controllers, one for the servers that manage them, and one for device management such as switch and gateway administration. Guest Wi-Fi, IPTV, voice and back-office remain on their own existing VLANs and never share a subnet with controllers.

IEEE 802.1Q provides VLAN IDs 1 to 4094, so the limit is administrative, not technical. The practical question is whether the controller VLAN should be one flat network or one per floor. A single flat VLAN is simpler to configure and suits small properties. Per-floor or per-riser VLANs suit larger ones, for three reasons: broadcast and discovery traffic stays local, a loop or a misbehaving device affects one floor, and the VLAN number tells the engineer where the device is.

A worked example for sizing: a floor of 25 rooms with two IP control endpoints per room has 50 devices. A /26 subnet gives 62 usable addresses, which leaves little room; a /25 gives 126 and covers a later addition of networked thermostats or a second gateway per suite. Twelve such floors use twelve /25 subnets, which fit inside a single /21 reserved for building services. Sizing for about twice the day-one count avoids renumbering during the first refurbishment.

Which ports must be open between the segments?

Only the protocol ports the installed system uses, in the direction it uses them. Start from a default-deny rule between every pair of VLANs and add one line per documented flow. The table lists the registered default ports for the protocols most often found in guestroom control; ask the vendor to confirm each line and delete the ones that do not apply.

Two of these lines cause most commissioning delays. BACnet/IP discovery relies on broadcast, so a BMS head-end on a different subnet from the controllers will see nothing until a BACnet Broadcast Management Device is configured on each side. KNXnet/IP routing relies on multicast, so the switches need IGMP snooping with a querier present on that VLAN, or the multicast will either flood every port or be dropped. Both are design decisions to settle before the switches are configured, not faults to chase on site. The division of responsibility between systems is covered in the scope guide for guestroom control integration with BMS and PMS.

Should room controllers ever share the guest network?

No. Guest devices are untrusted, and building protocols such as BACnet/IP and Modbus TCP were designed for closed networks and carry no authentication of their own in their basic form. A controller reachable from a guest laptop can be read, and in many cases written to, by anyone who knows the protocol.

The same reasoning applies to the room itself. The wall outlet behind the minibar or the TV is physically accessible to a guest for the length of a stay. Three switch-level measures limit what that outlet can do:

• Assign the VLAN at the port, not at the device. An access port fixed to the control VLAN for the RCU and a separate port fixed to the IPTV VLAN for the TV means a swapped cable gives the wrong device no service.
• Limit MAC addresses per port. Port security set to a single learned address stops an unmanaged switch or a laptop from being added behind the controller's outlet.
• Use IEEE 802.1X or MAC authentication where the controllers support it. Many embedded controllers do not offer an 802.1X supplicant, so confirm before writing it into the specification.

Wireless field devices need a different kind of separation. Zigbee shares the 2.4 GHz band with Wi-Fi. Zigbee channels 15, 20, 25 and 26 sit in the gaps between Wi-Fi channels 1, 6 and 11, so agree the Zigbee channel with the Wi-Fi designer during the radio survey instead of leaving both systems on automatic selection.

What should still work when the segment loses its uplink?

Everything the guest touches. Segmentation changes where a failure stops, so the design should state what each room does on its own. Local keypad scenes, thermostat control and the door-open welcome scene should run from the RCU without the server; central functions such as check-in pre-cooling, energy reports and PMS-driven setback will pause until the link returns.

Write that expected behaviour next to each VLAN in the design document, because it becomes the pass criterion for the isolation test below. The detailed behaviour by failure type is listed in the failure mode reference for smart room control network loss.

Which tests prove the segmentation before handover?

Run the tests from the places an intruder or a fault would start: a guest device, a room outlet and a disconnected uplink. A firewall rule set that has only been reviewed on paper is not yet verified.

Keep the results with the as-built documents: the VLAN table, the address plan, the port matrix as finally implemented and the switch port schedule by room number. The maintenance team will need all four the first time a controller is replaced. Other guestroom systems that share the same risers and switches are listed on the Prestige Solutions home page.

FAQ

Who should own the guestroom control VLAN, IT or engineering?

The hotel IT team normally owns the switches, VLANs and firewall, and the engineering department owns the controllers and their configuration. Record that split in the handover document together with a named contact for each side, so a fault call does not stall while both teams assume the other is responsible.

Can the control vendor have remote access for support?

Yes, through a controlled path. A VPN or remote-access gateway that terminates on the management VLAN, uses named individual accounts, is enabled per support session and is logged gives the vendor what is needed without a permanent opening from the internet to the controllers.

Does a cloud-managed room control platform change the design?

It adds one outbound rule. The on-site gateway or server needs HTTPS access to the vendor's documented cloud addresses, and nothing inbound. The controllers themselves should still talk only to the local gateway, so that rooms keep working when the internet link is down.

Recommended next step

Contact Prestige Solutions to review your site drawings and current operating pattern. Call +65 8010 2337 or +65 9825 8218, message us on WhatsApp (+65 8010 2337), or email sales@prestigesolutions.com.sg. You can also browse the full product range before the site walk.