Keeping Crews and Passengers Connected at Sea

K eeping a hundred people connected on a ship is not the same problem as keeping a hundred people connected in a hotel, even though from the outside the captive portal looks identical. On land the constraint is the quality of the link. At sea the constraint is its size and its price, and everybody on board ends up competing for the same slice of it.
This article is about that experience side: who is actually on the network, what each group needs from it, and what the day looks like for the people who have to make it work. The architecture underneath is covered separately in Captive Portal for Vessels with Satellite Connectivity.
Who Is Actually on the Network
A passenger thinks the WiFi is theirs. It is not. On a vessel the network is carrying at least four different kinds of traffic, and they have almost nothing in common except that they use the same satellite link.
* Ship systems: navigation, machinery monitoring, crew voice, the onboard management network. These are not optional and they are not negotiable. If they slow down, the vessel has a problem.
* Crew and officers: they need to work. Emails, ship-to-shore reporting, a VPN into the office, calls to the family. Predictable and reasonably fast, and available at the hours they work.
* Passengers: they are paying for the experience, they expect it to work, and they have no idea what it costs per megabyte. This is the group that will stream a film on a metered link if nothing stops them.
* Guests of the ship, such as day visitors or a chartered party, who need a profile that stops when the day ends.
Nothing on board is entitled to the whole pipe. The work is in deciding who gets what, and in being able to explain that decision to a passenger who is not happy about it.
The Rhythm of a Voyage
Demand on a ship does not follow the clock, it follows the itinerary. In port there are few people on board and the crew is ashore, so the link is quiet and cheap. At sea the ship is full and the crew is working, so the link is busy and expensive. Two hours before arrival everybody wakes up and starts using it at once.
That shape has direct consequences for how you configure the network:
* In port, the passenger profile can be generous. There is bandwidth to give away and it costs nothing to be generous with it while the ship is alongside.
* At sea, the passenger profile is what protects the crew profile. This is when a single guest streaming video can make a colleague's VPN unusable, and it is the moment the complaint arrives at the bridge.
* Before arrival, the crew profile usually matters more than the passenger one, because the officers are closing out reports and uploading the day's paperwork over the same pipe the passengers are using to post photos.
A profile that is correct for one moment of the voyage is wrong for another. The useful question is not "how much bandwidth do we have" but "who needs it most at this point in the day".
Three Profiles, Three Rules
The point of per-user profiles on a ship is not to ration data. It is to make the difference between the three groups explicit, so that the answer to "why is it slow" is a configuration and not an argument.
* The ship-systems profile is guaranteed, not best-effort. It gets a guaranteed minimum that holds even when everything else is saturated. Everything else on the network is allowed to run out before this one does.
* The crew profile is predictable and bounded. Enough to work, with a session length that matches a working day and a data cap that nobody notices. It is also the profile that should be authenticated by name rather than by a voucher, because the person on it is usually responsible for something.
* The passenger profile is metered and honest. It has a daily allowance that is generous enough to feel generous and small enough to stay inside the satellite budget, and it is the only profile whose users are told what the allowance is.
Leaving the minimum as the thing that matters is the mistake that costs money. A maximum stops one guest from taking everything. A guaranteed minimum keeps the ship working when a guest takes everything.
What the Crew Gets Asked
The support load on a vessel is small in volume and very predictable in content. In practice, almost all of it comes down to four questions:
* "Why did it stop?" Usually the allowance ran out, or the session ended, or the link dropped. The answer needs to be visible from the admin side, because nobody on board can diagnose it.
* "How much have I got left?" The remaining data and the remaining time need to be legible to the guest, not just to the operator.
* "Why is it slow?" This is the bandwidth one, and it is the only question that cannot be answered by explaining a limit. It needs a policy: a floor for what matters, a ceiling for what does not.
* "Can I get it working again?" Here the on-premises point becomes an operational advantage. The onboard administrator can re-issue a session, extend an allowance or reset a device from the local console without waiting for anything to come back from shore.
When People Move
A ship is a moving building with moving people. The cabin block has one set of access points, the public decks another, the bridge and the engine room a third. Guests walk, crews change watch, and the vessel itself changes its own radio environment several times a day.
Two behaviours cause most of the friction. The first is a session that does not survive the move from one access point to the next, so a guest who walks from the lounge to their cabin finds the network gone and assumes the ship is broken. The second is a device that connects successfully but cannot reach anything, which is what happens when the device is recognised and re-authenticated while the link is momentarily unavailable.
Both are handled by the same two features: sessions that survive a handover between access points, and devices that are recognised and re-authenticated automatically. Neither is exotic, and both are worth testing on the real vessel rather than in the office, because the access point layout on a ship is not like the access point layout in a building.
What Good Looks Like at the End of the Voyage
At the end of a crossing there are four things worth checking, and none of them require a report:
* The crew profile never hit its ceiling on a working day.
* The passenger profile never exceeded the satellite budget, and nobody had to be cut off mid-connection to keep the ship online.
* The sessions that were supposed to end at the end of the day ended on their own.
* Nobody had to phone a support line in another country to make the network work.
The last one is the honest measure of whether the onboard setup is right. On a vessel, every problem that cannot be solved locally becomes a call, and a call from a moving ship is an expensive call.
Where the Technical Side Is Covered
The experience described above depends on a specific architecture: local authentication, local session management and local policy enforcement, so that the satellite link is treated as a metered pipe rather than as a dependency of the local network. That architecture, its failure modes and how to deploy it across a fleet are covered in Captive Portal for Vessels with Satellite Connectivity.
One operation a day keeps the experience above. Walk the profile definitions, check the allowance actually used against the allowance actually sold, and confirm that the two profiles that must never be starved never were.

No part of this document may be reproduced without prior written permission of WifiGem.