找回密码
 注册

QQ登录

只需一步,快速开始

搜索
网吧三国 首页 IT技术 技术方案 查看内容

大型会议现场的 Wi-Fi 应该如何搭建?

2015-7-20 15:07| 发布者: next| 查看: 5632| 评论: 1

  WiFi网络的部署要远远比一般人想象的复杂,不是说放上几十个AP带宽就自动增加几十倍,恰恰相反,简单放几十个AP带宽会由于AP之间的竞争而迅速使带宽下降为几乎不可用。对于大型活动做WiFi的规划,要按照这几步来 ...

  WiFi网络的部署要远远比一般人想象的复杂,不是说放上几十个AP带宽就自动增加几十倍,恰恰相反,简单放几十个AP带宽会由于AP之间的竞争而迅速使带宽下降为几乎不可用。对于大型活动做WiFi的规划,要按照这几步来做:
  需求调查
  首先从主办方取得场地大小和人数、分布,包括场地平面图,之后现场勘察。对于网络的规模和部署有个大概的估计。一般来讲要为每个人规划至少1个客户端设备,以往经验值可以按0.5个客户端来规划,由于智能手机和平板的普及,未来估计要往1.5~2个客户端靠拢了。手机和笔记本或者平板电脑有可能同时在上网。
  有线带宽估计
  发布会或展会要保证参与者能正常使用比较轻量级的互联网应用,最基本每个设备要分配500kbps的可用带宽。在这个基础上要考虑大型活动的特点。如果是新闻发布会,那么会有很多人上传视频,带宽分配需要重新考虑,每个人至少有一个设备应保证1Mbps带宽。如果是小组讨论会,那么带宽需求就会小得多。下图是一些典型应用通常需要的带宽。
  

  例如:一个产品发布会,有1000人,应用需求是web浏览和一些在线互动,那么每个用户的限速可以为1Mbps,按照15%的同时点击率算(有可能会更高),有线带宽至少要1000*1Mbps*15%=150Mbps。
  组网设计
  在需求和出口带宽确认以后,首先要对整个网络进行评估,要评估整个网络的合理布局和数据规划,组网当然是每个工程师必不可少的重点,大型的会场建议用扁平化的组网设计理念,组网越扁平化故障节点会越少,出问题的概率将减小。
  目前主流的组网设计大多采用AP+云管理平台。让专业的设备干专业的事情,AP要专注无线信号覆盖和处理空口数据(管理帧、控制帧和基本的数据帧);出口设备要承担NAT转化、用户限速等消耗性能的的事情;云管理平台主要起管控的作用,不要把用户数据业务都交给控制器去转发,云管理平台是专门控制和配置AP的;AP直接本地转发业务数据。这样合理化的分配任务,网络的压力有效的分担,网络的运行效率会大大提升。如下组网图:
  

  1-2组网示意图
  

  1-3详细组网图
  我想每个组织者精心设计了这么一个Wi-Fi网络,最后连这个网络有多少人在用都不清楚!都不知道都是什么样的用户在用!所以云管理平台可以有效的进行大数据采集,图形化的页面呈现。
  

  设备选型
  选择适合的设备对整个网络的使用效果起决定性作用,我们经常在高铁站、机场等高密集区域会遇到有信号但连不上,即使连上了也用不了!这些问题实际是设备不适合你的使用场景,如果拿着家用级的设备,放置在高密度的场景,布设再多的点,再怎么优化也是无济于事,因为这是硬伤!!!
  选择适合的产品,再加上专业的优化,让用户体验倍儿爽。那有人问了什么样的产品才合适这种大型会场呢?下面归结几点:
  1、AP是高并发的智能型AP(并发数100+),有专门的智能天线和专门的天线算法处理芯片。例如业界专门做智能AP的优科和康凯科技。
  2、有较强的抗干扰能力,Wi-Fi的干扰大部分来自于同频和邻频干扰,选择专业智能AP可以有效的抗干扰。原因是智能AP并非能力大,同样的终端需要的AP数量少;智能AP的智能主要体现在射频,射频采用专门的芯片控制和天线阵列,采用动态波束成行技术使Wi-Fi的信号和能量有效的投放到需要的地方。
  

  AP规划
  根据如上两点可以算出每个区域的带宽需求,下一步就是AP规划。虽然11g号称54Mbps带宽,实际可用的最多只有25Mbps,也就是说最多能保证50个设备同时浏览网页(在这个情况下由于客户端相互竞争,用户体验已经非常糟糕了,一般打个对折)。11n对于大部分手机只能保证35Mbps,对于笔记本电脑等支持MIMO的可以保证到70Mbps甚至更高。按照这个原则相应地在图上标出每个AP应该覆盖的区域。为了保证通信质量,为了保证比较好的体验,实际上应该控制每个AP接入的设备不超过刚才计算出的数目的一半。
  信道规划
  

  2.4GHz频段,这个频段虽然号称有11个信道(有的国家有13个),实际上只有1,6,11三个互相不重叠的信道可以用。把这三个信道尽可能互不重叠地在上图中覆盖起来(见上图)。有时候如果无法做到不重叠地覆盖,那么还要考虑用扇区天线把覆盖区域细分成几个扇区。
  

  

  5G频段,目前中国已经将5.2G频段放开,之前只有5.8G,这样在5G信道的规划更加自由和宽松,由于2.4G的普及,导致干扰严重,目前5G反而是个避开干扰的好途径,5G的每个信道不重叠,所以每个信道是独立的不像2.4G需要人为的规划,只要避免同频干扰即可见上图。
  

  实地部署无线网络
  信道分配完成后就要实地部署无线网络了(实际上在上述理论工作之前就应该做实地勘探,考虑墙壁和各种反射物的影响)。部署时应该考虑用高增益天线,但是降低每个AP的发射功率,让其覆盖区域基本与规划的区域吻合。注意这里功率不是越大越好,应该让每个AP只覆盖规划好的区域。
  

  有线网络规划部署
  1、11n的AP应该接入千兆上行口。最后出口也要保证足够上下行带宽,上行传现场资料,下行供大家无聊或者需要查相关资料用,国内要考虑多个运营商的出口,这里不多建议大家根据情况自行选择运营商,人数多的场景出口路由器要选择性能较优的。
  2、施工要请专业有经验的工程队伍,网线(好的超五类线或六类)、水晶头的质量和制作工艺尤为重要。俗话说三分设备七分安装。
  SSID的分配:
  实际上除了少数情况用户实现已经分配好座位,大部分情况没有办法把用户固定在某个AP上,所以更常见的做法是所有AP设置同一个SSID。
  用户认证和带宽控制
  为了防止恶意蹭网,最好能对用户做基本的认证,比如凭入场券领取账号名和密码。同时对于每个账号要限制带宽使用,这也会涉及到用户认证和带宽管理,通常需要额外的服务器来处理。
  拒绝弱信号客户端接入
  通过AP测量到的客户端信号强度给客户端分配合适的AP,如果某个AP能接收到客户端信号,但是强度太弱不足以支持某个门限速率,就拒绝客户端从这个AP的接入,防止这个猪一样的队友占有过多带宽(他传1bit时间你能传54bit!),用最低速率把整个AP性能拖垮。
  

  频谱导航
  将大部分同时具有802.11a/g或者802.11a/g/n的用户从2.4Ghz的频段移动到5Ghz去,这一点可以可以大大降低无线信道的拥塞程度,从而极大地改善情况。
  

  至此一个较简单的WiFi网络才部署完毕!
  常见的问题:
  网络不好用、网页打不开、看视频卡、有信号连不上,这是经常听到用户的抱怨,1000人的会场出现这问题原因无非是:
  • AP抗干扰能力不强(AP接入能力有限,只能多放AP,放多了又干扰!)
  • AP数目不足(应该20个左右,至少15个)
  • AP规划不合理(太多包碰撞,同频干扰严重)
  • 或者AP崩溃(每个AP接入用户太多)
  • 或者AP控制器崩溃(无法同时响应这么多AP接入/断开请求)
  • 或者认证服务器崩溃(无法同时认证这么多用户)
  • 或者出口带宽太窄(按我的估计需要至少200MB上行,200MB下行)
  • 管理混乱(没有控制每个客户端设备流量)。
  除了干扰之外,还有几个显著的问题。
  1. 蹭网:让有价值的用户有效的接入,把虚假用户拒之门外!如果设计不好,这几乎是最容易干扰无线网性能的一个行为。道理很简单:你的发布会上只有二百人在用你的无线网看你的演示,而还有六百人不明真相的围观者在蹭你的无线网刷微博看土豆连VPN下BT……,结果是大家都不能用!?技术解决办法也很简单:加入基本的密码认证,每个报名参加者发一个密码(甚至可以是公用账号),这就可以在很大程度上避免蹭网的问题。然后就是切断因特网连接或者对因特网限制访问特定站点或者限速,这样对于大多数不明真相的群众来说,即使蹭到了网也没有多大意义,这可以把你的无线网最大程度地解放出来。
  2. 组播:类似这样一个人做发布会,数百人围观的事情,最好的是用组播应用向外发布,如果使用单播方式很容易造成网络拥塞,不仅无线网受不了,服务器、防火墙的连接数也很容易满员。
  3. 关闭低速率的信标信号:你并不知道,在你的发布会上,距离你一二百米之外的人连在你的无线网上在用尽全力的打开网页打开视频!为什么呢?因为现在的接入点发射功率都不低,2.4Ghz覆盖范围大,发布会现场往往又是空旷的结构,缺乏钢筋混凝土这种有效的信号阻挡,所以即使距离较远的地方也能以较低的速率进行覆盖,这么远的用户即使接入也是低速率接入,把整个信道搞到瘫痪。解决办法是关闭低速率的信标信号,比如802.11g的只发送54Mbps、48Mbps、36Mbps,其他的速率一律不再发送。什么?再远点的人怎么办?再远的您就往近靠靠吧!

鲜花
1

握手

雷人

路过
1

鸡蛋

刚表态过的朋友 (2 人)

发表评论

最新评论

引用 赵子龙 2015-7-22 16:58
转载此文章请标明来源:前瞻网。

查看全部评论(1)

小黑屋|手机版|Archiver|联系我们|网吧三国

GMT+8, 2024-3-29 17:50 , Processed in 0.031689 second(s), 8 queries , Gzip On, MemCache On.

Powered by Discuz! X3.4

© 2001-2013 Comsenz Inc.

返回顶部