当前位置:首页 > 网络
  • 小白必读:计算机网络入门

    很久很久之前,你不与任何其他电脑相连接,孤苦伶仃。 直到有一天,你希望与另一台电脑 B 建立通信,于是你们各开了一个网口,用一根网线连接了起来。 用一根网线连接起来怎么就能"通信"了呢?我可以给你讲 IO、讲中断、讲缓冲区,但这不是研究网络时该关心的问题。 第一层 首先,你要给所有的连接到交换机的设备,都起个名字。原来你们叫 ABCD,但现在需要一个更专业的,全局唯一的名字作为标识,你把这个更高端的名字称为 MAC 地址。 这样,A 在发送数据包给 B 时,只要在头部拼接一个这样结构的数据,就可以了。 B 在收到数据包后,根据头部的目标 MAC 地址信息,判断这个数据包的确是发给自己的,于是便收下。 第二层 交换机内部维护一张 MAC 地址表,记录着每一个 MAC 地址的设备,连接在其哪一个端口上。 MAC 地址 端口 bb-bb-bb-bb-bb-bb 1 cc-cc-cc-cc-cc-cc 3 aa-aa-aa-aa-aa-aa 4 dd-dd-dd-dd-dd-dd 5 你给这个通过这样传输方式而组成的小范围的网络,叫做以太网。 假如在 MAC 地址表为空时,你给 B 发送了如下数据 由于这个包从端口 4 进入的交换机,所以此时交换机就可以在 MAC地址表记录第一条数据: 交换机看目标 MAC 地址(bb-bb-bb-bb-bb-bb)在地址表中并没有映射关系,于是将此包发给了所有端口,也即发给了所有机器。 MAC:bb-bb-bb-bb-bb-bb 端口:1 但是你要注意,上面那根红色的线,最终在 MAC 地址表中可不是一条记录呀,而是要把 EFGH 这四台机器与该端口(端口6)的映射全部记录在表中。 左边的交换机 右边的交换机 MAC 地址 端口 bb-bb-bb-bb-bb-bb 1 cc-cc-cc-cc-cc-cc 1 aa-aa-aa-aa-aa-aa 1 dd-dd-dd-dd-dd-dd 1 ee-ee-ee-ee-ee-ee 2 ff-ff-ff-ff-ff-ff 3 gg-gg-gg-gg-gg-gg 4 hh-hh-hh-hh-hh-hh 6 但很遗憾,人是贪婪的动物,很快,电脑的数量就发展到几千、几万、几十万。 交换机已经无法记录如此庞大的映射关系了。 那我可不可以让那根红色的网线,接入一个新的设备,这个设备就跟电脑一样有自己独立的 MAC 地址,而且同时还能帮我把数据包做一次转发呢? 好了,现在交换机的 MAC 地址表中,只需要多出一条 MAC 地址 ABAB 与其端口的映射关系,就可以成功把数据包转交给路由器了,这条搞定。 不难想到这样一个点子,假如电脑 C 和 D 的 MAC 地址拥有共同的前缀,比如分别是 D 的 MAC 地址:FFFF-FFFF-DDDD 这样是否可行呢?答案是否定的。 00-16-EA-AE-3C-40 那如果你希望像上面那样根据目标MAC地址的特地格式来转发(FFFF-FFFF-?开头的),那你就需要要求某一子网下统统买一个厂商制造的设备,或者你就需要要求厂商在生产网络设备烧录 MAC 地址时,提前按照你规划好的子网结构来定 MAC 地址,并且日后这个网络的结构都不能轻易改变。 于是你发明了一个新的地址,给每一台机器一个 32 位的编号,如: 你觉得有些不清晰,于是把它分成四个部分,中间用点相连。 你还觉得不清晰,于是把它转换成 10 进制。 最后你给了这个地址一个响亮的名字,IP 地址。现在每一台电脑,同时有自己的 MAC 地址,又有自己的 IP 地址,只不过 IP 地址是软件层面上的,可以随时修改,MAC 地址一般是无法修改的。 那交给路由器之后,路由器又是怎么把数据包准确转发给指定设备的呢? 我们先给上面的组网方式中的每一台设备,加上自己的 IP 地址 现在两个设备之间传输,除了加上数据链路层的头部之外,还要再增加一个网络层的头部。 A ~ 路由器这段的包如下: 路由器到 C 这段的包如下: 好了,上面说的两种情况(A->B,A->C),相信细心的读者应该会有不少疑问,下面我们一个个来展开。 A 给 C 发数据包,怎么知道是否要通过路由器转发呢? 如果源 IP 与目的 IP 处于一个子网,直接将包通过交换机发出去。 好,那现在只需要解决,什么叫处于一个子网就好了。 这两个是我们人为规定的,即我们想表示,对于 192.168.0.1 来说: 那对于计算机来说,怎么表达这个意思呢?于是人们发明了子网掩码的概念 这表示,将源 IP 与目的 IP 分别同这个子网掩码进行与运算,相等则是在一个子网,不相等就是在不同子网,就这么简单。 A电脑:192.168.0.1 & 255.255.255.0 = 192.168.0.0 B电脑:192.168.0.2 & 255.255.255.0 = 192.168.0.0 C电脑:192.168.1.1 & 255.255.255.0 = 192.168.1.0 D电脑:192.168.1.2 & 255.255.255.0 = 192.168.1.0 A 如何知道,哪个设备是路由器? 上一步 A 通过是否与 C 在同一个子网内,判断出自己应该把包发给路由器,那路由器的 IP 是多少呢? 对 A 来说,A 只能直接把包发给同处于一个子网下的某个 IP 上,所以发给路由器还是发给某个电脑,对 A 来说也不关心,只要这个设备有个 IP 地址就行。 路由器如何知道C在哪里? 现在 A 要给 C 发数据包,已经可以成功发到路由器这里了,最后一个问题就是,路由器怎么知道,收到的这个数据包,该从自己的哪个端口出去,才能直接(或间接)地最终到达目的地 C 呢。 这个表就叫路由表。 不同于 MAC 地址表的是,路由表并不是一对一这种明确关系,我们下面看一个路由表的结构。 目的地址 子网掩码 下一跳 端口 192.168.0.0 255.255.255.0 0 192.168.0.254 255.255.255.255 0 192.168.1.0 255.255.255.0 1 192.168.1.254 255.255.255.255 1 这就很好理解了,路由表就表示,192.168.0.xxx 这个子网下的,都转发到 0 号端口,192.168.1.xxx 这个子网下的,都转发到 1 号端口。下一跳列还没有值,我们先不管 答案:arp 答案很简单,在网络层,我需要把 IP 地址对应的 MAC 地址找到,也就是通过某种方式,找到 192.168.0.2 对应的 MAC 地址 BBBB。 一开始的时候这个表是空的,电脑 A 为了知道电脑 B(192.168.0.2)的 MAC 地址,将会广播一条 arp 请求,B 收到请求后,带上自己的 MAC 地址给 A 一个响应。此时 A 便更新了自己的 arp 表。 好了,总结一下,到目前为止就几条规则 电脑视角: 交换机视角: 路由器视角: 如果你嗅觉足够敏锐,你应该可以感受到下面这句话: 涉及到的三张表分别是 这三张表是怎么来的 知道了以上这些,目前网络上两个节点是如何发送数据包的这个过程,就完全可以解释通了! 也就是说找来找去,最终必须能映射到一个端口号,然后从这个端口号把数据包发出去。 目的地址 下一跳 端口 192.168.0.0/24 0 192.168.0.254/32 0 192.168.1.0/24 1 192.168.1.254/32 1 192.168.2.0/24 192.168.100.5 192.168.100.0/24 2 192.168.100.4/32 2 思考一分钟... 详细过程动画描述: 详细过程文字描述: 2. A 通过 ARP 找到 默认网关 192.168.0.254 的 MAC 地址。 5. 数据包来到了路由器 1,发现其目标 IP 地址是 192.168.2.2,查看其路由表,发现了下一跳的地址是 192.168.100.5 7. 此时路由器 2 收到了数据包,看到其目的地址是 192.168.2.2,查询其路由表,匹配到端口号为 1,准备从 1 号口把数据包送出去。 9. 交换机 3 收到了数据包,发现目的 MAC 地址为 FFFF,查询其 MAC 地址表,发现应该从其 6 号端口出去,于是从 6 号端口把数据包发出去。 更详细且精准的过程: 至此,经过物理层、数据链路层、网络层这前三层的协议,以及根据这些协议设计的各种网络设备(网线、集线器、交换机、路由器),理论上只要拥有对方的 IP 地址,就已经将地球上任意位置的两个节点连通了。 —— 全文完 ——

    时间:2021-01-15 关键词: 网络 计算机

  • Wi-Fi比5G连接成本更高?

    本文来源:网优雇佣军 这似乎有点颠覆常识! 近日,爱立信发布《 5G and Wi-Fi》白皮书,指出未来5G和Wi-Fi6两大无线技术将在室内连接上共同发挥重要作用,并比较了两者的优缺点。 值得关注的是,该白皮书还举例比较了Wi-Fi 和蜂窝网络的TCO,指出Wi-Fi连接成本高于蜂窝网络,并总结到“5G将在未来的连接场景中扮演更重要的角色”。 各有优点 5G的优点: 1)工作于运营商授权频谱,可提供更出色的可靠性和更好的可预测性,能满足关键型任务的通信需求。 2)5G支持eMBB、mMTC(大规模连接型物联网)、Critical IoT(关键型任务物联网)和工业TSN,支持的用例比Wi-Fi更广泛。 3)5G可基于单一网络支持端到端的QoS区分。 4)5G有着严格的设备互操作性测试和认证过程。 5)5G也可通过非授权频谱(NR-U)来卸载非关键型任务的流量。 6)5G支持完全的移动性,可提供广域覆盖和本地覆盖,而Wi-Fi 6仅限于本地局域覆盖,且只能支持有限的移动性。 7)5G具有涵盖完整系统架构的端到端规范,而Wi-Fi主要限于第1层和第2层。 8)5G支持低、中、高频段,可通过低频段和中频段来实现良好的覆盖,也可通过毫米波高频段来补充容量需求,以及实现更低的空口时延和更高精度的室内定位,但Wi-Fi 6仅限于支持中频段,且支持带宽受限。 9)与Wi-Fi 6不同,5G提供端到端的安全性和全局身份管理。 Wi-Fi 6的优点 1)Wi-Fi 6调制解调器比5G调制解调器更便宜。 2)部署更容易 3)某些操作系统(比如 iOS 13)更喜欢Wi-Fi,因为手机总是优先自动连接附近的Wi-Fi网络,而不是蜂窝网络。 4)Wi-Fi 6(包括NR-U)工作于非授权频谱,不受频谱授权限制,人人都可用。 TCO对比 文中以一个仓库的无线网络部署为例,对比了Wi-Fi 5与4G网络的TCO成本。 该仓库面积为25万平方英尺,共连接1000个设备(平均吞吐量为80Mbps),主要用例为基于低时延、大带宽网络使能智能机器人自动拣货和搬运。 采用Wi-Fi 5技术,该仓库需部署160个Wi-Fi AP、10个PoE交换机;而采用4G技术,该仓库需部署40个Small Cells以及核心网相关设备,加上安装、布线,以及后期产品支持、服务和现场维护等,该报告指出,Wi-Fi每平方英尺的总成本比蜂窝网络高22%。 除了成本优势,文中还指出,两种技术带来的附加值也很重要。由于5G网络比Wi-Fi具备更高的可靠性,更广的覆盖能力,更好的移动性,且支持更多用例,因此未来能给企业带来更多的价值。 不难看出,文中尽管只是比较Wi-Fi 5和4G的连接成本,但似乎在暗示随着技术的普及,未来5G连接成本可能会与Wi-Fi持平,甚至更低,且运营商和企业能从5G获得更多的收益。 一直以来,蜂窝网络与Wi-Fi之争没有停息。随着5G时代室内场景越来越重要,这场技术之争必将更加激烈。从该白皮书看,爱立信显然更看好5G。不过,未来到底将如何发展,只能让市场和时间来给出答案了。 本文参考来源: 5G and Wi-Fi: Charting a path toward superior indoor connectivity,Ericsson ~END~ 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2021-01-12 关键词: Wi-Fi 5G 网络

  • 室内应用是5G业务的主战场,如何轻松搞定?

    室内应用是5G业务的主战场,据预测5G时代约85%的业务流量将发生在室内场景,室内覆盖的好坏直接关系到5G室内应用的体验,今天我们聊一聊5G时代的室内覆盖怎么建设。 我们先从最简单的开始,比如说覆盖简单的居民楼。 有小伙伴这样想,在房子里面专门部署一个基站。可以吗?这种办法当然可以,但……太费钱! 那么有没有更省钱的办法? 可不可以用室外的基站来覆盖这个房子,这种方式更节省成本,也能满足用户的需要。 这种方式就是室外基站覆盖室内,顾名思义是通过室外的基站来兼顾对室内的覆盖。在5G网络建设的初期,这种方案由于网络建设快,投资成本低,受到运营商的青睐。 那对于高楼大厦的室内覆盖,是不是也可以直接用这种方式呢? 4G宏站的无源天线只有一个波束,水平波瓣很宽,垂直波瓣比较窄,通过下倾角来满足水平覆盖,导致高层建筑的信号较差,无法满足高楼覆盖的要求。 5G引入Massive MIMO技术,宏站具有了波束赋形能力,由于运营商普遍采用水平7/8个波束配置,虽然水平方向覆盖达到了最优,但是在垂直方向覆盖有限,还是无法满足高楼覆盖需求。此外高楼大厦复杂的墙体结构会削弱室外基站信号。5G时代,容量、时延、可靠性有了更高的要求,室外基站覆盖室内方案遇到高楼大厦就显得力不从心。 那么室外基站对于高楼大厦是不是彻底无能为力了呢? 简单的室外基站覆盖当然不行了。中兴通讯针对这种问题,推出了一种SSB 1+X方案,通过创新型立体覆盖来提升宏站对高层楼宇覆盖能力,关于SSB 1+X方案的介绍,请参见: SSB 1+X:不管你站得多高,都让你的手机信号满满! 除此之外,对于大型楼宇我们还有没有其他的覆盖办法? 机智的小伙伴可能会想,既然信号被墙壁削弱了,那我们就把信号引进来,问题不就解决了。 怎么引过来呢?我们知道无线信号是由天线发送接收的,如果我们在室内部署上天线,信号不就进来了吗。 这实际上就是DAS(Distributed Antenna System,分布式天线系统)的思路,通过耦合器、功分器、合路器等无源器件对RRU的射频信号进行分路传输,将信号尽可能平均分配至每一副天线上,从而实现室内信号的均匀分布覆盖。 其实DAS方式在2G/3G中已经大量使用,技术的成熟度也高,但到了5G时代,面对5G大容量需求,却显得有些捉襟见肘。可能有小伙伴不以为然,认为增加容量不就是多加一些天线的事情吗?原先一副天线不能满足的,现在再增加一副天线不就解决问题了吗? 想法是美好的,但现实却是残酷的!这种改造实际建设时成本比较高,难度比较大。 那么有没有对现有DAS系统不用改动或者少改动就可以提高网络容量的方法?我们既要马儿跑,又要马儿不吃草!然而还真有这么一种改造思路,这就是中兴通讯推出的多通道联合收发方案。 这种思路也不是凭空而来,我们举个工作中的例子。 关注我们,带你了解通信世界的精彩!

    时间:2021-01-08 关键词: 5G 网络

  • “问诊”老旧线路,烽火助力国家电网通信网络“体检”

    OPGW光缆是电力行业专用特种通信光缆,是电力通信骨干网的主要组成部分,是电力通信网中综合承载继电保护、安稳控制、调度自动化以及数据网等的重要业务通道。随着智慧城市、光网城市、坚强智能电网及泛在物联网的大规模推进,OPGW光缆市场需求逐年增加,全国2019年需求建设量十余万公里。早期投运的OPGW光缆使用已经接近20年,“纤芯劣化”隐患逐步增多,对电力通信网络的正常运行造成影响。 早在2018年,国网公司即邀请烽火通信合作开展“线路光缆性能研究”的全面工作。该项目旨在通过对综合光纤断点镜面、OPGW光缆的原材料性能、制造工艺、物理性能、施工条件、光缆受力等各种因素进行立体化剖析,获取在线OPGW光缆的各项性能指标,全面了解线路运行情况。 故障线路样品检测分析 在国网公司全面支持下,烽火开始对某线路故障OPGW光缆样品进行了检测及分析研究工作。该线路全长超过1千公里,跨越华东、华中三个省份,于2003年建成投运,是我国最早一批的500KV超高压OPGW项目。烽火项目组成员实地考察了光缆运行环境,采集多个光缆样品,使用专业仪表对断纤端面放大观察,进行了各种性能检测、材料检测和制造工艺探讨等多项工作。历经4个月,烽火通信凭借深厚的OPGW光缆技术和检测能力,通过对原材料、光缆机械性能及光纤抗张强度等关键指标数据反复比对,结合断面理论对断纤面的分析,出具了故障OPGW光缆检测及分析报告,对光缆故障原因进行了详尽的分析。 在线实时线路性能监测研究 故障光缆样品的实验室解析是理论推断分析的结果,各项数据是否符合在线光缆情况,需要在实际运行状态下得到验证,以帮助电力运维部门更好的发现、解决、避免线路故障。2019年9月,烽火与武汉康普应国网公司邀请参加了华中境内某段OPGW光缆在线运行检测项目。该项目标志着老旧OPGW光缆性能,从实验室样品测试分析转向在线实时运行研究。由于B-OTDR设备的光纤传感技术在OPGW光缆运行线路上的使用没有先例,烽火做了大量实验,验证了布里渊光时域反射(B-OTDR)设备对OPGW光缆线路在线监测的准确性,并首次引用了光纤传感技术,结合其监控受力和温度的实例应用,解决了光缆在线受力监测分析这一困扰多年的难题。经过长时间持续监测收集到的光缆日常运行数据,结合实验室对样品检测的研究成果及对线路衰减逐年增加数据的综合分析,烽火归纳出影响光缆性能整体下降的原因,对光缆的适用性作出了有效评估。 烽火通信承担了《延长OPGW光缆寿命关键技术研究》等多项国家电网公司的科研课题,是全程参与国网公司“线路光缆性能研究”工作的唯一OPGW光缆制造企业。烽火为电力光缆线路的“体检”工作出具了全面的检测报告和分析报告,该成果弥补了国内外电力行业在运行线路OPGW光缆专项检测方面的空白,为科学评价光缆运行状态、准确评估电力通信网络的可靠性提供了有效支撑,将成为国家电网制定相关检测规范和标准的重要参考依据,为后期推出“电力网用在运行线路OPGW光缆的检测方法”奠定了坚实的基础。

    时间:2021-01-05 关键词: 国家电网 光缆 烽火通信 网络

  • 人类网络史上的知名黑客,猜猜你知道几个?

    1. 头号电脑黑客 如今的凯文·米特尼克(Kevin David Mitnick)是一名网络安全咨询师,但在二三十年前,年少轻狂的他就已凭借代码方面的惊人天赋,在黑客的世界里引起轩然大波。就连当时世界上最强大的科技和电信公司,诺基亚、富士通、摩托罗拉和 Sun 系统公司等的电脑系统都被他轻松光顾过,同时也造成他们高达2亿9千万美金的损失。1995年他被 FBI 逮捕并于2000年获得假释,他从不把自己的入侵行为称为黑客行为,而是“社会工程”。而他也从未用这项技能为自己谋取福利获得不义之财,对他来说,自己所作所为仅仅是因为喜欢而已。 2. 史上首个入侵银行系统获利的黑客 1995年,俄罗斯一名叫做弗拉季米尔·列宁(没错,和二月革命那个列宁完全同名)的黑客,在互联网上演了一场精彩的偷天换日,侵入美国花旗银行并盗走一千万美金。他是历史上第一个通过入侵银行电脑系统来获利的黑客,随后在英国被国际刑警逮捕。之后,他把帐户里的钱转移至美国、芬兰、荷兰、德国、爱尔兰等地。 3. 黑暗但丁 黑暗但丁是绰号,他真名是凯文·普尔森(Kevin Poulsen),专长是闯入电话线,占据一个基站的全部电话线路,甚至还会重新激活黄页上的电话,并提供给自己的伙伴进行出售。1990年,时年25岁的凯文为了参加洛杉矶广播电台的一次有奖活动(第102个成功打入电话的听众,奖品是一辆保时捷汽车),侵入电话网络 KIIS-FM 电话线,让别人的电话都打不进来,以确保他能打进第102个电话并去申领奖品。一年后,由于匿名举报被 FBI 抓捕。在狱中,被推举为 Wired(《连线》杂志)的高级编辑。(看照片是不是觉得这小哥很阳光呀) 4. 蠕虫病毒之父 罗伯特·塔潘-莫里斯(Robert Tappan Morris)不但是史上5大著名黑客之一,还是大名鼎鼎的“蠕虫病毒”的缔造者。他的父亲是美国国家安全局的一名科学家,而23岁的他在大学时制作“蠕虫”的目的也仅仅是探索互联网究竟有多大。但最终,“蠕虫”以无法控制的方式自我复制,造成6000台计算机死机,莫里斯也被判3年缓刑。后来,他成为麻省理工大学计算机科学和人工智能实验室的一名终身教授,主攻方向是计算机网络架构。 5. 编写首个具有全球破坏力病毒的黑客 1999年,一个名叫梅丽莎(Melissa)的病毒,让世界300多家公司的电脑系统崩溃,同时造成接近4亿美元的损失。而这个病毒也是首个具有全球破坏力的病毒,它的编写者戴维·斯密斯在写下梅丽莎病毒时,年仅30岁,随后他被判5年有期徒刑。 6. 入侵美国宇航局的黑客 乔纳森·詹姆斯(Jonathan James)是历史上最著名的5大黑客之一。据的《纽约时报》报道,时年仅16岁的他因入侵南方贝尔电话公司和美国政府计算机系统而被判有罪,成为世界上第一个因黑客行为而被捕的未成年人。1999年,他涉嫌入侵美国宇航局,并偷了控制国际空间站生命维持系统软件的源代码,为此美国宇航局不得不关闭系统数周,花费4万美元来升级系统的安全。随后他被判软禁,在此期间同 FBI 合作,找出了梅丽莎病毒和爱虫病毒的来源,又因此名声大振。 7. 一生追逐 UFO 的黑客 葛瑞·麦克坎侬(Gary McKinnon)是一位患有自闭症的英国电脑黑客,一生都在寻找有关外星人和 UFO 的保密信息,为此自称技术并不高超的他入侵了美国五角大楼、美国宇航局、美国陆海空三军网络系统和某处航天中心。2008年,美国向英国提出引渡请求但被拒绝,他也被认为是世界上头号军事黑客。 在亦真亦幻的互联网世界中,这些被曝光的黑客只是冰山一角。就在你阅读这篇微信文章的时候,在世界的其他角落里,就有无数黑客全身心投入地坐在电脑前,用手指敲击键盘尝试着入侵某个系统。他们也许为名为利,也许只是追求兴趣爱好,但只要稍有失手,不是自己深陷囵圄,就是像莫里斯那样因为错误判断,制造出后患无穷的电脑病毒。 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-12-30 关键词: 黑客 网络

  • 中兴SSB 1+X方案规模商用助力运营商5G领航城市网络建设

    如何高效、低成本地实现5G高层覆盖、让高楼用户也能畅享5G呢? 中兴提出了一种SSB 1+X的创新方案,助力运营商解决高楼场景网络建设。 本文将从技术原理、方案实施、工具应用、收益四个维度带你了解某运营商是如何应用SSB 1+X技术实现5G网络立体协同覆盖 ~

    时间:2020-12-28 关键词: 5G 网络

  • 美国力挺的Open RAN,真的能成功吗?

    今年以来,关于Open RAN的新闻不绝于耳。这种全新的网络架构在打开我们视野的同时,也带来了很多的困惑。 究竟什么是Open RAN?它真的是美国的5G杀手锏吗?它会成功吗? 1     Open RAN剑指开放   说起Open RAN,Open这个“词”的含义相当直白,就是开放的意思。RAN则是Radio Access Network缩写,意思就是无线接入网。因此,Open RAN的含义就是开放的无线接入网。 对于2G和3G来说,RAN包含两个网元:基站,以及管理基站的控制器(2G叫BSC,3G叫RNC)。到了4G,网络开始扁平化,控制器被取消,基站直连核心网,RAN就只有基站这一个网元,5G时代依然如此。 2G和3G现在已在退网,我们暂且不提。关键是4G和5G,RAN侧就是孤零零的一个基站,还要怎样开放呢? 其实,这看似小小的基站,里面大有乾坤。 在无线网络发展的远古时代,基站是浑然一体的一个设备,仅仅对外出两类接口:连接核心网的传输接口,以及连接天线的射频接口。 这两类接口之间的基站主设备,就像是一个“黑盒子”,我们只是大概知道里面是由电源,交换,基带,收发信机,数字中频,射频等零件组装起来的,运行着相关软件来支撑这一系统的正常工作。 这些基站的硬件和软件都是各个厂家自研的,内部各模块的划分和之间的接口对外不可见,其内运行的软件也是如此。运营商要买基站就只能整套买,出了问题厂家包排查包解决。 到了4G时代,这个“黑盒子”稍微打开了点,大家都把基站划分成了两大模块:BBU和RRU,以及它们之间的接口CPRI(通用公共无线接口)。 但是,BBU和RRU的内部实现还是不对外开放的,各厂家的方案各异。它们之间的CPRI接口虽然名字上带着“通用公共”,其实也是私有的,各厂家都有各自的数据格式,不能互通。 因此,运营商要买基站,还是得BBU,RRU连带软件从一家整套买,爱立信的BBU是不可能接诺基亚的RRU的。 从2G到5G至今,随着供应商之间竞争的加剧,倒闭的倒闭,并购的并购,供应商越来越少,而由于通信行业的技术壁垒又非常高,新的玩家很难进入,最终形成了近似少数厂家寡头垄断的客观现实。 运营商设备投资的费用高企,各供应商的产品同质化,价格难以降低,又没有新的厂家可以替代,这可如何是好? 于是,无数期望的目光纷纷投向了“白盒化”基站。 白盒基站,就是要把传统的黑盒基站打开,并大卸八块,软硬件解耦,并将所有的接口开放。这样一来,即使这些部件由不同厂家提供,只要大家都遵循相同的协议就可以组装起来运行。 其中的BBU硬件需要使用通用服务器(也称作COTS,Commercial Off-The-Shelf,意为商用现成品),可以从市场上的任意服务器厂家购买。 在BBU使用了通用服务器之后,就必须支持虚拟化功能(称作vRAN),才能在上面灵活地部署来自不同厂家的功能软件。 RRU硬件由于不仅仅处理数据,还要进行无线信号的发送和接收,必须使用专用的功放和滤波器等部件,因此不能直接使用通用服务器,需要由专业的RRU厂家提供。 不同厂家的RRU硬件,怎样运行不同软件提供商的软件呢?这就需要这些硬件遵循同样的开放架构,并且支持虚拟化。这样一来,运营商不论从哪家购买RRU,都可以运行第三方的软件。 RRU怎样和不同厂家的BBU软件对接呢?这就要求RRU和BBU之间的接口也是要开放的,大家都完全遵守相同的协议,才能互通有无。 在5G时代,传统的BBU可进一步拆分成CU和DU,这两个网元也可以采用不同的软件供应商,运营商的选择更多,网络的灵活性进一步增加。  比如,基站RRU的硬件采用供应商A,B,C三家,RRU软件采用供应商D,E,F三家,CU和DU的硬件采用供应商G,DU的软件采用供应商H,I,J三家,CU的软件采用供应商K。 这样一来,原先只能由2到3个传统设备商提供的同质化的基站,现在可以由11家厂商提供。原先孤零零的一颗大树,现在变成了一片树林,还形成了新的生态系统,各厂家在自己的生态位上各司其职! 这样一来,对运营商来说,其供应商体系将更加灵活,更加多元化,还能引入充分的竞争来激发创新活力,不必再担心因网络被某家供应商独占而丧失议价权。网络建设的成本也得以降低。 基站白盒化的诉求,核心在于软硬件解耦和接口开放,承载着运营商对于成本的节省,以及摆脱设备商胁迫的梦想,成就了如今Open RAN的风起云涌。 上图是一个关于Open RAN部署动机的调查。可以看出,28%的运营商的诉求是降低成本;21%的运营商考虑解除供应商锁定,引入竞争;15%的运营商想要借此增强网络部署的灵活性。此三点需求占了64%,是绝对的主流。 2     Open RAN背后的组织 当大家在讨论Open RAN的时候,经常能看到C-RAN,xRAN,O-RAN,ORAN,oRAN,OpenRAN,Open vRAN,O-vRAN这些字眼,让人眼花缭乱。 它们又都是什么意思,跟Open RAN之间的关系是什么呢? 上面这些说法其实来源于三个不同的组织:O-RAN联盟,OpenRAN工作组,以及Open vRAN计划。我们先从O-RAN联盟说起。 2018年,那是一个春天,在西班牙巴塞罗那一年一度的世界移动大会(MWC)期间,中国移动,美国AT&T,德国电信,日本NTT DOCOMO,以及法国的Orange这五巨头联合起来,宣布了O-RAN联盟的诞生。 O-RAN联盟的前身,就是中国移动发起的C-RAN联盟,以及日本NTT DOCOMO主导的xRAN论坛。 C-RAN,就是Centralized RAN或者Cloud RAN,由中国移动在2009年提出。其核心思想是把多个BBU集中部署形成基带池,然后再进行虚拟化和云化,从而降低能耗,基础设施投入以及运维成本。   xRAN成立于2016年,其主要目标是用开放可替代的通用服务器来替换传统基站的专用硬件,从而将基站的软硬件解耦,核心思想也无非是开放二字。  基于相同的目标,C-RAN联盟和xRAN论坛合二为一,成为了新的O-RAN联盟。上文提到的ORAN,oRAN等不同写法也都代表的是O-RAN联盟。 O-RAN联盟的成员众多,参与的运营商除了包含创始的五巨头之外,还有中国电信和联通,西班牙电信,英国沃达丰,日本软银,KDDI等,几乎囊括了全球绝大部分主流运营商。 设备商里面,爱立信,诺基亚,中兴,三星,中国信科等都是O-RAN联盟成员,只有华为没有参与。高通,Intel等芯片厂家也位列其中。 此外,还有大量新兴的中小设备商的参与,包括美国的Altiostar, Parallel,Mavenir,以及来自中国的佰才邦,赛特斯,亚信,京信等,他们都想从中分得一杯羹。 那么,O-RAN是怎样对基站进行拆分呢?主要有下面四个目标(新四化): 接口开放化:把基站内部原有的封闭接口的开放,在这个基础上,不同厂家的软件才有可能无缝配合,以此降低对单一厂商的依赖,鼓励创新,降低成本。 软件开源化:推动无线协议栈开源,共享代码,降低研发成本,让产业企业把更多精力聚焦在核心算法和差异化功能软件的研发上。  硬件白盒化:将传统基站的专用硬件用通用服务器代替,充分进行软硬件解耦,降低行业门槛,吸引更多中小企业参与竞争。  网络智能化:RAN开放和解耦之后,可以引人工智能,实现复杂组网环境下的高效运维管理,提升频谱资源的利用率,降低网络能耗。 在上述四点思路的指导下,基站就被分解成了下面的样子: O-RAN联盟负责制定统一的技术规范,以及互操作测试规范,在顺从3GPP定义的5G基站标准接口(E1/F1/FH/X2/Xn/NG)的基础上,还自行扩展了A1/O1/O2/E2等接口,约束非常严格。 为了实现上述目标,O-RAN联盟成立了9个工作组,3个焦点组,以及1个开源软件社区。 下面再说另一个主要组织:OpenRAN。 2016年,Facebook发起了一个叫做TIP(Telecom Infra Project,电信基础设施)的项目,下面包含了很多子项目,其中就有一个OpenRAN的项目计划。 2017年,全球运营商巨头沃达丰把自己研究的SDR RAN的成果奉献给了TIP,并创建OpenRAN工作组,旨在建立一个基于通用服务器,可软件定义技术的白盒化RAN解决方案。 参与OpenRAN的运营商成员以欧美地区为主,中国的三大运营商都没有参与。项目由沃达丰和西班牙电信牵头,沃达丰负责全力推进。 传统设备商中,除诺基亚积极参与之外,爱立信,华为和中兴都没有参与。此外新晋设备商三星对此也非常激进。 此外,希望夹缝生存,在通信市场分得一杯羹的大量欧美新兴的中小设备商的参与非常积极,他们已经在全球开始部署OpenRAN商用网络,并开始组建自己的生态系统。 跟O-RAN联盟不同,OpenRAN工作组并没有对开放网络的内外部接口进行严格规范的定义,他们属于务实行动派,积极鼓励各运营商和设备商进行Open RAN网络的实际部署,并在外场进行互操作测试。 也就是说,O-RAN联盟是标准先行,而OpenRAN则是先部署验证,标准后续再补。因此目前实际部署的开放接入网络基本都是基于OpenRAN的。 总体而言,O-RAN和OpenRAN这两个组织的参与成员虽然不尽相同,推进策略也各有侧重,但其目标和产品方案却大体一致,拥有非常广泛的共同语言。 在2020年2月份,两者携起手来,共同在欧洲成立了开放测试和集成中心(OTIC),共享资源来进行Open RAN的研究和推进。 从上图可以看出,OpenRAN定义了一套自己的工作流程,并和3GPP,开源软件社区,以及O-RAN联盟之间都有广泛的合作。 话说另外一个组织:Open vRAN的起源,也要从2018年说起。 同样是在当年的巴塞罗那全球移动通信大会上,思科发布了一个名为Open vRAN生态系统的计划,目标同样是基于通用硬件,以及开放式模块化的软件架构来让RAN走向开放之路。 Open vRAN也被称作O-vRAN。vRAN里面的v就是virtualized,指的是虚拟化,Open RAN的基础。 据悉,在2020年6月,思科和Telenor在挪威总部已经开始了Open vRAN的实验,进一步验证使用虚拟化的开放架构的成本和效率。 从上面的介绍可以看出,Open RAN是一个统称,代表了目前的基站白盒化,接口开放化,以及软件开源化,网络智能化等网络发展架构,而O-RAN,OpenRAN,Open vRAN等则是推动Open RAN不断前进的组织名称。 正是这些组织的诸多工作,不断为Open RAN添柴加火,成就了Open RAN今日的热度。 3     Open RAN需要面对的问题 毫无疑问,Open RAN代表了无线网络发展的方向,在技术上是可行的。但与此同时,它的成熟度又是明显不够的,面临的挑战也是巨大的。 技术复杂度增加 开放的接口会带来更加复杂的处理机制,部分接口还需定义全新规范的信令流程,增加了整体的设备复杂度和系统集成的难度。 并且,多个供应商之间要互联互通,就必须进行互操作测试。目前该测试也就是仅限于基站,核心网两个网元,涉及的厂家也不多,即便这样在前期也是困难重重,常有不兼容的情况发生。 Open RAN把基站拆地七零八碎,由于各厂家的技术方案各不相同,他们之间对接口相关规范的理解也可能存在差异,所需互操作验证的工作量是非常巨大的。 网络能效挑战 Open RAN的目标是硬件白盒化,使用通用服务器。这类硬件服务器的功能很强大,使用的是X86架构的通用芯片,什么都能算,不但成本低,灵活性还高。 但通用芯片也有致命的缺点,那就是没有经过特殊的定制和优化,对流量的处理效率低,功耗高。 而传统的黑盒基站,则主要是用FPGA和ASIC这样的专用芯片,软硬件是集成在一起的,因此也被称作SoC(System on Chip)。 FPGA,就是可编程集成电路。它可以通过硬件编程来改变内部芯片的逻辑结构,但软件是深度定制的,本质上其实就是专用芯片。 ASIC,即专用集成电路。顾名思义,它是为专业用途而定制的芯片,其绝大部分软件算法都固化于硅片,特点是“软硬件一体”。 专用芯片的优点是结构简单,性能强,体积小,功耗低,但灵活性差,基本没有可扩展性。 它们之间的优势对比,如下图所示:   图片来自公众号:鲜枣课堂 据业界研究,如果采用通用芯片来实现5G基站功能,其需要的芯片数量是专用芯片的18倍,功耗约是专用芯片的30倍。 如此巨大的功耗差距,使得白盒硬件难以满足宏站的性能要求,因此Open RAN产品多以微站,室分等为目标场景,或者以农村等低价值区域作为突破口。 网络质量挑战 采用Open RAN建网之后,性能到底怎么样?目前这个系统还处于方案验证阶段,对于其网络性能能否满足预期,还要打个大大的问号。 可以想到的是,在初期Open RAN仅仅是能正常工作,以微站形式部署,或者在低价值区域部署的策略对网络性能的容忍度也较高。 可以预想的是在系统集成验证完成之后,Open RAN才会逐渐在性能问题上进行增强。 并且,白盒硬件系统复杂,多厂家配合的可靠性也没有经过市场验证。 通常来说,运营商网络的可用性级别必须达到6个9的标准,也就是99.9999%。但是目前来看,白盒硬件难以做到这一级别。 如果要满足网络可靠性要求,就必须增加设备冗余备份。这就造成了设备成本的增加。 网络安全风险 一个基站由多个厂家的软硬件配合起来工作,多厂商之间如何进行安全隔离?如何保证最终的系统是安全的? 无线系统的复杂度远超操作系统的数十倍,如果采用开源软件,又怎样规避其中的安全风险?目前成功的大型开源软件,都要经过5年以上的积累和稳定周期。而O-RAN的软件开源才刚刚起步,道阻且长。 运维难度增加 软硬件分离解耦之后,同一个基站系统可能包括不同厂商的软件和硬件。这样一来,就会很难分清安装和维护时的责任划分。 众所周知,以前一两家厂商的时候,扯皮都是家常便饭。换成N家厂商,肯定会闹得鸡犬不宁。 安装阶段,扯皮将严重影响设备安装的工期,增加成本。维护阶段,扯皮还会增加故障的恢复时间。 并且,对于运营商来说,原本只需要掌握和维护三家设备商的产品,现在数量上直接翻了几倍,无形中也增加了学习成本和管理成本。 这样以来,运营商很有可能在设备投资上省下来的钱,又被迫投入到网络维护的无底洞中去,最后一算账成本并没有降低。 4     2020年的Open RAN成绩单 目前来说,Open RAN的推动力主要来自两条线。 一条线是前面介绍的O-RAN和OpenRAN这两个组织的持续努力,其中以沃达丰牵头的OpenRAN工作组最为积极,近一年来成果卓著。 另一条线则来自于美国政府的5G焦虑。 众所周知,美国本土的大型设备商均已不复存在,为了达到所谓“网络安全”的诉求,并进行行业的重新洗牌,塑造有利于美国的产业生态,美国在对Open RAN的支持上不遗余力。 2019年12月,美国国防部要求美国企业开发开源5G软件,重塑产业生态。 2020年1月,美国两党参议员提出一项华为替代法案,要求设立一个7.5亿美元的基金,用来支持Open RAN的开发。同时,美国国防高级研究计划局宣布正式启动“开放,可编程,安全的5G计划”,标志着美国的5G战略开始实施。 2020年2月,美国政府召集顶级运营商和技术公司,与AT&T,戴尔,微软合作开发5G软件,以减少对华为设备的依赖。 2020年5月,具有浓厚美国政府背景的Open RAN政策联盟宣布成立。前美国国家电信和信息管理局行政长官担任该组织执行董事,且该联盟的31家成员中有24家是美国公司。 2020年7月,美国政府要求日本的NTT DOCOMO和NEC加入Open RAN政策联盟。 2020年9月,美国联邦通信委员会(FCC)举行线上5G Open RAN论坛。在美国的威胁之下,欧洲各国开始禁用华为设备,多个的运营商表示未来会使用Open RAN。 2020年11月,美国众议院通过了年初提出的7.5亿元Open RAN支持资金,这些拨款将在新的电信法案颁布后的18个月内发放。 2020年12月,美国联邦通信委员会计划向运营商支付一定费用(耗资可能超过20亿美金),帮助他们拆除华为和中兴的设备,并表示可以采用Open RAN方案。 在美国政府的胡萝卜和大棒之下,2020年下半年,全球的Open RAN试点显著加速,呈现一片热火朝天的景象。 6月,GSMA和O-RAN联盟宣布合作,共同推进Open RAN相关的软件和硬件及解决方案的应用。思科和挪威Telenor宣布合作进行Open vRAN的研究和落地。爱立信表示Open RAN是其研发重点之一。 7月,诺基亚发布现有产品支持Open RAN的路标,并表示:“无论运营商是否采用Open RAN,它都在为未来的网络架构做准备。” 三星也声称已推出了完全开发和虚拟化的5G RAN产品,并表示:“三星是开放系统的忠实拥护者。” 从此之后,Open RAN在全球的试点遍地开花。 沃达丰在印度多个城市进行了基于Open RAN的4G Massive MIMO部署,并在非洲刚果,莫桑比克以及土耳其进行Open RAN试用。法电也正计划非洲农村地区推出Open RAN,用来进一步扩展用户。西班牙电信也在秘鲁开展了Open RAN测试。 8月,美国AT&T使用三星和诺基亚的设备在美国达拉斯商用Open RAN网络,与此同时,Verizon和Dish也在测试这项技术。日本乐天移动宣布推出一款基于Open RAN架构的32通道5G AAU,可支持100M带宽,能达到1.7Gbps的下行速率。 9月,市场研究机构Dell’Oro预测Open RAN将在未来的5年内保持两位数百分比的增长,累计投资超过50亿美元。 10月,使用Open RAN 的日本乐天移动宣布在多个城市推出5G服务,最高下载上传速率达870Mbps/110Mbps。高通宣布在其5G芯片中增加对Open RAN的兼容性,沃达丰在荷兰打通首个基于Open RAN的5G电话。 11月,沃达丰透露其将在2027年前在英国农村部署约2600个Open RAN站点,用来取代华为35%的设备。日本NEC野心勃勃地宣布在英国设立Open RAN卓越中心,面向沃达丰总部来推动全球Open RAN的推动。 12月,英国数字文化媒体相关部门表示将大力发展Open RAN。NEC马上参与英国政府主导的5G Open RAN实验计划,并在印度同步启动Open RAN实验室。 非洲的通信巨头MTN也宣布其将在尼日利亚农村地区部署2000个Open RAN站点,其中500个在明年安装,未来可能将数量增加到5000个。西班牙电信宣布在德国成功部署Open RAN站点。 市场研究机构Dell’Oro 预测2020年Open RAN的设备收入已达3亿美元。Omdia预测2024年Open RAN市场规模将达到34亿美元,接近4G和5G市场总量的10%。 虽然这份成绩单看似傲人,其中也不乏冷静的声音。目前业界一致的看法是:Open RAN目前还只是传统基站的补充,真正离成熟商用还有3到5年的时间。 对此,你怎么看? — END — 参考文档 鲜枣课堂:O-RAN,真的会成功吗? 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-12-28 关键词: 通信 网络

  • 关于5G最新进展的一些数据

    关于5G最新进展的一些数据

    12月24日,在国务院新闻发布会上,言人、信息通信发展司司长闻库表示,这一年来,加快5G网络建设,取得了比较好的效果

    时间:2020-12-28 关键词: 5G 网络

  • 5G数字化运维,到底是如何实现的?

    从2G到4G,移动通信改变了我们每一个人的生活。已经到来的5G,更是加速了各个行业的数字化转型。 就在移动通信网络改变人类的同时,它自身也在发生巨变——网元变得越来越多,网元之间的接口和协议也变得越来越复杂。 令人头秃的2/3/4/5G网络 那么,你有没有想过,面对如此复杂的网络,我们究竟该如何进行有效的 管理和维护 呢? 其实,我们可以把5G看作是一个人。我们对人进行健康监测,通常是在他身上安装监测设备,采集样本(例如验血、心电图、X光等)。 根据采集到的数据,我们再进行指标分析,最终得出健康报告。 早期的通信网络也是这样,每个网元设备都有自己的管理软件,通过软件可以查看该网元的指标情况。 但是,这种方式过于分散,属于典型的“头痛医头,脚痛医脚”。对人体来说姑且可行,但是,对于移动通信网络(尤其是5G这样的复杂网络)来说,增加了运维难度。 因为,一个业务问题,通常涉及到多个(甚至十多个)网元。全靠人工分散运维的话,需要面对巨大的工作量,很难快速找到问题根因。 真正优秀的医生,会根据身体全方位的检查结果汇总,给出准确的诊疗判断。网络运维,亦是如此。 网络是一个整体。对于网络的维护,应该“站得更高,看得更全”。 我们可以在每一个接口安装探针,进行抓包,获取数据。然后,对数据进行汇总整理,找出规律,并给出结论。 这种抓取网元之间接口数据包,并对其进行分析和识别的技术,就是业界常说的深度报文识别技术,DPI(Deep Packet Inspection)。 而抓取报文之后形成的记录,则被称为XDR(X Data Recording)。 常见的XDR有两种,分别是信令XDR和业务XDR: (1) 信令XDR:记录网元间发号施令的详细过程,这些指令包括接入、释放、切换等。 (2) 业务XDR:记录用户有关的信息如IMSI,以及用户上网、打电话等业务的详细过程。 大家会注意到,单个接口产生的XDR,只会记录该接口相关的信息,即“单接口XDR”。 然而,任何一次完整的用户行为(比如打电话),肯定会涉及到多个接口。 因此,我们在采集到多个相关接口的“单接口XDR”数据之后,还需要根据用户号码、时间顺序等,对它们进行关联、合成,形成能够全面描述整个业务过程的“完整XDR”。 XDR的关联合成 这些完整XDR,会被打包送到上层运维系统中,等待解析、使用。 字段名 说明 Length 整个XDR所占用的字节数 Interface 接口名称:Mw/Mg/Mi/Mj/ISC/Gm/…… XDR ID XDR唯一编号 IMSI IMSI号码 Procedure  Type 流程类型编码,取值如下:1:Register(注册)2:Deregister(注销) 3:3rd-Register(第三方注册)4:3rd-Deregister(第三方注销) 5:Calling(语音通话) 6:…… Procedure  Start Time 业务流程开始时间 Procedure  End Time 业务流程结束时间 ...... ...... XDR内部信息示例 如上表所示, XDR里面的各种字段信息,完整地描述了一次业务流程。例如,Procedure Type字段为5,则表明该次业务类型是 “Calling(语音通话)”。 大家搞明白了吧?DPI技术,有点像移动通信网络的“生命监测仪”,是运维支撑工作的神器。 接下来,我们就通过“语音通话”这个基本业务,深入了解一下DPI究竟如何帮助运维人员进行“5G生命监测”。 大家应该都听说过,5G通过VoNR(Voice over NR),实现对语音通话业务的支持。 其实,在5G网络建设早期,5G信号并没有做到无缝覆盖。所以,为保证通话的成功率,我们可能会更多地采用另一种语音技术方案,那就是EPS Fallback。 简单来说,就是当工作在5G网络上的终端,发起语音呼叫或有语音呼入时,网络通过切换流程,将5G终端切换到4G网络上,通过VoLTE(Voice over LTE)技术提供语音业务。 这样一来,打通5G语音电话,就需要跨无线域、5GC域(5G核心网)、EPC域(4G核心网)、IMS域,调动数量众多的网元、接口,进行大规模协作。 EPS Fallback的业务流程大致可以分为 起呼、回落、接通、返回 四大阶段,整个过程极为复杂(如下图所示)。 EPS Fallback的信令流程 这么多域,这么多网元,这么多接口,这么多信令,稍有一丁点差错,就会影响用户的语音通话体验,甚至导致通话失败。这么复杂的协同流程,一旦出现问题,想要反查原因,也是非常困难的。 在中兴通讯的EPS Fallback方案中,为了让用户能够 “打得通、接得快、不掉话、听得见” ,他们针对起呼、回落、接通、保持全流程建立了KQI-KPI指标体系。 KQI:关键业务指标,Key Quality Indicator KPI:关键性能指标,Key Performance Indicator 5G语音业务感知指标体系 指标体系建好之后,就轮到中兴通讯 VMAX智能大数据平台 闪亮登场了。 这个平台就是前面我们所说的移动通信网络“生命监测仪”。它可以通过查询XDR(监测数据),关联合成之后,完整“还原”一次EPS FallBack业务流程。 结合前面提到的“生命指标体系”,VMAX平台进行多维分析、信令回溯,就能精准定位出“病因(问题点)”。 中兴通讯VMAX平台的架构并不复杂,它分为数据采集层、数据解码层和应用层,可以面向核心网域以及无线域进行数据采集和解码。合成后的数据,可以提供给上层应用进行深度分析。 VMAX 5G DPI系统架构 大家应该能看出来,EPS Fallback 5G语音业务分析只是中兴VMAX平台强大功能的一个缩影。基于对XDR的深度分析,整个系统能够实现对网络、业务和用户的全面洞察。 运营商不仅可以了解网络各方面的运行状态,还可以监控具体业务的运行质量,更能够实现用户体验的主动感知。 除了发现和解决问题之外,VMAX系统还可以用于 精准营销 。 VMAX采用业界领先的加密业务识别技术,可以实时DPI解析用户流程的业务特征,判断业务流量类型。 也就是说,借助VMAX,运营商可以知道用户到底在使用哪种类型的App(抖音、微信、爱奇艺等)。这样一来,可以建立用户画像,进行针对性的推广营销(例如定向流量包推荐、App权益赠送)。 中兴VMAX可以识别10000种以上的协议,识别准确率高达95%,远远高于行业80%的平均水平。系统的规则库会持续更新,增加对最新业务的识别能力。 相比行业同类产品,中兴VMAX还具有以下特点: 全域数据采集能力 中兴通讯在信令分析领域有20多年的技术沉淀,是业内唯一具备2/3/4/5G/NB-IoT全网全域数据采集能力的厂家,同时具备核心网、无线的事务级话单关联能力,真正能做到业务端到端分析。 智能的AI采集,赋能5G 针对5G网络特征,中兴VMAX可以提供基于切片的采集方案,分场景、分时间、分区域、分流量等进行智能化DPI采集。 产品架构解耦灵活 秉承电信设备商所具有的模块内高内聚、模块间低耦合的产品架构设计思想,模块内功能简化,模块间分工明确,接口定义规范清晰。 总而言之,中兴通讯VMAX智能大数据平台,依托数据挖掘和深度学习能力,具有高可靠、高性能、高识别率等特性,可实现对全网全域数据的高效采集和精准解析。 随着5G网络的不断发展壮大,以VMAX为代表的数字化运维手段,将成为运营商感知用户、拓展市场的利器。借助它,运营商可以构建更加智能开放的价值运营平台,在激烈的市场竞争中抢占先机。 (全文完) 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-12-28 关键词: 5G 网络

  • 3w字带你揭开WebSocket的神秘面纱~

    目录 一. WebSocket 简介 WebSocket 是一种基于 TCP 的网络协议。在 2009 年诞生,于 2011 年被 IETF 定为标准 RFC 6455 通信标准,并由 RFC7936 补充规范。WebSocket API 也被 W3C 定为标准。 WebSocket 也是一种全双工通信的协议,既允许客户端向服务器主动发送消息,也允许服务器主动向客户端发送消息。在 WebSocket 中,浏览器和服务器只需要完成一次握手,两者之间就可以建立持久性的连接,进行双向数据传输。 二. WebSocket 特点 连接握手阶段使用 HTTP 协议; 协议标识符是 ws,如果采用加密则是 wss; 数据格式比较轻量,性能开销小,通信高效; 没有同源限制,客户端可以与任意服务器通信; 建立在 TCP 协议之上,服务器端的实现比较容易; 通过 WebSocket 可以发送文本,也可以发送二进制数据; 与 HTTP 协议有着良好的兼容性。默认端口也是 80 和 443,并且握手阶段采用 HTTP 协议,因此握手时不容易屏蔽,能通过各种 HTTP 代理服务器; 三. 为什么需要 WebSocket? 谈起为什么需要 WebSocket 前,那得先了解在没有 WebSocket 那段时间说起,那时候基于 Web 的消息基本上是靠 Http 协议进行通信,而经常有”聊天室”、”消息推送”、”股票信息实时动态”等这样需求,而实现这样的需求常用的有以下几种解决方案: 1. 短轮询(Traditional Polling) 短轮询是指客户端每隔一段时间就询问一次服务器是否有新的消息,如果有就接收消息。这样方式会增加很多次无意义的发送请求信息,每次都会耗费流量及处理器资源。 优点:短连接,服务器处理简单,支持跨域、浏览器兼容性较好。 缺点:有一定延迟、服务器压力较大,浪费带宽流量、大部分是无效请求。 2. 长轮询(Long Polling) 长轮询是段轮询的改进,客户端执行 HTTP 请求发送消息到服务器后,等待服务器回应,如果没有新的消息就一直等待,知道服务器有新消息传回或者超时。 这也是个反复的过程,这种做法只是减小了网络带宽和处理器的消耗,但是带来的问题是导致消息实时性低,延迟严重。而且也是基于循环,最根本的带宽及处理器资源占用并没有得到有效的解决。 优点:减少轮询次数,低延迟,浏览器兼容性较好。 缺点:服务器需要保持大量连接。 3. 服务器发送事件(Server-Sent Event) “ 目前除了 IE/Edge,其他浏览器都支持。 服务器发送事件是一种服务器向浏览器客户端发起数据传输的技术。一旦创建了初始连接,事件流将保持打开状态,直到客户端关闭。该技术通过传统的 HTTP 发送,并具有 WebSockets 缺乏的各种功能,例如”自动重新连接”、”事件ID” 及 “发送任意事件”的能力。 “ 服务器发送事件是单向通道,只能服务器向浏览器发送,因为流信息本质上就是下载。 优点:适用于更新频繁、低延迟并且数据都是从服务端发到客户端。 缺点:浏览器兼容难度高。 总结 显然,上面这几种方式都有各自的优缺点,虽然靠轮询方式能够实现这些一些功能,但是其对性能的开销和低效率是非常致命的,尤其是在移动端流行的现在。 现在客户端与服务端双向通信的需求越来越多,且现在的浏览器大部分都支持 WebSocket。所以对实时性和双向通信及其效率有要求的话,比较推荐使用 WebSocket。 四. WebSocket 连接流程 第一步 客户端先用带有 Upgrade:Websocket 请求头的 HTTP 请求,向服务器端发起连接请求,实现握手(HandShake)。 客户端 HTTP 请求的 Header 头信息如下: Connection: UpgradeSec-WebSocket-Extensions: permessage-deflate; client_max_window_bitsSec-WebSocket-Key: IRQYhWINfX5Fh1zdocDl6Q==Sec-WebSocket-Version: 13Upgrade: websocket Connection: Upgrade 表示要升级协议。 Upgrade: Websocket 要升级协议到 websocket 协议。 Sec-WebSocket-Extensions: 表示客户端所希望执行的扩展(如消息压缩插件)。 Sec-WebSocket-Key: 主要用于WebSocket协议的校验,对应服务端响应头的 Sec-WebSocket-Accept。 Sec-WebSocket-Version: 表示 websocket 的版本。如果服务端不支持该版本,需要返回一个 Sec-WebSocket-Versionheader,里面包含服务端支持的版本号。 第二步 握手成功后,由 HTTP 协议升级成 Websocket 协议,进行长连接通信,两端相互传递信息。 服务端响应的 HTTP Header 头信息如下: Connection: upgradeSec-Websocket-Accept: TSF8/KitM+yYRbXmjclgl7DwbHk=Upgrade: websocket Connection: Upgrade 表示要升级协议。 Upgrade: Websocket 要升级协议到 websocket 协议。 Sec-Websocket-Accept: 对应 Sec-WebSocket-Key 生成的值,主要是返回给客户端,让客户端对此值进行校验,证明服务端支持 WebSocket。 五. WebSocket 使用场景 数据流状态: 比如说上传下载文件,文件进度,文件是否上传成功。 协同编辑文档: 同一份文档,编辑状态得同步到所有参与的用户界面上。 多玩家游戏: 很多游戏都是协同作战的,玩家的操作和状态肯定需要及时同步到所有玩家。 多人聊天: 很多场景下都需要多人参与讨论聊天,用户发送的消息得第一时间同步到所有用户。 社交订阅: 有时候我们需要及时收到订阅消息,比如说开奖通知,比如说在线邀请,支付结果等。 股票虚拟货币价格: 股票和虚拟货币的价格都是实时波动的,价格跟用户的操作息息相关,及时推送对用户跟盘有很大的帮助。 六. WebSocket 中子协议支持 WebSocket 确实指定了一种消息传递体系结构,但并不强制使用任何特定的消息传递协议。而且它是 TCP 上的一个非常薄的层,它将字节流转换为消息流(文本或二进制)仅此而已。由应用程序来解释消息的含义。 与 HTTP(它是应用程序级协议)不同,在 WebSocket 协议中,传入消息中根本没有足够的信息供框架或容器知道如何路由或处理它。因此,对于非常琐碎的应用程序而言 WebSocket 协议的级别可以说太低了。 可以做到的是引导在其上面再创建一层框架。这就相当于当今大多数 Web 应用程序使用的是 Web 框架,而不直接仅使用 Servlet API 进行编码一样。 WebSocket RFC 定义了子协议的使用。在握手过程中,客户机和服务器可以使用头 Sec-WebSocket 协议商定子协议,即使不需要使用子协议,而是用更高的应用程序级协议,但应用程序仍需要选择客户端和服务器都可以理解的消息格式。且该格式可以是自定义的、特定于框架的或标准的消息传递协议。 Spring 框架支持使用 STOMP,这是一个简单的消息传递协议,最初创建用于脚本语言,框架灵感来自 HTTP。STOMP 被广泛支持,非常适合在 WebSocket 和 web 上使用。 七. 什么是 STOMP 协议 (1). STOMP 协议概述 “ STOMP(Simple Text-Orientated Messaging Protocol)是一种简单的面向文本的消息传递协议。 它提供了一个可互操作的连接格式,允许 STOMP 客户端与任意 STOMP 消息代理(Broker)进行交互。STOMP 协议由于设计简单,易于开发客户端,因此在多种语言和多种平台上得到广泛地应用。 (2). 简单介绍可以分为以下几点: STOMP 是基于帧的协议,其帧以 HTTP 为模型。 STOMP 框架由命令,一组可选的标头和可选的主体组成。 STOMP 基于文本,但也允许传输二进制消息。 STOMP 的默认编码为 UTF-8,但它支持消息正文的替代编码的规范。 (3). STOMP 客户端是一种用户代理 作为生产者,通过 SEND 帧将消息发送到目标服务器上。 作为消费者,对目标地址发送 SUBSCRIBE 帧,并作为 MESSAGE 帧从服务器接收消息。 (4). STOMP 帧 STOMP 是基于帧的协议,其帧以 HTTP 为模型。STOMP 结构为: COMMANDheader1:value1header2:value2Body^@ 客户端可以使用 SEND 或 SUBSCRIBE 命令发送或订阅消息,还可以使用 “destination” 头来描述消息的内容和接收者。 这支持一种简单的发布-订阅机制,可用于通过代理将消息发送到其他连接的客户端,或将消息发送到服务器以请求执行某些工作。 (5). Stomp 常用帧 STOMP 的客户端和服务器之间的通信是通过”帧“(Frame)实现的,每个帧由多”行“(Line)组成,其包含的帧如下: Connecting Frames: CONNECT(连接) CONNECTED(成功连接) Client Frames: SEND(发送) SUBSRIBE(订阅) UNSUBSCRIBE(取消订阅) BEGIN(开始) COMMIT(提交) ABORT(中断) ACK(确认)) NACK(否认)) DISCONNECT(断开连接)) Server Frames: MESSAGE(消息)) RECEIPT(接收)) ERROR(错误)) (6). Stomp 与 WebSocket 的关系 直接使用 WebSocket 就很类似于使用 TCP 套接字来编写 Web 应用,因为没有高层级的应用协议(wire protocol),因而就需要我们定义应用之间所发送消息的语义,还需要确保连接的两端都能遵循这些语义。 同 HTTP 在 TCP 套接字上添加请求-响应模型层一样,STOMP 在 WebSocket 之上提供了一个基于帧的线路格式层,用来定义消息语义。 (7). 使用 STOMP 作为 WebSocket 子协议的好处 无需发明自定义消息格式 在浏览器中 使用现有的stomp.js客户端 能够根据目的地将消息路由到 可以使用成熟的消息代理(例如 RabbitMQ, ActiveMQ等)进行广播的选项 使用 STOMP(相对于普通 WebSocket)使 Spring Framework 能够为应用程序级使用提供编程模型,就像 Spring MVC 提供基于 HTTP 的编程模型一样。 八. Spring 封装的 STOMP 使用 Spring 的 STOMP 支持时,Spring WebSocket 应用程序充当客户端的 STOMP 代理。 消息被路由到 @Controller 消息处理方法或简单的内存中代理,该代理跟踪订阅并向订阅的用户广播消息。 还可以将 Spring 配置为与专用的 STOMP 代理(例如 RabbitMQ,ActiveMQ等)一起使用,以实际广播消息。在那种情况下,Spring 维护与代理的 TCP 连接,将消息中继到该代理,并将消息从该代理向下传递到已连接的 WebSocket 客户端。 因此 Spring Web 应用程序可以依赖基于统一 HTTP 的安全性,通用验证以及熟悉的编程模型消息处理工作。 Spring 官方提供的处理流图: 上面中的一些概念关键词: Message: 消息,里面带有 header 和 payload。 MessageHandler: 处理 client 消息的实体。 MessageChannel: 解耦消息发送者与消息接收者的实体 clientInboundChannel:用于从 WebSocket 客户端接收消息。 clientOutboundChannel:用于将服务器消息发送给 WebSocket 客户端。 brokerChannel:用于从服务器端、应用程序中向消息代理发送消息 Broker: 存放消息的中间件,client 可以订阅 broker 中的消息。 上面的设置包括3个消息通道: clientInboundChannel: 用于来自WebSocket客户端的消息。 clientOutboundChannel: 用于向WebSocket客户端发送消息。 brokerChannel: 从应用程序内部发送给代理的消息。 九. 示例一:实现简单的广播模式 WebSocket 常分为广播与队列模式,广播模式是向订阅广播的用户发送信息,只要订阅相关广播就能收到对应信息。 队列模式常用于点对点模式,为单个用户向另一个用户发送信息,这里先介绍下广播模式的实现示例。 1. Maven 引入相关依赖 这里使用 Maven 工具管理依赖包,分别引入下面依赖: lombok: Lombok 工具依赖,便于生成实体对象的 Get 与 Set 方法。 spring-boot-starter-websocket:SpringBoot 实现 WebSocket 的依赖,里面对 WebSocket 进行了一些列封装,并且也包含了 SpringBoot Web 依赖。                             org.springframework.boot            spring-boot-starter-websocket                                    org.projectlombok            lombok            provided         2. 创建测试实体类 创建便于传输消息的实体类,里面字段内容如下: import lombok.Data;@Datapublic class MessageBody {    /** 消息内容 */    private String content;    /** 广播转发的目标地址(告知 STOMP 代理转发到哪个地方) */    private String destination;} 3. 创建 WebSocket 配置类 创建 WebSocket 配置类,配置进行连接注册的端点 /mydlq 和消息代理前缀 /topic 及接收客户端发送消息的前缀 /app。 @Configuration@EnableWebSocketMessageBrokerpublic class WebSocketConfig implements WebSocketMessageBrokerConfigurer {    /**     * 配置 WebSocket 进入点,及开启使用 SockJS,这些配置主要用配置连接端点,用于 WebSocket 连接     *     * @param registry STOMP 端点     */    @Override    public void registerStompEndpoints(StompEndpointRegistry registry) {        registry.addEndpoint("/mydlq").withSockJS();    }    /**     * 配置消息代理选项     *     * @param registry 消息代理注册配置     */    @Override    public void configureMessageBroker(MessageBrokerRegistry registry) {        // 设置一个或者多个代理前缀,在 Controller 类中的方法里面发生的消息,会首先转发到代理从而发送到对应广播或者队列中。        registry.enableSimpleBroker("/topic");        // 配置客户端发送请求消息的一个或多个前缀,该前缀会筛选消息目标转发到 Controller 类中注解对应的方法里        registry.setApplicationDestinationPrefixes("/app");    }} 4. 创建测试 Controller 类 创建 Controller 类,该类也类似于正常 Web 项目中 Controller 写法一样,在方法上面添加 @MessageMapping 注解,当客户端发送消息请求的前缀匹配上 WebSocket 配置类中的 /app 前缀后,会进入到 Controller 类中进行匹配,如果匹配成功则执行注解所在的方法内容。 @Controllerpublic class MessageController {    /** 消息发送工具对象 */    @Autowired    private SimpMessageSendingOperations simpMessageSendingOperations;    /** 广播发送消息,将消息发送到指定的目标地址 */    @MessageMapping("/test")    public void sendTopicMessage(MessageBody messageBody) {        // 将消息发送到 WebSocket 配置类中配置的代理中(/topic)进行消息转发        simpMessageSendingOperations.convertAndSend(messageBody.getDestination(), messageBody);    }} 5. 创建测试脚本 创建用于操作 WebSocket 的 JS 文件 app-websocket.js,内容如下: // 设置 STOMP 客户端var stompClient = null;// 设置 WebSocket 进入端点var SOCKET_ENDPOINT = "/mydlq";// 设置订阅消息的请求前缀var SUBSCRIBE_PREFIX = "/topic"// 设置订阅消息的请求地址var SUBSCRIBE = "";// 设置服务器端点,访问服务器中哪个接口var SEND_ENDPOINT = "/app/test";/* 进行连接 */function connect() {    // 设置 SOCKET    var socket = new SockJS(SOCKET_ENDPOINT);    // 配置 STOMP 客户端    stompClient = Stomp.over(socket);    // STOMP 客户端连接    stompClient.connect({}, function (frame) {        alert("连接成功");    });}/* 订阅信息 */function subscribeSocket(){    // 设置订阅地址    SUBSCRIBE = SUBSCRIBE_PREFIX + $("#subscribe").val();    // 输出订阅地址    alert("设置订阅地址为:" + SUBSCRIBE);    // 执行订阅消息    stompClient.subscribe(SUBSCRIBE, function (responseBody) {        var receiveMessage = JSON.parse(responseBody.body);        $("#information").append("" + receiveMessage.content + "");    });}/* 断开连接 */function disconnect() {    stompClient.disconnect(function() {        alert("断开连接");    });}/* 发送消息并指定目标地址(这里设置的目标地址为自身订阅消息的地址,当然也可以设置为其它地址) */function sendMessageNoParameter() {    // 设置发送的内容    var sendContent = $("#content").val();    // 设置待发送的消息内容    var message = '{"destination": "' + SUBSCRIBE + '", "content": "' + sendContent + '"}';    // 发送消息    stompClient.send(SEND_ENDPOINT, {}, message);} 6. 创建 WebSocket HTML 创建用于展示 WebSocket 相关功能的 WEB HTML 页面 index.html,内容如下:     Hello WebSocket                                                                                                            WebSocket 连接:                        进行连接                        断开连接                                        订阅地址:                                                                                    订阅                                                                                发送的消息内容:                                        发送                                                    接收到的消息:                                                                             7. 启动并进行测试 输入地址 http://localhost:8080/index.html 访问测试的前端页面,然后执行下面步骤进行测试: 点击 进行连接按钮,连接 WebSocket 服务端; 在订阅地址栏输入 订阅地址(因为本人设置的订阅地址和接收消息的地址是一个,所以随意输入); 点击 订阅按钮订阅对应地址的消息; 在发送消息内容的输入框中输入 hello world!,然后点击 发送按钮发送消息; 执行完上面步骤成后,可以观察到成功接收到订阅地址的消息,如下: 十. 示例二:实现点对点模式(引入 Spring Security 实现鉴权) 1. Maven 引入相关依赖 这里使用 Maven 工具管理依赖包,分别引入下面依赖: lombok: Lombok 工具依赖,便于生成实体对象的 Get 与 Set 方法。 spring-boot-starter-websocket:SpringBoot 实现 WebSocket 的依赖,里面对 WebSocket 进行了一些列封装,并且也包含了 SpringBoot Web 依赖。 spring-boot-starter-security:Spring Security,这是一种基于 Spring AOP 和 Servlet 过滤器的安全框架。它提供全面的安全性解决方案,同时在 Web 请求级和方法调用级处理身份确认和授权。                             org.springframework.boot            spring-boot-starter-websocket                                    org.springframework.boot            spring-boot-starter-security                                    org.projectlombok            lombok            provided             2. 创建测试实体类 创建便于传输消息的实体类,里面字段内容如下: @Datapublic class MessageBody {    /** 发送消息的用户 */    private String from;    /** 消息内容 */    private String content;    /** 目标用户(告知 STOMP 代理转发到哪个用户) */    private String targetUser;    /** 广播转发的目标地址(告知 STOMP 代理转发到哪个地方) */    private String destination;} 3. 创建 WebSocket 配置类 创建 WebSocket 配置类,配置进行连接注册的端点/mydlq 和消息代理前缀 /queue 及接收客户端发送消息的前缀 /app。 @Configuration@EnableWebSocketMessageBrokerpublic class WebSocketConfig implements WebSocketMessageBrokerConfigurer {    /**     * 配置 WebSocket 进入点,及开启使用 SockJS,这些配置主要用配置连接端点,用于 WebSocket 连接     *     * @param registry STOMP 端点     */    @Override    public void registerStompEndpoints(StompEndpointRegistry registry) {        registry.addEndpoint("/mydlq").withSockJS();    }    /**     * 配置消息代理选项     *     * @param registry 消息代理注册配置     */    @Override    public void configureMessageBroker(MessageBrokerRegistry registry) {        // 设置一个或者多个代理前缀,在 Controller 类中的方法里面发生的消息,会首先转发到代理从而发送到对应广播或者队列中。        registry.enableSimpleBroker("/queue");        // 配置客户端发送请求消息的一个或多个前缀,该前缀会筛选消息目标转发到 Controller 类中注解对应的方法里        registry.setApplicationDestinationPrefixes("/app");        // 服务端通知特定用户客户端的前缀,可以不设置,默认为user        registry.setUserDestinationPrefix("/user");    }} 5. 创建 Security 配置 Spring Security 的配置类,可以在该类中配置权限认证及测试的两个用户相关信息: 测试用户名/密码1:mydlq1/123456 测试用户名/密码2:mydlq2/123456 @Configurationpublic class SecurityConfig extends WebSecurityConfigurerAdapter {    /**     * 设置密码编码的配置参数,这里设置为 NoOpPasswordEncoder,不配置密码加密,方便测试。     *     * @return 密码编码实例     */    @Bean    PasswordEncoder passwordEncoder() {        return NoOpPasswordEncoder.getInstance();    }    /**     * 设置权限认证参数,这里用于创建两个用于测试的用户信息。     *     * @param auth SecurityBuilder 用于创建 AuthenticationManager。     * @throws Exception 抛出的异常     */    @Override    protected void configure(AuthenticationManagerBuilder auth) throws Exception {        auth.inMemoryAuthentication()                .withUser("mydlq1")                .password("123456")                .roles("admin")                .and()                .withUser("mydlq2")                .password("123456")                .roles("admin");    }    /**     * 设置 HTTP 安全相关配置参数     *     * @param http HTTP Security 对象     * @throws Exception 抛出的异常信息     */    @Override    protected void configure(HttpSecurity http) throws Exception {        http.authorizeRequests()                .anyRequest().authenticated()                .and()                .formLogin()                .permitAll();    }} 5. 创建测试 Controller 类 跟上面介绍广播模式一样,作用也是根据 WebSocket 配置类中 /app 前缀匹配后进入 Controller 类进行逻辑处理操作。 @Controllerpublic class MessageController {    @Autowired    private SimpMessageSendingOperations simpMessageSendingOperations;    /**     * 点对点发送消息,将消息发送到指定用户     */    @MessageMapping("/test")    public void sendUserMessage(Principal principal, MessageBody messageBody) {        // 设置发送消息的用户        messageBody.setFrom(principal.getName());        // 调用 STOMP 代理进行消息转发        simpMessageSendingOperations.convertAndSendToUser(messageBody.getTargetUser(), messageBody.getDestination(), messageBody);    }} 6. 创建 WebSocket JS 创建用于操作 WebSocket 的 JS 文件 app-websocket.js,内容如下: // 设置 STOMP 客户端var stompClient = null;// 设置 WebSocket 进入端点var SOCKET_ENDPOINT = "/mydlq";// 设置订阅消息的请求前缀var SUBSCRIBE_PREFIX = "/topic"// 设置订阅消息的请求地址var SUBSCRIBE = "";// 设置服务器端点,访问服务器中哪个接口var SEND_ENDPOINT = "/app/test";/* 进行连接 */function connect() {    // 设置 SOCKET    var socket = new SockJS(SOCKET_ENDPOINT);    // 配置 STOMP 客户端    stompClient = Stomp.over(socket);    // STOMP 客户端连接    stompClient.connect({}, function (frame) {        alert("连接成功");    });}/* 订阅信息 */function subscribeSocket(){    // 设置订阅地址    SUBSCRIBE = SUBSCRIBE_PREFIX + $("#subscribe").val();    // 输出订阅地址    alert("设置订阅地址为:" + SUBSCRIBE);    // 执行订阅消息    stompClient.subscribe(SUBSCRIBE, function (responseBody) {        var receiveMessage = JSON.parse(responseBody.body);        $("#information").append("" + receiveMessage.content + "");    });}/* 断开连接 */function disconnect() {    stompClient.disconnect(function() {        alert("断开连接");    });}/* 发送消息并指定目标地址 */function sendMessageNoParameter() {    // 设置发送的内容    var sendContent = $("#content").val();    // 设置待发送的消息内容    var message = '{"destination": "' + SUBSCRIBE + '", "content": "' + sendContent + '"}';    // 发送消息    stompClient.send(SEND_ENDPOINT, {}, message);} 7. 创建 WebSocket HTML 创建用于展示 WebSocket 相关功能的 WEB HTML 页面 index.html,内容如下:     Hello WebSocket                                                                                                            WebSocket 连接:                        进行连接                        断开连接                                        订阅地址:                                                                                    订阅                                                                                发送的消息内容:                                        发送                                                    接收到的消息:                                                                             8. 启动并进行测试 为了方便测试,需要打开两个不同类型浏览器(因为用户登录后会存 Session,如果一个浏览器不同用户登录会使之前 Session 失效)来进行测试,两个浏览器同时输入地址 http://localhost:8080/index.html 访问测试的前端页面,然后可以看到并没有进入 /index.html 页面,而是跳转到Spring Security 提供的登录的 /login 页面,如下: 两个浏览器中都输入用户名/密码 mydlq1/123456 与 mydlq2/123456 进行登录,然后会回到 /index.html 页面,然后执行下面步骤进行测试: ”浏览器1”和”浏览器2”点击”进行连接”按钮,连接 WebSocket 服务端; ”浏览器1”和”浏览器2”中同时设置订阅地址为”/abc”,然后点击订阅按钮进行消息订阅; ”浏览器1”(用户 mydlq1)设置发送目标用户为”/mydlq2”,”浏览器2”(用户 mydlq2)设置发送目标用户为”/mydlq1”; ”浏览器1”(用户 mydlq1)设置发送消息为Hi, I’m mydlq1,”浏览器2”(用户 mydlq2)设置发送消息为Hi, I’m mydlq2; 点击发送按钮发送消息; 执行完上面步骤成后,可以在两个不同浏览器中观察到如下内容: 十一. 示例三:实现点对点模式(根据请求头 Header 实现鉴权) 1. Maven 引入相关依赖 “ 同示例二 2. 创建测试实体类 @Datapublic class MessageBody {    /** 发送消息的用户 */    private String from;    /** 消息内容 */    private String content;    /** 目标用户(告知 STOMP 代理转发到哪个用户) */    private String targetUser;    /** 广播转发的目标地址(告知 STOMP 代理转发到哪个地方) */    private String destination;}@Data@AllArgsConstructorpublic class User {    private String username;    private String token;} 3. 配置 WebSocket 通道拦截器 配置 WebSocket 通道拦截器,里面添加两个模拟用户: 用户 mydlq1, Token:123456-1 用户 mydlq2, Token:123456-2 /** * WebSocket 通道拦截器(这里模拟两个测试 Token 方便测试,不做具体 Token 鉴权实现) * * @author mydlq */public class MyChannelInterceptor implements ChannelInterceptor {    /** 测试用户与 token 1 */    private User mydlq1 = new User("","123456-1");    /** 测试用户与 token 2 */    private User mydlq2 = new User("","123456-2");    /**     * 从 Header 中获取 Token 进行验证,根据不同的 Token 区别用户     *     * @param message 消息对象     * @param channel 通道对象     * @return 验证后的用户信息     */    @Override    public Message preSend(Message message, MessageChannel channel) {        StompHeaderAccessor accessor = MessageHeaderAccessor.getAccessor(message, StompHeaderAccessor.class);        String token = getToken(message);        if (token!=null && accessor != null && StompCommand.CONNECT.equals(accessor.getCommand())) {            Principal user = null;            // 提前创建好两个测试 token 进行匹配,方便测试            if (mydlq1.getToken().equals(token)){                user = () -> mydlq1.getUsername();            } else if (mydlq2.getToken().equals(token)){                user = () -> mydlq2.getUsername();            }            accessor.setUser(user);        }        return message;    }    /**     * 从 Header 中获取 TOKEN     *     * @param message 消息对象     * @return TOKEN     */    private String getToken(Message message){        Map headers = (Map) message.getHeaders().get("nativeHeaders");        if (headers !=null && headers.containsKey("token")){            List token = (List)headers.get("token");            return String.valueOf(token.get(0));        }        return null;    }} 4. 创建 WebSocket 配置类 创建 WebSocket 配置类,配置进行连接注册的端点 /mydlq 和消息代理前缀 /queue 及接收客户端发送消息的前缀 /app。 @Configuration@EnableWebSocketMessageBrokerpublic class WebSocketConfig implements WebSocketMessageBrokerConfigurer {    /**     * 配置 WebSocket 进入点,及开启使用 SockJS,这些配置主要用配置连接端点,用于 WebSocket 连接     *     * @param registry STOMP 端点     */    @Override    public void registerStompEndpoints(StompEndpointRegistry registry) {        registry.addEndpoint("/mydlq").withSockJS();    }    /**     * 配置消息代理选项     *     * @param registry 消息代理注册配置     */    @Override    public void configureMessageBroker(MessageBrokerRegistry registry) {        // 设置一个或者多个代理前缀,在 Controller 类中的方法里面发生的消息,会首先转发到代理从而发送到对应广播或者队列中。        registry.enableSimpleBroker("/queue");        // 配置客户端发送请求消息的一个或多个前缀,该前缀会筛选消息目标转发到 Controller 类中注解对应的方法里        registry.setApplicationDestinationPrefixes("/app");        // 服务端通知特定用户客户端的前缀,可以不设置,默认为user        registry.setUserDestinationPrefix("/user");    }    /**     * 配置通道拦截器,用于获取 Header 的 Token 进行鉴权     *     * @param registration 注册通道配置类     */    @Override    public void configureClientInboundChannel(ChannelRegistration registration) {        registration.interceptors(new MyChannelInterceptor());    }} 5. 创建测试 Controller 类 @Controllerpublic class MessageController {    @Autowired    private SimpMessageSendingOperations simpMessageSendingOperations;    /**     * 点对点发送消息,将消息发送到指定用户     */    @MessageMapping("/test")    public void sendUserMessage(Principal principal, MessageBody messageBody) {        // 设置发送消息的用户        messageBody.setFrom(principal.getName());        // 调用 STOMP 代理进行消息转发        simpMessageSendingOperations.convertAndSendToUser(messageBody.getTargetUser(), messageBody.getDestination(), messageBody);    }} 6. 创建 WebSocket JS 创建用于操作 WebSocket 的 JS 文件 app-websocket.js,内容如下: // 设置 STOMP 客户端var stompClient = null;// 设置 WebSocket 进入端点var SOCKET_ENDPOINT = "/mydlq";// 设置订阅消息的请求地址前缀var SUBSCRIBE_PREFIX  = "/queue";// 设置订阅地址var SUBSCRIBE = "";// 设置服务器端点,访问服务器中哪个接口var SEND_ENDPOINT = "/app/test";/* 进行连接 */function connect() {    // 设置 SOCKET    var socket = new SockJS(SOCKET_ENDPOINT);    // 配置 STOMP 客户端    stompClient = Stomp.over(socket);    // 获取 TOKEN    var myToken = $("#myToken").val();    // STOMP 客户端连接    stompClient.connect({token: myToken}, function (frame) {        alert("连接成功");    });}/* 订阅信息 */function subscribeSocket(){    // 设置订阅地址    SUBSCRIBE = SUBSCRIBE_PREFIX + $("#subscribe").val();    // 输出订阅地址    alert("设置订阅地址为:" + SUBSCRIBE);    // 执行订阅消息    stompClient.subscribe("/user" + SUBSCRIBE, function (responseBody) {        var receiveMessage = JSON.parse(responseBody.body);        console.log(receiveMessage);        $("#information").append("" + receiveMessage.content + "");    });}/* 断开连接 */function disconnect() {    stompClient.disconnect(function() {        alert("断开连接");    });}/* 发送消息并指定目标地址 */function sendMessageNoParameter() {    // 设置发送的内容    var sendContent = $("#content").val();    // 设置发送的用户    var sendUser = $("#targetUser").val();    // 设置待发送的消息内容    var message = '{"targetUser":"' + sendUser + '", "destination": "' + SUBSCRIBE + '", "content": "' + sendContent + '"}';    // 发送消息    stompClient.send(SEND_ENDPOINT, {}, message);} 7. 创建 WebSocket HTML 创建用于展示 WebSocket 相关功能的 WEB HTML 页面 index.html,内容如下:     Hello WebSocket                                                                                    WebSocket 连接:                    进行连接                    断开连接                                订阅地址:                                                                    订阅                                                    TOKEN 信息:                        发送的目标用户:                        发送的消息内容:                            发送                                接收到的消息:                                                     8. 启动并进行测试 为了方便测试,需要打开两个不同类型浏览器(这里模拟通过 Header 传 Token 的方式进行用户验证,具体登录逻辑不实现,而是直接使用事先配置好的两个用户 Token 进行模拟)来进行测试,两个浏览器同时输入地址 http://localhost:8080/index.html 访问测试的前端页面 ``/index.html` 如下: 浏览器1: 用户:mydlq1 Token:123456789-1 浏览器2: 登录的用户:mydlq2 Token:123456789-2 两个浏览器中都执行下面步骤进行测试: 浏览器1和 浏览器2点击 进行连接按钮,连接 WebSocket 服务端; 浏览器1和 浏览器2中同时设置订阅地址为 /abc,然后点击订阅按钮进行消息订阅; 浏览器1(用户 mydlq1)在 TOken 信息一栏中填写模拟用户 mydlq1 的 Token 串, 浏览器2(用户 mydlq2)填写模拟用户 mydlq2 的 Token 串; 浏览器1(用户 mydlq1)设置发送目标用户为 /mydlq2, 浏览器2(用户 mydlq2)设置发送目标用户为 /mydlq1; 浏览器1(用户 mydlq1)设置发送消息为 Hi, I’m mydlq1, 浏览器2(用户 mydlq2)设置发送消息为 Hi, I’m mydlq2; 点击 发送按钮发送消息; 执行完上面步骤成后,可以在两个不同浏览器中观察到如下内容: 十二. SpringBoot 结合 WebSocket 的常用方法示例 1. WebSocket 开启跨域选项 WebSocket 配置类,里面设置允许跨域,内容如下: @Configuration@EnableWebSocketMessageBrokerpublic class WebSocketConfig implements WebSocketMessageBrokerConfigurer {    @Override    public void configureMessageBroker(MessageBrokerRegistry registry) {        registry.enableSimpleBroker("/queue");        registry.setApplicationDestinationPrefixes("/app");    }    @Override    public void registerStompEndpoints(StompEndpointRegistry registry) {        registry.addEndpoint("/mydlq")        // 设置允许跨域,设置为"*"则为允许全部域名        .setAllowedOrigins("*")        .withSockJS();    }} 2. WebSocket 用户上、下线监听 创建 WebSocket 用户上线、下线处理器,内容如下: @Configurationpublic class HttpWebSocketHandlerDecoratorFactory implements WebSocketHandlerDecoratorFactory {    /**     * 配置 webSocket 处理器     *     * @param webSocketHandler webSocket 处理器     * @return webSocket 处理器     */    @Override    public WebSocketHandler decorate(WebSocketHandler webSocketHandler) {        return new WebSocketHandlerDecorator(webSocketHandler) {            /**             * websocket 连接时执行的动作             * @param session    websocket session 对象             * @throws Exception 异常对象             */            @Override            public void afterConnectionEstablished(final WebSocketSession session) throws Exception {                // 输出进行 websocket 连接的用户信息                if (session.getPrincipal() != null) {                    String username = session.getPrincipal().getName();                    System.out.println("用户:" + username + "上线");                    super.afterConnectionEstablished(session);                }            }            /**             * websocket 关闭连接时执行的动作             * @param session websocket session 对象             * @param closeStatus 关闭状态对象             * @throws Exception 异常对象             */            @Override            public void afterConnectionClosed(final WebSocketSession session, CloseStatus closeStatus) throws Exception {                // 输出关闭 websocket 连接的用户信息                if (session.getPrincipal() != null) {                    String username = session.getPrincipal().getName();                    System.out.println("用户:" + username + "下线");                    super.afterConnectionClosed(session, closeStatus);                }            }        };    }} WebSocket 配置类中实现 configureWebSocketTransport() 方法,将上面 WebSocket 处理器加到其中,如下: @Configuration@EnableWebSocketMessageBrokerpublic class WebSocketConfig implements WebSocketMessageBrokerConfigurer {    @Override    public void configureMessageBroker(MessageBrokerRegistry registry) {        registry.enableSimpleBroker("/queue");        registry.setApplicationDestinationPrefixes("/app");    }    @Override    public void registerStompEndpoints(StompEndpointRegistry registry) {        registry.addEndpoint("/mydlq").withSockJS();    }    /**     * 添加 WebSocket 用户上、下线监听器     */    @Override    public void configureWebSocketTransport(WebSocketTransportRegistration registry) {        registry.addDecoratorFactory(new HttpWebSocketHandlerDecoratorFactory());    }} 十三. 总结 本文从原理到实践详细的介绍了WebSocket,希望你们喜欢..... 特别推荐一个分享架构+算法的优质内容,还没关注的小伙伴,可以长按关注一下:长按订阅更多精彩▼如有收获,点个在看,诚挚感谢 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-12-27 关键词: 网络 计算机

  • 盘点丨十大关键词回看中兴通讯的2020

    如何评价2020年?   是不平凡的一年,疫情给整个社会留下了不可磨灭的印记;是“危”“机”之年,全球经济不确定之危与行业转型之机在这一年激烈碰撞;是数字大年,新基建战略背景推动下数字经济取得突破性发展,为重塑新经济格局奠定了基础。 对中兴通讯来说,2020是发展之年,这一年我们克服疫情影响,稳健经营,数字赋能和运营效率同步提升。在一年的尾声,我们通过十个关键词,一起来回看中兴通讯这一年留下的印记。 1 有质量增长 2020年中兴通讯积极应对全球市场风险与挑战,实现了有质量的增长。中兴通讯近三年的研发投入年均超过120亿人民币,2020年前三季度研发投入占比14.6%,同比增长15.3%。同时,中兴通讯面向全球高校引入5000+优质创新人才,以精英化的平台培养尖端5G创新人才,进一步提升行业竞争力。经过多年积累,中兴通讯的发展已经形成研发投入,技术领先,业务增长的良性循环。 在5G网络建设上,中兴通讯凭借自身5G竞争优势,持续深耕主业,稳健经营,聚焦提效,稳步推进市场格局和份额双提升。截至2020年9月底,中兴通讯已在全球获得55个5G商用合同,与全球90多家运营商展开5G合作,覆盖500多个行业合作伙伴。 2 全球联动、科技抗疫 面对疫情,中兴通讯全力配合运营商坚守抗疫一线保障通信服务,在全国26个省82个城市为210多家医院进行4G/5G网络建设,24小时内完成武汉近20家方舱医院的5G远程医疗联合会诊系统建设。中兴通讯积极捐赠抗疫物资驰援湖北、武汉等一线,并向全球多个国家、组织及当地医院等捐赠口罩、呼吸机等物资,联合海外多家运营商进行中外医院联合会诊、中小企业远程办公保障等一系列抗疫公益行动。 同时,中兴通讯以保障员工健康、确保正常服务全球客户为优先要务。从防控机制到人员排查,从远程办公到设施物资,充分利用数字化管理手段,搭建、升级了支持数万员工的远程办公和客户服务环境,以最快速度协同运营商及合作伙伴积极抗疫,助力复工复产。 3 向下扎根、持续创新 中兴通讯不断强化底层创新,在关键技术、基础科学等方面持续探索,强化自身核心竞争力,加固护城河。截至目前,中兴通讯5G战略全球专利布局6500+件,位列5G全球战略布局第一阵营,芯片专利申请 4100+件。 在通信的核心芯片领域,中兴通讯已实现超过100种芯片的自主研发设计,覆盖通信网络所有关键产品;在自主研发的操作系统和数据库方面,金融级分布式数据库GoldenDB是目前唯一通过信通院100%测试条目的产品,已实现国内首个在大型银行核心业务系统正式商用,并助力国内首家“分布式数据库联合实验室”正式商用;工业级的操作系统在复兴号等广泛的应用,累计发货2亿套。 4 股权激励 今年10月,中兴通讯公布实施2020年股票期权激励计划。本次激励计划为公司第4次股权激励计划,公司拟授予总量不超过16,347.2万份的A股股票期权,约占公司总股本的3.5%。其中首次授予的激励对象总人数共6,123人,约占公司员工总数的8.8%。  中兴通讯持续强化核心技术领域创新研发投入,增强5G人才培养与储备力度,提升行业竞争力。公司制定本次股票期权激励计划的主要目的在于建立与公司业绩和长期战略紧密挂钩的长期激励机制,增强管理团队和业务骨干对实现公司持续、健康发展的使命感,为中兴通讯的业绩长期持续发展奠定人力资源的竞争优势。  本次激励计划将对在5G商用建设发展期保留公司骨干员工、激活内部活力,保持公司稳健经营发展起到重要作用,实现公司未来的长远良性发展,为公司和股东创造更高的价值。 5 大道至简、唯快不破 5G开启无限可能,也意味着我们将同时面对网络层面的确定性挑战和商业层面的的不确定性模式。对此,无论对于5G网络的建设和发展,还是自身核心竞争力打造,中兴通讯将始终如一的秉承“大道至简、唯快不破”的核心理念。 对于网络TCO等确定性挑战,坚持创新突破,从站点、传输、网络、运维等提供全方位化繁为简的产品及解决方案,最大限度提升资源利用率;对于商业层面的不确定性,以敏捷为魂,从网络的快速弹性伸缩、切片的灵活智能运营、能力的全面开放支持千行百业的差异化业务定制,引领商业模式创新。 6 云随需生、网随云动 基于自身在5G领域长期的技术和核心能力的积累,以及对行业趋势和需求的洞察,中兴通讯为数字经济发展注入新动能,于今年9月通过云端直播的方式发布了面向行业的5G精准云网方案,做到网随云动、云随需生,为行业客户提供积木式简单、便捷、经济的云网融合的定制方案,加速行业转型升级。 精准云网包括分布式精准云和确定性精准网,分布式精准云可以实现“一地创新,全网复制,敏捷部署”;确定性精准网可以实现精准区分用户特征和业务类型,精准调配网络资源,实现精准网络业务服务。 7 5G制造5G 在行业的实践过程中,中兴通讯有一个基本的想法,5G要自己首先使用,勇立潮头,全面转型。 中兴通讯全球5G智能制造基地践行“用5G制造5G”的理念,依托领先的5G产品和ICT能力建成了“5G+智能制造”示范工厂,聚焦5G生产,以工业互联网平台和先进制造工艺为基础,通过数字孪生、智能仓库、云化AGV和机器视觉实现生产工厂逐步的无人化。装配质量漏检率降低了80%,关键工序不良率降低了37%,操作人员减少了27%,周转效率提升了20%。该项目作为2020发改委新基建5G创新提升示范工程,荣获ICT中国2020优秀案例,目前已经形成超过10个解决方案和100多个价值场景。 8 极致云公司 中兴通讯数字化转型的愿景是做“极致的云公司”,通过数字化办公支撑全员线上沟通与办公自动化;通过数字化研发让代码入云,跨地协作;通过数字化商务实现业务系统与客户、合作伙伴、供应商的无缝对接。在降本提效的同时,能够灵活敏捷的适应外部环境变化的不确定性。 在疫情期间,中兴通讯于2月3号就实现了云复工,有3万研发人员是在云端进行研发协同,研发效率保持日常的95%。在今年10月,三千名研发人员整建制进行了为期两周的远程协同,一万多名研发人员进行为期三天的远程研发协同演练,研发效率达到了98%。 除研发外,公司的运营管理已做到了可视、协同,也实现了跟客户和供应链之间数字驱动的敏捷协同。 9 屏下摄像 今年9月,中兴终端在国内正式发布具有划时代意义的全球首款屏下摄像手机——中兴天机Axon 20 5G,其搭载极具视觉张力的全面屏,在为消费者带来极致全面的视觉进化的同时,也以屏下摄像技术的正式商用宣告智能手机迈入行业新拐点。 “离技术近、离用户更近”,中兴通讯致力于打造科技、品质、年轻的全新终端品牌形象,为消费者畅享5G科技提供更加丰富多样的选择。 10 数字经济筑路者 数字经济是大势所趋,新基建是驱动数字经济持续发展的核心,5G已经成为新基建的关键引擎。对此,中兴通讯发布关于新基建战略背景下的全新定位——“数字经济筑路者”,以创新、匠心和耐心夯实产业升级之路,通过极致网络、精准云网和赋能平台,赋能千行百业数字化乃至智能化转型,为行业注入5G之‘心’。 截至目前,中兴通讯已与500+行业合作伙伴,在15个行业领域进行了86个5G创新应用实践,全力助推数字经济新基建快速发展。工业领域,中兴通讯联合运营商和多家龙头企业打造示范工程,其中神火铝业智慧工厂、5G+MEC机器视觉平台、精研科技5G+AI质检应用、湛江钢铁智慧钢厂四个项目荣获工信部绽放杯一等奖。交通领域,联合广州移动发布“全球首个5G智慧大交通示范城市”。电力领域,携手南方电网在广州实现业界首个5G R16高精度授时端到端配电网业务。教育领域,携手中国移动、新东方集团探索5G智慧教育并成功实施“5G乡村教育第一课”,开启教育公益新时代。 回顾2020年,疫情倒逼了行业数字化转型加速,中兴通讯紧抓机遇,定位为数字经济的筑路者,化压力为动力,积极发掘网络和行业潜力,实现经营与业务的稳健增长。 5G时代,数字产业将迸发类似热带雨林的强大群落生产力,将赋能各行各业,从原有简单的信息化和部分领域的自动化,向全域的数字化、网络化、智能化迈进。中兴通讯致力于在5G时代构造共生共赢的热带雨林生态系统,“向下扎根,向阳生长”,实现与客户、合作伙伴的共同发展。 一方面,中兴通讯向下在基础学科和底层能力扎根,在产品和技术维度进行创新,运营商不断提升5G云网的能力,满足行业场景下各种超高的能力要求。另一方面,中兴通讯通过极致网络、精准云网和赋能平台,赋能千行百业数字化乃至智能化转型,携手合作伙伴实现向阳生长。 未来中兴通讯将携同产业链合作伙伴,助力行业和数字经济发展,共同搭建信息沟通桥梁,让沟通与信任无处不在! 我们是一群平均从业年限5+的通信专业工程师。关注我们,带你了解通信世界的精彩!分享、点赞加在看,我们都是好伙伴 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-12-25 关键词: 中兴通讯 5G 网络

  • 据说只有千分之一的人知道5G玲珑基站

    5G系列文章回顾 1. 5G,看得见的未来 (总述) 2. 5G无线关键技术总览 3. 5G核心网关键技术总览  4. 5G承载关键技术总览 无线专题 1. 大规模MIMO自述  2. 5G RAN:您的配送服务已升级  3. 5G时代,多址技术何去何从? 4. D2D,让通信的方式简单点 5. MUSA,5G物联网为什么需要你? 6. 是兄弟一起上,5G UDN不负众望 7.上行要想快,还需FAST带 8.5G RAN节能 9.5G时代,你还在手工调天线吗? 10.SSB 1+X:不管你站得多高,都让你的手机信号满满! 11.深度解密5G多接入边缘计算 核心网专题 1. 5G切片,切的究竟是什么? 2. SBA,你对5G核心网做了什么? 3. 5G核心网,这次你是真的变了吗? 4. 移动边缘计算,站在5G“中央”? 5. 朋友一生一起走,计算存储要分手  6. 聆听5G的声音!  7. MANO,你凭什么编排我的人生? 8. 云“养”核心网,NFV你准备好了吗? 9. 您的新朋友OpenStack正飞奔而来,请做好准备 10. 当信令网遇上5G 11.5G时代,短信演进之路 12.先理解智能,再谈硬件加速 13.融合计费,为何成为5G新宠? 14.服务化的5GC,由谁来控制? 15.5G分流,为了更好的遇见 16.靠近核心的LMF,让你的定位服务更好用 承载网专题 1. ROADM为承载网带来了什么? 2. 5G时代,是谁撼动了MPLS的江湖地位? 3. 5G是如何传输数据的? 4. 什么是SDON软件定义光网络? 5. 5G时代,是谁为数据中心带来了新的活力? 6. 5G承载网,你的路修好了吗? 7. 是谁让5G光传送网(OTN)变得更灵活及强大? 8. 5G时代,以太网家庭幸福的秘诀是什么?  9. 你以为的北京时间,是真的北京时间吗? 10.堆叠,你能为5G做些什么? 11.No PULL, Just PUSH! 12. 数据中心也要迎战5G了? 13. 原来你是这样的5G电信云! 14.5G电信云数据中心的逻辑组网 15.“云诊断、云课堂、云旅游...”背后的力量 16.5G承载网,你的稳定我来守护 17.5G时代,PON出“新花样” 5G知识抢先看 欢迎继续关注后续精彩 同时 真诚欢迎您留言对5G技术的需求 我们将竭诚为您服务 我们是一群平均从业年限5+的通信专业工程师。关注我们,带你了解通信世界的精彩!分享、点赞加在看,我们都是好伙伴 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-12-25 关键词: 5G 网络

  • DHCP server down告警案例分析

    某地一台ZXR10 M6000-S在正常运行期间,偶尔出现DHCP server down告警,且此告警的地址192.168.2.1在设备上并未进行配置,属于不相关告警。告警如下: ZXR10 M6000-S版本:V3.00.11(3.71.0)。 根据故障现场的判断,有以下可能原因: 1. 设备自身配置错误,与该地址进行了交互。 2. 设备收到了非法的DHCP报文,产生告警。 1. 查看ZXR10 M6000-S上的DHCP相关配置,发现并没有配置192.168.2.1这个DHCP服务器地址,应该不会主动和它进行交互,判定应该是被动接受该服务器发来的DHCP广播报文导致故障。 DHCP服务器相关配置如下: 2. 根据地址192.168.2.1判断应该是私设的DHCP服务器导致,需要在M6000-S上进行debug抓包处理,方法如下: 3. 设置完毕后,就需要等待告警的再次发生。如果收到了同样的告警后,可以停止打印,使用Ctrl+D命令关闭debug功能。 4. 等告警再次出现后,使用命令将文件打印保存出来,查看打印信息的命令为more /datadisk0/LOG/DEBUG/dhcp,在文件中搜索192.168.2.1内容: 通过上述内容可以看出,都是ZXR10 M6000-S被动接受的广播报文,没有主动去和它交互的报文,且通过告警可以看到收到该报文的接口和报文的MAC地址为7888.6d30.e251。 通知客户,在二层网络上寻找这个MAC地址,将其剔除网络,故障排除。 DHCP server down告警一般是指定的DHCP服务器故障导致,但是本次告警属于设备上不存在的地址告警,属于非法DHCP服务器干扰导致,可以根据以上方法确认其MAC地址,然后将其移出网络以解决问题。 我们是一群平均从业年限5+的通信专业工程师。关注我们,带你了解通信世界的精彩!你点的每个在看,我都认真当成了喜欢 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-12-25 关键词: DHCP 网络

  • 中兴通讯5G大容量场景保障技术方案

    在5G时代,您是否参加过大型峰会、体育赛事、演唱会等重要的现场活动?担心在这类活动场景中实时在线分享图片及视频时卡顿? 中兴通讯5G网络技术研究专家们专治各种网络疑难杂症,本文带您解密保障5G大话务场景解决方案。 下期预告 对于高价值、高层建筑群、CBD商业高层楼宇的5G网络立体全方位覆盖,是未来5G网络建设的一个重要场景。 如何高效、低成本的实现5G高层覆盖,让百米高楼也能畅快体验5G呢? 下期小编将带您解密中兴通讯的创新方案:SSB 1+X。在保证水平覆盖良好的情况下,可进一步拓展垂直覆盖能力,根据高层楼宇覆盖需求灵活配置垂直波束,进一步为高层楼宇5G室内用户提供更好的网络体验。 期待的小伙伴记得点赞哟~~ 我们是一群平均从业年限5+的通信专业工程师。关注我们,带你了解通信世界的精彩! 你点的每个在看,我都认真当成了喜欢 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-12-25 关键词: 5G 网络

  • 5G切片+8K超高清商用首播闪耀咪咕汇音乐盛典

    近日,在第十四届音乐盛典咪咕汇—“全球首场5G+8K+云演艺盛典直播”上,咪咕视讯、广东移动、广州移动和中兴通讯基于5G SA商用网络实现了5G切片+8K超高清直播。这也是继去年珠海5G 8K春晚直播后,中兴通讯又将5G切片技术应用在视频现场直播中。 本次咪咕汇盛典包括广州宝能主会场及雷曼展厅等分会场,通过广州移动5G切片网络实现主会场多台8K摄像机的超高清直播信号实时上行回传和下行分发至第二现场,真正实现了多场景、跨地域的沉浸式盛典观看体验。在活动中,中兴通讯提供基于2.6GHz和4.9GHz 的5G上下行网络解决方案,包括切片配置、网络优化、CPE终端等设备和服务。         咪咕视讯和广东移动、广州移动一直致力于5G+视频应用的探索创新,为用户提供高品质的产品服务,在5G+VR直播技术中积累深厚。而中兴通讯作为全球领先的视频解决方案提供商,一直在联合产业合作伙伴共同推进基于5G网络的视频创新,现已形成了一套端到端的5G+VR视频解决方案。各方在今年上半年就合作实现了业界首个基于5G MEC的8K VR业务试商用,为用户带来了“全景赏花城”的极致视觉体验。9月,又携手完成了2.6+4.9GHz双频组网下3路4K直播+1路8K VR直播并发的商用演示,为此次活动顺利举行奠定基础。 业内人士认为,本次咪咕汇的创新实践意义非凡,在现网实践了5G网络切片赋能超高清视频直播行业的新模式,改变了直播场馆专线难以到达、采集位置容易受限、难以匹配移动场景等不便利的现状,通过5G网络更便利地打通了一条超高清视频采集端、传输端、播放端真正具备“大带宽”、“低延时”网络特征的“超高清直播专用通道”。同时,这也是对5G+8K超高清产业链国产化标准的一次检验,为超高清视频采播的普及和推广摸索了示范应用经验、提供了参考案例,也为相关基于超高清视频的诸如专家远程指导排障和维护、专家远程指导手术、远程指挥等行业应用提供了可借鉴参考。 未来,咪咕视讯、广东移动、广州移动和中兴通讯将继续推进高清VR产业迈上新的台阶,助力5G视频业务的全面升级,给用户带来全新的视觉体验。 转载自:中兴通讯 我们是一群平均从业年限5+的通信专业工程师。关注我们,带你了解通信世界的精彩! 你点的每个在看,我都认真当成了喜欢 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-12-25 关键词: 5G 网络

  • 5G领跑者的坚守

    全球领先的综合通信解决方案提供商 中国最大的通信设备上市公司 全球最具价值品牌500强 国家高新技术创新示范企业 …… 这是中兴通讯的印迹 而疫情之下的2020年 全球经济形势严峻 中兴通讯的步子迈向何方? 后疫情时代,5G引领下的数字经济加速 中兴通讯在5G领域又有哪些动作? 本期《璐演》对话 中兴通讯执行副总裁 首席运营官谢峻石 在主持人邓璐博士的“三问”中 我们似乎可以找到答案 (建议在wifi环境下观看专访视频) 惟其艰难,更显勇毅。 2020世界5G大会期间,中兴通讯以“筑路数字经济,绽放5G价值”为参展主题亮相大会,带来最新创新技术和方案,展示新基建大背景下如何利用5G技术赋能各行各业数字化转型的典型场景成功案例。 Q1 2019年业绩说明会,李自学董事长表示 2019年是“谨慎、艰难、扎实”的一年。 如果让您来形容2020年的中兴 您会用什么词? 关键词:“三步走”战略 谢峻石 实际上我们在2018年之后对中兴通讯新的发展制定了“三步走”的战略。 2018年到2019年是恢复期,希望公司的经营能够恢复到2017年的水平;2020年到2021年是发展期;2022年我们希望公司能够进入战略的超越期,所以2019年属于我们恢复期的最后一年。 从今年年初疫情到中国5G的快速发展,我觉得作为我们中兴通讯战略发展期的第一年,为我们后续的发展奠定了良好基础。 如果要用几个词来形容2020年的中兴通讯,我想第一个是“凝心聚力”,尤其是在今年疫情当下,我们所有7万名员工跟我们全球的客户合作伙伴以及整个产业链一起凝心聚力,为整个通信行业的发展,为整个5G的发展贡献自己的力量。我们克服供应链、生产、生活等方面的困难,大家携手同行。聚的是力量,聚的是人心。 第二个词我想用“突破”,中国5G商用一年多,今年第三季度我国已提前完成了年底建成60万个5G基站的目标,有1.6亿的终端的连接。 全球的数据是95万个基站,中国已经超过了70%,这里面中兴通讯也做出了自己应有的贡献。我们目前在国内的基站发货数量已超过20万个,基本上是占比超过30%的市场份额,同时我们也积极拉动我们上下游的合作伙伴,一起来建立一个5G开放共赢的生态。 不管是在国内的5G建设,还是在整个5G行业,甚至包括在我们整个全球各业务方面,我们还是取得了一定的突破。 第三是“数字化”。这也是今年的热门话题。所有的伟大其实都是被逼出来的,如果没有这种外在的动力压力,其实一个企业发生变化也是蛮难的一件事情。 罗马不是一天建成的,中兴的数字化也不是一天铸就的。 面对行业的碎片化需求,中兴通讯以行业场景为中心,依托分布式精准云和确定性精准网,为行业客户提供积木式灵活便捷的云网融合定制方案,助力行业转型升级。 目前中兴通讯已在工业、交通、能源等15个行业发展了超过500家合作伙伴,共同探索了86个5G创新应用场景,全球范围成功开展超过60个示范项目。 在5G行业展区,中兴通讯集中带来了5G智慧交通、5G智慧钢铁、5G智能电网、5G智能制造、5G全息访谈等7大行业应用成果展示。 其中5G智慧钢铁以沙盘形式,直观地呈现了基于5GC下沉的工业互联专网,在高炉皮带机器人、风机预测性维护、机器视觉、无人智能行车等多个场景部署的5G创新应用,该项目由广东联通、湛江宝钢、上海宝信、中兴通讯联合打造,是全国第一个商用的整套5GC下沉的工业互联专网,荣获工信部第三届“绽放杯”大赛一等奖。 Q2 怎么去定义中兴的角色? 是领跑者还是跟随者? 5G商用中国一定是领跑者,你认同吗? 关键词:5G先锋 谢峻石 我们在2016年给自己定义的就是“5G先锋”角色。我们希望能够做到技术领先、商用领先,以及市场规模的领先。从今年的情况来看,我觉得我们至少在5G领域是领跑者。 至于中国在5G商用上的领跑,我非常认同,而且我们也有底气跟信心,使得中国在全球5G领域成为一个领跑者。 第一,国家重视。把5G上升到整个国家的战略,已经作为新基建的一个基石,得到了各级政府的大力支持。 第二,我们整个通信行业里面不管是中兴还是华为,在国内已经有一个不断成熟的产业链,而且我们确实在5G这个领域已经处于领先地位。 中国在5G标准必要专利的占比已占全球35% 以上,也意味着我们已经成为规则制定的参与者,我想这是非常大的变化。 第三,现在整个中国科技创新的氛围浓厚。一个是创新的驱动,第二个是我们的人口红利,使得我们的创新更容易转化为成果,这也进一步驱动我们愿意在创新上进行投入。 Q3 中兴通讯2017-2019年年均研发 投入约121亿元,但并未快速转化成盈利。 如何看待这个颇为尖锐的问题? 关键词:研发投入产出比 谢峻石 实际上我们从最早的90年代自主研发出第一台数字程控交换机后,就一直坚持在研发投入下功夫,积累到今天才有5G的领先。 我们现在基本上已经步入了业务增长,然后再加大技术投入,技术领先带来下一轮的业务增长的良性循环中。 通信行业有两个特点: 第一,你没有办法做“小而美”的公司,我们必须要保持不断的增长,这是我们前进的方向。 第二,我们一定要有市场占有率的不断提升。如果哪一天我们能够在这个行业里排名第三,甚至第二,我们整个的收益或者研发投入的一个产出比才能够更高。 5G正成为新基建的核心引擎。中兴通讯致力于成为数字经济筑路者。 在产业层面,中兴通讯定位为数字化产业的引领者,聚焦数字信息领域,不做“万能胶”,坚持在自身领域做强做扎实;   在方案层面,采用精简积木化组合架构,为行业客户定制精准服务,让不同的领域能够快速的实施;   在产品层面,发挥芯片、嵌入式操作系统、数据库等核心技术优势,支撑各行业数字化解决方案,为用户来赋能,来提升整个产业的快速成熟度。 目前中兴通讯正不断加大研发投入,持续创新,例如中兴通讯基于Massive MIMO技术的深厚积累,创新提出SSB 1+X立体协同覆盖方案,可将高层楼宇的覆盖性能提升30%以上;推出PowerPilot绿色节能解决方案,在传统载波/通道/符号关断和深度休眠等基础节能技术上,进一步通过引入AI算法,在保护用户体验基础上最大化降低网络能耗,目前已在全球20多张网络超过600,000站点商用等。 在自主研发展区,中兴通讯重点展示了自研芯片、操作系统、分布式数据库、数通产品等领域取得的最新成果,其中工业级操作系统获得中国工业大奖,已在电信、高铁等关键行业广泛应用;GoldenDB分布式数据库已率先在大型银行核心业务系统成功投产。 中兴进入5G领域已经有很多年的累积,谢峻石觉得,在广东或者粤港澳大湾区实现5G商用可能会更优先、更领先的原因,主要在于创新氛围和行业聚集。 “整个大湾区的年轻活力、对人才的培育培养机制特别好,形成了大家一起创新的氛围。另外,物以类聚,大家抱团打天下,5G行业里越来越多的人聚集在此。5G时代,我们不是工业时代的零和关系,更像在热带雨林一个共生的生态里,大家一起把上下游的产业链聚合起来,才能够把共同的事业做大。” ▲ 谢  峻  石 当疫情给世界经济按下了暂停键时,5G所引领的数字经济新发展却给经济重新启动注入新动能,为疫情防控、保障人民生活、对冲行业压力、促进传统经济转型提供了有力支撑。 共生赋能,全心开放。不难看出,中兴通讯正努力走出困境,携手行业合作伙伴共探5G,赋能千行百业,推进5G产业生态繁荣,推动数字经济发展再上新台阶。 本文来源:公众号“璐演” 我们是一群平均从业年限5+的通信专业工程师。关注我们,带你了解通信世界的精彩! 你点的每个在看,我都认真当成了喜欢 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-12-25 关键词: 5G 网络

  • TCP:一个悲伤的故事

    漫画描述了 TCP 协议的基本原理,为了提高可理解性,部分细节设计与真实的 TCP 协议有所差别,但总体思想与 TCP 一致。 如果读者想了解 TCP 的设计细节,请参考严肃学术材料和 RFC 文档 通过本文相信读者能更深刻地理解 TCP 协议,它是个面向连接的可靠传输协议,提供了复杂的拥塞控制与流量控制的功能。当然 TCP 协议博大精深,文中只是介绍了一些皮毛,如若想进一步了解,建议大家读一读,卷一即可,或者看小林的图解网络 PDF。 最后,原创不易,漫画更不易,如果大家有收获,希望大家能来个三连支持一下。 哈喽,我是小林,时而图解技术,时而说些杂事,时而拍拍猫片。 推荐阅读 硬不硬你说了算!近 40 张图解被问千百遍的 TCP 三次握手和四次挥手面试题 你还在为 TCP 重传、滑动窗口、流量控制、拥塞控制发愁吗?看完图解就不愁了 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-12-25 关键词: TCP 网络

  • 每月6万元起,这个5G专网收费贵不贵?

    本文来源:网优雇佣军 关注点 一、这估计是全球首个确定5G专网收费模式和标准。 二、开启了设备商与运营商在5G专网市场上抢生意模式。 日前,日本设备商NEC宣布推出Local 5G服务,并公布服务收费标准。 服务项目包括咨询服务、集成服务和托管服务。 咨询服务,包括需求分析、无线环境评估、终端验证、演示实验等,指根据客户需求和现场环境提出最佳的可行性方案。 集成服务,包括现场勘测、设计和端到端验证,以帮助企业部署5G专网,并协助企业申请5G专网频谱许可。 托管服务,指全年365*24为企业提供包括网络监控、日常维护和故障修复等服务,相当于“代维服务”吧。 这三项服务的收费标准如下: 咨询服务和集成服务费用根据企业不同的部署需求单独估算。 值得关注的是,托管服务,包含了提供5G专网核心网和基站设备,采用按月收费的方式,每月费用为100万日元起(约合人民币6.3万元)。 换句话讲,针对5G专网市场,NEC并不单独售卖5G网络设备,而是提供包括网络设备和代维服务的一体化打包的服务模式。 所谓“每月100万日元起”又是什么意思呢?如果一家企业的5G专网采用最低配置,即一个5G核心网和一个5G基站(包含CU、DU和RU设备),那么每月向NEC支付的托管服务费用为100万日元。当然,网络规模越大,费用也随之增加。 回到文章开头提到的关注点,NEC作为一家电信设备商,直接向企业提供5G专网服务,这明显是直接与运营商抢生意嘛,为什么会出现这种情况呢? 要回答这个问题,得从日本的Local 5G说起。 什么叫Local 5G?就是允许电信运营商以外的垂直行业(包括企业、地方政府等)采用独立频段部署自己的5G专网。 众所周知,3GPP R16定义两种5G专网部署模式:SNPN(独立的非公共网络)和PNI-NPN(公共网络集成NPN)。 PNI-NPN,就是我们常说的“公网专用”,指企业可通过与运营商5G公网共享RAN,或者共享RAN和核心网控制面,或者端到端共享5G公网(端到端网络切片)的方式来部署5G专网。 SNPN,就是我们常说的“独立部署模式”,指企业独立部署从基站到核心网到云平台的整个5G网络,与运营商的5G公网隔离。这意味着工厂或园区内的设备信息、控制面信令流量、用户面数据流量等都不会出园区。 日本的Local 5G,顾名思义,就是“独立部署模式”。 同时,为了帮助各行各业“独立部署”5G专网,日本还专门为行业分配了5G专网频段,企业只需申请,并获得许可后,每年缴纳一定的费用,就可以使用了。 2019年4月,日本总务省向日本四大移动运营商分配了总计2200MHz带宽的5G公网频率资源。 随后2019年9月,日本总务省又计划为Local 5G分配4.6GHz-4.8GHz频段和28.2GHz-29.1GHz频段。 2019年12月24日,日本总务省宣布垂直行业可申请Local 5G频率牌照。本次申请范围仅限于28.2GHz-28.3GHz频段。 2020年12月21日,也就是昨天,日本总务省再次扩大Local 5G频段申请范围,进一步释放了4.6GHz-4.9GHz和28.3GHz-29.1GHz频段给垂直行业。 也就是说,到目前为止,日本总共释放了1200MHz带宽的频谱资源给垂直行业独立部署5G专网。 1200MHz带宽,这是日本四大运营商5G公网总频谱带宽的一半以上啊,不难看出,日本政府对独立5G专网的支持力度还是非常大的。可以说,日本推行的就是“5G公网+Local 5G”双轨发展的5G战略。 这样一来,垂直行业在频谱资源上也彻底摆脱了运营商,从而可真正的完全独立部署5G专网。 这也意味着,设备商可以直接跳过运营商,向各行各业售卖5G网络设备,以及提供5G专网服务了。 但问题是,虽然企业可申请这些频段来独立部署5G专网,但网络规划、设计、建设、维护和优化这些工作需要大量专业知识和经验,垂直行业不具备这些能力;同时,5G核心网和基站设备昂贵,企业建网初期投资成本很高。这些都是企业独立部署5G专网面临的难题。 也许正是看到了这些市场机会,NEC率先推出了这种一体化打包的5G专网服务模式。 不过,每月100万日元起,这个费用高不高呢? ~END~ 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-12-25 关键词: 5G 网络

  • 尴尬!美国的“假5G”露馅了

    尴尬!美国的“假5G”露馅了

    12月23日消息,据外媒报道,近日《PC Magazine》的Sascha Sagan做了一个测试,他发现美国电信巨头Verizon新的全国5G网络比其LTE网络要慢。以至于用户智能选择完全禁用5G,除非他们靠近毫米波(mmWave)网络。 他指出,动态频谱共享(DSS)是罪魁祸首。这项技术让运营商可以同时运行LTE和5G网络,对于像Verizon一样没有足够的专用5G频谱的运营商来说,有很大的用处。 虽然Verizon也已开始在全国范围内推出中频段5G网络,承诺通过使用DSS来避免毫米波的范围问题。但唯一的问题是,这项技术会导致在大多数情况下运行在5G模式下的手机性能变差。 (资料图) 此外,测试还发现,在美国几家运营商中,T-Mobile尽管使用的是专用的5G频段,但5G网络同样会比Verizon的LTE要慢。而同样的全国性测试还显示,AT&T也使用DSS技术,其5G也可能比LTE慢。 不过,对于Verizon来说,这也可能只是一个暂时的问题。随着Verizon继续增加专用的5G频谱,它们的速度将会进一步提高。

    时间:2020-12-24 关键词: 5G 网络

  • 5G时代高铁覆盖解决方案研究

    本文来源:邮电设计技术 摘要 针对5G高铁覆盖面临诸多困境,从5G网络高频段、高功耗、高传输带宽需求、多普勒频偏、频繁切换、穿透损耗大等方面进行了分析。针对高铁场景特征及业务体验需求,研究并提出5G高铁覆盖解决方案和规划设计方法,为运营商在高铁场景快速部署5G网络提供技术支撑。 01 概述 截至2018年底我国高铁里程达2.9万km,2025年将达3.8万km,累计发送旅客人数已超70亿人次,在4G时代,各大运营商针对高铁覆盖属于品牌场景网络建设的重中之重。随着高铁用户规模增长及多样化的业务感知要求,在5G大规模建设和应用中,对5G高铁覆盖解决方案的需求是非常迫切的。 5G高铁覆盖方案将面临诸多困境,如5G网络高频段、高功耗、高传输带宽需求、多普勒频偏、频繁切换、穿透损耗大等。本文针对高铁多种场景,研究并提出对高铁的5G覆盖解决方案和规划设计方法,指导快速推进5G时代的高铁覆盖及精品高铁网络建设。 02 5G高铁覆盖的重要性及技术难点 2.1  5G高铁覆盖的重要性 高铁建设全面铺开,快速化、信息化已成为趋势:中国高铁里程占全球60%,成为中国人出行第一选择,累计发送旅客人次已超70亿,年增长率超35%。在高铁信息化及高铁用户快速增长的趋势下,5G时代运营商需要针对高铁覆盖拟定针对性的方案,在网络覆盖及用户体验上形成优势。 高铁乘客特征和运营商价值客户高度重合,是运营商的网络品牌的重要展示窗口:高铁运输能力大,单车容纳能力高,且环境舒适,用户业务使用比例高,整体业务需求较其他场景大;高铁用户中商务人士乘坐比例高,高端客户占比大,对于提升网络品牌具有重要意义,是5G时代网络建设的重点。 2.2  5G高铁覆盖技术难点 高铁普遍存在的三大挑战:多普勒频偏、频繁切换、穿透损耗大。由于5G主力的3.5GHz频段频率高于4G, 5G时代高铁覆盖更加困难,5G网络覆盖解决方案需要重点关注站点规划与布局、系统切换重叠区域设计、频率纠偏等方面,实现更好网络性能。 2.2.1   多普勒频偏影响接收机解调性能 5G无线通信系统要求峰值移动性支持≥500km/h,高速移动下的多普勒频偏(接受信号频率会偏离基站侧中心频点)会影响接收机解调性能,多普勒频偏在5G网络影响更大,3.5G相对1.8G频偏增大一倍,在3.5GHz情况下,列车速度达到350km/h时,上行多普勒频偏将大于2.2kHz,因此,在高频段、终端高速移动状态下如何克服多普勒频偏是5G网络关键技术难点之一。多普勒效解决方案主要为通过基站设备纠偏算法,进行用户的频率纠正来消除多普勒频偏移带来影响。 表1 不同频段的上行最大多普勒频偏 2.2.2   超高速移动导致切换区不足及频繁切换问题 5G无线通信系统的系统可靠性需求为99.999%,端到端时延<1ms,在列车时速350 km/h,切换区域超过90米,高速移动时所需要的重叠覆盖距离明显高于普通场景,且由于5G站距相对更小频繁切换问题明显。高铁速度350km/h、站距500米情况下,平均3s切换一次,终端用户在小区频繁切换,切换时带来的吞吐率体验下降明显,甚至掉话增加(如图1所示)。 图1 高铁小区切换示意 频繁的小区切换将极大降低用户的感知,成为5G网络关键技术难点之一。解决办法需要合理的无线网络规划和参数设置,实现更快的小区重选和合理的小区重叠区满足小区间切换要求,同时,通过小区合并可以减少小区间切换次数,提高速率性能及可靠性。 2.2.3   5G高频段的车体穿透损耗更大 5G无线通信系统的目前使用频段为3.5 GHz,自由空间损耗及车厢损耗较1.8 GHz频段高,其中自由空间传播损耗高6 dB,车体传播损耗高3~5 dB。CRH380A车厢整体穿透损耗平均值约20 dB,3.5 GHz频段穿透损耗更高约25 dB,不同车型采用材质差异,穿透损耗差异也很大(见表2),且基站到高铁的入射角越小,损耗越大,因此,在网络规划设计时入射角应控制在10°以上,基站到高铁最小距离为:80~200 m。 表2不同列车不同频段的穿透损耗(dB) 03 高铁多场景覆盖规划方案 3.1   规划目标建议 目前阶段高铁主要以视频、游戏、社交、办公类等eMBB业务为主。根据4G高铁数据统计,高铁业务模型与大网eMBB类似,文字、图片带宽需求变化不大,视频业务占比56%左右,未来业务较长时间内仍以“高清视频”为核心,带动流量增长。 5G初期,eMBB主要以2K视频+智能手机、4K视频+HDTV/VR为主要业务(见表3);其中2K视频是5G业务最小业务要求,高铁场景大部分时间处于200~350kmh高速运行,边缘速率规划建议按照4K视频业务需求:下行速率要求>50Mbps,上行速率可根据不同覆盖目标要求确定,初期建议UL>1Mbps,后续再分阶段考虑>5Mbps满足1080P视频上传要求。 高铁场景边缘速率规划建议:DL 50Mbps,UL 1 Mbps /5Mbps。 表3  eMBB业务带宽需求 3.2   链路预算分析 合理站址规划是网络质量基石,在网络规划选址既要充分考虑利用现有资源,同时也要考虑站址规划合理性。目前中国获取5G频谱资源为3500~3600 MHz, 根据业界内专家的初步评估,3.5 GHz频段的总损耗比1.8 GHz约大14 dB,主要表现在空间损耗、车厢穿透损耗及间隙发射带来损耗。基于目标边缘吞吐量的小区半径链路预算分析如表4所示,从表4可以看出,5G站址规划站距势必比4G网络更密。 表4 基于目标边缘吞吐量的小区半径链路预算 (2.5ms单周期) 从基于目标边缘吞吐量的小区半径链路预算分析,Cost-Hata模型与3GPP模型测算站距差异较大,按目前广东联通高铁4G现有存量站址站距600~800 m,至少需增加1倍以上站址方可满足5G网络覆盖要求,这对运营商来说是一项艰巨的任务,主要表现在站址选取、物业协调、工程建设、投资成本以及管道传输资源等方面。如何克服高频段损耗站点过密问题、降低建设成本,成为重中之重。 NR下行可以和LTE现网1:1共站,通过上下行解耦、DC双连接提升上行覆盖:从链路预算及速率满足情况来看,5G高铁覆盖主要表现为上行受限,小区边缘速率超过50Mbps,可以实现和4G现网站点1:1共站。从上行边缘速率情况来看,5G相对LTE FDD存在上行覆盖受限,需要上下行解耦或DC双连接提升上行覆盖,解耦后上行速率提升明显。小区实际覆盖半径可根据具体站点规划情况确定,在1:1基础上,进行个别站点补充满足规划目标。 图2给出了边缘吞吐率与小区半径的关系示意。 图2  边缘吞吐率与小区半径的关系 3.3   切换区域设计 由于5G无线通信系统的需求,系统可靠性为99.999%,端到端时延<1ms,在列车时速达350 km/h,双向切换区域范围较大。终端用户在小区频繁切换,切换时带来的吞吐率体验下降明显,甚至掉话增加,因此,减少小区间切换是提升高铁用户体验感知的关键。 5G系统需要的切换重叠区域测算如图3所示,A过渡区为信号到满足切换电平迟滞(~2dB)需要的距离,并且考虑防止信号波动需重新测量而影响切换的距离余量。B切换区域:时延1为终端测量上报周期+切换时间迟滞,时延2为切换执行时延,包括信令面及数据面执行时延。 图3  切换重叠区域测算示意 合理的重叠覆盖区域规划是实现业务连续的基础,重叠覆盖区域过小会导致切换失败,过大会导致干扰增加,影响用户业务感知,实际规划中,根据网络参数配置及时延要求评估,进行合理的切换区域设计。考虑单次切换时,重叠距离= 2* (电平迟滞对应距离+切换触发时间对应距离+切换执行距离)。 以常用配置(切换测量及判决160ms、切换执行20ms)为例,不同列车速度对应的重叠距离需求如表5所示,5G网络的小区间重叠覆盖距离150m,可以满足小区间切换重叠覆盖区要求。 表5 不同列车速度对应的重叠距离需求 小区合并应用建议:根据4G网络经验,综合考虑大网用户的容量和性能,合理选择RRU共小区方案,是减少频繁切换、提高用户感知的有效方案。5G网络中也需要继续采用RRU合并解决切换问题,5G采用hypercell(相同逻辑小区)技术小区合并后,广播信道共小区,形成一个逻辑小区,其业务信道TRP可独立调度,容量无损,有效保障用户感知。 Hyper Cell:基站侧基于上行信号判断切换,用户在同一个逻辑小区内移动时不感知TRP变更。 3.4   高铁线路覆盖方案 线路站址规划:高铁线路覆盖站址建议以“之”字形布站,以最大限度保证列车两边座位都有比较好的覆盖,尤其是在列车会车的时候能保证车内通信质量最佳。 站轨距:据无线信号传播特点,信号入射角越小,穿损越大,通常建议入射角大于10度,考虑到天线水平波瓣在90度方向增益约为0dBi,为保证不出现塔下黑,根据链路预算,建议站点离铁轨距离不超过200m。 站高:站高设计需保证信号直射径能从列车玻璃穿透,减少信号从车顶穿透几率,天线相对铁轨高度在20~45m为宜;方位角:不同入射角对应的穿透损耗不同,入射角越小,穿透损耗大。实际测试表明,当入射角小于10°以后,穿透损耗增加的斜率变大,因此方位角设置中应保证天线与铁路夹角大于10°;下倾角:5G高铁场景天线下倾设置原则, 天线垂直波束最大增益方向指向边缘。 入射角与基站离铁轨的距离关系示意如图4所示。 图4 入射角与基站离铁轨的距离关系示意 建议相对站高在20~45m,站点离铁轨距离在35~120m,保证列车两边座位都有比较好的覆盖。 高铁线路覆盖设备选型建议:高铁场景中2T/4T无法满足一般站间距规划,8T可满足500~650m站间距覆盖,32T/64T可满足相对较大覆盖距离(见表6)。32T/64T理论上覆盖好于8T,容量高于8T,但小区合并、波束赋形算法难度更大、要求高,需要根据高铁线路场景及业务情况,并综合考虑成本、技术成熟度,确定建设方案,从目前厂家设备情况来看,8T方案的成熟度最高。 表6 不同类型设备覆盖对比 3.5   高铁隧道覆盖方案 高铁隧道由于隧道空间狭小,列车速度快,生产风压及安全性考虑导致无法采用常规天线覆盖,建议隧道内采用泄露电缆进行覆盖(见图5),两侧洞口采用定向天线朝外延伸,增大室外宏站与隧道区域的重叠覆盖带区域,保证切换的顺利完成。 图5  高铁隧道覆盖示意 表7给出了覆盖方案的对比。 表7 覆盖方案对比 漏缆及POI情况分析及建议:存量13/8漏缆规格无法支持3.5 GHz,最大截止频率为2.9GHz,无法满足5G演进,采用5/4漏缆可支持3.5GHz,优选2T2R漏缆方案。3.5GHz漏缆的2种部署方案,建议采用漏缆替换方案。 a) 800M~3.6G全带漏缆替换存量漏缆:无额外安装空间要求,对sub3G KPI存在恶化风险。 b) 新增3.5G only窄带漏缆:指标更好,不影响sub3G KPI,但有额外安装空间要求,安装位置导致穿损更大。 存量POI无法支持3.5GHz,也只支持2.6GHz频段60MHz,NR3.5GHz需新增或替换POI,建议隧道组网使用POI+漏缆,3家运营商共建共享,降低建设难度及成本。 3.6   高铁站厅覆盖方案 高铁站枢纽主要功能区包含站厅、站台、出入口等,场景空旷,但容量密度高,站厅、站台小区间干扰控制存在困难。从用户分布特点来看,高铁站大厅用户密度大,高铁运行时间段内人流巨大,且用户流动性强,大量用户随列车运行移动。从业务特征来看,高铁站厅是典型高流量区域,用户数密集、业务高热。 根据高铁站厅的场景特征,建议使用数字化室设备分进行覆盖,可选择新增3/4/5G多模数字化室分模块,或在现有传统DSA系统基础上,新增5G数字化室分模块混合部署(见图6)。 图6  高铁站厅覆盖示意 站厅使用数字化室分设备具备如下优势。 a) 高性能,提升用户体验,pRRU一根缆支持4*4MIMO,提升吞吐率与小区容量。 b) 光纤+网线,缩短施工周期;端到端可维可控,与宏站共网管,降低维护成本。 c) 支持软件扩容,无需硬件改造小区灵活劈裂,应对话务持续增长,保障用户体验。 04 高铁覆盖解决方案建议 根据5G小区半径及链路预算分析,按目前广东联通高铁4G现有存量站址规模,至少需增加1倍站址才可满足5G网络覆盖要求,这对运营商来说是一项艰巨的任务,且建网成本无法承受。本文研究克服高频段损耗站点过密问题的方案,建议NR下行可以和LTE现网1:1共站,通过上下行解耦、DC双连接提升上行覆盖,在1:1基础上根据规划评估进行部分区域按需补充站点,满足规划目标。 高铁场景终端用户在小区频繁切换,切换时带来的吞吐率体验下降明显,减少小区间切换是提升高铁用户体验感知的关键。建议进行合理的重叠覆盖区域规划,并采用RRU合并解决切换问题,有效保障用户感知。 高铁完整覆盖解决方案包括线路、隧道、站厅,其中高铁线路覆盖站址建议以“之”字形布站,建议入射角大于10度,站点离铁轨距离不超过200m,天线相对铁轨高度在20~45m为宜,根据站轨距、高度、入射角规划设计合理的方位角及下倾角,保障覆盖效果。 建议隧道内采用泄露电缆进行覆盖,两侧洞口采用定向天线朝外延伸,增大室外宏站与隧道区域的重叠覆盖带区域,保证切换的顺利完成,详细评估当前POI、漏缆演进到5G条件限制,建议隧道组网使用POI+漏缆,3家运营商共建共享,降低建设难度及成本。 高铁站厅建议使用数字化室设备分进行覆盖,可选择新增3/4/5G多模数字化室分模块,或在现有传统DSA系统基础上,新增5G数字化室分模块混合部署。使用数据化室分设具备易部署、易维护、平滑扩容等优势。 参考文献 1、Vincent W.S.Wong、Robrt Schober、Derrich Wing Kwan Ng、Li-Chun Wang 《5G系统关键技术详解》  人民邮电出版社 2、Afif Osseiran、Jose F.Monserrat、Patrich Marsch《5G移动无线通信技术》 人民邮电出版社 3、沈嘉、索世强、全海洋、赵训威、胡海静、姜怡华《3GPP长期研究(LTE)技术原理与系统设计》  人民邮电出版社 4、杨峰义、张建敏、王海宁等《5G网络架构》,电子工业出版社 作者简介: 林铁力,工程师,本科,主要从事无线通信网的规划建设工作。 ~END~ 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    时间:2020-12-24 关键词: 5G 网络

首页  上一页  1 2 3 4 5 6 7 8 9 10 下一页 尾页
发布文章

技术子站

更多

项目外包