Many schools decide to go to the dormitory WiFi network, often starting with a complaint. One night, the dormitory block is out of reach, the transport teacher is woken by telephone, and the switch logs are turned half a day, and it's not clear whether the authentication server is hanging or the bandwidth is full, so that only the entire building can be re-opened. The next day the leader asks who has questions about which level.
Let's start by checking the existing Internet access and billing methods.
Many dormitories think they have little to pay for, but not. One of the most confusing cases we've seen is that there are three: early broadband dialling accounts, later installed wireless feeders, and then a layer of web-based certification. Students often mix equipment with which to use, and they don’t know what to do with their own newspaper. Before building it, at least make this clear: how students access the Internet, where they get the number from, how the passwords change, how many historical accounts the old system has been cleared, how much money they charge for months or traffic. This step may seem to be a bit cumbersome, but it directly determines how much data will be migrated and the number of accounts merged when the new system is online.
The list of equipment is harder to get than it thought.
The second pit is a lack of assets. The system is concerned with who accesses and uses the traffic on which equipment, so you need to know how many points you have access, how many switches, and whether there are any management segments. In practical projects, there is often an old-style access switch on one floor that does not support standard authentication protocols, either it changes equipment or it simply moves away from the system. There are devices for networking, like door closures, surveillance, a cartoon terminal, all of which can be marked in advance as to where they are attached and whether they can go through independent access strategies. We generally recommend that schools first produce a list of points with a location, even if not precise, which is more impressive than the one in their minds.
Cost counts and peaks to be measured
The third is the system's capacity. Some people estimate it directly by multiplying the number of accommodations by two, and then find it totally inadequate because one student has a cell phone, flatboard, notebook, smart soundbox and game machine in his dormitory, which is already over two per person online. More likely is to choose a week to take a test, see how much the late peak request for accreditation is and how high the speed limit can be. The simultaneous identification of average daily traffic per person determines how the monthly price and volume thresholds are set to be reasonable.
The account's source must be figured out.
There is another particularly easy point to ignore: where the student accounts come from. Some schools have teaching and engineering systems that are made by two manufacturers, with their fields not being matched, and new billing systems either imported manually or connected. The most difficult thing we've ever had is that fresh data arrives late in school before they start, causing a large number of students to be unconnected and complaints to reach the network centers during the first two weeks. So it is up to the bottom-up phase to get the numbers when they can be obtained, what format they should be given, who will ensure that these three things are accurate, so it is better to write them into the cooperative responsibility of the construction side rather than wait for the line to get involved.
The output of the status quo should be a list.
In the end, the pre-construction mapping is not about reporting, but about all subsequent decisions. We are used to it as a three-fold deposit: an access mode and account status list, a list of access devices with location, a measured flow and peak record. These three sets together, and the back selection, capacity planning, costing strategy design, and schedule implementation are justified. Without anything, projects presumably will be stuck at one node, while when they are stuck, nobody will remember that the bottoming was never done, and it's just weird systems that work.
Don't think of touching as a factory job.
Finally, the school takes the lead. The manufacturers are willing to do your research, but they often do their research with an optimistic orientation and easily draw you on a programme that they are good at. A true neutral mapping should be first-hand data from the school network centre, where the manufacturer is responsible for giving it only on the basis of those data. This order should not be reversed; otherwise you think you are in the process of selecting it, which is actually chosen.
Don't miss the historical billing data.
Many dormitories are not white paper, and most of them have been covered by a bill from the operator or a trial system from some manufacturer, where historical bills, residual time periods and account numbers are still available, who is using them, and who is it. We've seen the old system go down, but the accounts are still in secret, and the new system goes up to work, so we can figure out what remains of history, which ones are to be moved, which ones to be deactivated, and which ones are simply not cleared. This step is lazy, and the following is mined for the future.