突发!5G 标准进程延后 3 个月
据可靠情报,在前两天于意大利举行的3GPP会议上,3GPP扔出重磅炸弹:R15 Late Drop冻结时间推迟3个月。
该计划推迟或将影响后续的R16版本冻结时间,也将可能导致推迟后续5G服务推出时间。
3GPP原计划在2018年12月冻结R15 Late Drop版本,并于2019年3月完成含有完整ASN.1 代码的标准版本,但本次会议决定,将R15 Late Drop版本的冻结时间推迟到2019年3月,ASN.1完成时间顺延至2019年6月。
R15为5G第一阶段标准,R16为5G第二阶段标准,该推迟计划可能将影响后续的R16版本冻结时间。原计划R16将于2019年12月冻结,而此次重新修改时间表后,R16估计将推迟于2020年3月冻结,并在2020年6月完成ASN.1冻结。
这到底是什么情况?
众所周知,2017年12月,3GPP 完成了R15 NR NSA(非独立组网)标准;2018年6月14日,世界杯前夕,3GPP发布了R15 NR SA(独立组网)标准。
但是,事实上3GPP R15标准并未完全结束。
因为R15有三个版本:R15 NR NSA、R15 NR SA和 R15 late drop。
没错,一个Release有三个版本,从来没有过。
这大概是因为2017年3GPP加速了标准制定速度,将原计划于2018年6月完成5G NR NSA标准提前到2017年12月完成,以满足部分运营商的先发需求,所以将5G第一阶段标准R15分成了三个版本分步走。
在2017年12月完成R15 NR NSA版本,2018年6月完成了R15 NR SA版本后,其实还剩下一个R15 late drop未完成。
那么,R15 NR NSA、R15 NR SA和R15 late drop到底有啥区别?剩下的R15 late drop包含了些什么内容呢?
这要从5G部署选项说起。
从3G演进到4G时,我们称之为”整体演进“,即无线接入网和核心网整体打包从3G演进到4G。
但到了5G时代,就不一样了。
4G向5G演进时,无线接入网和核心网被拆开了,并且5G无线接入网(NR)、5G核心网、4G核心网和4G无线接入网(LTE)混合搭配,组成了多种网络部署选项的演进路线。
这些选项主要包括(如下图):
选项2:独立组网(SA)模式,引入5G核心网,仅5G基站连接5G核心网。
选项3:非独立组网(NSA)模式,连接4G核心网,4G基站为主站,5G基站为辅站。
选项4:非独立组网(NSA)模式,引入5G核心网,5G基站为主站,4G基站为辅站。
选项5:独立组网(SA)模式,引入5G核心网,但仅4G基站连接到5G核心网。
选项7:非独立组网(NSA)模式,引入5G核心网,4G基站为主站,5G基站为辅站。
如上表可知,所谓非独立组网就是LTE与NR新无线的双连接,由于在具体实现上有差别,因此包含了三种构架:EN-DC(选项3)、NE-DC(选项4)和NGEN-DC(选项7)构架。
DC代表Dual Connectivity,即双连接;E代表E-UTRA,即4G无线接入网;N代表NR,即5G新无线;NG代表下一代核心网,即5G核心网。
EN-DC就是指4G无线接入网与5G NR的双连接,NE-DC指5G NR与4G无线接入网的双连接,而NGEN-DC指在5G核心网下的4G无线接入网与5G NR的双连接。
3GPP在2017年12月完成的R15 NR NSA(非独立组网)标准,就是选项3。而在6月14日完成的R15 NR SA(独立组网)标准,就是选项2。
至于剩下的选项4和选项7,将在R15 late drop版本里完成,原计划完成时间为2018年12月,而本次3GPP将完成时间推迟到了2019年3月。
R15 late drop主要包含的内容是: 选项4 (即NE-DC 构架)与选项7 (即NGEN-DC构架) 两种架构,以及NR-NR双连接(synchronous case)。
NR-NR双连接是什么呢?由于有些运营商计划采用低频段(比如700/800/900MHz频段)来建设5G网络的覆盖层,再用高频段(比如毫米波频段)来补充网络容量,但由于低和高频段的无线传播特性相差太大,共站实现载波聚合技术有些不实际,因此提出了NR-NR双连接技术。
为什么3GPP要推迟5G标准?
据说是为了预留更多的时间确保3GPP各种工作组之间充分协调,以及保证网络与终端、芯片之间更完善的兼容性等。
本次推迟标准完成时间,大多数代表都表示支持。前期因为标准制定加速,RAN工作组挑灯夜战赶进度,经常在晚上10点后还无法休息,实在是太累了。
来源:51CTO
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
伯克利开源 Confluo,吞吐量是 Kafka 的 4 到 10 倍
近日伯克利 RISE Lab 开源了一个多数据流实时分布式分析系统 Confluo,它既是一个网络监控和诊断框架,也可以作为时序数据库和发布订阅消息系统。 源码地址:https://github.com/ucbrise/confluo 当下,类似基于终端主机的网络监控系统、IoT 设备传感器程序等应用,其后端的服务器每秒都可以捕获数千万个数据点。这些数据被用于在线查询,实现可视化与监控,或者用于离线查询,进行故障分析和系统优化。这样的使用场景下,就需要实时监控和分析工具支持,这些工具通常支持高吞吐量数据提取、低延迟在线查询和低开销的离线查询。 虽然目前已经存在一些用于高吞吐量数据提取的数据结构,它们可以支持丰富的在线和离线查询,但是高吞吐量与查询能力目前来看还是互斥的。在从多个数据流提取数据时,查询需要更新多个数据结构,包括原始数据、聚合统计信息和物化视图。但是用于支持这些查询的数据结构往往具有较高的更新开销,而且无法维持大多数应用程序所需的数据提取速率。而另一方面,可以维持高数据提取速率的数据结构往往只支持非常简单的查询。 Confluo 正是为了应对这种情况而产生的,它是一个致力于...
- 下一篇
微软开源数据处理引擎 Trill,每天可分析万亿次事件
微软近日开源了数据处理引擎 Trill,它每天能够分析万亿次事件。 项目地址:https://github.com/Microsoft/trill 当下每毫秒处理大量数据正成为一种常见的业务需求,此次微软开源的 Trill,据说每秒能够处理高达数十亿事件,它结合了多模式分析支持和一系列其它功能,微软声称其它任何系统都无法完全与之匹敌。它有如下特点: 作为单节点引擎库,任何 .NET 应用程序、服务或平台都可以轻松使用并处理查询。 提供一种时态查询语言,允许用户进行实时和离线数据集复杂查询。 高性能,满足高速度与低延迟。过滤器以每秒数十亿事件的内存带宽速度运行,而分组聚合每秒运行 10 到 1 亿个事件。 该引擎用途广泛,足以处理实时数据和历史数据,目前只有少数几款开源工具拥有同样的能力。 Trill 于 2012 年开始作为 Microsoft Research 的一个研究项目,在 VLDB 和 IEEE Data Engineering Bulletin 等研究论文中进行了广泛的描述。Trill 最早来源于微软以前的服务 StreamInsight,这是一个功能强大的平台,允许开发人...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS8编译安装MySQL8.0.19
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS7,CentOS8安装Elasticsearch6.8.6