Guest Wi-Fi at a Conference: How to Prepare the Network

A practical plan for preparing guest Wi-Fi: calculating by zones and applications, separating network segments, testing the portal, monitoring, backup and acceptance.

Guest Wi-Fi at a conference should be designed around the real scenario of the day, not the size of the hall or a single speed test. At Aventura, we first map out the zones, attendee flow, devices and applications. Then we separate guest access from registration, team operations and technical systems. After installation, we test the entire user journey under load and test the backup in advance.

A good signal level doesn't yet mean the network will withstand the audience coming in, a coffee break or everyone opening a link from the stage at the same time. A device may see the access point but take a long time to get an address, fail to open the connection page or lose connection when moving between halls. That's why acceptance should cover more than just the radio airwaves. We check switches, authentication services, the internet channel, critical applications and support operations.

This article will help the client set the task for the venue and the network contractor. It does not replace a radio frequency survey and engineering calculation. There is no universal number of users per access point or general speed standard. The result depends on devices, applications, the radio environment, layout, building materials and the overall network design.

Where to start calculating the guest network?

The calculation begins with a demand map by zones and time. For each room, you need to understand how many devices will be there simultaneously, what they will be doing, and which functions cannot be lost. The overall conference attendance provides only top-level context. It does not show the load in the lobby during registration or in the main hall after the QR code is published.

We start with the programme and the movement of people. We mark the entrance, cloakroom, registration, plenary hall, parallel sessions, exhibition area, press zone, speaker rooms, headquarters, and catering areas. For each point, we record the expected density at different periods. Short peaks are especially important, when a large group simultaneously changes halls or opens the same resource.

The next layer is devices. A participant may bring a smartphone and a laptop. The team has tablets, terminals, printers, scanners, and work phones.

Stands may have demonstration devices. The technical team uses cameras, encoders, and remote power-on systems. These groups create different traffic and have different criticality, so they are counted separately.

Then we compile a list of applications. Ordinary website browsing differs from a video call, corporate virtual private network, cloud presentation, or mass download of materials. It is important to consider external dependencies: the domain name system, authentication, cloud storage, and the code distribution service. We check the registration software interface separately.

It is convenient to collect the initial data in the following sequence:

1. Mark all user and service zones on the plan.
2. Link the zones to the hourly programme and audience movement.
3. Describe the types of devices and their capabilities.
4. Divide applications into guest, work, and critical.
5. Note periods of simultaneous activity.
6. Record requirements for latency, loss, and resilience for important services.
7. Identify functions that need a wired primary channel.
8. Specify acceptable degradation and backup for each critical process.

The calculation must explicitly state assumptions. If it is unknown how many guests will bring laptops or use the corporate network via VPN, this is not a reason to substitute a convenient number. The contractor creates scenarios, shows the impact of assumptions, and clarifies them together with the client.

For conference organisation, we link the network map to the programme and the guest journey. This helps to see the peaks: simultaneous registration, transitions between sessions, and work with the speaker's materials.

Coverage and capacity

Coverage answers the question of whether a device can see the network at a given point. Capacity answers a different question: can it get the service it needs under real competition for airtime and resources. A conference needs both. A strong Wi-Fi indicator on a phone confirms only part of the journey.

When assessing coverage, an engineer looks at signal level and quality, interference, access point placement, antennas and surrounding materials. But an empty hall is different from a full one. People, decorations, screens, trusses, partitions and equipment change the radio environment. Adjacent rooms and temporary stand networks also affect the result.

Capacity depends on the entire chain. Devices share the airtime, and access points forward traffic to switches.

Then the controller, gateway, firewall, IP address assignment, domain name system, captive portal and internet link come into play. A bottleneck in any link degrades the user journey.

In the official Cisco Meraki high-density network guide, the calculation is tied to the number and capabilities of client devices, applications and their combined load. This is an important principle for the customer: you should not accept a proposal that explains the design solely by area, number of access points or their rated limit.

More access points do not always mean more available capacity. Without a channel and power plan, equipment starts to interfere with itself more. Channel width is also chosen after analysing the spectrum and client devices. A one-size-fits-all configuration does not work here.

We check the wired part separately. If an access point can transmit more data than its wired port receives, the bottleneck remains. The same applies to equipment power, inter-switch links, the gateway, the firewall and the internet link. A single speed test near the server room does not show the state of these links for a guest in a far hall.

Which network segments are needed at a conference?

Guest, staff and technical traffic must be separated logically and, where justified, physically. These flows have different users, rights, priorities and recovery methods. A shared network for guests, registration, the team and the broadcast creates a single point of failure. Separation helps identify the cause of a failure faster and preserve critical functions.

NIST recommends separating wireless networks with different security profiles. The external guest network must not provide a path into internal systems. For a conference, this principle translates into a clear access matrix.

The guest segment must be isolated from internal addresses. Typically, direct exchange between attendee devices is prohibited unless the programme requires it. Traffic limits are configured so that several active clients do not crowd out the rest. At the same time, the rules must not break approved guest scenarios.

The staff segment is built by roles. A registration employee needs access to the check-in and printing system. A coordinator needs the work service and the schedule.

A venue representative may require other resources. The whole team is not given identical rights just for ease of configuration.

The technical segment protects the broadcast, remote speakers, show control and other critical technical tasks from guest load. Fixed devices sensitive to latency or with high bandwidth are connected by cable where possible. Wi-Fi is left where mobility is needed, and it is tested on the target equipment.

The management segment is needed for administration and monitoring. An attendee or ordinary employee must not be able to open network management panels. Access is granted only to designated specialists with separate authentication and action logging.

We also check edge cases. A stand may have its own router, and a technician may turn on a hotspot on their phone.

A laptop can connect to two environments at once and create an unwanted path. All temporary networks and connection methods are agreed before installation.

Technical brief for the venue and the contractor

A technical brief should describe user scenarios, boundaries of responsibility and the acceptance procedure. Asking for stable Wi-Fi is too general. It does not explain where the network is needed, which devices will arrive, what is critical for them and who fixes a failure on the day of the conference.

From the venue we request a diagram of the existing infrastructure to the extent that can be shared for approval. We need models of key equipment, available bands, internet channels, switches, power, cable routes and technical rooms. It is important to understand which changes are permitted, who carries them out and how the system is returned to its original state after the event.

From the network contractor we need a calculation by zones, devices, applications and time. The document should include assumptions, a traffic flow diagram, an access point placement plan, channel and power settings, segmentation of network perimeters, a list of network services, monitoring and redundancy. Equipment datasheets do not replace this calculation.

In the contract or an appendix we designate the point of demarcation of responsibility. The venue may be responsible for the wired foundation and the primary channel. Another contractor may deploy the temporary wireless network.

The organiser is responsible for scenarios and access to test systems. Without this boundary, teams start looking for the owner only after a problem appears.

We add a list of artefacts to the brief. After configuration we need the as-built diagram, equipment locations, adopted configurations, survey results, a matrix of tested devices, a load report and a support instruction. Access to sensitive data is restricted, but the client must receive enough information for acceptance.

Before approval it is useful to conduct a technical audit of the venue. It helps to check not only the network but also power, routes, access to rooms, installation windows and interaction between technical services.

We publish practical materials about venues, command centres and technical preparation in the Aventura Telegram channel. The channel complements project documentation but does not replace testing of a specific network.

How do you prepare a captive portal page?

A captive portal, or guest network login page, must grant access quickly and avoid collecting unnecessary data. It is tested on the target operating systems and browsers. Reconnection and session termination are tested separately. A certificate error or a constant return to the consent page blocks the guest, even if the screen itself looks neat.

RFC 8952, RFC 8908 and RFC 8910 describe the captive portal architecture, the secure API and the way to tell a device the address of that API. Through it, the device receives the address of the user login page. The connection to the API and the page is protected with TLS. Before authorization, only the services required for connection are opened.

We test the portal on iOS, iPadOS, Android, macOS and Windows if these devices are expected at the event. We test the built-in connection window and a regular browser. Then we check device sleep, roaming between zones and re-login.

Private MAC address randomization and session termination are separate scenarios. The decision to roam between access points is made by the device itself, so different models may behave differently. This is noted in Apple's Wi-Fi roaming guidance.

Before launch, you need to decide what data is required. Federal Law No. 152-FZ requires that the amount of personal data match the processing purpose and not be excessive. If access can be granted without a name, job title, company, phone number and marketing consent, you should not collect the whole set just in case.

We review the data point by point:

1. Identify the personal data operator and the persons who process data on its instructions.
2. Record the purpose of each field.
3. Separate mandatory data from voluntary data.
4. Separate the technical conditions for network access from consent to marketing messages and verify the basis for such consent with a lawyer.
5. Set retention periods and deletion procedures.
6. Check where databases and backups are located.
7. Record transfers to the venue, contractor, messaging service or another system.
8. Publish clear information for the user.
9. Restrict access to portal logs and data.
10. Review contractual instructions and security measures with relevant specialists.

This checklist relates to various operator responsibilities and is not limited to Article 5 of Law No. 152-FZ. The legal basis for processing, database localization, instructions to other persons, informing participants and marketing messages are verified against the current version of the relevant regulations. For a specific conference, the scheme is agreed with a relevant lawyer and the telecom operator.

How do you test the network before the doors open?

The network needs to be tested after final installation on real routes, devices and applications. A single laptop next to an access point does not demonstrate conference readiness. You need a survey, an end-to-end test of services, a team dry run and a load scenario similar to the guest day. This set of checks replicates the attendee journey and the operation of critical functions.

First, a technical check is performed without an audience. The engineer reviews coverage, interference, channels, power and equipment operation. Then the entire chain is tested: connecting to the network, obtaining an address, the domain name system, the captive portal, internet access and access to the agreed resources.

After that, we conduct a dry run. The team follows the attendee journey from the entrance to the halls. In parallel, the working scenarios of registration, the command centre and the technical team are tested. For attendee registration, the wave of simultaneous connections, printing, scanning and access to the external system against the background of guest activity are especially important.

We carry out the testing step by step:

1. We connect the target models of phones, tablets and laptops.
2. We go through the captive portal via the built-in window and the browser.
3. We open the agreed websites, cloud services and VPN.
4. We check transitions between the foyer, halls and service areas.
5. We launch registration and working services against the background of guest traffic.
6. We simulate a group logging in simultaneously and opening a link from the stage.
7. We test applications sensitive to latency and packet loss.
8. We disconnect an individual link in the agreed safe order.
9. We switch to the backup and measure the impact on critical functions.
10. We return to the primary scheme and make sure the services have recovered correctly.

The load test reproduces a mix of actions: connecting, obtaining an address, logging in through the portal and working with the agreed services. In parallel, the team uses registration, while the technical environment supports a critical function. Exact criteria are set for each project.

We test roaming between Wi-Fi access points on the devices that will be used by speakers, staff and the technical team. Apple states directly that the decision to roam is made by the client. The network can assist the device, but it cannot promise equally smooth roaming for all models.

We record all deviations with the zone, time, device, operating system, network and symptom. The wording "Wi-Fi is sometimes bad" does not help the engineer. A workable record looks more precise: "When roaming from Hall 2 to the foyer, the device stays connected, but the guest portal asks for login again."

If the conference has an online audience, we test accessible event streaming and remote contributions separately from guest access. For a hybrid event, the production channel and its backup must have their own plan. Guest Wi-Fi is not considered a broadcast backup just because it has internet access.

Monitoring and support on the day of the event

On the day of the conference, the team monitors the user journey and the state of the entire chain. Monitoring covers radio, the wired network, the connection page and external services. An access point being on does not yet confirm that a guest has access. You need to see address assignment, the opening of the login page and the state of the internet channel.

The monitoring dashboard needs metrics that help you make a decision. The set depends on the architecture, but usually includes connection success, address assignment, domain name system responses, portal operation, the number of clients by zone, radio load, retransmissions, port errors, and the state of gateways and internet channels.

We link monitoring to the programme. A rise in connections before the doors open is expected. A sharp movement of the audience into the sections is also expected. If the system knows the context, the engineer can tell a planned peak from an anomaly and check the right zone faster.

We divide support into three levels:

1. The first line is next to the participants. It knows the network name, the entry path and how to collect a short diagnostic.
2. The network specialist sees the access points, switches, services and internet. They can change the permitted settings according to an approved plan.
3. The venue, the provider or the equipment manufacturer get involved in the event of a problem with the channel, a licence or hardware.

Before the event starts, we approve a single incident channel. The message states the time, zone, network, device, operating system and the observed result. Every change has an author, a reason and the ability to roll back.

Changing power, channels, access rules and the portal at the same time without recording it hinders diagnostics. The team must understand which action helped or created a new failure.

It is convenient to link the work of the technical and organisational leads to the event control centre and radio communication scheme. A network incident gets an owner, a priority level, an escalation channel and a clear message for the team.

Reserve capacity for critical functions

Reserve capacity is tied to specific functions. A second internet connection covers only part of the risks. A second channel is useful if it does not depend on the same section of communication, power and equipment. But even an independent internet connection will not save registration if the only gateway, address service or portal fails.

First, we identify the functions that must continue. Usually we consider registration, payments, command centre communications, display of materials, remote speakers and broadcasting separately. For each function we record the primary path, the backup path, the switchover owner and the acceptable degradation.

Services also need redundancy. The address allocation system, domain name system, gateway, connection page and controller can become a single point of failure. RFC 8952 permits replication of connection page components for resilience and scale. The specific scheme is chosen by engineers after a risk assessment.

Spare access points, switches, power supply units, cables and optical modules are useful only with a ready replacement procedure. You need to know where they are stored, who has access, which configuration will be loaded and how long service restoration will take.

Reserve capacity is not considered ready without a test. The team safely disconnects the selected link, observes the switchover and checks the applications. Then it switches back to the primary path. Errors often appear precisely during the switchback, when some devices remain in the old session or receive an incorrect route.

How do you sign off on guest Wi-Fi?

Sign-off confirms user scenarios, network segmentation, support and redundancy. The main test is carried out before the audience arrives. After any changes at the venue, a short verification route is repeated. The results are recorded in a report, and known limitations are described alongside the conditions under which they occur.

We consider calculating only by area or number of access points to be a red flag. A network cannot be signed off if guest and critical traffic are not separated, if the limitations of key services are unknown, if the contractor does not show monitoring, or if redundancy exists only on paper.

Another red flag is testing without a representative load. An empty venue and a single device provide useful but incomplete information. Meraki guidance recommends validating target applications on representative devices. We add real team routes and the programme scenario to this.

After sign-off, we schedule a window for fixes and retesting. If some requirements cannot be met before the event, the client receives a list of residual risks and makes an informed decision. A limitation can be offset by changing the programme, using a wired connection, running the service in local mode, or providing additional support. It must not be hidden behind the phrase "it should work".

Mistakes that break the network

Most problems start with the wrong model of the task. The team checks whether there is a signal, but does not check the behaviour of users, services and redundancy. Below are the mistakes worth eliminating before the project is approved.

1. Calculating access points by area without a map of people, devices and applications.
2. Taking the nameplate number of clients as the working norm.
3. Adding equipment without a channel and power plan.
4. Failing to account for neighbouring halls, temporary partitions and stand networks.
5. Testing only the internet channel and forgetting about switches, gateways, addresses, the domain name system and the connection page.
6. Putting guests, registration, the team and technical systems in one perimeter.
7. Leaving guests a path into the internal network or to each other when it is not necessary.
8. Connecting the broadcast and remote speakers only via the shared Wi-Fi.
9. Testing the connection page on a single phone.
10. Collecting participant data without a clear purpose and retention period.
11. Calling a channel redundant when it depends on the same input, power supply or gateway.
12. Looking only at the state of the equipment rather than the user journey.
13. Not appointing an owner of the network incident and the right to change settings.
14. Accepting the network based on a single speed test on an empty venue.
15. Not testing the switch back from the backup to the primary path.
16. Leaving temporary networks and rules in place after the conference ends.

Guest Wi-Fi becomes a managed part of the conference when it has input data, separate perimeters, acceptance criteria and an owner on the day of the event. At Aventura we link the technical scheme with the programme, registration and the team's work. This approach reveals dependencies before guests arrive and helps prepare actions for deviations. The behaviour of a particular device still depends on its model and settings.

Sources

• NIST SP 800-153: Guidelines for Securing Wireless Local Area Networks
• RFC 8952: Captive Portal Architecture
• RFC 8908: Captive Portal API
• RFC 8910: Captive-Portal Identification in DHCP and Router Advertisements
• Cisco Meraki: High Density Wi-Fi Deployments
• Apple Platform Deployment: Wi-Fi roaming support
• Federal Law No. 152-FZ, Article 5: Principles of Personal Data Processing