5G Internal SOC Baseline - 201801031

5月前基线库SOC数量 740
5月31日增录数量 500
总计 1240
3月前自答率 0.3
6月底自答率
5G RAN2.0 上市资料大全
5G RAN2.1 上市资料大全
5G答标领
【 KPI 1 自答率 =5G SOC基线库匹配问题(条数)/标书5G领
【 KPI 2 5G SOC基线库条数 = SOC基线库已录入问题总
产品领域
(5G/SRAN No 汇聚类别
/OSS/小站)
0 Standard Contribution
1 3GPP Compliance
2 5G Hardware
3 5G NR
4 5G Feature
5G
4 5G Feature
5G
5 5G Others
6 5G性能口径
7 5G覆盖容量仿真
产品领域
(5G/SRAN No 跨领域
/OSS/小站)
Core 1 Core
OSS 2 OSS
3 Multi-RAT Module
FrontHaul & Backhaul &

4
Sync
SRAN CU-DU Split

5
（原名CloudRAN）
6 Multi-mode Feature
7 Security
频谱 8 频谱
Use Case 9 Use Case
EMF 10 EMF
英文版
中文版
http://3ms.huawei.com/mm/docMaintain/mmMaintain.do?method=showMMDetail&f_id=5G180321451649993
http://3ms.huawei.com/mm/docMaintain/mmMaintain.do?method=showMMDetail&f_id=5G180730152114158
5G答标领域划分
KPI 1 自答率 =5G SOC基线库匹配问题(条数)/标书5G领域问题总数(条数) ，年中目标45%，年底目标75% 】
【 KPI 2 5G SOC基线库条数 = SOC基线库已录入问题总数(条数) ，年中目标1200条，年底目标1600条】
子领域（中文）子领域（英文）市场技术接口
齐飞
标准专利贡献 Standard Contribution
00381072
R15协议顺从性 R15 Standard Compliance 黎旭
5G站点解决方案 5G Site Solution
BBU规格、CU规格 BBU & CU Specification
L2/L3 规格 L2/L3 Specification

黎旭
设备O&M Element O&M
可靠性 Reliability
中射频（区分高低频） RF Specification
编码(Polar code,LDPC) Channel Coding

Numerology（区分高低频） Numerology
F-OFDM F-OFDM
Self-contained Frame（区分高低频
Self-contained Frame
）
可变带宽（区分高低频） Scalable Bandwidth
信道管理（区分高低频） Channel Management 吴俣
功率控制（区分高低频） Power Control
调度（区分高低频） Scheduling
调制（区分高低频） Modulation Schemes
空口QoS管理 Radio QoS Management
移动性管理（区分高低频） Mobility Management
Massive MIMO（区分高低频） Massive MIMO
波束管理（区分高低频） Beam Management 吴俣
D-SON（5G Only） D-SON（5G Only）
RAN Sharing RAN Sharing
SA SA Option2
语音业务（默认低频） Voice Service
吴俣
低时延（区分高低频） Low Latency
DC&CA（5G Only）（区分高低频） DC&CA (5G Only)

吴俣
WTTx（区分高低频） WTTx
UCNC 协同 UCNC Coordination
Energy Saving Energy Saving
Dynamic TDD Dynamic TDD
超远覆盖 Wide Coverage
高速场景 High Speed
Network Slicing RAN Slicing 产品管理
Counter与KPI Counter & KPI
Cell non-performance related

小区非性能相关类
functions 吴俣
mmWave Power
高频模块功耗
Consumption
IoT对接 IoT 产品管理和一线
测试类问题 Test Domain 区域/项目TSE
CPE Speed CPE Speed 涂宇
TUE Speed TUE Speed

RAN Site Speed RAN Site Speed
谢国珠
RAN Site Coverage RAN Site Coverage
RAN Site Capacity RAN Site Capacity
RAN System 覆盖仿真 RAN System Coverage

谢国珠
RAN System 容量仿真 RAN System Capacity
子领域（中文）子领域（英文）答标接口

Core Core 周智勇
EMS EMS 李永生
VNF VNF
C-SON C-SON
多模硬件（包括存量模块） Multi-RAT Module Specification SRAN MO
Transmission QoS
传输QoS管理
Management
VLAN VLAN
同步 Synchronization SRAN MO
IP路由备份 Active/Standby IP Routes
前传与无线回传 FrontHaul & Backhaul
虚拟化&解决方案 Visualization & Split Solution SRAN MO
NSA & Multi-RAT DC NSA & Multi-RAT DC SRAN MO

上下行解耦（区分高低频） UL&DL Decoupling SRAN MO
上行频谱共享 SUL SRAN MO
异系统互操作 Inter-RAT Operation SRAN MO
空口加密 Radio Interface Ciphering
IP性能监控 IP Performance Monitor 熊晓春
安全机制 Security Mechanism
Spectrum Spectrum
Use Case Use Case 余珞
EMF EMF 各产品管理分部

5G售前文档获取路径（MO）：
http://3ms.huawei.com/mm/docNav/mmNavigate.do?method=showMMList&tree_id=1-2-61621&node
5G通用路标申请途经（产品管理）：
http://gpc.huawei.com/Windchill/netmarkets/product/index.html
描述、安装与调测、操作与维护（含在产品文档）：
http://support.huawei.com/carrier/productNewOffering?col=product&path=PBI1-7851894/PBI1-22893882/PB
中文特性文档
中文产品文档：
英文特性文档
英文产品文档：
产品管理专题分工：
ＮＲ＋网络共享：曾美艳
高频：孙云韬 + 唐曙光
低频：沈月平+陈凯泓
切片和架构：张筱
节能：帅丹
路标：陈凯泓
=5G180321451649993
=5G180730152114158
45%，年底目标75% 】
，年底目标1600条】
备注评审
季度刷新，请参考链接http://3ms.huawei.com/mm/
docMaintain/mmMaintain.do?
method=showMMDetail&f_id=Mob180514062413
794
请参考上市资料大全中《Huawei NR SoC of 3GPP
Release15 2018Q3 (5G RAN2.0) V1.0.xlsx》
包含CRAN、DRAN、电源、光模块、机柜等
具体参考《DBS5900 5G V100R002C00 Product

Specification Draft 1.0》and《19A Product
Specification》
http://3ms.huawei.com/mm/docMaintain/mmMaintain.do?
method=showMMDetail&f_id=5G180321451649993
高频：廖尔东
低频：刘张宇
具体参考《19A FD》和《19B FPD》

19A
FD：http://3ms.huawei.com/mm/docMaintain/mmMaintain.do? NR+RAN Ｓ
method=showMMDetail&f_id=5G180321451649993 ｈａｉｒｎｇ
19A PD：曾美艳；
http://support.huawei.com/hedex/hdx.do?
docid=DOC1100324698&path=PBI1-7851894/PBI1-22893882/PBI1-
22894052/PBI1-22405465
及SOC库附件：NR numerology口径（5G RAN2.0）
5G MO：涂宇
具体参考《19A FD》和《18A FPD》

5G MO：周东飞
D-SON（ANR、Xn自建
立、PCI、MDT、MRO、MLB）
5G MO：付东明
5G MO：周彦
包括eMBB时延、uRLLC时延
5G MO：李华
5G Only DC and CA
5G MO：廖尔东
SA架构下RAN Slicing在5G管道；
NSA架构下RAN Slicing将会归属到LTE管道；
5G MO：李华
《5G RAN KPI参考》（含在产品文档中）
http://support.huawei.com/carrier/
productNewOffering?col=product&path=PBI1-
7851894/PBI1-22893882/PBI1-22894052/PBI1-
22405419
《功耗计算工具（BaseStation Power Consumption

Tool (PCT V201802）
》http://3ms.huawei.com/mm/docMaintain/mmMa
Sub6G、Sub3G模块功耗，统一由SRAN看护
intain.do?
method=showMMDetail&f_id=SR17062254021414
7
通用口径：协议冻结后三个月可做IoT测试
异厂家对接进展咨询：康颇/刘敏
请找区域DPM找到对口项目/区域的测试SE来答复
单独找CPE SE/MO获取
5G MO：涂宇
随版本性能口径，MO和售前网规都会发布。
http://3ms.huawei.com/mm/docMaintain/
mmMaintain.do?
method=showMMDetail&flag=expert&f_id=MSS1
80411361113090
一线售前网规从机关售前网规获取
接口人：谢国珠
一线售前网规从机关售前网规获取
接口人：谢国珠
备注
随项目获取接口人信息，本文档不负责刷新。
随项目获取接口人信息，本文档不负责刷新。
Massive MIMO SRAN MO：贾永来

射频RF SRAN MO：汪汝伟
BBU SRAN MO：程永福
参考SOC库附件《4G&5G对传输&时钟要求口径
1.0.xlsx》
SRAN MO：张丽芬
CU-DU分离口径暂不放开，有需要联系SRAN MO。
SRAN MO：李泉
SRAN MO：刘伟
SRAN MO：刘伟
SRAN MO：刘伟
SRAN MO：陈俊青
安全领域MO ：刘平 00435965
X-lab 领域MO ：余珞

ree_id=1-2-61621&node_id=1-2-61621&display_type=0
7851894/PBI1-22893882/PBI1-22894052/PBI1-22405419
7851894/PBI1-22893882/PBI1-22894052/PBI1-22405419
7851894/PBI1-22893882/PBI1-22894052/PBI1-22405465
7851894/PBI1-22893882/PBI1-22894052/PBI1-22405419
7851894/PBI1-22893882/PBI1-22894052/PBI1-22405465
7851894/PBI1-22893882/PBI1-22894052/PBI1-22405419
耗，统一由SRAN看护
5G RAN Content
No 跨领域子领域（中文）
0 Roadmap Roadmap
0 Standard Contribution 标准专利贡献
1 3GPP Compliance R15协议顺从性
5G站点解决方案
BBU规格、CU规格
L2 L3 规格
2 5G Hardware
设备O&M
可靠性
中射频（区分高低频）
编码(Polar code,LDPC)
Numerology（区分高低频）
波形（F-OFDM,CP-OFDM,DFT-s-OFDM）
Self-contained Frame（区分高低频）
可变带宽（区分高低频）
3 5G NR 信道管理（区分高低频）
功率控制（区分高低频）
调度（区分高低频）
调制（区分高低频）
空口QoS管理
移动性管理（区分高低频）
Massive MIMO（区分高低频）
波束管理（区分高低频）
D-SON（5G Only）
SA RAN Sharing
SA Option2
语音业务（默认低频）
低时延（区分高低频）
4 5G Feature DC&CA（区分高低频）
WTTx（区分高低频）
UCNC 协同
Energy Saving
Dynamic TDD
超远覆盖
高速场景
Network Slicing
Counter与KPI
5 5G Others 小区非性能相关类
IoT对接
Non-5G RAN Content

No 跨领域子领域（中文）
1 Core Core
EMS
2 OSS VNF
C-SON
3 Multi-RAT Module 多模硬件（包括存量模块）
传输QoS管理
VLAN
FrontHaul &
4 同步
Backhaul & Sync
IP路由备份
前传与无线回传
CU-DU Split
5 虚拟化&解决方案
（原名CloudRAN）
NSA & 双连接
NSA下网络共享
6 Multi-mode Feature 上下行解耦（区分高低频）
上行频谱共享
异系统互操作
空口加密
7 Security IP性能监控
安全机制
8 频谱 Spectrum
9 Use Case Use Case
10 EMF EMF
ontent
子领域（英文）
路标
Standard Contribution
R15 Standard Compliance
5G Site Solution 26
BBU & CU Specification 18
L2 L3 Specification 2
Element O&M 22
Reliability 1
RF Specification 26
Channel Coding
Numerology
Waveform
Self-contained Frame
Scalable Bandwidth
Channel Management
Power Control
Scheduling
Modulation Schemes
Radio QoS Management
Mobility Management
Massive MIMO
Beam Management
D-SON（5G Only）
SA RAN Sharing
SA Option2
Voice Service
URLLC
DC&CA
WTTx
UCNC Coordination
Energy Saving
Dynamic TDD
Wide Coverage
High Speed
RAN Slicing
Counter & KPI
Cell non-performance related
functions
IoT
Content
子领域（英文）
Core
EMS
VNF
C-SON
Multi-RAT Module Specification
Transmission QoS Management
VLAN
Synchronization
Active/Standby IP Routes
FrontHaul & Backhaul
Visualization & Split Solution
NSA & Multi-RAT DC

NSA RAN Sharing
UL&DL Decoupling
SUL
Inter-RAT Operation
Radio Interface Ciphering
IP Performance Monitor
Security Mechanism
Spectrum
Use Case
EMF
一、区域接口
区域接口
中国电联周彦 00286948
中国移动周东飞 00386399
中东周彦 00286948
中亚、俄罗斯刘倩 00167164
拉美刘倩 00167164
日韩涂宇 0030675
西欧刘张宇 00390675
东北欧彭俊 00271206
东南亚廖尔东 00441927
加拿大、北美廖尔东 00441927
南太张惠琴 00255883
Back Please apply the roadmap through：
http://gpc.huawei.com/Windchill/netmarkets/product/index.html
Product New New Sub- Version
Key word *Question *Compliant
Domain Category Category （Time）
Please present your 5G roadmap

for RAN covering Rel15 and a
5G Roadmap Roadmap NA Roadmap timespan of 5 years beyond Rel15 Other
including Rel16
How will you implement support of

mMTC and URLLC in your RAN?
For example, will bandwidth be
5G Roadmap Roadmap NA Roadmap separately allocated to eMBB, Other
mMTC and URLLC? Or does a
frame-by-frame multiplexing
happen?
mMTC and URLLC could also be
supported in existing 4G bands. In
5G Roadmap Roadmap NA Roadmap what 4G bands will you support this Other
capability
Do you have the system

CU-DU split
requirements for the Virtual
Visualization need
Machine layer for your CU
SRAN CU-DU Split & Split application virtualization FC
software? What VM technologies
Solution from SRAN
can this be supported on (e.g
MO
VMware, KVM etc)?
3GPP have recently defined the

CU-DU split
functional split of CU User Plane
Visualization need
and CU Control Plane. A new
SRAN CU-DU Split & Split application UP CP split
interface (E1) has been defined
Solution from SRAN
between the two. Do you support
MO
such configurations?
Describe how the RAN functions

will support network slicing between
eMBB, URLLC and mMTC traffic?
The demarcation between network
5G Roadmap Roadmap NA Slicing
slicing and RAN slicing appears to
be at the SDAP protocol layer in
NR. Is this where you see the
coordination happens?
Response
Response Attachment Remark
Name
Please refer to … 路标请找产品管理分部
申请或直接申请通用路
标，申请地址链接如上
。
Wire le ss
Standards related to mMTC and URLLC are yet to be 答复仅作为19B的一般
Ro a d m a p
Wire le ss
specified by 3GPP. Huawei plans to support mMTC and
URLLC in RAN. Both BWP (bandwidth part) and
参考基线。
具体项目策略及路标请 Ap p lica t io n
Multiplexing numonology are the options being considered 找产品管理分部申请。 Ro a d m a p
to implement in roadmap. Flo w(2 0 1 8 0 3 )
Ap p lica t io n
.p p t x
Sub3G LTE bands may provide performances (coverage 答复仅作为19B的一般 Flo w(2 0 1 8 0 3 )
and latency) approaching those needed by mMTC and 参考基线。
URLLC. Relevant services and requirments are driven by 具体项目策略及路标请 .p p t x
market demands and eco-system development. 找产品管理分部申请。
The separated DU and CU structure is being planned after

2020.
All function in gNB-CU could be virtualized in COTS
hardware platform. Huawei is considering to implement via
COTs (e.g., HPC7000) plus VMware.
CU-DU分离口径需申请
！
The gNB-DU-h does NOT virtualize, because the function
of RLC/MAC/PHY should be running at real time system
and accelerator hardware, the processing ability of
common hardware and software can NOT satisfied the
time latency and bandwidth requirement.
Although CU part CP-UP split provide more flexibility for

on demand service, especially low latency service, it will
introduce many challenges. Firstly, CP-UP split will
increase new signaling procedure, for example, for bearer
modify procedure, it will increase 60% signaling
interaction. Secondly, it will incurr more complex OM. OSS
has to distinguish data for CU-C/CU-U/DU, and more NE
configuration and management.
In summary, Huawei does not suggest to deploy CP-UP

split in due course but considers to deploy whenever the
business cases actual need. Huawei monitors closely the
industry progress on the CU user plane and CU control
plane splitting.
3GPP R15 recently has frozen the slicing framework. R16

will discuss further details such as NSSAI (S-NSSAI =
Single-Network Slice Selection Assistance Information)
value definition, mobility definition, etc.
Full-service slicing mMTC and uRLLC are promoted to
R16.
Huawei's planning of RAN slicing is based on SDAP

protocol stack. RAN function may be customized in
accordance with different types of connection and use
cases based on NSAAI awareness and SLA design from
Core.
e ss
m ap
e ss
t io n
m ap
1803)
t io n
x
1803)
x
Back please refer to http://3ms.huawei.com/mm/docMaintain/mmMaintain.do?method=showMMDetail&f_id=M
1. Vendor shall provide a high-level description of its role and activities at 3GPP for standardization of 5G NR and
incl. the number of approved contributions to 3GPP and patents pertinent to 5G.
Huawei Response: Compliant
Huawei is an active participant and a major contributor to the development of 3GPP specifications. In addition, Huaw
complies with 3GPP specifications during product development. Specifically, Huawei 5G gNodeBs comply with 3GPP
15. Compliance with 3GPP Release 15 of 5G NR helps to facilitate large-scale commercial use of 5G and reduce en
(E2E) industry costs.
Huawei is leading and pushing the progress of 3GPP standard. Many key technologies of 3GPP 5G standard are pro
the operators and Huawei.
Huawei's experts have served in at least 90 key roles in international standard organizations such as chairman, vice
board member, chairman of working group, rapporteur. Huawei employees currently hold the position of chairman at
SA2, vice chairman at 3GPP RAN4, chairman at ITU-R WP 5D WG technology, chairman at WWRF etc.
As of 2018Q1, Huawei has submitted 9,000+ 5G contributions to 3GPP (RAN1, RAN2, RAN3, RAN4, SA1, SA2, SA
CT1, CT3, CT4). Huawei has 1521 approved contributions of 5G specification (RAN1, RAN2, RAN3, RAN4, SA2, SA
since 2015.
In 3GPP Rel-15, Huawei achieves 9 rapporteurships (7 first rapporteurs and 2 co-rapporteurs), including study on se
evaluation towards IMT-2020 submission, LTE connectivity to 5G-CN，provisioning of network slicing for 5G networ
services, etc.
In 3GPP Rel-16, Huawei continues innovation and makes active contribution, and achieves 4 rapporteurships includ
on the wireless and wireline convergence, enablers for network automation, enhancement of URLLC supporting, sec
assurance specification.
In the light of ETSI IPR Policy, Huawei has 4,177 essential patents in the wireless communication field. In 5G, Huaw
declared 1,695 essential patents to ETSI, which is far ahead of the other vendors.
method=showMMDetail&f_id=Mob180514062413794
r standardization of 5G NR and New Core,

ents pertinent to 5G.
specifications. In addition, Huawei strictly

5G gNodeBs comply with 3GPP Release
mercial use of 5G and reduce end to end
es of 3GPP 5G standard are proposed by
izations such as chairman, vice chairman,

hold the position of chairman at 3GPP
rman at WWRF etc.
2, RAN3, RAN4, SA1, SA2, SA3, SA5,

1, RAN2, RAN3, RAN4, SA2, SA3, SA5)
pporteurs), including study on self-

of network slicing for 5G networks and
hieves 4 rapporteurships including study

ement of URLLC supporting, security
mmunication field. In 5G, Huawei has
725345634.xlsx 文档密级
Back Please refer to the version Go-to-Launch Materials

Provide 3GPP Standards

R15 alignment
standard
R15
3GPP alignment，3
5G Standard 19A FC
Compliance GPP
Compliance
compliance
02/06/2024 华为保密信息,未经授权禁止扩散第27页，共609页

Response
Response Remark
Attachment Name
Huawei will follow the 3GPP 《Huawei NR SoC of 5G RAN2.0 3GPP SOChttp://3ms.huawei.com/mm/docMaintain/mmMaintain.do?method=show
specification. 3GPP Release15
2018Q3 (5G RAN2.0)
V1.0.xlsx》

Back 更多站点信息请参考《19A 5G站点方案介绍培训 V0.94》
19A
5 G站点方案介绍
培训 V0 .9 4 .p p t x
The cooling method of gNB system.

5G 5G Site 制冷方式
5G 18B cooling
Hardware Solution
FC
If the main power is restored while the auxiliary power
source (battery) is in use, the normal operation shall be
possible without interruption of operation or manual operation
or and the auxiliary power shall be charged.
主备电倒换不影响运行
main
5G 5G Site
5G 18B power,auxili
Hardware Solution
ary power
FC
The application of lead acid batteries, lithium polymer
batteries, and lithium ions shall be all possible.
5G 5G Site 可适配的电池类型
5G 18B batteries
Hardware Solution
FC
Remote voltage/current threshold setting and alarm functions
shall be provided for remote charge/discharge test of battery
battery，re and DB for remote charge/discharge test result shall be
5G 5G Site mote managed.
5G 18B
Hardware Solution charge/disch 电池远程电压、电流告警门限设置
arge,alarm
FC
Both DC (-48 VDC nominal) and AC (120/240 VAC) power
5G 5G Site power options shall be available for the BBU.
5G 18B
Hardware Solution options BBU供电选项
FC
Both wall and pole mounting options shall be available for the
5G 5G Site wall,pole TRP(transmission reception point ).
5G 19A
Hardware Solution mounting 射频模块安装选项
FC
The gNB-CU shall be H/W configuration that can be mounted FC
on a 19 "rack, and shall be designed for earthquake-resistant
construction to the rack.
Visualization CU安装和防震
gNB-
SRAN CU-DU Split & Split 19A for trial
CU，rack
Solution
The BBU shall be designed in a module unit considering

capacity expansion and upgrade, and shall be designed in a
5G 5G Site structure that can be easily mounted/dismounted by push-
5G 18B BBU
Hardware Solution pull method for each module.
BBU模块化设计和灵活扩容
The BBU shall be H/W configuration that can be mounted on FC
a 19 "rack, and shall be designed for earthquake-resistant
BBU安装和防震
5G 5G Site
5G 18B BBU rack
Hardware Solution
The input power shall satisfy the following electrical FC

specifications：
5G 5G Site AAU/RRU from -36V to 57V
5G 18B input power
Hardware Solution BBU from -39 to 57V
基站电压输入范围
earthquake The Richter criteria shall be between 7.5 and 8.0 FC

5G 5G Site
5G 18B resistance 防震指标
Hardware Solution
test
The cooling system shall be designed to ensure that it does FC
not affect the service quality considering the external
5G 5G Site cooling environment and longtime operation. The natural cooling
5G 18B
Hardware Solution system method shall be implemented, without requiring the separate
fan.
自然散热不影响业务
It shall satisfy the power consumption of the optical module FC
according to the transmission speed and the temperature
characteristics according to the outdoor type installation and
there shall be no current limiting operation for the SFP
individual port and the entire port.
5G 5G Site Optical a) SFP, SFP +: Supports power consumption over 2.5W
5G 19A
Hardware Solution Module
b) SFP28: Supports power consumption over 3.0W FC
5G 5G Site Optical
5G 19A
c) Temperature characteristics: Satisfies temperature criteria FC

of -20°C (surface temperature) ~ + 85°C (surface
temperature) / 90% RH and supports low temperature
5G 5G Site Optical storage test
5G 19A
While supporting and operating Cascade, and in case of PC

failure of Cascade #1, there shall no problem providing
5G 5G Site services for Cascade # 2.
5G 19A cascade
Hardware Solution
The 5G system should have no change of power system

according to the specification and feature evolution, and H /
5G 5G Site power
5G 19A W design should be considered from the beginning FC
Hardware Solution system
considering sufficient margin for this.
供电系统设计考虑未来演进
Proposed solution can adjust IP and Firmware of
rectifier(include 3rd party) automatically without any
operator’s action when BBU is turned on and also support to
5G 5G Site rectifier
5G 19A monitor & control rectifier and download Firmware remotely PC
Hardware Solution monitor
with monitor port of gNB. Proposer should describe details of
option about automatic interworking between BBU and
rectifier.
The rectifier (including 3rd party) connected with BBU can do
5G 5G Site battery turn-
5G 19A test of turn-on/off of Battery remotely. Proposer should PC
Hardware Solution on/off test
describe the method of the test in detail.
5G 5G Site RoHC Profile 6 function shall be supported for TCP/IP
5G 19A RoHC NC
Hardware Solution Header TCP/IP Packet Header compression.
Following specification and detail explanation how to

evaluate should be provided for each 5G system equipment.
a. MTBF and the explanation how to evaluate
5G 5G Site MTBF,
5G 19A b. MTBF calculation method
Hardware Solution return rate
c. Return rate and the explanation how to evaluate
d. Max. Return rate and the explanation how to evaluate
e. ΔT and the explanation how to evaluate
If the NG-RAN is migrated from NSA to SA, the levels of SA

NSA to SA, NG-RAN shall be equivalent or higher compared to NSA NG-
5G 5G Site
5G 19A NG-RAN RAN, including capacity (number of cells, number of MIMO FC
Hardware Solution
capacity layers, number of bearers, number of UE, etc.), performance
(DL / UL speed, delay etc.), service (GBR, Non-GBR, etc.).
The operating conditions for high temperature/humidity are

based on the satisfaction of RF transmission/reception
characteristics specifications under the following test
5G 5G Site operating
5G 19A environment. FC
Hardware Solution condition
Maximum temperature/humidity (duration):
50°C / 90% RH (96 hours) in outdoor;
50°C / 80% RH (48 hours) in indoor;
The conditions for Cold Start test are based on the
satisfaction of RF transmission/reception characteristics
specifications under the following test environment.
* Outdoor:
1. Minimum temperature/humidity (duration): outdoor type: -
30 °C /0% RH (12hours)
2. Number of closed-loop: 1 time
5G 5G Site cold
5G 19A 3. The power is applied to the equipment after the minimum FC
Hardware Solution condition
temperature/humidity is maintained for 12 hours.
* Indoor:
1. Minimum temperature/humidity (duration): Indoor type: -20
°C /0% RH (12hours), measure at -5 °C
2. Number of closed-loop: 1 time
3. The power is applied to the equipment after the minimum
temperature/humidity is maintained for 12 hours.
The cooling system shall be designed to ensure that it does

not affect the service quality considering the external
5G 5G Site cooling
5G 19A environment and longtime operation. The natural cooling FC
method shall be implemented, without requiring the separate
fan.
F1, Xn Service Level Specification: Specify F1, Xn transport
transport
5G 5G Site requirements (all traffic types) regarding: Delay (ms), Jitter
SRAN 19A requirement FC
Hardware Solution (ms), Packet Loss rate, etc. Is P Packet Reordering allowed
s
(Yes/No)?
Please overview your software approach for minimising

service outage time to the customer in your solution
considering multi-RAT 5G/4G/2G solutions with 5G/4G Dual
minimising
5G 5G Site connectivity, and multiple bands, carriers, and sectors.
5G General service FC
Hardware Solution Include consideration of parameter changes, individual
outage time
component software changes, minor and major RAT or
SRAN software upgrades, cell/sector/unit/site resets,
individual component replacements, etc.
5G 5G Site When will parameter changes/resets/software upgrades to

5G General outage incur FC
Hardware Solution 5G incur outages to 4G in dual connectivity?
5G 5G Site Please provide typical and design target outage time figures
5G General outage time FC
Hardware Solution for different types of reset or software upgrade.
license
5G 5G Site Overview the software licencing/control approach and
5G General control
Hardware Solution mechanisms.
approach
hitless
5G 5G Site Please describe mechanisms and procedures (if any) to
5G General upgrade
Hardware Solution enable hitless software upgrades of RAN software.
procedure
Vendor shall indicate if the power system will be able to be
5G 5G Site Power
5G 19B managed by the NMS through the wireless network, no extra FC
IP resource required.
Vendor shall describe the upgradeability of its legacy

equipment installed in the network in terms of supporting the
5G 5G Site Power 3GPP NR Non-Standalone (NSA) as well as Standalone
5G 19B FC
Hardware Solution system (SA) operations. The Vendor must include a list of all the
legacy equipment options deployed with clear information of
5G-upgradability possibility.
Response
Name
The cooling method of BBU5900 is FAN cooling.
The cooling method of 3.5GHz AAU is Natural cooling.
The cooling method of 28GHz AAU is Natural cooling.
Huawei provides the AC-DC and battery solution for Main gNB equipment.
The AC-DC solution includes PSU (power supply unit) and PMU (power
manager unit). The function of PSU is transfer the AC to DC (-48V), the
function of PMU is the all status manager of PSU and battery. PMU is
powered by PSU or battery.
When the power resource switches from battery to AC-DC, the main
equipment of gNB will NOT interrupt.
The main equipment of gNB will NOT be influenced when AC-DC charge the
battery, because the PMU in AC-DC will balance charge current of main
equipment and battery.
All these three types of battery could be powered for main equipment of
gNB.
Huawei suggests that The AC-DC and battery solution should be from one
vendor.
For example: The AC-DC solution from Huawei will optimize the charge
process for Huawei's battery.
Huawei’s gNB operate & Manage System can set the alarm function about
voltage/current remotely.
The charge/discharge test result can be managed remotely and get the
result in Operate &Manage System.”
Huawei woud provide AC-DC power solution for BBU. This solution support
AC-DC, charge battary, input and output monitor function etc. huawei could
discuss this equipment's SPEC with Operator further.
Huawei AAU/RRU support installation on pole & wall.
The E9000 can be mounted on 19 inch rack, dimensions (H x W x D) of 问题划到

E9000: SRAN
• Chassis: 530.2 mm x 442 mm x 840 mm (20.87 in. x 17.40 in. x 33.07 in.)
• PSU: 40.5 mm x 126 mm x 285 mm (1.59 in. x 4.96 in. x 11.22 in.)
• Fan module: 84 mm x 82 mm x 296.3 mm (3.31 in. x 3.23 in. x 11.66 in.)
E9000's earthquake-resistant needs to be combined with the cabinet's
designing and installation.
HUAWEI BBU5900 could meet these requirements.

A BBU5900 box has 11 slots. The BBU5900 (gNB-DU-h) is designed in a
module unit considering capacity expansion and upgrade, and designed in a
structure that can be easily mounted/dismounted by push-pull method for
each module.
BBU5900 earthquake-resistant design needs to be combined with the
cabinet design. HUAWEI provide a cabinet solution named IBC10. This
cabinet follows ETSI EN 300019-1-3. It can meet magnitude 9 earthquake.
HUAWEI BBU5900 could meet these requirements.
Dimensions (H x W x D) of BBU5900 box:
86 mm x 442 mm x 310 mm = 2U x 19inch x 310mm
Weight of BBU5900 box:
≤ 15 kg (full configuration)
≤ 7 kg (typical configuration)
All of AAU/RRU: -36 ~ -57V

BBU5900: -38.4V~-57V
Huawei gNB equipment supports earthquake-resistant between 7.5 and 8.0

of Richter criteria.
All equipment in the working temperature range can operate long-term.

All equipment with natural cooling method are without separate fan.
The circuit on PCB board could provide 2.5W to the connector in SFP cage.
But there are many elements to influence the stability when XXX uses 3rd
party SFP+ optical module.
XXX and HUAWEI should discuss the detailed information about 3rd party
SFP + optical module, for example the max input voltage, the voltage rate
when start up, the alarm threshold in DDM register, the thermal distribution
of optical module, etc. And Huawei will support 3rd party optical module 6
months after requirements frozen.
The circuit on PCB board could provide 3.0W to the connector in SFP28
cage. But there are many elements to influence the stability when XXX uses
3rd party SFP28 optical module.
XXX and HUAWEI should discuss the detailed information about 3rd party
SFP28 optical module, for example the max input voltage, the voltage rate
when start up, the alarm threshold in DDM register, the thermal distribution
of optical module, etc. And Huawei will support 3rd party optical module 6
months after requirements frozen.
The temperature is a very important parameter of optical module.

Temperature would influence the stability of optical module and equipment.
HUAWEI would do lots of thermal simulation, analysis and test for optical
module working stability.
If XXX wants to use 3rd party optical module, HUAWEI suggests XXX
discussing the detailed information about 3rd party optical module. For
example: thermal resister of surface between module surface and core. And
Huawei will support 3rd party optical module 6 months after requirements
frozen.
For eCPRI cascading, in most case of failure of Cascade #1, there will no “gNB SOC 19A eCPRI
problem providing services for Cascade Baseline 支持级联已
Any one of A B C D point is failure, the service will continuous, but V1.2 - 延迟到19B及
bandwidth of Fx will be decreased. Please refer to the attachment “gNB Newest” 以后
SOC Baseline V1.2 - Newest” Q149. Q149.
The power system in Huawei H / W design has considered sufficient margin

for the specification and feature evolution.
Huawei's DU and RU could connect, monitor, control, test rectifier and
battery which provided by Huawei. The protocol between Huawei
rectifier/battery and Huawei DU/RU is PLC (power line communication)
which not based on TCP/IP.
Huawei's BBU could connect, monitor, control, test rectifier and battery
which provided by Huawei. The protocol between Huawei rectifier/battery
and Huawei DU/RU is PLC (power line communication) which not based on
TCP/IP.
RoHC Profile 6 function will be supported with VoNR service.
a. MTBF (Mean Time between Failures) is the average time from when a
new product starts to work under specified operating conditions until the first
failure occurs. The longer the MTBF, the higher the reliability and the
stronger the correct working ability. Huawei evaluates the MTBF based on
the SR-332 standard and the Markov model. MTBF for each board is listed
in below :
*E9000 (configed with CH121 V5) - 65 years；
*UMPTe1 - 70.6 years；
*UBBPfw - More than 10 years, should provide after TR5 ；
*UBBPg - More than 10 years, should provide after TR5 ；
*AAU 3.5GHz - More than 10 years, should provide after TR5 ；
*AAU 28GHz - More than 10 years, should provide after TR5 ；请注意只提
b. MTBF = 1/λ(h). λ is board total failure rate and its unit is FITs. 供所需board
c. Normally, Return rate is average annual repair rate of board. The average 的信息，如
客户未问到
annual repair rate of board is obtained through conversion of board total E9000，则不
failure rate which is sum of failure rate of all devices on the board. 用提供E9000
d. Huawei evaluates Max. Return rate based on average annual repair rate
and TL9000 statistics for return rate. Provided Return rate for each Board,
the detail specification is as follows：
*E9000 (configed with CH121 V5) - Return rate 1.54% (Theoretical Value)，
Free maintenance for 3 years and can be renewed to the fourth and fifth
years in business caliber;
*UMPTe1 - Return rate 1.41% (Theoretical Value),<2%(Business Caliber);
*UBBPfw - should provide after TR5
*AAU 3.5GHz - should provide after TR5 ；
*AAU 28GHz - should provide after TR5 ；
e. Huawei evaluates ΔT based on thermal simulation.
Huawei SA NG-RAN can provide equivalent number of cells, MIMO layers,

bearers and UE compared to NSA NG-RAN, performance (DL / UL speed,
delay etc.), when migrated from NSA to SA.
SA provides 5QI, so that service (GBR, Non-GBR, etc.) QoS mechanism
can be equivalent or higher compared to NSA NG-RAN.
All equipment in the working temperature range can operate long-term. All
equipment with natural cooling method are without separate fan.
4G&5G对传
please refer to the attrachment 输&时钟要求
口径1.0.xlsx
Huawei introduces kinds of software design solution to ensure the service

availability, for example:
The dual control boards and dual channels design on OMCH channel and IP
route etc., once master channels or control boards failure, system will
handover the transmission to salve channels/boards automatically.
The resource pool design within one baseband board, if any processing
resource failure, system can also switchover the service to other resource in
second level.
Most of software upgrade processes will not interrupt service, only major
and critical changes will require service interruption.
Huawei provides actual service impact information on every parameter in
parameter list documentation, and Huawei will minimize the service impact
of parameter modification as less as possible.
For the multi-RAT SRAN base stations, different RATs need software
upgrading together. In order to minimize the impaction between different
RATs, the main software upgrading process will not affect the services, then
after all the RATs upgrade process finished, all these RATs needs reset
operation at the same time.
Most of software upgrade processes will not interrupt service, only major
and critical changes will require service interruption.
Huawei provides actual service impact information on every parameter in
parameter list documentation, and Huawei will minimize the service impact
of parameter modification as less as possible.
The dual connectivity will outage when parameter changes/resets/software
upgrades.
Base station startup time 2.5 minutes;
Service interruption time during an upgrade:
- Single mode: 3 minutes;
- Multimode: 5 minutes.
Mode extension time without hardware changes in SingleOM scenarios:
- Mode extension time (including software loading): 10 minutes;
- Service interruption time: 2 minutes.
Service interruption time during reset of a mode in SingleOM scenarios:
- Services of the reset mode are interrupted for 2 minutes.
- The impact of resetting one mode on other modes depends on the CPRI
MUX function:
- If CPRI MUX is not used, resetting one mode will not interrupt services of
other modes.
- If CPRI MUX is used, services of other modes will be interrupted for 2
minutes.
gNodeB:
When applying SW Package, there will be service interruption.
DU (BBU): restart times: 1 time; service interruption time: about 5 minutes.
When applying SW Package, the gNB reduce service interruption time by
upgrading blocks in parallel.
And the gNB support patch upgrade feature, only the blocks requiring
changes will be applicable to minimize the service interruption.
Huawei U2020 outage time during software upgrade process is no more
than 30 minutes.
License Management function involves gNodeB license control. A license

file can be purchased from Huawei and remotely downloaded and stored in
a gNodeB. A license file determines whether optional functions can be
activated and how many optional functions can be activated. Operators can
manage and query the contents in a license file through the LMT or U2020
client.
Emergency License Control function can be used to revoke license
restrictions in emergencies so that operators can handle a sudden network
traffic increase. License restrictions can be revoked by running MML
commands on the LMT or U2020. In this way, the devices can be efficiently
used and the maximum hardware capacity of the devices can be reached.
For each R version, O&M personnel have three chances to revoke the
license restrictions through MML commands. The operation takes effect
immediately after the commands are executed. The validity period is seven
days. After the three chances are used up, a new chance can be obtained
through software upgrades.Huawei management system U2020 provides
kinds of NE license management, including:
Viewing license information, Loading a license file, Backup and Obtaining
license file, Exporting information to apply for a commercial license file,
Exporting the sales bill of material (SBOM) information, Exporting the
information about adjusting a license file, Exporting license statistics,
Invalidating a license, etc.
Software Management Expert feature of U2020 provides an end-to-end

upgrade solution and upgrade guidelines that are tailored to users'
requirements. The upgrade solution involves phases such as upgrade
planning, upgrade preparation, upgrade execution, and upgrade completion.
The U2020 manages the software upgrade of base stations as a project.
When users plan a network upgrade, they create an upgrade project and set
a target version in the project. Then, they create multiple upgrade batches,
each of which contains the NEs to be upgraded at a time, to upgrade base
stations by network type on a network in batches. Upgrade procedures
include risk check before downloading, downloading, risk check before
activation, and activation. There are 2 types of SW upgrade:
1. Cold patch and SW upgrade – the interruption time is less than 10
minutes;
2. Hot patch – no any interruption.
Huawei is also able to provide the professional infrastructure management
system NetEco, able to manage APM5930/ILC29 and DPS series power
sysetm, the data canbe transmitted via Huawei BTS data chain, no extra IP
resource required.
Please refer to the attrachment "legacy equipment upgrade to 5G"

Back
Key word
backhaul
5G BBU & CU
5G 19A interface
Hardware Specification
types
5G BBU & CU backhaul

5G 19A
Hardware Specification interface
5G BBU & CU
5G 19A E1
non-Ethernet
5G BBU & CU
5G 19A fronthaul
interface
max
5G BBU & CU
5G 19A transmission
distance
5G BBU & CU protocol

5G 19A
Hardware Specification specification
5G BBU & CU F1,protocol

5G 19A
Hardware Specification specification
5G BBU & CU Fx
5G 19A interface，M
VI
F1/Fx
5G BBU & CU
5G 19A interface，L
LS Option
LLS
5G BBU & CU
5G 19A Option,Intra-
band CA
5G BBU & CU CU,DU,virtul

5G 19A
Hardware Specification ization
5G DU load
5G RF Specification 19A
Hardware reduction
Fx topology,
5G BBU & CU eCPRI
5G 19A
Hardware Specification topology,
star,cascade
5G
5G RF Specification 19A BBU board
Hardware
5G BBU load
5G RF Specification 19A
Hardware balancing
Active/
5G
RF Specification 19A Standby
Hardware
MPT
5G
5G RF Specification 19A BW change
Hardware
5G
5G RF Specification 19A BW change
Hardware
*Question *Compliant
Here it is assumed that backhaul transmission interfaces face the core

network and will be on the CU where there is a higher or lower layer
split, or on the gNB at cell-site where there is no split. State whether
each of the following transmission interface types are supported: 1Gbit/s
Ethernet electrical,1Gbit/s Ethernet electrical, 1Gbit/s Ethernet optical
single mode dual fibre,1Gbit/s Ethernet optical single mode single fibre
(BX),1Gbit/s Ethernet optical CWDM fixed wavelength,1Gbit/s Ethernet
optical CWDM configurable wavelength,1Gbit/s Ethernet optical DWDM FC
fixed wavelength,1Gbit/s Ethernet optical DWDM configurable
wavelength,10Gbit/s Ethernet optical single mode dual fibre,10Gbit/s
Ethernet optical single mode single fibre (BX),10Gbit/s Ethernet optical
CWDM fixed wavelength,10Gbit/s Ethernet optical CWDM configurable
wavelength,10Gbit/s Ethernet optical DWDM fixed wavelength,10Gbit/s
Ethernet optical DWDM configurable wavelength.
回传backhaul端口支持能力
State the transport (3gpp) interfaces that exist within the backhaul
between CU/BBU and Core. FC
回传backhaul传输接口说明
State whether a E1 (3gpp) interface between between CU-UP and CU-
CP is supported and if it is required. NC
CU是否支持E1接口
State whether non-Ethernet fronthaul interfaces are used on the CU, the
DU or LLS-DU where applicable. FC
前传类型
The maximum transmission distance of F1 Interface and Fx Interface

shall be presented. FC
Fx接口传输距离及时延限制
Protocol specifications (frame information, interworking method, etc.)

required for Fronthaul network interworking between gNB-CU and gNB-
DU (including separate and integrated types) sections shall be provided
FC
in detail to our Company. There shall be no problems when interworking
with our own wired network solution.
F1接口遵从的协议
For interworking between gNB-CU and gNB-DU (including separate and

integrated) equipment and Fronthaul transmission equipment based on
our WDM (Wavelength Division Multiplexing)-PON (Passive Optical FC
Network) technology.
F1接口协议
The Fx interface between gNB-DU_H (High) and gNB-DU_L (Low) shall

conform to the TTA specifications (TTAK.KO-06.0461 and specifications
NC
to be revised) and shall provide an open Interface for MVI.
开放eCPRI接口
The Fx interface should support following options：

*3.5GHz：
F1 interface - Option 2, Fx interface - Option 7-3/7-2a for DL and Option
7-2/7-2a for UL; PC
*28GHz:
F1 interface - Option 2, Fx interface - Option 7-3 for DL and Option 6 for
UL;
无线切分Options选择
If each LLS（Low layer Split） method has different frequency, there
shall be no constraint or quality degradation in functions such as inter- FC
band CA, and the detailed implementation method shall be presented.
The integrated type of gNB-CU + gNB-DU-H virtualization base station

PC
equipment shall be supported.
In case of CU-DU separated type, DU’s load reduction ratioshould be

provided comparing to integrated type. FC
CU-DU分离后DU容量是否有提升
The configuration of DU_H and DU_L physical ports connection with

different topology (star, cascade etc.) and the corresponding cell
configuration (the bandwidth/the number of supported layer/the
PC
maximum number of cells supported) shall be presented, and for all cells
accommodated in the same DU_H and between DU_H, the remote
operation shall be possible without re-location of physical ports.
BBU board type, installed board should be minimized by board

FC
integration.
The gNB shall implement dynamic resource allocation algorithm for load
FC
balancing if it has a channel card structure and it shall be suggested.
Even if the interworked DU_H is down, DU-L shall support the structure
of interworking with other DU_H to provide service. (Active/Standby FC
redundancy structure using back port of DU_L).
When the function to change and operate BW is added, it shall be

FC
possible through S/W upgrade.
Please provide CU E9000 specification and traffic model FC

Response
Name
the transmission interface types listed in question are all supported.

Huawei gNB supports SFP optical module, as long as the optical module
meets the MSA standard, the system can support it.
1、 In NSA scenes, exist S1-U between CU/BBU and Core.

2、 In SA scenes, exist NG-c/u between CU/BBU and Core.
E1 interface has not been defined in the 3GPP protocol, Huawei product
will follow 3GPP Standard .
The non-Ethernet fronthaul interfaces are used on the DU(BBU 5900) and
CPRI/eCPRI-AAU.
For Fx interface, the maximum transmission distance between gNB-DU-h

and gNB-DU-l is 20km. Fx interface is real time interface, the time delay
comes from the transmission distance affects the end to end processing
time of HARQ loop, and the one-way time delay of 20km transmission
distance is about 100us, Huawei suggests the maximum transmission time
delay is 100us.
The F1 interface is non-real time interface, and is not included in
processing of the HARQ loop, the transmission distance between gNB-CU
and gNB-DU is no constraint. However the time delay of F1 transmission
distance will affect the user's end to end traffic time delay.
The F1 interface user plane and control plane are compliant with the follow
transmission protocol:
User Plane: ETH MAC/IP/UDP/GTP-U
Control Plane: ETH MAC/IP/SCTP
There will be no interworking problem with the wired transmission network
if the transmission network is compliant with the same transmission
standard.
The F1 interface is based on ETH/IP transmission protocol, the WDM-PON

network should support ETH interface and carry the F1 interface traffic
between gNB-CU and Gnb-DU. If the third part WDM optical module used
on UMPTe, please check the Optical Module.
Huawei will comply with the eCPRI standard for the Fx interface in the
initial version.
Huawei supports the LLS option as below:

*3.5GHz & 28GHz：
F1 interface - Option 2,
Fx interface - Option 7-3 for DL and Option 7-2a for UL;
For different frequencies Huawei will use the same LLS method, so there is
no constraint or quality degradation in functions such as inter-band CA.
Huawei supports gNB-CU virtualization, but does not support gNB-DU-h

virtualization because the RLC/MAC/PHY-h functions of gNB-DU-h using
dedicated hardware for greater performance and efficiency.
Huawei will support gNB-DU-h virtualization if a general-purpose server
with a high-performance CPU is available and real-time processing is
possible.
Please refer to
<04 BBU & CU
The CU is mainly responsible for the processing of the PDCP/RRC (RAN- Specification
NRT function). The DU is mainly responsible for the processing of the PHY Attachment 2.
/ MAC / RLC (RAN-RT function). Because the most of the baseband BBU or DU
processing is performed on the BBU, so the BBU specifications are same Specification and
regardless of the CU and DU are separated or integrated. Capacity>
Please refer to
<04 BBU & CU *:19A 延迟了
Specification eCPRI级联方
HUAWEI propose three Fx solutions. Star, RMU solution, Cascade* Attachment 1. Fx 案到19B或更
solution. Topology> 晚，需要项目
组确认最新口
径.
Huawei BBU5900 supports three full-width baseband boards or six half-

width baseband boards.
UBBPfw is the first generation of HUAWEI 5G-NR baseband board with full
width. 如果是19B为
UBBPg is the second generation of HUAWEI 5G-NR baseband board with 答标基线，可
half width. 不呈现UBBPg
Huawei BBU5900 supports maximum two main-control/transmission 和UMPTg单板
boards, UMPTe is the first generation of HUAWEI 5G-NR main-control
board, UMPTg is the second generation of HUAWEI 5G-NR main-control
board.
Huawei gNB supports load balancing between the processing chips within
the baseband board. The UMPT can perform L3 Control Plane Process
pooling for BBPs within BBU.
The UBBP board supports the redundancy function. When the active board
detects a fault, the board switches to the standby state and the standby 要配置主备
board switches to the active state. The service set up on the active board MPT单板
automatically resumes within a short period of time.
When the function to change and operate BW is added, so long as the

function and operate BW is under the capability of the exist hardware, it will
be possible to support S/W upgrade.
Please refer to
<04 BBU & CU
Please refer to <04 BBU & CU Specification Attachment 2. CU E9000 Specification
Specification> Attachment 2.
CU E9000
Specification>
Back
Key word *Question
The gNB shall support the COPY mode to combine two or more
combine
5G BBU & CU cells and operate with the same PCI, and the combined cell shall
5G 19A cells,same
Hardware Specification provide capacity as much as the sum of all cells capacity to
PCI
support the capacity of each cell.
The gNB shall implement dynamic resource allocation algorithm

5G BBU & CU load
5G 19A for load balancing if it has a channel card structure and it shall be
Hardware Specification balancing
suggested.
Response
*Compliant Response Attachment Remark
Name
Huawei will provide the SFN solution to match this

requirement that two or more cells are combined and operate
FC
with the same PCI, and provide capacity as much as the sum
of all cells.
Huawei gNB supports load balancing between the processing

FC chips within the baseband board. The UMPT can perform L3
Control Plane Process pooling for BBPs within BBU.
Back
Key word
SW,
5G
5G Element O&M 19A no service
Hardware
interruption
SW,
5G
5G Element O&M 19A interruption
Hardware
time
minimize
5G
5G Element O&M 19A service
Hardware
interruption
5G SW time per
5G Element O&M 19A
Hardware gNB
UE-specific
5G
5G Element O&M 19A parameter
Hardware
change
non-system
5G
Hardware
change
non-system
5G
Hardware
change
5G change
5G Element O&M 19A
Hardware execution
5G parameter
5G Element O&M 19A
Hardware skip
cell scale-in,
5G
5G Element O&M 19A no DU/BBU
Hardware
interruption
cell
5G
5G Element O&M 19A configuration
Hardware
,EMS
5G port
5G Element O&M 19A
Hardware re-location
5G condition
5G Element O&M 19A
Hardware parameter
usage，
5G
5G Element O&M 19A over load
Hardware
status
5G
5G Element O&M 19A gNB status
Hardware
5G auxiliary
5G Element O&M 19A
Hardware status
5G port fault
5G Element O&M 19A
Hardware reporting
store,
5G
5G Element O&M 19A monitor,RF
Hardware
signal
5G report power
5G Element O&M 19A
Hardware consumption
environment
5G
5G Element O&M 19A al condition
Hardware
monitor
5G Temperature
5G Element O&M 19A
Hardware monitor
beamformin
5G
5G Element O&M 19A g function
Hardware
verification
5G
5G Element O&M 19B debug
Hardware
When applying SW Package, there shall be no service interruption. FC
In case of service interruption when applying SW Package, the

necessary restart times and the service interruption time shall be FC
presented.
When applying SW Package, only the blocks requiring changes shall be

FC
applicable to minimize the service interruption.
When applying SW Package, the time required per gNB shall be

presented, and the number of applicable gNBs per minute and per hour FC
shall be presented.
The UE-specific parameters (parameters for which individual UEs can

have different values) that need to be changed during operation shall be FC
changeable without taking additional measures (cell block, etc.).
The operating parameters (parameters for operation, on which the base

stations or device do not need to have the common information, for
example, output, Cell Tx /Rx Power Atten, Modulation change (256QAM,
64QAM On / Off), power control values (Alpha, P0)) shall be changeable
without taking additional measures (cell block, etc.). These are different FC
from the system configuration parameters (parameters on which all cells
and all devices in the cell should have the common information since it
has the system configuration information, for example, call bandwidth,
cell PCI, etc.).
When changing parameters, there shall be no service interruption and

FC
quality degradation.
When changing parameters, the changed setting (or setting value) shall
FC
be applied immediately upon execution of the change.
If the same value is applied at the time of parameter change, the
FC
application time should be able to be shortened by Skip function.
For the scale-in and out of cells, only the corresponding cell shall be
FC
applicable, and there should be no interruption of overall DU service.
The operator shall be able to change cell configuration efficiently on EMS

FC
as well as on gNB, and there shall be no effect on gNB as a whole.
The port re-location shall be possible remotely (EMS), not in the field
through the logical configuration change, and all the cell parameters and FC
facility DB shall be automatically inherited after the port re-location.
The conditional parameter change function shall be available. (E.g. Apply
the parameter value (which is operating or set) change, when exceeding PC
threshold such as the number of users by cell.)
The gNB shall report the usage and overload status of the processor and
FC
H/W unit to the EMS.
The gNB status (Processor, Device, H/W unit service status
(Normal/Fail), Power), loading status per cell, reporting function for H/W
FC
unit display in active status, when main process supports redundancy,
shall be provided.
When the auxiliary power is used, auxiliary power residual status
FC
reporting function shall be provided
Monitoring and fault reporting of Ethernet Port and Optic signal shall be
FC
provided.
The measures to store and monitor (RF spectrum) DL/UL RF signal of

each gNB cell shall be provided.
DL/UL RF waveform snapshot, DL output, and UL RSSI shall be FC
periodically provided. Alarm Threshold and the monitoring period shall
be configurable by the operator.
The gNB shall collect/report the actual power consumption and

FC
instantaneous peak value at regular intervals (1 minute, 5 minutes).
For outdoor equipment, the environmental conditions (temperature,

FC
battery, door open, etc.) shall be monitored.
The temperature monitoring shall be performed on major module such

FC
as AMP, power supply, DC-DC converter of equipment.
The gNB shall provide a function to verify whether the final equipment
FC
output is radiating smoothly, including the beamforming function.
All troubleshooting features shall be included. This includes, for example,
debug logging features, syslogs, air interface physical/MAC/RLC/PDCP
layer logs, transport-related debug logs, S1AP, NGAP, X2, Xn related PC
debugging logs. The troubleshooting logs shall be collectible remotely
via management connection.
Response
Name
gNB: When applying SW Package, there will be service

interruption.
CU(E9000): restart times: 1 time; service interruption time: about

10 minutes
DU(BBU): restart times: 1 time; service interruption time: about 5
minutes.
When applying SW Package, the gNB reduce service interruption
time by upgrading blocks in parallel.
And the gNB support patch upgrade feature, only the blocks
requiring changes will be applicable to minimize the service
interruption..
The time required per gNB: 30 minutes

The ability to batch upgrade gNB is 1200 gNB / 30 minute.
The UE-specific parameters can be changed without taking

additional measures.
And the product documentation will provide instructions for each
parameter.
The non-system configuration parameters can be changeable

without taking additional measures. (For example, output, Cell
Tx /Rx Power Atten, Modulation change (256QAM, 64QAM On /
Off), power control values (Alpha, P0)).
Huawei provides actual service impact information on every

parameter in parameter list documentation, and Huawei will
minimize the service impact of parameter modification as less as
possible.
When changing parameters, the changed setting will be applied
immediately upon execution of the change.
If the same value is applied at the time of parameter change, the
application time will be able to be shortened by skip function.
For the scale-in and out of cells, only the corresponding cell will be
applicable, and there is no interruption of overall DU service.
The operator can change cell configuration efficiently on EMS

(U2000) as well as on gNB, and there will be no effect on gNB as a
whole
The gNB supports port re-location function through EMS, if the

resources allowed. It iIncludes the following 3 scenarios:
1. For all cells accommodated in the same CU and between CUs,
the remote operation shall be possible without re-location of
physical ports.
2. For all cells accommodated in the same DU_H and between
DU_H（between BBP in one BBU）, the remote operation shall be
possible without re-location of physical ports.
3. The gNB-CU and gNB-DU shall be able to remotely change the
mapping with logical Cells without physical relocation of all Cells
they are accommodating.
The gNB supports conditional parameter function, but not all
parameters are supported.
For example:
1) Call Admission Control:
5G RAN2.0 version based on the number of users specifications
and number of users, the threshold does not require configuration
2) Overload Control do not support:
The gNB is fixed at current version, because the probability of this
parameter modification is small. This parameter is not allowed to
add from the viewpoint of parameter reduction. If the customer still
needs, need to submit requirement.
If there is really a customer requirement (the above two
parameters), Huawei would like to discuss it with customer.
The gNB can report the usage and overload status of the processor
and H/W unit to the EMS.
The gNB supports status reporting function, including Processor,

Device, H/W unit service status, cell status, H/W unit active status.
When the auxiliary power is used, auxiliary power residual status
can be queried though the EMS, including remain time and remain
capacity.
The gNB supports monitoring and fault reporting of Ethernet Port
and Optic signal.
Following functions are supported through EMS:

• UL waveform snapshot
• DL output
• UL RSSI
• Tx Overshooting Alarm.
Please refer to
• Rx : Low RSSI, Unbalance alarm
<06 Element
Alarm Threshold and the monitoring period can be configured by
O&M Attachment
the operator
1. RF Signal
DL waveform snapshot:
Measurement>
1. For RRU module, It is recommended that spectrum detection be
supported by the coupling signal external to the module.
2. AAS antenna integrated module will generally provide RF
monitor output port, the output signal can be detected through the
RF monitor output port.
The gNB can collect/report the actual power consumption and

instantaneous peak value, the minimum intervals allowed is 5
minutes. Huawei can support 1 minute interval after 2018Q3.
The gNodeB can provide environment monitor functions through

the EMU device which can provide detection ports for the
temperature sensor, humidity sensor, smoke sensor, water sensor,
infrared alarm sensor, door status sensor, extended Boolean value,
analog values, and output control value. The gNodeB also provides
complete power solution including battery management.
The gNodeB support temperature monitoring on major equipment

and modules.
The gNB support channel-level output power detection function to

verify whether the final equipment output is normal.
Huawei through the following two aspects to ensure beamforming
function is normal:
1）Huawei will check whether the antenna pattern is correct before
delivery.
2）The AAU automatically starts the online channel calibration
function to ensure that RF channels reciprocity are normal.
Huawei supports debug logging features, syslogs, air interface
layer logs, transport-related debug logs, NGAP, X2, Xn related
debugging logs. The S1AP log is not supported by Huawei.
Back
Key word *Question
Following specification and detail explanation how to

evaluate should be provided for each 5G system equipment.
a. MTBF and the explanation how to evaluate
5G 5G Site MTBF,
5G 19A b. MTBF calculation method
Hardware Solution return rate
c. Return rate and the explanation how to evaluate
d. Max. Return rate and the explanation how to evaluate
e. ΔT and the explanation how to evaluate
Response
Name
a. MTBF (Mean Time between Failures) is the average time from when a
new product starts to work under specified operating conditions until the first
failure occurs. The longer the MTBF, the higher the reliability and the
stronger the correct working ability. Huawei evaluates the MTBF based on
the SR-332 standard and the Markov model. MTBF for each board is listed
in below :
*E9000 (configed with CH121 V5) - 65 years；
*UBBPfw - More than 10 years, should provide after TR5 ；
*AAU 3.5GHz - More than 10 years, should provide after TR5 ；
*AAU 28GHz - More than 10 years, should provide after TR5 ；请注意只提
b. MTBF = 1/λ(h). λ is board total failure rate and its unit is FITs. 供所需board
c. Normally, Return rate is average annual repair rate of board. The average 的信息，如
客户未问到
annual repair rate of board is obtained through conversion of board total E9000，则不
failure rate which is sum of failure rate of all devices on the board. 用提供E9000
d. Huawei evaluates Max. Return rate based on average annual repair rate
and TL9000 statistics for return rate. Provided Return rate for each Board,
the detail specification is as follows：
*E9000 (configed with CH121 V5) - Return rate 1.54% (Theoretical Value)，
Free maintenance for 3 years and can be renewed to the fourth and fifth
years in business caliber;
*UBBPfw - should provide after TR5
*AAU 3.5GHz - should provide after TR5 ；
*AAU 28GHz - should provide after TR5 ；
e. Huawei evaluates ΔT based on thermal simulation.
Back
Key word *Question
The gNB shall support the n78 (3.3GHz-3.8GHz) in 3.5 GHz band, by
5G RF n78,n79,Ban
5G 19A default, but whether to support n77 (3.3 GHz-4.2GHz) shall be also
Hardware Specification d
presented.
The gNB shall support n257 (26.5GHz-29.5GHz) in 28 GHz band, by

5G RF n257,n256,B
5G 19A default. (Present whether n258 (24.25 GHz – 27.5 GHz) band is
Hardware Specification and
supported or not).
The gNB shall support the following items for each frequency band.
Sub carrier *3.5GHz Band:
spacing, Sub Carrier Spacing [KHz]:15 / 30 / 60;
5G RF channe Channel Bandwidth :5 / 10 / 15 / 20 / 25 /30 / 40 / 50 / 60 / 70 /80 /
5G 19A
Hardware Specification bandwidth, 90 / 100;
OBW,IBW, Operation BW:Full range in NR Operating Band
Duplex Instantaneous BW:100 / 200 / 300MHz
Duplex:Dynamic TDD
The gNB shall support the following items for each frequency band.
Sub carrier
*28GHz Band:
spacing,
Sub Carrier Spacing [KHz]:60 / 120 (240 / 480: SSB );
5G RF channe
5G 19A Channel Bandwidth :50 / 100 / 200 / 400;
Hardware Specification bandwidth,
Operation BW:Full range in NR Operating Band
OBW,IBW,
Instantaneous BW:1 / 2 / 3GHz
Duplex
Duplex:Dynamic TDD
Out of Band
In relation with Out of Band Emission and Spurious, it shall confirm to
5G RF Emission，
5G 19A 3GPP TS 38.104 and domestic technical standards and methods to
Hardware Specification Spurious,
check whether it is satisfied or not shall be presented.
TS38.104
Out of Band
In relation with Out of Band Emission and Spurious, it shall confirm to
5G RF Emission，
5G 19A 3GPP TS 38.104 and domestic technical standards and methods to
Hardware Specification Spurious,
check whether it is satisfied or not shall be presented.
TS38.104
EMS shall be able to monitor both transmitted and received spectrum

5G RF EMS, waves of gNB, and the detailed implementation method and the
5G 19A
Hardware Specification TS38.104 method to measure RF by base station type (1-C, 1-H, 1-O and 2-O)
of TS 38.104 shall be presented.
EMS shall be able to monitor both transmitted and received spectrum

5G RF EMS, waves of gNB, and the detailed implementation method and the
5G 19A
Hardware Specification TS38.104 method to measure RF by base station type (1-C, 1-H, 1-O and 2-O)
of TS 38.104 shall be presented.
transceiver,f It shall be possible to detect failure and malfunction by unit
5G RF
5G 19A ailure, transceiver, and the operator shall be able to control the threshold for
malfunction the error rate to determine whether the equipment is operable.
transceiver,f It shall be possible to detect failure and malfunction by unit

5G RF
5G 19A ailure, transceiver, and the operator shall be able to control the threshold for
malfunction the error rate to determine whether the equipment is operable.
The self-healing function shall be implemented in case of transceiver

5G RF transceiver failure, and the minimum number of transceivers with self-healing
5G 19A
Hardware Specification self-healing function or the minimum error rate and the time required for returning
to normal after the failure detection shall be presented.
The self-healing function shall be implemented in case of transceiver

5G RF transceiver failure, and the minimum number of transceivers with self-healing
5G 19A
Hardware Specification self-healing function or the minimum error rate and the time required for returning
to normal after the failure detection shall be presented.
5G RF mechanical The separate type gNB AAU/RRU shall provide brackets that support
5G 19A
Hardware Specification tilt mechanical tilt, and the down tilt shall be more than 15°.
5G RF mechanical The separate type gNB AAU/RRU shall provide brackets that support
5G 19A
Hardware Specification tilt mechanical tilt, and the down tilt shall be more than 15°.
The separate type AAU/RRU of 28 GHz shall satisfy the following:In

order to reduce the loss of the radar dome, the dielectric constant
5G RF dielectric shall be configured with the low-loss dielectric substance less than
5G 19A
Hardware Specification constant three, and the loss of dielectric substance shall be improved by at
least 10% compared to pure PC series and its implementation
method shall be presented.
In the case of using 100MHz/200MHz BW in 3.5GHz band, if there

adjacent are other carriers in the adjacent band, the maximum carrier
5G RF
5G 19A band, operation and maximum output shall satisfy 3GPP TS 38.104 and
guard band domestic technical standards. When the guard band is required, the
reason shall be presented.
In the case of using 400MHz/ 800MHz/1GHz BW is used in the

adjacent 28GHz band, if there are other carriers in the adjacent band, the
5G RF
5G 19A band, maximum carrier operation and maximum output shall satisfy 3GPP
guard band TS 38.104 and domestic technical standards. When the guard band
is required, the reason shall be presented.
When PIM is generated, the automatic Rx Path On/Off function shall
5G RF
5G 19A PIM be supported.
无源交调PIM：passive intermodulation
5G RF Output
5G 19A C-band output power should be flexible.
Hardware Specification power
5G RF Output
5G 19A mmWave output power should be flexible.
Hardware Specification power
The proposer shall present the advantages of equipment design and

5G RF high
5G 19A device utilization used to achieve low power/high efficiency by
Hardware Specification efficiency
proposed equipment and the expected savings resulting from it.
The proposer shall present power saving or low-power operating

solution that can be utilized, including expected savings. The
5G RF power proposed solution shall minimize the impact on quality and shall be
5G 19B
Hardware Specification saving easily applied/monitored/analyzed by operator (e.g. saving operation
method that is operated in real time by Traffic Load or the operator’s
operation/previous method).
The equipment operation method is required to minimize the standby

power without affecting quality such as service interruption. The
5G RF PSU power
5G 19A proposer presents the saving measures such as blocking / controlling
Hardware Specification saving
the PSU power supply in the standby state in detail and implements
them so that the operator can remotely control.
A function to change the MIMO layer according to traffic load,

5G RF traffic load
5G 19A scheduling policy, etc., and the operator shall be able to set Traffic
Hardware Specification balancing
Threshold, etc.
The gNB shall support the COPY mode to combine two or more cells
combine
5G RF and operate with the same PCI, and the combined cell shall provide
5G 19B Cells with
Hardware Specification capacity as much as the sum of all cells capacity to support the
same PCI
capacity of each cell.
5G RF MU-MIMO
5G 19B MU-MIMO capability for Sub6G and mmWave
Hardware Specification layers
The RAN supplier supports up to 32 ports per CSI-RS resource per

UE. The following details shall be clarified (restricting the answers to
FR1 and single-panel/single-TRP(Transmission Reception Point)):
• What are the supported configurations (in terms of density,
overhead)? What are the purposes/use-cases of different densities
5G RF ports
5G 19A for a given number of ports?
Hardware Specification per CSI-RS
• How does the CSI-RS density (overhead) vary in function of the
number of RRC connected UEs in the cell?
• What is the power boosting factor of CSI-RS REs and how is it
related to the number of CSI-RS ports and on the selected
configuration in terms of density?
The RAN supplier shall present the way the difference is handled
5G RF ports,MUBF, between the number of physical PA in the AAS system (e.g.: 64) and
5G 19A
Hardware Specification SUBF the maximum number of antenna ports a UE may report (32 CSI-RS
ports in Rel. 15).
The RAN supplier shall indicate its implementation choices regarding

MIMO precoding/beamforming.
precoding,  based on DL reference signals,

5G RF
5G 19A beamformin a. Codebook-based type I
g b. Codebook-based type II
 Based on DL-UL reciprocity
a. UE antennas configurations: 1T4R , 2T2R, 4T4R, etc
b. SRS resources: based on antenna switching, etc
5G RF C-band:Specify how many elements are there in your base station

5G 19A C-band RF
Hardware Specification antennas
5G RF C-band:Are the antenna elements grouped to form logical antenna
5G 19A C-band RF
Hardware Specification elements
5G RF
5G 19A C-band RF C-band:Specify the transceiver to logical antenna element mapping
5G RF
5G 19A C-band RF C-band:Specify the number of sub arrays
5G RF
5G 19A C-band RF C-band:Specify the element gain
5G RF
5G 19A C-band RF C-band:Specify logical element gain
5G RF
5G 19A C-band RF C-band:Specify sub array azimuth and elevation pattern
5G RF
5G 19A C-band RF C-band:What is the array gain
C-band:How do you do multi user separation, ie via precoding at the
5G RF
5G 19A C-band RF baseband (digital precoding) or RF beamforming at RF (analog
precoding) or both (hybrid precoding)?
C-band:Specify maximum user numbers that can simutaneously
5G RF
5G 19A C-band RF access the carrier and are there any constraints on the UE locations.
If so, specify the constraints.
5G RF
5G 19A C-band RF C-band:Specify streams per user
5G RF
5G 19A C-band RF C-band:what type of beam forming is used for the C band
5G RF C-band:how is multi user multi stream separation achieved in the C

5G 19A C-band RF
Hardware Specification band and what happens when the users are clustered?
5G RF C-band:How is the UE Channel State Information (CSI) information

5G 19A C-band RF
Hardware Specification obtained, specify the algorithm
5G RF C-band:How often in time and the frequency the CSI information
5G 19A C-band RF
Hardware Specification obtained?
5G RF
5G 19A C-band RF C-band:Specify antenna form factors
C-band:How will beam management between two 5G cells anchored
5G RF on the same LTE happen to facilitate inter 5G hand off and what is
5G 19A C-band RF
Hardware Specification the BBU impact on beam management in C-band. What is the impact
on random access time?
5G RF mmWave
5G 19A mmWave:Specify how many elements are there in your antennas
Hardware Specification RF
5G RF mmWave mmWave:Are the antenna elements grouped to form a logical
5G 19A
Hardware Specification RF antenna elements
5G RF mmWave
5G 19A mmWave:Specify the number of sub arrays
5G RF mmWave
5G 19A mmWave:Specify the element gain
5G RF mmWave
5G 19A mmWave:Specify logical element gain
5G RF mmWave
5G 19A mmWave:What is the array gain for each band
mmWave:How do you do multi user separation ie via precoding at
5G RF mmWave
5G 19A the baseband (digital precoding) or RF beamforming at RF ( analog
precoding) or both (hybrid precoding)?
5G RF mmWave
5G 19A mmWave:Specify simultaneous user numbers
5G RF mmWave
5G 19A mmWave:Specify streams per user
5G RF mmWave
5G 19A mmWave:what type of beam forming is used for the mm wave band
5G RF mmWave mmWave:How is multi user multi stream separation achieved in

5G 19A
Hardware Specification RF mmWave bands,describe your algorithm.
5G RF mmWave
5G 19A mmWave:How is the UE CSI information obtained
5G RF mmWave mmWave:How often in time and the frequency the CSI information
5G 19A
Hardware Specification RF obtained
5G RF mmWave
5G 19A mmWave:Specify antenna form factor
mmWave:How will beam management between two 5G cells
5G RF mmWave anchored on the same LTE happen to facilitate inter 5G hand off and
5G 19A
Hardware Specification RF what is the BBU impact on beam management in mm Wave band.
What is the impact on random access time?
1. Physical description of n78 Product. For the different models,

5G RF could you indicate and provide a diagram with number of rows,
5G 19B C-band RF
Hardware Specification columns, elements, number of TX/RU. Number of of subarrays.
Power per TX/RU, power per element.
2. Physical description of n78 Product for small cell. For the different
Smallcell RF models, could you indicate and provide a diagram with number of
5G 19B C-band RF
Hardware Specification rows, columns, elements, number of TX/RU. Number of of subarrays.
Power per TX/RU, power per element, bandwidth.
5G RF 3. Definition of Instantaneous Bandwidth (IBW), Occupied Bandwidth

5G / IBW OBW
Hardware Specification (OBW), and working band range.
6. What are the DL and UL peak throughput per user assuming 100
5G RF peak MHz bandwidth? What are the DL and UL peak throughput per cell
5G 19B
Hardware Specification throughput assuming 100 MHz bandwidth, and ideal conditions in order to get
maximum performance from spatial multiplexing?
7. What is the roadmap of number of simultaneous MU-MIMO

5G RF
5G 19A MU-MIMO supported by the active antenna, for the different models of antenna
forecasted?
9. Do the users have to be splitted between both carriers, or instead

5G RF
5G / CA is it possible to do carrier aggregation, so a single user can get the
PRBs of both carriers simultaneously?
10. Does R15 standard specify carrier aggregation of 2 NR Carriers

5G RF in band n78, so that the totality PRBs of both carriers can be
5G 19A CA
Hardware Specification assigned to a single user? And with regard the terminals, will be
necessary terminal category that support carrier aggregation?
11. What are the combinations possible, anyone not exceeding 120
5G RF MHz of occupied bandwidth? (“you could consider to configure 2 NR
5G 19A CA
Hardware Specification carriers with several combination (100M+20M/80M+40M/60M+60M
etc), which would be feasible with only one AAU5613;”)?
5G RF 12. How much is the maximum occupied Bandwidth with a
5G 19A CA
Hardware Specification combination of 2 NR Carriers?
5G RF 13. What is the maximum number of NR carriers over the same
5G 19A C-band RF
Hardware Specification Massive MIMO antenna forecasted in band nr78?
15. Is it possible to implement MORAN with AAU5613? How many
5G RF NR carriers? How would be the configuration of the radio system:
5G 19A MoRAN
Hardware Specification Massive antenna, base band required? How are shared the antenna
layers between the operators?
17. Is it possible to implement MOCN with AAU56xx with only one

5G RF carrier? How would be the configuration of the radio system: Massive
5G 19A MoCN
Hardware Specification antenna, base band required? How are shared the antenna layers
between the operators?
18. Is it possible to implement MOCN with AAU56xx with different
carriers? How many NR carriers at maximum? How would be the
5G RF
5G 19A MoCN configuration of the radio system: Massive antenna, base band
required? How are shared the antenna layers between the
operators?
26. Supplier must provide AAUs and RRUs with minimum wind
5G RF
5G 19A loading/effective sail area and with ease of installation to leverage on
existing site with minimum site acquisition and upgrade costs.
27. All RRUs must support AISG2 and full interoperability with third
party Master Head Amplifiers and support Remote Electronic Tilt for
5G RF
5G 19A AISG passive antennas. Support for future AISG3 and other industry
relevant antenna line protocols must be detailed as part of equipment
roadmaps.
29. Supplier must detail all current and planned future AAU
capabilities to control the horizontal and vertical beamforming to
5G RF minimise concentrated beams to a specified power as a potential
5G 19B BF
Hardware Specification EME mitigations. Other possible capabilities would include the ability
to fix tilt or phase to restrict beams in horizontal or vertical planes or
peak single user, multi user power allocation.
30. NGMN requires a reduction of energy consumption by half of
today’s networks while meeting the 1000-fold traffic capacity within
5G RF power
5G 19B the upcoming 10 years, so in essence an efficiency gain of 2000 in
Hardware Specification saving
terms of bit/J. By means of which technologies do you plan to solve
this discrepancy?
5G RF power 31. By what measures does your NR optimize UE energy efficiency?
5G 19B
Hardware Specification saving e.g. DTX on UE side, etc.
5G RF power 34. Do you see any impact on power amplifier efficiency due to
5G 19B
Hardware Specification saving introduction of F-OFDM in NR?
5G RF 37. The typical noise figure of gNodeB shall be below 3 dB on all

5G 19B noise figure
Hardware Specification bands.
*Compliant Response
Huawei C-band gNB supports the following frequency band as listed below:
PC
Operation frequency band is 3400~3600M, 3600~3800M
FC Operation frequency band of 28GHz gNB support n257 (26.5GHz-29.5GHz) and n258 (24.25 GHz – 27.5 GHz).
Huawei gNB supports the following items for each frequency band. And Huawei will provide other SCS configuration
and Channel Bandwidth configuration after the requirement frozen +6 month.
Sub Carrier Spacing:
30KHz: FC 2018Q4
60KHz: For commercial application: Huawei will provide roadmap after agreement on this requirement with Operator
after discussion.
15KHz: Huawei will provide roadmap after agreement on this requirement with Operator after discussion.
PC
3.5GHz will be mainly applied for eMBB continuous coverage, SCS=30KHz can be a good tradeoff between
latency/coverage/mobility.
Channel Bandwidth :40 / 60 /80 /100; Huawei will provide roadmap after agreement on other channel bandwidth
requirement with Operator after discussion.
Instantaneous BW: 200MHz
Duplex:Dynamic TDD is not supported for 3.5GHz. Since 3.5GHz is considered for continuous coverage and multi-
operator will deploy at the same area. Huawei suggests aligned TDD configuration between cells.
Huawei gNB supports the following items for each frequency band. And Huawei will provide other SCS configuration
and Channel Bandwidth configuration after the requirement frozen +6 month.
Sub Carrier Spacing:
60KHz (includes SSB): 2018Q4
120KHz: Huawei will provide roadmap after agreement on this requirement with Operator after discussion.
SSB 240KHz: Huawei will provide roadmap after agreement on this requirement with Operator after discussion.
PC SSB 480KHz: Not defined in 3GPP currently.
Channel Bandwidth :
100 / 200MHz：2018Q4
400MHz：Huawei will provide roadmap after agreement on this requirement with Operator after discussion.
50MHz：Huawei will provide roadmap after agreement on this requirement with Operator after discussion.
Instantaneous BW: 800MHz （Hardware ready for 1GHz）
Duplex:Huawei will provide roadmap after agreement on this requirement with Operator after discussion.
Huawei will follow 3GPP (+3month after the standard frozen). For domestic technical standards, Huawei needs to
check after Operator share domestic technical standards.
*3.5G AAU:
PC
Huawei's 3.5G AAU supports TAB's test to verify Out Of Band Emission and Spurious requirements in 3GPP.
During the test, separate the AAU's TRXUA and composites antennas and use a dedicated adapter board connected
to the TRXU for testing. This test method has been applied to the test of major operators such as China Mobile.
Huawei will follow 3GPP (+3month after the standard frozen). For domestic technical standards, Huawei needs to
check after Operator share domestic technical standards.
PC *mmWave AAU：
The high-integrated architecture cannot support the traditional connectors test method， so 3GPP defines the OTA
test method in chamber (Huawei had built the test chamber in headquarter).
The 3.5GHz AAU and 3.5GHz RRU support FFT Frequency Scanning function, which function can monitor received
spectrum waves of DU through EMS.
PC The 3.5GHz AAU and 3.5GHz RRU cannot monitor transmitted spectrum waves through EMS.
Base station type of 3.5GHz AAU is 1-H of TS 38.104: Test method is TAB or OTA.
Base station type of 3.5GHz RRU is 1-C of TS 38.104: Test method is through Antenna connector.
The 28GHz AAU do not support FFT Frequency Scanning function.

PC
Base station type of 28GHz AAU is 2-O of TS 38.104: Test method is OTA.
*3.5GHz：
Huawei supports the failsafe mechanism, and the processing mechanism could be divided into low-medium-high three
levels:
(1) low Level: Only a small number of TRX channels failed, the performance loss and coverage loss still can be
FC tolerated，AAU will keep working.
(2) Medium level: Some TRX channels failed, a normal hardware alarm will be reported to U2000, AAU will still keep
working.
(3) High Level: More TRX channels failed, a serious hardware faulty alarm will be reported to U2000. End-users will
be forbidden to access to the network, and an alarm will be reported to U2000.
28GHz：
Huawei supports the failsafe mechanism, and the processing mechanism could be divided into low-medium-high three
levels:
(1) low Level: Only a small number of TRX channels failed, the performance loss and coverage loss still can be
FC tolerated，AAU will keep working.
(2) Medium level: Some TRX channels failed, a normal hardware alarm will be reported to U2000, AAU will still keep
working.
(3) High Level: More TRX channels failed, a serious hardware faulty alarm will be reported to U2000. End-users will
*3.5GHz:
In case the TRX is detected to be faulty, the corresponding receiver and PA will be both switched off. This processing
does not damage the reciprocity of the uplink and downlink channels.
In case the faulty elements ratio within one TRX exceeds y%, the two corresponding TRX of dual polarization will be
PC
switched off.
The minimum time granularity for an AAU to check channel faults is minute-level. The effective time of troubleshooting
is 10 ms.
About y parameter, it will be provided after discussion with customer.
28GHz:
In case the active element is detected to be faulty, the corresponding receiver and PA will be both switched off. This
processing does not damage the reciprocity of the uplink and downlink channels.
In case the faulty elements ratio within one TRX exceeds y%, the two corresponding TRX of dual polarization will be
PC
switched off.
The minimum time granularity for an AAU to check channel faults is minute-level. The effective time of troubleshooting
is 10 ms.
About y parameter, it will be provided after discussion with customer.
FC 3.5GHz AAU provide brackets support mechanical tilt and the down tilt is more than 15°,can reach to 20°.
3.5GHz AAU provide brackets support mechanical tilt and the down tilt is more than 15°,can reach to 20°.
FC
(Note : HAAU5213 20°, HAAU5112c 15°)
PC Material of 28GHz antenna radome is outdoor PC, loss is about 0.3dB, and dielectric substance is less than three.
Huawei will follow 3GPP specifications，based on 3GPP, the guard band is not needed.
FC
And Huawei needs to check after Operator share domestic technical standards.
Huawei will follow 3GPP specifications，based on 3GPP, the guard band is not needed.
FC
And Huawei needs to check after Operator share domestic technical standards.
For TDD system, transmitter is not working at the same time of receiver, thus passive IM of TX signal will not degrade
NA
receiver performance. From this point of view, PIM specification is not critical for TDD.
*3.5G:
FC The output power adjust range of 3.5G AAU is 10dB, the adjust step is 0.1dB.
The output power adjust range of 3.5G RRU is 13dB, the adjust step is 0.1dB.
*28G:
FC
The output power adjust range is 10dB, the adjust step is 1dB.
Huawei 5G equipment supports low power/high efficiency solutions：

1. High efficiency heat dissipation technology（E.g. Bio Leaf heat sink）has been adopted for natural cooling, no
needs for fans.
FC
2. High integration chips has been adopted for reducing power consumption
3. High efficiency PA (E.g. GaN PA) has been adopted for improving power efficiency.
4. DPD technology has been adopted for improving power efficiency.
Huawei 5G gNB will support power saving solutions as follows:

1. Symbol-level PA shutdown(2019Q2)：For symbol-level PA shutdown”, it turns off PAs during periods of symbols
that do not contain any data to transmit, which can save about 15% power consumption of the RF module when traffic
FC is low (about 10%)；
2. Massive MIMO RF channel shutdown(2019Q4): some transmit channels of RF module can be turned on/off
dynamically based on traffic load and configuration thresholds, and it can save about 10% power consumption of the
RF module when traffic is low(about 10%).
PSU intelligent sleep mode: In NR equipped with Huawei AC/DC PSUs, redundant PSUs enter sleep mode during off-
FC peak hours.
It can improve the power efficiency of the active PSUs, and reduce NR power consumption.
Massive MIMO RF channel shutdown: some transmit channels of RF module can be turned on/off dynamically based
FC on traffic load and configuration thresholds, and it can save about 10% power consumption of the RF module when
traffic is low(about 10%).
Huawei will provide the SFN solution to match this requirement that two or more cells are combined and operate with
FC
the same PCI, and provide capacity as much as the sum of all cells.
- MU-MIMO
In 5G RAN2.1,
for Sub6G:
PDSCH MUBF with maximum 16 layers is supported for 32/64Trx.
PDSCH MUBF with maximum 8 layers is supported for 16Trx.
PUSCH MUBF with maximum 4 layers is supported for 16/32/64Trx.
PDCCH MUBF with maximum 4 layers is supported for 16/32/64Trx.
FC PDSCH/PDCCH/PUSCH MUBF is under study for 8Trx
for mmWave:
PDSCH MUBF with maximum 4 layers is supported for 4Trx.
PUSCH MUBF with maximum 4 layers is supported for 4Trx.
PDCCH MUBF with maximum 2 layers is supported for 4Trx.
PUCCH MUBF is not supported either for Sub6G or for mmWave.
Up to 8 ports per CSI-RS resource per UE is supported. Different CSI-RS port number can be configurable and CSI-
RS port adaptation according to UE capability is supported.
CSI-RS resource cell periodicity is configured as 5ms. For user-specific CSI-RS configuration, CSI-RS is aperiodic. It
is based on scheduling and the minimum interval is 40ms in default.
PC
The number of RRC connected UEs isn’t considered by CSI-RS configuration.
The power boosting factor of the CSI-RS can be configured by parameters. The default is no power boosting. The
smaller the number of CSI-RS ports, the less RE resources are used, and the higher the power can be boosted
theoretically.
The difference between gNB physical antenna number and UE port number is handled by Massive MIMO technology.
For 2T4R UE, the maximum UE port number is 4. So the maximum layer number for a UE is 4.
C-band applies digital beamforming:
SUBF：If only 1user data is transmitted on the PRB,SUBF weight is adopted for maximize the received SINR of this
user only.
MUBF：If mutiple user data is transmitted on the PRB, MUBF weight is adpoted for maximizing the received SINR of
FC all these users so that cell capacity is optimized. Multiple UEs with low correlation and well signal quality will be
paired in MUBF for capacity improvement.
SUBF/MUBF adaptation：the users with well signal quality and low correlation between each other are paired for
MUBF. Otherwise, the user will work in SUBF mode.
SUBF/MUBF weight generation：instead of predefined broadcast beam for the common channel and reference
signal, the SUBF/MUBF beam for the data channel is dynamically generated from SRS channel estimation or PMI
feebback.
Huwei supports PMI & SRS self-adaption for both SU-MIMO and MU-MIMO. gNB can dynamic select PMI feedback
based beamforming (based on DL reference signal) or SRS feedback based beamforming (Based on DL-UL
reciprocity) based on SRS SINR. For near & middle point UE with good SRS signal quality, SRS-based BF weight is
FC adopted. Otherwise, PMI is adopted.
Huwei supports Codebook-based type I based on DL reference signal.
All UE antenna configurations (1T4R, 2T2R, 4T4R, etc.) are supported  based on DL-UL reciprocity. When UE
antenna configuration is 1T4R or 2T4R, UE support SRS antenna switching to get full channel measurement.
Huawei AAU5613 (C-Band, 64T64R) has 192 antenna elements.
In Huawei AAU5613, a logical antenna element is composed of three antenna elements of the same polarization.
In Huawei AAU5613, 64 transceivers are used. Each transceiver is connected to one logical antenna.
All 64TRX are used to form one antenna array. No sub-array in AAU5613.
5.2 dBi, to be presented at the upcoming workshop
10dBi, to be discussed at the upcoming workshop
All 64TRX are used to form one antenna array. No sub-array in AAU5613.
AAU5613 64TRx array gain： 10log(32) = 15dB
Digital beamforming is applied for 3.5GHz transmission. Multiple UEs with low correlation and well signal quality will be
paired in MUBF. Zero Forcing technology to further reduce multi-user interference to improve cell capacity.
In Huawei early software release, a maximum of 16 DL streams is supported. This means that a maximum number of
16 UEs where 1 stream per UE can be supported. To achieve this maximum number of UEs, UEs are assumed to be
separated to allow for minimal channel corrleation. Details to be discussed at the upcoming workshop.
For a single UE with 2T4R, number of layers in DL can be 1~4, which depends on the wireless channel condition of
UE.
The beam forming in C-band massive MIMO is achieved via digital precoding at the baseband.
For each TTI, different MU-MIMO total layer number can be scheduled, different UEs grouping can be chosen: those
users in low channel correlation between each other can be scheduled as spatial multiplexing otherwise scheduled as
different RBs. .Zero Forcing technology to further reduce multi-user interference to improve cell capacity.
UE obtained the CSI information based on CSI-RS measurment.
Aperiodic CSI-RS is supported in current version which minimum interval is 40ms in default.
Huawei AAU5613 dimension is 795 mm x 395 mm x 220 mm (HxWxD).
The Secondary Node Change procedure is initiated when UE moves from one NR cell to another NR cell.
The SgNB change is based on SSB measurement.The SSB sweeping of two cells are independent.When SgNB
change is performed，UE will receive the SSB and synchronize to the new cell ，then do random access
procedure.There is no impact on random access time.
Huawei HAAU5213 has 768 antenna elements （dipoles）.
Two antenna elements of the same polarization is connected to one PA.
6.7dBi
9.7dBi (Due to two antenna elements of the same polarization grouped to form a logical antenna element, so the
logical element gain is 9.7dB= 6.7dB+10*log(2) )
Total 32.5dBi for 4 sub-array, each array is about 29.5dBi.
Hybrid beamforming is adopt in mmWave.Hybrid beamforming includes two step beamforming: analog beamforming
and digital beamforming. UEs in the same beam is classified into one beam, and UEs in different groups may be
spatial multiplexed.gNB tries to allocated different DMRS port for MU users to alleviate the MUBF interference.
HAAU5213 supports a maxmium of 4 streams in the downlink. It can support a maximum of 2 UEs where each UE has
two streams in DL.
For a single UE with 2T4R, number of layers in DL can be 1~4, which depends on the wireless channel condition of
UE.
Hybrid analogue / digital beam forming are applied for mmWave transmission.
For analog beamforming, UE needs to feedback best beam information to gNB, gNB generate analog beam
accordingly. For downlink digital beamforming, UE needs to feedback CSI information to gNB, gNB processes digital
beamforming according to UE feedback information.
Multiple UEs with low correlation (based on SRS measurement) and well signal quality will be paired in MUBF for
capacity improvement.
UE obtained the CSI information based on CSI-RS measurment.
Aperiodic CSI-RS is supported in current version which minimum interval is 40ms in default.
Huawei HAAU5213 dimension is 585 mm x 300 mm x 152 mm (HxWxD).
The Secondary Node Change procedure is initiated when UE moves from one NR cell to another NR cell.
The SgNB change is based on SSB measurement.The SSB sweeping of two cells are independent.When SgNB
change is performed，UE will receive the SSB and synchronize to the new cell ，then do random access
procedure.There is no impact on random access time.
AAU5613 AAU5313 RRU5258

number of elements 192 192 N/A
number of TX/RU 64 32 8
FC number of subarrays 64 32 N/A
power per TX/RU 3.13W 6.25W 30W
power per element 1.04W 1.04W N/A
In 2019Q2, Huawei plan to launch two small cell products.

pRRU5935 (single band): C-Band, NR 100MHz, 4T4R
FC pRRU5936 (multimode and multiband): C-Band, NR 100MHz, 4T4R & 1.8G+2.1G, LTE 2T2R
• IBW (Instantaneous Bandwidth): to describe the maximum bandwidth range between the highest RF signal and
lowest RF signal that an RF instrument generates simultaneously in the same channel. It is one of most important
specification of the RF instrument to show the capability of generating the RF signal in wider bandwidth range
instantaneously to overcome the limitation of discontinuous spectrum owned by operators;
• OBW (Occupied Bandwidth): to describe the total effective bandwidth of the multi RF carrier that an RF instrument
generates simultaneously;
FC • Below picture for your reference for easy understanding.
Working band range: it is the bandwidth of the duplex filter, For example, RRU5613 Band 42 model could support
working band range from 3400MHz~3600MHz, while Band 43 model could support 3600MHz~3800MHz. In general,
Working band range>= IBW>= OBW.
NOTE: In the lab test scenario, 24 layers are supported in DL. In commercial scenarios, 16 layers are supported in DL.
The conditions are:
1. Unloading network;
2. Static Test, DL SINR > 27dB, Users are in low channel correlation between each other;
FC 3. 3.5G 64TRX, configure according 100M Bandwidth and DL：UL=3:1 (DDDSU)
4. Excluded (such as MME/transmission/UE) abnormal throughput decrease caused by non-Huawei equipment should
be excluded.
5G RAN 2.0: 64T64R AAU is planning to support DL 24/16 layers, UL 8 layers; 32T32R AAU is planning to support DL
24/16 layers, UL 8 layers; 8T8R RRU is planning to support DL/UL 8/4 layers. To achieve maximum layers, it depends
FC on the detailed scenarios. The roadmap for improvement of layers is still under evaluation based on the forecasted
traffic load, performance improvement and capability of hardware.
It is possible for the user to obtain the PRB resources of the two carriers by means of carrier aggregation.
Huawei 5G RAN 2.0 support 40MHz+40MHz, 40MHz+60MHz, 100MHz+100MHz CA combinations. N78 CA will be
included in R15 standard. The terminals must be capable of supporting CA.
The CA combinations supported by NR RAN 2.0 are 40MHz+40MHz, 40MHz +60MHz, and 100 MHz +100MHz. The
120MHz bandwidth CA combination will be supported after analysis based on market requirements and standard.
The maximum occupied bandwidth with a combination of 2 NR Carriers, currently Huawei latest AAU5613 (64T64R
IBW 200M/ 200W) could support maximum up to 2x100MHz NR carrier, the total OBW is 200MHz.
Huawei current planned model will support maximum 5 NR carriers in band n78, 40MHz per carrier. If 100 MHz is
configured for each carrier, a maximum of two carriers are supported.
Huawei current planned the 5G RRH is hardware ready for MoRAN, 2 NR carriers are supported, and the SW is
planning to support MoRAN in 2019H2.

Huawei current planned the 5G RRH is hardware ready for MoCN, and the SW is planning to support MoCN in
2019H2.
It’s possible to implement MOCN with AAU5613 with only one carrier. This feature has no restrictions on massive
antennas and baseband boards. All PLMNs share 24/16 layers.
It’s possible to implement MOCN with AAU5613 with different carriers. 2 NR carrier was support. All PLMNs share
24/16 layers. This feature has no restrictions on massive antennas and baseband boards.
Huawei
Huawei thinks great
proposed importance
AAU5613, to the design
AAU5313 of 5G network
and RRU5258 energy
supports efficiency
a wind loadingenhancement
of 150km/h. in two aspects: hardware
efficiency improvement and software intelligent energy saving.
1. High efficiency heat dissipation technology（E.g. Bio Leaf heat sink）has been adopted for natural cooling, no
needs
Huaweifor5Gfans.
product support AISG2, and AISG3 is not defined in 3GPP standard yet, and Huawei will follow the
2. High integration
standard in case ofchips has is
standard been adopted for reducing power consumption
frozen.
3. High efficiency PA (E.g. GaN PA) has been adopted for improving power efficiency.
At the same time, 5G Network Significantly Improves User Experience:
• 20Gbps - Peak Throughput;
Huawei gNodeB can apply Reciprocity/eigenvalue based beamforming. UE transmits SRS in UL, and gNB estimates
• xGbps - Outdoor Everywhere;
channel state information according to DL and UL reciprocity, beamforming weight is generated according to
• Nx100Mbps - Indoor Experience.
eigenvalue: SVD is calculated.The single 3dB Beam width is 12.7 in horizontal, 6.1 in vertical.The power is shared
equally between RBs.
1. Symbol-level PA shutdown (under planning for 19Q2 version): it turns off PAs during periods of symbols that do not
contain any data to transmit, which can save about 15% power consumption of the RF module when traffic is low
(about 10%);
2. Massive MIMO RF channel shutdown: some transmit channels of RF module can be turned on/off dynamically
based on traffic load and configuration thresholds, and it can save about 10% power consumption of the RF module
when traffic is low (about 10%);
3. L/NR Intelligent Power-Off of Carriers in the Same Coverage (under planning for version in 2020): Huawei also
considering power saving based on inter-frequency co-coverage scenario(3.5G and 2.6G..), when the total load of
basic and non-basic cells is low, the gNodeB transfers UEs in non-basic cells to basic cells and shutdown the non-
basic cells to save energy. It can save about 20% power consumption of the RF module.
4. PSU intelligent sleep mode: In NR equipped with Huawei AC/DC PSUs, redundant PSUs enter sleep mode during
off-peak hours. It can improve the power efficiency of the active PSUs, and reduce NR power consumption.
In NR, uplink power control enables gNodeBs to control the uplink transmit power of UEs in a way that UE power
consumption can be reduced with uplink service quality guaranteed and ensured. Uplink power control applies to the
PUSCH, PUCCH, SRS, and PRACH. Downlink power control enables gNodeBs to control the downlink transmit power
of each physical channel to ensure and improve the downlink service quality while reducing the gNodeB power
consumption. Uplink power control applies to the PDSCH, PBCH, and PSCH.
Furthermore, supporting by Huawei Hisilicon R&D team as well as Energy product line, the power efficiency of Huawei
In NSA, terminal RRC connectivity is maintained in LTE. Only when LTE is connected, NR user plane can be
connected. For LTE-NR NSA DC capable UE, NR connection will be triggered if LTE state transit from idle to
connected mode. After a specific timer and there’s no data transmission, NR connectivity will be released. After NR
connection release, If UE has data traffic and traffic volume threshold is satisfied, NR connectivity will be setup again to
improve UE throughput. Traffic volume threshold is configurable parameter. Further, if NR signal is weak or RLF, NR
connectivity will be released.
5G terminal operation in NSA is available at 2018.Q4.
With above device connectivity management functions, efficient power saving of UE device can be achieved. DTX on
UE side is under planning.
Power amplifier efficiency is mainly related to frequency band, bandwidth and transmission power, and has little
relationship with spectrum utilization. Therefore, although the spectrum utilization rate will increase after the
introduction of F-OFDM, but under the same frequency band, bandwidth and transmit power, the Power amplifier
efficiency is unchanged.
Huawei Response: Not Compliant

Huawei proposed RF modules do not support the noise figure:
AAU5313 (3.5G): 3.5dB
AAU5613 (3.5G): 3.5dB
HAAU5213 (26G): 8.5dB
RRU5258 (3.5G): 3.5dB
Response
Attachment Remark
Name
n257 TR5 in
19A;
n256 TR4A
in 19A;
项目答标可
用具体路标
时间替
换“Huawei
will provide
roadmap
after
agreement
on this
requirement
with
Operator
after
discussion.”
项目答标可
用具体路标
时间替
换“Huawei
will provide
roadmap
after
agreement
on this
requirement
with
Operator
after
discussion.”
Please refer to
<RF Specification
Attachment 1. Out
of Band Emission
and Spurious>
Please refer to
<RF Specification
Attachment 1. Out
of Band Emission
and Spurious>
具体产品型
号能力参考
5G RANX.X
上市资料的
<Product
Specification
>
具体产品型
号能力参考
5G RANX.X
上市资料的
<Product
Specification
>
Please refer to
<08 RF
Specification
Attachment 2.
High Efficiency>
19B及以后版
本才支持
19B及以后版
本才支持
Please refer to
attachment "Reply
attachment for
3.5GHz"
Back

Key word
5G 5G NR Massive MIMO 19A RS

5G 5G NR DC&CA 19A intra-band CA
equipment
5G 5G Feature Massive MIMO 19A
advantages
low power
5G 5G Feature Massive MIMO 19B solution,expected
savings
5G 5G Feature Massive MIMO 19A PSU power saving
5G 5G Feature SA Option 19B SA，option2
active antenna, fail

safe,
beam-steering,
range
current beam
number
5G 5G Feature Massive MIMO 19A MIMO




5G 5G Feature Dynamic TDD 19A dynamic TDD

5G 5G Feature URLLC 19B mini slot
5G 5G Feature URLLC 19A 1ms user plane
5G 5G Feature URLLC 19A URLLC
5G 5G Feature URLLC 19A URLLC,eMBB
5G 5G Feature URLLC 19A URLLC,0.5ms
5G 5G Feature URLLC 19A ‘99.999%
5G 5G Feature URLLC 19A reliability，99.999%
5G 5G Feature URLLC 19A reliability
low latency,
5G 5G Feature URLLC 19A
V2X
5G 5G Feature DC&CA 19A NSA,bearer
5G 5G Feature DC&CA 19A bearer switch
5G 5G Feature DC&CA 19A SRB
5G 5G Feature DC&CA 19A DRB
5G 5G Feature DC&CA 19A SRB

5G 5G Feature DC&CA 19A DRB
5G 5G Feature DC&CA 19A RoHC
5G 5G Feature DC&CA 19A NR cell addition
5G 5G Feature DC&CA 19A NR cell modification
5G 5G Feature DC&CA 19A NR cell release
5G 5G Feature DC&CA 19A NR cell change
5G 5G Feature DC&CA 19A SCG reconfiguration
MN
5G 5G Feature DC&CA 19A
handover/change
5G 5G Feature DC&CA 19A DL traffic split
5G 5G Feature DC&CA 19A UL traffic split
5G 5G Feature DC&CA 19A UL power control
5G 5G Feature DC&CA 19A retransmission
UCNC CU-level
5G 5G Feature 19A
Coordination coordination
UCNC CU-level
5G 5G Feature 19A
Coordination coordination
5G 5G Feature DC&CA 19A dual connectivity
5G 5G Feature DC&CA 19A DC & CA

5G 5G Feature DC&CA 19A X2 delay
5G 5G Feature DC&CA 19A X2 information
5G 5G Feature DC&CA 19A traffic steering
5G 5G Feature DC&CA 19A voice
5G 5G Feature DC&CA 19A intra-band CA

5G 5G Feature DC&CA 19A intra-band CA

Inter-cell and inter-

UCNC
5G 5G Feature 19B site scheduling ，
Coordination
CoMP

UCNC
5G 5G Feature 19B JT, SMP,DMP
Coordination
UCNC
5G 5G Feature 19A JT
Coordination
UCNC
5G 5G Feature 19B Joint Reception
Coordination
UCNC Dynamic point

5G 5G Feature 19A
Coordination switching
UCNC Inter-RAT
5G 5G Feature 19A
Coordination coordinate
UCNC
5G 5G Feature 19B Multi TRP
Coordination
UCNC
5G 5G Feature 19B Multi TRP
Coordination
5G 5G Feature Wide Coverage 19A cell radius，100km
5G 5G Feature Wide Coverage 19A cell radius，100km
5G 5G Feature Wide Coverage 19A long PUCCH
optimise cell
5G 5G Feature DSON 19B
identifier，SON
5G 5G Feature DSON 19B PCI
5G 5G Feature DSON 19B MDT
dynamic energy
5G 5G Feature Energy Saving 19B
saving

UCNC Future
5G 5G Feature interference
Coordination version
coverage
5G 5G Feature Wide Coverage 19B
enhancement
5G 5G Feature Massive MIMO 19B Beamforming
5G 5G Feature DSON 19B neighbour list
5G 5G Feature DSON 19B SON

5G 5G Feature URLLC 19B scheduler，CBG
5G 5G Feature URLLC 19B reliability
5G 5G Feature Energy Saving 19B power saving
5G 5G Feature Energy Saving 19B device power
5G 5G Feature Energy Saving 19B software version
differentiated
5G 5G Feature General 19B
solution
beam sweeping
5G 5G Feature Massive MIMO 19B
procedure

Beam procedure in
5G 5G Feature 19B
Management connected state
Beam beam measurement

5G 5G Feature 19B
Management period
Beam
5G 5G Feature 19B measurment report
Management
Beam
5G 5G Feature 19B beam tracking
Management
UCNC
5G 5G Feature 19B CoMP
Coordination
UCNC
Coordination
UCNC
Coordination
5G 5G Feature Voice Service 19B Voice
5G 5G Feature SMS service 19B SMS
5G 5G Feature SMS service 19B Emergency call
5G 5G Feature SMS service 19B SRVCC
5G 5G Feature SMS service 19B SRVCC

5G 5G Feature URLLC 19B URLLC techniques
5G 5G Feature Public warning 19B Public warning
5G 5G Feature Positionning 19B Positionning
Mission Critical
5G 5G Feature MCX 19B
Service
Performanc
5G Performance 19A Latency
e
Performanc
5G Performance 19A Latency
e

Performanc
5G Performance 19A intermodulation
e
Performanc
5G Performance 19B IP Header Compre
e
Performanc
5G Performance 19A TM modes
e
Performanc
5G Performance 19A capacity gain
e
Performanc
5G Performance 19A Intererfence
e

Performanc
5G Performance 19A Intererfence
e
Performanc
5G Performance 19A Signalling
e
Performanc
5G Performance 19A User Data
e
Performanc
5G Performance 19A coverage enhancem
e
Performanc
5G Performance 19A bandwidth
e
Performanc
5G Performance 19A availability
e

Performanc
5G Performance 19A spectral efficien
e
Performanc
5G Performance 19A sector capacity
e
Performanc
5G Performance 19A Spectral Efficien
e
Performanc
5G Performance 19A Transport Overhe
e

Performanc
5G Performance 19A LTE/NR Dual-Conne
e
Performanc
5G Performance 19A intra-band CA
e

Performanc
5G Performance 19A harmonics
e
Performanc
5G Performance 19A Supplementary Upl
e

Performanc
e
Performanc
e
Performanc
5G Performance 19B Dynamic Spectrum
e

Performanc
5G Performance 19A SUL
e
Performanc
5G Performance 19A SUL
e
Performanc
5G Performance 19B mobility procedur
e
Performanc
5G Performance 19A intra-NR intra-fr
e

Performanc
5G Performance 19A LTE-NR mobility
e
Performanc
5G Performance 19A ntra-NR Inter-fre
e
Performanc
5G Performance 19A intra-LTE mobili
e
Performanc
5G Performance 19B inter RAT mobili
e

Performanc
5G Performance 19A alternative cove
e
Performanc
5G Performance 19A flexibly configur
e
Performanc
5G Performance 19A idle and connecte
e
Performanc
5G Performance 19A time offset measu
e
Performanc
5G Performance 19A QoS flows
e

Performanc
5G Performance 19A QoS flows
e
Performanc
5G Performance 19A handover
e
Performanc
5G Performance 19A scheduler objecti
e
Performanc
5G Performance 19A Modulation and co
e
Performanc
5G Performance 19A scheduler objecti
e

Performanc
5G Performance 19A numerology
e
Performanc
5G Performance 19A TTI
e
Performanc
5G Performance 19A guard band
e
Performanc
5G Performance 19A subcarrier spacin
e
Performanc
5G Performance 19A slot formats
e
Performanc
e
Performanc
e
Performanc
5G Performance 19A UL interference c
e
Performanc
e
Performanc
5G Performance 19A UE power consumpt
e

Performanc
5G Performance 19B UE power consumpt
e
Performanc
5G Performance 19A frame format
e
Performanc
5G Performance 19A TDD frame format
e
Performanc
5G Performance 19B E-RABs
e
Performanc
5G Performance 19B E-RABs
e

Performanc
5G Performance 19A MU-MIMO
e
Performanc
5G Performance 19A suppressing trans
e
Performanc
5G Performance 19A X2 user plane and
e
Performanc
5G Performance 19A inter-band carrie
e
Performanc
5G Performance 19A X2 user plane on
e
Performanc
5G Performance 19A RNA
e
Performanc
5G Performance 19A NSA SA
e
Performanc
5G Performance 19A power boosting
e

Performanc
5G Performance 19A SSB Burst
e
Performanc
5G Performance 19A RACH format
e
Performanc
5G Performance 19A number of symbols
e
Performanc
5G Performance 19A number of symbols
e
Performanc
5G Performance 19A Short-PUCCH and L
e
Performanc
5G Performance 19A PRB section
e
Performanc
5G Performance 19A PRB section
e

Performanc
5G Performance 19A GP Guard Period S
e
5G 5G Feature Arch. 19A NSA
5G 5G Feature Arch. 19A CU/DU
5G 5G Feature M-MIMO 19A MIMO
5G 5G Feature Energy Saving 19B saving
5G 5G Feature VONR 20A VONR

5G 5G Feature UCNC 20A Comp
5G 5G Feature SUL 19B Decoupling
5G 5G Feature CA 19A CA
5G 5G Feature Arch. 19A Tromboning
5G 5G Feature Arch. 19A EPC

5G 5G Feature Mobility 19B Mobility
5G 5G Feature QoS 19A QoS Flow
5G 5G Feature Slice 19A Slice
5G 5G Feature QoS 19A Slice
5G 5G Feature Signaling 19A Bearer

5G 5G Feature Signaling 19A Tracking
5G 5G Feature Mobility 19B Mobility

5G 5G Feature DC/CA 19A DC
5G 5G Feature Security 19A E2E Security
5G 5G Feature Signaling 19A Reslection
5G 5G Feature Mobility 19A Mobility
5G 5G Feature Signaling 19A L2,L3

5G 5G Feature Specturm 19B Sharing
5G 5G Feature Specturm 19B Sharing
5G 5G Feature Sync. 19B sync.
5G 5G Feature Sync. 19B sync.
5G 5G Feature RAN sharing 19B Sharing
5G 5G Feature RAN sharing 19B Sharing
5G 5G Feature Dimension 19A Dimension
5G 5G Feature Performance 19A Performance

5G 5G Feature Energy Saving 19B Energy Saving
5G 5G Feature Energy Saving 19B Energy Saving
5G 5G Feature Security 19A Security
5G 5G Feature OAM 19A OAM
5G 5G Feature M-MIMO 19A code
5G 5G Feature M-MIMO 19A code

Flexible RS: DMRS, CSI-RS, SRS FC

DL/UL intra band CA FC
The proposer shall suggest the advantages of equipment design

and device utilization used to achieve low power/high efficiency by FC
proposed equipment and the expected savings resulting from it.
The proposer shall suggest power saving or low-power operating

solution that can be utilized by our Company by proposed
equipment, including expected savings. The proposed solution shall
minimize the impact on quality and shall be easily FC
applied/monitored/analyzed by operator (e.g. saving operation
method that is operated in real time by Traffic Load or the
operator’s operation/prior plan).
The equipment operation plan is required to minimize the standby

power without affecting quality such as service interruption. The
proposer suggests the saving measures such as blocking / FC
controlling the PSU power supply in the standby state in detail and
implements them so that the operator can remotely control.
Please describe SA options you support FC
Active Antenna Fail Safe: Active antennas shall support a failsafe

mechanism, such that if one or more individual transmit receive
(TRX) chains fails, the active antenna is able to reconfigure itself in
such a way that service and functionality is maintained.
The Supplier shall describe how this failsafe mechanism is FC
implemented. The Supplier shall also quantify the reduction in
performance in terms of beam steering capability, spatial layer
support, coverage or otherwise, depending on the number of failed
TRXs.
Beam-steering range (or called beam sweeping range) in azimuth

and elevation:
FC
Specify the maximum beam steering in Horizontal plane and in
Vertical plane for narrow beams
Maximum concurrent beam number (UL&DL) FC
Please describe your Massive MIMO FC
Support MU-MIMO FC
Dynamically switch between various levels of MU-MIMO
transmission on a per-TTI basis depending on radio conditions, UE FC
grouping and channel orthogonality, and other scheduling inputs
Supported maximum MU-MIMO layer number in downlink FC
Supported maximum MU-MIMO layer number in uplink FC
Maximum number of layers per user in downlink FC
Maximum number of layers per user in uplink FC
2-16 concurrent users with 1 spatial layer each in downlink MU-
FC
MIMO
2-8 concurrent users with 2 spatial layers each in downlink MU-
FC
MIMO

2-4 concurrent users with 4 spatial layers each in downlink MU-

FC
MIMO
2-16 concurrent users with 1 spatial layer each in uplink MU-MIMO PC
Based on 16-layer MU-MIMO, 2x2 MIMO UEs of 8 and based on

FC
8-layer 2x2 MIMO UEs of 4 shall be supported simultaneously.
A form of reciprocity / eigenvalue based beam forming for NR FC
Any beamforming performance restrictions, especially with respect

FC
to limits imposed by highly mobile users
PDSCH per TTI dynamic Rank adaptation FC
PDSCH per TTI Dynamic SU/MU MIMO adaptation FC
PDSCH Tx Diversity: Mandatory to support implicity Tx diversity FC
PDSCH Tx Diversity and close-loop SU/MU MIMO: Mandatory to

FC
support dynamic switching (dynamic adaptation)
Horizontal and vertical half power beam width for Narrow Beams:
Specify the 3dB beamwidth of the radiation pattern in horizonttal
FC
plane and the 3dB beamwidth of the radiation pattern in vertical
plane
How many beam number will be swept for SS Block transmission FC
Please describe the concept for handling common control channels

(system info, random access, paging) in Massive MIMO for bands FC
below 6 GHz
Dynamic optimal selection of transmission modes and spatial

FC
multiplexing mode to suit instantaneous radio conditions
The 5G RAN system shall support flexible and dynamic assignment

of TDD transmission resources (in contrast to TD-LTE, which has a
fixed UL/DL configuration and assumptions about traffic loading). PC
The Supplier shall detail how the dynamic assignment of TDD
transmission will function.
Interference control solution shall be provided to ensure that there

is no mutual interference effect when the calls with different DL : UL
PC
Configuration are used in combination and the proposer's product
can perform dynamic TDD operation in the multi-cell environment.
RS Coordination for CLI Measurement: Intra-DU TRP-TRP cross
PC
link interference measurement for dynamic TDD

RS Coordination for CLI Measurement: NW configuration for UE-

PC
UE cross link interference measurement for dynamic TDD
Inter DU RS Coordination for CLI measurement: Inter DU TRP to
TRP cross link interference measurement. Coordinate the RS and
measurement window across DU to make CLI (cross link PC
interference) measurement which enables the dynamic TDD slot
format coordination
The Supplier shall support “mini-slots”, which are frames that are
able to pre-empt normal transmission and can start at any time.
NC
The Supplier shall support features to map the use of mini-slots to
specific QoS flows or slices.
Please provide a recommended configuration to support the URLLC

target for user plane latency of 1 ms with reliability of 99.999% in FC
3.5GHz
Do you propose separate numerologies for normal eMBB traffic and

FC
ultra-low latency service?
Do you support different numerologies multiplexing within same
NC
carrier for normal eMBB traffic and ultra-low latency service?
URLLC DL or UL one way delay≤0.5ms shall be satisfied PC
2, 4 and 7 symbol mini slots should be supported. NC
Mini-Slot Based Pre-emption for URLLC should be supported. NC
Cross Scheduled Mini Slot for PDSCH: 2,4, and 7 symbol PDSCH
allocation starting in ANY OFDM symbol within a slot and with DCI NC
at the beginning of the slot
Self Scheduled Mini Slot for PDSCH: 2, 4 and 7 symbol PDSCH

allocation starting in OFDM symbol within a slot and with DCI in the NC
SAME OFDM symbol
99.999% URLLC Reliability required by ITU shall be supported. PC
Please describe how ultra-reliability (e.g. >99.999%) can be

FC
verified, e.g. for real life environments.
When supporting Reliability, the detailed Call Flow and Algorithm

FC
shall be provided.
Describe the strategy to support low latency service (such as

FC
AR/VR, V2X, etc.) from QoS perspective
The vendor shall list supported bearers in NSA FC
PDCP: Support configuration of bearer-switch or bearer-split

FC
depending upon UE capability
EN-DC(EUTRA-NR Dual Connectivity): PDCP support split-SRB
FC
and duplicate SRB
EN-DC: PDCP support split-DRB and duplicate DRB under EN-DC PC
NR and NR DC: PDCP support split-SRB and duplicate SRB PC

NR and NR DC: PDCP support split-DRB and duplicate DRB PC
PDCP: support ROHC FC
EN-DC: MN(Master Node) initiated SN(Secondary Node) addition

FC
should be supported
EN-DC: SN modification: MN/SN initiated with and w/o MN

involvement including operator configurable triggering conditions
PC
(e.g. DL and UL link quality, load based, etc.) with operator
configurable time-to-trigger, hysteresis, and offset parameters.
EN-DC: SN release: MN/SN initiated involvement including operator

configurable triggering conditions (e.g. DL and UL link quality, load
PC
based, etc.) with operator configurable time-to-trigger, hysteresis,
and offset parameters.
EN-DC: SN change: MN/SN initiated including operator

configurable triggering conditions (e.g. DL and UL link quality, load
PC
based, etc.) with operator configurable time-to-trigger, hysteresis,
EN-DC: SCG reconfiguration: used for SCG establishment and

SCG reconfiguration within the same or different SN including
operator configurable criteria for PSCell change (e.g. DL and UL FC
link quality, load based, etc.) with operator configurable time-to-
trigger, hysteresis, and offset parameters.
EN-DC: MN handover/change: with or w/o SN change and including

data forwarding including operator configurable criteria (e.g. DL and FC
UL link quality, load based, time-to-trigger, and hysteresis etc.)
For NSA DC, DL traffic dynamic split between SCG and MCG
FC
should be supported
For NSA DC, UL traffic dynamic split between SCG and MCG
FC
should be supported
NSA DC uplink power control: Semi-static power splitting mode

FC
should be supported
NSA DC uplink power control: Dynamic power sharing mode should

PC
be supported
NSA DC uplink power control: SUO-case1 (Single Uplink
PC
Operation) mode should be supported
EN-DC:Support fast centralized retransmissions of lost PDCP
FC
PDUs when performing inter-gNB-DU mobility
The Supplier shall provide CU-level coordination features to enable
fast redirection of traffic flows and packet forwarding in the case of FC
5G radio link failure
The Supplier shall provide CU-level coordination features to enable

traffic flow and load balancing functions to distribute flows optimally
FC
between 4G and 5G. The Supplier shall describe the mechanism
and expected performance gain of these features.
The Supplier may provide a feature to optimise the use of NR by

modifying relevant thresholds which dictate whether a device will FC
attempt to start or stop using NR dual connectivity
Describe LTE and 5G interworking including DC and CA FC

Please provide the maximum delay requirements for the X2

interface when used for LTE-NR Dual Connectivity. Does the
FC
maximum delay depend upon the option used (option 3 vs. 3x)?
How does the Xn interface delay impact the E2E application delay?
Please indicate what information should be shared between gNB

and eNB to make Dual Connectivity operation effective and fair for FC
all users.
Operator can configure steering the traffic to NR vs E-UTRAN cells

based on QCI, cell load, or other parameters signalled by the core PC
network over S1-MME.
With 5G NSA (option 3 family), the 5G RAN shall either fully

support QCI=1 and QCI=2 bearers or support voice services at
FC
least via create the QCI=1 and QCI=2 bearers over the E-UTRAN
access.
Maximum number of Active CC in the DL for 3.5GHz intra-band CA FC
Maximum number of Active CC in the UL for 3.5GHz intra-band CA FC
EN-DC with LTE CA: LTE 1CC + NR 1CC (NR is Band 3.5GHz)
FC
should be supported
FC
should be supported
FC
should be supported
FC
should be supported
NR 3.5GHz and NR 28GHz inter band CA should be supported PC
NR 3.5GHz and NR 28GHz DC should be supported PC
Cross carrier scheduling should be supported for CA PC
CC without Synch and Cross CC QCL PC
Inter-site CA should be supported PC
Inter-cell and inter-site scheduling should be supported. FC

NC-JT (Non-Coherent Joint Transmission) should be supported. FC
C-JT (Coherent Joint Transmission) should be supported. PC
Joint Reception should be supported. FC
Dynamic point switching should be supported. PC
DU level LTE and NR Inter-RAT coordinated scheduling should be

PC
supported.
Multi TRP Single DCI scheduling: NC JT with joint scheduler FC
Multi TRP Multi DCI scheduling: NC JT with indepndent scheduler,

FC
2 PDSCH allocation using 2 separate DCI within a given slot.
Cell radius of up to 100KM should be supported. PC

The Supplier shall support a 5G maximum cell range >100 km for
PC
low density areas scenario, e.g. maritime coverage
Long PUCCH should be supported FC
The Supplier shall provide a SON feature to automatically optimise

FC
5G cell identifiers
NR gNB shall detect and fix PCI collision/confusion, raise an alarm

NC
about the conflicts and report PCI to O&M system.
MDT (Minimization of Drive Test) shall be supported PC
Dynamic Energy Saving based on traffic load should be supported FC

Vendor to indicate and describe 5G NR inteference management

PC
support
Coverage enhancement features should be described FC
Please describe your Massive MIMO solution and other

FC
beamforming technology such as high-speed beamtracking
For SA NR, what are the limitations and constraints with neighbour
FC
list for both intra and inter-RATs?
Do you support any SON procedures for NR? FC
3GPP define the concept of mini-slots for URLLC traffic. State your
NC
support for 2,4 and 7 symbol URLCC mini-slots?

For the above URLCC support, state what your scheduler strategy
is for supporting recovery procedures of punctured eMBB traffic.
NC
For example, multi-bit HARQ indicates which Code Block Group
(CBG) of a codeword needs retransmission.
Several techniques are being defined in support for the reliability

aspect of URLLC. State your support for traffic pre-emption, semi- NC
persistent scheduling, PDCP layer packet duplication.
The solution should support node efficient power saving features FC
The solution should support device efficient power saving features FC
Vendor shall detail the plan of 5G SW Releases and how this SW

Release plan is related to Single RAN SW Release plan as the goal FC
is to have one unique SW upgrade where Single RAN is in place.
For the functions and features within the scope of 3GPP R15 and
foreseeable R16 items, what are the features or functionalities that
can differentiate your solution with others (you are doing in a better
way or your solution performs better)? For each function or feature FC
you listed, please provide detailed description (need to specify the
benefits, how it works, whether it is purely software feature or it has
hardware dependency and/or device dependency).
Vendor should describe beam sweeping procedure during

FC
Synchronization process in Initial Access.

Vendor should describe beam management FC

procedure in RRC-CONNECTED states.
Vendor should describe how often UE needs to perform beam

FC
measurements configured by NG RAN
Vendor should describe how UE reports the measurement report

FC
configured by NG RAN
Vendor should describe beam tracking algorithm. FC
Vendor should state whether your solution can

support DL CoMP and UL CoMP (DL and UL
coordination multi-point transmission) between micro FC
cells under same DU. Please elaborate how it is
supported and any limitations it may have.
Vendor should state whether you can support DL CoMP and UL

CoMP (DL and UL coordination multi-point transmission) between
FC
macro cells under same DU. Please elaborate how it is supported
and any limitations it may have.
Vendor should state whether you can support DL CoMP and UL

CoMP (DL and UL coordination multi-point transmission) between
macro cells under different DU. Do you have inter DU connection
FC
(through Switch or through direction connection), and what’s the
max number of DUs can be connected for CoMP? Please elaborate
if any limitations need to be considered.
Vendor shall detail its solution and availability (roadmap) in order to

FC
support voice services for 5G NR users.
Vendor shall detail its solution and availability (roadmap) in order to

support SMS services for 5G NR users. FC
主要取决于核心网路标支持情况。
Vendor shall describe how Emergency Call is supported in different

FC
5G NR operations, i.e. the 3GPP NR Options 3/3a/3x, 7/7a/7x, 2
Vendor shall inform about SRVCC options from 5G NR (VoNR) to

FC
4G (VoLTE)
Vendor shall inform about SRVCC options from 5G NR (VoNR) to
FC
3G and 2G.

Vendor shall describe the support of URLLC techniques for system-

critical applications, including fast retransmissions, improved block FC
error rate, and very low latency.
Vendor shall provide its roadmap on supporting Public warning

PC
system over NR by specifying product and component proposed.
Vendor shall describe network-positioning methods supported with

timelines (e.g. equivalents of LTE A-GPS, OTDOA, E-CELLID or PC
RF pattern).
Vendor shall provide its roadmap on supporting MCX (Mission

Critical Services) by specifying product and component
proposed, including but not limited to MCPTT (Mission PC
Critical Push-to-talk), MC Voice and MC data.
主要取决于核心网路标支持情况。
Expected User Plane Latency for NSA (3.x) and SA (2)FC
Expected Control Plane Latency for NSA (3.x) and SA FC

Describe the risk of intermodulation between C band

and 1800 MHz band. Also describe mechanisms that
FC
Huawei have deployed to avoid/mitigate the risk of
intermodulation.
The solution should support and include IP Header

FC
Compression.
The solution should support MU-MIMO on all defined

FC
TM modes.
Please describe the capacity gain supported by

above xTxR and Beamforming compared to L1800 FC
2T2R 20MHz.
The solution should support Intererfence reduction

FC
functionality. Please describe the solution.

The solution should support Interference rejection

FC
functionality. Please describe the solution
The solution should support transport of Signalling

between the solution and the devices dynamically
based on signal quality and strength using:
- 5G NR or FC
- LTE or
- DL/UL combinations on both 5G NR and LTE
The solution should support transport of User Data

between the solution and the devices dynamically
based on signal quality and strength using:
- 5G NR or FC
- LTE or
- DL/UL combinations on both 5G NR and LTE
Please describe functionality/building practices that

can enhance performance and reduce any limitation FC
(e.g. coverage) the 5G NR UL.
The Supplier should present their

view/recommendation of what bandwidth is required
for efficient 5G operations in the 5G NR spectrum.
FC
Are there restrictions depenfing on the bandwidth
aquired example different TTI and subcarrier
spacings?
Which is your availability for NSA (3.x) and SA (2)

FC
options?

Vendor shall indicate the average and peak spectral

efficiency for low frequency bands, C-Band and
mmWave solutions with the following scheme (adding FC
the rows to illustrate the more significant
combinations), detailing DL and UL where applicable.
vendor shall describe how the sector capacity and the

maximum user throughput scale with increasing BW,
FC
MIMO and modulation scheme order, detailing DL
and UL where applicable
The Vendor shall explain the improvement in Spectral

Efficiency between LTE and 5G NR when comparing
similar configurations (e.g. same order of MIMO) for FC
all the combinations included in previous table,
describing the reasons for the improvement
The vendor shall detail how big will the Transport

Overhead be for 5G (IPSEC, Protocols, etc.) for each FC
of the supported Transport solution

Vendor shall describe its support for LTE/NR Dual-

Connectivity and availability (for all supported
architecture options). Please list all the supported
FC
band combinations in the proposed solution and also
the SW versions and the features that are required to
support it
Vendor shall provide details about the support of

intra-band CA for NR for the different band and BW FC
options.

Vendor shall indicate if 1800 MHz harmonics could

be an issue for 3.5 GHz and how they proposed to FC
solve it.
Vendor shall provide its view on the need of 5G NR

deployed at C-band or mmWave to have a
Supplementary Uplink (SUL) using sub-3 GHz LTE
FC
frequencies to improve coverage and experience.
The Vendor shall describe any other different
alternative for this purpose.

Vendor shall indicate if they can support SUL and the

main differences with other ways of sharing spectrum, FC
recommending the best options.
Vendor shall indicate how SUL will impact on DL

FC
performance due to overheads
Vendor shall indicate if Dynamic Spectrum Sharing

mechanisms can be applied for implementing SUL FC
detailing how dynamic this mechanism is.

160. Vendor shall provide its support and roadmap

for 5G NR SUL using sub-3GHz LTE frequencies,
and confirm the band combinations supported in this
regard.
- 5G NR at 3.5 GHz/ 3.7 GHz + SUL at 2.6 GHz
- 5G NR at 3.5 GHz/ 3.7 GHz + SUL at 1.9 GHz FC
- 5G NR at 3.5 GHz/ 3.7 GHz + SUL at 800 MHz
- 5G NR at 3.5 GHz/ 3.7 GHz + SUL at 700 APT MHz
Vendor shall provide its support and roadmap for

deployment of 5G NR SUL and LTE in parallel on the FC
same frequency band.
Vendor shall elaborate the mobility procedures and

the features associated that allow the mobility FC
between LTE and NR and NR-NR.
Vendor shall describe its support and the features

associated with intra-NR intra-frequency mobility in FC
NSA option 3x.


FC
associated with LTE-NR mobility in NSA option 3x.

associated with intra-NR Inter-frequency mobility in FC
NSA option 3x

associated with intra-LTE mobility in NSA option 3x in FC
dual connectivity

associated with inter RAT mobility in other FC
architectural options

The supplier should provide alternative coverage

solution wherever mMIMO or beamforming antennas FC
cannot be implemented in the field
Solution must provide the ability to flexibly configure

DL:UL ratios for TDD carriers, especially if the need FC
for close synchronisation with other operators arises.
Solution must provide for full idle and connected
mode mobility for 5G NSA capable devices. The
roadmap proposal for Option 2 Stand Alone operation
FC
must also include full mobility procedures between
5G and 4G in RRC Idle, RRC Inactive and RRC
Connected states
Solution must provide for a configurable time offset
measured from the network phase synchronisation
source, typically a GPS supplied 1PPS to the start of NC
the New Radio frame/subframe to aid in
synchronisation efforts
Please confirm support for QoS flows within the NG-

FC
RAN

Please provide an overview on how QoS flow

management will function within your NG-RAN
FC
solution, especially in relation with Priority, GBR/Non
GBR and ARP
Please describe the how would the gNB decide if to

handover to eNB connected to the 5GC or with the
FC
eNB connected to a EPC where the eNB is the same
physical equipment
Please describe scheduler objectives with respect to

beam forming and MIMO and the extent to which FC
these are user configurable
Modulation and coding schemes supported and any

FC
relevant trade-offs
Please describe scheduler objectives, and

FC
configurability

What numerology subcarrier spacing is supported in

FC
sub6GHz case, 15kHz, 30khz, 60kHz?
What is the minimum TTI in sub 6Ghz case? FC
What is the minimum guard band to use different slot

FC
formats of different operators in the same area?
Can different subcarrier spacing be used on the same

PC
carrier?
Do you support dynamical switching of slot formats? NC
What is timing of switching the slot format
Can different slot formats be mixed on the same

NC
carrier?
State and describe UL interference cancelation

FC
algorithms used in order to improve UL Capacity.
Please provide the slot frame format used in your

solution (3.5GHz, 28GHz or 39GHz). What are your FC
observation and recommendations?
Vendor should provide UE power consumption

FC
comparison based on NSA (Option 3x) and SA

Vendor should provide your solution on UE power

consumption reduction management on NSA, i.e.
dynamically deactivate/activate NR link based on UE FC
traffic loads, whether this is via MAC CE or RRC
messages
Please provide your recommended frame format

design for 3.5 G NR deployment, including available
FC
beams, delay budget, and tolerance of atmospheric
duct interferences and TDD networks’ interference.
Based on your experiences on TDD network planning

and trials, please provide your recommendation on
FC
best coordination TDD frame format amongst
operators.
The number of supported E-RABs and split data radio

FC
bearers in NSA mode shall be at least 300
The number of supported E-RABs and split data radio

FC
bearers in SA mode shall be at least 300.

Multi-user MIMO SW functionality in downlink and

uplink shall be included. Possible additional HW shall
be priced separately. Provide also information about
PC
the number of simultaneous MU-MIMO users served
in a TTI, cell peak rates, total number of MIMO layers
served in a TTI, etc.
The offered radio solution shall support suppressing

transmission in configurable PRBs (PRB blanking), NC
for interference suppression.
For NSA 3x dual-connectivity operation, X2 user
plane and control plane inter-operability must be
unconditionally supported from Tenderers gNB
towards other vendors eNB and vice versa. NC
Specifically the offered gNB solution must provide
fully functional NR network when LTE is from another
vendor and vice versa.
Please describe the supported NR inter-band carrier

NC
aggregation combinations
lease provide requirements for X2 user plane one-

way delay to support NSA 3x. State clearly any
assumptions made, for example, regarding achieved
X2 throughput and PDCP/RLC buffer sizes. State FC
also if the delay requirements apply to 3GPP-
compliant or vendor-specific X2 user plane flow
control algorithm.
In SA system, present the method for managing the

Inactive UEs including the method for managing RNA FC
(RAN Notification Area) of the RRC Inactive UEs.
If there is any deterioration in capacity (the number of

cells, MIMO layers, bearers and UEs), performance
(DL/UL rate, delay, etc.) and service (VoLTE, GBR,
Non-GBR etc.) of the SA equipment after the FC
migration from NSA to SA due to the RRC Inactive
UE management operation, compared to NSA,
please explain this in detail
Vendor should present whether the beamforming
(present the dBi figures) and power boosting (-3, 0, 3,
FC
6dB) of SSB signals are performed in 3.5GHz and
28GHz bands

Vendor should present the transmission period of

SSB Burst Set Period (5~160ms) that is considered in
3.5GHz and 28GHz, the number of SSB transmitted
FC
in one SSB Burst (~8, ~64), and the number of SSB
Burst Sets required for transmission of the entire
beam.
Vendor should present the RACH format that is

supported in 3.5GHz and 28GHz bands and
applicable scenarios, respectively. Present the RACH FC
Configuration Index that is being considered and the
position of the transmission slot.
Vendor should specify the number of symbols used

as PDCCH resources by slot format in 3.5GHz and FC
28GHz bands.
Vendor should specify the number of symbols used

as Short-PUCCH and SRS resources by slot format FC
in 3.5GHz and 28GHz bands
Vendor should describe whether to support Short-
PUCCH and Long-PUCCH in 3.5GHz and 28GHz
FC
bands, and also describe how to separate them for
use
Vendor should describe whether to utilize the rest of

PRB sections excluding SSB PRB areas in SSB Slot
FC
in 3.5GHz and 28GHz bands and the relevant
purposes
Vendor should describe whether to utilize the rest of

PRB sections excluding RACH PRB areas in RACH
FC
Slot in 3.5GHz and 28GHz bands and the relevant
purposes.

Vendor should present the number of GPGuard

Period Symbols required for DL/UL conversion in
3.5GHz and 28GHz bands, and present the
Maximum Delay Spread and Propagation Delay
figures that are considered in the Dense
Urban/Urban/Rural scenario. Also, present the DL/UL FC
switching time required at the base station, DL/UL
switching time expected by terminal, and the default
TA offset value set by the base station. Lastly,
present the maximum coverage that can be
supported
Which is your availability for NSA (3.x) and SA (2) options? FC
Which is your availability for CU & DU Split? FC
Forecasted roadmap for MU-MIMO (number of simultaneous users

FC
and layers)
Forecasted Energy Saving features, and expected impact in
FC
energy saving and performance.
Which is your availability for Voice over NR UL? FC
Which is your availability for intra-site DL/UL-CoMP FC
Which is your availability for UL&DL Decoupling, and which bands

FC
will be possible to use for UL when using n78 for DL?
Which is your availability for intra-site DL Carrier Aggregation (CA)?

FC
How many carriers intra and inter-band will be possible to add?
Which architectures are supported (2, 3, 3x, 4, 7x, etc)? FC
Which are the impacts in the 4G network to support them (new

FC
interfaces, etc)?
Xn constraints in Dual Connectivity: latency introduced in

FC
User/Control planes and how to minimize the impact.
Tromboning effect FC
It is possible a 2 architecture with EPC and NRCN from different

FC
vendors?

How is connected-mode mobility from 4G to 5G implemented in

FC
NSA and SA 5G?
What is the QoS model of 5G? What Qos parameters are defined
in 5G? Does 5G QoS model allow a greater grade of flexibility than
4G QoS model?
What is the minimum resolution entity for the provision of QoS: a FC
network slice, a service bearer like in 4G?
How are applied different Qos profiles to different slices?
How is made the interaction between slices provided by 5G

network and the mechanism of policy control? Are equivalent FC
Session Data Flows (SDF) defined by PCC and slices?
Which are the 5G radio mechanism that implemented in order to

FC
comply with the Qos policy?
Can you describe how does the activation of a dedicated bearer

procedure work in 5G? You can assume for example a dedicated
FC
bearer for voNR? What are the differences versus 4G? What
differences introduces the slicing?

In 5G, is it defined the concept of Tracking area? And the concept

of Tracking Area list? When the 5G is registered but idle, the
mechanism to communicate to the 5G network the TA is like in FC
LTE, Tracking Area update? Are there any difference between LTE
and 5G with regard the location management of the UE?
If the 5G UE is registered and in idle mode, inside 5G network, it

changes of Tracking area, how is the protocol procedure to update FC
TA location? Which entities are involved?
If the 5G UE is registered and in idle mode, and it changes from 5G

to 4G, how is the protocol procedure to update TA location? Which
FC
entities are involved? What is the role of the protocol N26
established between EPC+ and 5G CN?
Can you describe how does the handover procedure between a

gNB 5G and a eNB 4G, considering that it exists N26 interface
What are the differences versus 4G? What differences introduces
the slicing?
FC
What are the entitiy functions involved in the inter 5G – 4G
handover procedure?
What is the role of the N26 interface?

26The solution should support Dual Connectivity and Carrier

Aggregation between 5G NR and LTE. Please describe all the FC
supported band combinations in the offered solution.
263. Please define what security functionality is supported with the

FC
proposed solutions.
The solution should support Cell Reselection to and from

PC
WCDMA/GSM
The solution should support Handover to and from WCDMA/GSM PC
Vendor to describe which L2 and L3 features are supported. FC
489. Vendor to elaborate on the different interworking options

including, but not limited to:
• Major Pros and Cons with the supported options
• Expected UE support short and mid term
FC
• Impact on RAN performance
• Configurations options (e.g. possibility to use different deployment
options for different frequency band in the same base station)
490. Vendor to elaborate about its plans for ng-eNB/eLTE (required

for Option 4 and 7). When will this be supported? Will HW upgrade
FC
be required? What are the major improvements compared to a
“normal” eNB?

From a radio network perspective what will be the driver for

migration of frequency bands from LTE to 5G-NR? What services
FC
are foreseen on the two systems? Will LTE and 5G-NR be
complementary or mainly capacity off-loading?
Will LTE and 5G-NR be two separate systems or one unified

system from radio resource management perspective? E.g. will
FC
there be separate or same radio scheduler to handle the radio
resources?
Describe the possibilities and limitations to configure LTE and 5G-
NR to dynamically share the same part of the frequency band.
FC
Describe how the band is shared between LTE and 5G-NR, i.e.
time and/or frequency sharing
Vendor to elaborate on the need for 5G-NR to have a
Supplementary uplink (SUL) using lower frequency band to improve
FC
coverage and performance. If SUL is proposed, which band
combinations.
Vendor to list timing requirements per radio feature and the
FC
impact /performance hit of not meeting the required demand.
Vendor to describe how Network Synchronization could be

FC
supported, e.g. SyncE, PtPv2, hybrid mode, G.8275.1/G.8275.2.
Shared network with operator specific PLMN according to 3GPP

FC
shall be supported, describe the solution.
514. Describe the solution for Fair sharing of radio resources
FC
between operators
Vendor to describe in general terms the dimensioning aspects for

5G-NR and what major entities are involved for coverage, capacity FC
and QoS calculations.
Vendor to clearly derive the performance difference between MIMO

2x2 and MIMO 4x4 for 4G/LTE and 5G-NR comparing same carrier FC
bandwidth on same 3GPP band.

Vendor to provide high level description of energy conservation and

FC
emission reduction features for 5G and how QoS is maintained.
Vendor to provide information regarding how the equipment’s DC

FC
power consumption can be measured for 5G
Regarding security evolution 2019-2022, please elaborate on 5G-

NR/massive IoT/etc. -related security risks or challenges and FC
specify solutions that can mitigate such risks or challenges
526. Vendor to describe general support for SON/AI in current

FC
release.
535. Vendor shall describe the support of Type-I and Type-II

codebooks for Massive MIMO, and whether multi-panel codebooks PC
are supported.
540. Vendor shall indicate the support of DL QPSK, 16QAM,

PC
64QAM, 256QAM and 1024 QAM in proposed 5G NR solution.

Response
Response Attachment
Name
please refer to feature : MIMO Basic Package
please refer to feature：Intra-band CA
1. High efficiency heat dissaption technology（e.g Bio Leaf heat sink）has been adopted for natural cooling,
no needs for fans.
2. High integration chips has been adopted for reducing power consumption
3. High efficiency PA( e.g GaN PA) has been adopted for improving power efficiency.
1. Symbol-level PA shutdown：For symbol-level PA shutdown”, it turns off PAs during periods of symbols that
do not contain any data to transmit, which can save about 15% power consumption of the RF module when
traffic is low (about 10%)；
2. DRX can reduces power consumption and prolongs the standby time of UEs. A UE does not need to
continuously monitor the physical downlink control channel (PDCCH). Therefore, the UE can turn off its
receiver.
PSU intelligent sleep mode : In NR equipped with Huawei AC/DC PSUs ,redundant PSUs enter sleep mode
during off-peak hours.
It can improve the power efficiency of the active PSUs, and reduce NR power consumption. Besides the
symbol-level PA shutdown mentioned are solutions aimed to minimize the standby power of PAs.
Huawei supports option 2 for SA.
*3.5GHz：
Huawei supports the failsafe mechanism, and the processing mechanism could be divided into three levels:
(1) Less than x% of TRX are faulty, the performance loss and coverage loss still can be tolerated，AAU will
keep working.
(2) More than x% and less than y% of TRX are faulty, a normal hardware alarm will be reported to U2000,
AAU will still keep working.
(3) More than y% of TRX are faulty, a serious hardware faulty alarm will be reported to U2000. End-users will
x is Huawei internal specifications, and cannot be configured.
y is not configurable currently, Huawei is willing to customize this requirement for Operator ( y is configurable),
3 months after this requirement is frozen.
For Huawei 3.5GHz 64TRX AAU,Beam-steering range with typical configuration:

Horizontal:±60º
Vertical:±15º
Huawei Massive MIMO can support DL 16 concurrent beams and UL 4 concurrent beams.
Digital beamforming is applied for 3.5GHz transmission.Reciprocity/eigenvalue based beam forming is applied.
UE transmits SRS in UL, and gNB estimates channel state information according to DL and UL reciprocity.
When UE moves to the cell edge and SRS feedback become unreliable, PMI based beamforming weight
calculation will be used to further improve UE performance.
Multi-User MIMO are supported in Both DL and UL. Single User MIMO and Multi-User MIMO is dynamically
selected in TTI level according to radio conditions and channel orthogonality between different users.
Both DL MU-MIMO and UL MU-MIMO are supported

It’s supported that dynamically switch between various levels of MU-MIMO transmission on a per-TTI basis
depending on radio conditions. For each TTI, different MU-MIMO total layer number can be scheduled,
different UEs grouping can be chosen: those users in low channel correlation between each other can be
scheduled as spatial multiplexing.
Up to 16 layers are supported in downlink
Up to 4 layers are supported in uplink
For a single UE with 2T4R, number of layers in DL can be 4.
For a single UE with 2T4R, number of layers in UL can be 2.
Huawei supports 2-16 concurrent users with 1 spatial layer in downlink
Huawei supports 2-8 concurrent users with 2 spatial layers in downlink

Huawei supports 2-4 concurrent users with 4 spatial layers in downlink.

Up to 8 layers are supported in uplink, so that 2-8 concurrent users with 1 spatial layer can be supported in
uplink.
Based on 16 layers, 8 UEs with each UE transmits 2 layers is supported. Further, various layer combination
between UEs also can be supported.
Based on 8 layers, 4 UEs with each UE transmits 2 layers is supported, Further, various layer combination
between UEs also can be supported.
Huawei provides very flexible MU-MIMO pairing scheduling. Dynamic MU-MIMO transmission on a per-TTI
basis depending on radio conditions is supported. Different UEs grouping can be chosen: those users in low
channel correlation between each other can be scheduled as spatial multiplexing.
Reciprocity/eigenvalue based beam forming is applied.

UE transmits SRS in UL, and gNB estimates channel state information according to DL and UL reciprocity,
beamforming weight is generated according to eigenvalue: SVD is calculated.
High mobility user is not suitable to perform MU-MIMO.
PDSCH per TTI dynamic rank adaptation is supported.

PDSCH per TTI Dynamic SU/MU adaptation is supported.
Huawei supports Transmit diversity as described following: Same signal are transmitted in two polarizations for
PDSCH when PMI or SRS is not available. Typically for scenario of UE initial access to the network or during
handover.
Huawei supports dynamic adaptation of MIMO transmission: When CSI feedback is not available, for example,
UE initially accesses to the network, gNB will schedule as transmit diversity since CSI feedback is not
available, and gNB will adapt to schedule as close-loop SU-MIMO or MU-MIMO once CSI feedback become
available at gNB side. SU-MIMO and MU-MIMO is dynamically selected at TTI level according to radio
conditions and channel orthogonality between different users. When UE moves to the cell edge and SRS
feedback become unreliable, PMI based beamforming weight calculation will be used to further improve UE
performance.
For Huawei 3.5GHz 64TRX AAU, beamwidth for data transmission:

Horizontal:13º
Vertical:6.5º
Half power beamwidth of different beams in honrizontal or vertial direction is different, the beamwidth given
here is for the beam at ~0 degree.
Huawei Massive MIMO can support DL 16 concurrent beams and UL 4 concurrent beams.
For Huawei 3.5GHz 64TRX AAU, ≤8 beams for each antenna polarization are swept for SS Block
transmission. Huawei provides different beam sweeping scheme for different coverage purpose, beam number
can be different for different configuration.
Further, maximum beam number is related to specific frame structure,some DL:UL slots configuration and self-
contained slot configuration maximum beam number may < 8.
Reply
attachment
Refer to word attachment
for
3.5GHz.docx
In downlink, transmission mode hasn’t been defined in 3GPP, Huawei will follow 3GPP and consider
transmission mode adaptation if necessary. Currently Huawei support both open loop and close loop. Open
loop is mainly used at initial access when no CSI feedback and high mobility. Close loop need UE CSI
feedback. UE feedback can base on SRS in uplink by channel reciprocity or PMI feedback. The gNB can
select the SRS-based weight or PMI weight for the UE according to the SRS SINR, the rank is based on the
CSI feedback.
In uplink, currently 3GPP only define one transmission mode: TM1, so transmission mode adaptation is not
available. If 3GPP defines more transmission mode in the future, Huawei will consider supporting more
transmission mode and transmission mode adaptation if necessary according to performance evaluation. In
uplink, TM1 is defined as close-loop MIMO, codebook based precoding is applied. Rank and precoding matrix
is dynamically selected to suit instantaneous radio conditions.
3.5GHz Dynamic TDD is not supported.

Supported version is TBD.
3.5GHz Dynamic TDD is not supported. Related interference control solution is also not supported.
It's not supported.


It's not supported.

It's not supported.

Mini-slot are frames that are able to pre-empt normal transmission. Mini-slots can start at every two symbols.
Currently the E2E uRLLC industry is not mature, no terminal supports the mini-slot yet. Huawei will closely
follow the standard and ecosystem,and support the these new frames in the coming version if operator has the
market requirements.
Recommended configuration for 3.5GHz: 60kHz+ mini-slot, 0.25ms slot with self-contain frame structure.
60kHz +mini-slot will decrease air interface delay and TTI waiting time. TTI waiting time means the time cost to
wait TTI boundary, since data only transmit on TTI boundary regardless when the data arrives.
0.25ms slot with self-contain frame will decrease the waiting time of uplink /downlink transmission chance.
It is proposed to use separate numerologies for ultra-low latency service and normal eMBB traffic.
It is not supported. Huawei only support eMBB traffic and URLLC multiplexing with same numerology.
Huawei currently not support URLLC, supported version is TBD.

URLLC 0.5ms latency needs key technologies like embedded Air interface, Uplink Grant-free ,configurable
numerology, mini-slot.
Currently it is not supported. Supported version is TBD.
Reply
attachment
for
3.5GHz.docx
Reply
attachment
for
3.5GHz.docx
Reply
attachment
for
3.5GHz.docx
Huawei supports MCG Bearer and SCG Split Bearer for option 3X.
Huawei supports MCG Bearer/MCG Split Bearer for option 3.
PDCP: Support configuration of bearer-switch or bearer-split depending upon UE capability
LTE PDCP Split SRB and duplicate SRB are supported.
LTE PDCP supports split DRB but not supports duplicated DRB in EN-DC.
Neither split-SRB nor duplicate SRB is supported. Supported version is TBD.

Split-DRB is supported. Duplicate DRB is not supported.
EN-DC: MN(Master Node) initiated SN(Secondary Node) addition is supported
MN initiated is supported for SN encryption parameter modification, triggering condition is not operator
configurable.
SN initiated SN modification is supported. SN initiates modification according to measurement results, and
adjustment will be inform to MN.
MN initiated is supported, triggered condition includes: traffic split exception or SgNB RLF, triggering condition
is not operator configurable.
SN initiated is supported.
MN initiated is not supported currently.

SN initiated SN change is supported. SN initiates change according to measurement results, and adjustment
will be inform to MN.
It's supported.
EN-DC: MN handover/change: with or w/o SN change and including data forwarding including operator
configurable criteria (e.g. DL and UL link quality, load based, time-to-trigger, and hysteresis etc.)
NSA DC traffic split mode is configurable in downlink, can be SCG only, MCG only, and SCG & MCG dynamic
split.
NSA DC traffic split mode is configurable in uplink, can be SCG only, MCG only, and SCG & MCG dynamic
split.
For a specific user, Plte-MAX will be configured as max allowed TX power in LTE uplink, and Pnr-MAX will be
configured as max allowed TX power in NR uplink. Plte-MAX + Pnr-MAX can be ≤Pmax, or Plte-MAX + Pnr-
MAX can be >Pmax. While Plte-MAX + Pnr-MAX ≤Pmax, UE in LTE or NR can transmit in the same time with
the restiction of its MAX power.
While Plte-MAX + Pnr-MAX>Pmax, LTE TX power will be higher priority, and NR TX power = Pmax - Plte-
Max.
Currently it's not supported. Supported version is TBD.
EN-DC:Support fast centralized retransmissions of lost PDCP PDUs when performing inter-gNB-DU mobility
It is supported.
Scheduler will dynamically perform traffic steering to 4G and 5G according to radio signal quality and loading
condition in 4G and 5G, so that load balance can be done.
Performance fain of load balance: Before load balance, data throughput at 4G = A, by apply DC and traffic load
balance, throughput at 5G = B and throughput at 4G = A, max performance gain = B/A.
For LTE-NR NSA DC capable UE, if UE traffic volume threshold is satisfied, NR dual connectivity will be
enabled to improve UE throughput. Traffic volume threshold is configurable parameter. While multiple NR cells
can be configured for LTE and NR dual connectivity, NR cell with highest signal strength will be selected as
PSCell (Primary Secondary Cell), then NR will configure SCELL(Secondary Cell) in NR domain.
Reply
attachment
for
3.5GHz.docx

The maximum delay requirements for the X2 interface is 20ms. The maximum delay doesn’t depend upon the
option used. The transmission delay of X2 interface will be considered when data splitting, so the impact of X2
interface delay on E2E application delay is small.
Huawei think that following information should be shared:

• Congestion status of interface between gNB and eNB;
• Transmission delay of interface between gNB and eNB;
• Throughput and remaining data transmission delay of RLC layer;
• The highest PDCP PDU sequence number successfully delivered in sequence to the UE among those PDCP
PDUs received from the MeNB;
• The highest PDCP PDU sequence number successfully delivered in sequence to the UE among those PDCP
PDUs received from the MeNB;
• The minimum desired buffer size in bytes for the UE;
• The X2-U packets that were declared as being "lost" by the corresponding eNB and have not yet been
reported to the eNB hosting the PDCP entity within the DL DATA DELIVERY STATUS frame.
Huawei will follow 3GPP specification after specification frozen.
Only non-GBR services is allowed traffic steering to NR. For traffic flow load balance: In stage 1, scheduler will
dynamically perform traffic steering to 4G and 5G according to radio signal quality and loading condition in 4G
and 5G, so that load balance can be done.
For NSA architecture, QCI=1 and QCI=2 bearers are only created in 4G network. Currently 5G Voice over NR
and video over NR are still under discussion in 3GPP.
2
2
The EN-DC combination "LTE 1CC + NR 1CC" will be supported. The specific band combination will follow
3GPP definition.
3GPP definition.
3GPP definition.
3GPP definition.
Huawei supports inter-cell intra-site CoMP coordinated-scheduling for test purpose and commercial in future
version.
inter-cell intra-site CoMP includes SMP (Separate Multi-Point), DMP (Duplicated Multi-Point)，and UL COMP.
SMP allows neighboring TP to provide additional MIMO layers. Different TP transmit different streams so that
to provide additional spatial multiplexing.
DMP allows neighboring TP to provide duplicated signals to improve the SINR.
UL inter-cell intra-site CoMP improves UL coverage by multi-TP joint reception.
For SMP/DMP, scheduling procedures are:
1) Select UE and TP: Based on UE MR, scheduler selects UE and the best neighbor cell that meets the
conditions.
2) Coordinate: A) Coordinated weight calculation base on SRS received both in serving TP and neighboring
TP. B) Coordinated scheduling to allocate RB resource for CoMP users.
3) SMP&DMP is adaptive to use based on channel condition (e.g. spectrum efficiency).
For inter-cell intra-site CoMP, the main scheduling procedure is:
1) Selects CoMP user
2) Send schedule information of CoMP user to cooperating TP
3) Joint precessing within CoMP cooperating sets for CoMP UEs
Inter-cell inter -site CoMP coordinated-scheduling still under study and currently no plan.

Huawei supports NC-JT for test purpose and commercial in future version.
NC-JT is supported, which includes SMP (Separate Multi-Point), and DMP (Duplicated Multi-Point).
conditions.
Scenario limitation: Currently only intra-DU SMP/DMP is supported.
Huawei supports UL CoMP .

UL CoMP improves UL coverage by multi-TP joint reception.
For UL CoMP, the main scheduling procedure is:
Scenario limitation: Currently only intra-DU UL CoMP is supported.
Huawei currently doesn’t support dynamic point switching, it’s due to that Huawei thinks it’s mainly use for
dynamic load balance between TRPs. At 5G initial stage, NR cell load will be low dynamic point switching is
unlikely to provide obvious gain.
Huawei currently doesn’t support LTE and NR inter-RAT coordinated scheduling at DU level,, Huawei will
consider to support in future version.
LTE and NR inter-RAT coordinated scheduling at DU level typically use for LTE and NR spectrum sharing
case: LTE and NR operates at the same carrier or spectrum is overlapped. LTE and NR dynamically negotiate
spectrum resources allocation to make full use of spectrum or interference control related also can be
negotiated to reduce LTE-NR interference.
It is supported.
DMP (Duplicated Multi-Point) is single DCI based Multi-TRP NC-JT for PDSCH.
It is supported.
SMP (Separate Multi-Point) is multi-DCI based multi-TRP NC-JT for PDSCH.
Long PUCCH is supported
From Huawei 5G RAN2.1（2019Q2）,following SON provedures are supported:

1. ANR : automatically plan, configure, and correct neighbor relationships. 【FOFD-021204 Automatic
Neighbour Relation (ANR)】
2. LTE and NR X2 Interface Self-Configuration:When an LTE eNodeB and an NR gNodeB are interconnected
and share an element management system (EMS), the transmission link over the X2 interface supports self-
setup and self-deletion.【MRFD-131161 LTE and NR X2 Interface Self-Configuration (NR)】
NR protocol about UE MDT has not frozen, Huawei will follow latest 3GPP Release 16 Standard and consider
to support once UE MDT is standardized.
Huawei 5G gNB will support energy efficiency solutions as following:
Symbol-level PA shutdown: For symbol-level PA shutdown, it turns off PAs during periods of symbols that do
not contain any data to transmit, which can save about 15% power consumption of the RF module when traffic
is low (about 10%)；

Several interference-management technologies are used.

A)Forward Error Correction technology: LDPC channel coding is used for data transmission and HARQ is used
for error packet retransmission, as defined in 3GPP 5G NR.
B) RB randomized scheduling: Since NR 3.5GHz has large bandwidth (100MHz), RB randomized scheduling
helps to reduce interference especially at eMBB and low load case.
C) DL MU-MIMO uses enhanced Zero Forcing to further reduce layer interference between users.
Huawei also consider following features in future version:

D) SMP (Separated Multiple Point) & DMP (Duplicated Multiple Point) are supported to improve transmission
robustness by multi-point transmission, meanwhile increase spectrum efficiency. SMP improves cell edge UE
throughput by multi-layer. DMP improves cell edge UE throughput by macro-diversity gain. FDL signal is
transmitted in multi-point for SMP/DPM, thus avoid other UE pararlell transmit in coordinated point, then
interference can be reduced, and useful signal is enhanced.
E) UL COMP is used to improve UL signal quality. UL Interference can be mitigated by IRC receiver.
F) Advanced receiver (Turbo receiver) is supported at base station to improve channel estimation accuracy at
poor SINR area.
1) DL/UL decoupling: utilizes Sub3G FDD uplink “sleeping” spectrum to enhance uplink coverage of C-Band.
2) UL COMP : uses the antennas of multiple cells to receive signals from a UE to achieve signal combining
gain and interference mitigation gain. It can improve the cell edge user uplink experience.
3) Turbo receiver: More advanced receiver technology to get more accurate channel estimation to improve UL
coverage.
4) Flexible waveform: gNB can decide and communicate to the UE which one of CP-OFDM and DFT-S-OFDM
based waveforms for UL to use .DFT-S-OFDM is suitable for a single stream transmissions and low
modulation order. CP-OFDM can be used for a single-stream and multi-stream transmissions. UL DFT-S-
OFDM based waveform is complementary to CP-OFDM waveform to improve UL coverage.
5) UL precoding: make the uplink beam precise directed to the receive antenna to improve the uplink
coverage.
6) Pi/2 BPSK: support lower modulation for uplink transmission.
7) UL FSS(Frequency Selective Scheduling): Frequency selective fading caused by delay spread. UL FSS
Facilitating superior user experience.
8) PMI feedback and SRS feedback adaptation: gNB can decide which one of PMI feedback or SRS feedback
to use according to the channel condition to improve UL feedback performance.PMI feedback is for poor
coverage.
9) UL Adaptive Uplink IBLER: cell edge user set to higher IBLER to improve throughput
Huawei powerful ASIC & Advanced Algorithm enables high-performed DL 16 Layer MU beamforming at
3.5GHz. Huawei provides following Massive MIMO algorithm to improve performance:
A) Huawei supports scenario based broadcast beam configuration, thus enable different coverage pattern to
make coverage more efficient.
B) PMI/SRS feedback adaptation: in good coverage area, UE transmits SRS in UL, and gNB estimates
channel state information according to DL and UL reciprocity so that to perform beamforming. When UE
moves to the cell edge and SRS feedback become unreliable, PMI based beamforming weight calculation will
be used to further improve UE downlink performance.
C) Zero Forcing and Iterative Zero Forcing precoding technology to further reduce multi-user interference to
improve cell capacity.
D) PDCCH multi-user beamforming to further improve PDCCH capacity, which is important for massive MIMO
since when scheduling user number is high, PDCCH capacity will be a challenge.
E) Multiple layer power allocation: The MIMO channel characteristic is affected by antenna correlation,
multipath transmission, etc. Channel gain for different layer can thus be much different. Multiple layer power
allocation is used to improve effective SINR of layers so that increase cell capacity.
F) Narrow and wide hybrid beam sweeping to improve high-speed beamtracking: the solution can reduce
sweeping beams to get shorter swiping time, with using wide beam in the near cell and using narrow beam in
the edge cell that can guarantee better coverage.
In SRAN15.1（GA: Q2-2019), each 5G cell is planned to support a max of 384 intra-RAT neighbour cell
relationship and 384 inter-RAT neighbour cell relationship.
In SRAN15.1（GA:Q2-2019) , the following SON features are being planned:

1. ANR : automatically plan, configure, and correct neighbor relationships.
2. LTE and NR X2 Interface Self-Configuration:When an LTE eNodeB and an NR gNodeB are interconnected
and share an element management system (EMS), the transmission link over the X2 interface supports self-
setup and self-deletion.

Huawei is watching closely the latest development in 3GPP standard, and will consider to support the relevant
functions in the coming software releases.
Huawei is watching closely the latest development in 3GPP standard, and will consider to support the relevant
functions in the coming software releases.
Huawei 5G gNB will support energy efficiency solutions as following:【FOFD-021203 gNodeB Power Saving】
not contain any data to transmit, which can save about 15% power consumption of the RF module when traffic
is low (about 10%)；
DRX【FBFD-021103 DRX】 can reduces power consumption and prolongs the standby time of UEs. A UE
does not need to continuously monitor the physical downlink control channel (PDCCH). Therefore, the UE can
turn off its receiver.
Huawei 5G SW release plan currently include 2 versions:

• 5G RAN 2.0 (General Availability date planned at the end of 2018 Q4), which will support 5G Non-Stand-
Alone mode.
• 5G RAN 2.1 (General Availability date planned at the end of 2019 Q2), which will add support for 5G Stand-
Alone mode.
The 5G software releases are part of the SingleRAN software, corresponding to SingleRAN15.0 and
SingleRAN15.1 releases respectively.
1) Huawei supports NR UL&DL Decoupling and LTE&NR UL sharing so that to extend coverage, since
normally NR UL is bottleneck of cell coverage.
2) UL 256QAM is supported which enable higher throughput experince at cell center. User maximu peak
throughput improves 33% compared with UL 64QAM.
3) DL MU-MIMO uses enhanced Zero Forcing to further reduce layer interference between users.
4) UL COMP uses the antennas of multiple cells to receive signals from a UE to achieve signal combining gain
and interference mitigation gain. It can improve cell edge user uplink experience.
5) Downlink COMP is supported, which includes SMP (Separate Multi-Point), and DMP (Duplicated Multi-
Point). SMP allows neighboring TP to provide additional MIMO layers. Different TP transmit different streams
so that to provide additional spatial multiplexing. DMP allows neighboring TP to provide duplicated signals to
improve the SINR. Scenario limitation: Currently only intra-DU SMP/DMP is supported. For SMP/DMP,
scheduling procedures are: A) Select UE and TP: Based on UE MR, scheduler selects UE and the best
neighbor cell that meets the conditions. B) Coordinate: A) Coordinated weight calculation base on SRS
received both in serving TP and neighboring TP. B) Coordinated scheduling to allocate RB resource for CoMP
users. C) SMP&DMP is adaptive to use based on channel condition (e.g. spectrum efficiency).
6) Flexible waveform: gNB can decide and communicate to the UE which one of CP-OFDM and DFT-S-OFDM
based waveforms for UL to use .DFT-S-OFDM is suitable for a single stream transmissions and low
modulation order. CP-OFDM can be used for a single-stream and multi-stream transmissions. UL DFT-S-
OFDM based waveform is complementary to CP-OFDM waveform to improve UL coverage.
7) UL FSS (Frequency Selective Scheduling): Frequency selective fading caused by delay spread. UL FSS
Facilitating superior user experience.
8) Narrow and wide hybrid beam sweeping (relay on mmWave hardware) to improve mmWave high-speed
beamtracking: the solution can reduce sweeping beams to get shorter swiping time, with using wide beam in
the near cell and using narrow beam in the edge cell that can guarantee better coverage.
For initial cell search, a UE may assume that half radio frames (5ms) with SS blocks occur with a periodicity of
2 radio frames (20ms)
PBCH not allowed to be changed within every 80ms Beam
within 80ms, SS Burst Set repeat 4 times Sweeping
SS Block Number L: Max 8 per half radio frame for 3GHz~6GHz; Procedure in
Max 64 per half radio frame for above 6GHz. Initial Access
Please refer to SOC attachment "Beam Sweeping Procedure in Initial Access".

Digital beamforming is applied for 3.5GHz data channel.Reciprocity/eigenvalue based beam forming is
applied. UE transmits SRS in UL, and gNB estimates channel state information according to DL and UL
reciprocity. When UE moves to the cell edge and SRS feedback become unreliable, PMI based beamforming
weight calculation will be used to further improve UE performance.
Hybrid analogue / digital beam forming are applied for mmWave data channel. For analog beamforming, UE
needs to feedback best beam information to gNB, gNB generate analog beam accordingly. For downlink digital
beamforming, UE needs to feedback CSI information to gNB, gNB processes digital beamforming according to
UE feedback information.
Uplink and downlink control channels adopt the static beam. The static beam with best RSRP is selected. The
RSRP is obtained by SRS and CSI-RS measurement.
The SSB is measured 20ms by default. The parameters can be configured.

CSI-RS is based on scheduling, aperiodic, and the minimum interval is 40ms by default. Parameters can be
configured.
SSB beam does not have to be reported for 3.5G.
SSB beam index and RSRP will be reported to gNB via PUSCH for mmWave.
CRI and RSRP of CSI-RS will be reported to gNB via PUSCH.
User level beam tracking including SRS based beam tracking and CSI-RS based beam traking
SRS Based Beam Tracking (TDD 3.5G)
Obtaining the optimal narrow beam by SRS measurement at gNB; Suitable for reciprocal scenes, middle or
near point, where SRS SINR is good enough.
CSI-RS Based Beam Tracking (TDD 3.5G/28G/FDD MM)
Obtaining the optimal narrow beam from UE report by CSI-RS measurement at UE; Suitable for far point,
where SRS SINR is poor.
CoMP between micro cells is under planning after 2019, it will start from Co-DU deployment scenario first, and
will elobarated to support more scenarios in the future.
Huawei will support DL CoMP and UL CoMP based on NR C-band Massive MIMO between macro cells under
same DU in 2019:
1) DL CoMP (SMP): In LOS scenario, the edge THP is limited by MIMO layers in serving TP. DL CoMP allow
neighboring TRP to transmit different signals to provides additional MIMO layers.
2）DL CoMP (DMP): In NLOS scenario, the edge THP is limited by low SINR in serving TP. DL CoMP allow
neighboring TRP to provides duplicated signals to improve the SINR.
3) UL CoMP:allow neighboring TRP transmit already demodulation signal to seving TRP for soft bits
combination to iprove demodulation performance.
The beamforming weight of DL CoMP is calculated base on SRS received or PMI both in serving TRP and
neighboring TRP.
Huawei will support UL CoMP in RAN2.1, under same DU and same BBU.
Huawei will support DL CoMP in future version for market requirements, under same DU and same BBU.
In 2019 software release, CoMP features are designed for Co-DU deployment scenario, and will support more
scenarios such as inter-DU in the future. We are open to further discuss with customer on desired scenario
and detailed requirement.
In NSA architecture, Huawei recommends VoLTE or CSFB from LTE to 2G/3G without VoLTE.
In SA architecture, Huawei recommends EPS FB (FB to VoLTE) in early stage of 5G deployment, and will
support VoNR in future version with clear market requirements..
SMS services are related to 5G Core functionality and do not depend on 5G RAN support. Huawei 5G Core
will follow 3GPP definition on SMS services for NR user and plan the roadmap according to customer
requirements.
In NSA architecture, option 3/3x, Emergency Call should supported from LTE network.
In SA architecture, option 2, Huawei is planning to support Emergency Call in future version with clear market
requirements.
In SA mode, Huawei recommends VoNR with 1.5~2s access time (PS Handover to 4G VoLTE at cell edge,
VoLTE is preferred when VoNR is not supported) and EPS FB to 4G VoLTE with 3~4s access time.
For SA mode, SRVCC from 5G NR directly to 2/3G is not supported in 3GPP R15.
In NSA mode, VoLTE performs SRVCC to 2/3G if there is no LTE coverage, with ~6s access time.

Huawei solution can support mini-slot, grant-free, self-contain, fast return, fast scheduling techniques for
uRLLC to improve block error rate, low latency and fast TTI.
As described in 3GPP Release 16, this standard will be stable at 20th of December 2020. And as the leading
telecommunication company, Huawei products will comply with 3GPP Release 16 within 6 months as soon as
standard is frozen.
Under NSA, LTE supports ETWS (TS 23.041 chapter 9.4) – ETWS is implemented on the UEs, eNodeBs,
mobility management entity (MME), and cell broadcast center (CBC) in compliance with 3GPP specifications.
Under SA, the standards are not yet clear, and they need to be provided by the NGC collaborative planning.
There are no planning road signs at present.
Under the NSA, LTE LCS supports three positioning methods: E-CID, OTDOA, and A-GPS. The E-SMLC
chooses one or more positioning methods based on the UE positioning capability and quality of service (QoS)
requirements for LCS.
Under the SA, NGC collaborative planning is required. Currently, this solution is not defined in Huawei
roadmap.
A Mission Critical Service (MCX) is a communication service reflecting enabling capabilities

Mission Critical Applications and provided to end users from Mission Critical Organizations and
mission critical applications for other businesses and organizations (e.g. utilities, railways).
MCX Services are based on the ability to invoke, modify, maintain and release sessions with
priority, and deliver the priority media packets under network congestion conditions. MCX Users
require 5GS functionality that allows for real-time, dynamic, secure and limited interaction with
the QoS and policy framework for modification of the QoS and policy framework by authorized
users. The limited interaction is based on operator policy, and provides specific limitations on
what aspects of the QoS and policy framework an authorized MCX User can modify. MCX service is
supported in a roaming environment when roaming agreements are in place and where regulatory
requirements apply.
Mission Critical Services leverage the foundation of the 5G QoS Model, and 5G Policy Control. It
requires that the necessary subscriptions are in place for both the 5G QoS Profile and the
necessary Policies. In addition, Mission Critical Services leverage priority mechanism.
When a MCX session is requested by an MCX User, the following principles apply in the network:
- QoS Flows employed in a Mission Critical Service session shall be assigned ARP value settings
appropriate for the priority level of the MCX User.
- Setting ARP pre-emption capability and vulnerability of QoS Flows related to MCX session,
subject to operator policies and depending on national/regional regulatory requirements.
- Pre-emption of non-MCX Users over MCX Users during network congestion situation, subject to
operator policy and national/regional regulations.
Priority treatment is applicable to IMS based multimedia services and priority PDU connectivity
service.
Huawei 5GC plans to supports MCX in 2021.
The eMBB DL/UL latency can reach 4ms. The conditions are: ping small packet, DL
SINR>16dB, UL SINR>15dB, DL:UL=3:1, 30KHz, excluding core network and
transmission latency.
For NSA (3.x), the requirement of Control Plane Latency is less than 60ms. For SA(2),
Idle to Active Latency can reach 30ms. The procedure of Idle to Active transition is as
following.
The condition is as following:

CSI-RS RSRP≥ -110dBm, SINR ≥ 0dB;
Sample number >200;
Core, transport, UE caused KPI degradation should be excluded.
Related KPIs under SA has not been frozen in 3GPP, Huawei predict NR KPI according
to LTE experience. Huawei will update to be accordance to follow 3GPP, related
change may happen.

In 3.5GHz and 1.8GHz dual connectivity, intermodulation will happen. One solution is to
send dummy slots or subframe on 1.8GHz, which cause around 40% LTE loss.
Huawei suggest introducing UL&DL decoupling solution to avoid/mitigate the risk of
intermodulation.
Huawei would support IP Header Compression function with VoNR feature since
2019Q2
In NR, specific TM mode is not defined in DL, and only one TM mode is defined in UL.
Both DL MU-MIMO and UL MU-MIMO are supported for both 3.5GHz & 28GHz. Single
User MIMO and Multi-User MIMO is dynamically selected in TTI level according to radio
conditions and channel orthogonality between different users.
Assume DL:UL ratio = 3:1, in eMBB full buffer simulation in dense urban/urban area,
where ISD < 500 meters, assume 4G UE in 3.5GHz band with 100MHz bandwidth, 2R
UE in 1800MHz band with 20MHz
a. 8T8R is about 2.2~2.6 times capacity gain compared with LTE 2T2R.
b. 64T64R is about 9~13 times capacity gain compared with LTE 2T2R.
Performance gain comes from three parts: A) 64T VS. 2T. B) NR protocol gain vs. LTE:
such as CRS-free, filtered-OFDM, etc. C) UE 4R VS. 2R.
RB randomized scheduling: Since NR 3.5GHz has large bandwidth (100MHz), RB

randomized scheduling helps to reduce interference especially at eMBB and low load
case.
SMP (Separated Multiple Point) & DMP (Duplicated Multiple Point) are supported to Serving TP
improve transmission robustness by multi-point transmission, meanwhile increase
spectrum efficiency. SMP improves cell edge UE throughput by multi-layer. DMP
improves cell edge UE throughput by macro-diversity gain. DL signal is transmitted in
multi-point for SMP/DPM, thus avoid other UE pararlell transmit in coordinated point,
then interference can be reduced, and useful signal is enhanced.
SMP: Different TP transmits different codeword to enable higher spatial multiplexing
DMP: Different TP transmits same signal to provide macro diversity. UL COMP is used
to improve UL signal quality.
Serving TP

With UL IRC receiver, UL interference can be rejected so that data SINR can be
improved.
Advanced receiver (Turbo receiver) is supported at base station to improve UL channel
estimation accuracy at poor SINR area.
For NR 3.5GHz DL MU-MIMO, enhanced Zero Forcing is applied to further reduce layer
interference between users.
In NSA, terminal RRC connectivity is maintained in LTE. Signalling transport-using LTE
In NSA, User Data transport using both 5G NR and LTE.
UL&DL decoupling: utilizes Sub3G FDD uplink “sleeping” spectrum to enhance uplink
coverage of C-Band.
UL COMP: uses the antennas of multiple cells to receive signals from a UE to achive
signal combining gain and interference mitigation gain. It can improve the cell edge
user uplink experince.
Turbo receiver: More advanced reciver technology to get more accurate channel
estimation to improve UL coverage.
Flexible waveform: gNB can decide and communicate to the UE which one of CP-
OFDM and DFT-S-OFDM based waveforms for UL to use .DFT-S-OFDM is suitable for
a single stream transmissions and low modulation order. CP-OFDM can be used for a
single-stream and multi-stream transmissions. UL DFT-S-OFDM based waveform is
complementary to CP-OFDM waveform to improve UL coverage.
UL precoding: make the uplink beam precise directed to the receive antenna to improve
the uplink coverage.
Pi/2 BPSK: support lower modulation for uplink transmission.
UL FSS( Frequency Selective Scheduling): Frequency selective fading caused by delay
spread. UL FSS Facilitating superior user experience.
PMI feedback and SRS feedback adaptation: gNB can decide which one of PMI
feedback or SRS feedback to use according to the channal condition to improve UL
feedback performance.PMI feedback is for poor coverage.
40MHz, 60MHz,80MHz, 100MHz are supported for 3.5GHz for single carrier. The
recommended bandwidth is 100MHz.
100MHz and 200MHz are supported for 28GHz for singal carrier. The recommended
bandwidth is 200MHz.
It is recommended to use fixed UL and DL configuration 3:1 (i.e. avoiding flexible
symbols) in a initial phase.
NSA(3&3X) will be availability at 2018Q4 in 5G RAN2.0 which based on 3GPP R15

In the same carrier bandwidth on same 3GPP band and same MIMO, the performance
of 5G-NR is better than 4G/LTE.
For MIMO 2X2, NR is about ~1.3 times gains as LTE.
NR MIMO 2X2 comparing with LTE MIMO 2X2, the calculations are based on below
test data.
NR MIMO 4X4 comparing with LTE MIMO 4X4, the calculations are based on below
test data.
Transport Overhead for 5G

IPv4 user plane protocol: The MAC/IP/UDP/GTPU/Payload.
1. MAC does not have VLAN tags 54 bytes.
2. The MAC contains the VLAN tag 58-byte
IPSec encryption: The packet length varies according to the encryption algorithm of the
MAC/IP/IPsec/IP/UDP/GTPU/Payload IPSEC header. The transmission header is
different when using the different Encryption Method, usually is chosen 85 bytes, which
does not include the VLAN ID 159 bytes, (including VLAN) 163 bytes.

Huawei NSA Networking based on EPC (5G NR) feature enables an LTE and NR NSA
DC-capable UE to simultaneously connect to an LTE eNodeB and an NR gNodeB and
use radio resources provided by these base stations for data transmission. NR, NSA,
and DC stand for New Radio, non-standalone, and dual connectivity, respectively.
This feature can be deployed where LTE and NR network coverage areas overlap
LTE eNodeB is the master base station, and the NR gNodeB is the secondary base
station. The control-plane data is carried on the eNodeB. The user-plane data supports
two architectures: Option 3 and Option 3X.
- In Option 3
The eNodeB is the data split anchor.
The user-plane data can be carried on just the eNodeB, or the eNodeB can allocate
some of the user-plane data to the gNodeB.
If all the user-plane data is carried on only the eNodeB, there will be master cell group
(MCG) bearer. If user-plane data is carried on both the eNodeB and the gNodeB, then
there will be MCG split bearer.
- In Option 3X
The gNodeB is the data split anchor.
The user-plane data can be carried on just the gNodeB, or the gNodeB can allocate
some of the user-plane data to the eNodeB.
If user-plane data is carried on both the eNodeB and the gNodeB, then there will be
secondary cell group (SCG) split bearer.
Huawei LTE/NR band combinations fully compliant to standard 3GPP TS38.101.
gNodeBs select suitable carriers for CA UEs based on the CA capabilities reported by
UEs, cell-level algorithm switch settings, and carrier management principles. This
feature allows aggregation of up to two uplink or downlink sub-6 GHz carriers to
achieve a maximum bandwidth of 200 MHz. It allows aggregation of up to ten uplink or
downlink 100 MHz mmWave carriers, or of five uplink or downlink 200 MHz mmWave
carriers to achieve a maximum bandwidth of 1 GHz.
CA enables aggregation of multiple contiguous or non-contiguous carriers to provide a
wider bandwidth as required by 3GPP Release 15 and to better utilize spectrum
chunks.
During CA, upper-layer data streams are mapped to individual component carriers
(CCs) at the MAC layer. Each CC uses its own hybrid automatic repeat request (HARQ)
entities and link adaptation mechanism.
During initial access, an incoming handover, or an RRC connection reestablishment of
a CA UE, a gNodeB configures SCells for the UE in a blind manner or based on a
specified frequency set. In frequency set-based CA configuration, the UE measures the
configured frequencies and reports the signal strength of cells on the frequencies. The
gNodeB configures the cells that meet specific conditions as SCells. The delivery of
SCell information during CA UE handovers is supported.
In 5G RAN2.0 combination on C-band:
100+100MHz.

Huawei Support for harmonic interference avoidance.

Typical scenario: 1.8 GHz LTE and 3.5 GHz NR networks
On the UE side, LTE uplink transmission generates secondary harmonic signals, which
affect NR downlink reception. As a result, NR common channel messages cannot be
demodulated.
To resolve this issue, LTE uplink scheduling and NR common channels (PBCH and
common PDCCH) are staggered on the UE side in the time domain and frequency
domain.
This function enables proper demodulation of NR common channel messages while not
affecting mobility.
3GPP Release 15 introduces the supplementary uplink (SUL). SUL effectively utilizes
idle sub-3 GHz band resources, improves the uplink coverage of C-band, and enables
the provisioning of 5G services in a wider area. SUL also improves the service
experience of cell edge users (CEUs). For details on the SUL, see section 6.9 in 3GPP
TS 38.300 (V15.0.0). In this feature, SUL carriers are on the sub-3 GHz band, and non-
SUL carriers are on C-band.
Huawei UL and DL Decoupling feature supports the decoupling between the SUL
frequency band in the uplink and non-SUL frequency band in the downlink, as shown in
picture below. It is applicable to scenarios where uplink and downlink frequency bands
are deployed at the same site and cover an identical geographical area.
- For UEs located in cell center areas, C-band can satisfy uplink coverage
requirements, and both uplink and downlink data transmission are carried on C-band.
- For UEs located in cell edge areas, the uplink coverage of C-band is limited. UL and
DL Decoupling is implemented in this case so that PUSCHs, PUCCHs, and PRACHs
are configured on the low frequency band, and downlink coverage is still carried on C-
band.
Alternative solution
During the early stages of 5G deployment, a number of operators still do not possess
New Radio (NR) spectrum resources. It is then required to use existing LTE spectrum
resources for the deployment of 5G networks. This feature allows NR to share spectrum
resources with LTE. In this version, this feature allows for the sharing of UL low-band
spectrum resources between LTE and NR. The low-band spectrum sharing serves as a
basis for NR UL and DL decoupling and improves NR UL coverage. This feature is only
applicable to 15 MHz and 20 MHz cells operating on the 1800 MHz frequency band.
Huawei LTE and NR Spectrum Sharing features provide UL low-band spectrum
resources for NR UL and DL decoupling by fully utilizing the idle UL spectrum resources
of LTE. It helps unleash the DL advantages of C-band, expanding its coverage and
capacity. With this feature, operators can quickly and cost effectively deploy 5G
networks.
LTE and NR share UL spectrum resources through frequency division. Specifically, LTE
and NR are allocated with different RBs in the frequency domain.

C-band is capable of satisfying the requirement of large bandwidth and is referred to as

a gold band for 5G Enhanced Mobile Broadband (eMBB) services. A vast majority of
global operators have selected C-band as the preferential 5G frequency band. DL
coverage is favoured over UL coverage on C-band for the characteristics of large DL
transmit power and disproportion in UL and DL subframe assignment of NR. The
application of technologies such as beamforming and cell-specific reference signal
(CRS)-Free further increases the difference between C-band UL and DL coverage.
With the technology of NR UL and DL decoupling, the coverage of C-band will be
significantly improved by SUL low-frequency spectrum because the uplink coverage of
C-band NR is the bottleneck.
Once a UE moves in the area where the uplink coverage of C-band NR is poor, uplink
can works in the SUL spectrum and downlink still works in the C-band NR.
The main difference is LTE and NR spectrum sharing solution have very limited
spectrum and cannot provide enough resources for users. In addition, solution has a lot
of mutually exclusive features which cannot be switched on.
Fully unleashes the DL advantages of C-band, and expands the coverage and
capacity, while enabling the continuous cost-effective deployment of 5G networks on C-
band.
For UEs located in cell edge areas, the uplink coverage of C-band is limited. UL and DL
Decoupling is implemented in this case so that PUSCHs, PUCCHs, and PRACHs are
configured on the low frequency band, and downlink coverage is still carried on C-band.
During the early stages of New Radio (NR) deployment, only high-band spectrum was
available for NR. LTE low-band spectrum could not be refarmed for NR deployment. NR
networks deployed on the high-band spectrum have limited uplink coverage. LTE FDD
and NR Uplink Spectrum Sharing allows LTE and NR to share LTE uplink low-band
spectrum when the uplink load of LTE networks is low. When this function is enabled,
UL and DL Decoupling can be used to establish supplementary uplink (SUL) cells on
the LTE low-band spectrum for NR networks. Low-band spectrum sharing improves NR
uplink coverage. For details about SUL cells, see section 6.9 "Supplementary Uplink" in
3GPP TS 38.300 (V15.0.0).
LTE and NR use frequency division to statically share uplink spectrum resources. LTE
and NR are allocated different RBs in the frequency domain. LTE and NR determine
their respective available RBs based on parameter configurations and schedule only
their own RBs. Picture below shows an example of LTE FDD and NR spectrum sharing.
This function can only be used in 15 MHz and 20 MHz LTE FDD cells operating on the
1800 MHz frequency band.
This function improves the uplink throughput of NR cells via the establishment of SUL
cells, and helps achieve fast NR deployment.
CloudAir2.0 enables the dynamic sharing of the spectrum and TX power between
technologies, allowing operators to make the most out of this assets and freeing them
from the ties and burden of technology re-farming. CloudAIR 2.0 solution supports
dynamic, tight spectrum sharing not only between GSM, UMTS and LTE, but also with
5G (NR/LTE spectrum sharing, necessary for the 5G NR Downlink/Uplink Decoupling
feature).
Huawei feature LTE FDD and NR Uplink Spectrum Sharing (NR) supports static
proportional allocation of PUCCH, PRACH, and PUSCH resources between LTE and
NR, and dynamic allocation of SRS resources.

Huawei LTE/NR band combinations fully compliant to standard 3GPP TS38.101.

Huawei products and features will support all listed band combinations. For now
Huawei supports 1800MHz band.
In version SRAN15.0 which will be released in 2018 Q4, trial LTE FDD and NR
Spectrum sharing feature will be available. Version SRAN15.1 will be released in 2019
Q2, it could supports LTE NR uplink dynamic spectrum sharing. The supported
frequency bands are 1800M/2100M/700M/800M. 900M and 2600M is under
consideration, and it may be developed according to the market request.
During the early stages of 5G deployment, a number of operators still do not possess
New Radio (NR) spectrum resources. It is then required to use existing LTE spectrum
resources for the deployment of 5G networks. This feature allows NR to share spectrum
resources with LTE. In this version, this feature allows for the sharing of UL low-band
spectrum resources between LTE and NR. The low-band spectrum sharing serves as a
basis for NR UL and DL decoupling and improves NR UL coverage. For SRAN15.0 LTE
FDD and NR Uplink Spectrum Sharing feature is only applicable to 15 MHz and 20 MHz
cells operating on the 1800 MHz frequency band.
Huawei will support Inter-RAT Mobility between E-UTRAN and NGRAN feature from
Release SRAN15.1, GA 2019Q2.
There are following scenarios between LTE and NR mobility:
(1) 5G idle UE camping on LTE cell reselect NR cell where there is good coverage of
NR cell;
(2) 5G idle UE in the weak coverage of NR cell camp on LTE cell;
(3) 5G connected UE in the weak coverage of NR cell handover/redirect to LTE cell;
(4) 5G connected UE in the LTE cell redirect to NR cell when certain service bear is set
up;
(5) 5G connected UE in the NR cell without VoNR handover to LTE cell with VoLTE
when voice service bear is set up.
From Release 5G RAN2.1 SA (Standalone) architecture for NR-NR will be supported as
well.
Introduced in 5G RAN1.0, this function provides mobility management for modifications
of a primary secondary cell (PSCell) under a secondary gNB (SgNB) for UEs in
connected mode in an NR cell on an EN-DC network.
By scenario, the modifications are classified into two procedures:
1. SgNB Modification procedure
A PSCell of an SgNB is changed, and another cell under the same SgNB becomes a
PSCell.
2. SCG Change procedure
A PSCell under a SgNB is changed, and a cell under other gNodeBs becomes a
PSCell.
Mobility requirements are fulfilled for UEs supporting EN-DC in an NR cell.

Most operators choose NSA Option 3x as the 5G early deployment architecture from
the perspective of initial site cost.
In Option 3X
- The gNodeB is the data split anchor.
- The user-plane data can be carried on just the gNodeB, or the gNodeB can allocate
some of the user-plane data to the eNodeB.
- If user-plane data is carried on both the eNodeB and the gNodeB, then there will be
secondary cell group (SCG) split bearer.
SCG split bearer:
Current version supports mobility management only in NSA EN-DC networking and
PSCell change only in intra-frequency networking. This document describes PSCell
change only in NSA networking. Inter-frequency supporting version to be discussed.
Huawei Inter-RAT Mobility between E-UTRAN and NGRAN feature will be available in
SRAN15.1 (GA @2019Q2).
When the user moves from the NR excellent coverage area to the NR weak coverage
area or the blind area, it needs to support the mobility function of the idle user and the
connected user.
Benefit of the that is utilizing interoperability between 4G and 5G networks ensures
business continuity and business experience.

a) DL/UL decoupling: utilizes Sub3G FDD uplink “sleeping” spectrum to enhance uplink
coverage of C-Band.
b) UL COMP: uses the antennas of multiple cells to receive signals from a UE to
achieve signal combining gain and interference mitigation gain. It can improve the cell
edge user uplink experience.
c) Turbo receiver: More advanced receiver technology to get more accurate channel
estimation to improve UL coverage.
d) Flexible waveform: gNB can decide and communicate to the UE which one of CP-
OFDM and DFT-S-OFDM based waveforms for UL to use .DFT-S-OFDM is suitable for
a single stream transmissions and low modulation order. CP-OFDM can be used for a
single-stream and multi-stream transmissions. UL DFT-S-OFDM based waveform is
complementary to CP-OFDM waveform to improve UL coverage.
e) UL precoding: make the uplink beam precise directed to the receive antenna to
improve the uplink coverage.
f) Pi/2 BPSK: support lower modulation for uplink transmission.
g) UL FSS (Frequency Selective Scheduling): Frequency selective fading caused by
delay spread. UL FSS Facilitating superior user experience.
h) PMI feedback and SRS feedback adaptation: gNB can decide which one of PMI
feedback or SRS feedback to use according to the channel condition to improve UL
feedback performance.PMI feedback is for poor coverage.
Currently, Huawei gNodeB mainly support DL:UL configuration = 4:1 (DDDSU, 2.5ms),
8:2 (DDDDDDDSUU, 5ms), more configuation will be supported on the synchronisation
demand. Syncronization is needed with other operators to avoid interference.
In NSA Option 3x idle mode, UE will stays on LTE idle mode, while Connected mode in
NSA DC, if the 5G neighouring cell is within LTE Anchor area, only SgNB modification
is required to allow the connection to NR SgNB. If the UE is leaving LTE service cell
area, it will perform handover and re-set DC connection with NR cell. However, SA
Option 2 standard will be frozen by 2018 Q2. Huawei will follow the standard once it is
finalized.
Huawei 5G RAN solution does not support configurable time offset.
QoS Management mechanism is introduced in 5G SA. Huawei will support it in RAN2.1.

In 5G, service flow with the same QoS attribute is defined as one QoS flow. Radio
bearer is between gNB and UE, and gNB can map a QoS flow to radio bearer based on
the QoS attributes. Each QoS flow is related to 5QI, and each 5QI defines parameters
such as GBR/Non GBR, ARP and Priority Level. According to the 5QI and QoS
attributes, different QoS flows are mapped to different bearers or the approximate QoS
flow is merged mapped to the same bearer

QoS Management mechanism is introduced in 5G SA. Huawei will support it in RAN2.1.

In 5G, service flow with the same QoS attribute is defined as one QoS flow. Radio
bearer is between gNB and UE, and gNB can map a QoS flow to radio bearer based on
the QoS attributes. Each QoS flow is related to 5QI, and each 5QI defines parameters
such as GBR/Non GBR, ARP and Priority Level.
Priority level is used in DRX and HO parameter. gNB selects the DRX parameter group
and HO parameter group based on QoS priority. Besides, the priority will be shown
based on the bearers' differentiated scheduling.
GBR/Non GBR is shown in differentiated scheduling. In details, differentiated
scheduling is provided based on the settings of each bearer's scheduling weight factor,
channel quality, and history rate to satisfy QoS characteristics of each bearer.
For GBR services, GBR guarantee and MBR limitation are supported. For non-GBR
services, the limitation on AMBR for UEs and minGBR are supported. For GBR
services that GBR rate don’t be satisfied and Non-GBR services that minGBR rate don’t
be satisfied, high priority scheduling will be obtained.
ARP is applied in congestion and preemption mechanism.
1. When cell is overload, low ARP priority user will transfer to other cells;
2. When RRC user is exceed the cell threshold, it can differentiated control RRC insert,
select low ARP level user to other cells.
Based on ARP function, the customer can guarantee their priority and experience.
For NSA scenario:

The anchor is on LTE side, which is almost the same as 4G. The handover is based on
the signal quality to make less switch time and higher success rate. When UE is out of
gNB coverage, gNB will release resource.
For SA scenario:
According to the coverage of NR cell. Specifically, gNodeB will trigger UE to measure
LTE cell. If the quality of signal reach the inter-RAT handover threshold when UE move
to the edge of NR cell, UE will do inter-RAT handover.
supported. Up to 16 layers are supported in downlink. Up to 4 layers are supported in

uplink
For 28G, hybrid beamforming is applied. It includes two step beamforming: analog
beamforming and digital beamforming. Both DL MU-MIMO and UL MU-MIMO are
supported. Up to 4 layers are supported in downlink. Up to 4 layers are supported in
uplink.
The MU MIMO switch and maximum layer number can be configured in MML for cell
level.
The modulations for DL are QPSK/16QAM/64QAM/256QAM, for UL is
QPSK/16QAM/64QAM. Coding supports Polar & LDPC.
The New Radio (NR) system uses shared channels for transmission with time-
frequency resources dynamically allocated among UEs. The Scheduling feature allows
the gNodeB to balance time-frequency resource allocation in the uplink and downlink.
In addition to guaranteeing system throughput and user fairness, this feature also
improves system capacity and network performance.
Both DL MU-MIMO and UL MU-MIMO are supported. Up to 16 layers are supported in
downlink, and up to 4 layers are supported in uplink for 3.5GHz. Up to 4 layers are
supported in downlink, and up to 4 layers are supported in uplink for 28GHz.
Cell level Parameters can be configured in MML. For example, downlink IBLER
target/downlink AMC step adjustment/initial step for downlink AMC/Downlink
Interference Randomization-based Scheduling/uplink IBLER adaptation/initial uplink
SINR adjustment/uplink frequency selective scheduling/uplink IBLER adaptation/ MU
MIMO switch/ maximum layer number.

3GPP Release 15 supports flexible numerology. Appropriate subcarrier spacing

configurations and corresponding cyclic prefix (CP) lengths can be used based on
different service requirements and different frequency bands.
Huawei proposed solution supports Basic Numerology as below:
30 kHz subcarrier spacing configuration for C-band
15 kHz subcarrier spacing configuration for 1800M in SUL mode.
For C-band in 5G RAN, the minimum TTI is 0.5ms

For C-Band the minimum guard band to use different slot formats of different operators
in the same area is >=25MHz. There is a limitation for avoid ng Interference - ECC
Spurious emission requirement <-43dBm/5MHz TRP
Currently, Huawei proposed solution does not support Mixed Numerology. Only
following spacing configurations are supported.
30 kHz subcarrier spacing configuration for C-band;
15 kHz subcarrier spacing configuration for 1800M in SUL mode.
120 kHz subcarrier spacing configuration for mmWave.
Huawei plans to support it in 2021 or later, based on the market demand
Currently, this functionally is not supported by proposed solution. Huawei plans to

support it in 2021 or later, based on the market demand. Huawei is willing to discuss
the details with customer
DDDSU and DDDDDDDSUU are supported.
For DDDSU, the slot format is changed in fourth and fifth slot.
For DDDDDDDSUU, the slot format is changed in eighth and ninth slot
Currently, this functionally is not supported by proposed solution. Huawei plans to

support it in 2021 or later, based on the market demand. Huawei is willing to discuss
the details with customer.
UL COMP: uses the antennas of multiple cells to receive signals from a UE to achieve
signal combining gain and interference mitigation gain. It can improve the cell edge
user uplink experience.
UL FSS (Frequency Selective Scheduling): Frequency selective fading caused by delay
spread. UL FSS Facilitating superior user experience.
RB randomized scheduling: Since NR 3.5GHz has large bandwidth (100MHz), RB
randomized scheduling helps to reduce interference especially at eMBB and low load
case
Huawei supports slot format 0/1 and self-contain slot.

Self-contain slot is introduced for faster DL HARQ response and UL data schedule:
decreased RTT latency and shorter SRS cycle to trace the channel change quickly,
improves MIMO performance.
For self-contain slot, GP symbol can be configured by 1-6 symbol for different coverage
requests. Uplink symbol is 2. Downlink symbol is 11-6.
More GP symbols result in further coverage.
Under NSA scenario, UE will work in LTE and NR simultaneously, so that the power
consumption should be, in theory, higher than single mode scenario (SA Option2). In
the worst case, UE power consumption under NSA could be about 2~3W higher than
SA.

UE energy saving features will be vailable in 2019.

1. The NSA/SA supports the connected DRX. The terminal saves power and extends
the standby time of the mobile phone.
2. SA supports inactive RRC connection state management.
For self-contained slot, GP symbol number can be 1~6 symbols, and 2 uplink symbols
is configured.
Cell radius may be limited by GP configuration.
With this TDD frame format, premamble format C2 is available which allows maximum
cell radius of 9.3km.
Delay budget: Since DL and UL rotation period is shorter, it allows lower transmission
time latency.
Atmospheric duct interference is related to GP configuration. One symbol length is
35.7us, If GP length set to 6 symbols, total time length is 214us, co-channel sites within
64km wont' cause atmospheric duct interference. If GP length set to one symbol, total
time length is 35.7us, co-channel sites within 10km wont' cause atmospheric duct
interference. Typically, if GP set to 2 symbol length, co-channel sites within 20km wont'
cause atmospheric duct interference.
For atmospheric duct interference, Huawei will consider further algorithm to minimize
the impact, as what we have done in LTE-TDD.
Maximum available SSB beam number can be 7.
Further, Huawei supports DL:UL configuration of 7 DL slots: 1 Self-contained slot: 2 UL
slots for commercial deployment.
For downlink slot, slot format 0 is used. For uplink slot, slot format 1 is used.
For self-contained slot, GP symbol number can be 1~6 symbols, and 4 uplink symbols
is configured.
Cell radius may be limited by GP configuration.
With this TDD frame format, premamble format 0 is available which allows maximum
cell radius of 14.5km.
Delay budget: Since DL and UL rotation period is larger; it leads to larger transmission
time latency.
Atmospheric duct interference is related to GP configuration. One symbol length is
35.7us, If GP length set to 6 symbols, total time length is 214us, co-channel sites within
64km wont' cause atmospheric duct interference. If GP length set to one symbol, total
time length is 35.7us, co-channel sites within 10km wont' cause atmospheric duct
interference.
For atmospheric duct interference, Huawei will consider further algorithm to minimize
the impact, as what we have done in LTE-TDD.
Maximum available SSB beam number can be 8.
For 3.5GHz, Huawei recommeneds TDD frame format: 7 DL slots: 1 Self-contained slot:
Huawei suggests to use the same TDD frame format among operators.
For 3.5GHz, Huawei recommeneds TDD frame format: 7 DL slots: 1 self-contained slot:
2 UL slots, since coverage can be a key factor in Canada – it can be aligned with LTE-
TDD to avoid DL/UL cross link interference.
For 28GHz, Huawei recommeneds TDD frame format: 3 DL slots: 1 self-contained slot:
1 UL slot, since high capacity and ultra low latency is key adavantage for mmWave, not
coverage
Huawei proposed UBBPg3 board for 5G supports the following E-RAB specifications in
NSA mode:
Per cell: 1200 E-RABs
Per board: 3600 E-RABs
Huawei proposed UBBPg3 for 5G supports 1200 gNB RABs for high bands (3.5G/28G)
and 600 gNB RABs for low band (700M). Huawei plans to support SA mode in 2019Q2.

Huawei supports "MU-MIMO Basic Pairing" feature. This feature uses the same
orthogonal frequency division multiplexing (OFDM) time-frequency resources for the
uplink and downlink data transmission of multiple UEs for spatial multiplexing.
Users per TTI is an internal specification, which cannot be disclosed. Huawei is willing
to discuss this requirement with customer.
Currently Huawei proposed 5G RF modules do not support the suppressing

transmission in configurable PRBs (PRB blanking), for interference suppression. Based
on Huawei's understanding, this function is not so necessary for 5G. Huawei is willing to
discuss this requirement with customer.
For NSA 3x dual-connectivity operation, Huawei does not support Multi-Vendor

connection. Huawei is willing to discuss with customer about this requirement.
Inter-Band CA is not supported now due to the Band combination in 3GPP not frozen
yet. Currently, Huawei supports Intra-band NR CA, there are one combination on C-
band can be supported: 100+100MHz, the other option of combination of intra-band CA
will be supported after the 3GPP standard frozen.
In NSA scenario:
User plane: The delay from X2-U+S1 is recommended to be 5 ms, not more than 20
ms.
Control plane: The delay X2-C does not exceed 20 ms.
The values above are vendor-specific.
X2-C: X2 control plane
X2-U: X2 user plane.
Following methods to manage inactive UE are supported:

1. RRC status transition from connected to inactive. When a UE in inactive state moves
out from it's RNA area, RNA update is also supported.
2. RRC status transition from inactive to connected, including RNA-Based paging.
3. RRC status transition from inactive to idle.
Following methods to managing RNA are supported:
1. Configure an RNA value for each cell. Cells in the same area have the same RNA
value, the maximum cell number in a RNA Area is 32.
2. Two methods to get neighbor's RNA ID:
- Configure neighbor cell's RNA ID by operator.
- Automatically configured via Xn.
Huawei SA NG-RAN can provide equivalent number of cells, MIMO layers, bearers and
UE compared to NSA NG-RAN, performance (DL / UL speed, delay etc.), when
migrated from NSA to SA, the RRC Inactive UEs can share RRC Acitive user number
resources in the same equipment.
SA provides 5QI, so that service (GBR, Non-GBR, etc.) QoS mechanism can be
equivalent or higher compared to NSA NG-RAN
Beamforming and power boosting (-3, 0, 3) of SSB signals are performed in 3.5GHz
and 28GHz bands. 3.5GHz baseline beam pattern's maximum beamforming Gain is
24dBi. 28GHz maximum beamforming Gain is 31dBi.

The transmission period of SSB Burst Set Period (5~160ms) can be considered in
3.5GHz and 28GHz. The number of SSB transmitted in one SSB Burst Set is:
- Sub3G: <=4
- 3G~6G: <=7
- above6G: <=64
One SSB Burst Set can complete transmission of the entire beam.
1 symbol or 2 symbols are used as PDCCH resources in D slot and S slot in 3.5GHz
and 28GHz bands
1 symbol is used as Short-PUCCH resources in U slot in 3.5GHz and in S slot in 28GHz
bands.
2 symbols are used as SRS resources in S slot in 3.5GHz bands and 4 symbols are
used as SRS resources in U slot in 28GHz band.
Huawei supports both Short-PUCCH and Long-PUCCH in 3.5GHz and 28GHz bands.
gNB adaptively select Short-PUCCH and Long-PUCCH by SINR. Short-PUCCH is used
for good SINR and Long-PUCCH is used for bad SINR
The rest of PRB sections excluding SSB PRB areas in SSB Slot in 3.5GHz could be
utilized but in 28GHz could not be utilized because of the difference of MIMO
architecture.
Digital beamforming (DBF) is applied for 3.5GHz transmission so that gNB could
transmit different PRBs with different digital beams in 3.5GHz. However, hybrid
beamforming (HBF) is applied for 28GHz transmission so that gNB could only transmit
different PRBs with one analog beam in28GHz.
The rest of PRB sections excluding RACH PRB areas in RACH Slot in 3.5GHz could be
utilized but in 28GHz could not be utilized because of the difference of
MIMOarchitecture.
Digital beamforming (DBF) is applied for 3.5GHz transmission so that gNB could
receive different PRBs with different digital beams in 3.5GHz. However, hybrid
beamforming (HBF) is applied for 28GHz transmission so that gNB could only receive
different PRBs with one analog beam in28GHz.

Huawei supports 1~6 symbol GP in 3.5GHz and 28GHz.

GP length consideration:
1) To meet the requirement of TRX Switching time + Round Trip Propagation Delay.
Delay Spread is irrelevant to GP configuration. Round Trip Propagation Delay decided
by cell radius. It is complicated since in dense urban/urban area, rich reflection may
cause large delay but signal strength will still be strong enough to cause negative
impact to uplink.
2) To reduce cross-link interference from neighbor cells: neighbor cell downlink signal
interfere to serving cell uplink due to high transmission delay but signal strength cannot
be ignored. Currently Huawei suggests aligned TDD configuration to avoid interference.
Considering Dense Urban/Urban/Rural continuous coverage, the longest GP needs to
be selected based on the maximum cell coverage radius and maximum distance of
interfering adjacent cell. Please refer to the table below for details.
NSA(3&3X) will be availability at 2018Q4 in 5G RAN2.0 which based on 3GPP R15.

NSA(3&3X)&SA(2) will be availability at 2019Q2 in 5G RAN2.1 which based on 3GPP R15
CU-DU split:
2018Q2 in 5G RAN1.0 for trial with Huawei infrastructure
2018Q4 in 5G RAN2.0 for GA with Huawei infrastructure
2019Q1 in 5G RAN2.1 trial version for integration with customer infrastructure (Dell + Redhat).
MU-MIMO (Max DL 24 layer, UL 12 layer) will be availability at 2018Q4 in 5G RAN2.0 which based on 3GPP
R15.
Huawei proposes Intelligent Symbol Shutdown and DRX will be availability at 2019Q2 in 5G RAN2.1 which
based on 3GPP R15.
Huawei proposes VoNR (Trial) will be availability at 2019Q2 in 5G RAN2.1 which based on 3GPP R15.
Huawei proposes DL CoMP (Trial) will be availability at 2019Q3 in 5G RAN3.0 which based on 3GPP R15.
Huawei proposes NR UL&DL Decoupling (Trial) will be availability at 2018Q4 in 5G RAN2.0 which based on
3GPP R15.
Huawei proposes NR UL&DL Decoupling will be availability at 2019Q2 in 5G RAN2.1 which based on 3GPP
R15.
1.8G (≥15M) will be possible to use for UL when using n78 for DL in 5G RAN2.0. 700MHz, 800MHz and
2100MHz will support SUL in 19Q2 or later.
Huawei proposes DC&CA Package for intra-site DL Carrier Aggregation (CA) will be availability at 2018Q4 in
5G RAN2.0 which based on 3GPP R15.
This feature allows intra-band aggregation of up to two uplink or downlink sub-6 GHz carriers to achieve a
maximum bandwidth of 200 MHz. It allows aggregation of up to ten uplink or downlink 100 MHz mmWave
carriers, or of five uplink or downlink 200 MHz mmWave carriers to achieve a maximum bandwidth of 1 GHz.
In 5G RAN 2.0 Three combination on C-band can be supported:
40+40M, 40+60M, 100+100M.
Huawei NR RAN2.0 supports NSA (option 3, 3x). Huawei NR RAN2.1 will support SA (Option 2). The standard
for other architecture is not completely frozen yet, Huawei will follow 3GPP protocol.
For NSA Option 3/3a/3x, eNB acts as the anchor for smooth mobility and better coverage, the gNB signaling
will go through the eNB, which could increase the load of eNB, new X2 interface will add between eNE and
gNB.
For NSA Option 7/7a/7x, eNB acts as the anchor but need upgrade to eLTE to connect new core through new
Ng interface, and new Xn interface will add between eNE and gNB.
For SA Option 2, 5G NR and 4G LTE are independent, so there is no impact.
For SA Option 4/4a, 5G NR and 4G work in DC mode, and eNB need upgrade to eLTE to connect new core
through new Ng interface, and new Xn interface will add between eNE and gNB.
For SA Option 5, eNB need upgrade to eLTE to connect new core.
Huawei suggest controlling the latency of Xn within 20 ms, and Huawei have its own auto-adaptive algorithm to
adjust LTE and NR split ratio.
In case of traditional CU/DU non-separated scenario, the 5G BBU and 4G BBU shall be connected locally to
minimize the tromboning risk; in case of DU/CU separated scenario, the CP between 5G CU and 4G DU/CU
(BBU) will generate the tromboning latency.
It is possible since the S1 or Ng interface after standard interface defined in 5G standard releases.

In SA mode: when connected UE moves from 4G to 5G coverage, the eNB will trigger the handover based on
traffic steering and load balance by sending inter-RAT B1 event message, and UE response to complete the
handover if the N26 available between EPC and NG Core, otherwise RRC disconnect for redirection, the UE
camps on 5G cell.
In NSA mode: when connected UE moves from 4G to 4G/5G coverage, then MN trigger SN addition procedure
by sending inter-RAT B1 event message to camp on NR cell with dual connection.
GBR QoS Flows). The 5G QoS model also supports Reflective QoS.
A QoS Flow may be either 'GBR' or 'Non-GBR' depending on its QoS profile. The QoS profile of a QoS Flow
contains QoS parameters as described below：
- For each QoS Flow, the QoS profile shall include QoS parameters:
- A 5G QoS Identifier (5QI); and.
- An Allocation and Retention Priority (ARP).
- For each Non-GBR QoS Flow, the QoS profile may also include the QoS parameter:
- Reflective QoS Attribute (RQA).
- For each GBR QoS Flow, the QoS profile shall also include the QoS parameters:
- Guaranteed Flow Bit Rate (GFBR) - UL and DL; and
- Maximum Flow Bit Rate (MFBR) - UL and DL; and
- In the case of a GBR QoS Flow only, the QoS parameters may also include:
- Notification control.
- Maximum Packet Loss Rate - UL and DL.
Each PDU Session of a UE is associated with the following aggregate rate limit QoS parameter:
- Per Session Aggregate Maximum Bit Rate (Session-AMBR).
The subscribed Session-AMBR is a subscription parameter which is retrieved by the SMF from UDM. SMF
may use the subscribed Session-AMBR or modify it based on local policy or use the authorized Session-
AMBR received from PCF to get the Session-AMBR, which is signalled to the appropriate UPF entity/ies to the
UE and to the (R)AN (to enable the calculation of the UE-AMBR). The Session-AMBR limits the aggregate bit
rate that can be expected to be provided across all Non-GBR QoS Flows for a specific PDU Session. The
Session-AMBR is measured over an AMBR averaging window which is a standardized value. The Session-
AMBR is not applicable to GBR QoS Flows. In downlink direction, the Session-AMBR is enforced by the UPF.
In uplink, the Session-AMBR is enforced by both the UE and the UPF.
Each UE is associated with the following aggregate rate limit QoS parameter:
- per UE Aggregate Maximum Bit Rate (UE-AMBR).
The UE-AMBR limits the aggregate bit rate that can be expected to be provided across all Non-GBR QoS
Flows of a UE. Each (R)AN shall set its UE-AMBR to the sum of the Session-AMBR of all PDU Sessions with
active user plane to this (R)AN up to the value of the subscribed UE-AMBR. The subscribed UE-AMBR is a
subscription parameter which is retrieved from UDM and provided to the (R)AN by the AMF. The UE-AMBR is
measured over an AMBR averaging window which is a standardized value. The UE-AMBR is not applicable to
GBR QoS Flows. The (R)AN enforces the UE-AMBR in both downlink and uplink.
5G has the following differences compared with 4G:
1. Mapping relationship change: the EPS bearer and DRB in LTE are one-to-one correspondence, while in 5G,
the mapping of QoS flow and DRB can be many to one.
2. In LTE, the S1 port tunnel is per EPS bearer, while 5G is the tunnel of per session.
3. 5G introduces reflective QoS to reduce signaling overhead; RAN side uses reflective mapping to configure
UL QoS flow and DRB mapping relationship through UP side.
4. 5G introduces Notification control.
These difference point simplify tunnel management (transforms multiple tunnels into one tunnel,) reduces
signaling cost and optimizes RAN resources.
The minimum resolution entity for the provision of QoS is QoS flow. One PDU Session includes multiple QoS
flow
Based on definition in 3GPP standard, the Qos profile is not applied to slice, only applied to PDU session, Qos
profile is related to the service (Qos flow) and user attributes. For example, two UEs in one same slice can use
different QoS profiles.
The slice is oriented to UE SLA, two UEs with same Qos can be in two different slices, slices has the different
In the UE Registration process, the AMF gets the NSSP from PCF and deliver NSSP to UE. Network Slice
Selection Policy (NSSP): This is used by the UE to associate the matching application with S-NSSAI.
There is no Session Data Flows (SDF) defined by slice. PCF tells the slice and service relationship to UE, UE
select slice mapping to the service flow. In UE session establishment process, the definition of SDF is in QoS
issued by PCC.
Huawei supports following mechanisms:

1. Both DL and UL QoS differentiation between 5QI/5QI+ARP.
2. Qos flow mapping to radio bearer configuration.
3. Operator defined non-standardized 5QI.
4. Reflective QoS control.
5. Support minimum bit rate for non-GBR bearer.
6. GFBR, MFBR guarantee and UE-AMBR rate limitation.
7. Compatible to NSA architecture.
There is no bearer concept in 5G Core, neither default bearer nor dedicated bearer. In 5G, you can use
different or same PDU session for internet and voNR. For voice service, UE can be fallback to 4G or continue
in 5G.
There is no relationship between the dedicated bearer and slice.

The same as 4G, in 5G as defined in 3GPP 23.003, the Tracking Area Identity (TAI) consists of a Mobile
Country Code (MCC), Mobile Network Code (MNC), and Tracking Area Code (TAC).
When a UE registers with the network over the 3GPP access, the AMF allocates a set of tracking areas in TAI
List to the UE. A number of tracking area TA is combined into a TA List, and when the mobile terminal moves
in all TA areas contained in TA List, no TA update /4G is needed, or a mobility registration update procedure
/5G is not required. When there is paging users in the network, paging users in all TA zones that are contained
in the entire TA List. TA List allows core network to be dynamically allocated according to user attributes.
The Registration type indicates if the UE wants to perform an Initial Registration (i.e. the UE is in RM-
DEREGISTERED state), a Mobility Registration Update (i.e. the UE is in RM-REGISTERED state and initiates
a Registration procedure due to mobility or due to the UE needs to update its capabilities or protocol
parameters), or a Periodic Registration Update (i.e. the UE is in RM-REGISTERED state and initiates a
Registration procedure due to the Periodic Registration Update timer expiry or an Emergency Registration (i.e.
the UE is in limited service state).
In the RM-REGISTERED (IDLE/ CONNECTED) state, the UE shall perform Mobility Registration Update
procedure (Registration type is Mobility Registration Update) if the current TAI of the serving cellis not in the
list of TAIs that the UE has received from the network in order to maintain the registration and enable the AMF
to page the UE.
In 4G, the MME carry the TA List to UE in the Attach Accept, TAU Accept, and GUTI Reallocation Command
messages. In 5G, the AMF carry the TA List to UE in the Registration Accept and Registration Update
messages.
If the predefined time period is timeout, UE needs to perform Periodic Registration Update and the period is
update, if TA list is move out, UE needs to perform Mobility Registration Update.
The General Registration call flow in the reply of Requirment“5.6 Registering procedure 5G” applies on all
these Registration procedures, but the periodic registration need not include all parameters that are used in
other registration cases.
Interworking procedures using the N26 interface, enables the exchange of MM and SM states between the
source and target network. When interworking procedures with N26 is used, the UE operates in single-
registration mode. For the 3GPP access, the network keeps only one valid MM state for the UE, either in the
AMF or MME. For the 3GPP access, either the AMF or the MME is registered in the HSS+UDM.
When the UE supports single-registration mode and network supports interworking procedure with the N26
interface:
- For idle mode mobility from 5GS to EPS, the UE performs either TAU or Attach procedure with EPS GUTI
mapped from 5G-GUTI sent as old Native GUTI, and indicates that it is moving from 5GC. The MME retrieves
the UE's MM and SM context from 5GC. For connected mode mobility from 5GS to EPS, either inter-system
handover or RRC Connection Release with Redirection to E-UTRAN is performed. During the TAU or Attach
procedure the HSS+UDM cancels any AMF registration associated with the 3GPP access (but not AMF
registration associated with the non-3GPP access): an AMF that was serving the UE over both 3GPP and non-
3GPP accesses does not consider the UE as deregistered over non 3GPP access.
The role of the protocol N26 established between EPC+ and 5G CN is same to between EPC and 5G CN. N26
use the same interface protocol with S10, there is some enhance on N26 interface.
When the UE supports single-registration mode and network supports interworking procedure with the N26
interface:
- For idle mode mobility from 5GS to EPS, the UE performs either TAU or Attach procedure with EPS GUTI
mapped from 5G-GUTI sent as old Native GUTI, and indicates that it is moving from 5GC. The MME retrieves
the UE's MM and SM context from 5GC. For connected mode mobility from 5GS to EPS, either inter-system
handover or RRC Connection Release with Redirection to E-UTRAN is performed. During the TAU or Attach
procedure the HSS+UDM cancels any AMF registration associated with the 3GPP access: an AMF that was
serving the UE over both 3GPP and non-3GPP accesses does not consider the UE as deregistered over non
3GPP access.
In the handover procedure between 5G and 4G, one 5G PDU session maps to one 4G PDN session; the
dedicated bearer setup may be triggered by the PCRF+PCF which may also provide the mapped QoS
parameters, if PCC is deployed.
A 5GS supports Network Slicing and might need to interwork with the EPS in its PLMN or in other PLMNs. The
EPC may support the Dedicated Core Networks (DCN). In some deployments, the MME selection may be
assisted by a DCN-ID provided by the UE to the RAN. Mobility between 5GC to EPC does not guarantee all
active PDU Session(s) can be transferred to the EPC.
The entity functions involved in the inter 5G – 4G handover procedure: UE, E-UTRAN, NG RAN, AMF, MME,
SGW SMF+PGW-C, UPF+ PGW-U, PCF+PCRF (optional).
PCF + PCRF, PGW-C + SMF and UPF + PGW-U are dedicated for interworking between 5GS and EPC,
which are optional and are based on UE and network capabilities.
N26 interface is an inter-CN interface between the MME and 5GS AMF in order to enable interworking
between EPC and the NG core. Support of N26 interface in the network is optional for interworking. N26
supports subset of the functionalities (essential for interworking) that are supported over S10.

Huawei supports following DC & CA solutions for 5G NR and LTE. For NSA, Huawei supports following
DC&CA combinations. SA architecture is not supported currently.
EN-DC with LTE CA: LTE 1CC + NR 1CC (NR is Band 3.5GHz or 28GHz) The EN-DC combination "LTE
1CC + NR 1CC" will be supported. The specific band combination will follow 3GPP definition.
EN-DC with LTE CA: LTE 2CC + NR 1CC (NR is Band 3.5GHz) The EN-DC combination "LTE 2CC + NR
1CC" will be supported. The specific band combination will follow 3GPP definition.
End to End security covers device, NG RAN, NG Core, NG OSS. End to End security follows the current
3GPP standard. 3GPP organization is studying and standardizing 5G technology, and Huawei products will
continue to comply with the latest 3GPP standard.
1. The NAS message between UE and CN would be protected with encryption and integrity protection,
according to the 3GPP.
2. The AS message between UE and RAN would be protected with encryption and integrity protection,
3. The user plane data between UE and RAN would be protected with encryption and integrity protection,
4. The data flows of N2/N3/Xn interface which pass throught the untrust domain network are protected with
IPsec, which provides encryption and integrity protection, and mutual authentication.
5. For the F1 interface, data flow between CU and DU is protected with IPsec tunnel from DU to the external
sewcurity gateway,
6. The data flow of OMCH interface is protected with TLS, which provides encryption and integrity protection,
and mutual authentication.
For NSA dual connectivity, Cell Reselection happens only in LTE. 5G NR cell reselection to and from
WCDMA/GSM will be implemented after 3GPP is fully frozen and released.
For NSA dual connectivity, there is no handover between 5G and WCDMA/GSM. Handover from LTE to and
from WCDMA/GSM is supported.
Huawei will support handover to and from WCDMA/GSM when 3GPP is fully frozen and released.
For LTE, The supported L2 features are: Ethernet link aggregation (802.3ad), VLAN, ETHOAM, LLDP.
The supported L3 features are: IPPM, TWAMP, BFD, active/standby route, active/standby OM channel, IPSec.
For 5G NR, currently supported L3 feature is IPSec (with IP layer (L3) capability of 550 Byte packet length).
Major Pros and Cons with the supported options:

Option 3 cons: legacy BBU baseband is limited.
Option 3a Pros: No limitation to legacy BBU.
Option 3a cons: Traffic steering in core only applicable in RAB level and cannot adjust base on radio condition.
Option 3x Pros: No limitation to legacy BBU. Traffic steering in RAN at per packet base provide better
performance.
Huawei plans to have 5G NR test smartphone by 2019H2, supporting 3GPP R15, 2G/3G/4G/5G, NSA option
3/3a/3x, SA option 2 and VoNR.
For NSA, Huawei will support option 3X for the best performance. Option 3a is not suggested and not
supported. Option 3 is supported but not suggested.
Option 3 and Option 3X can be deployed on the same base station. For example, voice services and NB-IoT
use option3, and data services use option 3x.
Option 4 and option7 will need 5G new core. They will be planned based on the market request. According
Huawei understanding, most of the operators globally will evolve to SA from Option 3X directly. For the RAN
part, only SW upgrade is needed. Comparing with NSA, the main benefit of SA (Option4) is to bring in network
slicing. Option 7 is about NSA with new core. It’s a transition solution to avoid frequent switch of control panel.
Its control panel is still in the LTE part and there is no obvious benefit to the access part of the network.
3GPP standard for option 4 & 7 is still under discussion, Huawei is willing to cooperate with customer for
further technical discussion.

1. The drives for LTE to evolve to NR are: business growth in data traffic and vertical industry, spectrum
efficiency.
2. Voice and GBR service will be on LTE as preferred while non-GBR service on NR.
3. LTE and NR are complementary in the aspects of service priority and coverage, Off-loading happened in the
hotspot.
RRM management could be unified or separated. By CloudRAN, PDCP and RRC could be unified. Actually in
Option 3X, since 5G is used to off-loading the data plane, there is no big difference in 2 solutions.
SRAN15.1 will be released in 2019 Q2, it could supports LTE NR uplink dynamic spectrum sharing. The
supported frequency bands are 1800M/2100M/700M/800M. 900M and 2600M is under consideration, and it
may be developed according to the market request.
In SRAN15.0/SRAN15.1, the combination of 1800M+3.5G can be used for uplink and downlink decoupling.
The uplink and downlink decoupling of 700M/800M is being planned in SRAN15.1 (2019Q2).
For 5G NR Basic services, synchronization precision requirement is ±1.5us. If not satisfied, there will be
interference between sites.
a) Huawei 5G gNB supports GPS and 1588V2 as 5G synchronization solution. G.8275.1 can be used for 5G,
G.8275.2 synchronization precision is lower than G.8275.1, so G.8275.2 is not recommended for 5G.
b) Huawei recommended that GPS is adopted as high priority synchronization solution. If “GPS (Master) +
IEEE1588v2 (Slave)” mode is configured, automatic switching will be provided from GPS synchronization to
IEEE1588v2 synchronization when a GPS failure occurs.
c) When IEEE1588V2 is adopted as the master synchronization solution, 2 BITS is recommended to strength
the system reliability and stability.
d) NTP is needed. For example, when the base station records the log, or the base station determines the
validity period of the digital certificate. In these scenarios, NTP is required.
Huawei supports shared spectrum for MOCN; Huawei supports RAN sharing with dedicated 5G NR carrier
(MORAN); Huawei supports up to 6 PLMNs per shared 5G NR.
For shared spectrum, Huawei will support (is planning in 2020 Q2) percentage of radio resource shared per
PLMN, for example, operator 1 can use 50%
Huawei uses below dimensioning parameters for 5G-NR which involved for coverage, capacity and QoS
calculations.
1. ISD
2. Carrier Frequency
3. Bandwidth
4. Channel model
5. Penetration loss
6. gNB Antenna Height
7. Tilt
8. DL:UL subframe ratio
9. gNB Antenna Configuration
10. TUE Antenna Configuration
11. BS TX Power
12. BS Antenna Gain
13. UE TX Power
14. Average User Number
15. UE distribution
16. Cell Number
17. Traffic Load
In the same carrier bandwidth on same 3GPP band and same MIMO, the performance of 5G-NR is better than
4G/LTE.
For MIMO 4X4, NR is about ~1.46 times gains as LTE

Energy conservation and emission reduction functions help improve the operating efficiency and reduce the
power consumption of devices, such as power amplifiers (PAs). Operators can query the power consumption
of devices and related changes on the EMS.
In the NR, uplink power control enables gNodeBs to control the uplink transmit power of UEs in a way that UE
power consumption can be reduced with uplink service quality guaranteed and ensured. Uplink power control
applies to the PUSCH, PUCCH, SRS, and PRACH. Downlink power control enables gNodeBs to control the
downlink transmit power of each physical channel to ensure and improve the downlink service quality while
reducing the gNodeB power consumption. Uplink power control applies to the PDSCH, PBCH, and PSCH.
The counter “VS.EnergyCons.BTS.Measuring.NR” provides the power consumption of 5G NR within the

measurement period. The value of this counter is calculated by using the power consumption measured by the
power system.
The Base Station periodically monitors the power of each monitoring point and reports the power consumption
within a period. The EMS receives and collects all data about power consumption. Through the EMS, operator
can observe the change in the power consumption and analyze the power consumption according to a
statistics report generated by the EMS.
Huawei has robust security solution for 4G RAN network based on industry best practice on security area. For
5G NSA deployment except for existing LTE security Solutions, there also some enhancement defined by
3GPP, such as
(1) UP and CP support Both Encryption and Integrity Protection (3GPP R15)
(2) Permanent user ID encrypted all time (3GPP R15)
(3) Security algorithm supports both 128-bit keys and 256-bit keys ((3GPP R16)
5G network has stronger security requirement to support the diversity of new services, which is still under
discussion, while Huawei is one of the most important security standard contributor in 3GPP, and Huawei 5G
products will comply 3GPP 5G security standard when it release.
Huawei SON solution is based on the network quality and network resource to design an optimal algorithm to
perform self-configuration/self-optimization/self-recovery functions. Huawei mAOS supports Operator
Controlled (Open Loop) Operation and autonomous (Close Loop) operation and they shall be easy to switch.
Huawei U2020 will provide auto deployment solution for 5G in self-configuration, which will be planned in OSS
R19.1 (2019 Q2), such as 5G ANR, 5G PCI etc
Huawei support Type-I codebooks for Massive MIMO. But multi-panel codebooks is not supported.
With Huawei DL 256QAM feature, 256QAM is supported on the sub-6 GHz and mmWave bands. With this
feature, when channel condition allows, high-order modulation can be used to provide higher data rates. MCS
is adjusted to adapt to UE-reported CQIs and IBLERs. When the MCS is above a certain order, 256QAM can
be selected in the downlink to raise user peak throughput and boost cell capacity.

Remark


友商也不支
持

MN相当于
LTE主小区，
SN相当于NR
辅小区

随项目确认
未来版本

随项目确认
未来版本





Coordinating TP
Serving TP
Coordinating TP
Serving TP
















Back

Key word



Dynamic
5G 5G Feature Dynamic TDD 19A
TDD
Dynamic
TDD
Dynamic
TDD
Dynamic
TDD
Dynamic
TDD
Dynamic
TDD
5G 5G Feature DC&CA 19A NSA DC





5G 5G Feature DC&CA 19A NR CA

5G 5G Feature DC&CA 19A NR DC
5G 5G Feature DC&CA 19A CA
5G 5G Feature DC&CA 19A Bandwidth
5G 5G Feature DC&CA 19A CA
Inter-cell and
UCNC
5G 5G Feature 19A inter-site
Coordination
scheduling

UCNC JT， SMP，

5G 5G Feature 19A
Coordination DMP
UCNC JT， SMP，

5G 5G Feature 19A
Coordination DMP
Joint
UCNC
5G 5G Feature 19A Reception，
Coordination
CoMP
Dynamic
UCNC
5G 5G Feature 19A point
Coordination
switching
UCNC Inter-RAT
5G 5G Feature 19A
Coordination coordinated
UCNC
5G 5G Feature 19A Multi TRP
Coordination
UCNC
5G 5G Feature 19A Multi TRP
Coordination
5G 5G Feature D-SON 19A ANR
Energy
5G 5G Feature Energy Saving 19A
Saving
UCNC
5G 5G Feature 19A interference
Coordination
UCNC
5G 5G Feature 19A
Coordination

Please describe your concept for hybrid beamforming FC
Support MU-MIMO FC
Dynamically switch between various levels of MU-MIMO transmission or a per-TTI basis
depending on radio conditions, UE grouping and channel orthogonality, and other FC
scheduling inputs
Supported maximum MU-MIMO layer number in downlink FC
Supported maximum MU-MIMO layer number in uiplink FC
Maximum number of layers per user & peak user rate in downlink FC
Maximum number of layers per user & peak user rate in uplink FC
2-4 concurrent users with 1 spatial layer each in downlink MU-MIMO FC
2 concurrent users with 2 spatial layers each in downlink MU-MIMO FC
2-4 concurrent users with 1-2 spatial layers each in downlink MU-MIMO FC
Hybrid analogue / digital beam forming and selection for mmWave FC
Any beamforming performance restrictions, especially with respect to limits imposed by

FC
highly mobile users
PDSCH per TTI dynamic Rank adaptation FC
PDSCH per TTI Dynamic SU/MU MIMO adaptation FC
PDSCH Tx Diversity: Mandatory to support implicity Tx diversity FC
PDSCH Tx Diversity and close-loop SU/MU MIMO: Mandatory to support dynamic

FC
switching (dynamic adaptation)
PUSCH Tx Diversity and Precodded MU MIMO switching: Dynamic switching and

FC
transparent to the UE
Beam-steering range (or called beam sweeping range) in azimuth and elevation:
Specify the maximum beam steering in Horizontal plane and in Vertical plane for narrow FC
beams
Horizontal and vertical half power beam width for Narrow Beams: Specify the 3dB
beamwidth of the radiation pattern in horizonttal plane and the 3dB beamwidth of the FC
radiation pattern in vertical plane
Beam number for SS Block transmission FC
PDSCH analog beam number FC

Analog Beamforming (BF) Concept: Explain the Analog BF concept and the differences
FC
between Analog BF and Digital BF
Why Analog is applicable for mmWave and Digital for sub6 GHz FC

Please describe the concept for handling common control channels (system info, random
FC
access, paging) in Massive MIMO for mmWave
Dynamic optimal selection of transmission modes and spatial multiplexing mode to suit
FC
instantaneous radio conditions
The 5G RAN system shall support flexible and dynamic assignment of TDD transmission
resources (in contrast to TD-LTE, which has a fixed UL/DL configuration and assumptions
PC
about traffic loading). The Supplier shall detail how the dynamic assignment of TDD
transmission will function.
Interference control solution shall be provided to ensure that there is no mutual interference
effect when the calls with different DL : UL Configuration are used in combination and the PC
proposer's product can perform dynamic TDD operation in the multi-cell environment.
SFI Signaling: GC-PDCCH based indication of slot structure and dynamic (per TTI)
NC
variation of slot structure
RS Coordination for CLI Measurement: Intra-DU TRP-TRP cross link interference
PC
measurement for dynamic TDD
RS Coordination for CLI Measurement: NW configuration for UE-UE cross link interference
PC
measurement for dynamic TDD
Inter DU RS Coordination for CLI measurement: Inter DU TRP to TRP cross link
interference measurement. Coordinate the RS and measurement window across DU to
PC
make CLI (cross link interference) measurement which enables the dynamic TDD slot
format coordination
The Supplier shall support “mini-slots”, which are frames that are able to pre-empt normal
transmission and can start at any time.
PC
The Supplier shall support features to map the use of mini-slots to specific QoS flows or
slices.
Please provide a recommended configuration to support the URLLC target for user plane
PC
RTT latency of 1 ms with reliability of 99.999% in mmWave
Do you propose separate numerologies for normal eMBB traffic and ultra-low latency
PC
service?
Do you support different numerologies multiplexing within same carrier for normal eMBB
PC
traffic and ultra-low latency service?
URLLC DL or UL one way delay≤0.5ms shall be satisfied PC
2, 4 and 7 symbol mini slots should be supported. PC
Mini-Slot Based Pre-emption for URLLC should be supported. FC
Cross Scheduled Mini Slot for PDSCH: 2,4, and 7 symbol PDSCH allocation starting in
PC
ANY OFDM symbol within a slot and with DCI at the beginning of the slot
Self Scheduled Mini Slot for PDSCH: 2, 4 and 7 symbol PDSCH allocation starting in
PC
OFDM symbol within a slot and with DCI in the SAME OFDM symbol
99.999% URLLC Reliability required by ITU shall be supported. PC
The vendor shall list supported bearers in NSA FC
PDCP: Support configuration of bearer-switch or bearer-split depending upon UE capability FC

EN-DC(EUTRA-NR Dual Connectivity): PDCP support split-SRB and duplicate SRB FC
EN-DC: PDCP support split-DRB and duplicate DRB under EN-DC PC
NR and NR DC: PDCP support split-SRB and duplicate SRB PC
NR and NR DC: PDCP support split-DRB and duplicate DRB PC
PDCP: support ROHC FC
EN-DC: MN(Master Node) initiated SN(Secondary Node) addition should be supported FC

EN-DC: SN modification: MN/SN initiated with and w/o MN involvement including operator
configurable triggering conditions (e.g. DL and UL link quality, load based, etc.) with PC
operator configurable time-to-trigger, hysteresis, and offset parameters.
EN-DC: SN release: MN/SN initiated involvement including operator configurable triggering
conditions (e.g. DL and UL link quality, load based, etc.) with operator configurable time-to- PC
trigger, hysteresis, and offset parameters.
EN-DC: SN change: MN/SN initiated including operator configurable triggering conditions
(e.g. DL and UL link quality, load based, etc.) with operator configurable time-to-trigger, PC
hysteresis, and offset parameters.
EN-DC: SCG reconfiguration: used for SCG establishment and SCG reconfiguration within
the same or different SN including operator configurable criteria for PSCell change (e.g. DL
FC
and UL link quality, load based, etc.) with operator configurable time-to-trigger, hysteresis,
EN-DC: MN handover/change: with or w/o SN change and including data forwarding

including operator configurable criteria (e.g. DL and UL link quality, load based, time-to- FC
trigger, and hysteresis etc.)
For NSA DC, DL traffic dynamic split between SCG and MCG should be supported FC
For NSA DC, UL traffic dynamic split between SCG and MCG should be supported FC
NSA DC uplink power control: Semi-static power splitting mode should be supported FC
NSA DC uplink power control: Dynamic power sharing mode should be supported PC
NSA DC uplink power control: SUO-case1 (Single Uplink Operation) mode should be
PC
supported
EN-DC:Support fast centralized retransmissions of lost PDCP PDUs when performing
FC
inter-gNB-DU mobility
The Supplier shall provide CU-level coordination features to enable fast redirection of traffic
FC
flows and packet forwarding in the case of 5G radio link failure
The Supplier shall provide CU-level coordination features to enable traffic flow and load
balancing functions to distribute flows optimally between 4G and 5G. The Supplier shall FC
describe the mechanism and expected performance gain of these features.
The Supplier may provide a feature to optimise the use of NR by modifying relevant
thresholds which dictate whether a device will attempt to start or stop using NR dual FC
connectivity
The Supplier shall provide a SON feature for discovering and associating LTE and NR cells
or sites to be used in a dual-connectivity relationship.
This feature will:
1. Reduce the need for operator / manual creation of static relationships between LTE and
NR cells
PC
2. Create all required network data and interfaces to facilitate the dual connectivity
relationship automatically
3. Avoid the need to create site-specific data-fill in areas with variable or patchy 5G
coverage
4. Clean-up erroneously created or rarely used relationship
Describe LTE and 5G interworking including DC and CA FC
Please provide the maximum delay requirements for the X2 interface when used for LTE-
NR Dual Connectivity. Does the maximum delay depend upon the option used (option 3 vs. FC
3x)? How does the Xn interface delay impact the E2E application delay?

Please indicate what information should be shared between gNB and eNB to make Dual
FC
Connectivity operation effective and fair for all users.
Operator can configure steering the traffic to NR vs E-UTRAN cells based on QCI, cell
PC
load, or other parameters signalled by the core network over S1-MME.
With 5G NSA (option 3 family), the 5G RAN shall either fully support QCI=1 and QCI=2
bearers or support voice services at least via create the QCI=1 and QCI=2 bearers over the FC
E-UTRAN access.
Maximum number of Active CC in the DL for 28GHz intra-band CA FC
Maximum number of Active CC in the UL for 28GHz intra-band CA FC
EN-DC with LTE CA: LTE 1CC + NR 1CC (NR is Band 28GHz) should be supported FC
NR 3.5GHz and NR 28GHz inter band CA should be supported PC

NR 3.5GHz and NR 28GHz DC should be supported PC
Cross carrier scheduling should be supported for CA PC
CC without Synch and Cross CC QCL PC
Bandwdith Part Configuration: Bandwdith part are UE specific and configured via RRC
FC
signaling
Maximum Number of BW Part Configured: Maximum suported by ASN.1. Only 1 active BW
FC
part at a time
BW Part Activation/Deactivation: DCI based, Timer Based and RRC Signaling Based
PC
should be supported.
Inter-site CA should be supported PC
Inter-cell and inter-site scheduling should be supported. PC

NC-JT (Non-Coherent Joint Transmission) should be supported. FC
C-JT (Coherent Joint Transmission) should be supported. PC
Joint Reception should be supported. FC
Dynamic point switching should be supported. PC
DU level LTE and NR Inter-RAT coordinated scheduling should be supported. PC
Multi TRP Single DCI scheduling: NC JT with joint scheduler FC
Multi TRP Multi DCI scheduling: NC JT with indepndent scheduler, 2 PDSCH allocation
FC
using 2 separate DCI within a given slot.
Same as 3.5GHz
Dynamic Energy Saving based on traffic load should be supported FC
Vendor to indicate and describe 5G NR inteference management support FC
The RAN supplier shall indicate the support of the DFT-precoded OFDM for UL
transmission and shall describe the mechanism or criteria that allows dynamic switching of
the UL transmission between OFDM and DFT-precoded OFDM ("Transform precoding" –
TS 38.300). The expected coverage gain (vs UL OFDM) inferred by the use of this
precoding shall be indicated.

Response
Name
Hybrid beamforming includes two step beamforming: analog beamforming and digital beamforming.
mmWave antenna array is separated into 4 subarrays. Analog beam is generated by each subarray, so that
totally 4 simultaneous analog beams can be generated. For analog beamforming, UE needs to feedback best
beam information to gNB, gNB generates analog beam accordingly.
R19A
gNB can further perform digital beamforming, which is processed at baseband, with digital beamforming,
each stream can map to all subarrays, so that all antenna elements can be used for each stream
transmission. For downlink digital beamforming, UE needs to feedback CSI information to gNB, gNB
processes digital beamforming according to UE feedback information.
Both DL MU-MIMO and UL MU-MIMO are supported R19A

It’s supported that dynamically switch between various levels of MU-MIMO transmission on a per-TTI basis
depending on radio conditions. For each TTI, different MU-MIMO total layer number can be scheduled, R19A
different UEs in low channel correlation between each other can be scheduled as spatial multiplexing.
Up to 4 layers are supported in downlink for a single AAU. R19A
Up to 4 layers are supported in uplink for a single AAU. R19A
For a single UE with 2T4R, number of layers in DL can be 4. R19A
For a single UE with 2T4R, number of layers in UL can be 2. R19A
Up to 4 concurrent users with 1 spatial layer each are supported. R19A
Two concurrent users can be scheduled in MU-MIMO, and up to 4 layers are supported. R19A
User with 1 layer, 2 layers can perform MU-MIMO. Concurrent users number can be 2, 3, 4. R19A
Hybrid analogue / digital beam forming are applied for mmWave transmission.
For analog beamforming, UE needs to feedback best beam information to gNB, gNB generate analog beam
R19A
accordingly. For downlink digital beamforming, UE needs to feedback CSI information to gNB, gNB
processes digital beamforming according to UE feedback information.
High mobility user is not suitable to perform MU-MIMO. R19A
PDSCH per TTI dynamic rank adaptation is supported. R19A

PDSCH per TTI Dynamic SU/MU adaptation is supported. R19A
Huawei supports Transmit diversity as described following: Same signal are transmitted in two polarizations
for PDSCH when PMI or SRS is not available. Typically for scenario of UE initial access to the network or R19A
during handover.
Huawei supports dynamic adaptation of MIMO transmission: When CSI feedback is not available, for
example, UE initially accesses to the network, gNB will schedule as transmit diversity since CSI feedback is
not available, and gNB will adapt to schedule as close-loop SU-MIMO or MU-MIMO once CSI feedback
become available at gNB side. SU-MIMO and MU-MIMO is dynamically selected at TTI level according to R19A
radio conditions and channel orthogonality between different users. When UE moves to the cell edge and
SRS feedback become unreliable, PMI based beamforming weight calculation will be used to further improve
UE performance.
R19A
Horizontal:±60º
R19A
Vertical:±15º
Horizontal: 6.4°
R19A
Vertical: 5.3°
4 concurrent beam can be generated. R19A

For basic configuration, there are 40 beams.
R19A
Beam number can be different according to different frame structure configuration.
PDSCH analog beam number 56 beams.
Digital BF is processed in digital using amplitude phase vectors, while Analog BF normally done by phase
R19A
shifter/VGA in RF front-end.
Digital BF provides the highest dynamics for beamforming, enable higher order mimo usage, but the
cost/power consumption also high.
Main challenge of mmWave is coverage, Analog BF can provide almost the same coverage gain when using
R19A
the same antenna number in a simple way, so that to reduce cost/power consumption. Actually, currently for
mmWave, Huawei product supports Hybrid BF: Digital BF + Analog BF. And for lower band, Digital BF is
used.

Reply
attachment
Refer to word attachment R19A
for
28GHz.docx
In downlink, transmission mode hasn’t been defined in 3GPP, Huawei will follow 3GPP and consider
transmission mode adaptation if necessary. Currently Huawei support both open loop and close loop. Open
loop is mainly used at initial access when no CSI feedback and high mobility. Close loop need UE CSI
feedback. UE feedback can base on SRS in uplink by channel reciprocity or PMI feedback. The gNB can
select the SRS-based weight or PMI weight for the UE according to the SRS SINR, the rank is based on the
CSI feedback. R19A
In uplink, currently 3GPP only define one transmission mode: TM1, so transmission mode adaptation is not
available. If 3GPP defines more transmission mode in the future, Huawei will consider supporting more
transmission mode and transmission mode adaptation if necessary according to performance evaluation. In
uplink, TM1 is defined as close-loop MIMO, codebook based precoding is applied. Rank and precoding
matrix is dynamically selected to suit instantaneous radio conditions.
Currently it's not supported. Supported version is TBD. R19A
Currently it's not supported. Interference control solution is under study, and supported version is TBD. R19A
Currently it's not supported. R19A
Currently it's not supported.

R19A
R19A

R19A

R19A

R19A
R19A
R19A
R19A
R19A
R19A
R19A
R19A
R19A
Huawei supports MCG Bearer and SCG Split Bearer for option 3X.
R19A
Huawei supports MCG Bearer and MCG Split Bearer for option 3.
R19A
Split SRB and duplicate SRB are supported. R19A
LTE PDCP supports split DRB but not supports duplicated DRB in ENDC. R19A
Neither split-SRB nor duplicate SRB is supported. Supported version is TBD. R19A
Split-DRB is supported. Duplicate DRB is not supported. R19A
R19A
R19A

MN initiated is supported for SN encryption parameter modification, triggering condition is not operator
configurable.
R19A
SN initiated SN modification is supported. SN initiates modification according to measurement results, and
adjustment will be inform to MN.
MN initiated is supported, triggered condition includes: traffic split exception or SgNB RLF, triggering
condition is not operator configurable. R19A
SN initiated is supported.
MN initiated is not supported currently.
SN initiated SN change is supported. SN initiates change according to measurement results, and adjustment R19A
will be inform to MN.
It's supported. R19A
R19A
NSA DC traffic split mode is configurable in downlink, can be SCG only, MCG only, and SCG & MCG
R19A
dynamic
NSA DC split.
traffic split mode is configurable in uplink, can be SCG only, MCG only, and SCG & MCG dynamic
R19A
split.
For a specific user, Plte-MAX will be configured as max allowed TX power in LTE uplink, and Pnr-MAX will
be configured as max allowed TX power in NR uplink. Plte-MAX + Pnr-MAX can be ≤Pmax, or Plte-MAX +
Pnr-MAX can be >Pmax. While Plte-MAX + Pnr-MAX ≤Pmax, UE in LTE or NR can transmit in the same
R19A
time with the restiction of its MAX power.
While Plte-MAX + Pnr-MAX>Pmax, LTE TX power will be higher priority, and NR TX power = Pmax - Plte-
Max.
R19A
It is supported. R19A
Scheduler will dynamically perform traffic steering to 4G and 5G according to radio signal quality and loading
condition in 4G and 5G, so that load balance can be done.
Performance fain of load balance: Before load balance, data throughput at 4G = A, by apply DC and traffic R19A
load balance, throughput at 5G = B and throughput at 4G = A, max performance gain = B/A.
For LTE-NR NSA DC capable UE, if UE traffic volume threshold is satisfied, NR dual connectivity will be
enabled to improve UE throughput. Traffic volume threshold is configurable parameter. While multiple NR
R19A
cells can be configured for LTE and NR dual connectivity, NR cell with highest signal strength will be
selected as PSCell (Primary Secondary Cell), then NR will configure SCELL(Secondary Cell) in NR domain.
According to Huawei strategy, LTE and NR dual-connectivity relationship is related to LTE and NR cell
neighbourhood, standardized ANR (Auto Neighbour Relation) mechanism is required. But currently, NR ANR
mechanism is not specified at 3GPP. So currently, automatic solution of DC relationship is not available.
Currenlty LTE and NR dual-connectivity relationship needs manual configuration. LTE and NR dual-
connectivity relationship is dependent on LTE and NR cell neighbourhood: only those cells configured as
R19A
neighbour cells can be setup dual-connectivity relationship. Further, LTE and NR cell should have X2
interface so that enable signal and data transmission between LTE and NR cell.
In 5G RAN2.1, Huawei will consider automatic discovering and associating LTE and NR dual-connectivity
relationship, creating all required network data and interfaces to facilitate the dual connectivity relationship
automatically, and clean-up erroneously created or rarely used relationship.
Reply
attachment
Refer to word attachment R19A
for
28GHz.docx
The maximum delay requirements for the X2 interface is 20ms. The maximum delay doesn’t depend upon
the option used. The transmission delay of X2 interface will be considered when data splitting, so the impact R19A
of X2 interface delay on E2E application delay is small.

Huawei think that following information should be shared:

• Congestion status of interface between gNB and eNB;
• Transmission delay of interface between gNB and eNB;
• Throughput and remaining data transmission delay of RLC layer;
• The highest PDCP PDU sequence number successfully delivered in sequence to the UE among those
PDCP PDUs received from the MeNB;
R19A
• The highest PDCP PDU sequence number successfully delivered in sequence to the UE among those
PDCP PDUs received from the MeNB;
• The minimum desired buffer size in bytes for the UE;
• The X2-U packets that were declared as being "lost" by the corresponding eNB and have not yet been
reported to the eNB hosting the PDCP entity within the DL DATA DELIVERY STATUS frame.
Huawei will follow 3GPP specification after specification frozen.
Only non-GBR services is allowed traffic steering to NR. For traffic flow load balance: In stage 1, scheduler
will dynamically perform traffic steering to 4G and 5G according to radio signal quality and loading condition R19A
in 4G and 5G, so that load balance can be done.
For NSA architecture, QCI=1 and QCI=2 bearers are only created in 4G network. Currently 5G Voice over
R19A
NR and video over NR are still under discussion in 3GPP.
For carrier bandwidth of 200MHz, maximum CC number is 5.

R19A
R19A
R19A
3GPP definition.
R19A
3GPP definition.
R19A
3GPP definition.
R19A
3GPP definition.
R19A
R19A
Only RRC signaling based BW Part Activation/Deactivation is supported. R19A
Huawei supports inter-cell intra-site CoMP coordinated-scheduling for test purpose and commercial in future
version.
inter-cell intra-site CoMP includes SMP (Separate Multi-Point), DMP (Duplicated Multi-Point)，and UL
COMP.
UL inter-cell intra-site CoMP improves UL coverage by multi-TP joint reception.
R19A
conditions.
For inter-cell intra-site CoMP, the main scheduling procedure is:
Inter-cell inter -site CoMP coordinated-scheduling still under study and currently no plan.

Huawei supports NC-JT for test purpose and commercial in future version.
NC-JT is supported, which includes SMP (Separate Multi-Point), and DMP (Duplicated Multi-Point).
R19A
conditions.
Scenario limitation: Currently only intra-DU SMP/DMP is supported.
Huawei supports UL CoMP for test purpose and commercial in future version.
UL CoMP improves UL coverage by multi-TP joint reception.
For UL CoMP, the main scheduling procedure is:
1) Selects CoMP user R19A
Scenario limitation: Currently only intra-DU UL CoMP is supported.
Huawei currently doesn’t support dynamic point switching, it’s due to that Huawei thinks it’s mainly use for
dynamic load balance between TRPs. At 5G initial stage, NR cell load will be low dynamic point switching is
R19A
unlikely to provide obvious gain.
Huawei currently doesn’t support LTE and NR inter-RAT coordinated scheduling at DU level,, Huawei will
consider to support in future version.
LTE and NR inter-RAT coordinated scheduling at DU level typically use for LTE and NR spectrum sharing
R19A
case: LTE and NR operates at the same carrier or spectrum is overlapped. LTE and NR dynamically
negotiate spectrum resources allocation to make full use of spectrum or interference control related also can
be negotiated to reduce LTE-NR interference.
It is supported.
R19A
DMP (Duplicated Multi-Point) is single DCI based Multi-TRP NC-JT for PDSCH.
It is supported.
R19A
SMP (Separate Multi-Point) is multi-DCI based multi-TRP NC-JT for PDSCH.
Same as 3.5GHz R19A
Huawei 5G gNB will support energy efficiency solutions as following:
R19A
not contain any data to transmit, which can save about 15% power consumption of the RF module when
traffic is low (about 10%)
Several interference-management technologies are used.

A)Forward Error Correction technology: LDPC channel coding is used for data transmission and HARQ is
used for error packet retransmission, as defined in 3GPP 5G NR.
B) RB randomized scheduling: Since NR 3.5GHz has large bandwidth (100MHz), RB randomized scheduling
helps to reduce interference especially at eMBB and low load case.
C) DL MU-MIMO uses enhanced Zero Forcing to further reduce layer interference between users.
Huawei also consider following features in future version:

R19A
D) SMP (Separated Multiple Point) & DMP (Duplicated Multiple Point) are supported to improve transmission
robustness by multi-point transmission, meanwhile increase spectrum efficiency. SMP improves cell edge
UE throughput by multi-layer. DMP improves cell edge UE throughput by macro-diversity gain. FDL signal is
transmitted in multi-point for SMP/DPM, thus avoid other UE pararlell transmit in coordinated point, then
interference can be reduced, and useful signal is enhanced.
E) UL COMP is used to improve UL signal quality. UL Interference can be mitigated by IRC receiver.
F) Advanced receiver (Turbo receiver) is supported at base station to improve channel estimation accuracy
at poor SINR area.

Back
Product New Version
New Sub-Category Key word
Domain Category （Time）
Frame,
5G 5G NR Numerology 19A
Numerology
SS Block,
numerology
data, control,
numerology
Frame,
5G 5G NR Numerology 19B
Numerology
Frame,
Numerology
subcarrier
5G 5G NR Numerology 19A spacing,
frequency band
5G 5G NR Scalable Bandwidth 19A Bandwidth

5G 5G NR Scalable Bandwidth 19A Bandwidth
channel
5G 5G NR Scalable Bandwidth 19A
bandwdith
5G 5G NR Waveform 19A F-OFDM

PUSCH, DFT-S-
5G 5G NR Scheduling 19A OFDM, CP-
OFDM, waveform
PUCCH,DFT-S-
5G 5G NR Scheduling 19A OFDM,CP-
OFDM, waveform
Channel
5G 5G NR 19A
Management
Channel
5G 5G NR 19A
Management
Channel
5G 5G NR 19A
Management
Channel
5G 5G NR 19A
Management
Channel
5G 5G NR 19A
Management
Channel
5G 5G NR 19A
Management
Channel
5G 5G NR 19A
Management
Channel
5G 5G NR 19A
Management
Channel Preamble
5G 5G NR 19A
Management format,RACH
Channel
5G 5G NR 19A
Management

Channel
5G 5G NR 19A
Management
Channel
5G 5G NR 19A
Management
Channel
5G 5G NR 19A
Management
Channel
5G 5G NR 19A
Management

5G 5G NR scalable bandwidth 19A
Modulation
5G 5G NR 19A
Schemes
Modulation
5G 5G NR 19B
Schemes
Modulation
5G 5G NR 19A
Schemes
Modulation
5G 5G NR 19A
Schemes
Modulation
5G 5G NR 19B
Schemes
5G 5G NR Scheduling 19A
Modulation
5G 5G NR 19A
Schemes

Modulation
5G 5G NR 19A
Schemes
5G 5G NR Power Control 19A
5G 5G NR Power Control 19A
Modulation
5G 5G NR 19B
Schemes

Mobility
5G 5G NR 19A mobile speed
Management
Mobility high speed

5G 5G NR
Management solution
Mobility
5G 5G NR 19A session continuity
Management
Mobility intra frequency

5G 5G NR 19A
Management handover

Mobility inter frequency

5G 5G NR 19B
Management handover
Mobility Inter RAT

5G 5G NR 19B
Management handover
Mobility UE mobility
5G 5G NR 19A
Management management
Mobility UL handover,
5G 5G NR 19B
Management SINR
Mobility DL handover,
5G 5G NR 19B
Management RSRP
Mobility 120km/h,
5G 5G NR 19B
Management 500km/h
Radio QoS
5G 5G NR 19A
Management
Radio QoS
5G 5G NR 19A
Management
Radio QoS
5G 5G NR 19A
Management
Radio QoS
5G 5G NR 19A
Management
Radio QoS
5G 5G NR 19A
Management

Radio QoS
5G 5G NR 19A
Management
Radio QoS
5G 5G NR 19A
Management
Radio QoS
5G 5G NR 19A
Management
Radio QoS
5G 5G NR 19A
Management
Radio QoS
5G 5G NR 19A
Management
Radio QoS
5G 5G NR 19A
Management
Radio QoS
5G 5G NR 19A
Management
Radio QoS
5G 5G NR 19A
Management
Radio QoS
5G 5G NR 19A
Management
Radio QoS
5G 5G NR 19A
Management
Radio QoS
5G 5G NR 19A
Management
Radio QoS
5G 5G NR 19A
Management
Radio QoS
5G 5G NR 19A
Management
Radio QoS
5G 5G NR 19A
Management

DFT-OFDM,
5G 5G NR Waveform 19A
CP-OFDM
Modulation DFT-OFDM,
5G 5G NR 19B
Schemes CP-OFDM
load based
Mobility handover,
5G 5G NR 19B
Management LTE/WCDMA/GS
M
service based
5G 5G NR Mobility 19B handover,
Management
LTE/WCDMA/GSM
distance based
Mobility handover,
5G 5G NR 19B
M
coverage based
Mobility handover,
5G 5G NR 19B
M
Mobility
5G 5G NR 19B NSA mobility
Management

Mobility conditional
5G 5G NR 19B
Management handover
Mobility RRC inactive

5G 5G NR 19B
Management mode,NSA,SA
Mobility RRC inactive

5G 5G NR 19B
Management mode
Mobility
5G 5G NR 19B states transition
Management
Mobility
5G 5G NR 19B paging
Management
5G 5G NR scheduling 19B RB control
5G 5G NR scheduling 19B admission control

Mobility
5G 5G NR 19B mobility control
Management
resource
5G 5G NR scheduling 19B
allocation
resource
5G 5G NR scheduling 19B
management

Mobility
5G 5G NR 19B intra-NR
Management
5G 5G NR Scheduling 19B RB3
Modulation terminal
5G 5G NR 19B
Schemes categories



Frame Structure, Numerology：

30 KHz Subcarrier Spacing (SCS)
PC
Slot aggregation
Code Block Groups (CBG )
SS Block Numerology for 3.5GHz: 30KHz and 15KHz, Operator Configurable;
PC
For NSA: Indication via RRC for SCG
Data Channel & Control Channel Numerology for 3.5GHz: 30KHz and 15KHz,
PC
RRC configurable per UE
Grant-Free UL FC
mini slot NC
Please state the subcarrier spacing supported in the different frequency bands:
FC
700MHz, 2.6GHz, 3.5GHz
n78 (TD 3500), subcarrier spacing 30kHz, with 40, 50, 60, 70,80,90,100 MHZ
FC
BW
n257 (28 GHz), subcarrier spacing 120kHz, with 100, 200 MHZ BW FC
Please list your supported Channel Bandwidth for 3.5GHz FC
F-OFDM should be supported FC
DFT-S-OFDM should be suppported for PUSCH and dynamic switching from/to

FC
CP-OFDM.
DFT-S-OFDM should be suppported for PUCCH FC
PDCCH symbol number can be configured. FC
PDCCH symbol adaptation should be supported PC
PDCCH multi-user spatial multiplexing should be supported FC
PDCCH and PDSCH resource sharing should be supported: PDCCH unused

PC
RBs can be scheduled as PDSCH to transmit user data
DMRS type configuration should be supported FC
CSI-RS port number should be configurable FC
Preamble format 0 should be supported FC
Preamble format C2 should be supported FC
Supported preamble formats of RACH should be listed FC
Periodic SRS should be supported. Different period can be configurable. FC

Aperiodic SRS should be supported FC
Long PUCCH should be supported FC
Short PUCCH should be supported PC
Synchronization signal and PBCH frequency position should be configurable PC
SS Block Numerology for 3.5GHz: 30KHz and 15KHz, Operator Configurable;

PC
For NSA: Indication via RRC for SCG
Data Channel & Control Channel Numerology for 3.5GHz: 30KHz and 15KHz,
PC
RRC configurable per UE
Please list your supported Channel Bandwidth for 3.5GHz FC
Please state the subcarrier spacing supported in the different frequency bands:
FC
700MHz, 2.6GHz, 3.5GHz
DFT-S-OFDM should be suppported for PUSCH and dynamic switching from/to

FC
CP-OFDM
Intra Carrier Mixed Numerology FDM:
A) Support FDM for all combinations of all physical channels and RS in DL
when the numerologies are different between those. PC
B) Support FDM for all combinations of all physical channels and RS in UL
when the numerologies are different between those.
Inter Carrier Mix Numerology FDM:

PC
Different carrier can apply different numerology
Intra Carrier Mixed Numerology TDM:
Support TDM of different numerology, i.e. support the ability to change the
PC
numerology (from network perspective) from one slot to the next slot
dynamically.
Please state if multiple numerologies are supported on the same carrier

FC
bandwidth.
All slot formats that are specified in 3GPP NR should be supported PC
SS Block Periodicity: 5, 20, 40, 80, 160 msec should be supported, and it
FC
should be operator configurable per cell
SS Block Frequency Location: The location of the SS Block in the frequency
domain and offset from the PRB grid can be operator configured on a per cell PC
basis
What is the minimum guard period for switching between UL and DL parts of
FC
the frame do you recommend for 3.x GHz 5G NR for a macro cell?
Please list the supported TDD DL/UL configuration FC
The Supplier shall support self-contained slots, which can transmit downlink
FC
and uplink data in the same slot
The Supplier shall describe how the resultant intra-cell and inter-cell
interference can be managed in a macro-cell environment while apply self- FC
contain slots in multi-cell environment.

In order to optimize the system, bandwidth part shall be divided by UE and

PC
supported accordingly.
Bandwdith Part Configuration: Bandwdith part are UE specific and configured

FC
via RRC signaling
Maximum Number of BW Part Configured: Maximum suported by ASN.1. Only

FC
1 active BW part at a time
BW Part Activation/Deactivation: DCI based, Timer Based and RRC Signaling

PC
Based should be supported.
Bandwidth Adaptation (BA) function defined in 3GPP TS38.300 shall be

PC
supported.
The detailed algorithm, performance and schedule of application of commercial

network for operations with Bandwidth Adaptation (BA) functions applied, such
PC
as BA-based Initial Access operation and BA-based RRC_CONNECTED/DRX
in RRC_INACTIVE/RRC_IDLE mode shall be supported.
DL Data Channel Modulation: QPSK, 16QAM, 64QAM, 256QAM should be

FC
supported
UL Data Channel Modulation:pi/2 BPSK, QPSK, 16QAM, 64QAM should be

FC
supported
UL Data Channel Modulation: 256QAM should be supported FC
DL Control Channel Modulation: QPSK should be supported FC
UL Control Channel Modulation: pi/2 BPSK and QPSK should be supported FC
Number of HARQ Processes per CC FC
Maximum number of HARQ re-trnamsisison FC
Incremental Redundancy for HARQ retransmission should be supported FC
Chase Combining for HARQ retransmission should be supported FC
Dynamic optimal selection of MCS to suit instantaneous radio conditions of

FC
each UE

Dynamic optimal selection of control channel formats to suit instantaneous

FC
radio conditions of each UE
Dynamic selection of optimal beam and beam patterns, including beam

FC
tracking
Uplink power control should be supported FC
Uplink Power Control shall be provided and the setting of related parameters
FC
shall be possible, and detailed algorithms shall be suggested
Outer Loop Link Adaptation based on HARQ ACK/NACK Ratio FC
PDSCH allocation with 2 or 4 slot aggregation in a single DCI should be

PC
supported
PUSCH allocation with 4 slot aggregation in a single DCI should be supported PC
Please describe whether and how slot aggregation will be used and its impact
FC
on overheads and user plane latency.
Target BLER change function shall be provided: DL, and UL Target BLER for
PC
each QCI or 5QI is configurable
The gNB Scheduler shall support Proportional Fairness algorithm FC
The gNB Scheduler shall support Max C/I algorithm,which attempt to maximise
FC
overall cell throughput
The gNB Scheduler shall support Round Robin algorithm FC
The gNB Scheduler shall support equal rate algorithm PC
Manage contention between users both in the time domain and frequency
FC
domain

Detailed scheduling method shall be suggested considering CQI, Rank

Indication, Precision Matrix Indication (PMI) information, UE QoS requirements, FC
buffer status and Interference status transmitted from UE.
Guaranteed latency scheduling Abilty to guarantee the latency for latency

FC
sensitive services
Guaranteed Bit Rate scheduling Ability to guarantee throughput for services

FC
that requires GBR service
Minimum user bitrate can be guaranteed for non-GBR service. Minimum user
FC
bitrate is configurable.
UE speed for scheduling: scheduler selection based on UE speed FC
DL Frequency Selective Scheduling should be supported: frequency

PC
multiplexing UE for slot based scheduling
UL Frequency Selective Scheduling should be supported: frequency

FC
multiplexing UE for slot based scheduling
vendor should describe supported maximum mobile speed FC
Solutions shall suggested to improve service quality when moving at high

FC
speed/high-speed movement.
Session continuity: Data forwarding, in-sequence delivery and duplication

FC
avoidance
3.5GHz intra frequency handover should be supported. FC

3.5GHz & 3.5GHz or 3.5GHz & 28GHz inter frequency handover should be
PC
supported.
NR 3.5GHz and LTE inter RAT handover should be supported. FC
Vendor to describe 5G NR UE Mobility management(active and Idle) FC
NR Handover function considering UL quality shall be supported. NR handover

triggering threshold for the UL quality indicator shall be configurable (e.g. UL FC
SINR).
NR Inter/Intra frequency handover function trigger condition should consider UL

FC
quality as well as DL quality (e.g. RSRP, RSRQ).
In minimum 120 km/h moving environment, there shall be no performance

degradation caused by beamforming in both DU and UL directions, and up to
PC
the minimum 500 km/h moving environment, there shall be no Radio Link
Failure (RLF).
Vendor to indicate and describe 5G NR Quality of Service (QoS) support PC
Support all the QCIs (including mission critical QCIs) and ARPs defined by
3GPP to meet PDB and packet loss defined in 23.401 release 15 and 23.203 FC
release 15 except reserved ones.
Support QoS Parameters defined in 23.501, including 5QI, ARP for QoS flow
PC
and GFBR, MFBR and notification control for GBR QoS flow
Support ALL the standardized ( including but not limited to the mission critical
PC
5QI and V2X 5QI) and non-standardized 5QIs (Operator defined)
Support the 5G QoS characteristics and the standard 5QI to QoS

PC
characteristics mapping defined in 3GPP 23.501.

Support full ARP range defined by 3GPP Release 15 and beyond. FC
Support Operator Defined QCI Profile FC
Dynamic QoS modification, including QCI, ARP, UE AMBR, GBR/MBR, etc. FC
The (R)AN shall enforce Max BitRate (UE-AMBR) limit in UL and DL per UE for
FC
non-GBR QoS flows.
Support minimum bit rate for non-GBR bearer FC
Support both DL and UL QoS differentiation between different 5QI. PC
Support Guaranteed Bit Rate FC
Support RAN resource reservation(including baseband, radio and transport) for

PC
High Priority Access and Emergency
Vendor to describe 5G NR user differentiation at call admission FC
Admission control should be supported.Vendor to describe the mechanism. PC
Load balance between LTE/NR or within NR should be supported.Vendor to

FC
describe the mechanism.
Describe the relationship between QoS/Scheduler and slicing and what

FC
QoS/Scheduler features are required for RAN network slicing
Describe the strategy and QoS capabilities planned to differentiate operator's

PC
OTT service over others’.
Congestion control should be supported.Vendor to describe the mechanism. PC

The RAN supplier shall indicate the support of the DFT-precoded OFDM for UL
transmission and shall describe the mechanism or criteria that allows dynamic
switching of the UL transmission between OFDM and DFT-precoded OFDM FC
("Transform precoding" – TS 38.300). The expected coverage gain (vs UL
OFDM) inferred by the use of this precoding shall be indicated.
The RAN supplier shall indicate the support of the pi/2 BPSK UL modulation
scheme. The expected coverage gain inferred by the use of this modulation
FC
scheme shall be indicated (versus QPSK with transform precoding). What is
the envisioned use case?
The solution should support Load based Handover to and from

LTE/WCDMA/GSM.
如果客户方案是NSA则可以答复FC，因为NSA NR小区作为LTE辅小区，由LTE小区 PC
完成异系统切换，NR不涉及。
如果客户方案是SA，则5G RAN2.0仅支持基于覆盖的NR与LTE切换，NR与3G/2G切
换标准未定义
The solution should support Service based Handover to and from

LTE/WCDMA/GSM.
如果客户方案是NSA则可以答复FC，因为NSA NR小区作为LTE辅小区，由LTE小区 PC
完成异系统切换，NR不涉及。
如果客户方案是SA，则5G RAN2.0仅支持基于覆盖的NR与LTE切换，NR与3G/2G切
换标准未定义
The solution should support Distance based Handover to and from

LTE/WCDMA/GSM.
如果客户方案是NSA则可以答复FC，因为NSA NR小区作为LTE辅小区，由LTE PC
小区完成异系统切换，NR不涉及。
如果客户方案是SA，则5G RAN2.0仅支持基于覆盖的NR与LTE切换，NR与
3G/2G切换标准未定义。
The solution should support Coverage based Handover to and from

FC
LTE/WCDMA/GSM.
Please define what additional mobility functionality supported with the proposed
FC
solutions.

Please describe if your solution supports conditional handovers where the UE

FC
is sent the Handover command in advance of handover criteria.
Please describe which non standalone and standalone 5G Architecture Options

FC
are supported with RRC Inactive Mode.
Please provide information how RRC Inactive Mode will work in MR-DC, could
FC
RRC_INACTIVE be used where the eNB is the master node.
Support the RRC states transition & mobility for IDLE/RRC_INACTIVE/

FC
RRC_CONNECTED.
Please give an insight how RAN-initiated paging will function in your solution. FC
Vendor should describe Radio Bearer Control algorithm. FC
Vendor should describe Radio Admission Control algorithm. FC

Vendor should describe Connection Mobility Control algorithm. FC
Vendor should describe Dynamic allocation of resources to UEs in both uplink

FC
and downlink (scheduling) algorithm.
Vendor should describe the radio resource management algorithms for multi-
FC
carrier, multi-RAT, multi-layer and HetNet.

Vendor shall describe Intra-NR Mobility mechanism including UE in

FC
RRC_IDLE, RRC_INACTIVE and RRC_CONNECTED states.
In NSA system, present whether to support SRB3 and the supporting schedule
as defined in the 3GPP 38.331 Specification and explain the detailed operation NC
method.
Vendor shall include a table with the details of the categories FC

of terminals that support the modulations in 5G NR.

Response
Name
30 KHz Subcarrier Spacing (SCS) is supported；

Slot aggregation will plan on real demand;
Code Block Groups (CBG ) will be supported in 5G RAN2.1
Huawei supports 30KHz for 3.5GHz, and 15KHz is not supported.

It's not configurable.
Huawei supports 30KHz for 3.5GHz, and 15KHz is not supported. it's
not configurable.
19B才支持
暂无规划，
随项目申请
19A竞争力版
Huawei will support 15kHz subcarrier spacing for 700Mhz. 本支持
Huawei will support 30kHz subcarrier spacing for 2.6GHz. 3.5GHz
Huawei will support 30KHz subcarrier spacing for 3.5GHz eMBB 60KHz子载
service, and 60KHz for 3.5GHz URLLC service trial. 波间隔下
URLLC测试
please refer to feature : scalable bandwidth

please refer to feature : scalable bandwidth
40MHz,50MHz, 60MHz,80MHz, 100MHz
DFT-S-OFDM is supported for PUSCH. DFT-S-OFDM dynamic

switching from/to CP/OFDM is also supported.
PDCCH symbol number 1, 2, or 3 can be configured.
Huawei supports DMRS type 1 and DMRS type 2 configuration
Different CSI-RS port number can be configurable and CSI-RS port

adaptation according to UE capability is supported.
With frame structure 7 DL slots + 1 self-contained slot + 2 UL slots,

Preamble format 0 is supported.
With frame structure 3 DL slots + 1 self-contained slot + 2 UL slots

and 7 DL slots + 1 self-contained slot + 2 UL slots Preamble format
C2 is supported.

Preamble format 0&C2 are supported.
Preamble format C2 is supported.


Currently Huawei supports Synchronization signal and PBCH
locates at central frequency.
Huawei supports 30KHz for 3.5GHz, and 15KHz is not supported.
It's not configurable.
Huawei supports 30KHz for 3.5GHz, and 15KHz is not supported. it's
not configurable.
40MHz, 60MHz,80MHz, 100MHz
Huawei will support 15kHz subcarrier spacing for 700Mhz.
Huawei will support 30kHz subcarrier spacing for 2.6GHz.
Huawei will support 30KHz subcarrier spacing for 3.5GHz.
DFT-S-OFDM is supported for PUSCH. DFT-S-OFDM dynamic
switching from/to CP-OFDM is also supported.
Huawei supports multiple numerologies on the same carrier

bandwidth for URLLC:
In DL, broadcast channel applies 30kHz, and data channel applies
60kHz for 3.5GHz.
Huawei supports slot format 0/1/31/32/33/44. New slot formats can

be considered to support according to customer's requirement,
roadmap will be provided after frozen of the requirement.
SS Block frequency location is located at central frequency. And it's

fixed, not configurable.
For 3.x GHz 5G NR macro cell, the suggested minimum guard
period is 2 OFDM symbols for 30kHz sub-carrier spacing.
Huawei supports DL:UL configuration of 3 DL slots: 1 Self-contained
slot: 1 UL slot for commercial deployment.
Further, Huawei supports DL:UL configuration of 7 DL slots: 1 Self-
contained slot: 2 UL slots for commercial deployment.
Huawei support self-contained slots, which can transmit downlink
and uplink data in the same slot for TDD.
Huawei suggests the same configuration between different cells to

avoid interference caused by self-contained slot.

Currently, BWP definition in 3GPP hasn't frozen yet. Huawei will

follow 3GPP definition regarding BWP.
The technical advantages of applying BWP are mainly in the
folowing scenario according to 3GPP discussion:
Scenario 1: Supporting reduced UE BW capability
Scenario 2: Supporting reduced UE energy consumption by mean of
bandwidth adaptation.
Only RRC signaling based BW Part Activation/Deactivation is

supported.

Initial Access with intial-BWP is supported.
BA-based RRC_CONNECTED：When UE enter
RRC_CONNECTED mode, UE achieve power saving by BA.
Currently is not supported regarding BA-based RRC_CONNECTED,
supported version is TBD.
BA-based DRX in RRC_INACTIVE mode: main power saving effect
of UE is done by DRX mechanism. UE is not necessary to consider
BA during RRC_INACTIVE mode.
In RRC_IDLE mode, gNB releases UE context, gNB doesn't know
UE's state and capability, BA is not feasible and not supported by
standard.
R19A（256Q
AM trial）
pi/2 BPSK依
赖于UBBPg
19A只用于测
试
Both pi/2 BPSK and QPSK are supported.And Huawei will follow
3GPP definition for the support of pi/2 BPSK and QPSK, since pi/2 BPSK依
allowed modulation scheme may be different for different UL control 赖于UBBPg
channel format.
Huawei supports 16 HARQ processes per CC
The scheduler dynamically selects the optimal MCS according to the

instantaneous SINR in both downlink and uplink. An alpha filter is
used to avoid sudden unreasonable change of SINR:
filtered SINR =α* instantaneous SINR + (1-α) * historical SINR
Then optimal MCS can be selected accordingly.

In downlink, the scheduler selects the optimal aggregation level

dynamically for PDCCH according to channel quality for each UE.
In uplink, currently no control channel in uplink has designed flexible
control channel formats for the purpose of link adaptation, different
control channel formats normally for the purpose of different
feedback information requirement. Huawei will follow 3GPP
definition.
For 3.5GHz, digital beamforming is applied. Dynamic optimal beam

is generated according to UE PMI feedback or SRS feedback.
PRACH, PUSCH, PUCCH, and SRS signal support dynamic power

control in both NR and LTE side.
For NSA DC, uplink power control beteen LTE and NR can be
supported:
Semi-static power splitting between LTE and NR is supported.
Reply
attachment
for
3.5GHz.docx
The basic idea is single PDCCH scheduling multiple slot

PDSCH/PUSCH. The mainly benefits are saving PDCCH overheads
for following PDSCH slot. For example, the following slot has no
PDCCH symbol, so PDSCH will get more RE and decrease coding
rate.
3GPP allows aggregated slots transmit same TBS by repetition
method,by this way, both coding rate and overhead will be
significantly decreased. so slot aggregation also can have benefits
on coverage/reliability.
Huawei supports downlink target IBLER configurable ,but it's not per
QCI/5QI basis.
It's supported.
The EPF(Enhanced Proportional Fair) priority takes both channel
quality and fairness into account, which is expressed as follows
Prio = (eff_cqi^alpha)/(avg_rate^beta)*gamma_conn*gamma_ue
where eff_cqi denotes the channel quality reflected by CQI, alpha
denotes the corresponding factor, avg_rate denotes the filtered
average transmit rate, beta denotes the corresponding factor,
gamma_conn denotes the weight factor for connection and
considers the delay and QCI for the connection, and gamma_ue
denotes the weight factor for UE.
It's supported.
It's supported.
In time domain, UEs are sorted according to EPF priority. In

frequency domain, the scheduler assigns RBs for UEs considering
each UE’s priority and data size.
With above mechanism, contention between users can be managed
in both downlink and uplink.

For the Single-User MIMO scheduling, each RBG is allocated to the
725345634.xlsx
UE with highest priority, where the priority takes the fairness and 文档密级
QoS into account.
The Single-User MIMO rank is obtained from the CSI feedback or
the Single-User MIMO rank adaption in gNB side.
The downlink beamforming weight can be SRS-based or PMI-based
according to the adaptive weight algorithm. For the SRS weight, it is
obtained from the singular value decomposition of frequency channel
matrix estimated from SRS with uplink-downlink reciprocity. For the
precise PMI weight, it adjusts the amplitude and phase of beams and
it is feedback from UE.
The final transmit MCS is calculated considering the CQI, Single-
User MIMO rank and BF gain, and adjusted by Single-User MIMO
OLLA offset. The number of RBGs allocated to a UE is determined
by the traffic buffer and MCS, and the TBS is obtained by MCS and
number of RBs.
For the Multi-User MIMO scheduling, more than two UEs can be
paired on a RBG. The UEs with low correlation and well beam
separation can be paired once there is sum proportional fairness
(PF) gain. The Multi-User MIMO MCS for the paired UEs is
calculated considering the SU SINR, total paring layers and the
paring SINR loss, and adjusted by Multi-User MIMO OLLA offset.
The TBS for each Multi-User MIMO UE is obtained by Multi-User
MIMO MCS and number of RBs.
It's supported. UEs are identified as "stationary", "moving" or "high

speed" status, and different scheduling strategy will be selected
accordingly.
150km/h
Huawei provides solution for doppler shift correction so that to

minimize impact of doppler shift.
The gNB enabled with the high speed mobility solution use AFC to
correct frequency offsets, thereby minimizing the impact of Doppler
shift. They can also adopt appropriate random access preambles
and scheduling parameters to improve system performance
Initial frequency correction
During the random access of UEs, gNB detects frequency shifts by
using preamble and performs initial frequency correction.
Continuous frequency correction
The gNB performs continuous frequency correction after UEs access
the network. The gNB estimates frequency shifts based on UE pilot
signals and uses the results as the continuous inputs to the
frequency correction function.
Initial frequency correction broadly adjusts the frequency whereas
continuous frequency correction fine-tunes it.
When a UE that has accessed the network experiences a sudden
change in channels, fine-tuning may fail to trace the frequency
change. This may result in consecutive failures to decode uplink
data. In this case, gNB searches for the frequency shift to ensure
correct demodulation and decoding of uplink data.
For NSA, handover only happened in LTE, NR is not involved in

handover.
For SA, Supported version is 5G RAN2.1.


handover.
For SA, currently 3.5GHz & 3.5GHz interfrequency handover is
supported, while 3.5GHz & 28GHz inter-frequency handover is not
supported yet.

handover.
For SA, currently it's not supported. Supported version is TBD.
Reply
attachment
See attachment for detail
for
3.5GHz.docx
NR handover should based on SA.

Supported version is 5G RAN2.1.
In the early 5G network deployment, UL quality will be good
because of light load, so considering DL quality is enough for
handover . but when UE number becomes more, the UL quality
becomes worse because of interference in future, Huawei will
support handover based on UL quality and DL quality.
NR Inter/Intra frequency handover should based on SA. Currently it's

not supported. Supported version is 5G RAN2.1.
DL quailty will be considered as handover trigger condition.
In the early 5G network deployment, UL quality will be good
because of light load, so considering DL quality is enough for
handover . but when UE number becomes more, the UL quality
becomes worse because of interference. In future, Huawei will
support handover based on UL quality and DL quality.
In minimum 120 km/h moving environment, performance

degradation caused by beamforming in both DU and UL directions is
strong related to environment.
For DL: In LOS environment where channel change very slowly,
performance degradation will be smaller. In NLOS environment,
performance degradation will be relatively higher compared with
LOS.
In minimum 500 km/h moving environment, Huawei will satisfy call
success rate defined in 3GPP. Radio link can be maintained after
success connection to network in good coverage area and without
any UE exceptional behavior.
Currently, SA is not supported by Huawei.

In next version, When SA is supported, Huawei considers to support:
1. Both DL and UL QoS differentiation between 5QI/5QI+ARP.
2. Qos flow mapping to radio bearer configuration.
3. Operator defined non-standardized 5QI.
4. Reflective QoS control.
5. Support minimum bit rate for non-GBR bearer
6. GFBR,MFBR guarantee and UE-AMBR rate limitation
7. Compatible to NSA architecture
5QI is defined on SA. 5QI related currently is not suppported.





In access control stage, gNB reserve some UE number resources

for emergency and high priority access call, these users have higher
access success rate.
Huawei admission control support:
1．Emergency call (based on EstablishmentCause) have reserved
resource at call admission stage
2．High priority ue(according to ARP value or EstablishmentCause)
have more opportunity to preemption other UE in order to protect the
successful rate of such users .
For NSA:
Huawei 4G performs admission control during RRC connection
setup or handover. Since RRC signalling is only in 4G, admission
control will only in 4G under dual connectivity mode.
For SA:
The gNB checks whether user number specifications and user
number license limitation are achieved when a UE requests to setup
a radio resource control (RRC) connection or requests an handover-
in. If achieved the limitation, the gNB temporarily stopped
RRC access request response:
• if preemption function switched on, gNB will initiate user
preemption procedure. User Preemption select is based on ARP and
other information, if the preemption succeeds, the preempted users
will be released to ensure the preferential admission of privileged
UEs RRC access successful rate.
Preempt users continue to complete RRC access
• if preemption function switched off, UE RRC setup failure.
Admission control for SA supported version is TBD.
Huawei product supports load balancing by Dual connectivity(DC)

and Carrier Aggregation(CA) to do traffic flow-split.
if cell is still overloaded, some low ARP priority users will be selected
to do redirection/handover to reduce serving cell load.
Reply
attachment
See attachment for detail
for
3.5GHz.docx
Calculate the cell resource utilization which only provide the basic
tolerant rate for each UE, if the resource utilization exceed a
threshould, gNB will select some large amount data transfer and low
priority users to handover out. Whether users on this bearer are
allowed to transfer out can be configured by operator.
Based on the above machanism, if eNB CPU load still exceed the
overload threshold, some paging or other RRC message will be flow
controled.
Congestion control supported version is TBD.

Huawei supports CP-OFDM and DFT-S-OFDM Adaptation. The

network side instructs a UE to select a proper CP-OFDM or DFT-S-
OFDM waveform based on the radio environment and the selected
threshold (THA or THB). An anti-pingpong mechanism is also
adopted when the uplink SINR ranges between the two thresholds,
and the switchover between the two waveforms is performed by
RRC signaling reconfiguration.
• When the uplink SNR is greater than THA, the UE selects CP-
OFDM.
• When the uplink SNR is lower than THB and rank is 1, the UE
selects DFT-S-OFDM.
• If the SNR ranges between THA and THB, the waveform remains
unchanged.
UL coverage may be improved 1dB by the use of this precoding.
Both pi/2 BPSK and QPSK are supported. Huawei will follow 3GPP
definition for the support of pi/2 BPSK and QPSK, since allowed
modulation scheme may be different for different UL control channel pi/2 BPSK依
format. 赖于UBBPg单
板
pi/2 BPSK is applied to far point that UE power limited scenario,
which may improve uplink coverage 0.5dB compared to QPSK.
For NSA dual connectivity, there is no handover between 5G and

LTE/WCDMA/GSM. LTE Load based handover to and from
WCDMA/GSM is supported.
For SA, 5G NR coverage based handover to and from LTE is
supported already in 5G RAN2.1.
Huawei will support 5G NR load based handover to and from
LTE/WCDMA/GSM when 3GPP is fully frozen and released.
For NSA dual connectivity, there is no handover between 5G

and LTE/WCDMA/GSM. LTE Service based handover to and from
WCDAM/GSM is supported.
5G NR QCI based handover to and from LTE is supported
already in 5G RAN2.1.
Huawei will support 5G NR load based handover to and from

LTE/WCDMA/GSM.
5G NR coverage based handover to and from LTE is supported
Huawei will support 5G NR distance based handover to and from

LTE/WCDMA/GSM.
5G NR coverage based handover to and from LTE is supported
Huawei will support 5G NR distance based handover to and from
In NSA, terminal RRC connectivity is maintained in LTE. Only when

LTE is connected, NR user plane can be connected. For LTE-NR
NSA DC capable UE, NR connection will be triggered if LTE state
transit from idle to connected mode. After a specific timer and
there’s no data transmission, NR connectivity will be released. After
NR connection release, If UE has data traffic and traffic volume
threshold is satisfied, NR connectivity will be setup again to improve
UE throughput. Traffic volume threshold is configurable parameter.
Further, if NR signal is weak or RLF, NR connectivity will be
released.

Generally, handover is based on coverage. Besides, service-based

handover has been introduced in 5G. The principle is as follows:
The base station configures a handover attribute for different service
types, and sends a handover command according to the service type
(QCI type) and the handover attribute of the service.
Huawei can fully support LNR->LTE handover in RAN2.1, and plans
LTE->NR handover in RAN3.0.
In NSA architecture, RRC Inactive Mode will the same as 4G. In SA

architecture, Huawei supports RRC Inactive Mode in RAN2.1 based
on option2.
For MR-DC, Huawei understands as option3x architecture, in NSA,

the RRC states will be the same as 4G.
In NSA, the RRC states will be the same as 4G.

In SA, 5G terminal supports 3 different states: connected state,
inactive state and idle state. State transition from connected to
inactive, from inactive to idle, and from idle to connected are all
supported.
When UE is in inactive situation, DL data and signaling trigger the
RAN-initiated paging, the signaling flow will follow TS38.300
protocol.
Differentiated bearer establishment and management.

When a UE initiates a service setup request, the gNodeB binds the
service to a proper bearer based on the QoS attributes, such as QoS
class identifier (QCI) parameters and QCI characteristics. In
addition, an operator can adjust Packet Data Convergence Protocol
(PDCP), Radio Link Control (RLC), and Media Access Control
(MAC) parameters for each bearer as required.
After the bearer is established, differentiated scheduling is provided
based on the settings of each bearer's parameters, channel quality,
and history rate to satisfy the QCI characteristics of each bearer in
table 6.1.7-A "Standardized QCI characteristics" in the 3GPP TS
23.203 protocol. For guaranteed bit rate (GBR) services, GBR
guarantee and maximum bit rate (MBR) limitation are supported. For
non-GBR services, the limitation on aggregate maximum bit rates
(AMBR) for UEs and minimum rate guarantee are supported.
For Admission control, The gNodeB supports admission control

based on the UE number specifications, licensed UE number, and
scheduling request indicator (SRI) resources. When the number of
admitted UEs or the amount of occupied resources exceeds a
specified threshold, no UE is allowed to access the network. This
ensures user experience and maintains device stability.

For the SA architecture, an intra-frequency coverage basedhandover
consists of the following phases:
Measurement phase
The UE performs measurements according to the measurement
configuration delivered from the gNodeB. When the signal quality in
at least one intra-frequency neighboring cell meets the configured
triggering condition of event A3, the UE sends the measurement
result to the gNodeB.
Decision phase
The gNodeB generates a list of candidate cells and makes a
handover decision based on the measurement result.
Execution phase
The handover from the serving cell to the target cell is executed.
For NSA EN-DC Mobility Management
Intial Access
UE do attach and access the LTE cell in MeNB#1
SgNB Addition
When UE access the LTE cell, then eNB trigger SgNB addition
procedure, add NR cell as SgNB.
SgNB modification
When UE move to the edge of Pscell, UE send A3 report to SgNB#1
to change the Pscell in the same SgNB#1.
SgNB Change
When UE move to the edge of SgNB#1, UE send the A3 report to
SgNB#1 to do SgNB change from SgNB#1 to SgNB#2.
MN HO with/without SN Change
When UE move to the edge of MeNB#1, then do MN HO from
MeNB#1 to MeNB#2, if UE is not out of coverage of SgNB2 and
SgNB#2 has DC neighbor cell with MeNB2 then do MN HO without
SN change, else do MN HO with SN change.
SgNB Release
When UE move to the edge of SgNB#2 and had no other SgNB
coverage, then do the SgNB release.
The gNodeB selects the most suitable frequency band resources for
UEs based on channel quality differences. The scheduler sets a
sliding window width to determine the number of RBs required by
each UE and selects a resource combination that delivers the
maximum expected gain in the window. The frequency selective
scheduling allows UEs to transmit data on the subband with good
The radioquality
channel resource management
when of CA is fading
frequency selective as below:
occurs on the uplink
CA level thereby increasing uplink throughput.
channel,
eNodeB divides source data traffic into 2CCs (details on next page)
Step1: eNodeB always divides source data (in RLC buffer) into 2CC
as 1:1, even though bandwidths are different
Step2a: If each carrier can afford its data transmission, eNodeB will
continue in next TTI repeating Step 1
Step2b: If one of the carriers cannot afford its data transmission (e.g.
heavy load), then eNodeB will allocate next TTI’s source data plus
the un-transmitted data, which is also divided into 2CCs as 1:1
CC level
eNodeB calculates non-GBR scheduling priority in each CC.
Two different policies may apply:
Fairness Scheduling: CA UE as a single user in priority calculation
Differentiation Scheduling: each CC calculates priority individually
(CA UE is taken as two individual UE
For Hetnet senario, it is suggested to camp on higher frequency with
larger bandwidth preferentially. UE handover to lower frequency
when the coverage of higher frequency is limited.
The radio resource management of multi-RAT is as below:
1. Cell reselection algorithm for interworking of 4G and 5G,
according to 36.304 and 38.304
2. Handover algorithm for interworking of 4G and 5G, according to
36.331, 36.413, 38.331 and 38.413
3. Redirection algorithm for interworking of 4G and 5G, according to
36.331 and 38.331
4. NR voice fall back to 4G algorithm, according to 36.331, 36.413,
38.331 and 38.413.

In NSA, terminal RRC connectivity is maintained in LTE. Only when

LTE is connected, NR user plane can be connected. For LTE-NR
NSA DC capable UE, NR connection will be triggered if LTE state
transit from idle to connected mode. After a specific timer and
there’s no data transmission, NR connectivity will be released. After
NR connection release, If UE has data traffic and traffic volume
threshold is satisfied, NR connectivity will be setup again to improve
UE throughput. Traffic volume threshold is configurable parameter.
Further, if NR signal is weak or RLF, NR connectivity will be
released.
5G terminal operation in NSA is available now. In SA, 5G terminal
supports 3 different states: connected state, inactive state and idle
state. State transition from connected to inactive, from inactive to
idle, and from idle to connected are all supported. Typically, a
connected UE will transit to inactive while a specific timer T1 is time
out and no data transmission happened within this duration. And
inactive UE will transit to idle while another specific timer T2 is time
out. UE in inactive state will transit to connected again while UE
needs to send UL traffic or RAN-based paging is received.
Currently Huawei solution does not support SRB3. The SRB3

signaling on NR side is forwarded to the UE through LTE air “Call Setup
interface; it does not affect the sending of the UE measurement Flow with
report and the reception of the reconfiguration message. The direct RB3”
SRB3 function between SN and UE is under planning.
UE-NR-Capability in RRC message indicates the modulation

scheme. Please refer to standard 3GPP 38331-6.3.3.
UE will report whether it supports 256QAM in downlink and uplink. If
the UE supports 256QAM, max modulation is 256QAM otherwise the
max modulation is 64QAM.


Back Back
Key word
5G 5G NR Numerology 19A Numerology


Modulation
5G 5G NR 19A Modulation Schemes
Schemes
Modulation
Schemes
Modulation
Schemes
Modulation
Schemes
Modulation
Schemes
scalable
5G 5G NR 19A scalable bandwidth
bandwidth
scalable
bandwidth
scalable
bandwidth

scalable
bandwidth
scalable
bandwidth
scalable
bandwidth
5G 5G NR scheduling 19A scheduling

5G 5G NR scheduling scheduling
Mobility
5G 5G NR 19A Mobility Management
Management

Mobility
Management
Mobility
Management
Mobility
Management
Mobility
Management
Mobility
Management
Mobility
Management
Radio QoS Radio QoS

5G 5G NR 19A
Management Management
Channel Preamble
5G 5G NR 19A
Management format,RACH

SS Block Numerology: 120KHz and 240KHz, Operator

PC
Configurable; For NSA: Indication via RRC for SCG
Data Channel & Control Channel Numerology: 120KHz and
PC
60KHz, RRC configurable per UE
Channel Bandwidth:50MHz, 100MHz, 200MHz, 400MHz should be
PC
supported.
DFT-S-OFDM should be suppported for PUSCH and dynamic
FC
switching from/to CP-OFDM
Intra Carrier Mixed Numerology FDM:
A) Support FDM for all combinations of all physical channels and
RS in DL when the numerologies are different between those. PC
B) Support FDM for all combinations of all physical channels and
RS in UL when the numerologies are different between those.
Inter Carrier Mix Numerology FDM:

PC
Different carrier can apply different numerology
Intra Carrier Mixed Numerology TDM:
Support TDM of different numerology, i.e. support the ability to
PC
change the numerology (from network perspective) from one slot
to the next slot dynamically.
All slot formats that are specified in 3GPP NR should be supported FC
All slot formats that are specified in 3GPP NR should be supported FC
SS Block Periodicity: 5, 20, 40, 80, 160 msec should be supported,
FC
and it should be operator configurable per cell
Please list the supported TDD DL/UL configuration FC
The Supplier shall support self-contained slots, which can transmit

FC
downlink and uplink data in the same slot
The Supplier shall describe how the resultant intra- and inter-cell
interference can be managed in a macro-cell environment while FC
apply self-contain slots in multi-cell environment.
DL Data Channel Modulation: QPSK, 16QAM, 64QAM, 256QAM
FC
should be supported
UL Data Channel Modulation:pi/2 BPSK, QPSK, 16QAM, 64QAM

FC
should be supported
UL Data Channel Modulation: 256QAM should be supported PC
DL Control Channel Modulation: QPSK should be supported FC
UL Control Channel Modulation: pi/2 BPSK and QPSK should be

FC
supported
In order to optimize the system, bandwidth part shall be divided by

PC
UE and supported accordingly.
Bandwdith Part Configuration: Bandwdith part are UE specific and

FC
configured via RRC signaling
Maximum Number of BW Part Configured: Maximum suported by

FC
ASN.1. Only 1 active BW part at a time

BW Part Activation/Deactivation: DCI based, Timer Based and

PC
RRC Signaling Based should be supported.
Bandwidth Adaptation (BA) function defined in 3GPP TS38.300

PC
shall be supported.
The detailed algorithm, performance and schedule of application of

commercial network for operations with Bandwidth Adaptation (BA)
functions applied, such as BA-based Initial Access operation and PC
BA-based RRC_CONNECTED/DRX in
RRC_INACTIVE/RRC_IDLE mode shall be supported.
Number of HARQ Processes per CC FC
Maximum number of HARQ re-trnamsisison FC
Incremental Redundancy for HARQ retransmission should be

FC
supported
Chase Combining for HARQ retransmission should be supported FC
Dynamic optimal selection of MCS to suit instantaneous radio

FC
conditions of each UE
Dynamic optimal selection of control channel formats to suit

FC
instantaneous radio conditions of each UE
Dynamic selection of optimal beam and beam patterns, including

FC
beam tracking
Uplink power control should be supported FC
Uplink Power Control shall be provided and the setting of related

parameters shall be possible, and detailed algorithms shall be FC
suggested
Outer Loop Link Adaptation based on HARQ ACK/NACK Ratio FC
PDSCH allocation with 2 or 4 slot aggregation in a single DCI

PC
should be supported
PUSCH allocation with 4 slot aggregation in a single DCI should

PC
be supported
Please describe whether and how slot aggregation will be used

FC
and its impact on overheads and user plane latency.

Target BLER change function shall be provided: DL, and UL

PC
Target BLER for each QCI or 5QI is configurable
The gNB Scheduler shall support Proportional Fairness algorithm FC
The gNB Scheduler shall support Max C/I algorithm,which attempt

FC
to maximise overall cell throughput
The gNB Scheduler shall support Round Robin algorithm FC
The gNB Scheduler shall support equal rate algorithm PC
Manage contention between users both in the time domain and

FC
frequency domain
Detailed scheduling method shall be suggested considering CQI,

Rank Indication, Precision Matrix Indication (PMI) information, UE
FC
QoS requirements, buffer status and Interference status
transmitted from UE.
Guaranteed latency scheduling Abilty to guarantee the latency for

FC
latency sensitive services
Guaranteed Bit Rate scheduling Ability to guarantee throughput for

FC
services that requires GBR service
Minimum user bitrate can be guaranteed for non-GBR service.

FC
Minimum user bitrate is configurable.
UE speed for scheduling: scheduler selection based on UE speed FC
DL Frequency Selective Scheduling should be supported:

PC
frequency multiplexing UE for slot based scheduling
UL Frequency Selective Scheduling should be supported:

FC
frequency multiplexing UE for slot based scheduling
vendor should describe supported maximum mobile speed FC

Solutions shall suggested to improve service quality when moving

FC
at high speed/high-speed movement.
Session continuity: Data forwarding, in-sequence delivery and

FC
duplication avoidance
28GHz intra frequency handover should be supported. FC
28GHz & 3.5GHz or 3.5GHz & 28GHz inter frequency handover

FC
NR 28GHz and LTE inter RAT handover should be supported. FC
Vendor to describe 5G NR UE Mobility management(active and

FC
Idle)
Same as 3.5GHz
Supported preamble formats of RACH should be listed FC

Response
Name
Huawei supports 120KHz for SS Block transmission.
240KHz is not supported. it's not configurable.
120KHz is supported, and 60KHz is not supported. it's not configurable.
100MHz and 200MHz are supported. 50MHz & 400MHz are not supported.
DFT-S-OFDM is supported for PUSCH. DFT-S-OFDM dynamic switching from/to

CP/OFDM is also supported.
DFT-S-OFDM should be suppported for PUCCH
F-OFDM should be supported
All slot formats that are specified in 3GPP NR should be supported

All slot formats that are specified in 3GPP NR should be supported
SS Block Periodicity: 5, 20, 40, 80, 160 msec should be supported, and it should be
operator configurable per cell
Huawei supports DL:UL configuration of 3 DL slots: 1 Self-contained slot: 1 UL slot for
commercial deployment.
Huawei support self-contained slots, which can transmit downlink and uplink data in the
same slot for TDD.
Huawei suggest the same configuration between different cells to avoid interference
caused by self-contain slot.
DL Data Channel Modulation: QPSK, 16QAM, 64QAM, 256QAM should be supported
UL Data Channel Modulation:pi/2 BPSK, QPSK, 16QAM, 64QAM should be supported
DL Control Channel Modulation: QPSK should be supported
Both pi/2 BPSK and QPSK are supported.And Huawei will follow 3GPP definition for the
support of pi/2 BPSK and QPSK, since allowed modulation scheme may be different for
different UL control channel format.
Currently, BWP definition in 3GPP hasn't frozen yet. Huawei will follow 3GPP definition
regarding BWP.
The technical advantages of applying BWP are mainly in the folowing scenario according
to 3GPP discussion:
Scenario 1: Supporting reduced UE BW capability
Scenario 2: Supporting reduced UE energy consumption by mean of bandwidth
adaptation.
Bandwdith Part Configuration: Bandwdith part are UE specific and configured via RRC
signaling
Maximum Number of BW Part Configured: Maximum suported by ASN.1. Only 1 active

BW part at a time

Only RRC signaling based BW Part Activation/Deactivation is supported.
Initial Access with intial-BWP is supported.

BA-based RRC_CONNECTED：When UE enter RRC_CONNECTED mode, UE achieve
power saving by BA. Currently is not supported regarding BA-based
RRC_CONNECTED, supported version is TBD.
BA-based DRX in RRC_INACTIVE mode: main power saving effect of UE is done by
DRX mechanism. UE is not necessary to consider BA during RRC_INACTIVE mode.
In RRC_IDLE mode, gNB releases UE context, gNB doesn't know UE's state and
capability, BA is not feasible and not supported by standard.
Huawei supports 16 HARQ processes per CC
The scheduler dynamically selects the optimal MCS according to the instantaneous SINR
in both downlink and uplink. An alpha filter is used to avoid sudden unreasonable change
of SINR:
filtered SINR =α* instantaneous SINR + (1-α) * historical SINR
Then optimal MCS can be selected accordingly.
In downlink, the scheduler selects the optimal aggregation level dynamically for PDCCH
according to channel quality for each UE.
In uplink, currently no control channel in uplink has designed flexible control channel
formats for the purpose of link adaptation, different control channel formats normally for
the purpose of different feedback information requirement. Huawei will follow 3GPP
definition.
For mmWave, hybrid beamforming is applied, and beam tracking mechanism is used to
dynamically select optimal analog beam according to UE feedback. Optimal digital
beamforming also can be generated according to UE PMI feedback or SRS feedback.
PRACH, PUSCH, PUCCH, and SRS signal support dynamic power control in both NR
and LTE side.
For NSA DC, uplink power control beteen LTE and NR can be supported:
Semi-static power splitting between LTE and NR is supported.
Reply
attachment
for
28GHz.docx

The basic idea is single PDCCH scheduling multiple slot PDSCH/PUSCH. The mainly
benefits are saving PDCCH overheads for following PDSCH slot. For example, the
following slot has no PDCCH symbol, so PDSCH will get more RE and decrease coding
rate.
3GPP allows aggregated slots transmit same TBS by repetition method,by this way, both
coding rate and overhead will be significantly decreased. so slot aggregation also can
have benefits on coverage/reliability.

Huawei supports downlink target IBLER configurable ,but it's not per QCI/5QI basis.
It's supported.
The EPF(Enhanced Proportional Fair) priority takes both channel quality and fairness
into account, which is expressed as follows
Prio = (eff_cqi^alpha)/(avg_rate^beta)*gamma_conn*gamma_ue
where eff_cqi denotes the channel quality reflected by CQI, alpha denotes the
corresponding factor, avg_rate denotes the filtered average transmit rate, beta denotes
the corresponding factor, gamma_conn denotes the weight factor for connection and
considers the delay and QCI for the connection, and gamma_ue denotes the weight
factor for UE.
It's supported.
It's supported.

In time domain, UEs are sorted according to EPF priority. In frequency domain, the
scheduler assigns RBs for UEs considering each UE’s priority and data size.
Withthe
For above mechanism,
Single-User MIMOcontention between
scheduling, usersiscan
each RBG be managed
allocated in both
to the UE withdownlink
highest and
uplink. where the priority takes the fairness and QoS into account.
priority,
The Single-User MIMO rank is obtained from the CSI feedback or the Single-User MIMO
rank adaption in gNB side.
The downlink beamforming weight can be SRS-based or PMI-based according to the
adaptive weight algorithm. For the SRS weight, it is obtained from the singular value
decomposition of frequency channel matrix estimated from SRS with uplink-downlink
reciprocity. For the precise PMI weight, it adjusts the amplitude and phase of beams and
it is feedback from UE.
The final transmit MCS is calculated considering the CQI, Single-User MIMO rank and
BF gain, and adjusted by Single-User MIMO OLLA offset. The number of RBGs allocated
to a UE is determined by the traffic buffer and MCS, and the TBS is obtained by MCS
and number of RBs.
For the Multi-User MIMO scheduling, more than two UEs can be paired on a RBG. The
UEs with low correlation and well beam separation can be paired once there is sum
proportional fairness (PF) gain. The Multi-User MIMO MCS for the paired UEs is
calculated considering the SU SINR, total paring layers and the paring SINR loss, and
adjusted by Multi-User MIMO OLLA offset. The TBS for each Multi-User MIMO UE is
obtained by Multi-User MIMO MCS and number of RBs.
It's supported. UEs are identified as "stationary", "moving" or "high speed" status, and
different scheduling strategy will be selected accordingly.
150km/h

Huawei provides solution for doppler shift correction so that to minimize impact of
doppler shift.
The gNB enabled with the high speed mobility solution use AFC to correct frequency
offsets, thereby minimizing the impact of Doppler shift. They can also adopt appropriate
random access preambles and scheduling parameters to improve system performance
Initial frequency correction
During the random access of UEs, gNB detects frequency shifts by using preamble and
performs initial frequency correction.
Continuous frequency correction
The gNB performs continuous frequency correction after UEs access the network. The
gNB estimates frequency shifts based on UE pilot signals and uses the results as the
continuous inputs to the frequency correction function.
Initial frequency correction broadly adjusts the frequency whereas continuous frequency
correction fine-tunes it.
When a UE that has accessed the network experiences a sudden change in channels,
fine-tuning may fail to trace the frequency change. This may result in consecutive failures
to decode uplink data. In this case, gNB searches for the frequency shift to ensure
correct demodulation and decoding of uplink data.
For NSA, handover only happened in LTE, NR is not involved in handover.



Reply
attachment
for
28GHz.docx
Same as 3.5GHz
With frame structure 3 DL slots + 1 self-contained slot + 2 UL slots, Preamble format C2

is supported.

Back
Key word *Question
1. The proposer shall present the MVI function

development plan (Roadmap) by dividing it into major
MVI period (hereinafter referred to as “reference time”) and
function，de system section (hereinafter referred to as “interface”).
5G 5G Others IoT 19A
ployment However, setting of the reference time shall be base on
plan the time to be verified by End to End system level, rather
than the completion of development at the individual
node.
Support OCNS (OFDM Cell Noise Simulator) on

PDCCH and PDSCH: The 5G RAN shall include
Cell non-
OCNA,OFD functionality to artificially load cells for performance
performance
5G 5G Others 19A M cell noise benchmarking, and functionality for conformance testing
related
simulator at the maximum radiated power of the radio unit.
functions
Do you have any functional restriction on your current

LTE equipment in case the NR supplier is a third party
LTE，NR，t Supplier? Please describe in detail what the NR
hird party equipment has to fulfill to ensure full interoperability with
an 3rd party LTE supplier.
Do you have any functional restriction on the overall

LTE，NR，t performance if the LTE supplier is a third party supplier.
hird party Please describe in detail what the LTE equipment
supplier has to fulfill to ensure full interoperability.
Support OCNS (OFDM Cell Noise Simulator) on

Cell non- PDCCH and PDSCH: The 5G RAN shall include
OCNA,OFD
performance functionality to artificially load cells for performance
5G 5G Others 19A M cell noise
related benchmarking, and functionality for conformance testing
simulator
functions at the maximum radiated power of the radio unit.
The real-time monitoring function for details of traffic,

Counter &
5G 5G Others 19A monitor noise, and quality for each RB band and the notification
KPI
function shall be supported.
The functions to collect data automatically at intervals of

1 minute, 5 minutes, 15 minutes and 1 hour according to
data
Counter & performance statistics item and to collect data for a
5G 5G Others 19A collection
KPI certain period time upon the operator's request shall be
period
supported. (It should be intuitively identifiable such as
XML.TEXT.)

There shall be a function to collect and report the

following performance data, and the collection of data
shall be subdivided into gNB, cell unit, co-location cell
unit, and frequency unit.
a) Traffic-related performance Data for each service
· Data Call Incoming/Outgoing related Data
· Handover related Data
· Paging related Data (include Paging Discard)
· Discarded Call Statistics according CAC
Counter & performance · Location Registration related Data
5G 5G Others 19A
KPI data · Data Call Throughput (by DL/UL, per User, per Cell)
related Data
· Unique statistics for specific trace requesting terminal
shall be provided. (attempt call, access success rate,
CD rate, transmission complete rate, transmission
speed, MAC, RLC, PHR, HARQ, R-BLER, CQI, RI,
SINR, MCS etc. RF and Scheduling related information,
Candidate UE for each TTI etc.)
· Multi-RAT related data
The RAN supplier shall indicate, under the form of a

CQI,SINR,
table (similar to the example below), what kind of
idle,connecte
reference signals and parameters (e.g.: CQI, SINR) are
d,
Counter & used in its implementation for: "idle" mode mobility
5G 5G Others 19A radio link
KPI measurements, connected mode mobility
monitoring,
measurements, radio link monitoring, and beam
beam
management. Other rows shall be added if further
management
measurements are foreseen.
Which NGC vendors have you done interoperability with

5G 5G Others IoT 19A N2,N3
for the N2 and N3 interfaces?
What is your status of interoperability across the Xn

5G 5G Others IoT 19A Xn interface? Will this interoperability extend to NR-NR
Dual Connectivity procedures?

Vendor shall state which interfaces plan to keep

Open proprietary and which interfaces plan to make open, now
5G Others IoT 19B
interface in roadmap. In case of open interfaces, the vendor shall
declare plans for IoT test with other solutions.

Response
Name
a) Following the 3GPP protocols, Huawei will support the MVI test for the
interface 5G Radio Access Network - 5G Core Network 3 months after the
3GPP standard frozen.
b) Following the 3GPP protocols, Huawei will support the MVI test for the
interfaces 5G Core/CP - 5G Core/UP and 5G NE (Network Entity) - NF
(Network Function) 3 months after the 3GPP standard frozen. strategy
depending
on frontline
FC application
The cell will simulate the load includes PDSCH and PDCCH channel load
according to a specified ratio and sends data through a specified fixed
beam ID.
FC
Attachment ：< 10 5G Others Attachement 1. LTE&NR Third Party

Interworking >
FC

Interworking >
FC
FC according to a specified ratio and sends data through a specified fixed
beam ID.
1. Support Cell level throughput monitor.

FC 2. Support Cell level interference monitor, including interference for each
RB.
Huawei EMS supports performance management, auto-collects data at two

regular intervals: short interval and long interval. The short interval can
support 5 minumtes or 15 minutes; the long interval can support 30 minutes
PC
or 1 hours. The data can be exported in TXT, HTML, XLS, XLSX, or CSV
format. Huawei EMS has limited specifications for collect 1min performance
statistics, and the data could not be exported.

a) Traffic-related performance Data for each service:

Data call reception and transmission related data: Can be supported from
19B
Handover related Data： Can be supported from 19B
Paging related Data (including Paging Discard)： Can be supported from
19B
Discarded Call Statistics according CAC： Can be supported from 19B
Location Registration related Data:Location registration process is through
NAS message, the gNB can't get the Location registration related Data
Data call Throughput (by DL/UL, per User, per Cell) related Data： Can be
supported.
Huawei will support performance data such as attempt call 、access
success number to calculate access success rate；Huawei will support
PC
performce data to calculate Call Drop rate froms 19B. Huawei will support
performance data trasmission speed（for transmission） from 19B.
Huawei will NOT support transmission complete rate.
Huawei supports MAC RLC throughput, PHR,
HARQ,BLER,SINR,MCS，RSRP，scheduled number for 1s granularity by
monitor.
For Multi-RAT related data, Huawei supports EN-NR Dual connection, and
Huawei 5G RAN can record performance data such as split traffic, split
packet, SgNB addition, SgNB release which to display the EN-NR Dual
connection performance.
co-location cell unit data can be derived from cell level data according to
post-processing; freqency uint data can also be derived from cell level data
according to post-processing; freqency uint data.
Connected mode mobility:

-SS signal RSRP
-PBCH DMRS RSRP
Cell selection and reselection:
-SS signal RSRP
-PBCH DMRS RSRP
FC Beam management:
-SS signal RSRP
-CSI-RS RSRP、SINR
-PBCH DMRS RSRP
Radio link monitoring (in-sync/out-sync)
-CSI-RS RSRP
-PBCH DMRS RSRP
Huawei has been working with other vendors on the N2/3 interoperability.
Due to the NDA assigment, the detailed info cannnot provided for the time strategy
Other being. depending
Huawei can support operators' IoT test to help the operator to deploy the on frontline
network upon request. application
At the time of writing this response, no interoperability tests related to Xn

interface have been carried out. Future test planning is subject to market
demands.
Huawei foresess the challenges behind the Xn interoperability as below:
1. There is no defined strategy or algorithm for data split in 3GPP. The
algorithm is vendor proprietary and may post potential impact to DC
Other
performance.
2. The 3GPP standard is still working in progress with 60% CR of
TS36.423 is NR-NR Dual Connectivity related.
3. No collaboration with MVI for IP automatic configuration and transmission strategy
robust management which will induce Automatic Configuration & depending
Optimization Failure. on frontline
application

Huawei has established the good IOT cooperation relation with all the
mainstream 2G/3G/4G/5G vendors, and all the IOT tests follow the
standard procedure which is defined by NVIOT Forum (Network Vendors
Interoperability Test), including the templates of test documents. Huawei
has built four global IOT labs in Shanghai/Xian/Chengdu, China;
Dusseldorf, Germany. All the IOT tests are performed in these four labs
through transmission network to connect with other vendors’ IOT labs.
Huawei plans to start IOT tests on interfaces S1, NG when the product
FC
release is ready. For the IOT of other interfaces, such as X2, Xn, will be
triggered by market requirements or/and customer’s requirements. Huawei
normally start IOT activities from TR5, and the exact test plan should be
negotiated and agreed by Huawei and other vendors. All the IOT test
information is protected by NDA (Non Disclosure Agreement).
The customer can submit IOT requirement, and all the IOT session depend strategy
on customer’s requirement, may not cover all the interfaces of other depending
vendors. on frontline
application

Back
Key word *Question
1. The proposer shall present the MVI function development

plan (Roadmap) by dividing it into major period (hereinafter
MVI referred to as “reference time”) and system section (hereinafter
function，de referred to as “interface”). However, setting of the reference
ployment time shall be base on the time to be verified by End to End
plan system level, rather than the completion of development at the
individual node.
Do you have any functional restriction on your current LTE
equipment in case the NR supplier is a third party Supplier?
Please describe in detail what the NR equipment has to fulfill to
LTE，NR，t ensure full interoperability with an 3rd party LTE supplier.
hird party
Do you have any functional restriction on the overall

LTE，NR，t performance if the LTE supplier is a third party supplier. Please
hird party describe in detail what the LTE equipment supplier has to fulfill
to ensure full interoperability.
Support OCNS (OFDM Cell Noise Simulator) on PDCCH and

Cell non- PDSCH: The 5G RAN shall include functionality to artificially
OCNA,OFD
performance load cells for performance benchmarking, and functionality for
5G 5G Others 19A M cell noise
related conformance testing at the maximum radiated power of the
simulator
functions radio unit.
The real-time monitoring function for details of traffic, noise,

Counter &
5G 5G Others 19A monitor and quality for each RB band and the notification function shall
KPI
be supported.
The functions to collect data automatically at intervals of 1

data minute, 5 minutes, 15 minutes and 1 hour according to
Counter &
5G 5G Others 19A collection performance statistics item and to collect data for a certain
KPI
period period time upon the operator's request shall be supported. (It
should be intuitively identifiable such as XML.TEXT.)
There shall be a function to collect and report the following

performance data, and the collection of data shall be
subdivided into gNB, cell unit, co-location cell unit, and
frequency unit.
a) Traffic-related performance Data for each service
· Data Call Incoming/Outgoing related Data
· Handover related Data
· Paging related Data (include Paging Discard)
· Discarded Call Statistics according CAC
Counter & performance · Location Registration related Data
5G 5G Others 19A
KPI data · Data Call Throughput (by DL/UL, per User, per Cell) related
Data
· Unique statistics for specific trace requesting terminal shall
be provided. (attempt call, access success rate, CD rate,
transmission complete rate, transmission speed, MAC, RLC,
PHR, HARQ, R-BLER, CQI, RI, SINR, MCS etc. RF and
Scheduling related information, Candidate UE for each TTI
etc.)
· Multi-RAT related data

Response
Name
a) Following the 3GPP protocols, Huawei will support the MVI test for the
interface 5G Radio Access Network - 5G Core Network 3 months after the
3GPP standard frozen.
b) Following the 3GPP protocols, Huawei will support the MVI test for the
interfaces 5G Core/CP - 5G Core/UP and 5G NE (Network Entity) - NF
(Network Function) 3 months after the 3GPP standard frozen.
FC
Interworking >
FC

Interworking >
FC
FC according to a specified ratio and sends data through a specified fixed
beam ID.
1. Support Cell level throughput monitor.

FC 2. Support Cell level interference monitor, including interference for each
RB.
Huawei EMS supports performance management, auto-collects data at two

regular intervals: short interval and long interval. The short interval can
support 5 minumtes or 15 minutes; the long interval can support 30 minutes
PC
or 1 hours. The data can be exported in TXT, HTML, XLS, XLSX, or CSV
format. Huawei EMS has limited specifications for collect 1min performance
statistics, and the data could not be exported.
a) Traffic-related performance Data for each service:

Data call reception and transmission related data: Can be supported from
19B
Handover related Data： Can be supported from 19B
Paging related Data (including Paging Discard)： Can be supported from
19B
Discarded Call Statistics according CAC： Can be supported from 19B
Location Registration related Data:Location registration process is through
NAS message, the gNB can't get the Location registration related Data
Data call Throughput (by DL/UL, per User, per Cell) related Data： Can be
supported.
Huawei will support performance data such as attempt call 、access
success number to calculate access success rate；Huawei will support
PC
performce data to calculate Call Drop rate froms 19B. Huawei will support
performance data trasmission speed（for transmission） from 19B.
Huawei will NOT support transmission complete rate.
Huawei supports MAC RLC throughput, PHR,
HARQ,BLER,SINR,MCS，RSRP，scheduled number for 1s granularity by
monitor.
For Multi-RAT related data, Huawei supports EN-NR Dual connection,
and Huawei 5G RAN can record performance data such as split traffic, split
packet, SgNB addition, SgNB release which to display the EN-NR Dual
connection performance.
co-location cell unit data can be derived from cell level data according to
post-processing; freqency uint data can also be derived from cell level data
according to post-processing; freqency uint data.

Back

Key word *Question
changes, Please describe the changes require on the 4G EPC

Core Core EPC 19A
EPC to fully support NR.
Please describe your concept for Mobile Edge

Core Core MEC 19A MEC
Computing (MEC).

Response
Name
To support non-standalone mode, the 4G EPC shall be

updated in the following aspects:
• Support new added ‘E-RAB modification’ procedure to allow
partial of RABs of a UE switch the downlink endpoint between
LTE eNB and 5G NR
• Receive 5G dual connectivity allowed authorization from
FC
HSS and send this information to eNodeB.
• MME may select S-GW & P-GW based on UE’s DC
capability.
• MME also needs to support receiving the data volume report
per RAT from the eNB both periodically as well as in S1
release / suspend procedures.
Huawei MEC solution has 3 parts.

a) First is the Control Plane & User Plane separated
networking, UP could be distributed to the network edge and
dealing with the LBO traffic.
b) Second is the application integration platform (CloudMSE), <00 Core
allows 3rd party application be easily integrated at the network Attachment
FC
edge. 1. MEC
c) Third part is CloudSCEF (Service Capability Exposure Concept>
Function) to collect various data from carrier pipes and open
capabilities after data processing and orchestration. Support
the following features, and CloudSCEF also can work with
RGW to open Edge Charging capability for LBO.

Back
Key word
CU-DU split
Visualization need
SRAN CU-DU Split & Split application virtualization
Solution from SRAN
MO
CU-DU split
Visualization need gNB
SRAN CU-DU Split & Split application CU，diagra
Solution from SRAN m，function
MO
CU-DU split
gNB
Visualization need
CU，size，
SRAN CU-DU Split & Split application
weight，volu
Solution from SRAN
me
MO

CU-DU split
Visualization need
gNB-CU
power supply
Solution from SRAN
MO
CU-DU split
Visualization need
gNB-CU
cooling
Solution from SRAN
MO
CU-DU split
Visualization need
gNB-CU
temperature
Solution from SRAN
MO

CU-DU split
Visualization need
gNB-CU,
H/W
Solution from SRAN
MO
CU-DU split
Visualization need
F1 inter-
operability
Solution from SRAN
MO
non-
virtualized
CU-DU split
programmabl
Visualization need
e hardware
(i.e. not
Solution from SRAN
ASIC)，dedi
MO
cated
hardware
non-
virtualized
CU-DU split
programmabl
Visualization need
e hardware
(i.e. not
Solution from SRAN
ASIC)，dedi
MO
cated
hardware
CU-DU split
Visualization need
separation，
CP，UP
Solution from SRAN
MO
CU-DU split
Visualization need
SRAN CU-DU Split & Split application E1
Solution from SRAN
MO
CU-DU split
Visualization need
CU-CP, CU-
UP
Solution from SRAN
MO
CU-DU split
Visualization need
SRAN CU-DU Split & Split application CU hardware
Solution from SRAN
MO

CU-DU split
Visualization need
SRAN CU-DU Split & Split application CU, module
Solution from SRAN
MO
CU-DU split
Visualization need scaling,
SRAN CU-DU Split & Split application migrating,
Solution from SRAN CU
MO
CU-DU split
Visualization need
SRAN CU-DU Split & Split application CU, update
Solution from SRAN
MO
CU-DU split
Visualization need CU,
SRAN CU-DU Split & Split application intelligent
Solution from SRAN management
MO
CU-DU split
Visualization need
SRAN CU-DU Split & Split application HA
Solution from SRAN
MO
CU-DU split
Visualization need
PDCP-RLC
split
Solution from SRAN
MO
CU-DU split
Visualization need
high layer
split
Solution from SRAN
MO
CU-DU split
Visualization need equipment,
SRAN CU-DU Split & Split application hardware,
Solution from SRAN software
MO
CU-DU split
Visualization need
performanc
impact
Solution from SRAN
MO
CU-DU split
Visualization need
SRAN CU-DU Split & Split application inter-vendor
Solution from SRAN
MO

CU-DU split
Visualization need
SRAN CU-DU Split & Split application inter-vendor
Solution from SRAN
MO
CU-DU split
Visualization need perforamce,
SRAN CU-DU Split & Split application inter-vendor,
Solution from SRAN intra-vendor
MO
CU-DU split
Visualization need
SRAN CU-DU Split & Split application benefit
Solution from SRAN
MO
CU-DU split
Visualization need
benefit,
scenario
Solution from SRAN
MO
CU-DU split
Visualization need
SRAN CU-DU Split & Split application saving
Solution from SRAN
MO
CU-DU split
Visualization need mixed level,
SRAN CU-DU Split & Split application higher layer,
Solution from SRAN lower layer
MO

CU-DU split
Visualization need
SRAN CU-DU Split & Split application 4G, split
Solution from SRAN
MO
CU-DU split
Visualization need
SRAN CU-DU Split & Split application 4G, split
Solution from SRAN
MO
CU-DU split
Visualization need
SRAN CU-DU Split & Split application 4G,split
Solution from SRAN
MO
CU-DU split
Visualization need 4G,BBU
SRAN CU-DU Split & Split application Hotel/RRU,
Solution from SRAN split
MO
CU-DU split
Visualization need
BBU
Hotel/RRU
Solution from SRAN
MO
CU-DU split
BBU
Visualization need
Hotel/RRU
split,
Solution from SRAN
hardware
MO
CU-DU split
Visualization need
SRAN CU-DU Split & Split application F1
Solution from SRAN
MO
CU-DU split
Visualization need
SRAN CU-DU Split & Split application CU,DU
Solution from SRAN
MO
CU-DU split
Visualization need
SRAN CU-DU Split & Split application component
Solution from SRAN
MO
CU-DU split
Visualization need
SRAN CU-DU Split & Split application VMs
Solution from SRAN
MO

CU-DU split
Visualization need
micro
services
Solution from SRAN
MO
CU-DU split
Visualization need
scaled in and
out
Solution from SRAN
MO split
CU-DU
Visualization need
SRAN CU-DU Split & Split application Linux
Solution from SRAN
MO
CU-DU split
Visualization need
hardware
acceleration
Solution from SRAN
MO split
CU-DU
Visualization need
hardware
acceleration
Solution from SRAN
CU-DU
MO split
Visualization need
hardware
acceleration
Solution from SRAN
MO
CU-DU split
Visualization need
decoupling
approach
Solution from SRAN
MO
CU-DU split
Visualization need
SRAN CU-DU Split & Split application orchestration
Solution from SRAN
MO
CU-DU split
Visualization need
Solution from SRAN
MO
CU-DU split
Visualization need
Solution from SRAN
MO
CU-DU split
Visualization need
SRAN CU-DU Split & Split application saving
Solution from SRAN
MO
CU-DU split
Visualization need
resiliency
and reliability
Solution from SRAN
MO
CU-DU split
state
Visualization need
information
sychchronize
Solution from SRAN
d
MO

CU-DU split
Visualization need
SRAN CU-DU Split & Split application VNF
Solution from SRAN
MO
CU-DU split
Visualization need
SRAN CU-DU Split & Split application CU approach
Solution from SRAN
MO
CU-DU split
Visualization need
backhaul
impairments
Solution from SRAN
MO
CU-DU split
Visualization need
SRAN CU-DU Split & Split application function
Solution from SRAN
MO
CU-DU split
Visualization need
SRAN CU-DU Split & Split application DU
Solution from SRAN
MO
CU-DU split
Visualization need
SRAN CU-DU Split & Split application DU
Solution from SRAN
MO

Do you have the system requirements for the Virtual Machine layer
for your CU software? What VM technologies can this be supported FC
on (e.g VMware, KVM etc)?
gNB-CU
The detailed equipment configuration diagram and the function
description shall be presented.
a) The mounting diagram of the specific units configuring H/W and

FC
block diagram shall be presented.
b) It shall present the name of specific unit configuring H/W, main

function, description of the main control module and whether it is a
redundancy structure.
gNB-CU
The equipment size shall be presented as Height (mm) x Width
(mm) x Depth (mm) along with weight (kg) and volume (liter). FC

gNB-CU
The equipment power supply method (standard voltage, operating
voltage range) shall be presented. FC
gNB-CU
The cooling method shall be presented. (e.g. Natural cooling or Fan FC
cooling)
gNB-CU
The operating temperature and humidity shall be presented.
(Example: 0˚C - 50˚C, 10-90%) FC

The gNB-CU shall be H/W configuration that can be mounted on a

19 "rack, and shall be desgined for earthquake-resistant FC
The solution shall support an open F1 interface enabling full inter-

FC
operability between CUs and DUs from different vendors.
Please provide a block diagram indicating which function(s) will be

implemented on non-virtualized programmable hardware (i.e. not FC
ASIC). Please describe what kind(s) of hardware is proposed.
Please state which interface is used between the functions running

on non-virtualized programmable hardware and the functions FC
running on dedicated hardware.
The gNB-CU shall support the separation structure of CU-CP and

PC
CU-UP
For E1 interface between CU-CP and CU-UP, an open Interface

FC
shall be provided
The gNB-CU-CP and gNB-CU-UP shall be flexibly deployed in the

FC
exchange station, concentrated station, etc
cots FC

The gNB-CU shall be designed in a module unit considering

capacity expansion and upgrade, and shall be designed in a
FC
structure that can be easily mounted/dismounted by push-pull
method for each module
The gNB-CU shall not affect service quality when scaling and
FC
migrating
Standby loading function of redundant (Active-Standby structure)

FC
H/W unit
Intelligent Management shall be automatically configured based on

the pre-set information defined by the operator when the gNB-CU is FC
first installed or the system is rese
High Availability (HA) in virtualization environment FC
Please confirm if your solution supports a gNB CU-DU with a

FC
centralised PDCP/RRC and decentralised RLC/MAC/PHY
Please confirm when this high layer split gNB CU-DU would be
FC
available within your product range
Please describe the equipment/hardware/software required for the

FC
gNB-CU and gNB-DU nodes in your solution
please give any insights on performance impacts of gNB containing

FC
may cells compared with a standard gNB containing only ~3 cells
Please state if your gNB-CU supports an inter-vendor connection to

FC
a gNB-DU supplied by a different vendor

Please state if your gNB-DU supports an inter-vendor connection to

FC
a gNB-CU supplied by a different vendor
Please give an insight into the relative performance between of

intra vendor gNB-CU/DU solution compared with inter-vendor gNB- FC
CU/DU solution
Please give any insights into the benefits of using your Control
FC
plane/User Plane split solution
Describe the level of the performance benefits that would be

obtained of running 5G via different CU/DU split(s) in comparison to
a classical D-RAN, and under what scenarios advantages from
FC
such an approach would be achieved (e.g. traffic scenarios, user
distributions, site types, etc.). (Describe benefits of different layer
split options individually where appropriate.)
What savings can be made at the DU in a CU/DU approach vs D-

FC
RAN approach
Further, can a mixture of different levels of CU/DU split be

supported simultaneously from a CU (eg, higher layer and lower
FC
layer splits), and what would be the advantages of such a mixture
approach in a macrocell area?

Is it necessary or recommended to move 4G to DU/CU split if

doing so for 5G. What are the specific performance advantages to FC
4G of doing this
If moving 4G to a CU/DU split from its classical DRAN deployment

FC
today, are all existing 4G functionalities and features still supported
Given that in 5G Dual connectivity 3GPP options 3x and 7x, the

eNB remains the Master node, are there any specific advantages
only available to 5G performance in options 3x or 7x if 4G is moved FC
to CU/DU split as well as 5G (compared to leaving eNB in classical
D-RAN but 5G on DU/CU split).
Is 4G BBU Hotel/RRU approach supported in addition to 4G CU/DU

split. If so, how, and what would the advantages/disadvantages of FC
running both be
Is 5G BBU Hotel/RRU approach supported in addition to 5G CU/DU

split. If so, how, and what would the advantages/disadvantages of FC
this be.
Can 4G be on BBU Hotel/RRU split, whilst 5G be on CU/DU split.

What would the hardware configuration implications and the FC
advantages/disadvantages of this be
When/will it be possible for a 5G DU to be connected to another

FC
vendor's 5G CU (via standardised F1 interface)
Architecture overview FC
Component description and dependencies/requirements where

FC
non-proprietary items
describe the role of containers versus VMs in your architecture FC

Please describe the role of microservices in your architecture NC
scaled in and out FC
Any requirement for real-time, ‘hardened’ or secure Linux, or any

FC
other specific enhancements to standard Linux.
Please describe any constraints on the hardware selection. For

FC
example hardware acceleration, specific NIC cards/drivers etc.
Where hardware acceleration is required, how would this be

FC
dimensioned
Please describe any recommendations for maximising throughput

FC
for high throughput, for example SR-IOV, DPDK
Describe your decoupling approach between orchestration, the

FC
NFVI, and the CU & IPSec, and dependencies
Overview any RAN CU/IPSec orchestration intentions FC
Please describe how you plan to ensure VMs are able to respond to
instantaneous bursty resource demands. E.g. are you expecting FC
MANO to respond by spawning new VNFIs?
Please explain any NFVI enhancements you require or recommend

FC
to make service-based architectures work in VM environments
What savings can be realised at the DU installation concomitant

FC
with deploying CU processing and functionality?
Please describe how your CU & IPSec solution can improve

FC
resiliency and reliability of the RAN and IPSec
Please describe how state information is synchronized between CU

FC
and IPSec in different locations

Please describe the mechanisms and procedures for re-start of

FC
VNFs after NFVI hardware failure
Describe particular features and their benefits that can be

FC
supported only via the CU approach
How are any performance benefits of CU impacted by backhaul

FC
impairments
Please provide an indication which functions will be placed at the

FC
CU and which at the DU for the higher layer split
Do you foresee any of the current DU protocol layers moving into

the CU (e.g. RLC and MAC)?
Do you foresee NSA continuing in the long term or do you see

Multi-RAT Dual Connectivity (MR-DC – note eNB/NR and NR/NR
combinations) becoming the norm with NR-NR combinations?

Response
Name
The separated DU and CU structure is being planned after 2020.

All function in gNB-CU could be virtualized in COTS hardware
platform. Huawei is considering to implement via COTs (e.g.,
HPC7000) plus VMware.
CU-DU分离口
径需申请！
The gNB-DU-h does NOT virtualize, because the function of
RLC/MAC/PHY should be running at real time system and accelerator
hardware, the processing ability of common hardware and software
can NOT satisfied the time latency and bandwidth requirement.
HUAWEI suggests using these two types of hardware platform as CU

hardware. One is E9000 produced by HUAWEI, another is C7000
produced by HP. These two platforms are designed in module unit and
all modules can be easily mounted and dismounted by push-pull
method. Appendix 2.1
Detail
The module or unit of configuring H/W, main function, description of information
the main control module and whether it is a redundancy structure of E9000
please refer to "Appendix 2.1 Detail information of E9000(CU).docx". (CU).docx,
Since the C7000 is designed by HP. Please refer to HP

website.:https://www.hpe.com/us/en/product-catalog/storage/disk-
enclosures/pip.hpe-bladesystem-c7000-enclosures.1844065.html
HUAWEI provides the information about E9000 as follows.
Dimensions (H x W x D)
•Chassis: 530.2 mm x 442 mm x 840 mm (20.87 in. x 17.40 in. x 33.07
in.)
•PSU: 40.5 mm x 126 mm x 285 mm (1.59 in. x 4.96 in. x 11.22 in.)
•Fan module: 84 mm x 82 mm x 296.3 mm (3.31 in. x 3.23 in. x 11.66
in.)
Weight (Net)
Empty chassis (including midplane): 70 kg (154.32 lb)
Fully configured chassis: ≤ 230 kg (507.06 lb)
Weight(Packing materials)
Chassis packing materials: 30 kg (66.15 lb)
Half-width node packing materials: 2.3 kg (5.07 lb)
Full-width node packing materials: 3.6 kg (7.94 lb)
Since the C7000 is designed by HP. Please refer to HP


HUAWEI provides the information about E9000 as follows.

Power supply method (PSU input specifications)
• Input voltage
DC PSU: -48 V DC to -60 V DC

AC PSU: 100 V AC to 130 V AC, 200 V AC to 220 V AC and 220 V AC
to 240 V AC, 50 Hz or 60 Hz
• Maximum input current

3000 W AC PSU: 16 A
2000 W AC PSU: 10 A
2500 W DC PSU: 80 A
•PSU output specifications

12.3 V DC
• PSU rated power

A chassis houses a maximum of six PSUs. The following information
lists the rated power of each type of PSU:
3000 W AC PSU:
1200 W (for 100 V AC to 130 V AC input)
2000 W AC PSU:
2500 W DC PSU:
2500 W (for -48 V DC to -60 V DC input)
The CU (E9000) uses Fan cooling.
The Operating temperature of E9000 is shown as follows.

Server:
Operating temperature: 5°C to 40°C (41°F to 104°F) (ASHRAE Class
A3 compliant)
Storage temperature: -40°C to +65°C (-40°F to +149°F)
PSU:
Operating temperature: -5°C to 50°C (23°F to 122°F)
Fan module:
Operating temperature: -10°C to 70°C (14°F to 158°F)
Humidity
Operating humidity: 5% RH to 85% RH (non-condensing)
Storage humidity: 5% RH to 95% RH (non-condensing)
Since the C7000 is designed by HP. Please refer to the HP


The E9000 can be mounted on 19 inch rack, dimensions (H x W x D)

of E9000:
•Chassis: 530.2 mm x 442 mm x 840 mm (20.87 in. x 17.40 in. x 33.07

in.)
•PSU: 40.5 mm x 126 mm x 285 mm (1.59 in. x 4.96 in. x 11.22 in.)
•Fan module: 84 mm x 82 mm x 296.3 mm (3.31 in. x 3.23 in. x 11.66

in.)
E9000's earthquake-resistant needs to be combined with the cabinet's

designing and installation. Huawei is willing to analyze with Operator
to earthquake-resistant construction, based on Korea's earthquake
standards.
Huawei will follow 3GPP protocol for the open F1 interface.
The dedicated hardware BBU5900 is proposed.

The BBU5900 has the following functions:
-Manages the entire base station system in terms of operation,
maintenance, and system clock.
-Processes signaling messages.
-Provides physical ports for information exchange between the base
station and the transport network.
-Provides an OM channel between the base station and the LMT,
SMT, or U2000.
-Processes uplink and downlink baseband signals.
-Provides CPRI /eCPRI ports for communication with the RF modules.
-Provides ports for communication with environment monitoring
devices.
-Povides 6 BBP slot for new efficiency BBP.
-Povides power-moniter feature.
BBU5900 is dedicated hardware, and also is non-virtualized

programmable hardware, The Real times functions(e.g.
RLC&MAC&PHY) are processed by BBU5900 to guarantee the
network performance.
1. The gNB-CU can be seperated into gNB-CU-CP and gNB-CU-UP

from 2018.12.30. The gNB-CU-UP can be depolyed with gNB-CU-CP
or gNB-DU.
2. After the 3GPP completes the standardized definition, the Interface
between gNB-CU-CP and gNB-CU-UP will completely follow the 3GPP
definition.
3GPP E1 interface definition is still in study item status. Huawei will

follow 3GPP Release 15 or 16 specifications defintion in the future
(+3month after the standard frozen).
Huawei suggests using these two types of hardware platform as CU

hardware. One is E9000 produced by Huawei, another is C7000
method.

Huawei suggests using these two types of hardware platform as CU

hardware. One is E9000 produced by Huawei, another is C7000
method.
Since the C7000 is designed by HP. Please refer to HP website.
https://www.hpe.com/us/en/product-catalog/storage/disk-enclosures/
pip.hpe-bladesystem-c7000-enclosures.1844065.html
Huawei intrudes the E9000 platform as follow. The E9000 is designed
based on module unit considering capacity expansion and upgrade.
And E9000 is designed in a structure that can be easily
mounted/dismounted by push-pull method for each module.
Huawei gNB-CU doesn't affect service quality when scaling and

migrating.
In scaling scenario, when selecting a VM to delete, the gNB-CU will
forbid new service to access the VM to be deleted and wait old service
release on the VM, then gNB-CU will request to MANO to delete the
VM. In migrating scenario, through data backup, redundancy design,
gNB-CU can recovery serivices very quilcky after trigger migration.
Huawei supports gray upgrades on CU. During the gray upgrade

process, the old and new versions will run at the same time, the
service can be switched from the old version to the new version, which
is almost seamless upgrade. This function will be supported from
The gNB-CU supports PnP install function.
When a fault occurs, the service switches quickly to redundant

resources and attempts to restore it.
Fully Compliant. Huawei supports option2 (PDCP-RLC) split which has

already be accepted in 3GPP.
Huawei CloudRAN solution complies with the 3GPP R15 Option2. We

can support trial/PoC by 2H 2018 but first commercial will have to be
1H2019
Huawei gNB supports CU/DU flexible deployment scenarios:

• In collapsed deployment scenario, gNB-CU and gNB-DU can be
collapsed and deployed inside the same BBU5900 hardware.
• In disaggregated deployment scenario, gNB-DU is deployed in
BBU5900 hardware while gNB-CU can be deployed in a centralised
COTS(Commercial off the shelt) -server and the software (Cloud OS)
can be VMware.
• When CU centralized, it can reduce the transport roundabout and

E2E user plane latency for Dual-Connectivity applications.
• When handover is triggered within gNB-CU, it will not be visible to
5GC and as a result no session transfer procedures will be triggered
by the 5GC significantly improve service experience.
• When CU centralized, it can also be used as an anchor for
cooperation features such as load balance to get better service
experience
Huawei will fully comply with the 3GPP specification for the F1
interface and is willing to support any inter-vendor specification from
3GPP but based on our past experience globally we see F1 interface is
very much like the Iub interface within the 3G. The daunting task of
IOT, potential performance degradation of overall network and the
complication of OAM jobs may well make such a well intended
initiative impractical

initiative impractical.
Huawei CU/UP split solution is expected to provide optimum control

plane (CP) functions at a network level enabling best signalling
performance and reliability globally. Huawei CU/DU split solution will
also provide significant flexibility in the deployment of UP functions to
match different QoS requirements of individual service requests (e.g.
reduce latency and increase transport bandwidth, etc.).
For high level CU/DU split by option2, the performance benefits is

shown below:
• Dual-Connectivity for seamless experience: when UP is centralized, it
can help reduce data trombone and E2E UP latency for concurrent
multi-RAT transmission over multi-connections.
• When triggering handover within gNB-CU, since the handover is not
visible to 5GC, it will not be able to trigger session transfer procedure
and hence improving service experience.
• When CU centralized, it can be used as an anchor for cooperation
features such as load balance to achieve better service experience.
• A key enabler for MEC and Agile: RAN-NRT SW can be co-located
with Distributed Gateway and Applications in edge to enable MEC
deployment which provides RAN open interface to applications for
optimal performance.
• Easy for Intelligent Network operation: Management of logical
Network Element is completely decoupled from the hardware.
Addition/deletion/modification of DUs will not affect the interface
between logical eNB/gNB and Core and OSS. CU keeps the RAN
configuration, measurement and counters, as well as storage and
computing resource for the Intelligent Network operation.
• Flexible capacity scaling with cloudification & NFV：SW and HW are
completely decoupled. By decoupling with dedicate hardware it can
save a lot of effort and investment for updating legacy hardware.
Capacity can be easily scaled up to meet the fast growing requirement
of 5G.
In D-RAN approach, RRC/PDCP function runs on the main control

board while in CU/DU split solution, RRC/PDCP function will be moved
from the main control board to the gNB-CU. This will help alleviate
capacity pressure on the main control board. On the other hand there
will be no change to baseband loading situation and therefore no
capacity saving on the BBU.
Fully compliant. Huawei supports flexible split such as high level

CU/DU split (option 2) and eCPRI split between DU and RRH at the
same time.

Huawei will follow 3GPP standards for 4G CU/DU split. The

advantages is listed below:
• When CU is centralized, it can reduce the transport roundabout and
E2E user plane latency for Dual-Connectivity.
• When handover is triggered within the eNB-CU territory, it will be
invisible to 4GC and as a resolute no session transfer procedure will
be initiated hence improving service experience.
• When CU is centralized, it can be used as an anchor for cooperation
features such as load balancing to achieve better service experience
It may reduce S1/NG interface handovers if 4G is moved to CU/DU

compared to leaving eNB in classical D-RAN when it is inside the
coverage of 5G.
Huawei can support both 4G CU/DU split and 4G BBU Hotel/RRU

approach at the same time. The advantages/disadvantages will
depend on actual deployment scenarios but in general:
• The advantage of BBU Hotel is easy site acquisition, shorter time to
market, less power consumption, and more efficient inter-eNB
coordination.
• The disadvantage of BBU Hotel is higher fronthaul bandwidth
requirement between the BBU Hotel and RRUs
Huawei can support both 5G CU/DU split and 5G BBU Hotel/RRU

approach at the same time. The advantages/disadvantages will
depend on actual deployment scenarios as mentioned above
Huawei can support a mixture of 4G/5G CU/DU split and 4G/5G BBU
Hotel/RRU solutions with no specific hardware configuration
implications. The advantages/disadvantages as mentioned above
Please refer to 5G RAN SOC Q2.docx
RAN CU contains one CloudRANCU_P and multiple CloudRANCU_
GNBs: CloudRANCU_P as a platform function, provide some public
functions such as resource scheduling, internal communication
network, file storage system, etc. CloudRANCU_ GNB provide
RRM/RRC/PDCP function
a RAN CU contains one CloudRANCU_P and multiple CloudRANCU_

GNBs: CloudRANCU_P as a platform function, provide some public
functions such as resource scheduling, internal communication
network, file storage system, etc. CloudRANCU_ GNB provide
RRM/RRC/PDCP function.

Huawei now doesn’t apply microservices in CloudRANCU because

microservices isn’t clearly in RAN domain, but Huawei would like to
discussion with BT about microservices in RAN domain and will
support it in future
The GuestOS of RANCU is based on CentOS7.2 with security

hardening
At present, in the SR-IOV scene RANCU only supports Mellanox 40GE

network card.
First, RANCU supports a common vSwitch solution to complete

software and hardware decoupling. The high-performance SR-IOV
solution was developed on the decoupled basis.
For different NFVI combinations, RANCU only need to update VNFD,
do not need to modify the code
RANCU is initially deployed by VNFM to create the corresponding

number of VMs according to the business plan. As the business
changes, RANCU will take the VM's scaling in / out judgment and send
it to VNFM for execution.
RANCU has built-in container management, through the pre-allocation

of VM, we can quickly deploy a lot of containers to meet the rapid
business increase
No specific requirement. Huawei RANCU has built-in container and

microservices managements.
In D-RAN approach, RRC/PDCP function deploy on Main Control

board, in CU/DU split approach, RRC/PDCP function will migrate from
Main Control board to gNB-CU, so can improve the capacity of Main
Control board, but the Baseband board capacity isn’t change ,so the
capacity of BBU(contain baseband board and Main control board) isn’t
change.
1) Data processing node, management processing node, storage

processing node etc. provide backup redundant mechanism. Critically
processing nodes provide Master and Slave processing nodes, and
anti-affinity deployment, once master node trigger a fault, processing
function fast switch to slave node. Data processing node such as
CP/UP services processing node support resources pool, scale
out/scale in automatically based on the traffic volume.
2) Now DU can only access a single CU, Huawei plans to support
Geo-redundancy resiliency in future.
Huawei RANCU achieve data separated from program, data

distributed stored method to keep synchronized of state information

when adopt the CU approach, it’s beneficial for:

• Dual-Connectivity for seamless experience: when UP are centralized,
it can reduce the transport roundabout and E2E user plane latency for
concurrent multi-RAT transmission with multi-connection.
• When trigger handover within gNB-CU, it will visible to 5GC so that
5GC will not trigger session transfer procedure it therefore can improve
service experience.
• When CU centralized, it can be used as an anchor for cooperation
features such as load balance to get better service experience
the by backhaul impairments may influence the any performance

benefits of CU, for example ,if the key message lost from CU transmit
to DU or data packet loss, so need to ensure the Qos of backhaul.
The benefits of moving DU protocol into CU are yet to be further

studied. Huawei is closely watching the standard development and
Huawei network evolution planning supports the various 5G

deployment architectures for e.g Option 3x, Option 4, Option 7, and
Option 2.
The network evolution path is dependent on a number of factors

including but not limited to:
- Spectrum strategy
- 5G use cases
- Chipset/Device availability
- 5GC transformation readiness
Based on the current 5GC development and progress, NSA is

expected to continue for mid to long term. Huawei will support
NSA&SA co-existing in one network.
Huawei would like to further investigate the network evolution planning
with Spark.

Back
Key word
FrontHaul &
FrontHaul & F1，Xn，Sn
SRAN Backhaul & 19A
Backhaul ，IEEE802.3
Sync
FrontHaul &
FrontHaul &
SRAN Backhaul & 19A TWAMP
Backhaul
Sync
FrontHaul &
FrontHaul & traffic
SRAN Backhaul & 19A
Backhaul shaping
Sync
FrontHaul & Acitve

FrontHaul &
SRAN Backhaul & 19A Standby
Backhaul
Sync router
FrontHaul &
Synchronizat
SRAN Backhaul & 19A 1588 v2
ion
Sync
FrontHaul &
Synchronizat
ion
Sync
FrontHaul &
Synchronizat
ion
Sync
FrontHaul &
SRAN Backhaul & VLAN 19A VLAN
Sync
FrontHaul &
Synchronizat oscillator,stra
SRAN Backhaul & 19A
ion tum 3E
Sync

Ethernet
FrontHaul &
FrontHaul & ports,service
SRAN Backhaul & 19A
Backhaul interrupt,Resi
Sync
lience
FrontHaul & phase

Synchronizat
SRAN Backhaul & 19A synchronizati
ion
Sync on
FrontHaul & phase

Synchronizat
ion
Sync on
FrontHaul &
Synchronizat
SRAN Backhaul & 19A GNSS
ion
Sync
FrontHaul & eCRPI

Synchronizat
ion
Sync on protocol
accuracy
FrontHaul &
Synchronizat degradation
SRAN Backhaul & 19A
ion ，eCPRI
Sync
distance
FrontHaul & GNSS

Synchronizat
SRAN Backhaul & 19A implementati
ion
Sync on

FrontHaul &
Synchronizat synchronizati
SRAN Backhaul & 19A
ion on backup
Sync
FrontHaul &
Synchronizat backup
SRAN Backhaul & 19A
ion requirement
Sync
FrontHaul &
Synchronizat backup
SRAN Backhaul & 19A
ion requirement
Sync
FrontHaul &
Synchronizat rtBU and RE
SRAN Backhaul & 19A
ion oscillator
Sync
FrontHaul &
Synchronizat syncE，freq
SRAN Backhaul & 19A
ion uency sync
Sync
FrontHaul &
Synchronizat time-
SRAN Backhaul & 19A
ion stamping
Sync
radio feature
FrontHaul &
SRAN Backhaul & 19A
ion on
Sync
requirement
FrontHaul &
Synchronizat standard
SRAN Backhaul & 19A
ion protocol
Sync

FrontHaul &
FrontHaul & Failure，Res
SRAN Backhaul & 19A
Backhaul ilience
Sync
FrontHaul &
FrontHaul & gNB,Failure
SRAN Backhaul & 19A
Backhaul ，Resilience
Sync
FrontHaul & CU,DU,Failu

FrontHaul &
SRAN Backhaul & 19A re，Resilien
Backhaul
Sync ce
FrontHaul & RAU,DU,Fail

FrontHaul &
SRAN Backhaul & 19A ure，Resilie
Backhaul
Sync nce
frequency
FrontHaul &
Synchronizat and
SRAN Backhaul & 19A
ion phase/time
Sync
synch
FrontHaul & CU DU，

Synchronizat
ion
Sync on solution

CU DU，
FrontHaul &
Synchronizat time
SRAN Backhaul & 19A
ion accuracy，er
Sync
ror budget
FrontHaul &
Synchronizat
ion
Sync
FrontHaul & interface,Syn

Synchronizat
SRAN Backhaul & 19A chronous
ion
Sync Ethernet
FrontHaul & interface,Syn

Synchronizat
SRAN Backhaul & 19A chronous
ion
Sync Ethernet
FrontHaul & hardware

Synchronizat
SRAN Backhaul & 19A tiem
ion
Sync stamping
FrontHaul &
Synchronizat
SRAN Backhaul & 19A CU sync
ion
Sync

FrontHaul & CU
Synchronizat
SRAN Backhaul & 19A sync,G.8275.
ion
Sync 1
FrontHaul & CU
Synchronizat
ion
Sync 2
FrontHaul &
Synchronizat
SRAN Backhaul & 19A DU sync
ion
Sync
FrontHaul & DU
Synchronizat
ion
Sync 1
FrontHaul & DU
Synchronizat
ion
Sync 2
FrontHaul &
FrontHaul & ethernet
SRAN Backhaul & 19A
Backhaul ports
Sync
FrontHaul &
FrontHaul & gNB-CU,link
SRAN Backhaul & 19A
Backhaul aggregation
Sync
FrontHaul &
FrontHaul & gNB-
SRAN Backhaul & 19A
Backhaul CU,multi rate
Sync

gNB-
CU,802.1Q
FrontHaul &
FrontHaul & VLAN,
SRAN Backhaul & 19A
Backhaul 802.1ad Q-
Sync
in-Q, DHCP,
LACP, ECM
gNB-
FrontHaul & CU,multi-
FrontHaul &
SRAN Backhaul & 19A homing,
Backhaul
Sync multiple IP
address
gNB-
FrontHaul & CU,redundan
FrontHaul &
SRAN Backhaul & 19A t
Backhaul
Sync switching,LA
CP,
FrontHaul & gNB-

FrontHaul &
SRAN Backhaul & 19A CU,redundan
Backhaul
Sync cy,
FrontHaul & backhaul,red

FrontHaul &
SRAN Backhaul & 19A undancy,inte
Backhaul
Sync rworking
FrontHaul &
FrontHaul & backhaul,swi
SRAN Backhaul & 19A
Backhaul tching time
Sync
FrontHaul &
FrontHaul & EMS,O&M,re
SRAN Backhaul & 19A
Backhaul dundancy
Sync
FrontHaul & gNB,link

FrontHaul &
SRAN Backhaul & 19A status,Core,
Backhaul
Sync EMS

FrontHaul & gNB-

FrontHaul &
SRAN Backhaul & 19A CU，timesta
Backhaul
Sync mp
hardware-
FrontHaul &
FrontHaul & based time
SRAN Backhaul & 19A
Backhaul stamp
Sync
function
FrontHaul &
FrontHaul & TWAMP，Y.
SRAN Backhaul & 19A
Backhaul 1731
Sync

FrontHaul &
FrontHaul &
Backhaul
Sync
FrontHaul &
FrontHaul &
Backhaul
Sync
FrontHaul &
FrontHaul & TWAMP，Y.
SRAN Backhaul & 19A
Backhaul 1731
Sync
FrontHaul &
Synchronizat sync method
SRAN Backhaul & 19A
ion specification
Sync
FrontHaul &
Synchronizat sync bt gNB
SRAN Backhaul & 19A
ion and core
Sync
FrontHaul &
Synchronizat G.8275.1，G
SRAN Backhaul & 19A
ion .8275.2
Sync
FrontHaul &
Synchronizat no
SRAN Backhaul & 19A
ion deterioration
Sync

FrontHaul &
Synchronizat antomatic
SRAN Backhaul & 19A
ion switching
Sync
FrontHaul &
Synchronizat antomatic
SRAN Backhaul & 19A
ion switching
Sync
sync
FrontHaul &
Synchronizat technology
SRAN Backhaul & 19A
ion advancemen
Sync
t
FrontHaul &
Synchronizat gNB and 5G
SRAN Backhaul & 19A
ion Core
Sync
FrontHaul &
Synchronizat gNB and 5G
SRAN Backhaul & 19A
ion Core
Sync

FrontHaul &
Synchronizat backup，mai
SRAN Backhaul & 19A
ion ntain
Sync
FrontHaul &
Synchronizat performance
SRAN Backhaul & 19A
ion improvement
Sync
FrontHaul &
Synchronizat lower layer
SRAN Backhaul & 19A
ion split
Sync
FrontHaul &
Synchronizat
ion
Sync
FrontHaul & interface，sy

Synchronizat
SRAN Backhaul & 19A nchronous
ion
Sync ethernet

FrontHaul &
FrontHaul &
SRAN Backhaul & 19A CU interface
Backhaul
Sync
FrontHaul &
FrontHaul &
SRAN Backhaul & 19A CU capacity
Backhaul
Sync
FrontHaul &
FrontHaul & backhaul
SRAN Backhaul & 19A
Backhaul redundancy
Sync
FrontHaul & CU，802.1，

FrontHaul &
SRAN Backhaul & 19A DHCP，LAC
Backhaul
Sync P，ECMP

FrontHaul &
SRAN Backhaul & 19A
Backhaul stability
Sync
FrontHaul &
FrontHaul & redundancy
SRAN Backhaul & 19A
Backhaul architecture
Sync

FrontHaul & load share，

FrontHaul &
SRAN Backhaul & 19A rate
Backhaul
Sync designation
FrontHaul & GTP-U

FrontHaul &
SRAN Backhaul & 19A session，TEI
Backhaul
Sync D
FrontHaul &
FrontHaul &
SRAN Backhaul & 19A IP
Backhaul
Sync
FrontHaul &
FrontHaul &
SRAN Backhaul & 19A IP
Backhaul
Sync
FrontHaul & state

FrontHaul &
SRAN Backhaul & 19A detection，al
Backhaul
Sync arm
FrontHaul &
FrontHaul & IP，port，re
SRAN Backhaul & 19A
Backhaul dundancy
Sync
FrontHaul &
FrontHaul &
Backhaul
Sync
FrontHaul &
FrontHaul & TWAMP，ac
SRAN Backhaul & 19A
Backhaul curacy
Sync

FrontHaul &
FrontHaul & TWAMP
SRAN Backhaul & 19A
Backhaul reflector
Sync
FrontHaul &
FrontHaul &
SRAN Backhaul & 19A quality
Backhaul
Sync
FrontHaul &
FrontHaul &
Backhaul
Sync
FrontHaul &
SRAN Backhaul & 19A
Backhaul interface
Sync
FrontHaul &
FrontHaul & SFP power
SRAN Backhaul & 19A
Backhaul level
Sync
FrontHaul &
FrontHaul & SFP power
SRAN Backhaul & 19A
Backhaul level
Sync

FrontHaul &
FrontHaul & CU
SRAN Backhaul & 19A
Backhaul DU,200km
Sync
FrontHaul &
FrontHaul &
SRAN Backhaul & 19A multi-rate
Backhaul
Sync
FrontHaul & CU,DU,switc

FrontHaul &
SRAN Backhaul & 19A hing
Backhaul
Sync operation
FrontHaul & CU,DU,switc

FrontHaul &
SRAN Backhaul & 19A hing
Backhaul
Sync operation
FrontHaul & fronthaul，ti

Synchronizat
SRAN Backhaul & 19A me
ion
Sync adjustment
FrontHaul &
Synchronizat Fx,compens
SRAN Backhaul & 19A
ion ation value
Sync
FrontHaul &
Synchronizat compensatio
SRAN Backhaul & 19A
ion n,distance
Sync
FrontHaul & compensate

Synchronizat
SRAN Backhaul & 19A d
ion
Sync automatically

FrontHaul & delay

Synchronizat
SRAN Backhaul & 19A measuremen
ion
Sync t methods
FrontHaul &
Synchronizat delay change
SRAN Backhaul & 19A
ion detection
Sync
FrontHaul &
Synchronizat delay
SRAN Backhaul & 19A
ion reference
Sync
FrontHaul &
SRAN Backhaul & 19A
ion on
Sync

FrontHaul &
Synchronizat GPS,1588v2,
SRAN Backhaul & 19A
ion syncE
Sync
FrontHaul &
Synchronizat GPS,1588v2,
SRAN Backhaul & 19A
ion syncE
Sync
FrontHaul & synchronizati

Synchronizat
SRAN Backhaul & 19A on
ion
Sync configuration
FrontHaul &
Synchronizat BC,boundary
SRAN Backhaul & 19A
ion clock
Sync
FrontHaul &
Synchronizat
SRAN Backhaul & 19A gNB,5GNC
ion
Sync

FrontHaul &
Synchronizat holdover
SRAN Backhaul & 19A
ion time
Sync
FrontHaul &
Synchronizat
SRAN Backhaul & 19A 1588v2
ion
Sync
FrontHaul &
Synchronizat
SRAN Backhaul & 19A negotiation
ion
Sync
FrontHaul &
Synchronizat 2 clock
SRAN Backhaul & 19A
ion references
Sync
FrontHaul &
Synchronizat
SRAN Backhaul & 19A G8275
ion
Sync
FrontHaul &
Synchronizat deterioration,
SRAN Backhaul & 19A
ion constraints
Sync
FrontHaul &
Synchronizat automatic
SRAN Backhaul & 19A
ion switching
Sync

FrontHaul &
Synchronizat
SRAN Backhaul & 19A 1588v2
ion
Sync
FrontHaul &
Synchronizat
SRAN Backhaul & 19A time error
ion
Sync
FrontHaul &
Synchronizat G.8265,G.82
SRAN Backhaul & 19A
ion 75
Sync
FrontHaul &
Synchronizat
SRAN Backhaul & 19A changeable
ion
Sync
FrontHaul &
Synchronizat
SRAN Backhaul & 19A performance
ion
Sync
FrontHaul &
Synchronizat reuse legacy
SRAN Backhaul & 19A
ion 4G GPS
Sync

FrontHaul &
Synchronizat
SRAN Backhaul & 19A alarm
ion
Sync
FrontHaul &
SRAN Backhaul & FrontHaul 19A Split, 7-2
Sync
5G 5G Feature Fronthaul 19A eCpri
5G 5G Feature Backhaul 19A Backhaul

The gNB F1, Xn and Sn interfaces must comply with the IEEE 802.3-
2015 10 GigE standard.
FC
gNB (CU and DU) shall support TWAMP per RFC 5357
FC
gNB(DU) shall be able to shape egress traffic below port speed to
match backhaul/mid-haul capacity (e.g. shape rate = 200M on 1G
physical port)
FC
gNB(DU) should be able to manage traffic between “Active” and
“Standby” interfaces to external router (SIAD)
FC
PTP 1588 v2 8265.1
FC
PTP 1588 v2 8275.1
FC
PTP 1588 v2 8275.2
FC
vLAN based PTP (i.e. PTP packets should be allowed on a separate
vLAN than bearer traffic but on the same physical port)
FC
Internal oscillator should comply at least Stratum 3E
FC

Is resiliency supported across Ethernet ports (LAG, RSTP, load sharing,

etc.)? What is the restoration time? Is service interrupted, and for how
long? Is the method interoperable with any switch-router vendors?
FC
5G Phase Synchronization requirements: Specify the transport network
requirements (Delay, Jitter, Packet Loss, etc.) for synchronization of
gNB (if timing over packet is supported).
FC
6.9.33 If primary timing source fails, or deployment of radio nodes are in
the area where there is no GNSS satellite visibility, the secondary (back
up) synchronization source shall be used.
FC
The use of GNSS system(s) other than GPS as additional
synchronization sources shall be agreed and approved by AT&T CSO
and Wireless Architecture and Devices organization.
FC
Since eCPRI standard v1.0 has left the implementation of
synchronization of Remote Equipment (RE, or AT&T - RRH) to the radio
vendor, please explain the synchronization protocol being selected for
eCPRI Interface. Please also explain that at 5G rtBBU, how rtBBU
deliver synchronization over eCPRI interface to RE.
FC
Please explain the frequency and phase synchronization accuracy
degradation over eCPRI interface, assuming maximum allowed eCPRI
distance. List maximum allowed eCPRI distance as well.
FC
Since AT&T plans for co-location of LTE BBU and 5G rtBBU, please
explain GNSS implementation from GPS antenna to both BBUs: a) GPS
receiver location – internal or external to BBUs, b) GPS antenna signal
distribution. Graphic illustration shall be provided as well.
FC

AT&T would like vendor to propose a network based synchronization

backup solution for 5G radio subsystem. Such system can be based on
IEEE 1588 protocol, and/or SyncE protocol. Any other network based
timing protocol that may be applicable can also be considered
FC
In such back up synchronization back up system, what would the critical
requirements?
FC
Because of the slip radio architecture, what are the necessary network
nodes and network feature that is critical to this solution
FC
Because of the Option 7 split and the use of eCPRI, two local oscillators
are involved with radio synchronization with rtBBU oscillation taking
synchronization signal inputs to discipline the Remote Equipment (RE
oscillator) in order to provide radio synchronization. a) what types of
oscillator to be used in rtBBU and RE?, b) because of replacing GPS as
timing source with far end network timing source, what is the cumulative
synchronization error the radio? Would radio still be able to meet the
nano-second (assumed) level phase sync?
FC
If syncE is required to enhance 1588 timing delivery, what is the syncE
timing source requirement? (Verify that syncE provides frequency sync
only). How would syncE help to enhance the syncE accuracy of radio
system?
FC
Support for timing protocols PTP IEEE1588v2/3 adapted to 5G
networks: Provide details about how your transport HW addresses
time-stamping required to meet the strict 5G phase synchronization
requirements.
FC
Please list known 3GPP 5G frequency and phase synchronization
specifications (in suggested table format) and 5G feature-by-feature the
phase synchronization requirements for FDD and TDD system,
separately if they are different and indicate requirements are pertaining
FDD or TDD or both.
FC
Vendor should provide universal and standardized protocols (i.e. IEEE
1588v2 or better solution) and Physical/L2 and L3 interfaces
configuration.
FC

Describe the mechanisms supported for resilience against failure of

transmission interfaces and failure of transport between the CU and the
core network.
FC
transmission interfaces and failure of transport between the gNB and
the core network.
FC
transmission interfaces and failure of transport between the DU and the
CU.
FC
transmission interfaces and failure of transport between the RAU and
the DU.
FC
BT expects to provide frequency and phase/time synchronisation via the
transport network. Frequency will be provided via physical layer
Synchronous Ethernet, phase/time will be provided by PTP. ITU-T
standards in the G.826x series (frequency) and G.827x series
(time/phase) will be used to ensure interoperability. The BT time/phase
platform will be aligned to UTC.
FC
transport network to the CU, and to the DU where a higher layer split is
implemented.
Please describe how synchronization can be achieved in the solution,
include all options, network based or otherwise, and any requirements
this places on external sources of all types and on the transport
network.
FC


implemented.State the time/phase accuracy required at the RAN air
interface, and at the time/phase source. Show the allocation of
time/phase error budget from the source to the air interface for each
element including CU and DU with higher or lower layer split, and RAU.
FC
implemented.For GNSS based synchronisation state the satellite
systems supported, any mitigation techniques for reception in
environments with limited clear sky view and with multipath, and any
techniques to mitigate interference or spoofing.
FC
implemented. For each backhaul interface type state whether
Synchronous Ethernet is supported.
FC
implemented. For each backhaul interface type state whether
Synchronisation Status Messaging (SSM) is supported.
FC
implemented. For each backhaul interface type state whether hardware
time stamping is implemented to optimise phase/time accuracy with
PTP.
FC
implemented. State the modes of operation for phase/time
synchronisation in CU (e.g. T-SC, T-BC, PRTC, GM as defined in the
G.827x series).
FC


implemented. State CU compliance with the profile defined in G.8275.1
for full on path support.
FC
implemented. State CU compliance with the profile defined in G.8275.2
for partial support and for assisted partial support (T-SC-P, T-BC-P).
Describe the partial support operating mode.
FC
implemented. State the modes of operation for phase/time
synchronisation in DU (e.g. T-SC, T-BC as defined in the G.827x
series).
FC
implemented. State DU compliance with the profile defined in G.8275.1
for full on path support.
FC
implemented. State DU compliance with the profile defined in G.8275.2
for partial support and for assisted partial support (T-SC-P, T-BC-P).
Describe the partial support operating mode.
FC
Backhaul refers to a wired network connecting gNB-CU equipment and
5G Core equipment or a wired network connecting gNB-CU equipment
and backbone network. The gNB-CU equipment Interface connected to
Backhaul basically supports Ethernet.
FC
The gNB-CU shall support link aggregation function in case backhaul
traffic increases.
FC
The gNB-CU shall support multi rate (1G, 5G, 10G, etc.) considering
backhaul traffic.
PC

The gNB-CU shall support 802.1Q VLAN, 802.1ad Q-in-Q, DHCP,

LACP, and ECMP that are connected to Backhaul, and shall be
interworked with low latency based time sensitive network, as required
in the future.
FC
The gNB-CU shall support the same service redundancy method as
multi-homing, multiple IP address, etc. when connecting with Backhaul
to ensure service stability.
FC
The gNB-CU equipment shall be able to support redundant switching
function (LACP, etc.) that is supported by Backhaul equipment during
interworking by duplicating uplink which is connected with Backhaul.
FC
When the gNB-CU Backhaul is configured for redundancy, Load Share
and Rate designation function shall be supported for NG-U according to
Active/Standby and Packet usage
FC
When the Backhaul is configured for redundancy, interworking method
for each port shall be presented in detail. Active/Standby configuration
for 5G Core between physical ports and Signaling Path and
Active/Active (Load sharing) for User Data Path shall be supported in
the redundant configuration.
FC
If some of the redundant Backhaul Interface is down, it shall be
switched to other Interface without call drop (switching time within 300
ms).
FC
The gNB shall provide redundancy for EMS and O & M Path.
FC
The gNB shall check the link status of Core and EMS equipment with
End to End, and if the service is not available, it shall be automatically
blocked to ensure that there is no quality degradation.
FC

When interworking with Backhaul, the gNB-CU shall support functions

to record the hardware-based timestamp information to quality
measurement packet received from TWAMP or Y.1731 that measures
packet loss, delay, jitter, etc. installed in the center and report to the
measurement device. (e.g. TWAMP and Y.1731)
FC
The hardware-based time stamp function shall not affect the accuracy
of the time stamp information even if the gNB-CU CPU load increases,
and the quality measurement accuracy shall be kept constant.
NC
The function accuracy of hardware-based time stamp function that
supports TWAMP or Y.1731 shall be presented. (e.g. ± 50 μsec, etc.)
PC

When operating with TWAMP Reflector, Full method (TWAMP Sender

and spec. Negotiation via TCP 862 port) and Light method (manually
configuration without Negotiation procedure) shall be supported.
FC
If the proposer has quality measurable solution above TWAMP level, it
can be presented.
FC
When using TWAMP or Y.1731, it shall not affect the gNB quality and it
shall be provided free of charge.
FC
Constraints such as specifications of each synchronization method,
configuration plan, clock accuracy, support distance, etc. of the above 2
shall be suggested.
a) GPS and IEEE1588v2 PTP (including details of each profile
supported and constraints) shall be suggested, respectively.
b) Synchronization configuration plan for each method shall be
suggested for gNB-CU, gNB-DU (integrated type), gNB-DU-h and gNB-
DU-1 (separate type), respectively.
c) Synchronization method for each interworking method (BC, TC
(P2PTC / E2ETC), OC) shall be suggested.
FC
Time synchronization between gNB and 5G Core shall be supported.
Other
The gNB shall support ITU-T G.8275.1 Multicast, G.8275.2 Unicast
Nego and shall satisfy all the features specified in the specification.
FC
There shall be no deterioration of the performance of the base station
and constraints of function by the clock source for each synchronization
method.
FC

In case of GPS failure, automatic switching shall be provided for other

reference clocks (such as IEEE1588v2) and the opposite case shall be
also possible.
• Clock Sync shall be maintained when system is rebooted or powered
off/on.
FC
The synchronization method shall be changeable by the operator.
FC
The gNB shall support the following synchronization method for
synchronization, and shall accommodate the technology advancement
for improving the clock accuracy, etc.
a) GPS
b) IEEE1588v2 (G.8275.2/G.8275.1)
FC
Time synchronization between gNB and 5G Core shall be supported.
FC
method.
FC


also possible.
· Clock Sync shall be maintained when system is rebooted or powered

off/on.
FC
Synchronization performance specialized by the manufacturer and
stability improvement plan shall be suggested.
FC
Please describe the approach to synchronisation of the RAU, and of the
DU where a lower layer split is implemented.
FC
For GNSS based synchronisation state the satellite systems supported,
any mitigation techniques for reception in environments with limited
clear sky view and with multipath, and any techniques to mitigate
interference or spoofing.
FC
For each backhaul interface type state whether Synchronous Ethernet
is supported.
FC

CU’s backhaul interface, capacity, number of ports should be provided. FC
The bandwidth of the gNB-CU equipment connected to Backhaul shall FC

provide the total capacity of the cell to be accommodated, and provide
the backhaul capacity and the number of ports/specifications required.
However, the Electrical Interface is not available.
For the redundancy of backhaul path, at least 4 ports for 10 G and 2 FC

ports for 1G shall be provided.
The gNB-CU shall support 802.1Q VLAN, 802.1ad Q-in-Q, DHCP,

LACP, and ECMP that are connected to backhaul, and shall be
interworked with low latency based time sensitive network, as required
in the future.

How to make sure the backhaul service stability？ FC
CU and DU of Basic type should provide seamless service solution of

backhaul redundancy architecture when backhaul has problem.

When the gNB-CU Backhaul is configured for redundancy, Load Share FC

and Rate designation function shall be supported for NG-U according to
Active/Standby and Packet usage.
How to identify the GTP-U session？
The internal IP of the gNB-CU shall not be seen outside the Backhaul FC
port, and the IP shall be easily changed by the operator's command.
The gNB shall provide redundancy for EMS and O & M Path. FC
Link state detection and alarm of Core and EMS. FC
The gNB shall support configuration of Multi IP and multi physical port FC
for redundancy.
Support TWAMP FC
Measurement accuracy of TWAMP PC

When operating with TWAMP Reflector, Full method (TWAMP Sender

and spec. Negotiation via TCP 862 port) and Light method (manually
configuration without Negotiation procedure) shall be supported.
Will the quality be affected when using TWAMP？
Is TWAMP free or not？
Detail explanation for backhaul interface and how to calculate the

bandwidth should be provided.
Backhaul SFP module’s Optic Power Level (Tx/Rx power), OTDR FC

result, wavelength information should be reported to gNB-Manager.
How does Huawei’s gNB interwork with the general-purpose wired FC

network switch equipment for reliable and aggregation and transmission
of traffic？

Is there any constraint in transmitting up to 200km between gNB-CU

and gNB-DU? Which optical modules does gNB support?
There shall be no problem in interworking of Multi-rate optical module

below 10G to ensure engineering based on the actual user traffic.
The mechanism of switching operation for protection by optical line FC

disconnection between gNB-CU and gNB-DU. Would there be “no call
drop (<50ms)” during the switching operation?
Protocol specifications (frame information, interworking method, etc.)

required for fronthaul network interworking between gNB-CU and gNB-
DU (including separate and integrated types) sections shall be provided
in detail. There shall be no problems when interworking with operator’s
own wired network solution.
Fronthaul shall support time adjustment function for delay measurement FC

and compensation.
Maximum measurement value, compensation value and transmission

distance that can be supported.
For delay measurement of fronthaul section, Delay measurement value,

compensation value and transmission distance from gNB-CU/gNB-DU-
h up to final gNB-CU/gNB-DU-h when gNB-DU or gNB-DU-l is
connected with cascade (when configured with maximum cascade)
shall be presented.
In the fronthaul section, the delay measurement value shall be

compensated automatically for the instantaneous transmission distance
change such as the circuit protection switching operation by the optical
line disconnection to ensure that there is no call drop. Also, the delay
measurement value shall be automatically compensated without any
constraints when interworking with the fronthaul transmission
equipment.

Delay measurement methods, delay calibration methods, re-

measurement methods and specific criteria to be performed in fronthaul
section shall be presented in detail.
Delay change detection method, re-measurement after delay change

and calibration method to be performed in fronthaul section shall be
presented in detail.
Delay reference value and the basis for drawing the delay reference
value in fronthaul section shall be presented in detail.
Synchronization is a function for accurate time synchronization of the FC

whole network such as gNB.

The gNB shall support the following synchronization method for

synchronization, and shall accommodate the technology advancement
for improving the clock accuracy, etc. GPS and IEEE1588v2 shall be
supported simultaneously, and shall operate as Active/Standby.
a) GPS
b) IEEE1588v2
c) SyncE
Constraints such as specifications of each synchronization method,

configuration method, clock accuracy, support distance, etc. of the
above 2 shall be presented.
a) GPS IEEE1588v2 PTP and SyncE (including details of each profile
supported and constraints) shall be presented, respectively.
Synchronization configuration method for each method shall be

presented for gNB-CU, gNB-DU (integrated type and separate type)
respectively.
The gNB shall support the synchronization between the gNBs using the
synchronization method of the above 2, and the method to utilize an
internal BC (Boundary Clock) function or an external clock shall be
presented.
Time synchronization between gNB and 5GNC or EPC shall be

supported

The gNB shall maintain the holdover for more than 24 hours in the
event of failure the synchronization function. There shall be no
degradation of the system performance and condition and service
quality during the holdover time.
The gNB shall support IEEE1588v2 Telecom Profile-2008 Mode,

Frequency sync Mode and Time & Phase Mode synchronization
method through the operator’s wired network.
gNB shall support both Negotiation and Non-Negotiation types in

Unicast mode when interworking with IEEE 1588v2 source.
The gNB shall be able to receive at least 2 clock references for signals
in IEEE 1588v2 and shall be automatically switched when problem
occurs in quality of the signal used as the main clock source.
The gNB shall support ITU-T G8275.1, G8275.2.

method.

also possible.

It shall be able to apply advanced technology such as 1588v2 to

improve time accuracy.
Specifications for Time Error Limits of gNB shall be provided.

- Carrier Aggregation, eICIC, CoMP, MIMO, etc.
The gNB shall be able to request and receive up to 128 FC

message/second (1 Gbit/s) in PTP Profiles (ITU-T G.8265.1, Telecom-
2008, G.8275.2) Unicast mode and shall support one-step and two-step
clock function.
The synchronization method shall be changeable by the operator. FC

The operator shall be able to change the priority of the reference clock.
Synchronization performance specialized by the manufacturer and the

stability and improvement method shall be presented.
Solution for re-using legacy 4G GPS should be provided.

Alarm should be supported to be monitored by operator when sync has

problem.
In the signal processing chain for the PHY layer, where is your current
split point between AAU functions and DU functions (this is currently
referred to as Split Point 7-2x in 3GPP)?
Describe eCPRI to support Massive MIMO (E.g. 100MHz 64T64R) and

FC
large number of cells. Bandwidth capabilities/requirements.
519. Vendor to describe backhaul capacity requirement per site type

FC
configuration (Urban small, etc.).

Response
Name
The gNB F1, Xn and Sn interfaces comply with the IEEE
802.3-2015 10 GigE standard.
IEEE 802.3 通常指
以太网。一种网络
协议。描述物理层
和数据链路层的
MAC子层的实现方
法，在多种物理媒
体上以多种速率采
用CSMA/CD访问
方式，对于快速以
太网该标准说明的
实现方法有所扩展
。
DU and CU support TWAMP(excluding eCPRI interface).
TWAMP：Two-Way Active Measurement Protocol
DU supports traffic shaping

ZHQ:不认为是QoS
的领域，类似
CPRI/eCPRI/S1接
口类
DU supports active/standby route by BFD. If link failure,

DU switches the traffic from active route to standby route.
gNB(DU) supports 1588v2 8265.1
1588v2 packet is VLAN based
Internal oscillator complies at least Stratum 3E
Stratum
3E:frequence
stability +/-
4.6PPM/20years,st
ability 1*10E-8…

Link layer:
LAG is supported on the Ethernet ports of DU/BBU/RAN-
CU in loadsharing mode, not including eCPRI interface.
Network layer:
Route backup is supported. The links are detected by
BFD.
The service interrupted time depends on the detection
time. The TX interval /RX interval of BFD session is
10~1000ms.Default value of detection multiplier is 3.
LAG and route backup are standard function, which need
the peer routers support too.
Phase synchronization on the transport Qos (latency,

jitter, packet loss) is not required. Because the gNB gets
the timing messages from the device connection directly
by IEEE1588V2.
GNB supports GNSS and other clock source between the

backup and switchover.
Backup types are as follows:
Time synchronization：
 GPS & IEEE1588 V2
 GPS & 1PPS+TOD
Frequency synchronization：
 GPS & SynchE
 SynchE & IEEE1588 V2
 GPS&IEEE1588 V2
GPS,GLONASS and BeiDou are supported.
The interface between DU and RAU of Huawei gNB is

CPR and eCPRI. However, synchronization is that ARU
obtains synchronization to DU, and the synchronization
path follows CPRI and eCPRI protocol.
eCPRI standard
v1.0 是什么状态；
答复的同步协议不
明确；
Factors affect RE synchronization accuracy is: from DU to
RRU between passes through the device number, and the
synchronization offset introduced by the device
specification.
答复问题不
全，CPRI和eCPRI
间最大距离？
LTE BBU and 5G BBU middle through a CI interface
interconnection or device right panel interconnection(Total
BBU box scenario), Distribution GPS clock source
synchronization information.
答复问题不全,没有
图示

1588v2+syncE is supported, but 1588v2+syncE is not a

clock source backup, they are belonging to the same
clock source.
Backup mechanisms, refer to the answer above, support
the backup clock source types are:
 GPS & IEEE1588 V2
 GPS & 1PPS+TOD
If multiple clock source backup, the customer network

should have multiple clock sources. For example: GPS
and 1588v2 backup, the customer network has GPS clock
source, It also can provide 1588v2 clock source.
For 1588v2+syncE, it’s needed for the network to provide

1588v2 clock source and SyncE clock source. For
GPS+1588v2 backup of multiple clock sources, The
customer network should have GPS clock source, It also
can provide 1588v2 clock source.
答复重复，建议删
除
a) BBU on the crystal oscillator type is: three-level
enhanced clock (3E) level OCXO; RE (AAU) on the
crystal oscillator type three-level strengthen clock (3E)
level TCXO.
b) eCPRI's RAU obtains synchronization information from
BBU through 1588v2+syncE, ensuring that BBU's sync
precision specifications are in line with RAU
specifications.
累计同步误差未答
；
Synchronous Ethernet is not the time synchronization of
the clock source but is a frequency source. Since it’s
frequency stability is very high, have good phase retention
capacity, and is used in 1588v2+SyncE scenario. When
1588v2 clock source is faulty and Phase loss, SyncE can
improve the hold time of the clock source.
同步时钟要求为答
复
The timing protocol PTP IEEE1588V2 is supported. But
PTP1588v3 is not supported. The BTS time-stamping at
PHY of ETH interface to avoid internal forwarding latency
include synchronization error.
5G TRAN
SOC
Q51.docx
Please refer to the attrachment
CBF：cooperative
beamforming .
5G TRAN DPS:
SOC Dynamic point
Q54.docx selection .
Please refer to the attrachment
5G TRAN
SOC
Q55.docx

Please refer to 5G TRAN SOC Q4.docx:

1.gNB-CU support Link Aggregation, Ethernet route
backup to against failure of transmission interfaces and
failure of transport between the CU and the core network.
Currently we did not see CU-DU split deploument yet, If
the gNB-CU deployed on Thrid party of COTS such as HP
C7000, which supports link aggregation (Ethernet Trunk).
Moreover, Huawei will continuously develop its own
product to support such functions.
2.Huawei use aggregate multiple physical links into a
logical link to increase the bandwidth and improve link
reliability.
3.Ethernet route backup
5G TRAN
SOC
Q4.docx
Huawei Answer:
Huawei gNB support Link Aggregation, Ethernet route
backup.
the CP of F1 interface supports SCTP dual-homing

the UP of F1 interface supports IP address pool on CU
please refer to the attrachment 5G TRAN
SOC
Q56.docx
Huawei gNB support CPRI interfaces redundancy
between RAU and the DU, one RAU could connect to
baseband board with two CPRI links simultaneously. If
one CPRI link is failure, the interface could auto switch to
another CPRI link.
UTC is the Coordinated Universal Time. Huawei gNB

sync is synchronized with GPS or PTP time scale and we
could get UTC and GPS / PTP time offset values. The
1588V2 protocol requires a clock source that is
synchronized at the time of PTP.
Please refer to 5G TRAN SOC Q5.docx

For the 1588V2 clock network solution, Huawei
recommends as shown below. It is recommended to use
the clock source sink program. The requirements for the
external clock source are referred to G.8271.1, as shown 电信级主时钟（T-
in the following table. GM）
电信级边界时钟（
T-BC）
电信级从时钟（T-
TSC）
普通时钟（OC）
透明时钟（TC）
边界时钟（BC）
*逐跳硬件支持
G.8275.1 T-GM-
>T-BC->T-TS.
参考：http://
support.huawei.co
5G TRAN m/enterprise/zh/
SOC doc/
Q5.docx EDOC1000106736

For 5G basic service, the air interface time

synchronization requirement is ± 1.5us. From the
backhaul network to the DU to the air interface, the
decomposition of the synchronization error refer to
G.8271.1 agreement.
If the follow-up ITU-T made a new decomposition
according to 3GPP R15 Protocol, Huawei also will follow.
For the CloudRAN CU / DU separation scenario, the CU
does not need to do a strict time synchronization, DU gets
the sync signal and passes it to the air interface.
HW gNB support GPS, GLONASS and Beidou

(COMPASS) satellite systems.
Normal satellite synchronization requires the search for
more than four satellite signals, but in some cases due to
occlusion may result in only one satellite signal being
found, in this case, HW gNB can get time synchronization
according to the historic synchronization information if the
satellite synchronization had been successfully acquired
in the past.
In addition, HW gNB support GNSS synchronization and
1588 synchronous mutual backup, further enhancing the
synchronization reliability in the case of occlusion or
interference.
For each backhaul interface, such as Gigabit, 10GE,

Optical, Electrical, etc., Synchronous Ethernet is
supported .
Synchronisation Status Messaging (SSM) is supported.
Hardware time stamping is implemented.
For the CU / DU separation scenario, the CU does not

need to do a strict time synchronization, requiring only DU
to get the synchronization signal and then pass it to the air
interface.

For the CU / DU separation scenario, the CU does not

need to do a strict time synchronization, requiring only DU
to get the synchronization signal and then pass it to the air
interface.
For the CloudRAN CU / DU separation scenario, the CU

does not need to do a strict time synchronization,
requiring only DU to get the synchronization signal and
then pass it to the air interface.

8271.1 and 8275.1 are supported. 8275.2 is supported
only under FDD.
HW recommended: Network node equipment should be
BC and gNB should be OC.
5G TRAN
SOC
Q6.docx
G.8275.2 is supported only under FDD and the gNB

should be configured for the 8275.2 mode. The gNB can
only synchronize to the nearest PTP node. If there is a
node that does not support BC in the middle of path
between the nearest PTP node and the gNB, the gNB can
also perform network synchronization in the way defined
by G.8275.2.

Huawei recommends that gNB-CU be deployed in Huawei
E9000 or HP C7000, and both of them support Backhaul
Ethernet.
For E9000, ports on the switch board panel are used for
cascading chassis and connecting to an external switch.
Huawei gNB-CU uses CX920 which support 8*10GE and
8*40GE Ethernet optical interface
5G TRAN
SOC
Q17.docx
refer to 5G TRAN SOC Q18.docx
5G TRAN
SOC
Q18.docx
The Ethernet interface supports GE/10GE auto-
negotiation, and the variety of actual transmission rates (x
mbps~10Gbps) can be carried on a physical port.

802.1Q VLAN, DHCP, LACP, and ECMP are supported

by E9000 and HP C7000.
Huawei E9000 supports QinQ, which tags a frame even if
the frame is tagged, and supports a maximum of 4094 x
4094 VLANs, meeting the network VLAN requirements.As
a general-purpose server, both E9000 and HP C7000
have no plan to support low latency or latency sensitive
features. Huawei thinks that the service on CU should be
non-real-time business.
5G TRAN
SOC
Q19.docx
5G TRAN
SOC
Q20.docx
5G TRAN
SOC
Q21.docx
5G TRAN
SOC
Q22.docx
Huawei gNB-CU supports the redundancy of Link
Aggregation, Equal-Cost Multi-Path routing and Ethernet
route backup. There will be no interworking problem with
the wired transmission network if the transmission
network is compliant with the same transmission
standard.
Trunk switch can be completed within 300ms, and

actually trunk switch time is about 50ms.
ECMP and Ethernet Route Backup depend on BFD
(Bidirectional Forwarding Detection) detection period
parameters, the minimum reporting period of BFD is
30ms.
"No call drop" depend ons different UE vendor's
implements.
Huawei gNodeB does not actively release UE when
switching time within 300ms.

5G TRAN
SOC
Q24.docx
The gNB supports link state detection and alarm.
If the user plane link is not available, the upper layer
service will be released. If OMCH is not available, it can
enter DHCP detect status, try to recover automatically.

When CU is deployed in E9000 or HP C7000, the gNB-

CU supports TWAM, but its timestamp is based on
software, it is CPU's forward thread but not the PHY of
network port record the timestamp.
In addition, gNB-CU can be deployed on the other third-
party servers (Besides E9000 and HP C7000). If third-
party servers support hardware timestamps, it can meet
the needs.Until now, communication industry has not
hardware-based timestamps for general-purpose
servers.Huawei also believes that the services running on
the CU are non-real-time services and do not require
hardware-based timestamps to measure high-quality
backhaul link quality. So it is not necessary to ask for
hardware-based TWAMP on the CU. Huawei also
predicted that even in the future, there may not be a
hardware-based timestamp of the generic server.
Huawei doesn't support the hardware-based time stamp

function when CU deploy on E9000 or HP C7000, but
supports the sofwarebased time stamp in E9000 or HP
C7000 scenario, and timestamp accuracy can be affected
due to netwrok congestion.
In addition, gNB-CU can be deployed on the third-party
servers (Besides E9000 and HP C7000). If third-party
servers support hardware timestamps, it can meet the
needs. Until now, communication industry has not
hardware-based timestamps for general-purpose servers.
Huawei also believes that the services running on the CU
are non-real-time services and do not require hardware-
based timestamps to measure high-quality backhaul link
quality. So it is not necessary to ask for hardware-based
TWAMP on the CU. Huawei also predicted that even in
the future, there may not be a hardware-based timestamp
of the generic server.
Huawei supports the software based time stamp when be

deployed in E9000 or HP C7000, its time stamp accuracy
is about +/- 1ms.
are non-real-time services and do not require hardware-
based timestamps to measure high-quality backhaul link
quality. So it is not necessary to ask for hardware-based
TWAMP on the CU. Huawei also predicted that even in
the future, there may not be a hardware-based timestamp
of the generic server.

The gNB-DU can support both Full method and Light

method. The gNB-CU does not support Light method.Both
gNB-CU and gNB-DU can use full method, and Huawei
suggests use Full mode between the gNB-CU and 5G
Core.
For the transmission network between gNB-CU and core
network, because the 5G NGC is the most recently
developed product, and the core network with greater
compatibility, it can be predicted that most vendor's NGC
will support Full method, so the probability of interworking
issue is also very low. We believe that the existing CU
Full method can meet the needs.
Even if there are interworking problems, Huawei gNB-CU
can support Light method according to the future needs in
a short time (in 3 month).
问题重复，请参考
新答复。
Huawei gNB-CU supports only TWAMP (Two-Way Active
Measurement Protocol) function.
Huawei TWAMP will not affect the gNB quality when

using. If there is customized development then it needs
discussion between Huawei and Operator.
5G TRAN
SOC
Q25.docx
Huawei gNodeBs currently do not have time
synchronization requirements with 5G Core. If 3GPP
protocol defines synchronization requirement between
gNodeBs and 5G Core, Huawei gNodeBs would comply
with it.
(1) G.8275.1 can be fully supported；

(2) G.8275.2 can be supported for FDD system, but
cannot be supported for TDD sytem, because G.8275.2 is
through the network, not hop-by-hop support 1588
synchronization, if the network occurs problems such as
jitter is too large, gNB clock lock may be failure, which will
lead to TDD system cannot work.
For different clock synchronization schemes, the gNB can

guarantee performance as long as the external clock
source accuracy can meet the requirements of the 3GPP
protocol.

If “GPS (Master) + IEEE1588v2 (Slave)” mode is

configured, automatic switching will be provided from
GPS synchronization to IEEE1588v2 synchronization
when a GPS failure occurs. And the opposite case is also
supported.
If the gNB system is rebooted or powered off/on, all
internal devices, chips, logic, etc., must be powered down
or restarted and initialized. During this process, all internal
signals will disappear and then regenerate, and the
system will be re-synchronized, so there is no
synchronization during reboot.
a) GPS synchronization is supported;

b) IEEE1588v2 synchronization:
cannot be supported for TDD sytem, because G.8275.2 is
through the network, not hop-by-hop support 1588
(3) Currently, it is recommended that customers give
priority to GPS as a clock synchronization source to
enable the TDD network. If the 1588V2 clock
synchronization network is built up, it can be as a backup
(GPS master +1588V2 assist) to improve the reliability.
(4) If 1588V2 network has been deployed, and the end-
to-end accuracy can meet the requirements of the base
station; then GPS synchronization resources for part of
the sites is also recommended for backup (1588v2 master
+GPS assist) to improve the reliability.
Huawei gNodeBs currently do not have time

gNodeBs and 5G Core, HW gNodeBs would comply with
it. In addition, for backhaul link between gNB and 5G
Core, state detection and delay measurement are
supported.
For different clock synchronization schemes, the gNB can

protocol.

If “GPS (Master) + IEEE1588v2 (Slave)” mode is

configured, automatic switching will be provided from
GPS synchronization to IEEE1588v2 synchronization
when a GPS failure occurs.
And the opposite case is also supported.
If the gNB system is rebooted or powered off/on, all

internal devices, chips, logic, etc., must be powered down
or restarted and initialized. During this process, all internal
signals will disappear and then regenerate, and the
system will be re-synchronized, so there is no
synchronization during reboot.
Huawei base station synchronization performance is in

line with 3GPP NR / ITU-T standard requirements. As the
NR protocol is still under development, Huawei will
continue to follow up and we will be able to discuss it in
the future.
The RAU obtains synchronization from DU, The interface

between RAU and DU of Huawei gNB is CPRI or eCPRI
and the synchronization methods follows CPRI and
eCPRI protocol.
HW gNB support GPS, GLONASS and Beidou

(COMPASS) satellite systems.
Normal satellite synchronization requires the search for
more than four satellite signals, but in some cases due to
occlusion may result in only one satellite signal being
found, in this case, HW gNB can get time synchronization
according to the historic synchronization information if the
satellite synchronization had been successfully acquired
in the past.
In addition, HW gNB support GNSS synchronization and
1588 synchronous mutual backup, further enhancing the
synchronization reliability in the case of occlusion or
interference.
重复问题，建议删
除
Fully compliant. For each backhaul interface, such as
Gigabit, 10GE, Optical, Electrical, etc., Synchronous
Ethernet is supported .

Huawei recommends that gNB-CU be deployed in Huawei HP6125和HP 宋卓

E9000 or HP C7000, and both of them support Backhaul C7000什么关系？
Ethernet.
Huawei gNB-CU uses CX920 which support 8*10GE
(usually used for internal switching) and 8*40GE Ethernet
optical interface, as switch boards.
Please refer to the following figure:
Huawei chooses
HP 6125 switch board
to connect with external switch:
The switch boards used for connecting with external CU吞吐口径是宋卓

network for E9000 (CX920) and HP C7000 (HP 6125) 100Gbps还是
both only support optical interface, and do not have 192Gbps
Electrical Interface.
For gNB-CU deploying in E9000 scenario, the throughput
is 100Gbps (DL+ UL), Huawei recommends to use two
CX920s to constitute the active/standby mode to increase
reliability, and each CX920 use 4 * 40GE optical ports to
100Gbps needs, while keeping about 40Gbps margin.
Huawei BBU5900 supports 2 UMPTe boards. It totally 宋卓

supports 4*10GE optical ports and 4*1GE electrical ports.
Huawei gNB-CU uses CX920 which supports 8*40GE
EthernetVLAN,
802.1Q opticalDHCP,
interface as switch
LACP, board.are supported
and ECMP 宋卓
by E9000 and HP C7000.
Huawei E9000 supports QinQ, which tags a frame even if
the frame is tagged, and supports a maximum of 4094 x
4094 VLANs, meeting the network VLAN requirements.
As a general-purpose server, both E9000 and HP C7000,

have no plan to support low latency or latency sensitive
features. Huawei thinks that the service on CU should be
non-real-time business.

Huawei gNB-CU supports control plane multi-homing by 宋卓

SCTP, and IP address pool.
SCTP is the signaling bearer protocol of the NG-C/X2/Xn

interface. With this function, one SCTP association has
two paths (IP-couple). An SCTP association is the logical
channel between two SCTP ends. The two paths in one
SCTP association are a master path and a slave path.
Generally, the master path is active. When the master
path fails, the slave path is activated.
For both control-plane and user-plane, it can be configed

multiple host IP address to setup multiple control and user
plane links.
Huawei gNB-CU supports Link Aggregation, Equal-Cost 宋卓

Multi-Path routing，Ethernet route backup.
Trunk: supports manual, static LACP and Dynamic LACP
mode:
1、In manual mode, all active links forwards traffic, and
traffic distribution is implemented by using specific
algorithms.
2、LACP supports dynamic and static modes. The
dynamic mode is generally used to connect to the server.
3、Differences between the static and dynamic modes:
• In static LACP mode, the Eth-Trunk becomes down and
does not forward data after LACP negotiation fails.
• In dynamic LACP mode, the Eth-Trunk becomes down
after LACP negotiation fails, but the member ports inherits
Eth-Trunk VLAN attributes and independently perform
layer-2 data forwarding.
Equivalent routes
If the destination IP addresses, subnet codes, and
priorities of two routes are the same in a routing domain,
the routes are equivalent routes
Packet forwarded on equivalent routes can be performed
based on streams or on a per packet basis. Huawei gNB
support packet forwarding based only on streams
The equivalent route is not recommended because one-
way audio or silence may occur if a route matching a
traffic flow is abnormal, for example, incorrectly
configured, or if the route path is abnormal, for example,
link interruption or packet loss occurs.
Ethernet route backup
If the static routes have different priorities, they are active
and standby routes.
Ethernet route backup is typically applied where the base

station is connected to two active/standby gateway
routers.

1、The CU supports traffic shaping and queue scheduling 宋卓

based on the physical capacity of the transport processing
unit.
2、The CU supports the restriction and shaping of the
entire CU transmission traffic based on the logical port. If
the traffic exceeds the logical port bandwidth, it can
guarantee high priority service bandwidth based on the
logical port queue scheduling.
3、gNB-CU supports multiple data plane links
configuration for one core network，and support load
balance between these user plane links.
4、Link aggregation applies when multiple FE/GE/10GGE
ports on the main control board or extension transmission
processing board/UCCU board of the base station form a
link aggregation group and connect to the link aggregation
ports of the layer 2 or layer 3 devices. The ports on the
base station board are involved in link aggregation in
static load sharing mode.
The current implementation of Huawei complies with the 宋卓

definition of 3GPP, means that different GTP-U sessions
are represented by different TEIDs.
Huawei gNB supports interface IP, logical IP and IP 宋卓
address pool. Logical IP (loop IP) can be divided by
customer in private network and isolated from public IP
address. It is no need for restarting when change IP.
The DU supports Active/Standby OMCH, and the CU 为什么不是OM领宋卓

supports Active/Standby IP route. 域？
Following is the work flow for Active/Standby OMCH:
The active channel takes priority over the slave channel,

and therefore the U2000 preferentially initiates setup of
the active channel. The U2000 detects the channel status
by using a handshake mechanism at the application layer.
If the active channel fails, the U2000 instructs the base
station through the standby channel to perform a
switchover. After receiving the instruction, the base
station deactivates the active channel and activates the
standby channel.
The gNB supports link state detection and alarm. 宋卓
If the user plane link is not available, the upper layer
service will be released.
If OMCH is not available, it can enter DHCP detect status,
try to recover automatically.
Huawei gNB support multi IP and multi physical port for 宋卓
redundancy.
When CU is deployed in E9000 or HP C7000, the gNB- 宋卓

CU supports TWAM, but its timestamp is based on
software, it is CPU's forward thread but not the PHY of
network port record the timestamp.
In addition, gNB-CU can be deployed on the other third-
party servers (Besides E9000 and HP C7000). If third-
party servers support hardware timestamps, it can meet
the needs. Until now, communication industry has not
Huawei gNB-CU supports the software based time stamp 宋卓
when be deployed in E9000 or HP C7000, its time stamp
accuracy is about ± 1ms.

The gNB-DU can support both Full method and Light 宋卓

method. The gNB-CU does not support Light method.
Both gNB-CU and gNB-DU can use full method, and
Huawei suggests to use Full mode between the gNB-CU
and 5G Core.
For the transmission network between gNB-CU and core
network, because the 5G NGC is the most recently
developed product, and the core network with greater
Huawei TWAMP
compatibility, willbe
it can not affect the
predicted gNB
that quality
most whenNGC
vendor's
宋卓
using.
Huawei TWAMP needs license. 宋卓
gNB-DU backhaul transmission capacity design depends DU空口带宽要求需宋卓

on the cell configuration.1DU air interface bandwidth 要统一指向一个文
requirement is below: 档《4G&5G对传输
&时钟要求口径
1.0.xlsx》
The backhaul interface bandwidth can be converted

through the air interface bandwidth, according to
IPsec/non-IPsec and packet length, backhaul bandwidth
capability need increase 8% (non-IPsec typical value) or
15%(IPsec typical value) based on air interface capability.
For example, Backhaul bandwidth = air interface
bandwidth requirement * 108% (non-IPsec).
At the same time, backhaul capabilities are also tied to
the board's processing ability, gNodeB use 2 * UMPTe
OTDR requires a separate proprietary test equipment, Compliant状态为“ 宋卓
can provide maximum 20Gbps backhaul capacity.
gNB does not integrate OTDR currently, and the BBU FC”。Ok？
supports report the external OTDR testing data to the
U2000.Through U2000 or WebLMT, can execute "DSP
SFP" command to query the dynamic information of an
optical module, it include Optic Power Level(Tx/Rx
power), wavelength information.
For example:
Huawei's gNB-CU and gNB-DU comply with IETF related 宋卓

transmission protocol, so both gNB-CU and gNB-DU can
interwork with the general-purpose wired network switch
equipment.

In the gNB-CU and gNB-DU (including separate and 宋卓

integrated) sections, there is not constraint in transmitting
up to 200km，and support 10G.
（19B支持）UMPTe support maximum 10G Optical
module, also support 100M, 1G optical module,
UMPTe support 2 * FE/GE/10GE optical ports，and port 宋卓
capacity can be 100 Mbit/s, 1000 Mbit/s, or 10,000 Mbit/s.
Huawei supports path redundancy between gNB-CU and 宋卓

gNB-DU, logic or physical link can switch within 50ms
when one path disconnection.
Trunk switch can be completed within 300ms, and
actually trunk switch time is about 50ms.
ECMP and Ethernet Route Backup depend on BFD
(Bidirectional Forwarding Detection) period parameters,
the minimum reporting period of BFD is 30ms.
"No call drop" depends on different UE vendor's
implements.
For the above mechanism, Huawei gNB does not actively
release UE when switching time within 300ms.
The gNB can ensure link switch within 50ms, and the cell
state does not change, but whether "no call dropping" for
The
UE isF1related
interface user
to the plane and control
implementation plane
of the UE. are 宋卓答复，陈圣贤陈圣贤
compliant with the follow transmission protocol: 评审，领域和
User Plane: ETH MAC/IP/UDP/GTP-U SRAN交叉，需要
Control Plane: ETH MAC/IP/SCTP 彻底明确答复接口
There will be no interworking problem with the wired
transmission network if the transmission network is
compliant with the same transmission standard.
Fronthaul shall support time adjustment function for delay 李智

measurement and compensation.
For Fx interface (both CPRI and eCPRI), Huawei gNB 李智

supports 20km transmission distance and 100us delay
compensation between gNB-DU and AAU.
For Fx interface (both CPRI and eCPRI), Huawei gNB 李智
supports 20km transmission distance and 100us delay
compensation between gNB-DU and AAU. If AAU is
connected with Cascade, the distance between gNB-DU
and final AAU should less than 20km.
For F1 interface, there is no need to measure and
compensate the delay between gNB-CU and gNB-DU.
In the fronthaul section, delay measurement is performed 李智

in real time and continuously. Also, the delay
measurement value is automatically compensated.
For CPRI interface, the gNB-DU checks the topology
state of the CPRI link every 200ms. If the CPRI-link status
error is detected 3 times within 1 second, the link rebuild
will be performed and the service will be damaged.
Therefore, if the instantaneous transmission distance
changes can be guaranteed in a very short time to
complete the switch, for example, less than 500ms, the
re-measurement and re-compensation action can
guarantee no call.
For eCPRI interface, delay re-measurement and re-
compensation is also performed automatically. Since the
eCPRI protocol is still in development, the details of the
implementation mechanism we can follow up further

For eCPRI interface: 李智

a) Delay measurement method
According to the draft eCPRI protocol, the message type
‘One-Way delay measurement’ is used for estimating the
one-way delay between two eCPRI-ports in one direction.
The service assumes that both nodes are time
synchronized to a common time with an accuracy
sufficient for the eCPRI service.
Two compensation values are used to set the

measurements reference points as suited for a specific
implementation. The exact locations of the reference
points are vendor specific. The One-Way delay value is
calculated according to following equation: tD = (t2 –
tCV2) – (t1 + tCV1)
b) Delay calibration method
When the sender gets the tD delay, it will compensate the
delay in advance when the Ethernet data is sent.
For CPRI interface, according to CPRI protocol, delay
measurement method is shown below, where REC and
RE means gNB-DU and AAU:
For both CPRI and eCPRI interface, the gNB-DU checks 李智

the topology state of the link periodically. If a change is
detected, the delay is measured again and then
compensated according to the new delay.
A RE shall use the incoming frame timing as the timing 李智

reference for any outgoing signals. The timing
specifications are defined as follows, where REC and RE
means gNB-DU and AAU:
Consent Complete 李智

a) GPS synchronization is supported; 李智

b) IEEE1588v2 synchronization:
cannot be supported for TDD system, because G.8275.2
is through the network, not hop-by-hop support 1588
c) SyncE for frequency synchronize is supported.
GPS Synchronization: Configuration method is shown 李智

below. The synchronization accuracy needs to meet the
3GPP protocol requirements. The maximum length of the
permissible cable (including the relay amplifier, etc.) is
300m。
1588 Synchronization: (1) G.8275.1 can be fully

supported； (2) G.8275.2 cannot be supported for TDD
system, because G.8275.2 is through the network, not
hop-by-hop support 1588 synchronization, if the network
problems such as jitter is too large, gNB clock lock may
be failure, which will lead to TDD system cannot work.
SyncE: HW gNodeBs support SyncE according to
G.8261, G.8262 and G.8264.
There is no time synchronization between gNB-CU and 李智

gNB-CU; gNB-DU and gNB-DU need to be synchronized,
the synchronization method is GPS and IEEE1588v2
PTP; the interface between gNB-DU and AAU may be
CPRI or eCPRI interface, respectively, synchronization
HW recommended: Network node equipment should be 李智
BC and gNB should be OC. Please see the following
diagram for reference. HW gNBs don't support an internal
BC (Boundary Clock) function.
Huawei gNodeBs currently do not have time 李智

gNodeBs and 5G Core, HW gNodeBs would comply with

不提供统一口径。具体项目具体答复李智
HW gNBs support IEEE1588v2-2008. For time 李智

synchronization, HW gNBs support ITU-T 8275.1. For
frequency synchronization, HW gNBs support ITU-T
8265.1.
The unicast mode defined by the protocol is only 8275.2 李智

and 8265.1 and both of them are in negotiation mode.
Huawei gNBs comply with the above protocol when
interworking with IEEE 1588v2 source.
Huawei does not recommend using non-negotiation mode
because
HW gNBsnocanprotocol
receivesupports
at least it.
2 clock references for 李智
signals in IEEE 1588v2 and shall be automatically
switched when problem occurs in quality of the signal
used as the main clock source.
HW gNBs support the GPS and IEEE1588v2 mutual
backup, both “GPS (Master) + IEEE1588v2 (Slave)” and
“IEEE1588v2 (Master) + GPS (Slave)” can be supported.
IEEE1588v2 (Master) + IEEE1588v2 (Slave) redundancy
function will be supported as below;
1) When a gNB has only one synchronization source
which is the upper level equipment such as BC1 shown in
figure below, the BC1 will automatically switch the clock
source when the clock quality of the two GMs changes. At
this point, the main and backup functions are
implemented by the clock network.
2) When a gNB has two synchronization sources such as

BC1 and BC2 shown in figure below, the gNB will
automatically switch between master and slave according
to the connection status of BC1 and BC2.
IEEE1588 Synchronization: (1) G.8275.1 can be fully 李智

supported； (2) G.8275.2 cannot be supported for TDD
system, because G.8275.2 is through the network, not
hop-by-hop support 1588 synchronization, if the network
For different clock synchronization schemes, the gNB can 李智
protocol.
HW gNBs support the GPS and IEEE1588v2 mutual 李智

backup, both “GPS (Master) + IEEE1588v2 (Slave)” and
“IEEE1588v2 (Master) + GPS (Slave)” can be supported.

Huawei base stations will continue to evolve to support 李智

new synchronization standards and technologies such as
IEEE1588v2.1. At the same time, the time
synchronization accuracy also meets the requirements of
5G frame structure affects CP (Cyclic Prefix) length of 李智
OFDM. The larger the subcarrier, CP is smaller. And CP
Length effect Tsync accuracy.
Definition:
• TD1: Time difference induced by transmission distances
d0/d1;
• TD2: Time difference induced by multi-path propagation;
• TD3: Tsync error between sites;
• Total TD = TD1 + TD2 + TD3: Time difference received
by UE's Rx;
Assume that UE uses single TA, according to 3GPP
TS36.922. It requires: TD1 + TD2 + TD3 = Total TD ≤ CP.
The larger the subcarrier and CP smaller, Smaller the
margin is reserved for the Tsync. The greater the distance
between sites and the propagation is larger, Smaller the
margin reserved for Tsync.
Tsync requirement for different features:

• SMP (symmetrical multi point)/DMP (duplicate multi
point)/DPS (dynamic point selection)/UL CoMP: Related
to CP as shown above.
• CBF (coordinated beamforming)/CA/DC: TTI level
coordination, Low sync requirement.
HW gNBs can request and receive up to 128 李智
message/second in PTP Profiles (ITU-T G.8265.1,
Telecom-2008, G.8275.2) Unicast mode. G.8275.2 can be
supported only for FDD system.
HW gNBs can support one-step and two-step clock
function.
Consent complete 李智
Huawei base station synchronization performance is in 李智

line with 3GPP NR / ITU-T standard requirements.
In the initial deployment of the network, 5G base station 李智

can use the legacy GPS clock resources for GPS time
synchronization.
Follow-up if the 1588 clock network is available, it is
recommended to provide GPS + 1588 as a backup clock
source solution for the base station to improve
synchronization reliability.

If an external clock source fails and the time 李智

synchronization is lost, the Huawei gNBs will report the
related fault alarm.
Huawei suggests the ID&IU option, because the
bandwidth requirement is reduced from 100Gbps to
25Gbps, and there is no impact on Coordination Features.
From SRAN15.0 Huawei supports split point 7-2x
specified by 3GPP.
a) The CPRI bit rates requirement for 100M 64T64R is
100Gbps. The maximum latency should be less than
100us.
b) The eCPRI bit rates requirement for 100M 64T64R is
25Gbps, it requires 25G SFP module. The applicable QoS
requirements is: The packet delay should be no more
than 100us, The packet loss ratio should be no more than
10-7.
It only requires the bandwidth and IP function support

from Transmission Network Equipment.
Huawei calculates backhaul capacity requirement per site
type configuration based on Cell Throughput and
Convergence Ratio to Transmission Network.
Backhaul Capacity requirement per Site
= Cell Qty. * Cell Peak Throughput * Convergence
Ratio
Take Urban small as an example:
Site type: Urban small (low-band: 2T2R, high-band:
4T4R)
L700 10M S111 +L800 10M S111 +G900 S444+L900
10M S111 + G1800 S444 + L1800 20+10M S222 + L2600
20+20M S222
LTE Band Cell Qty. Bandwidth
(MHz) Cell Peak Throughput
(Mbps) Backhaul Capacity requirement (Mbps)
700 2T2R 3 10 75 225
800 2T2R 3 10 75 225
900 2T2R 3 10 75 225
1800 4T4R 3 + 3 20 + 10 300 + 150 1350
2600 4T4R 3 + 3 20 + 20 300 + 300 1800
Backhaul Capacity requirement per Site 3825
Assumption: Cell Throughput and Convergence Ratio to

Transmission Network is 50% ( value can be different
according to actual requirement ) .
Then the Backhaul Capacity requirement per site to
Transmission Network =
Backhaul Capacity requirement per site * 50% = 1912.5
Mbps.
The principles can be used to future 5G Backhaul
Capacity requirement calculation.
Note: The backhaul interface bandwidth can be converted

through the air interface bandwidth, according to
IPsec/non-IPsec and packet length,
backhaul bandwidth capability need increase 8%(non-
IPsec typical value) or 15%(IPsec typical value) based on
aire interface capability.
For example, Backhaul bandwidth = air interface
bandwidth requirement * 108%(non-IPsec)
At the same time, backhaul capabilities are also tied to
the board's processing ability, DBS5900 use 2 * UMPTe
can provide maximum 20Gbps backhaul capacity.

Back
Key word *Question
Please describe NSA options you support

Multi-mode NSA & Multi-
SRAN 19A NSA，option3
Feature RAT DC
Please state which 5G architecture options are supported

for the RAN-CN interface and the interface between E-
UTRA and NR RAT (section 7.2 of [3GPP38.801]).
NSA,interface,X2,S
SRAN 19A 1-C1,S1-
Feature RAT DC
U,option2,option3x
Multi-mode UL&DL LTE 1.8GHz UL shared with 3.5GHz should be supported

SRAN 19A UL share to enhance UL coverage
Feature Decoupling
The Supplier shall provide a SON feature for discovering
and associating LTE and NR cells or sites to be used in a
dual-connectivity relationship.
This feature will:
1. Reduce the need for operator / manual creation of static
relationships between LTE and NR cells
2. Create all required network data and interfaces to
Multi-mode
SRAN D-SON 19A SON, DC facilitate the dual connectivity relationship automatically
Feature
3. Avoid the need to create site-specific data-fill in areas
with variable or patchy 5G coverage
Inter RAT Handover (5G ↔ LTE, 5G ↔ WCDMA) Latency

shall be less than 20ms
Multi-mode Inter-RAT
SRAN 19B handover
Feature Operation

SRAN 19A NSA，option3 Please describe NSA options you support
Feature RAT DC
NSA,interface,X2,S Please state which 5G architecture options are supported

SRAN 19A 1-C1,S1- for the RAN-CN interface and the interface between E-
Feature RAT DC
U,option2,option3x UTRA and NR RAT (section 7.2 of [3GPP38.801]).
Multi-mode LTE sub3G UL shared with 3.5GHz should be supported to

SRAN SUL 19A UL share
Feature enhance UL coverage
Multi-mode Automatic Neighbor Relationship (ANR) for inter RAT

SRAN D-SON 19A ANR
Feature neighbors should be supported
Multi-mode X2 auto X2 connection auto establishment between LTE and NR for

SRAN D-SON 19A
Feature establishment NSA DC should be supported.
If LTE and NR sites are managed by different U2000, X2

Multi-mode X2 auto
SRAN D-SON 19A connection auto establishment between LTE and NR
Feature establishment

The Supplier shall provide a SON feature for discovering

and associating LTE and NR cells or sites to be used in a
dual-connectivity relationship.
This feature will:
1. Reduce the need for operator / manual creation of static
Multi-mode relationships between LTE and NR cells
SRAN D-SON 19A dual-connectivity
Feature 2. Create all required network data and interfaces to
facilitate the dual connectivity relationship automatically

Response
Name
Huawei supports option 3 and option 3X for NSA.
FC
Option 3 and option 3X are supported currently.

For option3X, interface between EPC and eNB is S1-C, and
interface between EPC and gNB is S1-U, and using this option can
avoid updating LTE current hardware.
FC For Option 3, interface between EPC and eNB is S1-C and S1-U.
The interface between E-UTRA and NR RAT is X2 which is 3GPP
defined.
Please refer to attachment "5G SW SOC Q7.docx". 5G SW SOC

FC
Q7.docx,
According to Huawei strategy, LTE and NR dual-connectivity
relationship is dependent on LTE and NR cell neighbourhood: only
those cells configured as neighbour cells can be setup dual-
connectivity relationship. Further, LTE and NR cell should have X2
interface so that enable signal and data transmission between LTE
and NR cell. Standardized ANR (Auto Neighbour Relation)
mechanism is required. But currently, NR ANR mechanism is not
PC fronzen in 3GPP.
After ANR is standardized in 3GPP, Huawei will consider
automatic discovering and associating LTE and NR dual-
connectivity relationship, creating all required network data and
interfaces to facilitate the dual connectivity relationship
automatically, and clean-up erroneously created or rarely used
relationship.
1. Huawei will support 5G ↔ LTE handover in 5G RAN2.0,

handover latency will follow 3GPP specification.
2. 5G ↔ WCDMA handover has not been discussed in 3GPP,
Huawei will follow 3GPP specification.
During inter RAT handover procedure, 5G access procedure 随项目确定
Other latency is less than LTE and reach 10ms. 19B落地情况
So, LTE to 5G inter RAT handover latency will less than 20ms.
FC Huawei supports option 3 and option 3X for NSA.

For option3X, interface between EPC and eNB is S1-C, and
interface between EPC and gNB is S1-U, and using this option can
FC avoid updating LTE current hardware.
For Option 3, interface between EPC and eNB is S1-C and S1-U.
defined.
FC See attachement for detail
Inter-RAT ANR for NSA: It is not supported.

Inter-RAT ANR for SA: Inter-RAT ANR currently is not supported
PC and ANR mechanism currently is not frozen in 3GPP NR, Huawei
will support Inter-RAT ANR 6 months after ANR mechanism
frozen.
X2 connection auto establishment between LTE and NR for NSA

FC
DC should be supported.
PC Currently it's not supported. Supported version is TBD.


those cells configured as neighbour cells can be setup dual-
connectivity relationship. Further, LTE and NR cell should have X2
interface so that enable signal and data transmission between LTE
and NR cell. Standardized ANR (Auto Neighbour Relation)
mechanism is required. But currently, NR ANR mechanism is not
PC
fronzen in 3GPP.
After ANR is standardized in 3GPP, Huawei will consider
automatic discovering and associating LTE and NR dual-
connectivity relationship, creating all required network data and
interfaces to facilitate the dual connectivity relationship
automatically, and clean-up erroneously created or rarely used
relationship.

Back
Key word *Question
Inter RAT Handover (5G ↔ LTE, 5G ↔ WCDMA)

Latency shall be less than 20ms
Multi-mode Inter-RAT
SRAN 19B handover
Feature Operation

Feature RAT DC
Please state which 5G architecture options are

NSA,interface,X2,
Multi-mode NSA & Multi- supported for the RAN-CN interface and the interface
SRAN 19A S1-C1,S1-
Feature RAT DC between E-UTRA and NR RAT (section 7.2 of
U,option2,option3x
[3GPP38.801]).
Multi-mode LTE 1.8GHz UL shared with 3.5GHz should be

SRAN SUL 19A UL share
Feature supported to enhance UL coverage
Multi-mode Automatic Neighbor Relationship (ANR) for inter RAT

SRAN D-SON 19A ANR
Feature neighbors should be supported
Multi-mode X2 auto X2 connection auto establishment between LTE and NR

SRAN D-SON 19A
Feature establishment for NSA DC should be supported.
If LTE and NR sites are managed by different U2000,

Multi-mode X2 auto
SRAN D-SON 19A X2 connection auto establishment between LTE and NR
Feature establishment
The Supplier shall provide a SON feature for

discovering and associating LTE and NR cells or sites to
be used in a dual-connectivity relationship.
This feature will:
1. Reduce the need for operator / manual creation of
static relationships between LTE and NR cells
Multi-mode
SRAN D-SON 19A dual-connectivity 2. Create all required network data and interfaces to
Feature
facilitate the dual connectivity relationship automatically
4. Clean-up erroneously created or rarely used
relationship

Feature RAT DC
SRAN 19A interface Please describe SA options you support
Feature RAT DC
Please state which 5G architecture options are

Multi-mode NSA & Multi- supported for the RAN-CN interface and the interface
SRAN 19A interface
Feature RAT DC between E-UTRA and NR RAT (section 7.2 of
[3GPP38.801]).

Response
Name
1. Huawei will support 5G ↔ LTE handover in 5G RAN2.0, handover
latency will follow 3GPP specification.
2. 5G ↔ WCDMA handover has not been discussed in 3GPP, Huawei
will follow 3GPP specification.
During inter RAT handover procedure, 5G access procedure latency is 随项目确定
Other less than LTE and reach 10ms. 19B落地情况
So, LTE to 5G inter RAT handover latency will less than 20ms.

For option3X, interface between EPC and eNB is S1-C, and interface
between EPC and gNB is S1-U, and using this option can avoid
FC updating LTE current hardware.
defined.
FC See attachement for detail
Inter-RAT ANR for NSA: It is not supported.

Inter-RAT ANR for SA: Inter-RAT ANR currently is not supported and
PC
ANR mechanism currently is not frozen in 3GPP NR, Huawei will
support Inter-RAT ANR 6 months after ANR mechanism frozen.
X2 connection auto establishment between LTE and NR for NSA DC
FC
PC Currently it's not supported. Supported version is TBD.

those cells configured as neighbour cells can be setup dual-connectivity
relationship. Further, LTE and NR cell should have X2 interface so that
enable signal and data transmission between LTE and NR cell.
Standardized ANR (Auto Neighbour Relation) mechanism is required.
PC
But currently, NR ANR mechanism is not fronzen in 3GPP.
After ANR is standardized in 3GPP, Huawei will consider automatic
discovering and associating LTE and NR dual-connectivity relationship,
creating all required network data and interfaces to facilitate the dual
connectivity relationship automatically, and clean-up erroneously
created or rarely used relationship.
FC Currently it's not supported. Supported version is TBD.

For option3X, interface between EPC and eNB is S1-C, and interface
between EPC and gNB is S1-U, and using this option can avoid
FC updating LTE current hardware.
defined.

Back
Key word *Question
In order to support E2E Network Slicing, RAN Slicing function

Network Network
SRAN 19A shall be supported including function to select the proper AMF
Slicing Slicing
using Slice ID provided by the device.
The SDAP layer shall support the operations defined in 3GPP

TS38.300 and TS37.324. When there is a SDAP layer-based
Network Network
SRAN 19A solution for supporting RAN Slicing function, and the detailed
Slicing Slicing
algorithm and performance shall be provided including whether it
is implemented or not.
The SDAP layer shall support the specific functions such as data
Network Network radio bearer mapping algorithm considering QoS characteristics
SRAN 19A
Slicing Slicing by service flow, and the detailed algorithm and performance
shall be provided including whether it is implemented or not.
For data radio bearer mapped according to the service flow in

the SDAP layer, protocol layer (SDAP, PDCP, RLC, MAC, PHY)
Network Network in the user plane that configures the RAN including the SDAP
SRAN 19A
Slicing Slicing layer shall support RRM and resource allocation scheduling
algorithm considering QoS characteristics of the service flow
and the detailed algorithm and performance shall be provided.
Network Network
SRAN 19A Same as 3.5GHz
Slicing Slicing

Response
Name
Reply
attachment
PC Refer to word attachment
for
3.5GHz.docx
Reply
attachment
for
3.5GHz.docx
Reply
attachment
for
3.5GHz.docx
gNodeB support PDCP/RLC/MAC parameter configuration for each

radio bearer. and huawei also give a group of default configuration for
each one.
for example 5QI=9 is always used for FTP or sharing traffic, these
traffic is not senstive for packet delay but more concerned about the
PC
Packet Error Rate, so the defalut value of this radio bearer is different
with delay critical traffic bearer. such as RlcMode is AM, more
retransmission chance to reduce packet loss rate, longer polling
retransmission timer and so on.
Same as 3.5GHz

Back
Key word
number of
OSS OSS EMS
gNBs
change，con
OSS OSS EMS
figuration
ID
OSS OSS EMS
management
korean
OSS OSS EMS
language
OSS OSS EMS GUI
gNB
OSS OSS EMS
name,korean
OSS OSS EMS moving time

failure
cause,correc
tive
OSS OSS EMS
measures,ko
rean
language
OSS OSS EMS alarm code
display，nod
OSS OSS EMS
e info

call fail
OSS OSS EMS
reason
OSS OSS EMS call fail log
OSS OSS EMS call fail log
OSS OSS EMS job function
high-speed
OSS OSS EMS processing
function

history
OSS OSS EMS
management
OSS OSS EMS IPv4,Ipv6
OSS OSS VNF vCU
OSS OSS VNF
OSS OSS VNF
manifest
OSS OSS VNF file,all
components
VNF
OSS OSS VNF identification
data

VNF
OSS OSS VNF management
APIs
VNF function
OSS OSS VNF
APIs
OSS OSS VNF
dependency
OSS OSS VNF with other
VNFs
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF

OSS OSS VNF
OSS OSS VNF
OSS OSS VNF
OSS OSS VNF

OSS OSS EMS
OSS OSS EMS
OSS OSS EMS
OSS OSS EMS
OSS OSS EMS
OSS OSS EMS
OSS OSS EMS

OSS OSS EMS
OSS OSS EMS
OSS OSS EMS
OSS OSS EMS
OSS OSS EMS

OSS OSS EMS
OSS OSS EMS
OSS OSS EMS
OSS OSS EMS
OSS OSS EMS
OSS OSS EMS
OSS OSS EMS
OSS OSS EMS
OSS OSS EMS
OSS OSS EMS

SON, cell
OSS OSS C-SON
identifiers
OSS OSS EMS 5G cell plan
OSS OSS EMS Trace
OSS OSS EMS IPV6
OSS OSS C-SON SON
OSS OSS EMS license
TR069, CPE
OSS OSS EMS
Mgt.
TR143 CPE
OSS OSS EMS
Mgt.
OSS OSS EMS CPE
OSS OSS EMS CPE
OSS OSS EMS CPE
OSS OSS EMS CU-DU Split

OSS OSS EMS Automation
OSS OSS EMS PnP
OSS OSS EMS RANSharing
OSS OSS EMS commission
OSS OSS C-SON SON

OSS OSS C-SON SON
OSS OSS EMS

OSS OSS EMS
PnP, CU-DU
OSS OSS EMS
Split

OSS OSS C-SON SON,X2
OSS OSS C-SON SON

OSS OSS EMS Automation
OSS OSS C-SON X2
OSS OSS C-SON X2
OSS OSS EMS PnP

OSS OSS EMS PnP

The number of gNBs that can be managed by the EMS shall be

presented, and it shall be able to upgrade to the capacity required by our
Company in the future. Also, basically the capacity per EMS shall be more
than 10,000Cell
FC
Functions for output and change (increase / decrease) of gNodeB
configuration information shall be supported.
FC
ID management function to be managed in 5G such as gNodeB and Cell
shall be supported.
FC
Function to provide help with parameters shall be supported in Korean
language.
NC
Up to level 3, function to provide "H /W mounting GUI by NE" shall be
supported.
a) Level 1: Network Element level
b) Level 2: Rack / Shelf level
c) Level 3: Unit / Board level (H / W unit), Virtualization Function level
FC
Function to display and input the gNB name in Korean shall be supported.
NC
When changing the acceptance between EMS and gNB, the moving time
shall be minimized.
FC
Function to provide help with failure cause and corrective measures shall
be supported in Korean language.
NC
The EMS shall provide a separate alarm code for each NE of the gNB
(gNB-CU, gNB-DU (including separate and integrated), etc.) and shall
have unique alarm codes by failure.
FC
The EMS MUST include display of node information (IP Address, Node
Name, etc.) subject to interworking in Alarm and Fault Message when
failure occurs in each NE of gNB interworking equipment (5G Core, LTE
Core, LTE eNB, etc.).
FC

Call Fail Reason that can be supported (see the implementation request
cases below) shall be suggested.
a) Should provide cause of all the calls with Call Fail
? should include the cause about the call terminated by the user during
the call and the user’s limit
b) While implementing Call Fail Reason, EMS shall provide root cause
and solutions in Korean, and the operator should be able to edit the
information.
c) All failure calls (miscommunication, incomplete, CD call) should be
subdivided statically according to call type.
d) All failure calls (miscommunication, incomplete, CD call) should be
analyzed and printed in real time according to call type.
e) GNodeB resource allocation history about failure calls should be printed
together (include Group Unit ID # / Modem # information).
g) Besides failure calls, those calls with low throughput that do not satisfy
the expectation of our standards should be printed for statistics
segmentation and real-time analysis.
h) Peak values should also be provided for all performance data.
? ex: When Buffer Usage status in N2, N3 Interface, Congestion / Flow
Control cause history statistics are provided, 5 minutes, 15 minutes, 1
hour of average value and peak value are also provided.
i) Provide CRR (Call Release Reason), CSL (Call Summary Log) and
CRR & Mapping Table of statistics, CRR & N2 Cause Mapping Table etc.
PC
Call Fail Log should be provided in 1-minute basis.
PC
It should provide functions related to MDT (Minimization of Drive Test).
a) On/Off and Scheduling functions for each cell are provided.
b) MDT Log should be saved in a specific folder of EMS using XML or our
recommended format.
c) There should be no EMS restrictions in using MDT.
PC
Batch Job function shall be supported.
a) The MMI Command Script written by the operator shall be carried out at
a specified time.
b) The MMI Command Script must be able to contain multiple commands
for multiple NEs, Batch Job execution time shall be minimized.
FC
High-speed processing functions must be provided to ensure that multiple
inquiry and control commands can be processed by multiple gNodeBs.
FC

The history management function of inquiry / control command by Network

Management system shall be provided.
PC
Support of both IP v4 and IP v6.
PC
Instantiation of vCU by AT&T ONAP solution.
Requires compliance to requirements specified in
1. VNF Guidelines for Network Cloud and ONAP
2. VNF Cloud Readiness
3. AT&T Integrated Cloud Specification
4. VNF HEAT template
and per attachment A6-11 subcategory c.
PC
Integrate with AT&T ONAP configuration management solution ( APP-C)
Supported API are Chef, Ansible, NetConf.
Detailed requirements below.
PC
Integrate with AT&T ONAP monitoring solution ( DCAE).
Supported API is REST/HTTPS/JSON
Detailed Requirements below
PC
The VNF Vendor must provide a Manifest File that contains a list of all the
components in the VNF package.
PC
The package must include VNF Identification Data to uniquely identify the
resource for a given Vendor. The identification data must include: an
identifier for the VNF, the name of the VNF as was given by the VNF
Vendor, VNF description, VNF Vendor, and version.
PC

The VNF Vendor must provide documentation describing VNF

Management APIs. The document must include information and tools for:
· ONAP to deploy and configure (initially and ongoing) the VNF
application(s) (e.g., NETCONF APIs). Includes description of configurable
parameters for the VNF and whether the parameters can be configured
after VNF instantiation.
· ONAP to monitor the health of the VNF (conditions that require
healing and/or scaling responses). Includes a description of:
o Parameters that can be monitored for the VNF and event
records (status, fault, flow, session, call, control plane, etc.) generated by
the VNF after instantiation.
o Runtime lifecycle events and related actions (e.g., control
responses, tests) which can be performed for the VNF.
PC
The VNF package must include documentation describing VNF Functional
APIs that are utilized to build network and application services. This
document describes the externally exposed functional inputs and outputs
for the VNF, including interface format and protocols supported.
PC
The VNF Vendor must provide documentation describing VNF Functional
Capabilities that are utilized to operationalize the VNF and compose
complex services.
PC
The VNF Vendor must provide information regarding any dependency
(e.g., affinity, anti-affinity) with other VNFs and resources.
PC
The VNF Vendor must support and provide artifacts for configuration
management using at least one of the following technologies:
· Netconf/YANG
· Chef
· Ansible
Note: The requirements for Netconf/YANG, Chef, and Ansible protocols
are provided separately and must be supported only if the corresponding
protocol option is provided by the vendor.
PC

Configuration Management via Netconf/YANG

The VNF Vendor must provide a Resource/Device YANG model as a
foundation for creating the YANG model for configuration. This will include
VNF attributes/parameters and valid values/attributes configurable by
policy.
PC
Configuration Management via Chef
· VNF Vendor must provide cookbooks to be loaded on the
appropriate Chef Server.
· The VNF Vendor is required to provide a JSON file for each
supported action for the VNF. The JSON file must contain key value pairs
with all relevant values populated with sample data that illustrates its
usage. The fields and their description are defined in Appendix A.
Note: Chef support in ONAP is not currently available and planned for 4Q
2017.
NC
Configuration Management via Ansible
· VNF Vendor must provide playbooks to be loaded on the
appropriate Ansible Server.
· The VNF Vendor is required to provide a JSON file for each
supported action for the VNF. The JSON file must contain key value pairs
with all relevant values populated with sample data that illustrates its
usage. The fields and their description are defined in Appendix B.
Note: Ansible support in ONAP is not currently available and planned for
4Q 2017.
NC
The VNF Package must include configuration scripts for boot sequence
and configuration.
PC
The VNF Vendor must provide configurable parameters (if unable to
conform to YANG model) including VNF attributes/parameters and valid
values, dynamic attributes and cross parameter dependencies (e.g.,
customer provisioning data).
PC
The VNF Vendor must provide documentation for the VNF Policy
Description to manage the VNF runtime lifecycle. The document must
include a description of how the policies (conditions and actions) are
implemented in the VNF.
PC

The VNF Package must include documentation describing the fault,

performance, capacity events/alarms and other event records that are
made available by the VNF. The document must include:
· A unique identification string for the specific VNF, a description of
the problem that caused the error, and steps or procedures to perform
Root Cause Analysis and resolve the issue.
· All events, severity level (e.g., informational, warning, error) and
descriptions including causes/fixes if applicable for the event.
· All events (fault, measurement for VNF Scaling, Syslogs, State
Change and Mobile Flow), that need to be collected at each VM, VNFC
(defined in VNF Guidelines for Network Cloud and ONAP) and for the
overall VNF.
PC
The VNF Vendor must provide an XML file that contains a list of VNF error
codes, descriptions of the error, and possible causes/corrective action.
PC

Provide documentation describing all parameters that are available to

monitor the VNF after instantiation (includes all counters, OIDs, PM data,
KPIs, etc.) that must be collected for reporting purposes. The
documentation must include a list of:
· Monitoring parameters/counters exposed for virtual resource
management and VNF application management.
· KPIs and metrics that need to be collected at each VM for capacity
planning and performance management purposes.
· The monitoring parameters must include latencies, success rates,
retry rates, load and quality (e.g., DPM) for the key transactions/functions
supported by the VNF and those that must be exercised by the VNF in
order to perform its function.
· For each KPI, provide lower and upper limits.
· When relevant, provide a threshold crossing alert point for each KPI
and describe the significance of the threshold crossing.
· For each KPI, identify the suggested actions that need to be
performed when a threshold crossing alert event is recorded.
· Describe any requirements for the monitoring component of tools for
Network Cloud automation and management to provide these records to
components of the VNF.
· When applicable, provide calculators needed to convert raw data
into appropriate reporting artifacts.
PC
The VNF Package must include documentation describing supported VNF
scaling capabilities and capacity limits (e.g., number of users, bandwidth,
throughput, concurrent calls).
PC
The VNF Package must include documentation describing the
characteristics for the VNF reliability and high availability.
PC
The VNF vendor must provide an artifact per VNF that contains all of the
VNF Event Records supported. The artifact should include reference to
the specific release of the VNF Event Stream Common Event Data Model
document it is based on. ( AT&T Service Specification; Service: VES
Event Listener)
PC
The VNF Package must include VNF topology that describes basic
network and application connectivity internal and external to the VNF
including Link type, KPIs, Bandwidth, latency, jitter, QoS (if applicable) for
each interface.
PC

The VNF Package must include VM requirements via a Heat template that
provides the necessary data for:
• VM specifications for all VNF components - for hypervisor, CPU,
memory, storage.
• Network connections, interface connections, internal and external to
VNF.
• High availability redundancy model.
• Scaling/growth VM specifications.
Note: Must comply with the VNF Heat Template Requirements for ONAP.
PC
The VNF Vendor must provide the binaries and images needed to
instantiate the VNF (VNF and VNFC images).
PC
The VNF Vendor must describe scaling capabilities to manage scaling
characteristics of the VNF.
PC
The VNF Package must include documentation describing the tests that
were conducted by the Vendor and the test results.
PC
The VNF Vendor must provide their testing scripts to support testing.
PC
The VNF Vendor must provide software components that can be
packaged with/near the VNF, if needed, to simulate any functions or
systems that connect to the VNF system under test. This component is
necessary only if the existing testing environment does not have the
necessary simulators.
PC
VNFs must provide metrics (e.g., number of sessions, number of
subscribers, number of seats, etc.) to ONAP for tracking every license.
PC
Contract shall define the reporting process and the available reporting
tools. The vendor will have to agree to the process that can be met by
Service Provider reporting infrastructure.
PC
VNF vendors shall enumerate all of the open source licenses their VNF(s)
incorporate.
PC
Audits of Service Provider’s business must not be required.
PC
Vendor functions and metrics that require additional infrastructure such as
a vendor license server for deployment shall not be supported.
PC

Provide clear measurements for licensing purposes to allow automated

scale up/down by the management system.
PC
The vendor must provide the ability to scale up a vendor supplied product
during growth and scale down a vendor supplied product during decline
without “real-time” restrictions based upon vendor permissions.
PC
A universal license key must be provided per VNF to be used as needed
by services (i.e., not tied to a VM instance) as the recommended solution.
The vendor may provide pools of Unique VNF License Keys, where there
is a unique key for each VNF instance as an alternate solution. Licensing
issues should be resolved without interrupting in-service VNFs.
PC
The VNF Vendor must support the metadata about licenses (and their
applicable entitlements) as defined in this document for VNF software, and
any license keys required to authorize use of the VNF software. This
metadata will be used to facilitate onboarding the VNF into the ONAP
environment and automating processes for putting the licenses into use
and managing the full lifecycle of the licenses.
The details of this license model are described in Appendix C.
Note: License metadata support in ONAP is not currently available and
planned for 1Q 2018.
PC
Virtual Network functions (VNFs) must include a NETCONF server
enabling runtime configuration and lifecycle management capabilities. The
NETCONF server embedded in VNFs shall provide a NETCONF interface
fully defined by supplied YANG models.
PC
NETCONF server connection parameters shall be configurable during
virtual machine instantiation through Heat templates where SSH keys,
usernames, passwords, SSH service and SSH port numbers are Heat
template parameters.
PC

Following protocol operations must be implemented:

close-session()- Gracefully close the current session.
commit(confirmed, confirm-timeout) - Commit candidate configuration data
store to the running configuration.
discard-changes() - Revert the candidate configuration datastore to the
running configuration
edit-config(target, default-operation, test-option, error-option, config) - Edit
the target configuration datastore by merging, replacing, creating, or
deleting new config elements.
get(filter) - Retrieve (a filtered subset of) the running configuration and
device state information. This should include the list of VNF supported
schemas.
get-config(source, filter) - Retrieve a (filtered subset of a) configuration
from the configuration datastore source.
kill-session(session) - Force the termination of session.
lock(target) - Lock the configuration datastore target.
unlock(target) - Unlock the configuration datastore target.
PC
Following protocol operations should be implemented:
copy-config(target, source) - Copy the content of the configuration
datastore source to the configuration datastore target.
delete-config(target) - Delete the named configuration datastore target.
get-schema(identifier, version, format) - Retrieve the YANG schema.
PC
All configuration data shall be editable through a NETCONF <edit-config>
operation. Proprietary NETCONF RPCs that make configuration changes
are not sufficient.
PC
By default, the entire configuration of the VNF must be retrievable via
NETCONF's <get-config> and <edit-config>, independently of whether it
was configured via NETCONF or other mechanisms.
PC
The :partial-lock and :partial-unlock capabilities, defined in RFC 5717 must
be supported. This allows multiple independent clients to each write to a
different part of the <running> configuration at the same time.
PC

The :rollback-on-error value for the <error-option> parameter to the <edit-

config> operation must be supported. If any error occurs during the
requested edit operation, then the target database (usually the running
configuration) will be left affected. This provides an 'all-or-nothing' edit
mode for a single <edit-config> request.
PC
The server must support the :startup capability. It will allow the running
configuration to be copied to this special database. It can also be locked
and unlocked.
PC
The :url value must be supported to specify protocol operation source and
target parameters. The capability URI for this feature will indicate which
schemes (e.g., file, https, sftp) that the server supports within a particular
URL value. The 'file' scheme allows for editable local configuration
databases. The other schemes allow for remote storage of configuration
databases.
PC
At least one of the capabilities :candidate or :writable-running must be
implemented. If both :candidate and :writable-running are provided then
two locks should be supported.
PC
The server must fully support the XPath 1.0 specification for filtered
retrieval of configuration and other database contents. The 'type' attribute
within the <filter> parameter for <get> and <get-config> operations may be
set to 'xpath'. The 'select' attribute (which contains the XPath expression)
will also be supported by the server. A server may support partial XPath
retrieval filtering, but it cannot advertise the :xpath capability unless the
entire XPath 1.0 specification is supported.
PC
The :validate capability must be implemented.
PC
If :candidate is supported, :confirmed-commit must be implemented.
PC
The :with-defaults capability [RFC6243] shall be implemented.
PC
Data model discovery and download as defined in [RFC6022] shall be
implemented.
PC
NETCONF Event Notifications [RFC5277] should be implemented.
PC

All data models shall be defined in YANG [RFC6020], and the mapping to
NETCONF shall follow the rules defined in this RFC.
PC
The data model upgrade rules defined in [RFC6020] section 10 should be
followed. All deviations from section 10 rules shall be handled by a built-in
automatic upgrade mechanism.
PC
The VNF must support parallel and simultaneous configuration of separate
objects within itself.
PC
Locking is required if a common object is being manipulated by two
simultaneous NETCONF configuration operations on the same VNF within
the context of the same writable running data store (e.g., if an interface
parameter is being configured then it should be locked out for
configuration by a simultaneous configuration operation on that same
interface parameter).
PC
Locking must be applied based on the sequence of NETCONF operations,
with the first configuration operation locking out all others until completed.
PC
If a VNF needs to lock an object for configuration, the lock must be
permitted at the finest granularity to avoid blocking simultaneous
configuration operations on unrelated objects (e.g., BGP configuration
should not be locked out if an interface is being configured, Entire
Interface configuration should not be locked out if a non-overlapping
parameter on the interface is being configured). The granularity of the lock
must be able to be specified via a restricted or full XPath expression.
PC
All simultaneous configuration operations should guarantee the VNF
configuration integrity (e.g., if a change is attempted to the BUM filter rate
from multiple interfaces on the same EVC, then they need to be
sequenced in the VNF without locking either configuration method out).
PC

To prevent permanent lock-outs, locks must be released:

a. when/if a session applying the lock is terminated (e.g., SSH session
is terminated)
b. when the corresponding <partial-unlock> operation succeeds
c. when a user configured timer has expired forcing the NETCONF SSH
Session termination (i.e., product must expose a configuration knob for a
user setting of a lock expiration timer)
Additionally, to guard against hung NETCONF sessions, another

NETCONF session should be able to initiate the release of the lock by
killing the session owning the lock, using the <kill-session> operation.
PC
The VNF should support simultaneous <commit> operations within the
context of this locking requirements framework.
PC
The supplied YANG code and associated NETCONF servers shall support
all operations, administration and management (OAM) functions available
from the supplier for VNFs.
PC
Sub tree filtering must be supported.
PC
Heartbeat via a <get> with null filter shall be supported.
PC
Get-schema (ietf-netconf-monitoring) must be supported to pull YANG
model over session.
PC
The supplied YANG code shall be validated using the open source
pyang[1] program using the following commands:
$ pyang --verbose --strict <YANG-file-name(s)>
$ echo $!
PC
The echo command must return a zero value otherwise the validation has
failed.
PC
RFC 2020: YANG - A Data Modeling Language for the Network
Configuration Protocol (NETCONF)
PC
RFC 6022: YANG module for NETCONF monitoring
PC

RFC 6470: NETCONF Base Notifications
PC
RFC 6244: An Architecture for Network Management Using NETCONF
and YANG
PC
RFC 6087: Guidelines for Authors and Reviewers of YANG Data Model
Documents
PC
RFC 6991: Common YANG Data Types
PC
RFC 6536: NETCONF Access Control Model
PC
RFC 7223: A YANG Data Model for Interface Management
PC
RFC 7224: IANA Interface Type YANG Module
PC
RFC 7277: A YANG Data Model for IP Management
PC
RFC 7317: A YANG Data Model for System Management
PC
RFC 7407: A YANG Data Model for SNMP Configuration
PC
RFC 4741: NETCONF Configuration Protocol
PC
RFC 4742: Using the NETCONF Configuration Protocol over Secure Shell
(SSH)
PC
RFC 5277: NETCONF Event Notification
PC
RFC 5717: Partial Lock Remote Procedure Call
PC
RFC 6241: NETCONF Configuration Protocol
PC

RFC 6242: Using the Network Configuration Protocol over Secure Shell
PC
The HealthCheck RPC, executes a vendor-defined VNF Healthcheck over
the scope of the entire VNF (e.g., if there are multiple VNFCs, then run a
health check, as appropriate, for all VNFCs). It returns a 200 OK if the test
completes. A JSON object is returned indicating state (healthy, unhealthy),
scope identifier, time-stamp and one or more blocks containing info and
fault information.
If the VNF is unable to run the HealthCheck, return a standard http error
code and message.
Examples:
200
{
"identifier": "scope represented",
"state": "healthy",
"time": "01-01-1000:0000"
}
200
{
"identifier": "scope represented",
"state": "unhealthy",
{[
"info": "System threshold exceeded details",
"fault":
{
"cpuOverall": 0.80,
"cpuThreshold": 0.45
}
]},
"time": "01-01-1000:0000"
}
PC

ONAP will interact with the Chef Server designated to manage a target
VNF. ONAP design allows for the VNF to register with the following types
of Chef Server [1]:
· Chef Server hosted by ONAP: ONAP will provide a Chef Server to
manage a VNF. If this choice is used then it is required that the VNF
Vendor provide all relevant cookbooks to ONAP to be loaded on the Chef
Server.
· Chef Server hosted in Tenant Space: The Chef Server may also be
hosted external to ONAP in tenant space. Same guidelines as ONAP Chef
Server apply. In addition, the owner is required to provide appropriate
credentials to ONAP in order to interact with the Chef Server.
[1] Decision on which Chef Server instance associates with a VNF will be
made on a case-by-case basis depending on VNF, access requirements,
etc. and are outside the scope of this document. The specific criteria for
this would involve considerations like connectivity and access required by
the VNF, security, VNF topology and proprietary cookbooks.
NC
It is required that as part of the installation process, the chef-client on the
VNF be preloaded with validator keys and configuration to register with the
designated Chef Server.
NC
All the endpoints (VMs) of a VNF that contain chef-clients are required to
have routable FQDNs which are used to register with the Chef Server. As
part of invoking VNF actions, ONAP will trigger push jobs against FQDNs
of endpoints for a VNF, if required.
NC
It is recommended that each VNF expose a single endpoint that is
responsible for all functionality.
NC
It is required that the VNF be installed with
· Chef-Client >= 12.0
· Chef push jobs client >= 2.0
NC
Each VNF Vendor is required to make available for loading on appropriate
Chef Server, all relevant Chef artifacts (roles/cookbooks/recipes) required
to execute VNF actions requested by ONAP.
NC

For each supported VNF action, the VNF Vendor is required to provide a
run list of roles/cookbooks/recipes that will perform the desired VNF action
in its entirety as specified by ONAP (see Section 3.5 for list of VNF actions
and requirements), when triggered by a chef-client run list in JSON file.
NC
Roles/cookbooks/recipes invoked for a VNF action must not contain any
instance specific parameters for the VNF. Instead they must accept all
necessary instance specific data from the environment or node object
attributes.
NC
It is required that all configurable parameters in the roles, cookbooks and
recipes that can be set by ONAP, over-ride any default values.
NC
It is required that when executing a VNF action, if the chef-client run
encounters any critical errors/failures, it update status on the Chef Server
appropriately (e.g., via a fail or raise an exception).
NC
If the VNF action requires the output of a chef-client run be made available
(e.g., get running configuration), an attribute, defined as
node[‘PushJobOutput’] must be populated with the desired output on all
nodes in the push job that execute chef-client run.
NC
It is recommended that, for actions that change state of the VNF (e.g.,
configure), the Vendor design appropriate cookbooks that can
automatically ‘rollback’ to the original state in case of any errors.
NC

It is recommended that any chef-client run associated with a VNF action

support callback URLs to return information to ONAP upon completion of
the chef-client run.
· As part of the push job, ONAP will provide two parameters in the
environment of the push job JSON object:
o ‘RequestId’ a unique Id to be used to identify the request,
o ‘CallbackUrl’, the URL to post response back.
· If the CallbackUrl field is empty or missing in the push job, then the
chef-client run need not post the results back via callback.
· If the chef-client run list includes a cookbook/recipe that is callback
capable, it is required to, upon completion of the chef-client run, POST
back on the callback URL, a JSON object as described in Table A2.
· Failure to POST on the Callback Url should not be considered a
critical error. That is, if the chef-client successfully completes the VNF
action, it should reflect this status on the Chef Server regardless of
whether the Callback succeeded or not.
NC

ONAP will utilize an Ansible server in order to manage VNFs that support
Ansible playbooks. We note that Ansible in general does not require the
use of a server. However, this framework has been adopted to align with
ONAP architecture, ease of management and scalability.
All playbooks for the VNF will be hosted on a designated Ansible Server
that meets ONAP Ansible API requirements. ONAP design allows for
VNFs to be managed by an Ansible Server in any of the two following
forms[1]:
· Ansible Server hosted by ONAP: ONAP will provide an Ansible
Server to manage a VNF. If this choice is used then it is required that the
VNF Vendor provide all relevant playbooks to ONAP to be loaded on the
Ansible Server.
· Ansible Server hosted in Tenant Space: Same guidelines as the
ONAP Ansible Server. The Ansible Server must meet the ONAP Ansible
Server API Interface requirements.
[1] Decision on which Ansible Server to use may happen on a case-by-

case basis depending on VNF, access requirements etc. and are outside
the scope of this document. The specific criteria for this could involve
considerations like connectivity and access required by the VNF, security,
VNF topology and proprietary playbooks.
NC
The endpoints (VMs) of a VNF on which playbooks will be executed must
have routable FQDNs that are reachable via the Ansible Server. ONAP
will initiate requests to the Ansible Server for invocation of playbooks
against these end points[1].
[1] Upstream elements must provide the appropriate FQDN in the request
to ONAP for the desired action.
NC
It is recommended that a VNF typically have a single endpoint.
NC
The endpoint VM(s) of a VNF on which an Ansible playbook will be
executed is required to have Python >= 2.7.
NC
The endpoint VM(s) must support SSH and allow SSH access to the
Ansible server in line with Network Cloud Service Provider guidelines for
authentication and access.
NC

An Ansible playbook is a collection of tasks that is executed on the Ansible

server (local host) and/or the target VM (s) in order to complete the
desired action. Each VNF Vendor is required to make available (or load
on VNF Ansible Server) playbooks that conform to the ONAP
requirements.
NC
It is required that each VNF action be supported by invocation of one
playbook[1]. The playbook will be responsible for executing all necessary
tasks (as well as calling other playbooks) to complete the request.
[1] Multiple ONAP actions may map to one playbook.
NC
A playbook must not contain any instance specific parameters. It must
utilize information from key value pairs that will be provided by the
Ansible Server as extra-vars during invocation to execute the desired VNF
action. If the playbook requires files, they must also be supplied using the
methodology detailed in the Ansible Server API.
NC
The Ansible Server will determine if a playbook invoked to execute a VNF
action finished successfully or not using the “PLAY_RECAP” summary in
Ansible log. The playbook will be considered to successfully finish only if
the “PLAY RECAP” section at the end of playbook execution output has no
unreachable hosts and no failed tasks. Otherwise, the playbook will be
considered to have failed.
NC
VNF vendor must design playbooks to allow Ansible Server to infer failure
or success based on the “PLAY_RECAP” capability.
NC
If, as part of a VNF action (e.g., audit), a playbook is required to return any
VNF information, it must be written to a specific set of text files that will be
retrieved and made available by the Ansible Server. The text files must be
written in the same directory as the one from which the playbook is being
executed. A text file must be created for each host the playbook is run on,
with the name ‘<playbook name> <hostname>_results.txt’ into which any
desired output from each respective VM/VNF must be written.
NC

It is recommended that, for actions that change state of the VNF (e.g.,
configure), the VNF Vendor design appropriate playbooks that can
automatically ‘rollback’ to the original state in case of any errors.
NOTE: In case rollback at the playbook level is not supported or possible,
vendor shall provide alternative locking mechanism (e.g., for a small VNF
the rollback mechanism may rely on workflow to terminate and re-
instantiate VNF VMs and then re-run playbook(s)).
NC
VNFs must provide all telemetry (e.g. fault event records, syslog records,
performance records etc.) to ONAP using the model, format and
mechanisms described in this section.
PC
Content delivered from VNFs to ONAP is to be encoded and serialized
using JSON:
JSON
Telemetry data delivered from VNFs to ONAP is to be encoded and
serialized using JSON (RFC 7159) plain text format. High-volume data is
to be encoded and serialized using Avro (http://avro.apache.org/), where
the Avro [1] data format are described using JSON.
• JSON plain text format is preferred for moderate volume data sets
(option 1), as JSON has the advantage of having well-understood simple
processing and being human-readable without additional decoding.
Examples of moderate volume data sets include the fault alarms and
performance alerts, heartbeat messages, measurements used for VNF
scaling and syslogs.
• Binary format using Avro is preferred for high volume data sets (option 2)
such as mobility flow measurements and other high-volume streaming
events (such as mobility signaling events or SIP signaling) or bulk data, as
this will significantly reduce the volume of data to be transmitted. As of the
date of this document, all events are reported using plain text JSON and
REST.
• Avro content is self-documented, using a JSON schema. The JSON
schema is delivered along with the data content
(http://avro.apache.org/docs/current/ ). This means the presence and
position of data fields can be recognized automatically, as well as the data
format, definition and other attributes. Avro content can be serialized as
JSON tagged text or as binary. In binary format, the JSON schema is
included as a separate data block, so the content is not tagged, further
compressing the volume. For streaming data, Avro will read the schema
when the stream is established and apply the schema to the received
content.
In addition to the preferred method (JSON), content can be delivered from

VNFs to ONAP can be encoded and serialized using Google Protocol
Buffers (GPB).
KV-GPB/GPB
Telemetry data delivered using Google Protocol Buffers v3 (proto3) can be
serialized in one of the following methods:
• Key-value Google Protocol Buffers (KV-GPB) is also known as self-

describing GPB:
o keys are strings that correspond to the path of the system resources for
the VNF being monitored.
o values correspond to integers or strings that identify the operational
state of the VNF resource, such a statistics counters and the state of a PC
VNF resource.

The frequency that asynchronous data is delivered will vary based on the
content and how data may be aggregated or grouped together. For
example, alarms and alerts are expected to be delivered as soon as they
appear. In contrast, other content, such as performance measurements,
KPIs or reported network signaling may have various ways of packaging
and delivering content. Some content should be streamed immediately; or
content may be monitored over a time interval, then packaged as
collection of records and delivered as block; or data may be collected until
a package of a certain size has been collected; or content may be
summarized statistically over a time interval, or computed as a KPI, with
the summary or KPI being delivered.
• We expect the reporting frequency to be configurable depending on the
virtual network function’s needs for management. For example, Service
Provider may choose to vary the frequency of collection between normal
and trouble-shooting scenarios.
• Decisions about the frequency of data reporting will affect the size of
delivered data sets, recommended delivery method, and how the data will
be interpreted by ONAP. These considerations should not affect
deserialization and decoding of the data, which will be guided by the
accompanying JSON schema or GPB definition files.
PC

ONAP destinations can be addressed by URLs for RESTful data PUT.

Future data sets may also be addressed by host name and port number
for TCP streaming, or by host name and landing zone directory for SFTP
transfer of bulk files.
• REST using HTTPS delivery of plain text JSON is preferred for moderate
sized asynchronous data sets, and for high volume data sets when
feasible.
• VNFs must have the capability of maintaining a primary and backup DNS
name (URL) for connecting to ONAP collectors, with the ability to switch
between addresses based on conditions defined by policy such as time-
outs, and buffering to store messages until they can be delivered. At its
discretion, the service provider may choose to populate only one collector
address for a VNF. In this case, the network will promptly resolve
connectivity problems caused by a collector or network failure
transparently to the VNF.
• VNFs will be configured with initial address(es) to use at deployment
time. Subsequently, address(es) may be changed through ONAP-defined
policies delivered from ONAP to the VNF using PUTs to a RESTful API, in
the same manner that other controls over data reporting will be controlled
by policy.
• Other options are expected to include:
o REST delivery of binary encoded data sets.
o TCP for high volume streaming asynchronous data sets and for other
high volume data sets. TCP delivery can be used for either JSON or
binary encoded data sets.
o SFTP for asynchronous bulk files, such as bulk files that contain large
volumes of data collected over a long time interval or data collected across
many VNFs. This is not preferred. Preferred is to reorganize the data into
more frequent or more focused data sets, and deliver these by REST or
TCP as appropriate.
o REST for synchronous data, using RESTCONF (e.g., for VNF state
polling).
• The ONAP addresses as data destinations for each VNF must be
provided by ONAP Policy, and may be changed by Policy while the VNF is
in operation. We expect the VNF to be capable of redirecting traffic to
changed destinations with no loss of data, for example from one REST
URL to another, or from one TCP host and port to another.
PC
VNFs are to deliver asynchronous data as data becomes available, or
according to the configured frequency. The delivered data must be
encoded, addressed and delivered as described in the previous
paragraphs.
PC
VNFs are to respond to data requests from ONAP as soon as those
requests are received, as a synchronous response.
PC
Synchronous communication must leverage the RESTCONF/NETCONF
framework used by the ONAP configuration subsystem. This shall include
using YANG configuration models and RESTCONF [RFC8040]
(https://tools.ietf.org/html/rfc8040).
PC
The VNF must respond with content encoded in JSON, as described in the
RESTCONF specification. This way the encoding of a synchronous
communication will be consistent with Avro.
PC

ONAP may request the VNF to deliver the current data for any of the
record types defined in Section 4.2. The VNF must respond by returning
the requested record, populated with the current field values.
Currently the defined record types include fault fields, mobile flow fields,
measurements for VNF scaling fields, and syslog fields. Other record
types will be added in the future as they become standardized and are
made available.
PC
ONAP may request the VNF to deliver granular data on device or
subsystem status or performance, referencing the YANG configuration
model for the VNF. The VNF must respond by returning the requested
data elements.
PC
YANG models can be translated to and from JSON [RFC7951]
(https://tools.ietf.org/html/rfc7951), meaning YANG configuration and
content can be represented via JSON, consistent with Avro, as described
in “Encoding and Serialization” section.
PC
VNFs must support secure connections and transports such as Transport
Layer Security (TLS) protocol [RFC5246]
(https://tools.ietf.org/html/rfc5246) and should adhere to the best current
practices outlined in RFC7525 (https://tools.ietf.org/html/rfc7525).
PC
Access to ONAP and to VNFs, and creation of connections, must be
controlled through secure credentials, log-on and exchange mechanisms.
PC
Data in motion must be carried only over secure connections.
PC
Service Providers require that any content containing Sensitive Personal
Information (SPI) or certain proprietary data must be encrypted, in addition
to applying the regular procedures for securing access and delivery.
PC

Dockerized application, providing micro-service, to be integrated with

AT&T ONAP/DCAE
Detailed specification for Docker applications:
http://dcae-platform.research.att.com/components/component-
specification/start-here/
NC
Process SAS-CBSD messages through appropriate JSON arrays defined
in WinnForum document WINNF-TS-0016 SAS to CBSD Technical
Specification sections 9.1 and 10
FC
Translate SAS-CBSD messages into pre-defined events, where policy
identifies actions to be taken.
PC
Translate CBSD event messages into SAS-CBSD (WINNF-TS-0016 )
messages to be forwarded to SAS via DP
FC
Receive registration response messages from SAS and take appropriate
action (i.e. successful registration responses shall contain a cbsdid which
EMS-DP shall match and use on behalf of the CBSD for all subsequent
procedures with SAS and unsuccessful registration responses from the
SAS which does not contain a cbsdid will be matched to its CBSD)
FC
Keep a record of the mappings between SAS assigned cbsdid and RAN
CBSD managed node ID in the network
FC
Process spectrum inquiry requests and responses on behalf of one or
many CBSDs and take the appropriate action as defined in WinnForum
document WINNF-TS-0016 SAS to CBSD Technical Specification section
8.4
FC
Send Grant requests to SAS on behalf of one or many CBSDs
FC
Receive Grant response messages from SAS and match them to the
appropriate CBSD originating the request
FC
Send Heartbeat requests to SAS on behalf of one or many CBSDs
FC
Receive Heartbeat response messages from SAS and match them to the
originating request; if this is the initial Heartbeat request after a successful
Grant response then EMS-DP shall take appropriate actions to initiate
radio transmission
FC
Send Grant Relinquishment requests to SAS on behalf one or many
CBSDs
FC

Receive Grant Relinquishment response messages from SAS and match

them to the originating request; if successful the associated CBSD no
longer would have authorization to use the spectrum associated with the
Grant; if unsuccessful and invalid value is received EMS-DP shall match it
to the originating request for which the CBSD shall immediately terminate
transmission and consider itself Unregistered
FC
Send Deregistration requests on behalf of one or many CBSDs to SAS
FC
Receive Deregistration response messages from SAS and match them to
the originating request; if Deregistration operation succeeds or fails, the
CBSD should consider itself as Unregistered
FC
Keep SAS CBSD registration records up-to-date, for example RF channel
and power level changes, when EMS receives such change requests from
external applications and tools like SON/SAS for optimization; this might
require EMS-DP to re-register the CBSD by performing a deregister
followed by a register procedure
PC
All requests to and from SAS/CBSD to be processed and sent to
destination in less than 5 seconds
FC
What is your recommended approach for O&M tools (OSS) when
introducing your 5G technologies and why?
FC

Through providing a high-level description and diagrams, how do you see

the O&M for your 5G macro radio products being deployed and operated?
FC
Describe your OSS Platform.
FC
What capabilities / domains does your OSS Platform support? (Detail all
domains of operational processes and make explicit whether it is RAN,
Transmission or Both).
FC

What OSS components are core to your 5G solution?
FC
What data storage levels (all data) will you supply in your O&M solution,
and why are those levels being offered?
FC
How will your platform scale?
FC
Being able to upgrade an OSS platform with no O&M service disruption is
a real asset to us. How will your solutions accommodate this and ensure
zero downtime when upgrading to support the next software release?
FC
What is your approach to Virtualisation?
FC
How do you work with industry commodity hardware?
FC

How would you coexist with existing technology?
FC
What “legacy” data is important for managing your 5G solutions, and why
is it needed?
FC
What levels of integration will exist for other 5G network element suppliers
rather than your own? Please provide examples that are either in place or
being considered.
FC
How will your OSS Platform ensure that data is meaningful?
FC
How will your OSS Platform discover network element data?
FC
How will data integrity be maintained to 100% accuracy?
FC

What problems do you envisage will need to be managed to support data

integrity?
FC
How will Plug and Play work?
FC
How is self-discovery managed?
FC
What level of pre-integration is offered in your solution?
FC

What will be your approach to data segregation whether it be by Operator

or by PLMN?
There must be improved OSS capabilities to support operational
processes.
FC
What tasks would be automatic and those which would be semi-
automatic?
FC
How will the 5G network elements be optimised once installed and
commissioned?
FC
What level of AI will be employed to achieve this?
FC

In your 5G NR solutions what will your approach be to SON?
FC

How will you 5G NR solutions perform Self-Healing?
FC
How do you envisage that coverage is modelled with your 5G radio
solutions?
FC
What will be the key attributes for the 5G radio solution that will be needed
for coverage prediction?
FC
What capabilities will you provide to allow real time data to be available?
FC

What is your definition of near real time?
FC
Will you be able to provide actual REAL TIME?
FC
What GIS capabilities will provide and why do you see that they will be
beneficial?
FC
How have you brought operational experience into designing the reporting
capabilities?
FC

What is your recommendation on the Business Organisational structure to

manage 5G when supplied by you and or another supplier?
FC
Please indicate the timing when the currently supported LTE SON features
will be supported by his NR products.
FC

Please describe your abilities to support customer self-care functions.

Possible aspects could be:
• Realization on BSS or OSS layer? Why?
• Do you even see both layers in the future?
 If no: Why? Is the reason, that management principles of a future OSS
layer may apply also for products?
 If yes: Does the border in between shift?
• Which use-cases do you support for such self-service portals?
FC
What are your ideas and solutions enabling the definition and
management of a global network (slice), covering many local resources in
separate networks?
FC
Please state your concept to cover the increasing variety of different

players within the Managed Environment but also within the Management
Domain. What (defacto) standards are supported? Please also mention
the related APIs, modeling languages and potential other levers, that you
use to address this topic.
FC
Please share your view on such approaches and whether you are
prepared to integrate or interact with such solutions.
FC

The Supplier’s system shall provide tools to decode trace event data at UE
and Cell level. This data needs to identify which customer service each
event was applicable to (where relevant) by IMSI or other accepted
correlated (within Telstra’s core) customer identifier. These shall include
all layer 3 messages as well as internal proprietary system messages (M).
FC
The Supplier’s system shall be able to correlate trace, event and counter
data where possible to provide end to end visibility at customer/IMSI level
(M).
FC
The Supplier’s system shall be able to monitor at least but not limited to all
network performance as described in following technical specifications
(M).
a. 4G RAN
b. 5G RAN
c. Transport FC
d. ePC integration
The supplier shall demonstrate that all performance monitoring data

collection capabilities, including activation and deactivation of these, can
be completed both with and without a central OSS management platform
using machine – machine micro-service interfaces (HD).
PC
The supplier’s system shall demonstrate a capability to provide visibility to

all Node based error and activity logging information and make that
available for human and machine-machine micro-service level access by
Telstra if required (M)
PC
The Supplier shall provide a capability to manually disable or enable any

Network configuration automation deployed in network (M).
FC
The Supplier’s system shall be able to maintain correctly aligned

configuration data as required to facilitate create neighbour relations to
successfully handover active call/session from/to Telstra’s existing 3G/4G
network zone (M).
FC

The Supplier shall maintain an independent (of the network hardware)

complete and up to date record of intended network element configuration
settings and shall share that with Telstra (M)
FC
The Supplier shall regularly audit actual network element configuration

against an agreed set of standard configurations coupled with site specific
configuration rules and take corrective action where errors are found (M)
FC
The Supplier shall provide Telstra full visibility of the configuration

templates and rules used to define what constitutes valid configuration
data for each network element type and all valid permutations of network
element configuration designs (M)
FC
The Supplier to demonstrate a capability to provide configuration delivery

control and content definition/retrieval mechanisms via published
machine-machine micro-service interfaces in addition to any command
line or GUI interfaces (M)
PC
The supplier shall demonstrate a capability for an operator to define and

run their own automated configuration optimisation and management
algorithms based on reading current state performance and configuration
data and executing a resulting decision in an agreed scheduled automated
way (HD)
PC

The Supplier shall demonstrate a capability to provide access to software

management functionality both via and independent of a central
management system (M).
FC
The Supplier shall demonstrate a capability to provide access to software

management functionality via a published interface as a micro-service (M)
PC
The Supplier shall demonstrate capability to do software upgrades using

APIs on nodes directly or through a support system (M).
PC
The Supplier shall demonstrate capability to manage software licences

using standard API directly on nodes or through a support system (M).
PC
The supplier shall demonstrate their system architecture following micro-

service architecture. The Supplier shall demonstrate and utilise plug in
play integration capability. This is to allow Telstra to decide on which
component to integrate with Telstra’s existing tools and automation
framework (HD). PC
Software upgrade process: The Supplier shall demonstrate automation for

the software upgrade procedures into network nodes (M).
FC
Test automation: The Supplier shall demonstrate automation for software

and configuration behaviour testing before it is deployed into Telstra’s
network to carry customer traffic (HD).
PC
Configuration management: The Supplier shall demonstrate automation

around network configuration and/or network optimisation. A clear
statement on how far the Supplier’s automation systems are from zero
touch configuration management for real world scenarios useful to
Telstra’s network environment and context (M).
PC
The Supplier’s system shall be able to demonstrate capability to deliver

nodes with complete package which includes optimise configuration, test
automation/scripts etc. (HD)
PC
Vulnerability Compliance. – The Supplier shall be able to fix all the

vulnerability identified as part of scan report (M). FC

The Supplier may provide a SON feature to automatically plan 5G cell

identifiers FC
The Supplier may provide a SON feature to automatically plan 5G cell

FC
identifiers
Solution's Trace/Troubleshooting interfaces should be able to send any

and all logs, events, protocol messages (including but not limited to RRC,
MAC, Uu, S1AP/N1AP, F1AP, X2AP/XNAP, DHCP, IPSec, Security, SON PC
logs), and be configurable at a message type level as to which messages
to send via the interface..
The solution must support IPv4/IPv6 dual-stack capabilities for all

FC
interfaces.
The supplier must ensure reporting for SON including all aspects of what
FC
SON is delivering including 3G, 4G and 5G based RAT.
The supplier shall provide licencing management for OSS platforms,

network elements and supporting applications/tools including feature FC
based licences.
TR069 compliant for remote CPE management. FC
TR143 compliant for monitoring and performance of CPE. NC
Provide service view of customers supported by CPE. FC
The supplier shall propose the local and remote backup solution at
FC
OS/DB/Application and including CPE configurations.
The solution for CPE management must be vendor agnostic and
FC
demonstrate the interoperability with multi- vendor CPE devices.
What approach is used for OAM communication between CU/DU & OSS?
FC
Eg separate OAM links from OSS to all CUs and from OSS to all DUs?

How will the 5G elements be integrated, what level of automation will there
FC
be for integrating elements?
How will Plug and Play work? FC
What will be your approach to data segregation whether it be by Operator

FC
or by PLMN?
How will the 5G network elements be optimised once installed and

FC
commissioned?
In your 5G NR solutions what will your approach be to SON? FC

In your 5G NR solutions what will your approach be to SON? FC
What is your recommendation on the Business Organisational structure to

FC
manage 5G when supplied by you and or another supplier?

What is your view on the use of Fault-data and why? FC
Vendor shall describe their 5G RAN zero touch auto provision (or Plug and
Play) solution.
a. For scenarios including (1) new deployment, (2) software upgrade, (3)
capacity expansion, (4) new feature introduction and (5) other network
changes.
FC
b. For scenarios including network element or component changes: (1)
Macro/Small cells, (2) AAU, (3) BBP boards/Control Boards or (4) CD/DU
and (5) transport network (including backhaul, front-haul and middle-haul if
applicable).

Vendor shall describe how NG RAN decides the necessary cell

configurations, e.g. identifications, power settings, UU channels, beam
FC
configurations, Xn/NG interfaces etc., focusing on how these parameters
can be automatically decided (and optimized) if applicable.
Vendor shall describe their overall vision on 5G self-organizing capability,

with regard to:
a. The overall SON architecture, including DSON (Distributed SON,
located in 5G-RAN) and CSON (Centralized SON).
b. Self-Planning: The capability to plan NG RAN features, i.e. when to
enable or disable the feature to get the gain or avoid negative impacts.
c. Self-Configuration and Optimization: The capability to auto-configure FC
NG- RAN function parameters based on specific network scenarios or
conditions, and adjust them when conditions change.
d. Smart Operation: the capability to improve operation efficiency and save
operation cost. Some examples are interference hunting, hardware failure
prediction.

Comparing with LTE, please describe network operation and optimization

challenges introduced by 5G and the automation opportunities to address FC
those challenges.
Vendor should present the data types of en-gNB which broadcast in the
NSA system, and if there is an automatic configuration method based on FC
this data, explain the detailed operation procedure.
When supporting the automatic configuration based on the internal

solution in the NSA system, explain the detailed Automatic SeNB FC
Configuration operation procedure.
The BBU shall support Plug&Play function, and when the BBU is powered
ON and connected with backhaul, it shall be the in-service enable status
by automatically performing the following functions within 5 minutes:
FC
automatic assignment of the BBU IP, creating VM, applying SW (based on
the application of new S/W), Config operation, and automatic registration
of BBU on EMS and CU.

The RRH shall support Plug&Play function, and when the BBU is powered
ON and connected with backhaul, it shall be the in-service enable status
by automatically performing the following functions within 1 minute: FC
applying SW or firmware (based on the application of new S/W), Config
operation, and automatic registration on EMS/CU/BBU.

Response
Name
The capacity per EMS can exceed more than 10,000 Cells. The
max number of gNBs is related to its cell number. The cell
number of per gNB is not same, so usually we take the cell
number to measure the capacity of EMS. And with our evolution
of U2020, the capacity will be bigger, U2020 will start from
2019.06.30.
Huawei EMS supports querying the change history information of

configuration.
Huawei EMS supports ID management function.
The help information is in English.
All the information is supported with GUI display.

a) Network Element Level: Topo.
b) Rack/Shelf Level: Device Panel.
c) Unit/Board level, Virtualization Function level: MANO.
The function to display and input the gNB name can be supported
in English.
Huawei EMS supports the quick migration between EMS.
Only English help information is supported.
The alarm code is unique, of which can separate alarm code for
each NE of the gNB.
The alarm contains detail information report by NE.

Huawei can collect and provide call failed reason related

information, but the detail field will need to be deep discuss with
customer
Huawei will not support requirement g), because the U2000
doesn't support real-time analysis.
Huawei will support Call Fail Log with 1-minute basis.
NR protocol about UE MDT has not frozen, Huawei will follow

latest 3GPP Release 15 Standard (+3month after the standard
frozen) if UE MDT will be standardized.
Huawei EMS supports batch job, the average time of executing 4

MMLs is 1 second.
Issuing MML Commands in Batches in Command Line Interface.

Huawei is willing to discuss with Operator about the NBI

requirement in 5G. If the specifications are same as 4G, we can
provide this function after Operator confirm the bid + 6month.
IPv6 is not supported.
Huawei is willing to dicuss with AT&T for the ONAP integtation

including ONAP specifications and timeline.
Huawei will support Netconf/YANG.
Huawei suggests an interim adapter based solution to support

AT&T’s initial 5G test and deployment
Currently, Huawei solution doesn't support integrate with ONAP.



Huawei will provide the required VNF documentation to AT&T.

Huawei suggest to integrate with ONAP by Huawei VNFM and
Huawei adaptor. And Huawei is willing to discuss with AT&T for
ONAP integration.
Note: Huawei VNF have already provided document about VNF
Management APIs (restful,mml api) in ETSI NFV Architecture
(VNFM+NFVI+VNF)

ONAP integration.
(VNFM+NFVI+VNF)

ONAP integration.
(VNFM+NFVI+VNF)

Huawei will provide Netconf/YANG.

Huawei is willing to discuss these requirements with AT&T.

Huawei VNF use docker technologies, and have a built-in

kubernetes liked software for application lifecycle management

Huawei will provide the required VNF documentation to AT&T

and is willing to discuss with AT&T for detailed ONAP integration
requirements.

requirements.
Huawei will provide the required VNF information to AT&T when

VNF is ready for delivering. Huawei suggest to integrate with
ONAP by Huawei VNFM and Huawei adaptor. And Huawei is
willing to discuss with AT&T for ONAP integration.


VNF is ready for delivering.
note:Huawei VNF have already provided fault, performance,
capacity events/alarms reference document in ETSI NFV
Architecture (VNFM+NFVI+VNF)



requirements.
Huawei is willing to discuss with AT&T for detailed ONAP

integration requirements.





Note: Huawei VNF have already provided the information in
image file in ETSI NFV Architecture (VNFM+NFVI+VNF)

Note: Huawei have already supported scaling capability in ETSI
NFV Architecture (VNFM+NFVI+VNF)



VNF is ready for delivering

Huawei adaptor.






Huawei adaptor.

Note:Huawei VNF have already provided the sacling ability in
ETSI NFV Architecture (VNFM+NFVI+VNF)

VNF is ready for delivering

Huawei adaptor.

AT&T’s initial 5G test and deployment. Huawei is willing to dicuss
with AT&T for detailed ONAP integtation requirements























































































Huawei is willing to dicuss with AT&T for the detailed ONAP

integtation requirements
















Huawei VNFM support sensitive data protection by following

policies:
1)A password must be saved in the authentication system in
cipher texts. A password must be encrypted using an irreversible
algorithm if the password does not need to be decrypted.
2) Sensitive data must be transmitted over encrypted channels or
after being encrypted.
3) Access to sensitive data must be authorized and
authenticated.
4) Passwords cannot be stored in memories and must be
encrypted before being stored.
5) Private encryption algorithms are not used.

Huawei is willing to discuss the details including ONAP

specifications and timeline with AT&T.



Huawei next generation OSS shall be a cloud based network

management system, offering capacity scale out for management
of huge networks, providing a high platform availability and
service related operation, installation and upgrade. From Huawei
point of view, a transition from Network-Centric O&M towards
Service-Centric operation is vital for 5G networks. Huawei offers
enhanced data analysis and automation tasks within the 5G OSS.

As the intelligent management system, mAOS (MBB Agile

Operations System) provides service-oriented agile operation
and maintenance system. mAOS is the O&M product to manage
5G macro radio products. It includes a collection and analysis
modeul plus three base modules:
Data Analysis: This module collects multiple types of data from
RAN network elements. It embeds powerful technologies to
efficiently parse, store and move data. In addition it offers
extended service functions for up-stream applications and
services
Optimization: This module is an evolution of Huawei SON
management tool SONMaster. It offers Self Organizing,
optimization and automation functionality for 2G/3G/4G and 5G
networks.
Evaluation: The Evaluation module provides insight into actual
network, service and scenario performance for analysis and
planning purposes. It is the evolution step for Huawei PRS
system.
Provisioning: This is a new module within the Huawei OSS suite.
It is responsible for service provisioning and offers pre-evaluation
and deployment functionality as well as an Open API for system
integration.
The existing Network management system for fundamental
network operation, the U2000 still remains and will evolve to
U2020.
U2020 is the Huawei cloudified MBB Network Management

System.
Data Analysis module provides the foundation of network
automation and machine learning algorithm.
Provisioning: Provides downstream function, such as network
slicing; this function translates service requests to network
requests and deploy new services automatically.
Evaluation: Provides upstream function, such as capacity,
coverage, throughput, experience visualization, also include IoT
evaluation, such as availability, battery life.
Optimization: Provides functionalities for organization and
optimization in a closed-loop manner. In 5G era, Optimization
needs to be an integrated functionality and cannot seen as “Add-
On” anymore. It will incorporate downstream and upstream
functions and integrate with the auto O&M workflow.
About the 5G network OSS for RAN domain, Huawei OSS

platform is based on Cloud technology, Service Oriented
Approach (SOA), Micro Services and Web-Technologies.
The OSS applications are split between the element
management layer and the service management layer. The
U2020 element management system offers similar functionality
as before and the other is the Service-oriented mAOS
management system. The element management system U2020
can be upgraded smoothly from U2000. The functions of the new
Huawei network and service management system mAOS are
mostly inherited from the previous SONMaster and PRS
systems.
Huawei 5G OSS provides the following key capability: SOA

orientation, Web UI for best user experience, Scale Out for
network expansion, high management capacity for huge network
support and High Availability for continuous network operation.
Huawei 5G OSS is comprised of E2E process for multi-domain,
including RAN and Transmission.

Core components of Huawei 5G OSS are the U2020 and the

mAOS products. Both offering Cloud, SOA, Micro Service and
Web technologies.
U2020 is responsible for the basic FCAPS related NE
management whereas mAOS is responsible for the higher
management tasks, such as Data Analytics, Provisioning,
Evaluation and Optimization.
Huawei 5G OSS will store three levels of data storage, including

static data storage, dynamic data storage, and operating system
data storage. Dynamic service data is data related to alarm and
performance data. Static data is configuration data related to the
OSS server software and the device files of the database.
Operating system data is the data related to the operating system
installed on the OSS server.
mAOS supports multiple cloud computing platforms such as

VMware, OpenStack or KVM. Huawei offers two options: 1/ Pre-
integration option 2/ Per Integration option with VMware,
OpenStack or KVM. Huawei 5G OSS complies with the Cloud
architecture and its virtual resources offers a management
capacity of more than 20,000 equivalent NEs.
In current U2000 release, Huawei OSS already introduces the

Emergency System for minimum the upgrading downtime within
5 minutes. The emergency system can take over services of the
primary system to provide basic network monitoring and
maintenance.
Based on Cloud, SOA and Micro Service technology, Huawei 5G
OSS is able to provide the capability for zero downtime during
upgrade in the year 2020.
Huawei is the leader in providing virtualization platform solutions

for the wireless OSS system based on its service and
architecture characteristics. Virtualization software defines and
divides information technology (IT) resources, including:
CPUs/Memory/Disks/Network interface cards (NICs)/Application
programs. Virtualization software dynamically allocates and
schedules IT resources to virtual machines (VMs), increasing the
usage of existing resources. Huawei offers two main options for
5G OSS virtual deployment (1/ Pre-integrationn of our SW on top
of Huawei Cloud SW and HW which includes E2E responsibility
and 2/ Per integration of our SW into customers datacentre based
on VMware, OpenStack, KVM which limits Huawei E2E
responsibility). Multiple HW and CloudOS options are supported.
Huawei aims to be as close as possible to the customer needs in
order to ensure a smooth 5G OSS introduction.
Huawei virtualisation solution deploys the OSS product on a

virtualized platform and use virtual resources provided by a
universal x86 hardware platform and a couple of preferred
CloudOS.

The Huawei 5G OSS architecture not only supports the

integration with Next Generation network, but also includes the
management of existing 2G, 3G, 4G and NR within one Wireless
management Domain.
In Huawei 5G OSS solution, the legacy data model and data

content for 2G/3G/4G networks will be supported. From Huawei
point of view, a future OSS system needs to provide a complete
view on the complete legacy + future network.
Basically, U2020 and mAOS are released and tested for Huawei
networks only. In case special 5G use case like network slicing
management or E2E management requires other vendor
integration, these cases have to be individually discussed and
agreed between Huawei and customer.
U2020 as well as mAOS provide a powerful web GUI towards

different “user” within different roles. It is ensured, that data
presentation is related to the task a user has to perform on the
system. For different task, U2020 and mAOS will provide different
applications for the user, e.g. CME for CM management, alarm
browser for FM, Software Management application to maintain
the SW in the network, SON for optimization tasks.
The “system” and its internal data processing has access to data
on need base as well. By nature, Data Analytics within mAOS
has to most powerful access to data within the systems.
For example in CM area, U2020 provides the dedicated CME
tools for data configuration integrity, redundancy, consistency
verification and health checking mechanism for data of whole
systems.
NE data discovery depends on the management area, e.g. alarm

information is immediately send to OSS, configuration change as
well. Performance data are send according to the related
scenario, e.g. in real time, in 5 min granularity or 60 min interval.
E.g. When the configuration of network element is modified, the
NE reports a modification notification to the OSS. Then, the OSS
updates the NE configuration data in the database according to
the notification.
On the user level for configuration management for example,

Huawei OSS provides the consistency check and data check via
configuration module. It allows user to perform integrity,
redundancy, correction checks on the configuration data. This
improves configuration data accuracy and reduces the amount of
useless data. On the system level, the use of database
applications, Hadoop File System and other mechanism ensuring
data integrity. Relevant changes on user and system level are
subject of data logging which also can be used for rollback
actions.

Basic concept for data integrity is “access only on need base”

This will ensure that only skilled people can access sensitive
data, Huawei OSS will support on application level with
appropriate mechanism like integrity or syntax check.
On system level, Huawei NBI and Open API shall be used to
connect Huawei OSS with other systems. Only the use of official
integration points will ensure data integrity.
On the main configuration management application CME, Huawei
also provides the following modes for restoring incorrect data
based on check results to manage the integrity issues:
• GUI-based data editing: The CME provides a general
configuration window for users to modify related configuration
data.
• Wizard-based data update: The CME provides modification
suggestions for users.
• Automatic restoration: The CME automatically changes the
parameter values to the recommended values.
Huawei 5G OSS support PnP for 2G/3G/4G and 5G Network

Elements. Basically it involves the following procedures, which
can be customized based on application scenarios: 1.Automatic
detection 2.Automatic configuration 3.Automatic planning
4.Delivery of commissioning licenses 5.Installation & deployment
quality testing.
User imports a site deployment list to the OSS. The list contains
data required for site deployment, such as site names, target
version number, ESNs, and IP addresses. The OSS creates site
in GUI, based on the deployment list. After O&M personnel select
target site on the GUI and start deployment, the OSS
automatically checks whether the required data is available. If no
exception occurs, the OSS automatically performs site
deployment without human intervention.
The OSS assigns IP addresses to the selected sites using DHCP
and automatically sets up O&M channels to the sites.
Huawei 5G OSS provides several levels of pre-integration:

- On platform level the NFV architecture can be pre-integrated
with COTS HW, the CloudOS and Huawei VNFM and CSM
- Furthermore Huawei ensures compatibility with other CloudOS
like VMware, OpenStack and KVM
- On Huawei 5G OSS application level, all U2020 application are
integrated as well as all mAOS applications incl. NBI and Open
API
- A common user management across all U2020 and mAOS
applications
- On NBI system integration level, several pre-integrations with
other OSS vendors, e.g. HP are available.

In the dedicated carrier RAN sharing solution, telecom operators

do not share radio network spectrums. Instead, they have their
own CNs and share RAN devices.
In the MOCN solution, all resources including spectrums on the
entire RAN are shared.
The U2000/U2020 O&M solution supports these two RAN
sharing solutions. U2020 enables operators to share network
resources and data while ensuring their privacy and security for
each them.
The design of mAOS enables the network administrator to run

the optimization tasks in two modes. The first mode is the open
loop mode or semi-automatic and the second mode is the closed
loop mode or automatic. Like all fully automatic system, there is
always an appropriation phase to make sure the system runs the
way it should. When the appropriation phase is over, Huawei
thinks that tasks having to optimize parameters in the millisecond
time frame will have to be done in the automatic manner. Other
tasks planning optimization in the long term can used the open
loop or semi-automatic manner. mAOS delivers optimization
advice which be applied or not by the network administrators.
Whatever the mode used, our system logs all actions enabling
the network administrator to understand what was recommended
and done. Right now the management of neighbour relationships
is done automatically. Other tasks like balancing the load in a
very short time frame or even in a predictive manner due to
unexpected or spontaneous gathering of a crowd could be done
automatically as well.
Once 5G NEs are deployed, installed and commissioned, mAOS

with its evaluation, optimization and provisioning components has
the ability to optimize the 5G NEs in real time or near real time.
The analysis module leverages efficient technologies like Hadoop
to collect, organize and store data efficiently. Once data are
collected, the evaluation component assesses the area or the NE
to optimize. The optimization itself is then performed by the
optimization component (NG SON).
We are far from the end of the AI journey. In fact we are just at
the beginning. Huawei works on multiple directions on AI. Deep
and Reinforcement learning are part of the promising AI
technology. We do work on KPI-based hidden incident detection,
traffic prediction, VoLTE optimization, KPI-based cell load
management, AI-based coverage optimization, cell edge user
throughput enhancement or AI-Based mMIMO Pattern Selection
Huawei would be pleased to discuss further with to understand
what you expect from AI by 2020

The focus of the operation of future networks is changing from

network-centric to service- and user- centric experience. Huawei
has planned scenario- and service- based SON functions
For example,
Motorway Optimization – Focus on motorway network
performance optimization and on the improvement of the
end(user experience.
Indoor MBB Optimization – Focus on the optimization of indoor
network performance and on the improvement of the end-user
experience.
VoLTE Optimization – Monitor and optimize the quality of VoLTE.
Massive Event Optimization – The gathering of people or a crowd
generates a intensive stress on the network. Our solution offers
to optimize the network during big event scenarios, control the
network congestion and handle the increased traffic generated
The features described above are useful for both legacy 3G and
4G networks and also for 5G. Furthermore, in 5G with the advent
of new technologies and services. Require new SON functions
which are under planning:
Power on demand - Intelligent energy saving on massive MIMO
scenario.
Optimization for IoT–Special requirements for IoT (e.g. wide
coverage, low power consuming) need new ways to optimize the
network.
Super dense site and mmWave site optimization – In super
dense areas or sites equipped with millimetre waves, coverage
and interference issues will be more important as large number of
sites and shorter distances between sites will be used.
Regarding the existing SON functions (e.g. MLB, ANR, CCO),
adaptions are also needed to meet the 5G new architecture and
networking characteristics.

mAOS embeds an optimization component including self –

configuration, -optimization and –healing blocks. mAOS provides
a Cell Outage Detection and Recovery and Cell Outage
Detection and Compensation features. These two features are
part of the self-healing features included in mAOS. With the Cell
Outage Detection and Recovery feature, OSS detects and
recovers the cell in outage. With the Cell Outage Detection and
Compensation feature, the OSS detects and compensates the
cell in outage via adjusting antennas of neighbouring cells.
During the different phases of the life cycles of the network slice
instances, SON is used to achieve the automated management
and orchestration of the network slice instances. For network
slice instances running, SON algorithms identify the failures of
network slice instances and correct the failures with corrective
appropriate actions. Network functions composing the network
slice instances support fast failure recovery and healing
mechanisms. This enables an automatic convergence of the
affected network functions to a stable and desired state. The
results of Self-Healing needs to be notified to the operator.
Service-based coverage maps are available to different

application types such as VoLTE, WTTx, Motorway or NB-IoT
Coverage. For NB-IoT for instance, the requirement in terms of
coverage are more important than the one for MBB basic
services. Default values for received signal strengths (RSS) for
colouring the maps are set during at the installation. These
thresholds are modifiable.
Call drop rates, throughputs and the received signal strengths are
the key KPIs to monitor for an optimal and predictive coverage.
The reinforcement learning capability is a good candidate to
deliver an AI-based coverage optimization mechanism. However
as RL needs an exploratory phase to learn, the RL-based
coverage optimization task will have to find the right trade-off
between exploration and exploitation. This is the key ingredient of
an efficient AI-Based Coverage optimization tool
mAOS collects the network data and analytics in real-time,

enabling real-time policies and appropriate actions. One of the
key characteristics to collect and manage data in real time lies on
the ability of the platform to manipulate data in an efficient
manner. The data analysis component is based on Hadoop
components. The usage of Apache Spark, HDFS or Flume
enable mAOS to be fast, reliable and secure and enable to
manage data in real time

Our current OSS solutions, U2000 or PRS can collect counters

every 5, 15 or 60 minutes. This collection rate is considered as
near real time. Near real time is basically the required time “in
minutes” to collect, analyse and make decisions following an
event. For 5G, the real time telco world will be between 5ms and
500ms. But, new opportunities could be explored like tactile
domains. This domain will require fast data collection at the order
of 1ms or lower. Huawei will be pleased to understand the
definition given by BT for real time, near real time or non- real
time data collection knowing that faster data collection than one
millisecond may open new business opportunities
Yes we will. Huawei has redesigned its OSS portfolio

architecture, now based on SOA, leveraging Hadoop components
to cope with the advent of 5G new applications requiring
reaction time in real time. A fast reaction time will be mandatory
to unleash the potential of 5G, this is why Huawei is fully
committed to this new OSS characteristics.
mAOS is a complete new design and based on the most recent

technologies. Web user interfaces are part of the mAOS portfolio.
These new easy to apprehend interfaces will enable the network
administrators to pin-point issues in the network immediately.
mAOS provides a GIS geographic observation capability to
support the display of sites and cells or carriers geographically., It
also enable to display performance report analysis results
geographically.
Since the beginning, our R&D team closely works with our own
operational teams. The main idea behind is to inject in our OSS
portfolio our unique operational know-how. Our product
development process enables all people using our product
planning tools to inject new requirements or product gap
enhancements in the product development stream. The second
approach is to also work with our customers during the beta
version and after enabling the design of a better product while
reaching a faster time-to-market. Since last year, we have
introduced the concept of DevOps in the planning of our OSS
portfolio and so in our reporting capabilities. This DevOps
capability is named Joint Agile Development. JAD takes into
account the feedback of our own teams and also of our
customers throughout the development and the development
cycle of the product. As a reminder, Huawei OSS enables the
network administrators to create simple custom reports,
comparison reports, combined reports, and database (DB)-based
reports. Custom reports can be modified, deleted, moved,
imported, or exported. Custom reports help the network
administrators to monitor networks. DB-based reports provide
flexible and professional report customization functions to meet
various requirements.

In the context of next generation networks, responsibilities and

roles regarding operations have to be clearly defined and
assigned.
The related protocol is 3GPP TR 28.801, Huawei is actively
participating in discussions on the business model role within
3GPP framework. Huawei is willing to release the latest business
model roles following the 3GPP timing.
Currently, in the draft of 28.801, the following High-level business
roles are included:
Communication Service Customer (CSC): Uses communication
services.
Communication Service Provider (CSP): Provides
communication services (see clause 4.8). Designs, builds and
operates its communication services.
Network Operator (NOP): Provides network services. Designs,
builds and operates its networks to offer such services.
Virtualization Infrastructure Service Provider (VISP): Provides
virtualized infrastructure services. Designs, builds and operates
its virtualization infrastructure(s). Virtualization Infrastructure
Service Providers may also offer their virtualized infrastructure
services to other types of customers including to Communication
Service Providers directly, i.e. without going through the Network
Operator.
Data Centre Service Provider (DCSP): Provides data centre
services. Designs, builds and operates its data centres.
Network Equipment Provider (NEP): Supplies network
equipment. For sake of simplicity, VNF Supplier is considered
here as a type of Network Equipment Provider.
NFVI Supplier: Supplies network function virtualization
infrastructure to its customers.
Hardware Supplier: Supplies hardware.
In Wireless Domain, after the standardization of 5G completed,

Huawei will follow the complete SON function functionalities
which defined by 3GPP, the estimate time is 2019Q2. Huawei is
willing to discuss with customer for the custom SON
requirements in advance.

1. As per Huawei’s understanding, the customer self-service

portals are usually related to BSS, e.g. CRM, product/product set,
marketing, billing etc. BSS layer is still needed because that BSS
is focusing on the business operation towards customers and
OSS is focusing on the network operation towards networks.
Huawei can provide open API or technical portal, including both
tenant portal and admin portal, for BSS system to integrate with.
2. Yes, we probably still see the both layers in the future, but the
border might be shifted. We see that the OSS is evolving into
automated, open and unified system to replace current multiple
silo systems. And we see that the BSS is becoming more
internet-style, social involved and personalized for customers.
Since the OSS is more and more customer-oriented like the BSS,
the border between them must be shift towards customers.
3. Huawei can support E2E slice management demo or PoC for

eMBB and FMA slicing.
Some vertical industries have global operational requirements

(such as IoV), the network slice for IoV needs to be managed
within the scope of globalization. Huawei provides the integration
capabilities through flexible open APIs to support global network
slicing management.
For the adaption of multi-vendor devices, Huawei slices

management system achieves multi-vendor through an open
southbound adaptation framework. Huawei had contributed the
southbound framework to the open source OPEN-O, and are
willing to contribute the southbound framework to ONAP. With
the open source southbound, multi-vendor integration could be
done by the open source community which could accelerate the
commercial process.
For the management layer, Huawei slice management system
uses hierarchical management architecture, including E2E slices
product / service / instance management and single-area sub-
slice management, each layer is decoupled, can be provided by
different vendors. But each layer must provide the 3GPP
standard API.
Huawei’s vision for the future management system is that the

openness and the cloud-based technology are the key to
succeed.
For the openness, Huawei’s overall strategy is to embrace the
formation of a unified and healthy ONAP ecosystem foundation
where we have been actively participating, proactively
collaborating and effectively contributing since its beginning.
For the cloud-based technology, Huawei adopts micro-service
based architecture, which has decoupled functionalities, and
supports flexible scaling of the management capacities.

Huawei OSS supports to decode the trace data by subscriber

tracing and cell tracing via trace ID which is provided by core.
Based on 3GPP TS 32.422, when 3rd MME start one End to End
UE tracing, the MME will auto send tracing information by
standard signalling to eNodeB to start tracing for special UE
which is identified by trace ID, when the UE roaming to the
eNodeB, the eNodeB will automatic traceing and report to U2000
Huawei U2000 supports subscriber tracing. The subscriber

tracing refers to tracing the signalling messages of all the calls of
a specified UE (for example, a VIP UE) on the network within a
certain period. By collecting and analysing statistics of the call
signalling messages, users can locate call faults.
Huawei U2000 network management system could manage

Huawei network devices. It could manage LTE, 5G RAN, and
transmission devices.
Huawei U2000 supports NBI performance interfaces to collect

monitoring data. Huawei will explore further with Telstra on the
machine-machine microservices interface and provide it in
2019Q2.
Huawei provides alarm NBI interface. Huawei will explore further

with Telstra on the machine-machine microservices interface and
provide it in 2019Q2.
Huawei U2000 supports to automatically delivery network

configuration to the site activated by the user.
Huawei OSS provides the automatic neighbour relationship

optimization feature.
The Cell of Huawei eNodeB obtains the 3G neighboring

relationship form the boardcasting message of 3G Cell via UE,
and then adds related neighboring relationship in Huawei SON
solution.

Huawei U2000 support Huawei configuration parameters

mapping to the intended configuration settings. U2000 provides
history configuration data file management. It supports to create
and store multiple configuration parameter baselines of NE in the
different time, and export the configuration parameter baselines.
Huawei U2000 provides current data area and planned data area
via CME. Data in the current data area automatically keeps
consistency with that on the live network. A planned data area is
a replication of the current data area. User can plan configuration
data of the NE as telstra's planning in the planned data areas.
Huawei U2000 allows users to compare live NE configuration

parameters with benchmark configuration parameters.
The parameter comparison can be performed on a scheduled
basis.
U2000 shall modify parameters comparison results based on the
user confirmation.
Huawei U2000 supports the configuration templates such as

base stations, cells, and radio parameters.
Huawei U2000 supports the configuration NBI interface, and it

will be served as micro-service interfaces in 2019Q2.
1. Huawei SON Solution provides automated configuration

optimization and management algorithms, matching the needs of
the most of operators , including ANR(Automatic Neighbor
Relation), MLB(Mobility Load Balancing), PCI, CCO(Capacity
and Coverage Optimization), CODR(Cell Outage Detection and
Compensation), CODC(Cell Outage Detection and Recovery),
MEH(Massive Event Handling) etc.
2. Telstra can define the customized policy to control Huawei
provided features. For example, ANR is used to optimize the
neighbor relation automatically. Operator can define the
intra/inter-freq policy, intra/inter-site policy, distance threshold,
semi/bi-direction, etc. to decide what kind of neighbor relation can
be added.
3. Huawei is willing to discuss with Telstra if there are new
requirements for automated configuration optimization and
management algorithms.

Huawei provides LMT to directly access the network element.

Uese could upload the software and upgrade the software with
MML using LMT.
It is more recommended to manage software through U2000.
U2000 provides an end-to-end upgrade solution,such as risk
check before download and activation,the alarm and cell status
comparison before and after the upgrade, and KPI measurement
results comparison before and after the upgrade.
Huawei U2000 supports to manage software remotely via a

wizard, while not a published interface. Huawei will demonstrate
this feature in 2019Q2.
Huawei U2000 supports to upgrade Node software remotely via a

wizard. Huawei will provide software management api in 2019Q2.
Huawei U2000 supports to manage NE software licenses in the

window. Huawei will provide software licenses management api
in 2019Q2.
Huawei U2000 is based on microservice architecture and Huawei

PAAS platform. U2000 shall provide part of features SOA
reconstruction in 2018, such as Fault Management and MML
interface, and later OSS will provide all the features SOA
reconstruction
Huawei U2000 provides upgrade project management and batch

upgrade mode based on NE upgrade operations. In this way, NE
upgrade management becomes more reasonable by reducing a
large amount of repetitive work. It can also reduce errors caused
by manual operations and improve upgrade efficiency.
Huawei U2000 supports test automation of network functions with

network simulation tool before it is deployed in Telstra's
network.It supports to test alarm, configuration, topology
management, according the pre-integrated configuration. while
not performance and reliability test.
Huawei OSS provides automatic configuration, such as auto-

deployment for base stations and automatic cell configuration for
Lampsite. Huawei OSS also provides automatic network
optimization, such as automatic neighboring relationship
optimization for LTE and PCI optimization.
Huawei OSS provides NE software management to centrally

manage NE version software, patches, licenses, and
configuration data. Scripts are generally not recommended.
Huawei OSS shall fix all the vulnerability identified as part of scan
report.

Huawei provide offline tool to help automatically plan 5G cell

identifiers. R19A
Huawei provide offline tool to help automatically plan 5G cell

R19A
identifiers.
Currently, Huawei supports Trace of RRC, MAC, UU, S1AP,

F1AP, X2AP, DHCP, IPSec messages. But only for those
messages useful for troubleshooting, not all protocol messages.
IN addition, for security part, trace/troubleshooting interface can
send protocol message of IKE,CMPv2, but now message type
can not be configurable. For C-SON, Huawei contains SON log
but does not support sending through NBI.
Huawei U2020 supports both IPv6 and IPv4 addresses. When

this feature is enabled, the southbound and northbound network
isolation solution must be used on the network so that the
southbound network can support both IPv4 and IPv6 IP
addresses and network devices can gradually start using IPv6
addresses.
Huawei SON solution contains D-SON (on network elements)

and C-SON (OSS).
For CSON, 3G: It supports ANR(Automatic Neighbor Relation),
MLB(Mobility Load Balancing), MRO(Mobility Robustness
Optimization), CCO (UMTS DL Coverage Optimization),
Scrambling Code Self-Optimization, MTM (MBB Traffic
Migration), UL Interference Intelligent Management.
4G : It supports ANR(Automatic Neighbor Relation), MLB(Mobility
Load Balancing), CCO (DL Coverage Optimization), PCI Self-
Optimization, Intelligent Network Energy Saving, CODC (Cell
Outage Detection and Compensation - RET Optimization), Multi-
Carrier Strategy Management
While 5G SON ANR, PCI Optimization shall planned in 2019Q2
version.
Huawei U2020 supports NE License Management feature which

includes base station controller, NodeB, eGBTS, CloudEdge, and
standalone license management.
The license management functions are as follows:
- Viewing detailed license information, uploading, activating,
synchronizing, downloading, and deleting license files
- Backing up license files on a scheduled basis
- Activating license files on a scheduled basis
- Exporting license data on a scheduled basis
- Northbound license file interface
Huawei CPE Management Tool (Huawei LTM) supports to

provide the management function for TR-069-based CPEs.
Huawei CPE Management Tool (Huawei LTM) does not support
TR143 compliant for monitoring and performance, only support
TR069 based CPE.
Huawei mAOS supports FWA Map which allows users to import
coverage simulation data and evaluate whether each location
meets number allocation requirements for indoor and outdoor
CPEs.
Huawei CPE Management Tool (Huawei LTM) supports backup
OS/DB/Application to the local or remote server by vOSMU.
With condition that the multi-vendor CPE should pass the IOT
test with Huawei CPE Management Tool (Huawei LTM).
In separate mode (CU/DU split), RANCU_P, RANCU_E, DU are
independent NEs on U2020.. They have independent OAM links
with OSS.

High level integration principle is as follows:

• Using meta-model to support service design for different
requirements
• Supporting fully automatic provisioning, including auto service
decomposition, auto service to resource mapping, auto driving
NBI connection.
• Supporting programmable logics as part of provisioning,
including dimensioning rule, user policy etc.
Huawei 5G OSS supports PnP for 2G/3G/4G and 5G Network

Elements. Basically it involves the following procedures, which
can be customized based on application scenarios: 1.Automatic
detection 2.Automatic configuration 3.Automatic planning
4.Delivery of commissioning licenses 5.Installation & deployment
quality testing.
In the dedicated carrier RAN sharing solution, telecom operators

do not share radio network spectrums. Instead, they have their
own CNs and share RAN devices.
In the MOCN solution, all resources including spectrums on the
entire RAN are shared.
The U2020 O&M solution supports these two RAN sharing
solutions. U2020 enables operators to share network resources
and data while ensuring their privacy and security for each them.
Once 5G NEs are deployed, installed and commissioned, mAOS

with its evaluation, optimization and provisioning components has
the ability to optimize the 5G NEs in real time or near real time.
The analysis module leverages efficient technologies like Hadoop
to collect, organize and store data efficiently. Once data are
collected, the evaluation component assesses the area or the NE
to optimize. The optimization itself is then performed by the
optimization component (NG SON).

For example,
performance optimization and on the improvement of the end-
user experience.
experience.
generates an intensive stress on the network. Our solution offers
scenario.
network.


For example,
performance optimization and on the improvement of the end-
user experience.
experience.
generates an intensive stress on the network. Our solution offers
scenario.
network.
In the context of next generation networks, responsibilities and

roles regarding operations have to be clearly defined and
assigned.
The related protocol is 3GPP TR 28.801, Huawei is actively
participating in discussions on the business model role within
3GPP framework. Huawei is willing to release the latest business
model roles following the 3GPP timing.
Currently, in the draft of 28.801, the following High-level business
roles are included:
Communication Service Customer (CSC): Uses communication
services.
Communication Service Provider (CSP): Provides
communication services (see clause 4.8). Designs, builds and
operates its communication services.
Network Operator (NOP): Provides network services. Designs,
builds and operates its networks to offer such services.
Virtualization Infrastructure Service Provider (VISP): Provides
virtualized infrastructure services. Designs, builds and operates
its virtualization infrastructure(s). Virtualization Infrastructure
Service Providers may also offer their virtualized infrastructure
services to other types of customers including to Communication
Service Providers directly, i.e. without going through the Network
Operator.
Data Centre Service Provider (DCSP): Provides data centre
services. Designs, builds and operates its data centres.
Network Equipment Provider (NEP): Supplies network
equipment. For sake of simplicity, VNF Supplier is considered
here as a type of Network Equipment Provider.
NFVI Supplier: Supplies network function virtualization
infrastructure to its customers.
Hardware Supplier: Supplies hardware.

Fault management (FM) is one of the FCAPS functions defined

for the telecommunications management network (TMN). The
purpose of FM is to ensure normal operation of devices and
quality of service (QoS) of networks. To achieve this, FM
centrally detects and records network device faults/alarms,
notifies maintenance engineers of these faults/alarms in different
ways, and provides troubleshooting methods for the engineers to
quickly locate and rectify faults.
Huawei 5G RAN site can support Plug and Play provisioning. The
5G RAN site will establish OMCH automatically, the U2020
instructs the gNB to start the software upgrade. Then, the gNB
automatically downloads the software and configuration data
from U2020 via OMCH and completes the software upgrade and
data loading.
Here is the procedure of Automatic OMCH establishment.
a. For (1) and (3), a Huawei 5G RAN site can be deployed using
PnP when the configuration is set up on the U2020, and related
DHCP servers are configured to ensure successful automatic
OMCH establishment. For (2), (4) and (5), the Huawei 5G RAN
can support remote operation by the OSS.
The feature "NE Software Management"supports software
upgrades, new features can be introduced by the Feature
Operation Management, and the centralized command line
feature allows users to modify the configuration of an NE.
b. For (1) , (2) and (3), a Huawei 5G RAN site can be deployed
using PnP when the configuration is set up on the U2020, and
related DHCP servers are configured to ensure successful
automatic OMCH establishment. For (4), there is no preloaded
software on CU@COTS, so the CU@ COTS can be deployed by
PnP when the IaaS (Infrastructure-as-a-Service) is up and
running. For (5), the transport network (backhaul and middle-
haul) can support topology self-discovery when the access
network supports LLDP. Front haul can support topology self-
discovery.

Huawei’s SON solution supports automatic neighbor relationship,

PCI optimization, X2/XN self-configuration. The SSB beam
configurations can be optimized by mAOS.
1. Measurement event-triggered ANR—automatic detection of
missing neighboring cells:
- gNodeB sends Measurement Control to UE to perform the
measurement of surrounding cells,
- UE performs measurements on the cells and reports it to the
cells which sent the measurement command,
- upon reception of the measurement report, if the PCI is not in
the NRT (Neighboring Relationship Table),the gNB requests the
UE report CGI of the neighboring cell,
- The cell extracts the cell information from the measurement
report message and updates the NRT.
2. The 5G PCI conflict detection can be deployed in a gNodeB as

a D-SON (Distributed SON) function. The 5G PCI Optimization
can be deployed in OSS as a C-SON (Centralized SON) function.
3. Supports self-establishment, self-updating, and self-delete of
NG-C interface. Supports self-establishment and self-delete of
NG-U interface.
Xn self establishment refers to not configuring the Xn link and the
peer gNB address information in advance, rather only configuring
the Xn local address information, triggering the signaling
interaction to obtain the address of the opposite end gNB through
the user NG handover process, and automatically establishing
the Xn link.
4. Beam configurations: the SSB beam configurations can be
optimized by mAOS (based on DT/MDT and CHR data), and will
automatically give the beam configuration parameters, such as tilt
and azimuth. The key technologies include analyzing the 3D
traffic distribution and topology, using taboo search algorithms to
get near optimum configurations. For mature commercial
networks, AI algorithms can be used to learn and speed up
optimum parameters setting.
a. As an industry-leading self-organizing network (SON) solution

provider, Huawei’s SON Solution provides functionality relating to
distributed-SON (D-SON) and centralized-SON (C-SON). These
solutions support optimization on multi-RAT, and multi-layer and
automatically improves operation and maintenance (O&M)
efficiency and network performance.
b. Huawei does not support to automaticaly configure neighbor
relationships or PCI, but does support automatic neighbor
relationship and auto optimization after the PCI conflict is
detected.
c. Huawei will improve 5G base station auto-configuration
capabilities over time, for example, some H/W auto configuration,
the relationship between Cell and H/W auto configuration, and
Cell relationship auto configuration.
Huawei mAOS provides a series of auto-optimization features
including: network basic performance optimization, such as ANR/
PCI, etc.
RAN feature enabler optimization, such as Massive-MIMO
optimization.
d. Huawei does not provide hardware failure prediction, but
provides intelligent operation features such as Massive MIMO
pattern Optimization and Intelligent Alarm Correlation.

which brings great challenges to coverage and interference

optimization.
Solution: Massive MIMO Big Data Iteration Automatic
Optimization +AI (Automation)
Challenge: 5G uses the C-Band networking. The uplink edge
coverage is about 11dB lower than the downlink coverage, and
the uplink coverage and capacity are also severely limited.
Solution: Uplink and Downlink Decoupling Optimization
(Automatic)
Challenge: 5G High-bandwidth, low-latency, and large-
connection services have higher requirements on network
performance and are more sensitive than LTE. Therefore,
network performance problems must be identified, analyzed, and
closed.
Solution: Automatic network performance monitoring and
automatic optimization of basic parameters such as
PCI/neighboring cells automatic optimization.
Challenge: 5G network, the edge MEC, the separated CU/DU,
and network slicing are introduced, and therefore, the difficulty in
demarcating and locating UC problems increases exponentially.
In addition, the network architecture cloudification (NFV/SDN)
extends the demarcation and locating scope to the IT side, which
contradicts between the demarcation and locating efficiency and
service requirements.
Solution: Automatic Demarcation and Location Based on Expert
Experience Rules and Customized Rule Engine +AI (Man-
Machine Collaboration)
Challenge: 5G bears massive types of applications. It cannot
perform O&M for various application services, such as quality
monitoring, problem identification, and optimization, and brings
more pressure on operation efficiency and costs.
Solution: SOC Service Quality Visualization Monitoring and
Problem Analysis, UC Service Experience Optimization (Man-
Machine Collaboration)
Challenge: 5G user terminals are expanded from mobile phones
to airdrone, CPEs, and IOT smart devices. The network
performance and user experience evaluation cannot be resolved
by traditional drive tests. Therefore, a new efficient test solution is
required.
Solution: 3D virtual drive test based on the OTT + BSS side data
correlation
Challenge: Operation challenges on E2E (cross domain) slice
management.
Solution: Slice Manager
Challenge: Automation for more complicated network.
Solution: Automation capability based on OWS platform will
provide NOC automatic preventive maintenance, automatic
The eNB sends the CGI message to the core network according
to the received gNB broadcasting message, the core network
sends the gNB IP address in the CGI message to the eNB, and
the eNB automatically establishes an X2 interface to the gNB
according to the IP address. This process is still under discussion
in 3GPP.
In Huawei solution, the eNB sends the CGI message of the target
gNB to U2020. The U2020 will query the gNB IP address
according to the CGI and send back to the eNB, then the eNB will
automatically establish the X2 connection with the gNB according
to the IP address.
It will take about 10mins for deploying BBU only when target
software loaded in BBU before the hardware delivered, and about
60mins for deploying BBU only when target software is not
loaded in BBU before the hardware delivered; the details are
shown in the tables below.
The process of BBU deployment when the target software loaded
in RRH before the hardware delivered.

1. It will take 3mins for RRH Plug&Play function if the S/W is

installed already.
2. The entire required time is about 10mins for CPRI module and
20mins for eCPRI module when the target S/W is not installed in
RRH. The BBU which has installed the target S/W will
synchronize the S/W to RRH automatically when RRH is
powered on, then activate S/W and reset RRH. For different type
RRH, the size of S/W package is different, so the time may be
different. The site will be in service when both BBU and RRH
deployed successfully.
3. Generally, the S/W has been installed in BBU and RRH but
without the same version, the entire in-service time will be about
10mins for CPRI and 20 mins for eCPRI. When the equipment is
powered on, the BBU will synchronize the S/W to RRH firstly,
then activate the S/W and configuration. In this case, the
syschronization in step 3 and step 1 can run in parallel, so the
total time is less than the total step time (15~25min).

Back
Key word *Question
The gNB shall support ciphering of user data between the UE
and the gNB
user
SRAN Security Security 19A data，cipheri
ng
The gNB shall support ciphering of RRC-signalling
signalling，ci
SRAN Security Security 19A
phering
The gNB shall implement the following ciphering algorithms:

ciphering NEA0, 128-NEA1, 128-NEA2 as defined in 33.501 5.6.1.1.
algorithm，N and EIA2 (NIA2) as defined in 33.401
EA0, 128-
NEA1, 128-
NEA2，
EIA2 (NIA2)
support of ciphering algorithms: 128-NEA3 as defined in

ciphering 33.501 5.6.1.1. is optional
SRAN Security Security 19A algorithm，N
EA3
Confidentiality protection of user data between the UE and

gNB, RRC signaling, and NSA signaling is optional
confidentialit
y protection
The gNB shall support integrity protection of user data

between the UE and the gNB.
integrity
protection
The gNB shall support integrity protection of RRC-signalling
integrity
protection
The gNB shall implement the following integrity protection

algorithms: 128-NIA1, 128-NIA2 as defined in 33.501 5.6.1.2.
integrity
and EIA2 (NIA2) as defined in 33.401
protection
algorithms，
128-NIA1,
128-NIA2，
EIA2 (NIA2)
The gNB may implement the following integrity protection

algorithms: 128-NIA3 as defined in 33.51 5.6.1.2.
integrity
protection
algorithms，
128-NIA3

Integrity protection of user data between the UE and gNB,

RRC signaling, and NSA signaling is optional
integrity
protection
support Requirements for gNB setup and configuration as

defined in 33.501 5.2.4
SRAN Security Security 19A 33.501
support requirement for key management inside gNB, as

defined in 33.501 5.2.5
support Requirements for handling User plane data for the

gNB as defined in 33.501 5.2.6
support Requirements for handling Control plane data for the

gNB as defined in 33.501 5.2.7
support Requirements for secure environment of the gNB as

defined in 33.501. 5.2.8
support Requirements for gNB DU-CU interfaces as defined

in 33.501. 5.2.9
Support security procedures as defined in 33.501 chapter 8
Regarding security evolution 2019-2022, please elaborate on

5G-NR/massive IoT/etc. -related security risks or challenges
and specify solutions that can mitigate such risks or
challenges.
security
evolution

Vendor shall describe and detail their full security RAN and
cRAN solutions and provide as much technical information as
possible, also for MVNOs, roaming-in or Ran-Sharing
scenarios.
security
solution
Vendor shall describe the protection mechanisms supported

for sensitive information exchanges between the Core and the
Mobile Edge. Please, explain how the solution protects from
orchestrator, spoofing, eavesdropping or data manipulation attacks for both
SRAN Security Security 19A core, mobile signalling and user plane.
edge
Vendor shall describe the support for IPsec of its proposed 5G

NR solution, including the suggested security GW
deployment.
SRAN Security Security 19A Ipsec
Vendor shall describe the support for MACsec (or any other
SRAN Security Security 19A MACsec technology to secure the data plane) of its proposed 5G NR
solution.
Vendor shall describe in detail the Cryptographic algorithms
adopted for all communications (Over the air, on backhaul,
etc.) and specify which is used for each plane, user,
signalling, voice, data, etc
crypto
SRAN Security Security 19A algorithm,
integrity
Vendor shall describe in detail and with protocol flows the

IMSI solution adopted to protect from IMSI catchers, and detail the
SRAN Security Security 19A catchers, authentication and key exchange mechanism used before the
IMSI, SUPI IMSI, location or any sensitive user information in clear is
send.
Vendor shall describe the adopted protections on all the
implicated interfaces: Xn, NG, E1, F1, F2, Ut, S1-C, S1-U, X2,
X2-C, etc (user to network or inter node interfaces). If any
other interface is needed, please detail it.
SRAN Security Security 19A interface

Vendor shall describe how achieve full protection from DoS

attacks. Note we need details not only protection on Radio
resources, we also need the vendor provide details on
protections for the core network and services or applications
SRAN Security Security 19A DoS behind it.
flooding Vendor shall describe their protections on flooding attacks to

SRAN Security Security 19A user data, signalling.
attack
Vendor shall describe if their solution protects gNB/network
from malware, botnets, virus, etc.
malware,
botnet, virus
Vendor shall describe in detail the security protections

adopted on application layer. (i.e. Security Threats that target
the content server using protocols like HTTP/HTTPS)
application
layer
Vendor shall describe in detail the security mechanisms

adopted on the gNB to store in a secure way all the assets at
the edge, like could be user and network information. (i.e.
beamforming uses the exact users’ location to send them the
signal in a more accurately way).
SRAN Security Security 19A edge
Vendor shall describe how they avoid old Security

Associations (SA) caching storage or SA re-using that can
lead into a security problem.
old security
association

Vendor shall explain in detail all the security aspects

concerning to O&M operations on programmable and
software based RAN. The Vendor shall describe in detail how
connections, updates, patches, operations, etc., are being
SRAN Security Security 19A O&M applied to the gNB.
SRAN Security Security 19A IDS/IPS Vendor shall describe (if having one) their IDS/IPS solutions to
inter gNB,
Vendor shall describe in detail the protections on the
SRAN Security Security 19A eNB and
communications between eNB and gNB or inter gNB.
gNB
Vendor shall describe if their solution supports Level2 (OSI)
SRAN Security Security 19A OSI
integrity checks for signalling and user data.
legacy
Vendor shall describe if their RAN/cRAN solution provides
SRAN Security Security 19A vulnerabilitie
any protection to known legacy vulnerabilities.
s
Vendor must describe how they protect the core infrastructure

SRAN Security Security 19A core from an untrusted site (cell site) if the end point (cell site) is
compromised.
The solution must be able to pass through the appropriate

emergency
SRAN Security Security 19A information to support emergency calls (e.g. location of the
call
cell site).
centralized Vendor shall offer and describe in detail the mechanisms of

SRAN Security Security 19A authenticatio centralized authentication and traceability in our repositories
n, traceability for users in the O&M function.

Vendor shall confirm the capacity of his solutions to guarantee

SRAN Security Security 19A integrity
integrity in the UP and CP communications.
Authenticatio Vendor shall describe 5G Authentication and Key Agreement

SRAN Security Security 19A n, Key behaviour/flow (covering identification, authentication and key
Agreement agreement procedures as well as key hierarchy)
Vendor shall describe the 5G Protection Architecture for

Signalling - as well as User Data (security algorithms
Protection
SRAN Security Security 19A negotiation, signalling as well as user data protection, security
Architecture
for network interfaces, emergency call handling, as well as
automatic certificate enrolment).
SRAN Security Security 19A Intra 5G HO Vendor shall describe the Security in Intra 5G HO
Vendor shall describe the overall security architecture in

SRAN Security Security 19A architecture
detail.
overload
SRAN Security Security 19A Vendor shall describe whether overload protection is implemen
protection
permanent
SRAN Security Security 19A Vendor shall describe how permanent identities are protected i
identities

Vendor shall summarize all interfaces for which plan and do

SRAN Security Security 19A IoT
not plan IoT (inter-operability testing) with other vendors.
Vendor shall detail IoT between its Core and gNBs of other
SRAN Security Security 19A IOT
vendors and viceverse for the different operating modes.
Vendor shall list its multi-vendor Inter-Operability Testing

SRAN Security Security 19A IOT activities with other vendors' EPC/ 5G CN from the
perspective of 5G NR Radio Access Network.
Vendor shall describe the support of IoT technologies (NB-IoT

SRAN Security Security 19A IoT and LTE-M) as the solutions for massive IoT in their 5G
proposal.
The 5G FWA security architecture includes Core Network,

RAN network and UE elements. The security architecture is
required to comply with Australian local lawful interception
laws and regulations. That is, the security mechanisms are
required to provide authorization, integrity protection and
SRAN Security Security 19A FWA confidentiality end to end security. The security mechanisms
are also required to be configured to protect subscriber's
privacy and the network must be protected against denial of
service attack from external networks. The objective of these
requirements is to provide 5G FWA security better or at least
the same than that as in 4G
RAN security in the specifications is to deal with the security

of 5G FWA new radio interface and new radio access
SRAN Security Security 19A FWA network. RAN Security is to protect control plane and user
plane between the UE and RAN, between the RAN and 5GC,
and also between eNB and gNB.
The O&M systems for setting up and configuring gNBs shall

be authenticated and authorized by gNB so that attackers
SRAN Security Security 19A O&M
shall not be able to modify the gNB settings and software
configurations via local or remote access.

confidentialit
The gNB shall support confidentiality, integrity and replay
SRAN Security Security 19A y, integrity,
protection for F1-C signalling bearer
F1-C
All management traffic on F1-C interface shall be integrity,

SRAN Security Security 19A F1-C
confidentiality and replay protected.
confidentialit
The gNB shall support confidentiality, integrity and reply
SRAN Security Security 19A y, integrity,
protection on the gNB DU-CU F1-U interface for user plane.
F1-U
For EN-DC security, the security functions like Key

dual Generation, Key Management, Ciphering and Integrity
SRAN Security Security 19A connectivity, Protection shall be necessary to support a UE that is
EN-DC simultaneously connected to eNB as master and gNB as
secondary for EN-DC dual connectivity.
RRC, The RRC signalling connection between the UE and the

SRAN Security Security 19A integrity SgNB shall be integrity protected and ciphered with the
protection ciphering algorithm.
The ciphering protection shall be applied between the UE and

ciphering gNB at the PDCP layer. The integrity protection shall be
protection applied to the SRB between the UE and gNB at the PDCP
layer.
dual For the dual connectivity to SgNB, the UE shall have the
SRAN Security Security 19A connectivity, same support for the mapping of E-UTRAN security
mapping algorithms support to NR security algorithms support.
The control plane X2-C interface shall be protected by use of
X2-C security. The control plane signalling between MeNB
and SeNB, that includes the transfer of the S-KeNB from the
SRAN Security Security 19A X2-C
MeNB to the SeNB, over the X2 reference point shall be
confidentiality and integrity protected using X2-C security
protection.
The supplier shall comply with the requirements of IPSec

security protocols as specified by IETF at the network layers
IPSec, IETF,
SRAN Security Security 19A and Security Gateways (SEGs) functionalities as well as
3GPP
access routers’ packet filtering and firewalls by 3GPP latest
security standards.

State the encryption protocol and key length used, if

SRAN Security Security 19A encryption encryption is used (in hardware or software) to encrypt any
data stored in tendered systems or communicated.
deactivated Monitor attempts to access deactivated accounts through

accounts audit logging.
central Configure access for all accounts through a central

SRAN Security Security 19A authenticatio authentication system, for example Active Directory or
n system LDAP/TACACS etc.
account Profile each user’s typical account usage by determining

usage normal time-of-day access and access duration.
usenames, Ensure that all account usernames and authentication

SRAN Security Security 19A authenticatio credentials are transmitted across networks using encrypted
n channels.

Verify that all authentication files are encrypted or hashed and

authenticatio that these files cannot be accessed without root or
n administrator privileges. Audit all access to password files in
the system.
Ability to segment or partition the system, network based on

segment,
SRAN Security Security 19A the label or classification level of the information stored on the
partition
servers or devices.
All communication of sensitive information over less-trusted

sensitive networks should be encrypted. Whenever information flows
information over a network with a lower trust level, the information should
be encrypted.
standard
Establish standard secure configurations of your operating
SRAN Security Security 19A secure
systems and software applications.
configuration
Perform all remote administration of servers, workstation,

SRAN Security Security 19A TLS network devices, and similar equipment over secure
channels.
Ability to configure host-based firewalls, access lists or port
filtering tools on end systems, with a default-deny rule that
SRAN Security Security 19A firewall
drops all traffic except those services and ports that are
explicitly allowed.
Use automated tools to verify standard device configurations

automated
SRAN Security Security 19A and detect changes. All alterations to such files should be
tools
logged and automatically reported to security personnel.
Secure channel (e.g. SFTP) must be provided to perform

SRAN Security Security 19A SFTP backup and it should be able to configure the backup time and
duration.
secure, Vendor must explain how would they secure/ harden any
harden Internet facing systems in their proposed solution.
Vendor must provide list of all API interfaces exposed to the

SRAN Security Security 19A API interface internet or external providers and explain how would they
secure these API interfaces in their tendered solution.

Specify whether proposed solution or system has NMS/OSS

SRAN Security Security 19A NMS, OSS solutions, if so explain techniques available to harden and
secure NMS OS, Database, Application etc.
All tendered devices and System should be managed using

following secure protocols only.
a. SSH v2
b. IPSec
secure c. SFTP
protocol d. SCP
e. SSL
f. https
g. SNMPv3
Currently 4G over the air encryption is terminated at the

eNodeB, requiring re-encryption over IPSec to reach a secure
re-encryption
SRAN Security Security 19A datacentre. We would like to look at more efficient alternatives
over IPSec
based on encryption from the terminal straight through to a
secure site thus removing the requirement for re-encryption.
combined RF
Vendor shall describe how multiple combined RF links,
links, over
SRAN Security Security 19A possibly going to different base stations will interact with over
the air
the air encryption.
encryption

Vendor shall provide details the impact on the RAN network of

a DoS or DDoS attack on a subscriber or group of
subscribers, in particular whether this will cause signalling
SRAN Security Security 19A DoS, DDoS
storms and/or exhaustion of radio resources, and how the
network should be architected to be hardened against such
attacks.
The services enabled by 5G and the ‘cloud’ architectures

used to build it create new security threats or exacerbate
existing ones. Examples include the way MMTC services
create the potential for truly massive DDOS attacks from
MMTC，
SRAN Security Security 19A legions of devices attached to the network, and the way
DDOS
compromise of the NFVI has the potential for much more
damage than compromise of traditional appliance. The RAN
must be an inherently secure architecture capable of
addressing existing and the emerging security threats.
Vendor shall provide any insights into alternative approaches

to security architectures enabled by the cloud model and the
cloud model,
SRAN Security Security 19A SBA that would allow operator to move away from traditional
SBA
security architectures, in particular the need for Firewalls as
the enforcement points for security policy.
Vendor shall provide details if there are vulnerabilities within

signalling the RAN network to signalling protocol attacks (SS7 /
SRAN Security Security 19A protocal diameter) via the core or from software implementations of UE
attacks stacks which may be maliciously modified and what protection
will be available against such attacks.
Vendor shall provide details what monitoring points will be

monitoring
SRAN Security Security 19A available in the RAN network to identify signalling attacks,
points
DoS attacks and other security events.

Oerator believes that the NFVI itself must have the capability
for ‘Tap-as-a-Service’ (TaaS) and a generic packet brokering
capability supporting all of the various probe applications,
which will usually be deployed as VNFs co-located with RAN
SRAN Security Security 19A NFVI NFs. In some cases the NFVI may also provide local storage
of captured flows. However, in an SBA the reference points
between NFs do not necessarily correspond to well defined
physical or virtual interfaces to which a virtual probe can be
applied.
bidirectional Oerator would like the RAN to include features to detect and
SRAN Security Security 19A authenticatio report fake base stations which are transmitting on 2G/3G/4G
n or 5G frequencies.
SRAN Security Security 19A NESAS Please indicate if your company has implemented NESAS
If your company has implemented/partially implemented

SRAN Security Security 19A NESAS NESAS, provide a declaration for your products/system based
on NESAS/3GPP 33.916.
What physical and logical security is applied to the DU?

SRAN Security Security 19A threat model
Please provide the formal threat model behind this design.

How do you plan to provide integrity and confidentiality

SRAN Security Security 19A CU, DU, F1 between DU and CU (F1 interface)? In both physical and
virtual deployments.
What end-point authentication mechanisms are appropriate

between DU and CU? (E.g. we expect that all DU/CU
elements to do mutual authentication to ensure no spoofed
end-point
devices or communications can be inserted. This can be done
SRAN Security Security 19A authenticatio
at the protocol layer or at any phase down to the transport
n
layer, depending on chosen solution. However, these may not
all scale to a fully virtual gNB and may be difficult to manage
as resources are scaled in/out.)
radio
What security problems in 3G/4G do you believe have not
jamming,
SRAN Security Security 19A been addressed by current 5G standards and how do you
rogue
plan to address these?
basestation
Please describe your security protocol solution for protecting

the Xn interface over unsecured links. How does your gNB
SRAN Security Security 19A Xn, IPSec automatically establish secure Xn connections to its neighbors
in a multi-vendor environment? Does the gNB support group
VPNs (e.g. GDOI/Group Domain of Interpretation) for Xn?
Please describe your security solution for non-split gNB (e.g.

small cells) or split gNB DUs that are deployed in physically
trusted insecure locations. It requires that such devices use trusted
computing computing methods in their hardware and software to ensure
that unauthorized access cannot lead to a compromise of the
device or the network.

The ability to monitor the 5G network for security anomalies is

SRAN Security Security 19A log currently unknown. Please identify any systems for why you
believe we will –not- be able to enable full, real-time logging.
What mechanism will be in place to ensure only validated

device can stay connected to the network? i.e. vulnerable
SRAN Security Security 19A PEI
device/brand/type might need to be surgically removed when
they are deemed obsolete or dangerous.
threat model,
SRAN Security Security 19A What is your threat model for IOT devices, if you have one?
IOT
What is the state of cipher notification to UEs? Is this

cipher
SRAN Security Security 19A supported in your release and on UEs that you have tested
notification
with?

What mechanisms are you prepared to take in this release to

SRAN Security Security 19A IMSI,SUPI
protect the broadcast of IMSIs in the clear?
Will 5G brings any new security challenge in term of ESIM we

SRAN Security Security 19A ESIM
already have in place?
SRAN Security Security 19A multi, Sim Will 5G will allow concurrent multi Sim/eSIM on the network?
What security measure will be in place for soft SIM

SRAN Security Security 19A soft, SIM
provisioning?
Vendor shall identify supported options available for

APN, interconnecting mobile APNs and packet network VPNs. The
VPN,tunnel Responder should also supply recommendations for securing
this interconnect.

Response Attachment
*Compliant Response Remark
Name
Ciphering of user data in gNB is planed in 5G RAN2.0, the
details of exchange message is being worked out in 3GPP
now, if the standard is poseponed, the implement plan will
be postponed in later version.
Huawei_Attachment A6-
FC 2 Software Features.xlsx
Ciphering of RRC-signalling is planed in 5G RAN2.0,the
be postponed in later version.
In RAN 2.0, NSA DC is implementated, RRC ciphering is
not related.
ciphering algorithms: NEA0, 128-NEA1, 128-NEA2 is
planed in 5G RAN2.0, the details of exchange message is
under working out in 3GPP now, if the standard delay, the
implement plan will be postponed in later version
These algorithms have already supported in RAN 2.0.
128-NEA3 is planed in 5G RAN2.0, the details of exchange
message is under working out in 3GPP now, if the standard
delay, the implement plan will be postponed in later version
This algorithm has already supported in RAN 2.0 Huawei_Attachment A6-
Confidentiality protection of user data is planed in 5G
RAN2.0, the details of exchange message is being worked
out in 3GPP now, if the standard is poseponed, the
integrity protection of user data is planed in 5G RAN2.0, the
details of negotiation procedure are under working out in
3GPP now, if the standard delay, the implement plan will be
postponed in later version
Intergrity protection is not triggered in NSA DC in RAN 2.0 Huawei_Attachment A6-
integrity protection of RRC-signalling is planed in 5G
RAN2.0, the details of exchange message is being worked
out in 3GPP now, if the standard is poseponed, the
Intergrity protection is not triggered in NSA DC in RAN 2.0 Huawei_Attachment A6-
integrity protection algorithms: 128-NIA1, 128-NIA2 are
planed in 5G RAN2.0, the details of exchange message is
being worked out in 3GPP now, if the standard is
poseponed, the implement plan will be postponed in later
version
Intergrity protection is not triggered in NSA DC in RAN 2.0
128-NIA3 is planed in 5G RAN2.0, the details of exchange
message are under working out in 3GPP now, if the
standard delay, the implement plan will be postponed in
later version


Integrity protection of user data is planed in 5G RAN2.0, the

be postponed in later version

For now(33.501 V3.0), it supported in 5G RAN 2.0 version.
However, 33.501 is still under working now, if there are new
function requirement beening added in later 33.501 version,
which wolud be considered in later version plan.
33.401 has not been worked out now. Huawei planed some
security functions in 19A version now, E.g. the algorithm
negotiation, key derivation,key change in the initial access
procedure and Handover procedure. the remaining parts,
which security requirements or solution not very clear now,
will be planed in later version.
PC 2 Software Features.xlsx
Attachment ：Huawei Wireless Security Solution for 4G&5G
Network_0524-final
Huawei has robust security solution for 4G RAN network
based on industry best practice on security area. For 5G
NSA deployment，except for existing LTE security
Solutions, there also some enhancement defined by 3GPP,
such as
FC (1) UP and CP support Both Encryption and Integrity
Protection (3GPP R15)
(2) Permanent user ID encrypted all time (3GPP R15)
(3) Security algorithm supports both 128-bit keys and 256-bit
keys ((3GPP R16)
5G network has stronger security requirement to support the
diversity of new services, which is still under discussion,
while Huawei is one of the most important security standard
contributor in 3GPP, and Huawei 5G products will comply

Based on the characteristics of wireless networks and

equipment logical locations, we define four security
application scenarios: air interface, equipment, network
between equipment, and management.
Scenario 1:
FC Air interface security protection (security application on the
air interface)
The nature of wireless communication networks is wireless
communications. Wireless communication networks are
open networks. User service information is propagated in
the form of radio waves. The format of data transmission is
defined by 3GPP protocols. All equipment manufactured
The security level of orchestrator shall be Huawei supports
inter-cell intra-site CoMP coordinated-scheduling for test
purpose and commercial in future version.
Inter-cell intra-site CoMP includes SMP (Separate Multi-
FC Point), DMP (Duplicated Multi-Point), and UL CoMP.
SMP allows neighboring TP to provide additional MIMO
layers. Different TP transmit different streams so that to
provide additional spatial multiplexing.
DMP allows neighboring TP to provide duplicated signals to
improve the SINR.
For CU/DU integration, Huawei BBU supports IPSec to
protect the Xn interface and the interface between gNB and
5GC.
For CU/DU division, Huawei DU supports IPSec, but
Huawei CU does not support IPSec, customer should
FC deploy a separate SeGW to protect CU.
Huawei RAN currently supports the MACSEC to be used for

FC security between connections for multiple UMPT board
inside one site.
1. Crypto algorithms for air interface are specified in 3GPP:
• SNOW 3G (CP & UP)
• ZUC (CP & UP)
• AES128 (CP & UP)
2. Crypto algorithms for IPSec on backhaul:
Encryption
• DES
• 3DES
• AES128
• AES192
FC • AES256
Integrity:
• MD5
• SHA1
• AES-XCBC-MAC-96 (IKEv2)
• SHA256 (IKEv2)
FC
Huawei RAN complies with 3GPP standard. 3GPP
TS33.501 has defined the SUPI encryption, the SUPI shall
not be transferred in clear text over 5G RAN.
PC 1. Huawei RAN supports IPSec protocol to protect F1, S1-C,

S1-U, X2, Xn, and NG interfaces, also supports TLS to
protect F1-M interface.
2. E1 interface between CP and UP in CP/UP division
scenario currently is not defined yet. Huawei will follow
3GPP standard.
3. For CU/DU integration, Huawei RAN supports IPSec
inside BBU;
For CU/DU division, Huawei RAN supports IPSec inside
DU, but Huawei RAN CU does not support IPSec. Customer
should provide SeGW for CU protection.

FC 1. Huawei RAN complies with 3GPP standard, and support

backoff mechanism to prevent DoS attacks.
2. Huawei RAN has flow control function inside base station
to prevent congestion.
3. Huawei RAN does not involve core network services or
applications.
FC Huawei RAN has integrated firewall, the functionality

provides the packet filtering, anti-attack from some network
protocols.
FC 1. Huawei's gNB supports secure boot originating from an
immutable entity - RoT (Root of Trust) built in SOC chip-to
high-level application software. All launched firmwares and
software is integrity verified.
2. Huawei's gNB supports software digital signature
verification feature that make the firmware and software
authenticity and integrity when loading and upgrading.
3. Huawei's U2020 supports software management and
gNB supports DIM (dynamic integrity measurement) which
measures run-time integrity of operating system kernel and
user process in memory. To ensure the trusted system, DIM
is used to detect malicious software and instruction code
injection attack. Currently DIM records measurement results
into logs for security audit requirements.
4. Huawei's gNB supports ACL, Anti-DDoS features to
protect gNB from malware, botnets.
FC 1. Huawei’s gNB supports SSL to secure application

communication. All data are confidentiality and integrity
protection during transport.
2. Huawei’s gNB supports RBAC (Role Based Access
Control) feature. All users should be granted and
authenticated to access to gNB.
3. Huawei’s gNB supports log feature to ensure that all user
access and operations are recorded and available for
auditing.
4. All sensitive data, e.g. password, key materials, are
secure stored.
FC The gNodeB does not store the end user information. Some
necessary network information, such as the base station IP
address, the core network address, the network
management IP address (U2020), and the routing
information, are stored in the base station in the form of a
configuration file.
The configuration file supports the integrity check
mechanism. When the configuration file is downloaded to
the base station, the base station verifies that the file is used
by the party. Profile export supports encryption.
FC 1. IPSec SA, SSL/TLS, etc., meet the requirements of the

standard IETF protocol, which itself has an embedded
session management mechanism. If IKE supports ISAKMP
SA Duration (ISAKMP SA Duration),
2. Support the secure session timeout mechanism to clear
memory or cached session information after session
timeout/interrupt/termination.

FC Up to now, Huawei gNB does not support programmable

features but supports following features for OM plane:
1. OMCH can be protected by SSL/TLS, and Certificate-
based authentication;
2. Support integrity check for software package, patch;
3. Support user hierarchical management and operation
authorization group management.
Huawei RAN supports Packet filter function and anti-flooding

FC packets function, which can detect and drop invalid packets
for protecting system from attacks.
Huawei RAN supports IPSec protocol to protect the
FC
communication between eNB and gNB or inter gNB.
Huawei RAN supports the integrity check for signalling and

FC
user data, the solution follows 3GPP standard.
The code of Huawei gNodeB will be scanned by tools such

as pclint, coverity, fortify, etc. All problems will be cleared
and reviewed in detail. Before the release of the version, it
FC
will be detected by a vulnerability scanning tool such as
Nessus and Nexpose, and the middle and high level
problems will be solved.
1. Huawei's gNB supports secure boot and software digital

signature features to ensure the firmware and software are
trust origin.
2. Huawei U2020 supports software management and gNB
supports DIM (dynamic integrity measurement) which
measures run-time integrity of operating system kernel and
PC user process in memory. To ensure the trusted system, DIM
is used to detect malicious software and instruction code
injection attack. Currently DIM records measurement results
into logs for security audit requirements.
3. Huawei’s gNB supports real time security alarm if it
detects a security breach.
In NSA, Huawei solution supports emergency calls via LTE

PC network; In SA cannot support emergency calls currently,
Huawei is planning to support it in later version.
1. Huawei’s RAN and OSS support RBAC (Role Based

Access Control) feature. All users should be granted to
access to RAN and OSS and be authenticated.
2. Huawei’s RAN and OSS support log feature to ensure
that all commands are recorded and available for viewing.
You can monitor user activity using Huawei’s U2020 Log
function.
3. For Operation Log, it records the following items.
[Start time]: the time that the operation started or received
[End time]: the time that the operation finished
[Operation]: the details of the operation
FC
[Operation type]: the type of the operation, such as system
management, configuration management, fault
management, security management etc..
[Result]: Success or Fail
[Operator]: Operator’s user name or user ID
[Work station]: The terminal name or terminal’s IP address
from that the operation comes
[Source]: the source of the operation
[Error code]: error code for failure of operation
[Command level]: Operating command level.

3GPP TS33.501 defines the UP and CP integrity on air

FC
interface, Huawei RAN complies to 3GPP standard.
Huawei RAN follows the definition about key agreement

FC procedures specified in 3GPP TS 33.501. RAN do not
involve 5G authentication.
1) Huawei RAN supports data ciphering and integrity for

signalling and user data between UE and Base station,
which solution complies with 3GPP standard.
2) Huawei also supports the IPSec protocol to protect the
data transfer on network interfaces.
The protection architecture is as followed in figure.
FC
Huawei RAN security architecture has these aspects such

as air interface security, transmission security, equipment
security
Huawei RAN and OM security.
supports the security in intra 5G handover, the
FC
The air interface
solution security
follows 3GPP comply with 3GPP standards, its
standard.
solution have data encryption and data integrity.
The transmission security is to protect the network
communication, TLS/SSL is used for OM network security.
IPSec is used to protect the signalling and user data
transmission between network interfaces such as S1, NG,
F1, X2 and Xn interface. PKI deployment is used to
FC certificate authentication and key negotiation for TLS and
IPSec.
The OM security contains the maintenance security from
OM plane. The solution have authentication & authorization,
OM channel security, data security and audit log
management.
The equipment security is to protect the Base station
system, the solution have OS hardening, integrated firewall,
software integrity check, physical interface security and
1) For the already connected users, Huawei supports
security environment.
congestion control in RAN2.1. If the cell’s radio resource
utilization exceeds a threshold, gNB will select some low
priority users to redirect out GBR services radio resource
are calculated separately, gNB will select GBR users when
GBR service utilization exceeds the threshold. Else if the
total radio resource triggered congestion control, gNB will
FC
select some NonGBR users to redirect out.
2) For the RRC access users, Huawei supports admission
control mechanism. Low priority users are limited to attach
in these cells whose radio resources or UE specification are
limited. This function is used to protect the experiences of
the network users and device stability.
3GPP TS33.501 defines the mechanism to encrypt SUPI

FC and ensures not to transfer in clear text over 5G RAN.
Huawei RAN follow the solution of the 3GPP standard.

Huawei supports the standard open interfaces S1, X2 for
NSA, and Xn, NG interfaces for SA and proprietary
interfaces F1 for CU-DU split, CPRI/eCPRI for BBU-RRU.
Whether proprietary interfaces will be open or not it depends
on industry requirements.
Huawei has established the good IOT cooperation relation
with all the mainstream 2G/3G/4G/5G vendors, and all the
IOT tests follow the standard procedure which is defined by
NVIOT Forum (Network Vendors InterOperability Test),
including the templates of test documents. Huawei has built
four global IOT labs in Shanghai/Xian/Chengdu, China;
Dusseldorf, Germany. All the IOT tests are performed in
these four labs through transmission network to connect
FC
with other vendors’ IOT labs.
Huawei plans to start IOT tests on interfaces S1, NG when
the product release is ready. For the IOT of other interfaces,
such as X2, Xn, will be triggered by market requirements
or/and customer’s requirements. Huawei normally start IOT
activities from TR5, and the exact test plan should be
negotiated and agreed by Huawei and other vendors. All the
IOT test information is protected by NDA (Non Disclosure
Agreement).
The customer can submit IOT requirement, and all the IOT
session depend on customer’s requirement, may not cover
all the interfaces of other vendors.
All the IOT test information is protected by NDA (Non
Disclosure Agreement). Huawei cannot disclose any IOT
information without other vendors’ agreement.
If customers want more information, Huawei suggests
customer to send formal requirements to Huawei and other
FC
venders in official path because Huawei have to obey NDA
(Non-Disclosure Agreement) and avoid violation in law.
Based on approval from other venders, Huawei will very
glad to provide IOT information wanted by customer.
Huawei multi-vendor Inter-Operability Testing activities are

based on NVIOT Forum procedure. According to NDA (Non-
Disclosure Agreement), Huawei cannot provide such
FC information without approval from other venders. Customer
can check the basic activities information in section “The
MVI Process” on NVIOT Forum. The link is http://www.nviot-
forum.org.
As described in 3GPP Release 16, mMTC standard will be

stable at 20th of December 2020. As the leading
PC telecommunication company, Huawei products will comply
with 3GPP Release 16 within 6 months as soon as standard
is frozen.
Huawei FWA solution complies with 3GPP standard (R15),

PC IETF and ETSI standard protocol. However, 5G RAN does
not provide Lawful Interception function.
Huawei gNodeBs support Air Interface Ciphering that

involve AES, SNOW 3G, and ZUC ciphering algorithms,
which are used to cipher signaling and service data
transmitted between UEs and base stations. In addition,
FC Huawei gNodeBs support Security Mechanism that protects
the network access security of devices. It covers the
following functions: Public Key Infrastructure (PKI), PKI
redundancy, integrated firewall, and access control based
on 802.1X.
Huawei gNodeB support to authenticate through TLS

FC certificate and user/password and authrize the user access
via local or remote access.

In the scenario of DU-CU splitting, Huawei recommend the

solution that IPSec protect F1-C and F1-U interface. The DU
FC
of Huawei gNodeB support the IPSec feature, and SeGW
should be deployed for CU of gNodeB.
For management traffic on F1, huawei gNodeB support TLS
FC
to integrity, confidentiality and replay protect.
In the scenario of DU-CU splitting, Huawei recommend the
solution that IPSec protect F1-C and F1-U interface. The DU
FC
of Huawei gNodeB support the IPSec feature, and SeGW
should be deployed for CU of gNodeB.
Huawei gNodeB and eNodeB support the security
functionalities including Key Generation, Key Management,
FC Ciphering and Integrity Protection and support a UE that is
simultaneously connected to eNB as master and gNB as
secondary for EN-DC dual connectivity.
Huawei gNodeB support that the RRC signalling connection

FC between the UE and the SgNB is integrity protected and
ciphered with the ciphering algorithm.
Huawei gNodeB support the ciphering protection between

PC the UE and gNB at the PDCP layer; but Huawei gNodeB do
not supportthe SRB in EN-DC scenario.
Currently, NSA will based on LTE Security architecture and
PC procedures as the anchor is still go through LTE eNodeB.
Thus, Huawei eNodeB is complies with 3GPP TS33.401.
The protection of X2 between MeNB and SgNB support the

FC
IPSec for integrity and confidentiality on control plane.
Huawei gNodeB is complies with IPsec protocol which is

defined by the Internet Engineering Task Force (IETF).
Implemented at the IP layer, it uses three different protocols:
FC Authentication Header (AH), Encapsulating Security
Payload (ESP), and Internet Key Exchange (IKE). IPsec
provides transparent, end-to-end security services for IP
networks, protecting them against cyber-attacks.

The following are the protocol and key length used currently:
• 3DES Data Encryption 168 Symmetric
• AES Data Encryption 128 Symmetric
• AES Integrity Check 128 Symmetric
• DES Data Encryption 56 Symmetric
• MD5 Authentication NA HASH
• SHA1 Authentication NA HASH
• MD5 Integrity Check NA HASH
• SHA1 Integrity Check NA HASH
• SHA256 Integrity Check NA HASH
• MD5 Digital Signature NA HASH
• SHA1 Digital Signature NA HASH
• SHA256 Digital Signature NA HASH
• HMAC-MD5 Integrity Check 128 HASH
• HMAC-SHA Integrity Check 160 HASH
FC • RSA Digital Signature 1024 Asymmetric
• RSA Digital Signature 2048 Asymmetric
• DSA Digital Signature 4096 Asymmetric
• RC4 Data Encryption 128 Symmetric
• SNOW 3G Data Encryption 128 Symmetric
• ZUC Data Encryption 128 Symmetric
• SNOW 3G Integrity Check 128 Symmetric
• ZUC Integrity Check 128 Symmetric
• Others Authentication 128 Symmetric
• DSA Digital Signature 4096 Asymmetric
• RC4 Data Encryption 128 Symmetric
• DES Data Encryption 56 Symmetric
• MD5 Authentication NA HASH
Huawei RAN will record the any accounts' failed login

FC
attempts in audit logs
Huawei U2020 supports LDAP-based centralized

FC
authentication based on users and based on user roles.
Huawei U2020 supports to set maximum expiration date of

FC
password in security policy.
Huawei RAN support the security protocol TLS for OM

network connections, and ensure the secuity connection is
FC
used to protect the transmission for usernames and
authentication credentials.

The software packet files for gNB are hashed, and Huawei
FC gNB does not supply the way to access these files except
the software management module.
Huawei U2020 supports to set user access right of OSS or

networl elements. It supports to assigne different right for
each user or user group to access network element or OSS.
In addition, Huawei U2020 can supports OS Hardening
which includes restricting access to system directories, files,
FC
and executable files, setting files and directories that have
no owners, restricting the use of the cron command,
restricting the access to the PATH directories (only user root
is authorized to access the PATH directories), and setting ro
mounting.
Huawei RAN support the secured protocols

FC TLS/IPSec/MACSEC/FTPS, which protect all the
communication of sensitive information.
Huawei gNB’s operating system will be reinforced when

FC
release.
Huawei RAN support the secured protocol TLS to protect

FC
remote connections.
Huawei RAN support integrated firewall to packect filtering

FC
basing on access control (ACL) rules.
Huawei RAN support the integrity check for important files,

and if the check period is configured, Huawei RAN will
FC
automatically check the integrity check for those important
files and record the check result in log.
Huawei U2020 supports to backup NE data manually or

automatically on a scheduled basis. The U2020 centrally
FC manages and schedules backup tasks by Centralized Task
Manager. The U2020 backs up the data based on the preset
period and time.
Huawei U2020 supports OS hardening, databse hardening,

and antivirus solution. Huawei mAOS supports OS
hardening and antivirus solution. Main risks that threaten
OSS security include viruses, worms, and spyware. To
prevent OSSs from being attacked by these threats, Huawei
FC
provides antivirus solutions for Windows operating systems
by deploying third-party software Trend OfficeScan. Huawei
no longer delivers Linux-specific antivirus software for
wireless OSS products. Purchase the antivirus software
from Trend Micro if necessary.
Huawei U2020 provides a series of NBI interfaces including:

- Alarm SNMP/ASSCII Steaming interface
- Performance File interface
- CORBA Bulk CM
Huawei uses SFTP for northbound interfaces related to file
PC
transfer, such as performance file interface, batch
configuration CORBA interface. Huawei supports data
encrypted using SSL in Alarm ASCII Streaming interface.
Huawei U2020 can support 5G NBI interface by 2019Q2.

Huawei U2020 enhances the security of operating system

by disabling unsecured operating system services,
restricting access to files and directories, securing user
accounts and passwords, and adjusting kernel parameters.
OS hardening policies enable the U2020 to display a
warning banner when users log in to the U2020 through FTP
or SSH. In addition, the hardening policies provide system
logs related to Inetd, FTP, cron tasks, and daemon process
for users to tracing and audit the operations performed on
the operating system.
FC Database Hardening enhances Oracle database security by
restricting the access to files and directories, adjusting
database parameters, locking unnecessary default user
accounts, and preventing common users from accessing
system tables. This feature enhances Sybase database
security by locking unnecessary default user accounts,
deleting unnecessary user rights information, increasing
password complexity, and using the minimum software
installation. By enhancing database security, this feature
enhances U2020 system security.
Huawei U2020 adopts secure protocols, including SSHV2,

HTTPS, SFTP and SNMP; and supports transmission
FC
security to provide a security data channel by using SCP
protocol.
Huawei follows the mechanism of IPsec defined in the

3GPP protocol, currently there's no such requirement in
3GPP, which can encryption from the terminal straight
through to a secure site and removing the requirement for
FC re-encryption.
Alternatively, End-to-End encryption can be achieved
through mobile encryption on application layer, for example,
based on the HTTPs protocol, to protect user data security.
Huawei RAN supports CA (carrier aggregation) function. CA
enables a UE to simultaneously access more than one
Component carriers (CCs). Each CC has an independent
set of User-plane data scheduling at MAC layer and Uu
interface transport channels, as well as separate hybrid
automatic repeat request (HARQ) entities and
retransmission processes. Each radio bearer has only one
FC PDCP entity and one RLC entity, so the date from these
CCs are aggregated to the RLC entity and the PDCP entity
at PCell.
When these CCs are deployed in different base stations, the
data from different nodes’ radio links combined at the
primary node, the air encryption is only done at the PDCP
layer in the primary node.

From Huawei’s opinion, there are two DDOS attack paths to

a subscriber or group of subscribers.
One attack path is from network:
1) If the attacker forges signal messages to some certain
UEs, then only UEs is affected, no signalling storm risk for
RAN;
2) If the attacker trigger the core net to send signal
messages to UEs frequently, then may cause signalling
storms and exhaust radio resources to RAN.
Possible defence method: RAN can do the signalling flow
control to limit the affect to radio resource. However, it’s
difficult for the RAN side to identify the signalling which
contain the attack, or the being attacked UEs. Maybe the UE
or AMF can detect and against the DDOS attacks.
Another attack path is from air interface:
1) An attacker may control many terminal devices to initiate
access procedure frequently to exhaust radio resources of
gNB, then cause DDOS attack to other normal terminal
FC
devices.
Possible defence method: In the RAN side, it’s supported to
limit the flow rate of the initial access messages to prevent
the resources in the gNB from being exhausted. But the
gNB cannot identify the attacking UEs and deny their access
requests.
2) An attacker may control many terminal devices to spoof
as high priority subscribers and seize the RRC radio
resources, which may cause low priority subscribers being
denied by the gNB.
Possible defence method: it may be useful if the gNB can
check the validity of the UE’s priority, but this is still being
studied.
The impact on the RAN network of DDOS attacks and
corresponding mitigation method is still being studied, and
most DDOS scenarios are postponed to discuss in Phase II
of 3GPP 5G standard.
The security threats caused by 5G new services and the

corresponding mitigation solution is being studied in 3GPP
SA3 team. Huawei’s product will follow the worked out 5G
FC security standard.
For the cloud security, Huawei’s product would follow the
relevant ETSI standard.
The security architecture of SBA is being studied in 3GPP
standard. Huawei’s product will follow the final worked out
standard.
The security architecture of cloud model in Huawei’s
product:
RAN CU as a VNF in the NFV network provides its own
system and service security, and the traffic transmission
FC
security with surrounding network elements, including radio
access security, network security, system security, data
protection, security management. The detail functions of
these security domains are under planning.
Other VNFI security, virtual security, VNF management
The introduction
security depend onof 5G
the will not change
relevant the isolation principle
ETSI standard.
between the RAN side and the E2E communication at the
application layer. The reason is that the E2E attack is
FC
completely transparent to the RAN side. This principle has
worked for 2G/3G/4G and do not see any prospect for it to
be violated.
From Huawei’s opinion, the DDOS attacks from each

protocol layer should be monitored in the corresponding
protocol termination point, E.g. RRC signalling DDOS
FC
attacks monitored in gNB and UE, NAS signalling DDOS
attacks monitored in AMF and UE, User plane DDOS
attacks monitored in UPGW and UE, and so on.

Generally, the port mirroring solution depends on DPI

requirement, what traffic want to capture (such as signaling
plane, user plane, east-west or north-south traffic).
Huawei NFVI solution is able to provide two solutions for
TaaS, the first one is OpenStack TAPaaS based on the
neutron and the second is the probing solution based on
optical splitter. Meanwhile, the TaaS solution has already
been verified with Empirix probe software.
1) For Openstack TAPaaS, the port-mirroring function is
based on the neutron and vSwitch and supported by Huawei
EVS (enhanced virtual switch).
Due to the network security issues and the forwarding
performance degradation of the port mirroring by EVS, the
FC function is not in the default release version of
FusionSphere OpenStack and it can only be installed
additionally with the definite requirement from the customer.
The TaaS is able to do the port mirroring and integrate with
vProbe to deal with all the probing traffic.
There are two ways to do the port mirroring:
1. Local port mirroring SPAN(Switched Port Analyzer)
2. Remote port mirroring RSPAN(Remote Switched Port
Analyzer)
2) Currently, the probing solution based on optical splitter at
the physical switch is a solution used most often in the
industry. Only the traffic going through the TOR/EOR can be
mirrored to the analyzer.
According to the provisions of the 5G protocol, there should

be a bidirectional authentication mechanism between the
FC
UE and base station, and the mobile phone will not establish
the link with fake base station.
Huawei has implemented NESAS from two sides, on the

one hand, Huawei took part in the SACS making like eNB
FC and gNB, and cooperate with GSAM to support the NESAS
pilot activity, on the other hand, the SCT, BVT and EVA
have been implemented in our security testing period.
Since GSMA NESAS is still in PILOT phase, GSMA does

not provide test licenses to any supplier till now. Currently
Huawei cannot give a declaration for products based on
NESAS.
For example, gNB SCAS is still under discussion and
FC
estimated to be released in 2019 H2. Huawei has
implemented the NESAS technical and procedure
requirements, but cannot declare that Huawei products are
compliant with a standard which is not frozen now.
Huawei RAN secuity is consist of four aspects including Air

interface security, OM security, Transimission security and
Device security. The following figures are about the threat
model and huawei security solution. for DU security design
can cover the threats from the following 5 aspects.
FC

IPSEC is supported by CU-DU split architecture.

DU support built-in IPSEC and CU support IPSEC gateway
FC
both virtual and physical.
The current reasonable solution to satisfy this requirement is

that both CU and DU support built-in IPSEC and digital
FC certificate authentication. However, SRAN15.1 support CU
with IPSEC Gateway and DU already supports IPSEC and
certificate authentication.
Radio jamming and disruption is always possible in any

wireless technology. Similar to LTE, the 5G NR physical
layer consists of several physical channels and signals;
Disruption through radio jamming is still possible in 5G. An
attacker may disrupt the radio broadcast signal by sending
strong white noise, so that the UE cannot access the node’s
critical system information, thus preventing new UEs from
accessing the cell. Or the attacker can interrupt the radio
service data transmission by jamming the radio signal of the
physical uplink/downlink shared channel. Huawei’s product
supports the radio resources dynamic scheduling of physical
uplink/downlink shared channel to avoid channel
FC interference, and supports inter-cell coordination to
suppress inter-cell interference.
A rogue basestation is another problem in 4G and 5G. The
attacker can launch DDOS attacks to the UE, which camps
on the rogue cell (e.g. spoofing public safety warnings or
incoming emergency calls, etc.). Another issue is the rogue
basestation spoofs information to disturb the UE’s cell-
reslection and handover procedure. Currently more and
more risks of rogue basestations are being studied and
exposed. This has been a potential study item in 3GPP SA3
phase 2. Huawei will join the SA3 discussion and comply
with the standards result.
Huawei RAN BBU supports IPSec for protecting the Xn

interface over unsecured links and supports automatic
IPSec connection based on the security template. In a multi-
vendor environment, the IPSec connection on the Xn
FC
interface depends on the available IPSec functionality of
neighboring gNodeB/eNodeB. Huawei RAN does not
support group VPNs. Huawei is willing to discuss with
customer about
All necessary the detailed
interfaces requirement.
are authorized-accessed. Huawei's
gNB supports secure boot originating from an immutable
entity - Root of Trust (RoT) built into the SOC chip and high
level application software. All launched firmware and
FC
softwares are verified for integrity. Huawei's gNB also
supports a software digital signature verification feature that
ensures firmware and software authenticity and integrity
when loading and upgrading.

Huawei RAN provides log management functionality,

including log record, log storage and log query. Customers
can query log information through the U2020.
Huawei RAN supported log types are as follows:
 security log: contains logs related to security operations,
for example: user login/logout, security management, etc..
 operation log: contains logs related to user operations
 debug log: contains information related to system actions
while the system is running, for example: service start/stop,
data modification, etc..
It is well understood that there exists numerous examples of
design and programming flaws that have led to security
incidents and the proliferation of malicious software. Often
these flaws emerge as day-zero vulnerabilities, rendering
defense using reactive security tools almost impossible. It’s
a fact, software has significantly increased in both size and
complexity with network evolution. In addition, attack
methods are increasingly creative and sophisticated.
Predefined signature and rule based detection patterns
FC cannot detect and prevent new “never-before-seen” attacks
until a specific intrusion protection signature or rule that
understands the method of the attack is added to the
detection database. Identifying security vulnerabilities in
software and network is very challenging.
Huawei believes 5G network security resilience is important
to counter cyberattacks. Intelligent security analysis
technologies, for example, big data analytics and machine
learning, will be needed to detect and mitigate future
unknown threats. Making use of these industry security
analytics capabilities will help customer to disclose such
activities at an early stage, thus reducing greater harm. Real
time logging reporting can help to reduce time with
automated incident response. Enabling full logs may help to
reduce false positives of machine learning models to detect
unknown attacks, and also can help to assist tracking
cyberattacks. As a result, enabling full, real-time logging is
helpful to limit the damage to the system or business, and to
reduce recovery time and costs.
The network may perform a PEI (Permanent Equipment

Identifier) check with the 5G-EIR, where the operator
FC If there areillegal
blacklists a huge number
devices. of network
The IoT devices
mayattached to thethe
authenticate
gNodeB/eNodeB, the RANthat
UE during any procedure willestablishes
face the threat
a NASof asignaling
DDoS
attack. IOT with
connection threats
theare
UE,categorized into corruption
avoiding unwanted UEs. of system
integrity, system intrusion, malicious privilege abuse, and
threats to data security and interruption caused by network
service attacks. For details see Huawei IOT security white
paper
http://www.huawei.com/minisite/iot/img/hw_iot_secutity_whit
e_paper_2017_en_v2.pdf.
FC
IoT threats include:
1. Huge amount of IoT devices accessing the
gNodeB/eNodeB, causing a DDoS attack.
2. Spoofing/malicious/unauthorized IoT device attempts to
connect to the RAN.
3. RAN transmits the signaling or user data from IoT devices
– the
By data may
following 5Gbe tampered
service with and
procedures privacy
the UE is compromised.
aware of the
state of cipher notification. Notification to end users is an
FC
added feature of the UE’s user interface and depends solely
on UE implementation.

5G introduces a global unique 5G subscription permanent

identifier (SUPI) and IMSI is contained in the SUPI. The
SUPI, which is privacy protected over-the-air, is described in
FC section 6.12.2 of 3GPP TS 33.501. The SUCI encrypted
IMSI through public key will be supported in the broadcast
message. Provisioning and updating of the public key
depends on the operator's methodology and mechanism.
For the UE (e.g. IoT device) equipped with eUICC (e.g.

eSIM), an attacker may be able to hack the communication
between the 3GPP network and legitimate IoT devices
during a remote provisioning procedure – if there is no
secure mechanism to protect the confidentiality and integrity
of the UE. This could result in the misuse of credentials,
causing issues such as data breach and invasion of privacy.
FC
A potential solution is that the UE can initiate an attach to
the 3GPP network without its 3GPP subscription credentials
using eUICC (i.e. eUICC certificate chain including eUICC
certificate Cert_eUICC and the eUICC manufacturer (EUM)
certificate Cert_EUM). This allows the UE to securely
access a 3GPP network only dedicated for the purpose of
remote provisioning.
Concurrent multi SIM/eSIM is a feature / capability of the

UE, available in many LTE smart phones today. The
FC
expectation is that 5G UEs will also support this. In either
case each SIM/eSIM acquires its AKA independently.
To prevent attacks during a remote provisioning procedure

such as soft SIM, a possible solution is to allow the UE to
FC
securely access athat
Huawei believes 3GPP network
a tunnel only dedicated
technology combinedfor with
the
purpose of remote
IPSEC would provisioning.
provide the required security and flexibility to
enable similar capability. Ideally, Segment-Routing and
EVPN could be used on the transport network to deliver
tunnels to and from breakout locations to a centralized
aggregation point. Tunnel hand off to enterprise customers
would be determined by the capability of the partner and
depend on the service being delivered (for example in
scenario where customer is providing L2TP LNS capability
FC to manage IP connectivity for private APN vs L3 Private
APN).
Huawei IP products are fully featured and flexible, they are
high capacity, scalable and flexible and have the capability
to provide any type of tunneling service and offer flexible
support for next generation protocols such as SR-MPLS,
FlexE and are H/W ready and have programmable chipsets
that allow for a smooth evolution to SR-IPv6 in the future via
simple s/w upgrade.

Back
Key word *Question
8.Q-1 Which bands above 24 GHz are seen as key

above 24 bands for NR introduction worldwide and especially in
Spectrum Spectrum Spectrum NA
GHz EU?
8.Q-2 Which bands are considered as global bands with
roaming roaming capabilities?
capability
8.Q-3 When are those bands expected to become

available? (=usable)
band
available
8.Q-4 Which use cases are seen for each respective

band?
Spectrum Spectrum Spectrum NA use cases
8.Q-5 Which general technical parameters are expected

for spectrum usage in the considered bands with regard
to hardware support for max. supported bandwidth
(tuning range), carrier bandwidths, instantaneous
bandwidth, duplex principles, split between UL and DL
capacity/spectrum usage?
8.Q-6 How are the bands at 26 and 28 GHz judged with

regard to HW implementation (eNB as well as terminal
equipment)? Can it be expected to have a common HW
with a tuning range spanning both bands or different
Spectrum Spectrum Spectrum NA equipment for the 2 bands?
8.Q-7 How will the technical parameters for the joint

band / the 2 sub-bands look like with regard to
Spectrum Spectrum Spectrum NA supported band range, max. and instantaneous BW?

8.Q-8 How about other/further mm-wave bands?
8.Q-9 What are the Supplier’s views on the bands 3.3 to

Spectrum Spectrum Spectrum NA 4.2 or even 4.99 GHz?
8.Q-10 Which parts (of 3.x GHz) are seen here as

pioneer bands for NR introduction?
8.Q-11 How is the worldwide usage of those new bands

Spectrum Spectrum Spectrum NA judged? (pot. roaming capabilities)
8.Q-12 Is there the implementation of just one band

planned or multiple ones? Which?
8.Q-13 Will there be different equipment (base stations

and devices) for different regions?
8.Q-14 Will there be one band implementation spanning

at least 3.4 to 3.8 GHz?
8.Q-15 Are there any other new bands expected for the
NR introduction? Please elaborate which (incl. tech.
parameters), where (in which regions), when (to
Spectrum Spectrum Spectrum NA become usable) and for which use cases.

8.Q-16 Please elaborate your NR system concepts for

the 3.4 to 3.8 GHz range:
• What are the key technical parameters of systems the
Supplier will provide for 3.5 and 3.7 GHz bands with
regard to duplex scheme, supported bandwidth and
tuning ranges and IBW?
• When will system technology and terminal equipment
for these bands become available?
• Which are the use cases the Supplier sees specifically
for these bands?
In some countries the 3.5 and 3.7 GHz spectrum will be
re-allocated to the markets at different points in time.
This can lead to fragmented spectrum holdings per
operator distributed over both bands. Both NRAs and
Spectrum Spectrum Spectrum NA MNOs might have a need to defragment the spectrum
(re-shuffling) so that spectrum allocations of MNOs
might change over time.
8.Q-17 Will the Supplier’s NR system and terminal

concept for the bands 42 and 43 allow full tunability over
the full 400 MHz to follow any spectrum reshuffling?
Where are potential limiting factors?
It has also to be considered that in the future the band
Spectrum Spectrum Spectrum NA might become expanded towards 3.3 to 4.2 GHz.
8.Q-18 Will the Supplier’s NR system and terminal HW

Spectrum Spectrum Spectrum NA be ready for such expansions?
8.Q-19 Do you see any technical, political or regulatory

hurdles in a specific DTAG footprint country to use the
3.5/3.7 GHz bands for NR introduction?

8.Q-20 Please describe your expectation of worldwide

deployments of LTE vs. NR for the next 5+ years.
Please differentiate between the system side and the
Spectrum Spectrum Spectrum NA device capabilities for the different world regions.
8.Q-21 Please elaborate the advantages and drawbacks

of deploying NR vs. LTE incl. a fair comparison of
system performance, cost, supported use cases.
8.Q-22 What else might drive the selection of either LTE

or NR specifically in band 28?
8.Q-23 Please elaborate your plans for a respective NR

system with regard to technical key parameters like
channel BW, duplex scheme, usage and expected
Spectrum Spectrum Spectrum NA utilization of UL and DL spectrum chunks.
8.Q-24 Do you have any further ideas how the 700 MHz
band in EU markets could be more efficiently used for
NR? (incl. considering the duplex gap, see section 8.2.3
below)

Spectrum Spectrum Spectrum NA 700 MHz band for NR introduction?
8.Q-26 Please elaborate your view on the usage of the

700 MHz duplex gap in future NW deployments. Please
elaborate whether you judge this band as mainstream or
at least important enough to become implemented in
Spectrum Spectrum Spectrum NA Base Stations and terminals.
8.Q-27 When can product availability be expected?

8.Q-28 What is your system concept for the band with

regard to channel BW, bands to pair with, technology to
be used (LTE SDL?, NR?), Base Station deployments,
integration with HW for other bands, use cases?
8.Q-29 Please elaborate if you see this band for other

purposes than described above or with another
allocation.
band
purpose

700 MHz duplex gap spectrum for NR?
political，reg
ulatory
8.Q-31 Please elaborate how the L-Band spectrum

might be best used by EU MNOs and what you expect
Spectrum Spectrum Spectrum NA L-band as a mainstream usage.

8.Q-32 Will/should the L-Band be used as a SDL

component to LTE or NR deployments?
L-
band，SDL
8.Q-33 How are (local) plans judged to use the L-band

in a FDD manner?
L-
band，FDD

8.Q-34 Will there be HW implementations (systems,

devices) first only for the core L-Band (1452-1492 MHz)
or directly for the extended band?
L-
Spectrum Spectrum Spectrum NA band，imple
mentation
8.Q-35 When will respective products become available

Spectrum Spectrum Spectrum NA (system, device)?

L-Band (core, extension) for LTE or NR deployments?
8.Q-37 In which bands and in which regions of the world

do you expect a respective NR standalone (from
spectrum perspective, please read above) deployment?
8.Q-38 When and for which bands will products (system

and devices) be offered?
8.Q-39 What is the recommendation from the Supplier

to DTAG which bands to refarm for NR?
8.Q-40 What would be the benefits for DTAG to follow

such a recommendation? TCO reduction? Performance
Spectrum Spectrum Spectrum NA benefits1?
8.Q-41 Please elaborate your judgement whether such

a coexistence and sharing concept is valuable and for
which reasons.

8.Q-42 Please elaborate your view on how the bands

mentionedhere are expected to be used in the different
markets/regions.
8.Q-43 Please provide your system concepts for using

unlicensed bands for NR:
• What are the performance benefits if adding
unlicensed spectrum (5 GHz / 60 GHz) to NR compared
to doing the same on basis of LTE?
• Which band combinations between NR on licensed
and unlicensed spectrum is considered within the
Supplier’s concept?
• What are the key technical parameters for a system
using the 5 GHz unlicensed band?
• What are the key technical parameters for a system
using the 60 GHz unlicensed band?
• Please elaborate on the difference and benefits of NR
unlicensed vs LTE unlicensed spectrum usage in an
“LAA type of deployment”. The especially the
performance differences between LTE and NR as
secondary carrier should be evaluated.
• Please elaborate on the aspects of using unlicensed
Spectrum Spectrum Spectrum NA 5 / 60 GHz without aggregation to licensed spectrum.
• When will products (system and devices) become
available?
8.Q-44 Please list for the following cases all band

combinations that will be supported in initial NR release
and the following releases (out of the bands listed in
Table 8 1):
• LTE-NR Dual connectivity (including CA combinations
with multiple LTE or NR bands)
Spectrum Spectrum Spectrum NA • CA (NR – NR)
The answer should differentiate between system and
device support.
8.Q-45 Please clarify whether non-contiguous

allocations within band that fit within the instantaneous
bandwidth of the radio HW should be treated as
additional CA combinations.

8.Q-46 While for the above question the key interest is

of course related to the EU/CEPT bands, DTAG would
like to get an overview and comparison with the
situation in other parts of the world.
8.Q-47 Please provide your view on typical band

Spectrum Spectrum Spectrum NA combinations in addition to Band 47 PC5-Sidelink
operation.
8.Q-48 Please provide your view on the evolution of
PC5-sidelink to support NR.
8.Q-49 Please elaborate which spectrum bands should

be best used for supporting drones considering the
specific impact of flying “terminals” with regard to
Spectrum Spectrum Spectrum NA interference to cellular ground based networks.
8.Q-50 Please elaborate which spectrum bands should

be best used for supporting low altitude aircraft or
unmanned flying vehicles considering the specific
impact of flying “terminals” with regard to interference to
Spectrum Spectrum Spectrum NA cellular ground based networks.

Response
Name
Above 24GHz, currently we see 26GHz, 28GHz are most popular.
FC
Please refer to attachment "5G Spectrum SOC Q1.docx".
5G Spectrum
SOC
FC Q1.docx,
Huawei estimates that 3.4~3.8GHz is the highest priority for
launching 5G NR services in 5G Phase 1 by 2019/2020.
In addition it could be that some countries, mainly outside of Europe,
will use part of 4.44~4.9GHz as well by 2020 (e.g. China 4400-
4500MHz and 4800-5000MHz, Japan 4400-4900MHz).
While mmWave such as 28GHz/26GHz will be later than 2019/20.
FC
Most potential use cases on mmWave are eMBB, WTTx, self-
backhaul, backhaul, IoT (e.g. “Smart Home” solution or other
“Broadband IoT” services).
While for C-band, all typical 5G services can be deployed, including
eMBB (capacity and coverage, similar to current smartphone
scenario), mMTC (M2M evolution if no requirement for deep
coverage) and uRLLC use cases.
FC
Currently the normal tuning range of mmWave product is 26.5G-
29.5GHz, in the future the tuning range could be 24.75-27.5GHz
which decided by the spectrum availability and operators’
requirements.
Currently the bandwidth of 100MHz/200MHz/400MHz per carriers
can be supported.
UL and DL capacity split can be flexibly configured. While the normal
tuning range of Band42 product is 3.4G-3.6GHz and Band43 is 3.6-
3.8GHz, in the future the tuning range could be larger which decided
by the spectrum availability and operators’ requirements.
Currently the bandwidth of 100MHz/200MHz/400MHz per carrier for
mmWave can be supported.
While 40/60/80/100MHz per carrier for C-band can be supported.
UL and DL capacity split ratio can be flexibly configured.
FC
Currently two bands (26GHz and 28GHz) are mapped into two HWs.
How to judge these two bands in future we will follow up the 3GPP
standards’ definition.
FC
Currently the technical parameters of these two bands are planned
to be same but different HWs.
FC

Now we see 39GHz (37-40GHz) may be select by china operators

and North Africa operators. While 32GHz (31.8~33.4GHz) is also
under estimation. The mmWave will be allocated and defined in
WRC19 (held in 2019). After the band allocation, it will usually take
several years to deploy in the area.
FC
5G Spectrum
SOC
FC Q2.docx,
Huawei estimates that 3.4~3.8GHz is the highest priority for
launching 5G NR services in 5G Phase 1 by 2019/2020. In addition it
could be that some countries, mainly outside of Europe, will use part
of 4.44~4.9GHz as well by 2020 (e.g. China 4400-4500MHz and
4800-5000MHz, Japan 4400-4900MHz).
FC
5G Spectrum
SOC
FC Q3.docx,
Currently multiple bands are preferred due to the chipset limitation,
such as B42 and B43.
Band42：3.40~3.60GHz
Band43：3.60~3.80GHz
Huawei will keep tracing and analyzing this possibility of spectrum
expansion, and prepare for the products ready in times of need.
FC
Huawei would try our best to provide the same equipment or same
hardware platform for different regions, but it depends on the
technical maturity. While at the same time different regions can
select suitable products according to their dedicated situations, such
as different available spectrum, macro or micro, indoor or outdoor,
single carrier or multiple carriers and etc.
FC
It's not possible to achieve full tuning range over the full 400 MHz
currently due to the capability limits of key chipsets. Huawei will
keep tracing and analyzing this possibility of spectrum expansion,
and prepare for the products ready in times of need.
FC
5G Spectrum
SOC
FC Q4.docx,

• Huawei can provide AAU with OBW/IBW 200MHz in 18Q4;

• RAN system can be ready in 18Q4 , CPE can be ready in 2019,
and Smartphone will be available in 19H1 hopefully;
• eMBB is the key use case for C-band;
For C-band, 30KHz/60KHz carrier spacing modes are supported.
The tuning range is 3.4~3.6GHz, and 3.6GHz~3.8GHz in 18Q4.
Huawei will keep tracing and analyzing this possibility of spectrum
expansion, and prepare for the products ready in times of need.
FC
It's not possible to achieve full tunability over the full 400 MHz before
2020 due to the capability limits of key chipsets. Huawei will keep
tracing and analyzing this possibility of spectrum expansion, and
prepare for the products ready in times of need.
FC
It is TBD.
If DTAG has dedicated requirement, further detailed discussions are
welcome.
FC
In 2017 several official Ministry activities have been triggered across
Europe for preparing operators to use this band for 5G NR. For
example Ireland has auctioned 350MHz of capacity across Bands 42
and 43 in 05-2017. And in 07-2017 Czech Republic Communications
Regulator has completed the auction phase of a tender to grant
rights of use for 3.6-3.8GHz band for high-speed 5G networks.
Recently in 08-2017 Italy Government has awarded several 5G NR
trial licenses in using 3.5GHz in some of the largest Italian cities.
Several other European countries are conducting 5G spectrum
consultations and all of them include 3.5GHz band; they are e.g.
Austria, France, Germany, Spain, Switzerland and all of them
include 3.5GHz. UK is planning to auction 150MHz of 3.5GHz in
coming months. Note that the endorsement of 3.5GHz for 5G NR
services goes beyond the European region. Indeed other regions are
currently looking for 3.5GHz for deploying 5G NR services e.g.
China, Korea, Japan, USA, etc. This large adoption should drive the
eco-system development and favor the 5G NR devices price down
(economy of scale).
FC

For 700MHz, EU is preferred to deploy NR while 800MHz is

deployed for LTE coverage already, and LATAM is preferred to
deploy LTE for coverage firstly.
FC
5G Spectrum
SOC
FC Q5.docx,
It depends on whether the LTE low frequency coverage is ready or
not, EU has 800M LTE low frequency coverage, to deploy the 700M
LTE is not quite valuable, while using it to deploy the NR low-
frequency coverage is preferred to support VoNR, URLLC, etc;
While Latin America where lack of LTE low frequency,700M priority
due to LTE coverage.
FC
For 700MHz in EU, channel BW should be 10MHz, FDD mode is
preferred.
FC
Such as 4T4R or 2T4R can get more coverage and capacity than
2T2R.
FC
5G Spectrum
SOC
FC Q6.docx,
5G Spectrum
SOC
FC Q7.docx,
Huawei does not have eNodeB for supporting b67 yet and the
support of b67 will depend on the market demand.
Currently Huawei Hisilicon chipset hardware is ready for supporting
b67. It is up to 4G LTE terminals suppliers to decide for activating it.
There are no commercial 4G LTE terminals supporting b67 up to
now.
FC

The band b67 is defined in 3GPP R13 as SDL mode for LTE-
Advanced services (need of carrier aggregation for using b67) and it
has to be combined with b20 as per carrier aggregation scenario.
The maximum bandwidth of b67 is 30MHz (3GPP R13). Moreover in
3GPP R13 the definition of b20+b27 carrier aggregation indicates
that it is possible to aggregate up to 40MHz with the following
granularity:
• b20: 5MHz, 10MHz, 15MHz or 20MHz
• b67: 5MHz, 10MHz, 15MHz or 20MHz
In addition note that b67 is not part of 3GPP R15 for 5G NR band as
of today.
Huawei recommends following current 3GPP standards for b67:
• Use of carrier aggregation b20+b67 (b20 being the PCC) for LTE-
Advanced services (MBB scenario)
• As b67 directly increases the overall downlink capacity then one
should better target at least 10MHz and if possible 20MHz in order
to justify the rollout cost of b67 in adding enough capacity into the
network
When there will be clear market demand and requirements for b67
Huawei will analyze for the RRU module implementation. It is
obvious that due to the propagation capability of b67 it is needed to
precisely plan the overlap area between b67 and b20 in order to
make sure that b20 signal can be received wherever there is b67
signal.
The band b67 is useful to boost the downlink capacity in MBB
scenarios.
FC
As per the current 3GPP standardization status the band b67 is
focused on LTE-Advanced services in using b20 and b67.
There is no 3GPP 5G NR standard for supporting b67 yet.
Therefore Huawei does not see other purposes for b67 than the
ones previously discussed in the answer to 8.Q-28.
FC
As per today 3GPP standardization status there are 2 pre-conditions
for using b67:
1. To approve b67 into 3GPP 5G NR bands list
2. To decide for relevant 5G NR carrier aggregation scenario(s) for
supporting b67 (up to now in 3GPP R13 3GPP has approved
b20+b67 carrier aggregation for LTE-Advanced services)
Up to now these 2 pre-conditions are not addressed by 3GPP yet.
FC
5G Spectrum
SOC
FC Q8.docx,

The core part of Ext L-band (1452-1492MHz; 3GPP Band b32) is

currently allocated in some European countries (including Italy,
Germany and UK). In 2017 commercial LTE-Advanced services
have been launched in using b32 (3GPP R13 carrier aggregation
combining b20 and b32) in Italy. First commercial LTE-Advanced
terminals supporting b32 are available (e.g. from HTC and Sony).
The use of Ext L-band will depend on the allocation time schedule:
• If the allocation is done before 2020 then LTE services should be
the relevant choice (assuming b20 is available in markets where b32
will be deployed or any other bands being aggregated to b32 as per
3GPP R14; to refer to answer to 8.Q 31 for details about carrier
aggregation scenarios list for b32).
• If the allocation is done after 2020 then 5G NR services could be
relevant (assuming there are CA scenarios being defined for 5G NR
involving Ext L-band; note that there is no 5G NR CA scenario being
approved yet).
In addition there is a need to standardize corresponding 3GPP CA
scenarios (LTE-Advanced and/or 5G NR) in order to use Ext L-band
in SDL mode.
FC
L-band in a FDD mode is mainly promoted for Japan market due to
legacy 3GPP FDD bands b11 and b21. Some Japan operators see a
benefit for keeping FDD mode for Ext L-band.
For Region 1 Huawei recommends using SDL mode for following
reasons:
1. Both Europe EC and CEPT are currently working on SDL mode
for Ext L-band in Europe (including LTE and 5G NR). The final report
from CEPT to EC should be released by 11-2017 based on SDL
mode.
2. Due to the allocation of the core part of Ext L-band (1452-
1492MHz) as SDL mode in key European countries including
Germany, Italy and UK it makes more sense to keep using SDL
mode for the Ext L-band in Region1.
3. Today cellular networks carry much more traffic in the downlink
and therefore it is more logical for not keeping assigning the same
amount of spectrum resources between uplink and downlink.
Therefore in applying SDL mode one can guarantee that the
spectrum resources are allocated where it is needed. If using SDL
mode operators can take advantage of 90MHz for the downlink
(more than 2 times the downlink capacity if using FDD mode).
4. When “removing” the Ext L-band uplink part as per the SDL model
then one could achieve a significant coverage with Ext L-band
downlink. A similar coverage cannot be achieved in FDD mode.
FC

There are already commercial hardware being deployed for the core
L-Band (1452~1492MHz) in Italy since the end of 2016. There are
on-going works for b32 rollout in Germany.
Major chipsets suppliers and early 4G LTE terminals supporting the
core L-Band (1452~1492MHz) are already commercially available
(e.g. HTC 10 M10h smartphone, Sony XZ Premium smartphone).
FC
5G Spectrum
SOC
FC Q9.docx,
5G Spectrum
SOC
FC Q10.docx,
5G Spectrum
SOC
FC Q11.docx,
For system products, 3.5G and 2.6G had planned in first commercial
release 5G RAN 1.0, while 2.1G NR products plan is depending on
the spectrum availability and operators requirements. 1800MHz UL
LTE&NR spectrum sharing had planned in 5G RAN 1.0.
For devices it will be 0.5-1 year later than system roadmap.
FC
Huawei recommends to DTAG following 5G NR bands:
• 2.1G FDD: Capacity supplement layer for 5G NR services, the
refarming time will depend on the legacy service development trend
and the available bandwidth.
• 2.6GHz TDD: Backup plan in some markets for 5G NR if DTAG
cannot secure C-band for 5G NR services (and of course depending
on the availability of B41 spectrum resources as per countries’
allocation).
FC
5G Spectrum
SOC
FC Q12.docx,
In the early days of deploying NR, the NR terminal is very few and
the service is not enough, it is valuable to using the spectrum
efficiently by sharing with existing LTE. And it is valuable to
expanding the UL coverage of high band of NR (like 3.5G) by
sharing UL spectrum from LTE.
FC

5G support full spectrum access. The working modes include FDD

and TDD.
For sub 3GHz, mostly FDD mode is used.
The current legacy spectrum such as 700M \ 800M \ 900M \ 1.8G \
2.1G \ 2.6G all can be used for 5G. For Europe it is expected to
choose 700MHz for NR,2.6GHz could be an alternative selection
when 3.5G is not available, while 2.1GHz bands can be used for
future 5G hotspot traffic offload. And 1.8GHz could be an NR UL
supplement coexistent with LTE. 800MHz is for LTE wide coverage
for rural, and 900MHz is for GL wide coverage of voice and IoT.
FC
5G Spectrum
SOC
FC Q13.docx,
In initial NR release, HUAWEI support all LTE band, and 3.5G/28G
NR frequency band for LTE-NR Dual connectivity. HUAWEI support
3.5G or 28G frequency band for CA (NR-NR). HUAWEI will follow
3GPP in the following releases.
FC
It should be treated as additional CA combinations.
FC

Please refer to the table being provided as part of the answer to the
question 8.Q-37.
FC
Most of counties and regions' sidelink spectrum is in band 47. Japan
may consider 5.8 GHz (5770-5850MHz) but there is no decision yet.
FC
3GPP will discuss and specify PC5 evolution in 5G NR. It will be
standardized in 3GPP R16 & R17 timeframe. Huawei will fully
support 3GPP activities on that topic in R16/R17.
FC
5G Spectrum
SOC
FC Q14.docx,
According to Huawei X Labs analysis, the dedicated frequencies
used for low altitude aircraft or unmanned flying is necessary to
eliminate the interference. Currently, there is no additional
consideration on which spectrum bands should be best used for
supporting low altitude aircraft.
FC

Back
Key word *Question *Compliant Response
NSA & Multi- NSA RAN

SRAN 19B
RAT DC Sharing
Response
Attachment Remark
Name
Back
The proposed architecture for NSA is underpinned by

Dual Connectivity. Can you confirm that the NSA
configuration will support option 3x whereby the
Secondary Control Group (SCG) cell can control the
splitting of the bearer path.
Multi-mode Multi-mode
SRAN 19A NSA，SCG Other
Feature Feature
How does the eNodeB determine when to add the

secondary (NR) cell group to the user?
NSA，secon
SRAN 19A dary cell Other
Feature RAT DC
group
Describe the simulated/measured impact on the

cumulated 4G/5G NR cell capacity for concurrent 4G
and 5G NR services compared to a non-shared 4G-
system.
SRAN 19A cell capacity FC
Feature RAT DC
Please state any impact on the interfaces or

equipment above where the physical eNB and gNB
equipment are: Co-located; Non co-located.
Multi-mode NSA & Multi- co-/non co-
SRAN 19A FC
Feature RAT DC located
Please describe the User bearers that will be

Multi-mode NSA & Multi- supported within in your solution (i.e. MCG bearer,
SRAN 19A MCG,SCG MCG split bearer, SCG bearer and SCG split FC
Feature RAT DC
bearer).
Where a gNB has no S1-U connection to SGW,

SRAN 19A MCG,SCG please explain how your MeNB will know that SCG FC
Feature RAT DC split bearer are not supported and not attempt this
type of bearer.
Please supply an insight how a dual connection
capable UE will detect that it connected to EN-DC
node with nodes providing NR and eUTRAN
connectivity, how would the 5G service indicator (or
Multi-mode NSA & Multi- NSA UE equivalent) be determined when connected to a eNB
SRAN 19A FC
Feature RAT DC connect supporting EN-DC connectivity.
Vendor shall provide its roadmap on supporting
Public warning system over NR by specifying product
and component proposed.
Response
Name
From software release SRAN15.0 (GA time: Q4-2018)
Huawei starts to support NSA Option 3 and 3x. In
Option 3x, gNodeB is the data split anchor.
The user-plane data can be entirely carried via
gNodeB, or alternatively the user-plane data can be
carried via both gNodeB and eNodeB.
In the case where the user-plane data is carried via
both eNodeB and gNodeB, then there will be a
Secondary Cell Group (SCG) split bearer.
"MRFD-131162 NSA Networking based on EPC (NR)"

in "SRAN15.0 NR Multi-mode Feature Description" on
Page 5~9 of "Appedix I - SRAN15.0 NR Multi-mode
Feature Description" provides more relevant
information if the reader is interested.
In Option3/3X, the X2 connection between LTE and NR

needs to be established (that is to say NR cell is added
into the secondary cell group) when the following
conditions are met:
1) UE reports that it is capable of DC in "DCNR
Capability Indication", and
2) MME confirms the user 5G subscriber information
"NR Restriction", and
3) If there is DL data in the buffer.
If consider LTE cell capacity as A, and NR cell capacity

as B, cumulated 4G/5G NR Cell capacity will be almost
as A + B, comparing with pure 4G as B only.
As example, here is NSA Dual-Connectivity Max User
Experience Peak Rate
LTE 1CC 20M - 0.3 Gbps;
NR 100M - 1.4 Gbps;
NSA DC LTE 1CC + NR - almost 1.7Gbps.
When eNB and gNB are co-located, eNB and gNB

should be deployed in the same BBU.
When eNB and gNB are Non co-located, eNB and gNB
should be deployed in two BBU. An additional BBU is
needed in this case.
For NSA, the tolerant latency requirement on X2 is
20ms, the tolerant latency requirement on S1 is 20ms
Huawei supports MCG Bearer and SCG Split Bearer

for option 3X.
Huawei supports MCG Bearer and MCG Split Bearer
for option 3.
S-gNB should reject the SCG addition request from

eNB. Then the SCG split bearer will not be built.
According to the addition bit per user in SIB 2 message

in LTE system based on the 3GPP protocol, whether
the cell supports the NSA-DC function, the UE will
displays the 5G network capability according to the SIB
2 message. When connected to the MeNB, MeNB will
perform PCC anchoring, SCell management and
PSCell configuration, distributing primary carrier,
adding PSCell and SCell for the UE..
Back
The 5G network is TDD, the LTE network is FDD,

how will time synchronisation happen between the
LTE & TDD two networks.
FrontHaul &
Synchroniza NR
SRAN Backhaul & 19A FC
tion Synchroniza
Sync
tion
Will the answer to the above question be different if

5G is also FDD as some bands support this.
LTE & FDD
FrontHaul &
Synchroniza NR
tion Synchroniza
Sync
tion
How will beam management between two 5G cells

anchored on the same LTE happen to facilitate inter
5G hand off and what is the BBU impact on beam
FrontHaul & management. What is the impact on random access
Synchroniza inter-5G
SRAN Backhaul & 19A time? FC
tion handoff
Sync
How will beam management between two 5G cells

anchored on different LTE cells happen to facilitate
inter 5G and inter 4G handoff and what is the BBU
FrontHaul & inter 5G and impact on beam management. What is the impact
Synchroniza
SRAN Backhaul & 19A inter LTE on random access time? FC
tion
Sync handoff
What synchronisation technologies do you support

in NR (for example GPS, IEEE1588, SyncE)? If you
FrontHaul & support IEEE1588 will this be based on v2 or the
Synchroniza syn emerging v3?
tion technologies
Sync
What synchronism specification supports the gNB
FrontHaul &
Synchroniza syn
Backhaul & 19B FC
tion technologies
Sync
Does the gNB complies with specifications

G8275.1, G8275.2, G8275.3 for time and phase
FrontHaul &
Synchroniza syn syncrhonization).
Backhaul & 19B PC
tion technologies
Sync
411. What are the synchronism requirements for the

FrontHaul & different type of services of 5G? What standards
Synchroniza syn
Backhaul & 19B FC
tion technologies have to comply the grand master in order to comply
Sync with the 5G synchronism requirements?
412. What kind of synchronism is necessary to set

up between 5G neighbour operators in order to
avoid interferences inter operator?
FrontHaul &
Synchroniza syn
Backhaul & 19B FC
tion technologies
Sync
413. In case operators do not reach coordination
FrontHaul & agreements, how much guard band would be
Synchroniza syn
Backhaul & 19B FC
tion technologies necessary to define in the border between bands of
Sync different operators?
1. If operators are synchronized, would PC

FrontHaul &
Backhaul &
Synchroniza
19B
syn it be possible to activate dynamic TDD?
tion technologies
Sync
415. Requirements on accuracy (max phase-error): FC

a) Specify the needed timing accuracy for basic 5G
FrontHaul & services. List those services.
Synchroniza syn b) List services & technologies that need tighter
Backhaul & 19B
tion technologies timing accuracy and specify those limits.
Sync
416. Solution description: FC

a) Describe the preferred synchronization solution,
including the supported sync
interfaces, like Ethernet carrying PTP & SyncE,
2M, 1PPS, UTI, GNSS.
FrontHaul & b) List the applicable ITU-T synchronization
Synchroniza syn
Backhaul & 19B
tion technologies recommendations that the solution supports.
Sync c) Is NTP needed in certain scenarios, e.g. by a
gNB-CU?
417. What are plans for Over the Air NC

FrontHaul & Synchronization?
Synchroniza syn
Backhaul & 19B
tion technologies
Sync
418. Should all operators use gnss traceable sync FC

source (via gnss card or network sync)? What is
impact if one is using GPS, aother one UTC and
third one own independent time source not
treceable to gnss?
FrontHaul &
Synchroniza syn
Backhaul & 19B
tion technologies
Sync
419. The solution should support Timing over PC

packet IEEE1588v2, frequency and phase:
a) An embedded PTP Slave Clock function
according to G.8273.2 should be supported.
FrontHaul & b) Use of the PTP TC correction field to remove
Synchroniza syn PDV should be supported.
Backhaul & 19B
tion technologies c) Is PTP Assisted Partial Timing Slave Clock
Sync
(APTSC) according to G.8273.4 supported?
420. TC (transparent clock) support is proposed to FC

achieve better performance for network sync. Some
FrontHaul &
Synchroniza syn network elements are using TC adding residence
Backhaul & 19B
tion technologies time to correction field. Slave clock should read this
Sync
field to be able to remove PDV. Is TC planned
feature?
421. Synchronization by GNSS: PC
a) The solution should support synchronization by
GNSS.
b) State which of GPS, Glonass and Galileo
(readiness) that are supported.
c) Provided that an external antenna is proposed,
does it support multi-constellation?
FrontHaul & d) Is an integrated multi-constellation antenna
Synchroniza syn
Backhaul & 19B
tion technologies supported?
Sync
422. How multiconstallation with GPS and Glonass FC

is working? There is time difference so how leap
second from Glonass are handled? What gnss time
is used in multiconstallation when there is outage in
GPS but Glonass available?
FrontHaul &
Synchroniza syn
Backhaul & 19B
tion technologies
Sync
423. Robustness, performance and holdover: FC

a) Specify the QoS performance – at least in term of
a PDV percentile and Packet Loss
Ratio – that should not be exceeded for the
transport of the PTP flow.
b) Specify the oscillator type and its characteristics.
c) Specify how long time all services stays up when
all sync sources are lost and the gNB
needs to rely on its own oscillator only. Describe
how the 5G users will be affected by
the decreasing sync performance in this case.
d) Specify how long time all services stays up when
FrontHaul & timing/PTP sync source is lost but
Synchroniza syn
Backhaul & 19B
tion technologies SyncE frequency is still traceable to PRC.
Sync Describe how the 5G users will be
affected in this case.
e) Describe the sync performance monitoring
features (for PTP, SyncE and GNSS) and
alarms that can be triggered at performance
degradations
424. Clarify when ATR function is usable and how FC

PTP slave clock algorithm is working in gNB? How
long it takes when basic sync requirement +/-1.5us
phase accuracy at antenna output of eNB is
achieved during holdover. What is expected for
Inter-Cell Coordination services like CoMP?
FrontHaul &
Synchroniza syn
Backhaul & 19B
tion technologies
Sync
425. The Supplier should describe how intra- and FC

inter-operator synchronisation is to be established
and coordinated between different use cases with
FrontHaul & different UL/DL TDD slot ratio. The Supplier should
Synchroniza syn
Backhaul & 19B
tion technologies describe how guardbands can be avoided and
Sync interference mitigated most efficiently
426. Telecom profiles support: FC
a) A phase sync transport according to G.8275.1
FrontHaul & b) Is transport according to G.8275.2 supported? Is
Synchroniza syn
Backhaul & 19B
tion technologies it recommended?
Sync
427. Sync source redundancy, like multiple GMs FC

and SyncE backup:
a) Describe the redundancy options for the T-SC
function as well as the T-GM function
(if applicable) of the gNB.
b) Describe the effects, like short term phase
transients, of a fail-over from one sync
FrontHaul & source to another one.
Synchroniza syn
Backhaul & 19B
tion technologies
Sync
428. Is it possible to have SyncE as a backup FC

FrontHaul & source (if traceable to ePRC G.811.1) giving better
Synchroniza syn
Backhaul & 19B
tion technologies performance compared to gNB own oscillator?
Sync
FrontHaul & 429. Vendor shall provide the requirements of FC

Synchroniza syn maximum phase-error and timing accuracy for basic
Backhaul & 19B
tion technologies 5G services, incl. data and voice.
Sync
430. Vendor shall identify and list the timing- FC
stringent 5G functions or services, and provide (for
FrontHaul &
Synchroniza syn these functions or services) the required maximum
Backhaul & 19B
tion technologies phase-error and timing accuracy, and the
Sync
recommended synchronization solution for those
functions.
FrontHaul & 431. Vendor shall provide the calculation of the FC
Synchroniza syn required link budget for each of the offered functions
Backhaul & 19B
tion technologies or services.
Sync
FrontHaul & 432. Vendor shall describe the supported and the FC
Synchroniza syn recommended synchronization solution for 5G NR
Backhaul & 19B
tion technologies deployment.
Sync
FrontHaul & 433. Vendor shall indicate if its Active or Passive FC
Synchroniza syn Antenna solution has an integrated GPS antenna
Backhaul & 19B
tion technologies receiver for synchronization.
Sync
Vendor shall detail how the proposed FC
synchronization solution works with legacy networks
with SRAN.
FrontHaul &
Synchroniza syn
Backhaul & 19B
tion technologies
Sync
1.Vendor shall state if and where his FC

synchronization requirements for 5G
FrontHaul &
Synchroniza syn
differ from 4G requirements and shall
Backhaul & 19B
tion technologies describe the differences and
Sync
corresponding RAN
features/functionalities for which they are
needed.
FrontHaul & 436. Vendor shall indicate if 1588v2 could be used FC
Synchroniza syn in a 5G NR The vendor must indicate changes in
Backhaul & 19B
tion technologies architecture of clocks, new standards, etc
Sync
437. Vendor shall propose sync solution for indoor FC
and outdoor deployment
FrontHaul &
Synchroniza syn
Backhaul & 19B
tion technologies
Sync
438. Based on the synchronization accuracy level FC

your eCPRI can achieve, please list the features in
5G that you can support, and list which features
would have performance impact, and the list of
features that wouldn’t be able to support.
FrontHaul &
Synchroniza syn
Backhaul & 19B
tion technologies
Sync
439. Vendor to describe your overall FC

synchronization solution for 5G network and its
roadmap, including but not limited to GPS and
IEEE1588v2, by specifying product and component
proposed.
FrontHaul &
Synchroniza syn
Backhaul & 19B
tion technologies
Sync
440. Vendor to provide description of any FC
synchronization equipment (e.g. IPCLK server)
capabilities so as to meet 5G synchronization
requirements
FrontHaul &
Synchroniza syn
Backhaul & 19B
tion technologies
Sync
441. Vendor to describe any features or service FC

(e.g. eDRX) that require gNB and NGC timing
FrontHaul & synchronization, accuracy required and impacts for
Synchroniza syn not meeting them. Please describe how your
Backhaul & 19B
tion technologies solution can address these synchronization
Sync
requirement between gNB and NGC
442. Vendor shall describe its synchronization FC

configuration plan and solution for each method
FrontHaul & shall be suggested for gNB-CU, gNB-DU, and gNB-
Synchroniza syn RRH (Remote Radio Head), respectively.
Backhaul & 19B
tion technologies
Sync
443. Vendor shall describe your view on IP network FC

provided synchronization incl. IEEE1588v2 solution
to be able to meeting 5G NR synchronization
requirements, considering Nano second level timing
FrontHaul & accuracy required on NRs. And in order to achieve
Synchroniza syn those requirements, please describe the network
Backhaul & 19B
tion technologies configuration plan, clock server location (e.g. co-
Sync
located with CU or DU etc.), number of router hops
allowed, and/or support ONT distance etc.
444. Vendor shall describe the overall FC

synchronization concept for the early deployment of
FrontHaul & eMBB and WTTx, and the evolution path towards
Synchroniza syn 5G mobility, URLLC and MCX (Mission Critical
Backhaul & 19B
tion technologies Services) deployment.
Sync
445. Please provide the typical oscillator phase FC

sync hold-over time in case reference sync source
(GNSS, IEEE1588v2) becomes unavailable.
FrontHaul &
Synchroniza syn
Backhaul & 19B
tion technologies
Sync
Response
Name
SSB Bitmap and SSB-PRACH will be sent to UE through SIB
message in LTE. SSB bitmap indicates the position of SSB.
UE can obtain the SSBId through SSB bitmap and sents the
PRACH in corresponding occasion.
In mmWave, the QCL between gNB and UE in P1~P3
procedure will be sent to UE through RRC message using
LTE. UE uses the QCL to find the corresponding receiving
beams.
SSB Bitmap and SSB-PRACH will be sent to UE through SIB

message in LTE. SSB bitmap indicates the position of SSB.
UE can obtain the SSBId through SSB bitmap and sents the
PRACH in corresponding occasion.
In mmWave, the QCL between gNB and UE in P1~P3
procedure will be sent to UE through RRC message using
LTE. UE uses the QCL to find the corresponding receiving
beams.
The Secondary Node Change procedure is initiated when UE

moves from one NR cell to another NR cell.
The SgNB change is based on SSB measurement.The SSB
sweeping of two cells are independent.When SgNB change is
performed，UE will receive the SSB and synchronize to the
new cell ，then do random access procedure.There is no
impact on random access time.
The inter 4G with SgNB handover is performed first, and then

SgNB Change procedure is performed.
The SgNB change is based on SSB measurement.The SSB
sweeping of two cells are independent.When SgNB change is
performed，UE will receive the SSB and synchronize to the
new cell ，then do random access procedure.There is no
impact on random access time.
Huawei can support GPS, GLONASS, BeiDou, IEEE1588v2,

and 1588v2+SyncE. For NR 3GPP defines that NR needs
time synchronisation. For the sake of security snd reliability,
huawei suggests to use GPS + 1588V2 where 1588V2 is the
back-up. 1588v3 no longer proceeds as far as Huawei
understands, and it will be replaced by 1588V2.1.
HW gNBs support GPS synchronization. The synchronization

accuracy needs to meet the 3GPP protocol requirements.
HW gNBs support 1588v2 synchronization:
(1) G.8275.1 can be fully supported.
(2) G.8275.2 cannot be supported for TDD sytem, because
G.8275.2 is through the network, not hop-by-hop support 1588
synchronization, if the network problems such as jitter is too
large, gNB clock lock may be failure, which will lead to TDD
system cannot work.
HW gNBs support time and phase syncrhonization:

(1) G.8275.1 can be fully supported
(2) G.8275.2 can not be supported for TDD sytem
(3) G.8275.3 does not exist.
see attachment '5G Synchronizaiton SOC Q1'
Generally, the frequency bands between operators are

separated. The separated guardband can guarantee that there
is no interference between operators. If there is no guardband
between 5G neighbour operators, it is requires that the frame
boundary be aligned with the common clock source (such as
GPS), and the TDD UL/DL ratios are consistent to ensure no
interference
For 3.5GHz NR, Huawei suggest not setting flexible TDD

(dynamic TDD), because 3.5GHz is considered for continuous
coverage and multi-operator will deploy at the same area.
Huawei suggests aligned TDD configuration between cells.
a) For basic 5G TDD services, needed timing accuracy is

±1.5us.
b) For Inter-Cell Coordination services, such as
CoMP/SMP/DMP, need tighter timing accuracy is ±350ns for
C-band and ±100ns for mmWave.
Looking into today’s technology, Over the Air Synchronization

is far from being mature. There is no reliable reference clock
in this case, so gNBs are not likely to be synchronized among
each other.
It is not necessary for all operators use GNSS traceable sync

source. The industry trend is either GNSS or network sync.
UTC is not applicable here as it is not continuous source.
Either GNSS or Network Sync or other source, need following:
1. Accuracy on gNB is < 1.5us
2. Clock source is continuous signal
Then operators will not interfer others as long as T-GAP is
complied with 3GPP R4-1700208/R4-1700209.
TGAP ≥ 2* TSync + 2*Tprop_cell edge + TBS on off+ TBS
off on
a) G.8273.2 is the requirement for transport equipment.

Huawei basestation is compliant with G.8271.1, meeting
150ns requirement as end application.
b) Huawei supports the required function, but recommends to
use hop-by-hop BC realizing 1588v2 synchronization network,
to guarantee the synchronization accuracy.
c) Huawei cannot support APTSC now and we are willing to
discuss with customer.
Huawei gNBs can read TC packets from the network TC

mode. However, considering the problem of delay introduced
by TC nodes in the network, such problems may cause
service failure in gNB eventually. Therefore, it is not
recommended to adopt TC in the network. Huawei
recommended to use hop-by-hop BC mode.
a) The proposed solution supports synchronization by GNSS;
b) Huawei can support GPS and Glonass. Galileo is not
supported now. If needed, Huawei is willing to discuss further
with customer.
c) The proposed solution supports dual constellation. Please
be noticed that until now the UMPT board capability of dual
constellation (GPS and Glonass) is a special hardware version
for Russia.
d) Huawei is doing initial study of the CGPS solution to mux
the GPS clock signal through CPRI links. For 5G, fronthaul will
be eCPRI, and Huawei need to check the technology
requirements accordingly.
Multiconstallation card is supported to be either GPS only,

Glonass only or dual mode.
In dual mode, GNSS system is seleted upon satellites traced.
When GPS is outage, then system will be swithed to Glonass,
and vice versa.
There is 3 hour time difference between Glonass and GPS, as
well as leap second. In GPS system, there is leap second
indication so that UTC time could be easily calcuted. In
Glonass system, leap second will be considered by Huawei
solution and transformed to GPS or UTC time.
a) For time synchronization, Huawei suggests hop-by-hop BC

realizing 1588v2 synchronization network to guarantee the
synchronization accuracy, so there is no PDV and packet loss
in this situation; If it is time synchronization of ATR mode
transparent network, it only can use FDD mode.
b) Huawei basestation adopts industrial level OCXO crystal
oscillator.
c) As the timing related details in the 3GPP protocol, such as
TX/RX transition, TA offset, GP length, etc., have not yet been
finalized, Huawei cannot determine the length of the holdover.
After 3GPP protocol is frozen, Huawei will follow protocol.
d) Huawei gNB can maintain the holdover for more than 48
hours in case of frequency synchronization failure.
e) Huawei gNB supports detecting and reporting the existing
synchronization quality (e.g. clock source failure alarm report)
by using timing quality monitor function.
Huawei gNBs support ATR function. Note: ATR can only be

used under FDD system. TDD system is not recommended to
use ATR mode due to high precision of clock synchronization.
gNB internal clock algorithm will track the alignment of
external clock, smooth filtering abnormal jitter.
Phase holdover time for sub6G is around 8~12 hours:GP is
half of LTE 15K 140us to 30K 70us, and TAoffset is 13us to
20us.
Phase holdover time for 28G is around 4 hours: GP may be
reduced further (60K 35us), TAoffset is 6us.
Inter-cell coordination service like CoMP requires accuracy of
+/-350ns. Therefore, the holdover time is less than 6 hours
Intra- or inter-operator will select 1588v2 or GPS function to

guarantee inter-site time synchronization. In addition, UL/DL
TDD slot ratio should be same to guarantee TDD transmit and
receive at the same time with no interference.
There is no need for other guardbands, except the TX/RX
transition GP in TDD own system
a) Huawei support phase sync transport according to
G.8275.1.
b) G.8275.2 can be supported for FDD system, but not
recommended for TDD system. The reason G.8275.2 works
through the network, instead of hop-by-hop 1588
synchronization. The gNB clock lock could go failure if the
problem such as large jitter will occur.
a) Huawei suggests hop-by-hop BC network, in this situation,

gNB just need to synchronize previous-hop. If BC connect to 2
T-GM, BC will select the clock source (2 T-GM is not visible to
gNB). Huawei gNB cannot support T-GM server.
Huawei gNB supports satellite synchronization and 1588v2
synchronization backup. The clock source will be selected
based on the quality;
b) Switching from a failed clock source to a normal clock
source usually takes a short time (about ten minutes). As long
as the new clock source is normally available, there will be no
synchronization phase transition or service impact during the
process.
SyncE is recommended to be used as a backup clock source

instead of main reference source. 0.1ppb SyncE is helpful to
extend BTS hold time up to 24 hours when reference source is
lost
3GPP specifications define the following clock accuracy

requirements of gNodeB synchronization: gNodeBs must be
time-synchronized within the accuracy of ±1.5 μs.
For Inter-Cell Coordination services, such as
CoMP/SMP/DMP, tighter timing accuracy is needed: ±350ns
for C-band and ±100ns for mmWave.

With the Common Clock feature, all RATs of a multimode
base station share a clock source and require only one set of
clock equipment.
The following clock sources can be configured for clock
sharing in multimode base stations: GPS/BeiDou clock, BITS
clock, E1/T1 clock, IEEE 1588v2 clock, synchronous Ethernet
(SyncE) clock, 1PPS+TOD clock, IEEE 1588v2+SyncE clock,
and GPS+SyncE clock. The IEEE 1588v2 clock and
synchronous Ethernet clock are enhancements. Each RAT
has a separate license control item for these two types of
clocks. When the Common Clock feature is used, the license
of a single RAT can be shared by other RATs

Huawei 5G RAN2.0 supports the following synchronization
solutions both for indoor and outdoor deployment:
• Single GPS solution
• GPS+1588V2 (BITS at the core layer)
• 1588V2 (BITS at the core layer)
• 1588V2 (BITS at the access layer)
• Dual 1588V2 (Dual BITS)
1588V2 synchronization is recommended for indoor sites.
GPS synchronization is recommended for outdoor sites.
Huawei will conform to 3GPP TS38.104.

For MIMO or TX diversity transmissions, at each carrier
frequency, TAE shall not exceed 65 ns.
For intra-band contiguous carrier aggregation, with or without
MIMO or TX diversity, TAE shall not exceed 260ns.
For intra-band nnon-contiguous carrier aggregation, with or
without MIMO or TX diversity, TAE shall not exceed 3us.
For inter-band carrier aggregation, with or without MIMO or TX
diversity, TAE shall not exceed 3us.
Huawei gNodeBs can work with diversified clock sources to

suit different clock topologies. gNodeBs support the following
clock sources:
GPS clock
The gNodeB internal clock can be synchronized with the
transport network. No auxiliary clock equipment is required,
which reduces costs. The synchronized clock is of the required
accuracy to meet both radio frequency and transport network
requirements.
The clock signals are processed and synchronized as follows:
1. The GPS antenna system receives GPS signals at 1575.42
MHz and transmits the signals to the GPS satellite card. The
system can simultaneously trace up to eight (normally three or
four) satellites. The GPS satellite card processes the signals
and transmits them to the master clock module.
2. gNodeBs must be configured with a UMPTe board to
support the GPS clock.
gNodeBs must be configured with a GPS or RGPS receive
device to support the GPS or RGPS clock
IEEE1588v2 ATR
With 1588v2 ATR, synchronization packets are transparently
transmitted from the clock server to gNodeBs. Intermediate
transmission equipment is not required to support the
IEEE1588v2 standard, and gNodeB clock synchronization has
less dependency on the transport network.
1. This function requires 1588v2 L3 unicast, 1588v2 16.1, and
ITU-T G.8275.2. It is recommended that packets be sent at a
frequency of 128 Hz (128 packets per second) to improve the
synchronization precision.
2. IEEE1588v2 applies only to IP over FE/GE links.
3. The IEEE1588v2 time synchronization requires that all
intermediate transmission equipment between the gNodeB
and the clock server support the BC or TC function defined in
IEEE1588v2.
For most scenarioes, 5G synchronization requires time
synchronization. Huawei gNB can support GPS or 1588v2. As
to 1588v2, Huawei provides IPCLK500 or IPCLK3000 that
supporting 1588v2 ATR Synchronization to meet 5G
synchronization requirements. The IPCLK500 is an IEEE
1588v2-2008, ITU-T G.8265.1, ITU-T G.8275.1, and ITU-T
G.8275.2 compliant timeserver that delivers carrier-class and
high-precision time and frequency synchronization for
downstream devices. The IPCLK500 provides high-density
synchronization input/output ports and therefore offers a cost-
effective IP clock solution.In the cost-effective, easy-to-deploy
IP time synchronization solution, IPCLK500’s function as 1588
adaptive time recovery (ATR) servers to provide time
synchronization information for base stations. The
intermediate three or four hops of transmission links do not
need to support IEEE 1588v2. In the scenario in which 1588v2
ATR is not required (such as in a frequency synchronization or
hop-by-hop time synchronization scenario), the IPCLK3000
deployed at the core layer can provide frequency
synchronization information for base stations.The IPCLK500
can provide time or frequency synchronization to Huawei and
third-party base stations based on ITU-T standards and IEEE
1588v2-2008 16.1.
To avoid uplink and downlink interference, the time

synchronization between different gNBS are required. Time
synchronization is not required between the gNB and the NGC
There is no synchronous requests for CU now. GNB-DUs are

synchronized through GPS or IEEE1588v2 PTP. AAUs are
synchronized by connecting to DU. The interface between
gNB-DU and AAU(gNB-RRH) may be CPRI or eCPRI
interface, respectively, synchronization method follows the
CPRI and eCPRI protocol.
Huawei recommends GPS synchronization method to achieve

Nano second level timing accuracy on NRs, and IEEE1588V2
solution for high reliability. The number of router hops depends
on the time of each hops, and we follow G8271.1.
For time synchronization, only basic services and coordinated

services are differentiated. The clock requirements for different
services such as eMBB and URLLC are the same. Based on
the 3GPP version definition, the clock synchronization
requirements for basic services between base stations are +/-
1.5us. For coordinated services, the current protocol hasen’t
required yet.
If all clock sources are unavailable, the internal clock of
gNodeB can work in the free running mode to ensure proper
operation of the gNodeB.
The enhanced stratum-3 oven controlled crystal oscillator
(OCXO) with high accuracy works as the master clock of the
gNodeB and enables the gNodeB to run properly for up to
eight hours.
Back
New New Sub- Version
Category Category （Time）
333. IP addressing requirements of gNB
FrontHaul &
Synchroniza LTE & TDD NR
Backhaul & 19A FC
tion Synchronization
Sync
FrontHaul & 334. User and control plane protocol stack of F1 interface.
Backhaul & transmisson 19B transmisson FC
Sync
335. What are the latency and jitter requirements of radio
protocols of F1 interface (DU-DU)? Does this restriction
FrontHaul & may limit the maximum distance between CU and DU?
Backhaul & transmisson 19B transmisson What maximum distance you propose? Are there specific FC
Sync latency and jitter requirements for different use cases
(eMBB, mMTC, uRLLC)?
336. What transport architecture do you propose for the F1

interface (CU-DU interface)? What would be the protocol
stack? What addressing plan do you propose? What is the
impact at IP level addressing? Is it feasible to introduce L3
FrontHaul & solutions like IP/MPLS or eVPN?
Sync
337. For what and when to implement L3 between VRAN

and EPC?
FrontHaul &
Sync
338. Requirements for segmentation of services between

DU and CU. Will each service be differentiated by VLAN?
FrontHaul & How differentiated each service from DU to CU?
Sync
FrontHaul & 339. What are the latency and jitter requirements of N1 FC
Backhaul & transmisson 19B transmisson interface? Are there specific latency and jitter requirements
Sync for different use cases (eMBB, mMTC, uRLLC)?
340. What transport service is required for the different FC
services between vRAN and EPC.
FrontHaul & - EVPN
Backhaul & transmisson 19B transmisson - L3VPN
Sync - SR ( VPN sobre SR ?)
341. For what and when to implement L3 between VRAN FC

and EPC
FrontHaul &
Backhaul & transmisson 19B transmisson
Sync
FrontHaul & 342. Is it required Flex Ethernet to have a pure Slicing? FC

Sync
343. What capacities are required in the differente FC
interfaces.
FrontHaul &
- F1: DU-CU
- N1 for different aggregation levels.
Sync
344. The gNodeB shall support Optical ports: NC

a) Third party grey and coloured pluggable optics should be
supported.
b) CWDM plugs should be supported.
FrontHaul & c) DWDM plugs should be supported.
Backhaul & transmisson 19B transmisson d) Wavelengths for tuneable DWDM interfaces should be
Sync possible to manage via an API.
e) Mono/single fiber plugs should be supported.
345. The solution should support IPv4 and IPv6 for FC

transport.
FrontHaul &
Sync
346. The built-in switch function should be independent NC

from other gNB functions in the following respects:
a) Restart of other gNB functions should not force a restart
of the switch. (So that
FrontHaul & forwarding of traffic to/from an attached eNB/NB/BTS will
Backhaul & transmisson 19B transmisson not be affected.)
Sync b) Support for an API towards the switch for configuration
and reading.
347. Describe the supported protocols and forwarding PC

features of the Ethernet switch, including support for C- and
S-VLANs, G.8032 & other L2 redundancy options, fetaures
for broadcast/multicast/unknown-unicast traffic limitations
and storm controls. Also specify the number of VLANs
supported and the maximum frame size supported.
FrontHaul &
Sync
348. Describe support for L3 forwarding and routing, FC

including redundancy options. E.g. support for VRF Lite,
static routing + BFD, dynamic routing protocols (if
applicable)
FrontHaul &
Sync
FrontHaul & 349. Briefly describe the support for IPsec, including FC
Backhaul & transmisson 19B transmisson suggested security GW implementation. What options, if
Sync any, do you see for supporting low latency?
350. All nodes of the proposed solution should be able to PC
FrontHaul & classify traffic into different transport QoS classes, and to
Backhaul & transmisson 19B transmisson set the corresponding QoS markings (DSCP in IP packets,
Sync PCP + DEI bits in Ethernet frames) on all outgoing packets.
351. Fronthaul technologies: FC
FrontHaul & a) Describe the support for CPRI.
Backhaul & transmisson 19B transmisson b) Describe the support for eCPRI and associated split
Sync points.
352. Fronthaul bandwidth and performance requirements: FC

a) Specify required bit rates and maximum latency for
CPRI.
FrontHaul & b) Specify required bit rates and applicable QoS
Backhaul & transmisson 19B transmisson performance limits (e.g. max or percentile
Sync delay limit, packet loss ratio) for the different eCPRI split
point options supported
353. Transport for packet fronthaul: FC

a) What are your plans for eCPRI + IEEE 802.1CM
support? Given the split point options
supported, do you see a need for TSN features, like pre-
emption? Or will an ordinary
FrontHaul & strict priority scheduler support low enough queuing
Backhaul & transmisson 19B transmisson delay?
Sync b) Do you plan to support IEEE1914.1 and 1914.3?
(It is noted that neither 802.1CM nor 1914.1/3 are finalized
yet and thus the answers to the above questions cannot be
firm commitments.).
FrontHaul & 354. Vendor shall give details about the throughput FC
Backhaul & transmisson 19B transmisson supported for backhaul in proposed gNodeB product, and
Sync the number and characteristics of ports (electrical/optical).
FrontHaul & 355. Vendor shall describe its support for CPRI in its FC
Backhaul & transmisson 19B transmisson proposed 5G NR gNB product.
Sync
FrontHaul & 356. Vendor shall describe its support for eCPRI and FC
Backhaul & transmisson 19B transmisson associated split points in its proposed 5G NR gNB product.
Sync
FrontHaul & 1. Vendor shall specify which interfaces are FC
Backhaul & transmisson 19B transmisson supported, according to each split option.
Sync
358. Vendor shall show his roadmap for support of the F1 PC
and Fx interfaces.
FrontHaul &
Sync
359. Vendor shall describe typical transport requirements FC

FrontHaul & for different interfaces (fill in table below). If values depend
Backhaul & transmisson 19B transmisson on eMBB, mMTC or URLLC, please describe the
Sync differences on the different interfaces.
360. Vendor shall specify backhaul requirements of FC
bandwidth and performance in terms of
FrontHaul & - required bit rates and latency
Backhaul & transmisson 19B transmisson - required bit rates and QoS performance metrics e.g.
Sync maximum latency, packet loss ratio, etc.
1. Vendor shall specify QoS and QCI, for FC

FrontHaul &
Backhaul & transmisson 19B transmisson different services, in terms of GBR/NGBR,
Sync Priority, delays and bit error rates.
362. Vendor shall describe the recommendations for the FC
deployment strategy of eCPRI/CPRI.
FrontHaul &
Sync
FrontHaul & 363. Vendor shall describe the support of NGFI and xRAN NC
Backhaul & transmisson 19B transmisson Fronthaul interfaces in its 5G NR solution.
Sync
FrontHaul & 364. Supports the use of Sync/access IP address as router, FC
Backhaul & transmisson 19B transmisson with all other IP addresses routable via the NE's
Sync Sync/access IP address.
FrontHaul & 365. Supports the use of separate IP addresses for FC

Backhaul & transmisson 19B transmisson Sync/Access, Control Plane, User Plane and Management
Sync Plane
FrontHaul & 366. Supports S1-U and X2-U applications using different FC
Backhaul & transmisson 19B transmisson IP addresses.
Sync
FrontHaul & 367. Simultaneously supports IPSec tunnels in star (to EPC FC
Backhaul & transmisson 19B transmisson and indirect X2/Xn) and mesh topologies (direct X2/Xn
Sync traffic).
368. Supports ACLs for selecting traffic for IPSec tunnels FC
FrontHaul & based on any or all combination of source IP or subnet,
Backhaul & transmisson 19B transmisson destination IP or subnet, protocol type, source port,
Sync destination port.
FrontHaul & 369. Supports automatic configuration of IPSec rules to FC

Backhaul & transmisson 19B transmisson support sending X2/Xn traffic over a point-to-point IPSec
Sync tunnel rather than a central IPSec tunnel.
FrontHaul & 370. Supports sending encrypted X2-U traffic via point-to- FC
Backhaul & transmisson 19B transmisson point IPSec tunnel while also sending unecrypted S1-U
Sync traffic.
FrontHaul & 371. Solution supports IPv4 and IPv6 on all interfaces, and PC
Backhaul & transmisson 19B transmisson in dual-stack configuration (both IPv4 and IPv6 in use at the
Sync same time on the same logical interfaces).
FrontHaul & 372. Supports automatically configuring eNB-gNB X2 links FC

Sync
1.Supports automatically configuring eNB- FC
FrontHaul &
Backhaul & transmisson 19B transmisson gNB IPSec tunnel, including key and certificate
Sync management.
FrontHaul & 374. Supports automatically configuring interSupplier eNB- FC
Backhaul & transmisson 19B transmisson gNB IPSec tunnel, including key and certificate
Sync management.
FrontHaul & 375. Supports star and mesh topologies simultaneously. FC

Sync
376. Solution must provide for specifying which IP address FC
FrontHaul & should be used for each and every logical interface, such
Backhaul & transmisson 19B transmisson as S1-U, X2-U, X2-C, OAM, etc. This list of logical links is
Sync not exhaustive
FrontHaul & 377. Solution must be able to send and receive S1-U plane FC
Backhaul & transmisson 19B transmisson traffic both with and without IPSec protection, at the same
Sync time, while sharing X2-U IP address.
378. Solution must support sending and receiving X2-C or FC
Xn-C traffic via central IPSec gateway, and via point to
FrontHaul &
point IPSec tunnels between NEs, at the same time.
Solution should provide for configuring the choice of central
Sync
or point to point per link, and provide a default for all new
links.
379. Solution must support sending and receiving X2-U or FC
FrontHaul & Xn-U traffic via central IPSec gateway, via point to point
Backhaul & transmisson 19B transmisson IPSec tunnels between NEs, or untunnelled and encrypted
Sync via normal IP routing principles
FrontHaul & 380. Solution must be configurable to send latency critical NC

Backhaul & transmisson 19B transmisson signalling via X2-U, with and without encryption
Sync
381. A SON solution for eNB-gNB IPSec link must be NC
FrontHaul & available in the solution. Similar solution to current S1AP
Backhaul & transmisson 19B transmisson method is suitable. Solution must be able to set up eNB-
Sync gNB links without operator input.
FrontHaul & 382. Must support MTU values equal to or greater than FC
Backhaul & transmisson 19B transmisson 9000B.
Sync
FrontHaul & 383. Solution must produces counters, metrics or KPIs that PC
Backhaul & transmisson 19B transmisson count or report all IP packet fragmentation or reassembly
Sync performed by the solution.
384. For tunnelled and/or encrypted traffic, where the inner FC
packet has been produced by the NE, the inner packet
FrontHaul & must be sized so that the outer IP packet conforms to the
Backhaul & transmisson 19B transmisson size of the MTU without fragmentation.
Sync
385. F1 has another MTU value. X2/Xn has another MTU FC

value. OAM/trace has another MTU value.
FrontHaul &
Sync
1. Which Protocol do you propose in case of FC
FrontHaul &
Centralized RAN for Transport between DU
Backhaul & transmisson 19B transmisson and CU (CIPRI, eCIPRI, Ethernet, IP etc…)
Sync and what bandwidth needs to be transported
towards each DU with the selected protocol?
387. Total length of fiber links in km FC
FrontHaul &
Sync
388. State the numbers and types of fronthaul transmission FC
interfaces at the CU and DU.
FrontHaul &
Sync
FrontHaul & 389. State the transport (3gpp) interfaces that exist within FC
Backhaul & transmisson 19B transmisson the fronthaul between DU and CU.
Sync
390. Describe the QoS mechanisms available to manage FC
prioritisation and utilisation of capacity on backhaul
transport interfaces. Provide buffer sizes, queues and
MTU-size.
FrontHaul &
Sync
391. State whether IPSec is supported for fronthaul FC

transport interfaces.
FrontHaul &
Sync
392. State whether IPV6 is supported for fronthaul transport FC

interfaces, both within and outside IPSec tunnels
FrontHaul &
Sync
393. Describe the mechanisms for authentication and FC
encryption key distribution, including protocols supported
for communication with a PKI.
FrontHaul &
Sync
394. Describe the mechanisms for detection of failure at FC

IPSec endpoints, stating whether Dead Peer Detection is
supported.
FrontHaul &
Sync
FrontHaul & 395. Describe any alternative methods supported for FC

Backhaul & transmisson 19B transmisson authentication and encryption of fronthaul transport and
Sync transmission.
FrontHaul & 396. State whether the Central Unit is capable of PC

Backhaul & transmisson 19B transmisson functioning as an IPSec Gateway towards the Distributed
Sync Unit.
397. eCPRI dimensioning rules for FDD-massive MIMO, FC
3.5GHz Massive MIMO and mmWave NRs, how to
calculate the eCPRI bandwidth on down link and upper link
directions, with the assumptions of the variance of # of
users, MU-MIMO, user plane traffic, different MCS setting,
different MIMO codebook setting, different beam weight
FrontHaul & setting.
Backhaul & transmisson 19B transmisson a. For FDD-massive MIMO eCPRI, please give a
Sync calculation example.
b. For 3.5HGz TDD-massive MIMO eCPRI, please give a
calculation example
c. For mmWave eCPRI, please give a calculation example
398. When eCPRI interface bandwidth has limitation, i.e. FC

25Gbps required but only 20Gbps interface been
configured, will the DU scheduler be able to react
accordingly in your solution, i.e. by reducing the max
FrontHaul & number of simultaneous scheduled user to reduce the
Backhaul & transmisson 19B transmisson eCPRI bandwidth consumption down to the available level?
Sync
399. If your DU supports the eCPRI bandwidth auto FC

adaptation, please describe how your scheduler works to
FrontHaul &
address the bandwidth limitation. Please describe the
performance impact (eCPRI bandwidth limited case vs
Sync
eCPRI bandwidth no limitation case.
400. If your DU doesn’t support the adaptation, please FC

FrontHaul & describe what will be the system behavior when eCPRI has
Backhaul & transmisson 19B transmisson congestion, and also please share the roadmap on when it
Sync could be supported.
401. The industry recommends passive DWDM solution FC

deployed for LTE front-haul, with the fiber route distance
less than 20Km from Macro to central office where the
baseband is hosted. What’s you view on 25Gbps/50Gbps
DWDM optics maturity for the front-haul use case?
FrontHaul &
Sync
402. Please describe your mid-haul interface specification; FC

do you support 25GE or 50GE or 100GE? Do you support
LAG (Link Aggregation Group)? If not supported, what is
FrontHaul & your roadmap?
Sync
403. By separating the RRH and the basestation physically, FC
a potential intervention point for attackers is introduced.
Please comment on your view of the security (e.g.
confidentiality, integrity, availability) of this link and eCPRI
protocol
FrontHaul &
Sync
404. Vendor should provide strategy pertaining to 5G Front FC

haul requirements and standards.
FrontHaul &
Sync
405. The CPRI interface is currently the present standard FC

of choice for the connection between the Remote Radio
Head and the Baseband Unit. However, it has limitations
on flexibility and scalability. How do you see this standard
evolving
FrontHaul &
Sync
406. Currently, synchronization is still challenging in FC
packet-based networks and jitter introduced by switches
and queues could become critical for front haul traffic. How
will you address synchronization between transport
devices? Will synchronization be supported directly from
DU to RRU? (Transparently through passive DWDM
infrastructure).
FrontHaul &
Sync
407. Please describe the eCPRI over IP/Ethernet FC

bandwidth dimensioning principles for fronthaul connection
between the radio units and the baseband units. The
FrontHaul & baseband units may be assumed located at a central data
Backhaul & transmisson 19B transmisson center site.
Sync
1. For gNB-CU and gNB-DU, the 25G PC

FrontHaul &
Backhaul & transmisson 19B transmisson Ethernet shall support Forward Error
Sync Correction (FEC) and the operator shall be
able to set (Enable/Disable).
Response Response Attachment Name Remark
Huawei gNB support NG, Xn, X2 use the same IP address or different IP,
and also support user plane, control plane, operation and maintain plane
use the same IP address or individual IP address. This depend on
customer's network scenario.
Control Plane: SCTP, User Plane: GTPU.
see attachment '5G Transmission SOC Q1'
F1 interface transmission protocol stack: user plane: IP/UDP/GTPU,

signaling plane: IP/SCTP;
User planes and signaling planes on the F1 interface can share IP
addresses. Separate IP addresses can also be used. Compared with
DRAN, CLOUDRAN architecture has more CU network elements, so it
needs more IP addresses.
It is not recommended that the base station supports protocols such as
IP/MPLS. The bearer network equipment already has mature IP/MPLS
technology.
In the early stage of 5G, the network infrastructure was mainly focused
on eMBB service requirements. At this time, the backhual network was
mainly concerned with the construction of large bandwidth, and L3 could
be centralized at the core DC or regional DC level. With the growth of 5G
services, especially the rise of URLLC applications like automated
driving, collaborative robots, and remote surgery, the key requirement for
5G mobile backhaul networks is low latency. By enabling L3 routing
capability to edge, the forwarding path becomes shorter and thus
achieving lower latency.
It depends on the customer's network plan. Whether different services

configure different next hop IP addresses, if yes, different services can be
planned to enter different VLANs.
For different slice service, the slice ID which is an E2E ID between gNB
and 5GC could be used to distinguish.
In the early stage of 5G, the network infrastructure was mainly focused
on eMBB service requirements. At this time, the backhual network was
mainly concerned with the construction of large bandwidth, and L3 could
be centralized at the core DC or regional DC level. With the growth of 5G
services, especially the rise of URLLC applications like automated
driving, collaborative robots, and remote surgery, the key requirement for
5G mobile backhaul networks is low latency. By enabling L3 routing
capability to edge, the forwarding path becomes shorter and thus
achieving lower latency.
Slicing can be based on VPN with SR-TE & Channelized sub-interface

etc
F1: the capacities are based on service capacity which configured by DU,
plus overhead between DU-CU.
N2: the bandwidth depends on gNB configuration backhaul network
convergence ratio.
Huawei fully understands customer’s view on future network architecture

about reducing the boxes or nodes. Huawei will look into global market
trends to decide future roadmap.
Huawei supports IPv4 by default. IPv6 is supported and tested in Huawei

lab. We don’t see any commercial IPv6 reference so far. Therefore,
Huawei suggest testing IPv6 solution together with customer before large
scale deployment. Network evolution to 5G is a good opportunity for
carrier to think about the plans to IPv6.
Huawei BBU5900 box slot is of more value to place baseband card

instead of built-in swith function.
Not Support: C- and S-VLANs, G.8032

Support: vLan 802.1p and 802.1q, totally 48 VLANs are supported.
L2 redundancy options: link aggregation 802.3ad
Unknown-unicast traffic limitations and storm controls: support vlan,
802.1p, 802.1q
Broadcast is supported, multicast is not supported.
Unknown-unicast traffic limitations:
VLAN number supported: 1~4094, one VLAN domain setting is less than
100 sites.
maximum frame size supported: 1800 bytes, which is to support GTP
channel + IPSec head, plus some redundancy
Huawei proposed solution support static routing and Ethernet route

backup+BFD, Dynamic routing is supported in splited gNB CU.
Ethernet route backup is typically applied where the base station is
connected to two active/standby gateway routers.
BFD is enabled between the physical port on the base station and its
peer ports on the active/standby gateway routers. Both the base station
and router associate the BFD status with the route status and they trigger
active/standby route switchover on their own sides. BFD authentication is
applied in the same scenario.
All nodes of BTS support QOS mapping for different traffic (DSCP for IP
& VLAN p bit for MAC), DEI bit is not supported.
a) The CPRI bit rates requirement for 100M 64T64R is 100Gbps,

maxinum latency is 100us.
b) The eCPRI bit rates requirement for 100M 64T64R is 25Gbps,
applicable QoS requirements: packet delay<=100us; packet loss
ratio<=10-7.
a) Huawei gNB supports eCPRI and the split point refers to eCPRI
specification(eCPRI_v_1_0_9_2017_07_11) 6.1.1, ID for downlink and IU
for uplink in figure 32. IEEE802.1cm is the requirement for transport, and
now is under discussion. The TSN features are needed to ensure the
delay and QoS requirements.
b) The proposed solution support eCPRI, and Huawei will consider
supporting IEEE1914.1 and 1914.3 after finalized in future.
Proposed UBBPfw1 supports CPRI interface with following rates:

2.457/4.915/6.144/9.830 with SFP and 4x10.1376/4x24.33024 with
QSFP.
Proposed UBBPfw1 and UBBPg3 supports eCPRI interface with following
Rates: 2.457/4.915/6.144/9.830/10.1376/24.33024/10.3125/25.78125.
For Fx interface, the maximum transmission distance between gNB-DU-h

and gNB-DU-l is 20km. Fx interface is real time interface, the time delay
comes from the transmission distance affects the end to end processing
time of HARQ loop, the one-way time delay of 20km transmission
distance is about 100us, Huawei suggests the maximum transmission
time delay is 100us.
Huawei 5G solution from the very first commercial release (5G RAN2.0 in
Q4 2018) will support the Option 7 split between the NR Massive MIMO
AAU(s) and the NR BBP(s) configured in BBU or CBU (Cloud Baseband
Unit).
The F1 interface is non-real time interface, and is not included in
processing of the HARQ loop, the transmission distance between gNB-
CU and gNB-DU is no constraint. However the time delay of F1
transmission distance will affect the user's end to end traffic time delay.
3GPP R15 standard specifies the Option 2 high-layer split for NR based
on centralized PDCP/RRC (CU) and decentralized RLC/MAC/PHY (DU).
Huawei 5G gNB portfolio follow 3GPP R15 specification of CU-DU high-
layer split and will support CU-DU split deployment starting from RAN2.0
(Q2 2019.

The Split 7 eCPRI is recommended for deployment between NR Massive

MIMO AAU and NR Baseband Processing modules, due to the
characteristics of wide channel/carrier bandwidth (typ. 10s~100s MHz)
and large number of TRXs (typ. 64T64R/32T32R).
The Split 8 CPRI is recommended for deployment between NR RRU (typ.
8T8R) and NR Baseband Processing modules.
Huawei 5G RAN solution currently does not support NGFI and xRAN
Fronthaul interfaces.
Huawei can allow IP address for each logical interface can be configed
individually
individually.
Huawei RAN supports star & mesh topologies simultaneously on the

same BTS when Star topology is applied between BTS & central hub
gateway, while Mesh topology is applied between BTS & BTS.
Huawei gNB can use ACL rule to control which transmission link will
enter the IPSec tunnel or not
Huawei RAN BBU support the IPSec for X2 interface.
Huawei gNB supports central IPSec through IPSec and also support
direct IPSec for point to point IPSec. In addition, Huawei gNB can use
ACL rule to control which transmission link will enter the IPSec tunnel or
not.
Currently, Huawei can support IPv4 only. As there are no commercial
network that using IPv6, Huawei will plan to support dual-stack in future.
Huawei RAN supports star & mesh topologies simultaneously on the

same BTS when Star topology is applied between BTS & central hub
gateway, while Mesh topology is applied between BTS & BTS
individually.
Huawei gNB can use ACL rule to control which transmission link will
enter the IPSec tunnel or not.
Huawei gNB supports central IPSec through IPSec and also support
direct IPSec for point to point IPSec
Huawei gNB in NSA architecture supports central IPSec through IPSec

and also support direct IPSec for point to point IPSec. Currently, Xn
interface will involve only in SA architecture. As the standard for SA
architecture is yet to be frozen, Huawei will comply with the standard
once it is finalized.
Currently, 3GPP standard does not define that latency critical signaling to
support on X2-U. Huawei is willing to have a further discussion with
customer.
In NSA architecture, Huawei gNodeB will support SON function based
from LTE eNodeB.
Huawei gNodeB will support D-SON in the next software release.
Currently, Huawei UMPTe board can support up to 2000B. Huawei will

plan to support 9000B with new hardware in 2019Q2
Currently, Huawei gNB supports using MML to check interface statistic

which contains packet fragmentation information and reassemble statistic
information, and not using any counters or KPI.
Huawei gNB can indicates the MTU before a packet is encrypted. When
the size of a packet exceeds the value of this parameter before being
encrypted, the system fragments the packet based on this value and then
encrypts the packet. If the size of an encrypted packet exceeds the MTU
in the ETHPORT MO or IPRT MO, the encrypted packet is segmented for
a second time based on the MTUs in both MOs.
MTU is configure on transmission interface, and it is not related to service

type interfaces like F1, X2, or OAM interfaces. Currently, the configurable
MTU range is 46B to 2000B, and the default configured value is 1500B in
condition that the transmission equipment shall allow the particular MTU
message to pass through completely and not split them out.
The transport of Centralized RAN is between BBU and RRU. It is not

between DU and CU.
Huawei has Midhaul solution to the transport between DU and CU.
Huawei propose 10GE/25GE interface between DU and CU.

Huawei consider the fiber is future-oriented in transport network.
1. DRAN Scenario:
The fiber length beween each gNB and each access router is 99.4KM,
The fiber length between each access routers to aggregation routers is
38.9KM. Total are 138.3KM Fiber in DRAN Scenario.
If deploy MW in the last mile connection between gNB to Access routers.
Total are 38.9 KM fiber for Access routers to Aggregation router in DRAN
scenario.
2. CRAN Scenario:
The fiber length beween each gNB and each BBU Pool is 112.4KM, The
fiber length between each access routers to aggregation routers is 15KM.
Total are 127.4KM Fiber in CRAN scenario..
DU: type of fronthaul transmission interfaces at the DU is eCPRI, in
Huawei proposed solution, 6*SFP ports are supported for per UBBP.
CU: Huawei gNB-CU use CX920 as switch board, which supports
8*1/10GE and 8*40GE ethernet optical interface, the ports on the switch
board panel, used for cascading chassises and connecting to a external
switch.
The transport (3gpp) interface that exist within the fronthaul between DU
and CU is standard F1 interface.
Huawei proposed routers supports abundant QoS mechanisms including

DiffServ Model, BA Classification, MF Classification, Traffic Policing,
Traffic Shaping, Queue Scheduling, Congestion Avoidance, MPLS QoS,
and HQoS.
Huawei proposed routers provide the buffer size as follows:
-ATN950C: 50 ms
-NE40E-X2-M8A: 16ms
-NE40E-X2-M16B: NPU-2T:16ms
-NE40E-X8A: 100ms
Huawei proposed routers provide the queue size as follows:
-ATN950C: 8K total for upstream and downstream
-NE40E-X2-M8A: 128K upstream and 128K downstream
-NE40E-X2-M16B: 128*K upstream and 128*K downstream
-NE40E-X8A: LPUI1T （512K downstream); LPUI480 (Upstream: 384K;
Downstream: 512K); LPUI240 (256K upstream+downstream)
Huawei proposed routers provide the MTU size ranging from 46 to 9600,
in bytes.
Huawei proposed 10G/25G eCPRI interface in fronthaul transport

solution. It is no need to deploy IPSec.
Huawei proposed 10GE/25GE interface in Midhaul solution between DU
and CU. Huawei suggest to deploy firewall product in CU site that
supports IPSec function including manual key, public key infrastructure
(PKI) (X.509), IKEv2, VPN gateway redundancy, EAP authentication, and
IKEv2 redirect.

solution. It is no related to IPV6. Huawei Midhaul solution between CU
and DU support IPV6.The IPV6 protocol includes RIPng, OSPFv3,
BGP4+, and IPv6 IS-IS. Huawei's firewall supports both AH and ESP
IPSec tunnels.Through Authentication Header (AH) and Encapsulating
Security Payload (ESP), the Eudemon8000E protects IP data packets or
upper layer protocols, and supports both the transport mode and tunnel
mode.
solution. It needn't IPSec solution in the eCPRI interface. Huawei Midhaul
solution is supported to deploy IPSec between CU and DU.Huawei
firewall supports CMPv2, OCSP, SCEP protocols.
For the CMPv2:
If the device can access a CA and the CA supports the Certificate
Management Protocol version 2 (CMPv2), the device can apply for and
update the local certificate through CM Pv2.
CMPv2-based local certificate application applies to the following
situations:
•Initial local certificate application using an initialization request (IR)
•Local certificate application for another device using a certification
request (CR)
For the OCSP:
When two PKI entities use certificates to perform IPSec negotiation, they
check the peer certificate status through OCSP in real time.
OCSP does not require the PKI entity frequently download CRL. When a
PKI entity accesses an OCSP server, the entity requests the certificate
status. The OCSP server replies with a valid, expired, or unknown state.
•Valid indicates that the certificate has not been revoked.
•Expired indicates that the certificate has been revoked.
•Unknown indicates that the OCSP server does not know the certificate
status.
For the SCEP:
Two methods are available to apply for the local certificate for a PKI entity
through the Simple Certificate Enrollment Protocol (SCEP):
•Automatic local certificate application and update
•Manual local certificate application
When you use either of the two methods to apply for the local certificate,
the system automatically downloads the local certificate and saves it to
the device storage. However, in manual local certificate application, you
have to install the local certificate to make it take effect. That is, import it
to the device memory.
Huawei firewall supports DPD feature.

In IPSec communication, heartbeat detection technology detects faults at
the remote end and prevents packet loss. However, periodically sending
heartbeat messages consumes CPU resources at both ends and limits
the number of established IPSec sessions.
Dead Peer Detection (DPD) technology sends DPD packets based on
IPSec packets between IKE peers, and does not periodically send
heartbeat packets. When the local end can receive IPSec traffic from the
remote end, the local end considers the remote end as active. The local
end sends DPD packets to detect the status of the remote end when the
local end does not receive IPSec traffic from the remote end within a
given period of time. If the local end does not receive response packets
after sending DPD packets several times, the local end considers the
remote end as unreachable and deletes the IKE SA or IPSec SA between
IKE peers.
The encryption methods are AES, DES, 3DES etc. The authentication
methods are MD5, SHA1, SHA2-256, SHA2-384, and SHA2-512.
Currently, in Huawei 5G solution, gNB-CU does not supports IPsec

functionality, but support external IPsec.
Huawei C-Band and mmWave Macro AAU support 2xSFP28 interfaces

for eCPRI fronthaul. Each port can support 10Gbps or 25Gbps
transceivers, and according to our eCPRI split option, the downlink
bandwidth is decided mainly by user traffic, in the case of fronthaul
bandwith is limited, our system will try to reduce layers or PRB usage to
accommodate the traffic. For uplink, the bandwidth requirement will be
less flexible, the only parameter our system will consider to adapt is
transmission duration, by increasing the duration up to 1.5 times of
OFDM symbol, and both C-Band and mmWave Macro AAU can work
with 20Gbps fronthaul bandwidth.
In Huawei's design, it will consider adaptively controlling the maximum

traffic per cell based on the F/H bandwidth such as reducing the layers or
PRB usage by scheduling controlling, to ensure that the cell peak does
not exceed the F/H bandwidth limit.
Huawei DU supports eCPRI bandwidth auto adaptation to avoid eCPRI

congestion.
Generally, the adoption of 25G and 50G technologies has been driven by
the requirements in the datacenter for connectivity in rack and between
racks. IEEE has two standards driving these forward:
• IEEE P802.3by
• IEEE 802.3cd
For DCI, 10G and coherent 100/200G are the driving technologies.
Huawei does not see a large requirement for long distance 25/50G
DWDM transceivers, although development work is ongoing availability of
these modules with specifications suitable for the RAN will be available
as the requirements become popular trend.
Huawei BBU5900 can support one or two UMPTg cards. Each can
support 25 Gbps so as a total the BBU 5900 can support a total of 50
Gbps aggregated bandwidth
BBU5900 supports LACP protocol and each chassis can support up to 16
link aggregation groups, it supports inter-board and intra-board link
aggregation. Note that the BBU5900 supports only intra-board link
aggregation in load sharing mode.
To guarantee the integrity and confidentiality on eCPRI interface, there
are several options defined in the protocol, like the following descriptions:
Vendors can choose e.g. IPSec or MACSec to ensure the security of
transmission.
1. User Plane
 User plane over IP
IPSec or MACSec are both optional solutions to provide transmission
security.
 User plane over Ethernet
MACSec is an optional solution to provide transmission security.
2. C&M Plane
TLS, IPSec or MACSec are optional solutions to provide transmission
security and access control for eCPRI C&M access control.
3. Synchronization Plane
There is no eCPRI recommendation for security aspects related to the
cynchronization plane.
Huawei will fully comply with the standard, and we have planned TLS on
C&M plane in 2019 software release, while MACSec on User plane is
under planning in 2020 software release.
Huawei experience with global customers is that each have a different set
of requirements and limitations with respect to the deployment of CRAN,
there is no one solution that fits all the requirements for every CRAN
deployment.
Some operators are not comfortable with passive solutions which have
limited OAM, and some potential risk with regards to 5G eCPRI Colored
modules, which are not currently widely available and have no current
eco-system built up to drive down the cost of such modules.
Hence Huawei is developing multiple solutions, one of which is a semi-
passive solution that can merge the best of both world with regards to
passive and active WDM
Huawei actively works with industry partners in developing the eCPRI
protocol, and through that co-operated with the IEEE on developing the
standards for 802.1CM, which define a set of profiles to enable fronthaul
over a bridged network.
CPRI interface based on the split of RF and PHY, which in 5G era will
result in very high CPRI bandwidth (hundreds Gbps per RRU) which will
be difficult to transport. A new functional split was proposed called eCPRI
which reduces the bandwidth and introduces Ethernet technology which
will be more flexible and scalable. Huawei see eCPRI 25G interface will
be the main standard for CRAN Fronthaul.
New eCRPI interface is defined by Ericsson, Huawei, Nokia & widely
supported in the industry.
We believe WDM (include DWDM and CWDM) are a good solution for
limited feeder fiber case. When deploying traditional WDM it should be
optimized for CRAN requirement, such as small size, Full Out door,
latency measurement, easy to installation and maintenance, and low cost
per bit.
The flexibility of the eCPRI design incorporating IP/Ethernet as transport
technologies will enable future networks where Ethernet can be used as
fronthaul. The eCPRI development group worked closely with IEEE,
including ongoing collaboration in defining some of the requirements for
IEEE P802.1 TSN (and sub project 802.1CM) which developed a profile
for Fronthaul over Ethernet bridged networks. In addition IEEE P1914.1
will develop an transport reference architecture for fronthaul traffic over
Ethernet.
Huawei current solutions are active WDM based on OTN and semi-
passive solution.
1. Clock synchronization address by OTN bit stream recover (L1)
technology, not based on packet data (L2) recover, that will avoid
switches and queues impact.
2. DU to RRU will support clock synchronization.
Fronthaul is a simplex traffic and strict latency, synchronization, Bit Error
Rate requirement, so the transport of fronthaul technologies should be
simplex, reliable. We use OTN (L1) technology because of flowing
factors:
1) Low latency and fixed latency jitter.
2) FEC (forward error correction) improve BER performance.
3) Hitless protection improve reliability.
Consider decoupling of wireless and transport devices, and simplified
CPRI interface, we don't implement synchronization function to transport
devices which in the Huawei solution are transparent to the network.
For the eCPRI bandwidth dimensioning, it include 3 parts:

User data: sc number * QAM * layers / transmission duration (OFDM
symbol)
Control info (Beamforming weight): RB number * layers * antenna *
weight bit width / trans. Duration
Control info (user scheduling information + cell common information):
~1Gbps
Assuming 32T/64T active antenna unit with 100MHz carrier and 16-layer
downlink MIMO the 25G eCPRI is required.
Huawei supports the Forward Error Correction (FEC) function by default,

but it cannot be set (Enable/Disable) manually
Back 5 G Use
Ca se .d o cx

860. Please provide information of mobile video
Use Case Mobile Video Mobile Video NA Movile video
FC
861. Please provide information of mobile live
broadcast.
Social Live Movile live

Use Case NA
Networks Broadcasting broadcast
FC
862. Please provide information of Home 4K/8K ultra-
HD TV
Wireless
Home UHD 8K
Use Case NA 8K Video
Entertainmen Video
t
FC
863. Please provide information of Home voice
assistant.
Personal AI Home voice Home voice

Use Case NA
Assistant assistant assistant
FC
Wireless 866. Please provide information of Cloud games.
Home Cloud
Use Case NA Cloud Game
Entertainmen Gaming
t FC
867. Please provide information of VR game.
Cloud Virtual
&
Use Case Cloud VR NA VR game
Augmented
Reality
FC
868. Please provide information of VR video.
Cloud Virtual
&
Use Case Cloud VR NA VR video
Augmented
Reality
FC
869. Please provide information of VR live broadcast.
Cloud Virtual
& VR live
Use Case Cloud VR NA
Augmented broadcast
Reality
FC
870. Please provide information of VR conferences &
SNS.
Cloud Virtual
VR
&
Use Case Cloud VR NA conferences
Augmented
& SNS
Reality
872. Please provide information of VR museum.
Cloud Virtual
&
Use Case Cloud VR NA VR museum
Augmented
Reality
FC
873. Please provide information of VR education
Cloud Virtual
& VR
Augmented education
Reality
FC
874. Please provide information of AR.
Cloud Virtual
&
Use Case Cloud AR NA AR
Augmented
Reality
FC
875. Please provide information of Hologram.
Cloud Virtual
&
Use Case Cloud AR NA Hologram
Augmented
Reality
Tele- 876. Please provide information of Tele-operated

Connected
Use Case ToD NA operated Driving (ToD).
Automotive FC
Driving
Connected Truck 877. Please provide information of Truck platooning.
Use Case Platooning NA
Automotive platooning
Connected Autonomous 878. Please provide information of V2X assistance
Use Case NA V2X driving (C-V2X).
Automotive Driving FC
881. Please provide information of USE CASE -
DRONE Security monitoring.
Professional
Connected
Use Case Inspection & NA DRONE
Drones
Security
FC
882. Please provide information of USE CASE -
DRONE rescue.
Professional
Connected
Drones
Security
FC
Professional 885. Please provide information of USE CASE -
Connected DRONE inspection.
Drones
Security FC
Remote 886. Please provide information of Ambulance
Ambulance communication.
Wireless Diagnosis
Use Case NA communicati
eHealth With Force-
on
Feedback FC
888. Please provide information of Remote surgery.
Remote
Wireless Diagnosis Remote
Use Case NA
eHealth With Force- surgery
Feedback
FC
889. Please provide information of Industry robotics.
Cloud Based
Smart
Wireless Industry
Use Case Manufacturin NA
Robot robotics
g
Control
FC
894. Please provide information of VR/AR for factories.
Cloud Virtual
& VR/AR for
Augmented factory
Reality
FC
AI-enabled 898. Please provide information of Smart city
Use Case Smart City Video NA Smart City
Surveillance FC
Response
Name
Mobile video services are accounting for the most of traffic in current network.
There will be more new mobile video services in 5G. Such as the audience can
watch sports and conerts from different views, even from athletes' views. A
large number of passengers watch high-definition videos in the bus or subways
at the same time.
Huawei MI forecast that the whole video industry market will reach 1 trillion
USD by 2021. Among them, the entertainment video is expected of 650 billion
dollars, communication video is expected to be 18 billion dollars, and industry
video is estimated at 350 billion dollars. Mobile video has become the basic
services for carriers, and mobile video is now taking more than 50% of the
mobile data traffic in advanced markets
Cases:
Multi-view streaming:
In F1 racing 2016 Shanghai, China Mobile realized the first live multi-view
streaming service in the circle - which gives its 4G users an unprecedented new
experience. As before, the audience will watch the racing from a single point.
After the multi-angle of view streaming service launched, the audience can
watch live sports from multiple cameras, and switch independently between
them.
Athletes' view video streaming:
At the training day of International Bobsleigh & Skeleton Federation (IBSF)
which was taken in March 2017, South Korea operator KT tested wireless
network based player view video service. By using ultra-compact camera, a
location sensors and 4G module to transmit the ultra-high-quality real-time 4K
video streaming from player’s view. Audience watched the live matches from
the perspective of players. In view of the sleigh driving speed is 120-150 km/h
and multiple-angle-view, in 2018 Winter Olympics LTE will be replaced by 5G
module.
Mobile live broadcast includes personal broadcast and enterprise broadcast.

Which contains interaction between the audience and hosts. The live
broadcasting are widely applied.
According to China Mobile and Huawei jointly white paper - mobile live video
report, by 2020 global mobile live video users will reach 926 million. The market
scale is about 15.5 billion dollars. The Report pointed out that more and more
live contents are generated on the mobile network. And each Giga Byte of
upload video content generation will bring more than 120GB download data
traffic consumption.
Cases:
Facebook may be late to launch live service but it is catching up, in particular
with high-profile events. For example 14 million people live watched a 20-year
old man climbing Trump Tower in New York City on August 10th 2016, and
close to 4 million people watched Michael Phelps’ live broadcast before his final
team race at Rio Olympics.
4G network supports 1080p live TV and VOD services anytime and anywhere.
5G network supports multi-view video, athletes' view video and more than 4K
UHD live video services.
By August 2016, there were nearly 10 million 4K/UHD TV service users
worldwide. The rapid sales of 4K/UHD TVs promoted the development of
4K/UHD TV service. The delivery ratio of 4K/UHD TVs is more than 40%
globally. According to the forecast of OVUM, the decreased price and new
subscription-based UHD TV services will attract half of the TV-owning families
worldwide to use 4K/UHD TVs by 2020.
WTTx provides fiber-like high-speed wireless broadband access serviceand
premise ultra-HD TV experience at home. WTTx can greatly shorten the period
of network constructionreduce the cost on network construction and increase
operator revenue.it helps operator to enable the wireless broadband new
business opportunities and realize fast ROI.
Cases:
The world's first 8K live broadcast was used during the 2016 Rio Olympic
Games. On August 1, NHK, Japan's public broadcaster, began testing 8K TV
broadcasting and broadcasted the opening and closing ceremonies, swimming
events, and track and field events of the 2016 Rio Olympic Games. Additionally,
NHK plans to broadcast 8K programs over the BS satellite channel in 2018 and
intends to popularize 8K programs during the 2020 Tokyo Olympic Games.
South Korea also plans to broadcast the 2018 PyeongChang Winter Olympics
in 8K.
Network:
Image quality Bandwidth requirement (5G eMBB)
4K TV (30fps, 8bit) DL: 30Mbps
4K TV (50/60fps, 10bit) DL: 50Mbps
8K TV (50/60fps, 10bit) DL: 120Mbps
One of the key feature of video services is bandwidth. Bandwidth determines
the initial buffering delay and stalling. In addition, the network architecture such
as CDN deploy close the users is also an aspect of performance optimization.
For playing music, control home electronics, setting the clock, play news, and
online shopping.
Log in to Echo, represented by Amazon Alexa voice platform in the year 2015,
the shipment reaches 2.5 million. 2016 sharply increases to 5.2 million console
(data source: CIRP). And Apple HomePod will be delivered to the customers
soon in this year.
Cases:
Experianand Creative Strategies research in 2016 reports, that have 50.9%
user to use the Echo in the kitchen, 33.5% of user in the living room. According
to a survey, about 45% of respondents uses smart speakers to play music, and
reading books.
Voice assistant of voice recognition needs to interact with the cloud intelligence,
but only transmit audio track. However, for execution command to the sound
that consumes a certain bandwidth, for example, news, videos etc. (new
Amazon Show supports video).
See attachement
Multi-player interactive VR game has becomes the trend, which depends on the
interaction of multiple users and room-scale motion tracking. Networked and
team play with friends in the same immersive virtual place.
Internet Data Center predicts that global VR/AR product and service market will
reach to $215 billion by 2021. Currently, 81.9% VR games are palying locally,
and connected VR games are less than 20%. Multi-player VR Interaction
upgrade will further promote the sales of hardware products, so as to drive the
entire game ecology enters the virtuous cycle.
Cases:
Fusion Wars is a fast paced Tron inspired Vehicle combat VR game. What
makes this game unique is that it supports up to 16 players going head to head.
You can also join teams; that is where the magic is in Fusion wars. Teammates
can fuse the vehicles together to form a bigger vehicle with different abilitys.
VR VOD: VR videos is 360-degree panoramic video, can be obtained from the
camera angle of 360 degree angle, but only limited to the pre-recorded videos
with 3 DOF (Degree of Freedom) experience. In the future, VR resolution at 60
pixel per degree and 6 DOF will be a necessary for the next generation VR
experience.
VR VOD and VR live event is the main 360° VR use case. Gartner forecasted
that VR market size would reach 40 billion USD by 2020. Based on Goldman
Sachs 2016 VR/AR industry report, VR live event and VR video entertainment
market will reache to 52 million user by 2020.
Cases:
At present, 360° VR video has begun to take shape:
Youtube launched 360 video service and uploaded VR 360 video to more than
8,000.
Samsung Gear and Oculus CV1 has provided more than 1000 video souces.
Vrideo is focus on 360 video content platform and provides high-quality 360
video online content. Its 4K 360 video reaches to 400+, accounting for 70% of
the total.
VR 360 video consumption is also growing rapidly. VR video user base and
traffic is also quite impressive, especially the popular video.Youtube TOP N
popular 360 video daily click up to 20.5 million, Samsung Gear also has 100
million active users.
VR technology has changed the traditional broadcast, to the greatest extent to

restore the scene, bringing people feel immersive. VR live broadcast is very
promising.
Personal live broadcast: sharing views with friends when travelling let friends
have the same feeling with you.
Concerts and sports events: not ony give audiences an immersive live
experience, but also break the seat restrictions even you need not buy a ticket.
VR education, VR broadcasts allow learners more truly experience atmosphere
in the classroom. Learners can better integrate into the classroom atmosphere.
According to Goldman Sachs 2016 VR/AR industry report. VR live event and
VR video entertainment will have 52 million user by 2020, and VR 360 video
user will reach to 17.4 million.
Cases:
In October 2015, CNN cooperated with NextVR to VR live broadcast the
Democratic TV debate for the first time. The Olympic Games, NBA, and
European Cup have tried VR live services.
In November 2016, AltspaceVR broadcasted the US general election vote using
VR technology.
In December 2016, Facebook launched Live 360 services to allow users
sharing their story and experience.
VR social connect people in real world to virtual world, which allows multiple
person to present in the same virtual environments even they are not in the
same place (for example, theater, fitness center, in the virtual conference room
together and go to the movies, do yoga, or meetings). In addition to the content
common experience, we can more intuitively feel each other's existence; this is
the biggest advantage of VR social.
Gartner forecast VR market size would reach 40 billion USD by 2020; Social
need is the basic need for everyone. SNS (Social Network Services) is the core
of the Internet era, and VR social is definitely become the core of VR era. As a
global social networking giant, Facebook has already develop a kingdom of
Internet and mobile Internet-based network. As a global social networking giant,
Facebook is creating an Internet-based and mobile Internet networks kingdom.
Zuckerberg belived that "virtual reality is the next mobile computing platform".
VR socal will be one of the biggest use case to change people’s life.
Cases:
Altspace and Facebook Space integrate meetings, games, gatherings into VR.
Rec Room and VTime support simple VR social application, such as chat rooms
UGC such as VR Chat and High Fidelity allowsusers to create their own content
and share experiences.
VTime allows friends to chat or share images in a variety of virtual
environments; it can be used for meetings, business meetings and more.
This one is making a virtual world museum through 3D modeling technology;

the other is the combine augumented reality to real museum to carry out visual
reconstraction.
According to the Association of American Museum of Art reports, American
museums’ 32% of spend is used on the staging various activities. But the
infrastructure maintenance only 19% of expenditure. The use of VR / AR
technology can avoid the loss of these collectibles and save maintenance costs.
According to statista statistics, the United States Museum and the historical
heritage industry in 2015 created a $ 13 billion revenue, estimated at 2018 can
reach 15 billion US dollars.
Cases:
At the end of 2015, Google Cultural Institute (GCI) project has teamed up with
the world's largest museum – The Great British Museum plans to build a virtual
reality Museum. GCI plans to cover the museum with 9 layer space and 85
permanent exhibition halls. This means that people around the world need only
move the head will be able to see the rich collections inside.
According to Goldman Sachs, VR/AR technology has the potential to be a
standard tool in education and could revolutionize the way in which students are
taught for both the K-12 segment and higher education (college and beyond).
Teachers can use VR/AR as a way for students to interact with objects in a 3D
environment. For example, students can learn about the solar system or a
historical event by interacting with those virtual worlds. Google is pushing
forward in this market by offering Cardboard to schools for free and has already
developed over 100 “virtual field trips.” We’re also seeing traction of virtual
reality at the higher end of the market with medical schools experimenting with
AR.
Gartner sizes the global education software market at ~$12bn for 2015,
consisting of the K-12 education software market at $5.2bn and the higher
education (college and beyond) software market at $6.6bn. Goldman Sachs
assumes $300mn in educational software revenue in 2020 and $700mn in
2025.
Cases:
In June 2016, Google for Education announced that it will integrate Google
Expeditions and Google Classroom with TES, a service that has tens of millions
of teachers' users, and can be used to find digital data and curriculum plans for
the classroom.
Network:
VR/AR is divided into 5 stages from the network point of view, which is:
• Stage0: PC VR, refers to professional-grade VR such as HTC VIVE, etc. it
need a local high-end PC to do the local rendering but with no demands on
mobile network;
• Stage1: Mobile VR is best exemplified by Google Cardboard and Daydream
and Samsung’s Gear VR. Pricing for these devices are low with most solutions
priced at $100 or less – these devices are also used in promotional events. The
requirements for the network are the bandwidth required to download the video;
• Stage2: cloud Assisted VR, cloud-based motion processing and delivery of
images with an appropriate field of view (FOV) based on the motion. It requires
low lantency for network;
• Stage3/4: cloud redering VR, introduces cloud-based realtime rendering of
Computer Graphics (CG) virtual images. It has a high demand for network
latency and bandwidth.
As the Augumented reality (AR) has a stronger tool attribute, it will have a wider
application in the consumer and enterprise market.
In Consumer market, AR+LBS games such as Pokémon GO ignite AR market
last year. AR make the game and the real world have a strong interaction, a
great increase in the fun of the game and bring into the sense. Shopping mall
can use the AR for Shopping malls can use AR for three-dimensional
marketing. In tourism, AR can be combined with the geographic information of
LBS to achieve the integration of online and offline information. AR HUD can
help navigation and safety by reminding pedestrian and obstacle in front of the
road ahead. In the future, even it can be extended to social and other fields.
In Enterprise market, such as military, security protection, and Industrial
maintenance field, AR can be used for remote expert advice. AR smart glasses
help the first perspective of the surgery or auxiliary medical teaching. In
education, AR makes the two-dimensional image three-dimensional,
superimposing with more information, to effectively solve the problem of
knowledge transfer.
The applications like Pokémon Go is accelerating AR popularization. Smart
phones and AR glasses will become extension to human sensory systems.
Real-time interactive AR, image cloud processing, network bandwidth, and
delay are the challenges to the network.
Investment banks Digi-Capital’s report pointed out that global augmented reality
(AR) and Virtual Reality (VR) market size will reach 150 billion dollars by 2020.
The AR market size will be 120 billion USD, higher than 30 billion USD of VR
market size. AR application and service will generate more profit than VR.
Cases:
January 22 2015, Microsoft released HoloLens holographic display helmets. It
contains various AR game experience. Skype is a video call software for AR
equipment; it cannot only show the video, but also to show the holographic
annotation, so that remote learning becomes more vivid. SketchUp AR can be
used in lots of industrial areas, such as construction architectural, engineering,
construction and operation by providing real 3D models.
Network:
Phase 1: local rendering AR games: (resource file loaded) 10Mbps, RTT 50ms,
4G network can meet the requirements.
Phase 2: cloud rendering AR games: (transmission rendering FOV stream)
100Mbps, RTT 10ms, only 5G network meet the requirements.
Holographic calls are common in science fiction movies, such as "Ace agents",
"Star Wars", "Iron Man". Holographic technology allows people to truly show in
front of you, although far apart. Holography is 3D-based AR.
Holographic technology has many potential uses, regardless of consumer-
oriented or enterprise users. Forrester Research thinks, holographic technology
will significantly impact on people's daily life. Holographic computing will expand
human-to-machine interactive way.
In addition to the holographic communications, gaming, holographic technology
will make a difference in the field of virtual shopping, travel, education, etc., it
will bring more than virtual reality better experience for the user.
Cases:
In March 2016, Microsoft first demonstrated Holoportation technology. It uses
3D capture technology to build the user's high-quality 3D model, and transmits
the user's image, voice and other information. It allows people to watch the
video on HoloLens or HTC Vive hologram, or make real-time face-to-face
communication. In November 2016, Microsoft released Holoportation
technology for automotive scenarios.
In October 2016, American development team Valorem R&D holographic
demonstrate chat application HoloBeam, but only disclosed the technical
preview. HoloBeam use stereo cameras to capture the character's holographic
display. When put on HoloLens, open the software, HoloBeam can bring the
holographic image in your eye.
February 2017, KT, the official telecom operator for the upcoming 2018
PyeongChang Winter Olympics, demonstrated hologram and 360-degree virtual
reality video services that would be running on its fifth-generation network
technology.
April 2017, Korea-based KT and US-based Verizon has succeeded in testing
the world’s first live hologram international call based on their 5G networks.
Network:
• Phase 1: 1080p, downlink/uplink: 194Mbps, RTT 20ms,
• Pahse 2: 4K, downlink/uplink: 1.16Gbps, RTT 20ms.
See attachement
See attachement
See attachement
Drones can carry the visible light camera and infrared thermal Imager. Visible
light camera can zoom up to 30 times, collect 50 million pixels, so that the
drones can capture and recognize human face 300 meters away while the
suspect is not aware of that.
The thermal imager detects infrared rays emitted by the object. So it can detect
objects in low visibility and dangerous locations.
The two technologies can be used in the areas of public security, night-vision
tracking, search and rescue, equipment patrol, agriculture, forestry, animal
husbandry and disaster prevention. Drones can also carry poisonous gas
detectors to detect various types of toxic gases.
Cases:
DJI announces the launch of the night vision UAV with the global thermal
imaging leader, Philip Co. (IR) of the United States. Chinese startups have also
started to explore drones with thermal imager.
Drones in the rescue can:
1) Arrive at the scene at the first time, quickly transmits the video and audio of
the scene to the command center, the image accuracy can reach 0.1 meters.
2) Carry infrared night-vision goggles, see things in the evening, and look
through the smoke to check the source of fire.
3) Design paths for fire fighters;
4) Delivered life preserver, life jackets, medical supplies, tools, batteries and
other emergency supplies.
5) Be equipped with life detectors to detect signs of life.
Cases:
The fire brigade of Guangdong Province of China set up a drone unit, providing
the fire officers with video and thermal imaging information. This information is
used to determine if a fire fighter is safe to enter a certain area.
See attachement
See attachement
See attachement
Industrial robots are automated, programmable and capable of movement on

two or more axes. Typical applications of robots include welding, painting,
assembly, pick and place for printed circuit boards, packaging and labeling,
palletizing, product inspection, and testing. Artificial intelligence is becoming an
increasingly important factor in the modern industrial robot.
According to the International Federation of Robotics (IFR) latest statistics, the
2016 global sales volume of industrial robot is 290,000 units, with a growth rate
of 14%. It is estimated that the growth rate of 2017 is about 13%. China, Japan,
South Korea, the United States, Germany dominates the global industrial robot
74% share, and China has become the world's largest market for five
consecutive years. Currently, the robot arm and robot controller connected by
fieldbus and Ethernet, wireless only accounts 4%, including Bluetooth, zigbee,
WLAN, cellular wireless technologies, an increase of 30% year.
Cases:
Huawei have deployed smart factory solution based on wireless cellular
technology in its own factory--Dongguan Songshan Lake Factory. The services
include video surveillance, AGV control, robot status data backhaul, and power
consumption data collection, device monitoring, asset counting, worker and key
asset location. The device energy consumption monitoring and asset counting
eLTE-IoT narrowband IoT solution. Other services use LTE-U technology. After
the solution is deployed, the production efficiency is improved by 30%,
operation cost is reduced by 20%, and cut energy consumption by 10%.
Recently, Huawei together with KUKA in a car factory are deploying LTE-U
based Smart Factory solution. It’s used for reporting robot state information. In
the future, the Cooperation Project will be enhanced network connectivity and
enable more wireless services, such as mobile robot, AGV, Edge Gateway, so
as to verify more based on LTE and 5G use case, optimize the existing
production line, improve the production efficiency, and shorten product release
cycle 10%.
Network:
Bandwidth: The uplink data rate: 20Mbps, downlink data rate: 20Mbps.
Latency: cloud-based robot 1~5ms.
Industrial wearable equipment, through the workers can quickly understand the
production situation, energy consumption and waste rate, timely adjustment of
production strategy. When there are abnormal equipment, abnormal time,
managers can grasp the situation the first time, deployment staff emergency
maintenance, shorten the downtime. At present the main application is industrial
AR.
Industrial AR is mainly used for remote expert guidance, auxiliary teaching and
training, on-site inspection, industrial assembly and maintenance. Industrial AR
as productivity tool has been greatly improve production and learning efficiency
and safety factor or even breaking through capability limits. The benefits are far
higher than costs.
Cases:
Case 1: In order to improve the plant staff on-site operation environment and
Fujitsu have AR technology is applied to its equipment checkpoint with 24 x 7-
service operation. Worker can easily determine whether devices are running
properly, and analyzing data of device preventive maintenance can be
implemented.
Case 2: In 2013, Beckhoff shows how to use the Google glasses to implement
machine operations. Google Glass integrates a head mounted display and a
digital camera to display. It can be used for industrial environment as a
supplement of production process operation.
Case 3: World famous lift vendor Thyssen Krupp together with Microsoft, for its
24,000 skilled workers with Hololens glasses. So that the workers can obtain
more timely and more convenient technical support when they do the elevator
installation or repair.
Network:
Phase1 2D AR, use 4G or WiFi technology. Bandwidth: 20Mbps; Latency:
50ms;
Phase2 3D AR, uses 4.5G technology. Bandwidth: 40Mbps; Latency: 20ms;
Phase3 Could AR/VR, uses 5G technology. Bandwidth: >100Mbps; Latency:
2~10ms
See attachement
Back
Will your solution support a feature that allows

sharing radio resources between 4G and 5G in a
dynamic way in a Non-Standalone configuration
(4G-signalling used)? A 5G enabled terminal should
indicate 5G NR coverage and a 4G legacy terminal
should see the 4G-indicator. Describe the feature in
detail.
sharing
Multi-mode
SRAN SUL 19B radio FC
Feature
resources
In which steps will you introduce SUL? Discuss the

limitations of the steps.
Multi-mode
SRAN SUL 19B SUL FC
Feature
Response
Name
LTE FDD and NR Uplink Spectrum Sharing will allow NR to
share spectrum resources with LTE. This feature will allow for
the sharing of UL low-band spectrum resources between LTE
and NR. The low-band spectrum sharing serves as a basis for
NR UL and DL decoupling and improves NR UL coverage.
This feature plans to be applicable to LTE FDD 700 MHz (10
MHz cells), 800 MHz (10 MHz cells), and 1800 MHz (10 MHz,
15 MHz, and 20 MHz cells) frequency bands.
LTE and NR spectrum sharing in uplink works in uplink, and
has no impact to downlink. It means LTE and NR coverage
has no change as before. Indicator of 5G and 4G is based on
BCCH channel in downlink. So a 5G enabled terminal will
indicate 5G NR coverage and a 4G legacy terminal will see
the 4G-indicator.
It will be configure LTE and 5N NR UL simultaneously 19Q2

from Huawei SRAN15.1. It will require the bandwidth of UL to
be 15M or 20M at 1800MHz/2.1MHz, 700/800MHz at 10MHz,
and the band should be contiguous allocated. UL/DL
decoupling will be completely defined in 3GPP R15.

5G Internal SOC Baseline - 201801031

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

5G Internal SOC Baseline - 201801031

Uploaded by

Copyright:

Available Formats

5月前基线库SOC数量 740

FrontHaul & Backhaul &

SRAN CU-DU Split

子领域（中文） 子领域（英文） 市场技术接口

R15协议顺从性 R15 Standard Compliance 黎旭

5G站点解决方案 5G Site Solution

BBU规格、CU规格 BBU & CU Specification

L2/L3 规格 L2/L3 Specification

编码(Polar code,LDPC) Channel Coding

DC&CA（5G Only）（区分高低频） DC&CA (5G Only)

Network Slicing RAN Slicing 产品管理

Counter与KPI Counter & KPI

Cell non-performance related

IoT对接 IoT 产品管理和一线

测试类问题 Test Domain 区域/项目TSE

CPE Speed CPE Speed 涂宇

TUE Speed TUE Speed

RAN System 覆盖仿真 RAN System Coverage

子领域（中文） 子领域（英文） 答标接口

多模硬件（包括存量模块） Multi-RAT Module Specification SRAN MO

虚拟化&解决方案 Visualization & Split Solution SRAN MO

NSA & Multi-RAT DC NSA & Multi-RAT DC SRAN MO

EMF EMF 各产品管理分部

具体参考《DBS5900 5G V100R002C00 Product

具体参考《19A FD》和《19B FPD》

具体参考《19A FD》和《18A FPD》

《功耗计算工具（BaseStation Power Consumption

Massive MIMO SRAN MO：贾永来

X-lab 领域MO ：余珞

Non-5G RAN Content

Visualization & Split Solution

NSA & Multi-RAT DC

Please present your 5G roadmap

How will you implement support of

Do you have the system

3GPP have recently defined the

Describe how the RAN functions

The separated DU and CU structure is being planned after

Although CU part CP-UP split provide more flexibility for

In summary, Huawei does not suggest to deploy CP-UP

3GPP R15 recently has frozen the slicing framework. R16

Huawei's planning of RAN slicing is based on SDAP

Huawei Response: Compliant

r standardization of 5G NR and New Core,

specifications. In addition, Huawei strictly

es of 3GPP 5G standard are proposed by

izations such as chairman, vice chairman,

2, RAN3, RAN4, SA1, SA2, SA3, SA5,

pporteurs), including study on self-

hieves 4 rapporteurships including study

Back Please refer to the version Go-to-Launch Materials

Product New New Sub- Version

Provide 3GPP Standards

02/06/2024 华为保密信息,未经授权禁止扩散 第27页，共609页

02/06/2024 华为保密信息,未经授权禁止扩散 第28页，共609页

The cooling method of gNB system.

The BBU shall be designed in a module unit considering

The input power shall satisfy the following electrical FC

earthquake The Richter criteria shall be between 7.5 and 8.0 FC

b) SFP28: Supports power consumption over 3.0W FC

c) Temperature characteristics: Satisfies temperature criteria FC

While supporting and operating Cascade, and in case of PC

The 5G system should have no change of power system

子领域（中文）子领域（英文）市场技术接口

子领域（中文）子领域（英文）答标接口

02/06/2024 华为保密信息,未经授权禁止扩散第27页，共609页

02/06/2024 华为保密信息,未经授权禁止扩散第28页，共609页