3gpp ran2 #98 國際標準會議報告
TRANSCRIPT
1
會議報告（會議類別：其他）
出席第三代合作夥伴計畫無線存取網路 -
3GPP RAN2 #98國際標準會議報告
出國單位：財團法人工業技術研究院
出席人員：陳宏鎮、邱俊淵、林奕廷、楊豐銘
派赴地區：中國大陸/杭州
會議期間：106年 5月 15日至 106 年 5月 19日
報告日期：106年 6月 29日
2
摘 要
本次 3GPP RAN2#98會議於中國大陸的杭州舉行，本計畫團隊依規劃有 4
位成員出席，參與 3GPP R15 的標準制定，其中以 NR 的工作項目為主，本計
畫團隊著重在 CP 與 UP 之各個議題；在會議期間表達我方之意見與立場，同
時彙整各項研究議題之發展與技術現況，並蒐集各家廠商對於不同議題之立場
與看法。
由於 NR 初期優先考慮 non-standalone，NR 與 LTE 會以雙連結方式互動，
所以在 CP 方面，本次會議對於主節點與次節點間的各種信令流程以及
Measurement Coordination 等進行深入的討論，此外由於引入 SCG SRB，對其
運作的方式也進行了討論。另一個會議的重點則是聚焦在 RRM Measurement
的部分，其中包括了決定 NR量測模型、計算 Cell Quality的方法等。
由於需要討論的議題涵蓋範圍很廣，本次會議於第三天開始將 CP 與 UP
相關議題分開討論，以兩個平行議程同時進行，在 UP 方面，本次會議討論了
MAC 層、RLC 層、PDCP 層和 SDAP 層內的 PDU 格式。此外也對這些 L2 子
層內的各種功能細節如 UL PDCP Duplication、上行資料分流、UM和 QoS Flow
ID標示等進行深入的討論。
縮寫與中英文對照表 (依報告內容摘錄及依英文字母排序)
英文全稱 英文縮寫 中文全稱
3rd Generation Partnership Project 3GPP 第三代合作夥伴計畫
Absolute Threshold 絕對門檻值
Access and Mobility Management Function AMF 接取與行動管理功能
Access Stratum AS 存取層
Acknowledged mode AM 確認模式
Additional indication
額外指示
Automatic Repeat reQuest ARQ 自動重傳請求
Averaging window
平均視窗大小
Beam
波束
beamforming
波束成型
Buffer Status Report BSR 緩衝區狀態回報
3
Carrier Aggregation CA 載波聚合
Cell Quality 細胞品質
Channel State Information Reference Signals CSI-RS 通道狀態資訊參考訊號
Conditional Handover
有條件的換手
CONNECTED Mode
連線模式
Consolidation
合併
Control Element CE 控制元件
Control Plane CP 控制平面
Criteria
準則
Data Radio Bearer DRB 數據連線載體
Data Radio Bearer Identification DRB ID 數據連線載體識別碼
Dedicated Control Channel DCCH 專用控制通道
Duplicate Detection
重複檢測
E-UTRA-NR Dual Connectivity with the 5GC NGEN-DC
連接第五代核心網路之演進的
通用陸面無線接入與新世代無
線技術雙連結
E-UTRA-NR Dual Connectivity with the EPC EN-DC
連接演進分封核心網之演進的
通用陸面無線接入與新世代無
線技術雙連結
Evolved Node B eNB 基地台
filter
濾波器
First Missing COUNT FMC 第一個遺失計數
First Missing Sequence FMS 第一個遺失序號
Guaranteed Bit Rate GBR 保證位元率
hard-split
硬分割
Header
標頭
Hybrid Automatic Repeat reQuest HARQ 混合型自動重傳請求
Identity ID 識別
IDLE mode
閒置模式
IDLE Reference Signal IDLE RS 閒置狀態參考訊號
INACTIVE mode
非活躍模式
In-sequence Delivery
依序傳遞
inter-cell
跨細胞
IP Flow
網際網路通訊協定流
L1 Filter
第一層濾波器
L3 Filter
第三層濾波器
4
layer 1 L1 第一層
layer 2 L2 第二層
layer 3 L3 第三層
Liaison Statement LS 聯絡說明
logical channel group LCG 邏輯通道群組
Logical Channel Group Identity LCG ID 邏輯通道群組識別
Logical Channel ID LCID 邏輯通道識別
Logical Channel Prioritization LCP 邏輯通道優先權
Long Term Evolution LTE 長程演進技術
LTE Positioning Protocol LPP 長期演進技術定位協議
LTE-NR Dual Connectivity EN-DC 長程演進技術與新無線電技術
雙連結
MAC Control Element MAC CE 媒體控制存取控制元件
Master Cell Group MCG 主細胞群
Master Cell Group Data Radio Bearer MCG DRB 主要細胞群組之數據連線載體
Master Cell Group Signalling Radio Bearer MCG SRB 主細胞群訊號無線載體
Master Cell Group Signalling Radio Bearer MCG Split
SRB 主細胞群分流訊號無線載體
Master eNB MeNB 主基地台
Maximum Bit Rate MBR 最大位元率
Measurement Coordination
量測協調
Measurement Object MO 量測物件
Measurement Report
量測回報
Measurement snapshot
量測時間點
Medium Access Control MAC 媒體存取控制層
Message 1 Msg1 第一訊息
Message 3 Msg3 第三訊息
Message 5 Msg5 第五訊息
Minimum System Information minimum SI 最小系統資訊
Mobility Management Entity MME 行動管理單元
Multiple beams
多波束
Multi-RAT Dual Connectivity MR-DC 多無線電存取技術之雙連結
Narrow Band Internet of Things NB-IoT 窄頻段物聯網
Network Slice Selection Assistance Information NSSAI 網路切片選擇輔助資訊
New Generation NB gNB 新世代基地台
New Radio Technology NR 新無線電技術
5
New Radio Technology Secondary
Synchronization Signal NR-SSS 新無線電技術次要同步訊號
Non-Access Stratum NAS 非接取存取層
Non-Standalone
非獨立運作
NR Dedicated Control Channel NR-DCCH 新世代無線技術專用控制通道
On-demand System Information On-demand SI 隨選系統資訊
Other System Information Other SI 其他系統資訊
Packet Data Convergence Protocol PDCP 分封數據匯聚協定
Packet Duplication
封包複製
Padding
填充
Paging
呼叫
Paging signalling
呼叫訊息
PDCP Control PDU
分封數據匯聚協定控制協定數
據單元
Physical Random Access Channel PRACH 實體隨機存取通道
Preamble
前置符元
Primary Secondard Cell PSCell 主要次細胞
Protocol Data Unit PDU 協定數據單元
Quality of Service QoS 服務品質
Quality of Service flow ID QoS flow ID 服務品質流識別碼
Radio Access Network RAN 無線存取網路
Radio Access Network working group #1 RAN1 無線存取網路第 1工作組
Radio Access Network working group #2 RAN2 無線存取網路第 2工作組
Radio Link Control RLC 無線鏈路控制
Radio Link Control Transparent mode RLC TM 無線鏈路控制層透明模式
Radio Link Control Unacknowledged mode RLC UM 無線鏈路控制層非確認模式
Radio Link Control Acknowledged mode RLC AM 無線鏈路控制層確認模式
Radio Link Failure RLF 無線鏈路故障
Radio Resource Control RRC 無線電資源控制
Radio Resource Management RRM 無線電資源管理
Radio Resource Management Measurement RRM
Measurement 無線資源電管理量測
Reconfigured
重配置
Reference Signal Received Power RSRP 參考信號接收功率
Reference Signal Received Quality RSRQ 參考信號接收品質
Reflective Quality of Service Reflective QoS 反射性服務品質
Relative Threshold
相對門檻值
6
Release 13 R13 第 13版
Release 14 R14 第 14版
Release 15 R15 第 15版
SAE-Temporary Mobile Subscriber Identity S-TMSI 臨時行動使用者識別碼系統架
構演進之暫時移動用戶識別碼
Scheduling Information
排程資訊
Scheduling Request SR 排程情求
Secondary Cell Group SCG 次細胞群
Secondary Cell Group Data Radio Bearer SCG DRB 次要細胞群組之數據連線載體
Secondary Cell Group Signaling Radio Bearer SCG SRB 次細胞群訊號無線載體
Secondary Cell Group Signaling Radio Bearer
reconfiguration
SCG SRB
reconfiguration 次細胞群訊號無線載體重配置
Secondary Cell Group Split Signaling Radio
Bearer
SCG Split
SRB 次細胞群分流訊號無線載體
Secondary eNB SeNB 次基地台
Secondary gNB SgNB 次新世代基地台
Security key
安全金鑰
Segmentation
分段
Sequence Number
序列號
Service and System Aspect working group #2 SA2 服務及系統面第 2工作組
Service and System Aspect working group #3 SA3 服務及系統面第 3工作組
Service Data Adaptation Protocol SDAP 服務數據適配協定
Service Data Unit SDU 服務數據單元
Serving cell
服務細胞
Signaling Radio Bearer SRB 訊號無線載體
Single-Cell Point-to-Multipoint SCPTM 單細胞之點對多點傳輸
slicing
切片處理
Sub-header
次標頭
Synchronization Signal SS 同步訊號
Synchronization Signal block SS block 同步訊號區塊
System Information SI 系統資訊
Threshold
條件
Threshold based splitting
臨界型分割
Timer
計時器
Tracking Area Update TAU 追蹤區域更新追蹤區更新
UL PDCP Duplication
上行分封數據匯聚協定封包複
製
7
Ultra Reliable and Low Latency
Communications URLLC 超高可靠低時延通訊
Unacknowledged Mode UM 非確認模式
User Equipment UE 用戶設備
User Plane UP 用戶平面
Window
時窗
Work Item WI 工作項目
技術貢獻：
在這次會議，在 NR的部份，本計畫團隊在 RAN2會議上提出了 5篇技術
貢獻與會前信件討論；其中一篇技術貢獻與主節點跟次節點間的 Measurement
Coordination相關，我們建議主節點與次節點需要對 UE量測能力進行協調，之
後主節點與次節點就可以各自配置個自的量測程序即可，會議的結論與我們的
主張相符；另外一篇技術貢獻討論對於 UL PDCP Duplication的控制方法，我
們認為封包複製功能可以對個別的載體進行設定，如果需要更動態地控制封包
複製功能，則建議使用 L2 信令來加以控制，會議的結論與我們的主張相符，
並且經由投票決定採用 MAC CE 的來動態控制封包複製功能；在 RRM
Measurement的議題，我們提出要由 RRC層設定最多可以考慮多少個波束來計
算細胞信號品質，另外還要有一個門檻值來規範可被考慮波束的最低信號品質，
此外我們也建議設定服務細胞與臨近細胞都考慮同樣數量的波束來計算其細
胞信號品質，最後會議的結論則是會採用ㄧ個 Absolute Threshold來判斷可被考
慮的 Beam；關於 SCG Split SRB上行傳送路徑的選擇，為了能夠同時增強 CP
的穩固性以及減少延遲，我們建議當設置 MCG Split SRB時，應該要將封包重
複傳送於MCG路徑與 SCG路徑上，相關議題於會場雖有討論，但未取得共識；
在 RLC UM的議題上，我們主張不需要 Duplicate Detection的功能，因為在 LTE
裡 HARQ造成的重複封包已經由 MAC層排除。此次會議的結論與我們的主張
相符；在 RLC層的 Segmentation議題上，我們主張在一些情況下，如在高傳輸
率和低延遲的情境下，停用此功能以降低手機端的處理負擔。但並無法取得多
數公司的支持，因此最後會議結論手機端必須對所有服務的所有封包傳送支援
RLC 層的 Segmentation 功能；在 SDAP 層 Header 的議題上，我們主張在一些
8
情況下可以省略 QoS flow ID。然而此問題會與 SA2的設計有關，因此 RAN2
最後決議將發一個 LS給 SA2，並等待回覆後再做決定；在 MAC層 Sub-header
的議題上，我們主張 RAN2應該考慮隸屬同一邏輯通道的連續媒體存取控制封
包服務單元群組的 Sub-header，只需要一個邏輯通道識別。雖然高通的媒體存
取控制封包數據單元連鎖提案在本次會期決議 R15 不支援，但是尚未決定
Sub-header 最佳化是否有需求。我們的看法與諾基亞相同，認為媒體存取控制
封包數據單元連鎖與 Sub-header最佳化是兩個不同的議題，應該分開討論。
此外，在非 NR的議題方面，我們也參與了上行資料壓縮研究項目的討論，
我們的技術貢獻提到由於不同的上行資料壓縮方法在不同的實驗環境下模擬
的結果各有擅場，因此建議在無損數據壓縮演算法與適應性封包資料壓縮法中
選擇一個以繼續後續的工作項目，最終會議的結論則是將選擇的工作交由全會
決定。
會議解說：
1. 新無線電技術(NR) – 用戶平面(UP)
在 UP 方面，本次會議討論了 MAC 層、RLC 層、PDCP 層和 SDAP 內
的 PDU 格式。其中確認了下行的情況不需要考量預先處理的問題，所以在
下行的情況下MAC CE應該和 LTE一樣放在MAC PDU的最前面。此外也
對這些第二層子層內的各種功能細節進行深入的討論。在 UL PDCP
Duplication的設定問題上，同意了採用 MAC CE動態地啟動與反啟動 PDCP
封包複製。在上行資料分流的議題上，決議仍是採用 LTE的 Threshold based
splitting，但如何在 Threshold based splitting 下實現上行封包的預先處理則仍
需進一步研究。在有關 RLC 層的議題中，討論了 UM 的運作細節，最後決
議UM下不需要重複檢測的功能。但是是否所有封包都需要 Sequence Number
和接收端是否仍採用 LTE的Window和 Timer機制來丟棄無法重組的封包則
將留到信件討論中做進一步的研究。另外也討論了禁用 RLC層 Segmentation
的議題，最後會議結論手機端必須對所有服務的所有封包傳送支援 RLC 層
Segmentation 功能。在服務數據適配協定層相關議題的討論中，主要討論了
9
QoS flow ID標示的問題。但是由於此問題會與 SA2的設計有關，因此 RAN2
最後只決議了只有當 Reflective QoS被啟動時才需要帶 QoS flow ID。至於是
否所有下行封包都要帶則留待討論，並決議將發一個聯絡說明給 SA2，等待
回覆後再做決定。
2. 新無線電技術(NR) – 控制平面(CP)
本次會期是 NR 工作項目的第二次會期討論，由於在本年度結束前必須
要優先完成 Non-Standalone的相關議題，也就是 LTE與 NR緊密互通下的主
節點與次節點之間各種信令程序要如何運作，在 Measurement Coordination
的方面，同意了主節點與次節點之間必須要對所欲量測的載波的總數進行協
調工作，以避免超過 UE 量測能力，之後主節點與次節點就可以各自配置以
獲得量測報告並進行相關的決策，此外也同意了由次節點自行決定其 PSCell，
但由於在進入 EN-DC 狀態之前次節點並沒有任何的量測報告可供參考，此
時必須由主節點提供相關的量測報告給次節點使用，而當 SCG被釋放時，必
須要有方法將在 SCG DRB切換成MCG DRB，或是搬移到另一個 SCG去，
而不論是MCG DRB或是 SCG DRB，其載體識別都會是由主節點指定，同
時也容許所有的資料連線載體都屬於 SCG DRB；而在 SCG SRB方面，則是
同意 SCG SRB在設置時也會同時起動加密程序，在 SCG增加以及改變的程
序中可以決定是否要建立 SCG SRB，而 MCG Split SRB也容許與 SCG SRB
同時存在。在 RRM Measurement的部分，其中包括了決定 NR量測模型將會
涵蓋兩個部分，當每個波束通過 L1 Filter後，在 Cell Quality計算的部分，會
先根據設定的個數決定要將多少個波束的能量加以平均，在經過 L3 Filter後
取得 Cell Quality，再根據事件觸發回報機制，同時為了取得個別波束的訊號
品質，則另外對每ㄧ個波束運作的 L3 filter，來取得較為可靠的個別波束訊
號品質，當用戶設備提供 measurement report 時，最佳的幾個波束的辨識也
會跟著回報上去，做為換手時參考之依據，為了讓 Cell Quality不會因為平均
多個波束的能量而導致的失真，也採用ㄧ個 Absolute Threshold 來判斷可被拿
來平均的波束。
10
3. 窄頻段物聯網(NB-IoT)議題
本會期延續上次會議，NB-IoT技術討論主要是解決尚未定案的行動強化
技術，以及許多修訂案，以完善 NB-IoT 在增加傳輸率、低功耗、定位服務
上的技術與應用。
R14 NB-IoT已進入收尾階段，將在 2017年第二季完成制訂，本團對已
開始關注 R15 NB-IoT 的發展，並規劃在第三季投入 R15 NB-IoT 的提案布
局。
與會成員與工作分配
成 員 任 務
陳宏鎮
掌握 LTE/5G-NR 的議題，提出技術提案，參與技術討論
及協商，以 Control Plane of 5G-NR 與 Inactive state of
5G-NR為主。
邱俊淵
掌握 LTE/5G-NR 的議題，提出技術提案，參與技術討論
及協商，以 User Plane of 5G-NR 與 RAN QoS of 5G-NR
為主。
林奕廷 掌握 LTE/5G 的議題，提出技術提案、參與技術討論及協
商，以 NB-IoT為主。
楊豐銘 掌握 LTE/5G-NR 的議題，提出技術提案、參與技術討論
及協商，以 5G-NR URLLC為主。
11
目 錄
摘 要 .................................................................................................. 2
一、會議名稱 .................................................................................. 12
二、參加會議目的及效益 .............................................................. 12
三、會議時間 .................................................................................. 12
四、會議地點 .................................................................................. 12
五、會議議程 .................................................................................. 12
六、會議紀要 .................................................................................. 15
七、心得與建議 .............................................................................. 33
12
一、會議名稱
3GPP RAN2 #98 Meeting
二、參加會議目的及效益
參與 NR 與 R14 NB-IoT 等議題之討論及尋找具前瞻特性之研究題
目。
報告本計畫團隊所發表的文章。
發表系統實作所發現的相關議題，增進實作技術和系統概念的交
流。
與其他大廠接觸以討論合作項目。
使其他國際廠商清楚瞭解本計畫團隊的技術方法與關注方向，以期
開展未來合作機會。
加強與合作廠商的關係，提高合作密度。
三、會議時間
15th – 19th May, 2017
四、會議地點
Hangzhou, China
五、會議議程
本次 3GPP RAN2 #98會議議程如下：
Schedule Main room
Ball Room C
Breakout room 1
Houchao
Breakout room 2
Wulin
UMTS room
Yongchang
Monday
09:00 -> [1], [2], [3], [4], [5],
[6] Rel12 and earlier
[7] Rel-13 and earlier (not
eMTC/NB-IoT)
11:00 -> [8.2] R14 V2V
(Diana)
[8.11.1] eNB-IoT Mobility
Enhancements
[7.4] NB-IoT
[11][12] UMTS
Rel-8/9/10/11/12
[13] UMTS Rel-13
13
[8.5] R14 eLWA
[8.15] R14 meas gap
[8.25] TEI14
[8.11] eNB-IoT (not
positioning)
(Johan)
[14.1] RRC opt
[14.2] DTX/DRX
[14.3] MC
[14.4] QoE
[14.5] TEI14
[14.6] ASN.1 review
[15.1] DL int mit [1]
[15.2] SI sched enh [2]
[15.3] Simp HS-SCCH
[0.5]
(Xudong)
14:30 -> Legacy LTE items from
Monday am continuation
NR [2] (likely to start around
coffee break)
[10.1] Organisational
[10.2.1] Stage 2 TS
[10.2.2] User plane
[10.2.12] QoS
[10.4.3.1] UE cap spec
[9.7] LTE-5G-CN [1.5]
[8.1] R14 eLAA
[8.7] R14 IP
[8.14] R14 SRS switch
[8.17] R14 high speed
[8.19] R14 1rx Cat 1
[8.20] R14 UL cap enh
[8.24] R14 Other
[8.8] R14 L2 latred
[8.21] R14 eFD-MIMO
[8.23] R14 MUST
(Diana)
17:00 ->
Tuesday
08:30 -> [9.7] LTE-5G-CN
continuation
NR [4]
[Other 10.2.x] Stage 2 and
common CP/UP issues
[8.13] R14 V2X
[9.1] R15 feD2D [1.5]
[9.2] R15 sTTI [0.5]
(Diana)
[8.12] feMTC Positioning
[8.11] eNB-IoT Positioning
[7.3] eMTC
[8.12] feMTC
[8.12.1] SC-PTM for feMTC
and eNB-IoT
(Johan)
UMTS continuation (if
required) 11:00 ->
14:30 ->
17:00 ->
Wednesday
08:30 -> NR [4]
Stage 2 continuation if
required
Stage 3 CP
[10.4.1.1-5] RRC
[8.26] Rel-14 ASN.1 review
(Kai-Eric)
NR Stage 3 UP(Diana)
MAC
10.3.1.3 MAC PDU format
10.3.1.5 SR/BSR
10.3.1.6 LCP
UMTS Comebacks
11:00 ->
14:30 -> [9.4] Aerials [1.5]
[9.6] QMC [0.5]
(Hu Nan)
10.3.2 RLC
10.3.3 PDCP
Available for ASN.1
review 17:00 ->
Thursday
08:30 -> NR [4]
Stage 3 CP
[10.4.1.6-8] RRC
[9.3] UDC [2] (Hu Nan) NR Stage 3 UP
(Diana)
10.3.1 MAC remaining AIs
Available for ASN.1
review 11:00 ->
14:30 -> [8.6] R14 eMob
14
17:00 -> [10.4.2] Idle mode [8.10] R14 feMBMS
[8.18] R14 eVolte
[9.5] ViLTE enh [0.5]
(Hu Nan)
10.3.3 PDCP cont (if
needed)
10.3.4 QoS Layer
Comebacks for UP topics
[9.8] Pos Acc [1]
(Yi)
Friday
08:30 ->
until 17:00
Comebacks
NB-IoT/MTC Comebacks
(Johan)
15
六、會議紀要
1. 新無線電技術(NR) – 用戶平面(UP)
在 UP方面，首先討論到 UL PDCP Duplication的設定問題以及是否需要動
態地控制這項功能的啟動與反啟動。
R2-1704834 Summary of email discussion [97bis#13][NR] Control of UL PDCP
duplication Huawei discussion Rel-15 NR_newRAT-Core
在這篇信件討論總結中討論 UL PDCP Duplication功能的控制方法，多數
公司認為封包複製功能可以對個別的載體進行設定，為了能夠更動態地控制封
包複製功能，也建議使用 L2信令來加以控制。對於 DRB的部份各公司都表示
認同，但英特爾公司認為考慮在 EN-DC 的情況下，在 SRB 上使用 UL PDCP
Duplication 這個功能並沒有實際上的效益，因為傳輸功率的分散將會導致可靠
性的下降，但是愛立信公司則是認為即使是使用 UL PDCP Duplication，也不必
然會導致傳輸功率的分散，因此在SRB的方面並未取得共識。根據討論的結果，
主席做出了下列的決議：
Agreements
1 UL PDCP duplication is configurable per DRB and, for NR-NR DC case, per
SRB.
FFS whether the initial state of the UL PDCP duplication (duplication active or not active
and if not active which leg is used) is a default or whether the initial state can be signalled by
RRC
2 RAN2 will attempt to define at least one mechanism to start/stop PDCP
duplication more quickly and with less signalling overhead compared to RRC
reconfiguration.
R2-1704660 Consideration on the activation/deactivation of data duplication for CA
ZTE Corporation discussion Rel-15 NR_newRAT-Core
中興的這篇技術貢獻認為隨著無線電情況的改變，網路端應該要能夠動態
地控制用戶設備是否要進行 PDCP 封包複製，在位於細胞邊緣時，需要進行
PDCP 封包複製，然而當移動到細胞中央時，可能使用其中一條連線進行資料
傳輸即可，如此ㄧ來便可以更有效率地使用上行資源，為了可以動態地啟動與
16
反啟動，可以使用MAC CE或是 PDCP Control PDU進行控制，但由於 MAC CE
下的速度比較快，因此建議採用 MAC CE來控制。
R2-1704835 Dynamic Activation/Deactivation of Packet Duplication Huawei, HiSilicon
discussion Rel-15 NR_newRAT-Core
華為的這篇技術貢獻則是討論到是否真的需要動態地啟動與反啟動 PDCP
封包複製這個功能，華為認為只有在細胞邊緣時當兩條連線的通道品質都很差
的時候才需要啟動這個功能，而這個使用的場景並沒有很高的急迫性，所以認
為只需要用 RRC 來進行這項功能的啟動與反啟動即可。愛立信認為 Packet
Duplication這個功能是位於 PDCP層，所以應該要用 PDCP Control PDU 來控
制，但諾基亞則是支持使用 MAC CE可以更快速地加以控制，黑莓與聯發科則
是認為不論是使用MAC CE或是 PDCP Control PDU都有用戶設備因為通道品
質變差不能及時收到的問題會出現，因此希望是由用戶設備本身根據網路端先
前的指示進行判斷是否要啟動或是反啟動這項功能。最後根據討論與投票的結
果，決定了採用MAC CE動態地啟動與反啟動 PDCP封包複製這個功能。相關
的決議如下：
Agreement
=> MAC CE approach will be used for control of UL duplication. Optimisations to
reliability of the MAC CE will not be introduced for this mechanism. No optimisations or
additional interactions between network nodes are introduced for this mechanism.
R2-1705240 Packet duplication in CA LG Electronics Inc. discussion Rel-15
NR_newRAT-Core
最終的共識為：
1. 單一載波不支援 Packet duplication運作方式
2. RRC可以控制不同的多個載波對應到兩個邏輯通道
3. Packet duplication機制下，PDCP PDUs 運在於不同的 RLC元件。
R2-1704839 Further details of PDCP – RLC Mode Mapping Huawei, HiSilicon
discussion Rel-15 NR_newRAT-Core
17
本提案延續先前RAN2同意的內容: SRB (除了 SRB0之外)運用於RLC AM
模式，DRB將延續 LTE作法運用於 RLC AM或 RLC UM模式。而這次會期更
進一步討論出 RLC TM模式，同意如下：
在 NR系統中，minimum SI、第 0號 SRB、與廣播服務相關的 SI、
和 paging signalling 都會使用 RLC TM模式。
此外在 UP的平行議程裡也進一步討論了上行資料分流的議題。
R2-1704381 Email discussion report on UL data split Ericsson (Rapporteur) report
Rel-15 NR_newRAT-Core
在這篇信件討論總結中主要討論上行資料分流該使用如 LTE 的 Threshold
based splitting或是 hard-split。考慮 hard-split的主要原因是較容易實現上行封包
的預先處理，但反之也可能會造成較高的佇列延遲。最後會場上決議仍是採用
LTE的 Threshold based splitting，但如何在 Threshold based splitting 下實現上行
封包的預先處理則仍需進一步研究。
Agreements
=> A configurable threshold approach is used to determine if the UE should transmit
on one more than one link. As a baseline, the buffer status is used as a threshold. FFS if
other thresholds like data rates or delay can be considered.
=> If below a threshold the UE transmits on one link. When above the threshold
enhancements can be considered to allow for pre-processing and link performance.
在有關 RLC層的議題中，主要討論了 UM的運作細節。
R2-1704365 RLC UM details for NR Ericsson discussion Rel-15
NR_newRAT-Core
愛立信的這篇技術貢獻認為 UM下仍需要重複檢測的功能，特別是當 RLC
和 PDCP是位於不同實體的情況下，以避免 RLC直接將所有封包包含重複的封
包直接傳給 PDCP。但許多公司包含我們則點出重複封包主要由 HARQ的重傳
所引起，而在 LTE裡 HARQ造成的重複封包已經由 MAC所排除，所以 UM下
不需要重複檢測的功能。最後主席採用了此看法並做成如下決議：
Agreements:
=> Duplicate detection in RLC UM is not necessary
18
R2-1705054 RLC UM with t-reassembly Qualcomm Incorporated discussion Rel-15
NR_newRAT-Core
高通的這篇技術貢獻主要討論 UM 下是否所有封包都需要 Sequence
Number 和接收端是否仍採用 LTE 的 Window 和 Timer 機制來丟棄無法重組的
封包。高通認為由於 NR已經同意 RLC不再支援依序傳遞的功能，因此只有被
Segmentation 的封包需要 Sequence Number 讓接收端能重組封包。此外由於並
非所有封包都有 Sequence Number，所以不適用 LTE的 Window機制來丟棄無
法重組的封包。此議題相較於 LTE的機制由於改動較大，會場上花了許多時間
討論各種可能的方案和其優缺點，但最後仍然無法達成共識。所以將留到信件
討論中做進一步的研究。
[NR/UP] – RLC UM – Qualcomm
- Discuss/understand solutions and complexity of solutions
- Company’s preferences on the solutions
- Before next meeting
在有關MAC層的議題中，主要討論了 MAC層 PDU的格式。xx
R2-1705833 MAC CE placement Nokia, Alcatel-Lucent Shanghai Bell, CATT, Fujitsu,
MediaTek Inc., NEC, NTT DOCOMO, INC., ZTE discussion
Discussion 10.3.1.3 R2-1705073 Rel-15
NR_newRAT
這篇多家公司共同提案的技術貢獻認為在下行的情況下，MAC CE應該和
LTE一樣放在MAC層 PDU的最前面。另外在上行的情況下，MAC CE應該放
在所有MAC層 SDU的後面，但在 Padding的前面。主要的理由是下行的情況
不需要考量預先處理的問題，所以不用如上行的情況將MAC CE放在所有MAC
層 SDU 的後面，與 LTE 一樣即可。這部分會場上很快達成共識，但是關於上
行的情況下MAC CE和 Padding位置會場上其他公司則有不同意見。高通和愛
立信認為需要有方法讓基地台能夠提早解讀在MAC層 SDU後面的MAC CE，
例如在 MAC 層 PDU 的最後面固定放一個指標指示 MAC CE 的所在位置，如
19
此 Padding則應該放在 MAC層 SDU和 MAC CE之間。此議題會場上意見仍有
分歧，因此最後決議留待下次會議解決。
Agreements
1. The DL MAC CE is always placed before any MAC SDU and padding
2. FFS for UL MAC CE if we have a pointer and if it is before or after padding
R2-1705114 Discussion of MAC sub-header enhancements ITRI discussion
NR_newRAT-Core
在媒體存取控制封包的 Sub-header議題，本計畫團隊在此篇文稿中，提到
考量 NR 在媒體控制存取層的特性，事先建置與平行處理，在執行邏輯通道優
先權機制後所得到的媒體存取控制封包數據單元，隸屬同一邏輯通道的連續媒
體存取控制封包服務單元將會被群組化成最多兩個群組，並建議 RAN2應該考
慮隸屬同一邏輯通道的連續媒體存取控制封包服務單元群組的 Sub-header，只
需要一個邏輯通道識別。雖然高通的媒體存取控制封包數據單元連鎖提案在本
次會期決議 R15不支援，但是尚未決定 Sub-header最佳化是否有需求。我們的
看法與諾基亞相同，認為媒體存取控制封包數據單元連鎖與 Sub-header最佳化
是兩個不同的議題，應該分開討論。本計畫團隊可以再進一步針對這一點提案，
舉出 Sub-header最佳化所產生的增益進行說明。
R2-1705074 SR for NR Nokia, Alcatel-Lucent Shanghai Bell discussion Rel-15
NR_newRAT
R2-1704054 Discussion on SR and BSR enhancements Guangdong OPPO Mobile
Telecom. Discussion
R2-1705625 SR enhancements with multiple numerologies Huawei, HiSilicon
discussion
以上三篇在服務請求議題上被討論，主要有兩個方向，一個是多個服務請
求配置，一個是 2 bits服務請求。雖然會場上愛立信和高通發言不能排除 2 bits
服務請求的方法，但是大部分公司皆認為多個服務請求配置對標準的變動較少，
且比較有彈性，因此得到以下決議，並由三星撰寫聯絡說明至 RAN1，表達從
RAN2 的觀點認為單一位元的服務請求已經足夠，也不認為有需要在服務請求
攜帶緩衝區狀態回報的資訊。
20
Agreements
1. Multiple SR configurations can be configured to the UE and which SR
configuration is used depends on the LCH that triggers the SR. The granularity of SR
configuration for a logical channel is FFS.
2. From RAN2 point of view a single bit SR with multiple SR configuration is
sufficient to distinguish the “numerology/TTI length” of the logical channel that trigger the
SR. RAN2 has not identified other use cases for which multibit SR is need with sufficient
support.
3. RAN2 does not see the need to convey buffer status information.
4. Send LS to RAN1 to indicate to RAN1 that RAN2 doesn’t see the need to support
multi-bit SR.
在邏輯通道優先權議題有兩個重點被討論。
R2-1705237 Awareness of numerology in MAC LG Electronics Inc. discussion
Rel-15 NR_newRAT-Core
R2-1704504 Visibility of numerology for NR MAC functions Samsung discussion
Rel-15
R2-1704397 Further aspects on LCP Ericsson discussion Rel-15
NR_newRAT-Core
以上三篇討論媒體存取控制層對實體層參數與傳輸時間區間的察覺。部分
公司例如 LG 和英特爾堅持媒體存取控制層只需要得到傳輸時間區間即能進行
適當的運作。然而如高通和華為等公司則認為媒體存取控制層需要額外不同的
服務品質參數才能了解每個實體層參數的意涵。最後得到以下決議，除了傳輸
時間區間，邏輯通道優先權將以指標或配置文件的方式表示媒體存取控制層需
要察覺的實體層參數，參數內容則再討論。
Agreements
1. For LCP and to know which restrictions to use the MAC needs to be aware of
more information than just TTI length (e.g. numerology). An abstraction based on index or
profiles can be supported. Exact parameters are FFS.
R2-1704398 Prioritization in MAC Ericsson discussion Rel-15
NR_newRAT-Core
R2-1704903 LCP with mulitple numerologies Qualcomm Incorporated discussion
Rel-15 NR_newRAT-Core
21
R2-1705624 Remaining issues on LCP with Multiple NumerologiesHuawei, HiSilicon
discussion
另一重點是有關多個實體層參數的優先權討論。由於在 RAN1 有定義子訊
框為 1毫秒，在邏輯通道優先權會遇到的問題是相關參數如每個邏輯通道的優
先權值及計算參數，若子訊框的值和傳輸時間區間的值不同，該如何設計。大
部分的公司皆認為由於 RAN4在量測的粒度很大，約數十個毫秒，因此長時間
來看並不需要在意短時間內的服務品質考量，因此做出以下決議。
Agreements:
1. Logical Channel Priority is configured per MAC entity per logical channel
2. PBR is not configured per numerology, it is per “logical channel” as in LTE
3. Bj is calculated per logical channel. It is up to UE implementation to ensure that Bj is
updated at the right time.
4. FFS if it is up to UE implementation how the UL grants are processed if multiple UL
grants are received or some form of prioritization guidelines are specified.
在 SDAP層相關議題的討論中，主要討論了 QoS flow ID標示的問題。
R2-1704277 QoS Flow Marking Nokia, Alcatel-Lucent Shanghai Bell discussion
Rel-15 NR_newRAT
諾基亞的這篇技術貢獻認為一個 DRB 內並非所有的封包都需要在 Header
裡帶QoS flow ID。在下行封包標示QoS flow ID主要是為了運作Reflective QoS。
在上行封包標示 QoS flow ID 主要是為了幫助基地台轉傳封包至核心網路。
Reflective QoS是指手機可以根據下行封包內的 QoS flow ID觀察其與 DRB和
與 IP Flow 之間的對應關係，並在上行自動採用相同的對應。諾基亞認為只有
當下行的對應關係改變時才需要短暫的在下行封包標示 QoS flow ID，如此可以
減少無線資源的開銷和節省手機的程序處理。但是由於此問題會與 SA2的設計
有關，例如當下行的 QoS flow ID與 IP Flow之間的對應關係改變時，核心網路
會不會告知基地台？會的話包含哪些資訊？如何告知基地台等問題。因此
RAN2 最後只決議了只有當 Reflective QoS被啟動時才需要帶 QoS flow ID。至
於是否所有下行封包都要帶則留待討論，並決議將發一個聯絡說明給 SA2，等
待回覆後再做決定。
Agreements of SDAP headers
22
1. The QoS flow ID is presence once the AS reflective QoS is active. FFS whether
it is always present.
2. gNB should be informed when NAS layer reflective QoS is activated (e.g. can be
used). It is FFS how we handle NAS reflective QoS and dependent on how/when it will be
provided.
3. RAN2 will support a mode in which SDAP header is not present and is
configured per DRB. If configured, FFS how the different fields are handled.
[NR-UP] LS on NAS reflective QoS – Nokia
1. Inform SA2 of our agreements and our stage QoS text
2. ask questions on activation/de-activation of NAS reflective (U-plane/C-plane),
when the AS should/will be informed, expected QoS flow ID size.
- Agree on final draft LS
- One week after the meeting
2. 新無線電技術(NR) – 控制平面(CP)
在 CP 的方面，本次會議對於主節點與次節點間的各種信令流程以及
Measurement Coordination 等進行深入的討論，此外由於引入 SCG SRB，對其
運作的方式也進行了討論。
R2-1704138 Summary of email discussion [97bis#10][NR] MN/SN measurement
coordination NTT DOCOMO, INC. (Email discussion rapporteur) report
Rel-15 NR_newRAT-Core
在這篇信件討論總結中討論在 LTE與NR雙連結下主節點與次節點如何進
行量測設定，多數公司認為對兩個節點想要量測的目標載波必須進行協調才不
會超過用戶設備的能力限制，協調之後便可以各自獨立地進行自身的量測設定。
由於多數公司都同意此ㄧ方向，根據討論的結果，主席做出了下列的決議：
Agreements
1: At least, the total number of measured carriers across LTE and NR needs to be
coordinated between MN and SN so that it does not go beyond the UE capability.
FFS if there are any other UE capabilities related to measurements for which coordination is
required across LTE and NR.
Agreements:
23
2: If MN and SN both configure a measurement object on the same carrier frequency then
the measurement objects need to be configured consistently.
FFS which parts of the object need to be configured the same and which can be allowed to
differ.
3: For MCG and SCG, measurements (objects/ID/reportConfigs) can be configured
independently by LTE RRC (inter-RAT measurement on NR) and NR RRC (intra-NR
measurements on serving and non serving frequencies). (noting that for the objects will be
configured consistently as described by agreement 2)
=> Ask RAN4 which parts of the objects (we can provide details for the object
parameters) from MN and SN should be the same. If RAN4 response indicates further
problems then we can reconsider these agreements.
R2-1705345 EN DC inter-node interaction, overview and RAN2/ RAN3 scope
Samsung Telecommunications discussion Rel-15
三星的這篇技術貢獻認為之前會議已經同意了由次節點來決定 PSCell，但
是在一開始加入 SCG的時候，次節點並沒有任何量測資訊可以決定其 PSCell，
此時必須要由主節點提供相關的量測給次節點做為參考之用，另外也認為主節
點與次節點為了提升整體系統吞吐量，應該都可以發起用戶設備能力重新協調
的機制，而協調的內容應該要擺在兩基站互相傳遞的 RRC 信令之中。由於這
些機制與之前 LTE DC的設計原則相似，因此多數公司都同意採納其意見，相
關的決議如下：
Agreements for all MR-DC options:
1) SN decides the PSCell
2) For SCG cell addition case MN provides measurements to SN (for deciding
PSCell)
3) RRC inter node messages (outside of the UE configuration that is exchanged) are
used for UE capability coordination related fields
FFS whether we have a concept of source and target, and if so whether SN/MN is considered
as source/target for MR-DC.
4) MN can initiate UE capability re-negotiation (as SN can do)
R2-1704919 Modeling of SCG SRB InterDigital discussion Rel-15
NR_newRAT-Core
InterDigital的這篇技術提案主要是認為，MCG Split SRB建立的目的是為
了要增加控制平面的穩固性，而 SCG SRB 則是為了要縮短設定的時間，所以
24
兩者是可以並存的，此外 SCG SRB的建立與釋放可以在 SCG新增或是更動時
執行，其 Security Key則是由次節點的安全金鑰中擷取出來。英特爾與樂金等
公司認為 SCG SRB 應該在 SCG 新增時就已經判斷是否需要建立，不需要在
SCG 更動時又決定要建立或是釋放，但愛立信認為在 SCG 更動時容許 SCG
SRB的建立或是釋放並不會帶來多餘的設計負擔。根據討論的結果，主席做出
了下列的決議：
Agreements for EN-DC and NGEN-DC:
1: SCG SRB is modelled as one of the NR SRBs defined in 38.331.
2: SCG SRB uses NR-DCCH logical channel type.
3: A UE can be configured with both split MCG SRB and SCG SRB
simultaneously.
4: SCG SRB and the SCG leg of split SRB1/2 will be independently configured
5: SCG-SRB establishment and release can be done at SCG addition and SN change
6 SCG-SRB reconfiguration can be done at SCG modification procedure.
7 RRC PDUs on SCG-SRB are ciphered using NR PDCP.
8 RRC PDUs on SCG-SRB are integrity protected using NR PDCP.
9 Security keys for SCG-SRB are derived from S-KgNB.
R2-1704221 Terminology of SCG SRB CATT discussion Rel-15
NR_newRAT-Core
延續上次會期同意內容「SCG SRB 高於所有 DRB 之優先權」。本次討論
SCG SRB所需要考慮的優先權項目，但還尚未有共識。明確地共識如下
因為 MCG 第 2 號 SRB 夾帶在 NAS 訊息裡面，故 SCG SRB 優先
權與第 2號MCG split SRB相當。
R2-1705150 Management of DRB id in LTE-NR interworking Huawei, HiSilicon
discussion Rel-15 NR_newRAT-Core
同意內容如下：
1. 在 MR-DC架構下，無論是MCG或 SCG，UE會有獨立的 DRB ID。
2. 在 EN-DC架構下，由 MeNB分派 DRB ID。
25
在 RRM量測的部分，其中包括了決定量測模型、計算 Cell Quality的方法
等。
R2-1704832 RRM Measurements open issues Sony discussion Rel-15
NR_newRAT-Core
索尼的這篇技術貢獻認為在計算 Cell Quality時，可以採用兩種方法來決定
哪些 beam 是有資格被拿來計算 Cell Quality，第一個方法是採用 Absolute
Threshold，信號強度超過 Absolute Threshold才會被拿來計算 Cell Quality，第
二個方法則是採用 Relative Threshold，即是與最佳 beam 的信號強度差距在
Relative Threshold之內的 beam才會被拿來計算 Cell Quality。各公司間各有偏
好，主張採用 Absolute Threshold比較多，但是主張採用 Relative Threshold則
是認為這個方法能夠保證至少都會有ㄧ個最佳的 beam 來代表這個細胞的 Cell
Quality。根據投票的結果，最後採用了 Absolute Threshold這個方法做為工作假
設，相關的決議如下：
Agreements for combining of beam measurements if N > 1:
1 Averaging will be based on power values (i.e. not dBm values)
Working assumption: Average of up to best N of the detected beams above absolute
threshold
R2-1705596 RRM Measurement: Is Additional Filtering Needed for L3 Moiblity?
Samsung Electronics discussion Rel-15 NR_newRAT-Core
三星的這篇技術貢獻認為不需要在多ㄧ個 L3 Filter 來過濾每ㄧ個 beam從
L1 Filter 來的輸出，否則最新的結果將會被層層的 Filter 稀釋掉而導致 Cell
Quality的不準確。
R2-1704100 Measurement model in NR Ericsson discussion Rel-15
NR_newRAT-Core
愛立信的這篇技術貢獻則是認為在換手的過程中，如果有多ㄧ個 L3 Filter
來過濾每ㄧ個beam從L1 Filter來的輸出，將可以取得每ㄧ個beam的量測結果，
進而可以透過波束的選擇與回報，最佳化換手過程。索尼與英特爾認同愛立信
的看法，但是各公司對於是否要用每ㄧ個 beam的 L3 filter結果做為 Cell Quality
的輸入並沒有共識，所以便將三星與愛立信的提案一併採納，其示意圖如下：
26
根據討論的結果，主席做出了下列的決議：
Agreements
1 There is an additional configurable filter per beam of the beam level
measurements output from the L1 filter for the purpose of reporting beam measurement
results in RRC measurement reports.
2 There is no additional specified filter between the L1 filters and cell quality
derivation function for the purposes of cell quality derivation
3 Same NR measurement model is applicable for measurements performed on
CSI-RS or NR-SS.
R2-1705008 Network Slice Selection Assistance Informatino over RRC Huawei, HiSilicon
discussion Rel-15 NR_newRAT-Core
在切片處理議題只討論此篇技術貢獻。RAN3 已經同意使用者可以提供輔
助資訊以支援 AMF的選取，並送出聯絡說明詢問 RAN2以 RRC訊息傳送輔助
資訊的看法。華為的這篇技術貢獻即是針對此聯絡說明提出技術分析。下圖說
明了 SA2 的決議：用戶必須在 RRC連線建立和非存取層訊息中包含 NSSAI，
RRC和非存取層的網路切片選擇輔助資訊是否完全相同則仍須討論決定。
27
NAS (NSSAI, N-Rq)
UE AMFgNB
RRC (Assistance info, R-Rq) N2
N2
NAS (N-Rp)
Source: R2-1705008, Figure 1. General signalling flow for NSSAI/assistance information
delivery
由於Msg3並不是特別用戶使用，Msg3的大小非常受限，必須非常小心考
慮可以在 Msg3 上傳送那些切片資訊。相對上 Msg5 是特別用戶使用，且也攜
帶非存取層負載，因此建議 RAN2不應考慮Msg3，而應該考慮由 Msg5來傳送
選取 AMF 的輔助資訊。會場上其他公司如愛立信也持相同看法，因此迅速地
做出以下決議。華為也負責撰稿回復 RAN3 聯絡說明，內容除了包含以上決議
外，並說明雖然較小的 Msg5 可以減少連線建立的延遲，但尚未定義 Msg5 的
大小。而有關無線資源提早處理的政策，RAN2 尚未討論，若有任何進展會通
知 RAN3。
Agreements:
1 RAN2 assumption is that MSG3 does not to deliver assistance information for
AMF selection due to RRC size constraints as in LTE.
2 RAN2 assumption is that MSG5 is the earliest message that can be used to
deliver assistance information for AMF selection.
3. NB-IoT重點摘錄
行動強化技術
R2-1705816 Reestablishment for CP CIOT EPS Optimisation Ericsson discussion
本篇提案目的在解決 R14 NB-IoT的行動強化技術。
由於 R14 NB-IoT採用 RRC重建程序來加速換手的流程，LTE版的重建訊
息本身需要加密才能傳遞，但 NB-IoT 控制平面解決方案並未提供安全性的加
密機制，因此 3GPP RAN2 #96 會議中曾寄出一份聯絡說明提案給 SA3，希望
SA3能設計 NB-IoT控制平面解決方案的重建訊息加密機制，SA3回應 2017年
28
二月會議中總共有六篇相關的加密提案被提出討論，然而因為需要進一步的驗
證，最後並沒有決議採用哪一種加密機制，這結果造成 R14 NB-IoT 無法順利
在 2017年三月完成 R14 NB-IoT的標準制訂。
為了讓 R14 NB-IoT能夠在 2017年六月順利完成，SA3於五月加開臨時會
議，會議中討論多種AS安全機制與NAS安全機制，但最終要採用哪一種機制，
SA3 認為應該由 RAN2 決定，因此本篇提案彙整出三種安全機制，並與 R13
NB-IoT的行動機制作比較，並由會議討論出最後的解決方案。
第一個機制是 R13 NB-IoT的行動解決方案，主要是經由重新建立 RRC連
線的機制，包括 NAS的回覆機制，其流程如下圖所示。UE所需傳輸與接收的
信令共有四道，而 eNB與 MME之間的信令共有四道，當 UE換到新 eNB時，
資料會經由MME、新的 eNB重傳至 UE。
29
第二個機制是 R14 NB-IoT的行動解決方案，主要是採用 RRC重建程序與
AS安全機制，其流程如下圖所示：
第二個機制的特點如下：
1. 記號的有效性與連線驗證都在 RAN執行。
2. 資料的重傳也在 RAN執行。
3. RAN的信令可覆用傳統格式。
4. 如果來源端 eNB與目的地 eNB是同一個 eNB，則 eNB到MME端的信
令或許可省略（步驟 10與步驟 11）。
30
第三個機制是 R14 NB-IoT的行動解決方案，主要是採用 RRC重建程序與
NAS安全機制，且 NAS安全機制是由來源端 eNB負責傳收，其流程如下圖所
示：
第三個機制的特點如下：
1. 無論重新建立的連線是否處於同一基地台，記號的有效性與連線驗證都
必須在MME執行。
2. 為了驗證連線的有效性，eNB 與 MME 之間必須設計新的信令（步驟 4
與步驟 7）
3. 資料的重傳可在 RAN執行（步驟 8）。
4. 必須設計新的信令內容給第二道訊息使用。
5. 該流程顯示 MME 可能要保留 RAN 通知的資訊，如系統架構演進之
S-TMSI等參數。
31
第四個機制是 R14 NB-IoT的行動解決方案，主要是採用 RRC重建程序與
NAS安全機制，且 NAS安全機制是由目的地 eNB負責傳收，其流程如下圖所
示：
第四個機制的特點如下：
1. 記號的有效性與連線驗證在 MME執行。
2. 為了啟動MME重新設定背景參數，eNB與 MME之間必須設計新的信
令（步驟 3）
3. 資料的重傳必須經由 MME執行（步驟 8與步驟 9）。
4. 必須設計新的信令內容給第二道訊息使用。
比較上述四種機制，可發現：
1. 機制二、三、四都比機制一增加一次 UE與 eNB之間的上行傳輸。
2. 相較於機制一，機制二可降低 eNB與MME之間的信令傳輸。
3. 相較於機制一，機制三會增加 eNB 與 MME 之間的信令傳輸，且 MME
要保留 RAN的資訊。
4. 機制四與機制一在基地台與 MME之間的信令傳輸次數一致。
32
本提案的處理經過多次表決，最終形成二大陣營，一是以 Ericsson 為首的
AS 安全機制派，支持的包括 LG、ZTE、Mediatek 等。一是以 Qualcomm 為首
的 NAS安全機制派，支持的包括 Nokia、Gemalto、DTAG、Huawei、CMCC、
Vodafone等。AS安全機制陣營認為當初會設計使用 RRC重建的用意就是要減
少 NAS 程序，如果 AS 無法自己處理安全問題，又要交由 NAS 來驗證的話，
相較於 R13 NB-IoT的作法幾乎沒有好處。而 NAS安全機制陣營則認為 AS安
全機制必須改動 UE端規範，很多廠商不想在此時又重新更動 NB-IoT UE的設
計，另一方面許多營運商也不放心交由 AS 來處理安全性的問題，但同時也承
認 NAS 安全機制除了減少 TAU 的程序外，無法為 R14 NB-IoT 行動強化技術
帶來多少好處。最終二陣營互不相讓的情況下，經過多數決採用 NAS 安全機
制方案，並為懸宕已久的行動強化技術議題劃下句點。
群播技術
R2-1705283 Summary of email discussion [97bis#36][LTE eNB-IOT feMTC] SC-PTM
offset Huawei report Rel-14 LTE_feMTC-Core, NB_IOTenh-Core
本篇提案是以電子郵件討論的方式，討論 SCPTM 偏移量的相關問題。由
於 RAN2 於第 97 次會期通過使用 SCPTM 偏移量讓使用群播的 NB-IoT UE 能
持續使用群播服務，然而由於同頻帶細胞重選的公式將 SCPTM 偏移量只設定
在鄰近細胞的權重上，當鄰近細胞成為服務細胞後，SCPTM 偏移量的權重對
新服務細胞就消失了，且 SCPTM 偏移量的影響接著又發生在原服務細胞上，
而造成所謂的乒乓效應。經過討論後，決定將 SCPTM 偏移量也同時設定在服
務細胞上，同時也變更同頻帶細胞重選公式中SCPTM偏移量參數的正負符號，
以達到加強群播服務的效果。
定位
R2-1705032 Email report [97bis#33][eNB-IoT] Positioning Ericsson report Rel-14
NB_IOTenh-Core
33
本提案主要是討論以 LTE為主的 LPP訊息資料量太大，會影響 NB-IoT的
系統效能。本提案提出兩種方案：(1)利用細胞索引來涵蓋多種參數；(2)修正
LPP訊息內的某些參數，降低整體訊息大小。由於第一種方案使用較少的位元
數去定義較多的資訊，某些資訊會無法分辨而造成定位伺服器定義細胞的困擾，
尤其當小細胞的數量增加時，更會增加布建的困擾。會場上經討論後通過第二
種方案，取消鄰近細胞的某些資訊以達到降低訊息大小的目的。另外本篇提案
也提及使用廣播的方式傳送 LPP訊息，雖然獲得大部分公司的支持，然而因為
時間不足以在 R14完成制定，因此可能於下次會期繼續討論廣播 LPP訊息的可
行性。
七、心得與建議
心得
NR 初期優先考慮 Non-Standalone，NR 與 LTE 會以雙連結方式互動，
因此在會議上的花費許多時間來討論主節點與SN間的信令流程與如何
進行彼此之間的協調工作，這部分基本上是以過去 LTE DC的設計原則
為基礎，但是由於主節點與 SN屬於不同的無線電通訊技術，因此如何
達成其中複雜的協調工作便是ㄧ項重要的工作，尤其是對於用戶能力的
協調，目前的進展仍然十分緩慢，可以繼續投入研究能量。另外關於移
動性的相關議題，受限於時間的因素本次會議並沒有進行任何討論，
NR 的換手程序要如何達到 0ms 的需求以及如何引進 Conditional
Handover都是我們在未來需要持續關注的部份。
在 UP方面，為因應 5G緊迫的標準制定時程，5G NR的 UP標準制定
方向主要還是以 LTE為基礎，然而考量到 5G新的服務品質框架和新的
實體層技術，其總體 UP 架構仍然做了一些改變。另外為滿足 URLLC
應用的需求，5G NR 的 UP 功能相較於 LTE 也做了不少演進。整體而
言，UP標準制定的方向初步已大致底定，可以預期接下來標準進程的
腳步將加快，以期能在 2017年底完成 Non-Standalone 5G NR 的標準制
定。
34
URLLC 是 NR 的主要特徵之外，雖然尚未排入會議議程，但相關討論
分散於 Packet Duplication與 SCG SRB兩大主軸已先行討論。此外，NR
開始逐步討論更多相關性的設計細節，例如:SR/BSR增強、QoS和 PDCP
無漏失換手等議題，也陸續開始處理。因 NR non-standalone 預計在本
年度結束前必須要優先完成，故 SCG SRB 也緊鑼密鼓討論與產生共
識。
在 NB-IoT行動強化技術方面，主要是以 R13所提出的二種技術各別探
討如何新增行動功能。在 UP解決方案方面，因為 R13已設計了中斷與
恢復等程序，已能有效減少 NAS 回覆的負載，因此 R14 NB-IoT的 UP
解決方案不增加新的設計。在 NB-IoT 的 CP 解決方案方面，因為 R13
NB-IoT的 CP解決方案沒有 AS的安全性設計，即沒有 AS的完整性驗
證，造成無法執行 RRC重建程序。為了達成連線重建程序，SA3 於 2017
年五月提出許多 NB-IoT 之 RRC 重建安全性驗證的方法，以避免非法
使用者利用重建連線的機會進行阻斷性服務攻擊。RAN2在本次會議作
成決議，採用NAS 安全的方式作為驗證RRC重建訊息完整性的方案，
並為懸宕已久的行動強化技術劃下句點。
另外在定位功能方面，討論的方向在定位協定訊息的減量，因為 NB-IoT
的無線資源很有限，如何在有限的資源內作最有效率的傳送常常是
NB-IoT 第一考量的點，這部分各大家都很有共識並通過許多訊息減量
修正案。
建議
R14 NB-IoT已正式在本會期解完所有的重要議題，將在今(2017)年第二
季完成規範制定。R15 NB-IoT的工作項目已於 2017年三月通過立案，
並已於 2017年四月的RAN1展開討論，RAN2也規劃在第三季開始R15
NB-IoT 的討論，聚焦的議題包括省電、小細胞的布建、分時技術等，
建議對 NB-IoT 有興趣的台灣廠商，可開始加入討論並提早相關的布
局。
RAN2 NR相關討論分別和 RAN3、SA2都有緊密的關係，建議本計畫
35
團隊可一併關注此兩群組動態並予相關專家交換意見。