會議報告（會議類別：其他）

出席第三代合作夥伴計畫無線存取網路 -

3GPP RAN2#101 Meeting 會議報告

出國單位：財團法人工業技術研究院

出席人員：林榮懋、吳志祥

派赴地區：雅典/希臘

會議期間：107 年 02 月 26 日至 107 年 03 月 02 日

報告日期：107 年 03 月 31 日

2

摘 要

本團隊出席在雅典/希臘舉辦的第三代合作夥伴計畫(3GPP)無線存取網路

第 2 工作組(RAN2)第 101 會議，本次會議由 3GPP 的歐洲友人(European Friends

of 3GPP) 主辦，共有 294 人參加。本計畫團隊依規劃有 2 位成員出席，參與

3GPP 第 15 版 (Release 15, R15) 中新無線電技術(New Radio Technology, NR)

的標準制定工作，本計畫團隊著重在控制平面(Control Plane, CP)與用戶平面

(User Plane, UP)之各個重要議題；在會議期間表達我方之意見與立場，同時彙

整各項研究議題之發展與技術現況，並蒐集各家廠商對於不同議題之立場與看

法。

由於 NR 要在今年中前完成第一階段的相關設計，所以在 CP 的方面針對

NR 基本換手(Handover)機制的設計，著重於討論先前會議未決議的設計與問題，

例如: 在 Handover 階段的中存取層(Access Stratum, AS)組態，應該要包含哪些

資訊。在非活躍模式(Inactive mode)的議題下，主要針對無線存取網路通報區域

(RAN Notification Area, RNA)的組態中相對應參數的特性進行討論，另外則是

討論 Inactive mode 在之前會議所做的工作假設做再一次的確認。關於系統資訊

(System Information, SI)，這次會期討論了 SI 應該要包含的內容、SI 的更新流

程與儲存的系統資訊(stored System Information, stored SI)內容。

由於 UP 需要討論的議題涵蓋範圍很廣，本次會議於第二天開始將 CP 與

UP 相關議題分開討論，以兩個平行議程的方式同時進行。本次會議 UP 方面討

論了媒體存取控制(Medium Access Control, MAC)層、無線鏈路控制(Radio Link

Control, RLC)層、分封數據匯聚協定(Packet Data Convergence Protocol, PDCP)

層、以及服務數據適配協定(Service Data Adaptation Protocol, SDAP)層。重要議

題包括 MAC 層對部分頻寬(Bandwidth Part, BWP)的資源設計、隨機存取

(Random Access)對波束故障(Beam Failure)的設計，及對排程請求(Scheduling

Request, SR)及半持續性排程(Semi-Persistent Scheduling, SPS)等的開放性議題

做釐清討論。

縮寫與中英文對照表 (依報告內容摘錄及依英文字母排序)

英文全稱 英文縮寫 中文全稱

3

3rd Generation Partnership Project 3GPP 第三代合作夥伴計畫

Abstract Syntax Notation One ASN.1 抽象語法符號

Access Stratum AS 存取層

Access Stratum context AS context 存取層本文

area ID

區域識別

area specific

區域專用的

Bandwidth Part BWP 部分頻寬

Beam Failure

波束故障

Beam Failure Recovery BFR 波束故障恢復

Beam measurement

波束測量

Bit 位元

Cell

細胞

Cell Identity

細胞識別

Cell specific

細胞專用的

Change Request CR 修正要求

Close Subscriber Group CSG 封閉型用戶群組

Common RACH Resource

通用隨機存取通道資源

Control Plane CP 控制平面

Core Network CN 核心網路

Data Radio Bearer DRB 數據連線載體

Discontinuous Reception DRX 非連續接收

Downlink Control Information DCI 下行控制訊息

EUTRA-NR dual connectivity EN-DC

演進版通用陸地無線接取網路-新無

線電技術雙連結

Evolved Universal Terrestrial Radio

Access EUTRA 演進版通用陸地無線存取

Frequency Division Duplex FDD 分頻雙工

Handover

換手

Handover Preparation Information 換手準備資訊

Hybrid Automatic Repeat reQuest HARQ 混合型自動重傳請求

Idle mode

閒置模式

Inactive mode

非活躍模式

Inactive UE

非活躍模式用戶設備

Inactive Radio Network Temporary

Identifier I-RNTI

非活躍模式無線網路暫時識別碼

Interoperability IOT 互通性

Logical Channel

邏輯通道

4

Long Term Evolution LTE 長期演進技術

Medium Access Control MAC 媒體存取控制

Minimum System Information Minimum SI 基礎系統資訊

Network Slicing

網路切片

new generation NB gNB 新世代基地台

New Radio Technology NR 新無線電技術

Packet Data Convergence Protocol PDCP 分封數據匯聚協定

Paging

呼叫

Paging message

呼叫訊息

Paging Record

呼叫記錄

PDCCH order

實體下行控制通道指令

Physical Random Access CHannel PRACH 實體隨機存取通道

Public Land Mobile Network PLMN 公用陸地移動網路

QoS flow

服務品質流

Radio Access Network RAN 無線存取網路

Radio Access Network working

group #1 RAN1

無線存取網路第 1工作組

Radio Access Network working

group #2 RAN2

無線存取網路第 2工作組

Radio access Notification Area

Code RANAC

無線存取網路通報區域碼

Radio Link Control RLC 無線鏈路控制

Radio Resource Control Connected

RRC_CONNECT

ED 無線資源控制連線模式

Radio Resource Control Idle RRC_IDLE 無線資源控制閒置模式

Radio Resource Control Inactive

RRC_

INACTIVE 無線資源控制非活躍模式

Radio Resource Management RRM 無線資源管理

RAN Notification Area RNA 無線存取網路通報區域

RAN Notification Area Update RNAU 無線存取網路通報區域更新

Random Access

隨機存取

Random Access Response RAR 隨機存取回應

reflective Quality of Service reflective QoS 反射性服務品質

Release 15 R15 第 15版

Resume

恢復

Scheduling Request SR 排程請求

Secondary cell Scell 次細胞

5

Semi-Persistent Scheduling SPS 半持續性排程

Service Data Adaptation Protocol SDAP 服務數據適配協定

Signaling Radio Bearer 3 SRB3 第 3號訊號無線載體

Source cell

來源細胞

Source gNB

來源新世代基地台

stored System Information stored SI 儲存的系統資訊

synchronous reconfiguration

ReconfigWithSyn

c 同步重組

System Information SI 系統資訊

System Information Block 1 SIB1 第 1系統資訊區塊

Target gNB

目標新世代基地台

Tracking Area Identity TAI 追蹤區辨別碼

User Equipment UE 用戶設備

User Equipment capability UE capability 用戶設備能力

User Equipment context UE context 用戶設備本文

User Plane UP 用戶平面

value tag

數值標籤

Working assumption

工作假設

技術貢獻：

在這次會議，在 NR 的部份，本計畫團隊在 RAN2 #101 議上提出了 8 篇技

術貢獻與會前信件討論；其中 4 篇獲大會討論並被接受。

這次的提案著重在 Network slicing 議題、Inactive mode 議題、Idle mode 議

題、以及 SI 議題。

會議解說：

本次RAN2主要處理NR工作項目技術討論，聚焦於非獨立運作NR功能，

預期會議後完成 NR 的初版標準規格。

1. 新無線電技術(NR) – 控制平面(CP)

在 NR Handover 機制中，決議了在 Handover 階段的中存取層(AS)組態，

需要包含用戶設備(UE) 透過反射性服務品質(reflective QoS)得到的 QoS

flow 與數據連線載體(DRB)之間的對應；包含目標新世代基地台(Target gNB)

6

可以選擇性的包含 Common RACH Resource 於同步重組(ReconfigWithSync)

訊息中，若 Target gNB 未將此資訊包含，則 UE 繼續使用 Source cell 的

Common RACH Resource；包含 Source cell 的 Minimum SI。而 Beam

measurement 的結果也會包含於 Handover Preparation Information 中。

在 Inactive mode 的討論中，關於無線存取網路通報區域(RNA)組態決議

了：RNA 中的 cell 需要屬於相同的公用陸地移動網路(PLMN)；RNA 中最多

可以包含 32 個 cell；RNA 中將用 NR 之 Cell Identity 來辨識 RNA 中的 cell；

RNA 最多可以包含 32 個無線存取網路通報區域碼(RANAC)；RANAC 的大

小為 6 個位元；對於一個 cell 只會廣播一個 RANAC，對於所有 PLMN 共享

相同的無線存取網路(RAN)的情況下，將會共有個共同的 RANAC；RANAC

將會是第 1 系統資訊區塊(SIB1)的選項欄位；一個 RNA 最多可以包含 16 個

追蹤區辨別碼(TAI)；RNA 對於 R15 的 Inactive mode UE 是必要的組態。

在 Inactive mode 中，對於相關的程序決議如下：確認 gNB 可以將 Inactive

mode UE 轉換至無線資源控制連線模式(RRC_CONNECTED)或無線資源控

制閒置模式(RRC_IDLE)，做為回應無線存取網路通報區域更新(RNAU)的動

作；當因為 RNA 改變而使 gNB 收到 RNAU 後，UE context 需要轉移到服務

的 gNB；當 Resume 失敗（包括 RNAU 失敗），UE 將轉移至 RRC_IDLE 並

通知上層；Resume 將會受到一個時間機制保護，當超過時間時，將認定

Resume 失敗；非活躍模式無線網路暫時識別碼(I-RNTI)將用於 RAN Paging

message 中的 Paging Record；當收到 RAN Paging 之後，UE 將會開始 Resume

程序；確認當收到核心網路(CN) Paging 之後，UE 將會移至 RRC_IDLE 並通

知上層；RAN paging 將會使用與 Idle mode 一樣的 Paging message；RAN

Paging 將不會用於將 Inactive UE 移至 RRC_IDLE 的用途上。

對於系統資訊(SI)方面，經過電子郵件討論後與會場上決議，確定了

Minimum SI 的內容；另外也決議了系統資訊的更新方式，也就是透過 Paging

的方式來通知 UE 需要更新 SI。對於 SIB1 之外的其他系統資訊，則透過 SIB1

來排程；對於 stored SI，則決定了使用 value tag 和 area ID 來辨別 stored SI

是否有效。

7

2. 新無線電技術(NR) – 用戶平面(UP)

BWP 在隨機存取程序仍有一問題須釐清。在競爭式的隨機存取程序中，

使用者如何知道要去哪一個下行 BWP 收取隨機存取回應(RAR)。經過討論後

的共識是將實體隨機存取通道(PRACH)配置和資源與下行 BWP 做連結，因

此使用者只需要在相對應的下行 BWP 收取 RAR。

波 束 故 障 恢 復 (BFR) 議 題 推 翻 RAN1 設 計 的 參 數

beamFailureRecoveryTimer，並且重新討論了 BFR 的運作流程，得到結論如

下，只有一個 maxpreamble 參數運作，在 MAC 層接收實體層送來的 Beam

Failure 通知後，啟動計時器以作為重新將 BFR 計數器歸零的動作，當計時

器期滿終止時則將計數器歸零，而計數器歸零則停止 BFR 程序。如果啟動中

的 BWP 有 PRACH 的資源，則直接在啟動中的 BWP 進行隨機存取處理來執

行 BFR；否則會回到初始 BWP 處理。不論在哪一個 BWP，處理優先權是一

樣的，先進行非競爭模式，接著是競爭模式。

在 SR 議題，對於觸發和取消的條件再進行釐清。因為實體層可以動態

地排程傳輸區塊的時間，因此當一個傳輸區塊組合完成，並不會立即傳送，

而是依據排程的時間點，過一段區間後才傳送。經過討論後的決議為，含緩

衝區狀態報告的傳輸區塊在組合完成一直到送出的這段期間，若有 SR 且有

上行資源可以傳送，就允許進行 SR 觸發。而當含緩衝區狀態報告的傳輸區

塊送出後，相對應的 SR 則會取消。

關於SPS議題，已在電子郵件討論中確認，不論是動態授予的時槽聚合，

還是配置授予的重複傳送，皆視為混合型自動重傳請求(HARQ)的一次重傳

程序。會議中僅對標準文件如何修改的文句用語再做細部的修改和確認。

8

目 錄

摘 要 .................................................................................................. 2

一、會議名稱 .................................................................................... 9

二、參加會議目的及效益 ................................................................ 9

三、會議時間 .................................................................................... 9

四、會議地點 .................................................................................... 9

五、會議議程 .................................................................................... 9

六、會議紀要 .................................................................................. 13

七、心得與建議 .............................................................................. 28

9

一、會議名稱

3GPP TSG RAN2 #101

二、參加會議目的及效益

參與新無線電技術(NR)等議題之討論及尋找具前瞻特性之研究題

目。

報告本計畫團隊所發表的文章。

發表系統實作所發現的相關議題，增進實作技術和系統概念的交

流。

與其他大廠接觸以討論合作項目。

使其他國際廠商清楚瞭解本計畫團隊的技術方法與關注方向，以期

開展未來合作機會。

加強與合作廠商的關係，提高合作密度。

三、會議時間

26 February- 2 March, 2018

四、會議地點

Athens, Greece

五、會議議程

本次 3GPP RAN2 #101 會議議程如下：

Schedule Main room

Ethinki Conference Centre

(5 mins walk from

Intercontinental hotel)

Breakout room 1

Aphrodite 3

Breakout room 2

Ethinki Library

Small Breakout room 3

Omikron 1

Monday

09:00 -> [1], [2], [3]

10

[4.1] Handover interruption for

LTE/NR

Starting after completion of

4.1 in main room (approx.

10:00)

[9.2] sTTI [0]

[6] R12 and earlier

[7.3] R13

[8.1] R14 eLAA

[8.5] R14 eLWA

[8.6] R14 eMob

[8.7] R14 IP

[8.8] R14 L2 latred

[8.10] R14 feMBMS

[8.14] R14 SRS switch

[8.15] R14 meas gap

[8.17] R14 high speed

[8.18] R14 eVolte

[8.19] R14 1rx Cat 1

[8.20] R14 UL cap enh

[8.21] R14 eFD-MIMO

[8.23] R14 MUST

[8.24] R14 Other

[8.25] TEI14

(Diana)

11:00 -> NR

[10.1] Organisational

[10.4.1.8] Access Control (at least

email and LS to CT1)

[7.2] NB-IoT

[8.11] eNB-IoT

[7.1] eMTC

[8.12] feMTC

(Johan)

14:30 -> Common CP/UP topics:

[10.2.1] TS

[10.2.2.1] UP

[10.2.5] BWP

[10.2.12] QoS

Other NR stage 2

[10.2.2.2] EN-DC correction

[10.2.3] Non EN-DC corrections

[10.2.4] Basic HO

[10.2.8] RLM/RLF

[10.2.9] IRAT mobility

[9.5] ViLTE [0]

[9.6] QMC [0]

[9.18] BT/WLAN MDT [0.5]

(Hu Nan)

[9.13] Rel-15 NB-IoT

[2.5] (Johan)

[9.14] Rel-15 MTC [2.5]

(Emre)

17:00 -> [8.2] R14 V2V

[8.13] R14 V2X

[9.10] R15 V2X may be

started if time allows

(Kyeongin)

11

[10.2.10] Security

[10.2.11] Slicing

[10.2.12] Positioning

[10.2.14] Other

May start some EN-DC corrections

if time allows

Tuesday

08:30 -> NR CP

EN-DC corrections to NR RRC

[10.4.1.3.1, 10.4.1.4.1/2,

10.4.1.5.1/2, ]

EN-DC corrections to LTE RRC

[10.4.2.2/3]

UE capabilities [10.4.4.2]

[10.3] NR User Plane

[10.3.1] MAC (except

duplication)

(Diana)

[9.9] CA Util [0.5] (Hu

Nan)

[9.17] feCOMP [0.5] (Hu

Nan)

11:00 -> [9.13] Rel-15 NB-IoT

[2.5] (cont) (Johan)

[9.14] Rel-15 MTC [2.5]

(cont) (Emre)

14:30 -> ASN.1 review [10.4.3.2]

17:00 ->

Wednesday Room change (Wed

only):

Small Breakout room 3

Omikron 1

Room change (Wed

only):

Breakout room 2

Ethniki Library

08:30 -> NR CP

[10.4.1.6] System Information

[10.3.2] RLC (except

duplication)

[10.3.3] PDCP (except

duplication)

[9.16] UDC [1]

(Hu Nan)

ASN.1 review [10.4.3.2

continued and class 2

issues]

Part 4 - RRM

Part 1 - L1 params

Part 7 - UE caps

Part 5 - Bearer config

Part 6 - Inter node

Part 3 - L2/3

11:00 -> [9.20, 9.21] Other R15,

TEI15 [1] (Hu Nan)

14:30 -> [10.4.1.7.6] Inactive security

[10.4.1.3.2] Message

harmonisation

[10.4.1.7.x] Inactive

17:00-18:00 (During CSI-RS joint

session): Stage 2 topics:

[10.2.14] Voice related

[10.2.10] Security

[10.3.4] SDAP

[10.3.1] MAC

continuation/second round

[9.8] Positioning [1]

(Nathan)

17:00 -> [9.10] R15 V2X [1]

(Kyeongin)

17:00-18:00 Joint with

RAN1 on CSI-RS

configuration

12

Thursday Room change

(Thursday):

Small Breakout room 3

Omikron 1

Room change

(Thursday):

Breakout room 2

Ethniki Library

08:30 -> [9.7] LTE-5G-CN [1.5]

NR (cont)

[10.4.5.6] Paging

Stage 2 items

[10.2.11] Slicing

[10.2.9] IRAT

[10.2.14] Other

[10.3.3.5] PDCP Duplication

[10.3.2.3] RLC impact of

duplication

[10.3.1.11] MAC impact of

duplications

CBs

[9.12] Unlic [1] (Hu Nan) ASN.1 review continued

Part 1 - L1 params

Part 7 - UE caps

Part 5 - Bearer config

Part 6 - Inter node

Part 3 - L2/3

11:00 -> [9.11] 1024 QAM [0.5]

Hu Nan)

12:30 to 14:30

[9.8] Positioning

(continued)

(Nathan)

14:30 -> [10.4.1.3.2] Message

harmonisation

[10.4.1.3.x] Connection control

[9.15] HRLLC [1]

(Hu Nan)

17:00 -> Comebacks? [9.18] Aerial [1]

(Hu Nan)

Friday

08:30 ->

until 17:00

Comebacks

NB-IoT/MTC

comebacks, if required

(Johan)

13

六、會議紀要

1. 新無線電技術(NR) – 控制平面(CP)

換手(Handover)機制

本次會議對於 NR 基本 Handover 機制的設計進行深入的討論，討論

Handover 機制中 gNB 之間所傳送的訊息應該夾帶的資訊內容。

基本上多數公司認為原本在 LTE 中 Handover 程序所使用的相關訊息

中所夾帶的資訊都可以在 NR 中加以延用，在 Source gNB 向 Target gNB

傳送 HandoverPreparationInformation 時，就應包含原本在 Source gNB 所使

用的 AS 組態、RRM 組態、以及 AS context，但是否要提供 Source gNB 的

Minimum SI，或者是否也可以夾帶 beam measurement 資訊給 Target gNB

參考尚未達成共識。另一方面，當 Target gNB 接受 Source gNB 的 Handover

請求後，會回傳Handover所需要設定給Source gNB，但UE在進行Handover

時對於 Common RACH Resource 的使用原則也尚未達成共識。本次會議即

針對以上議題進行討論。

R2-1802082 Remaining issues and TP for baseline handover procedure

vivo discussion Rel-15 NR_newRAT-Core R2-1800863

在本篇技術文件中，討論了以上提到的議題。在會場上的討論上，針

對在 HandoverPreparationInformation 包含原本在 Source gNB 所使用的 AS

組態中是否要包含 UE 透過 reflective QoS 得到的 QoS flow 與 DRB 之間的

對應，沒有太多歧見。多數公司認為包含此項資訊，可以協助 Target gNB

盡快地恢復 UE 原本的服務，所以此項資訊很快便達成共識。

另外，關於 Common RACH Resource 的使用原則，也因為在前幾次會

議中的討論，會議上的公司已逐漸達成共識。便是認為 Target gNB 可以選

擇性地包含 Common RACH Resource 的資訊於 ReconfigWithSync 中，當此

項資訊沒有包含時，UE 應該要繼續使用 Source cell 的 Common RACH

Resource。這項行為的主要是若 Target gNB 知道 Source cell 所使用的

Common RACH Resource 與自己所提供的是一樣的，Target gNB 可以選擇

不再額外提供一樣的資訊，而 UE 可以直接延用 Source cell 的 Common

14

RACH Resource。

但關於是否要包含 Minimum SI 於 HandoverPreparationInformation 中

的議題上，雖然大多數公司持贊成的意見，但愛立信的代表依舊發言希望

能釐清這項資訊的明確使用情境，是以此項資訊在當時會場的討論上，並

沒有馬上地達成共識。

另 外 ， 關 於 beam measurement 的 資 料 是 否 要 包 含 於

HandoverPreparationInformation 中的議題上，多數公司對於其細節該如何

設計尚未有共識，例如，其表現方式是否如 Scell 改變時具有一樣特性。

此議題在當時會場的討論上，並沒有馬上地達成共識。

所以，在此篇技術文件討論上，達成以下的決議：

Agreements

1: AS configuration includes the QoS flow to DRB mapping configured to the UE via reflective

QoS to support lossless handover (mapping configured by RRC signalling already agreed to be

provided in AS config).

FFS: Whether the beam measurement information is provided in the HandoverPreparationInformation

following the same principles as beam measurement information in the SCG change case.

FFS: Whether AS configuration needs to includes the minimum system information from source

2 The target gNB optionally includes the common RACH configuration in the

ReconfigWithSync, if not included, the UE continues to use the common RACH configuration

of the source cell.

針對決議中的未決事項，主席裁定將利用離線討論再進討論，希望能

達成共識。

經離線討論後，彙整討論結果如下技術文件。

R2-1804013 Summary of offline discussion #22 vivo discussion Rel-15

NR_newRAT-Core

在離線討論中，公司針對會場上的問題皆加以釐清，所以上篇技術文

件中，所列的未決議題皆以達成共識。但三星的代表依舊對 beam

measurement 該包含的是一個 cell 或是一個 cell 列表的 beam measurement

15

的結果存有疑慮。所以，此項議題依舊未達共識。

本篇技術文件討論後，達成共識如下：

Agreements

1: The beam measurement information is provided in the HandoverPreparationInformation following

the same principles as beam measurement information in the SCG change case.

FFS The number of cells for which this information is provided.

2: AS configuration can include the minimum system information from source.

非活躍模式(Inactive mode)議題

在 Inactive mode 的議題上，本團隊參與了 R2-1803760 與 R2-1803778

兩篇信件討論。

R2-1803760 Report of #13 RRC inactive (RAN area configuration) (Intel)

Intel Corporation report Rel-15 NR_newRAT-Core

此信件討論主要討論的是關於 RNA 組態的討論。RNA 中包含的 cell

數目與 RNA 碼的數目應該為何，由於在信件討論當中，多數公司皆以達

成共識，在會場並無太多的異議提出。

關於 RNA 組態決議了：RNA 中的 cell 需要屬於相同的 PLMN；RNA

中最多可以包含 32 個 cell；RNA 中將用來 NR Cell Identity 來表示 RNA 中

的 cell；RNA 最多可以包含 32 個 RANAC；RANAC 的大小為 6 個位元；

對於一個 cell 只會廣播一個 RANAC，對於所有 PLMN 共享相同的 RAN

的情況下，將會共有個共同的 RANAC；RANAC 將會是 SIB1 的選擇性欄

位；一個 RNA 最多可以包含 16 個 TAI；RNA 對於 R15 的 Inactive mode UE

是必要的組態。

相關決議如下：

Agreements

1: For cell lists approach, RNA contains cells that belong to the same PLMN

2: maximum number of cells in RAN notification area is 32;

3: NR Cell Identity (36 bits) are used as cell id for cell list approach;

16

4: maximum RAN Area IDs configured in one RNA is [32]

5: RANAC size should [6]bits. (send LS to RAN3)

6: For one cell, only 1 RANAC can be broadcasted. A single RANAC is common for all PLMNs

sharing the RAN.

7 RANAC is optional field in SIB1.

8 maximum 16 TAIs can be configured in one RAN notification area;

9 ASN.1 is agreed as a baseline.

10 RNA is mandatory configured for the inactive UEs for Rel-15; (May be re-discussed after the

discussion of the interaction between RANU and TAU)

於信件討論中關於 RNA 對於 UE 是否為必要欄位，我們的建議獲會

議同意。

R2-1803778 Report of Email Discussion [NR-AH1801#14][NR] RRC

inactive procedures Qualcomm Incorporated report

此信件討論主要討論的是關於 Inactive mode 的其他相關議題，主要是

再次確認在前幾次會期所提出的工作假設。由於在信件討論當中，多數公

司皆以達成共識，在會場並無太多的異議提出。

對於相關的程序決議如下：確認 gNB 可以將 Inactive mode UE 轉換至

RRC_CONNECTED或是RRC_IDLE做為回應RNAU的動作；當因為RNA

改變而使 gNB 收到 RNAU 後，UE context 需要轉移到服務的 gNB；當

Resume 失敗（包括 RNAU 失敗），UE 將轉移至 RRC_IDLE 並通知上層；

Resume將會受到一個時間機制保護，當超過時間時，將認定Resume失敗；

I-RNTI 將用於 RAN Paging message 中的 Paging Record；當收到 RAN

Paging 之後，UE 將會開始 Resume 程序；確認當收到 CN Paging message

之後，UE 將會移至 RRC_IDLE 並通知上層；RAN paging 將會使用與 Idle

mode 一樣的 Paging message；RAN Paging 將不會用於將 Inactive UE 移至

RRC_IDLE 的用途上。

決議如下：

17

Agreements

1: RAN2 to confirm that moving the UE to RRC_CONNECTED or RRC_IDLE in response to

RNAU is allowed and up to eNB decision.

2: RAN2 to agree that the UE context is transferred to the serving gNB when it receives from the

UE an RNAU due to change of RNA.

3: If resume procedure (including RNAU procedure) fails, the UE move to RRC_IDLE and

indicates to NAS to perform NAS recovery

3a Resume procedure is protected by a timer (similar to T300 for connection establishment

procedure). UE consider resume failure upon timer expiry.

4 For RAN paging, I-RNTI is used as the UE identity in the paging record.

5 The UE initiates RRC Connection Resume procedure upon receiving RAN paging.

6 RAN2 to confirm that the UE moves to RRC_IDLE and informs NAS when it receives a CN

paging in RRC_INACTIVE state.

7 Same paging message is used for RAN paging as Idle paging.

8 RAN paging is not used to move UEs from RRC_INACTIVE to RRC_IDLE.

於信件討論中關於 Inactive mode 相關的程序，我們的建議皆獲會議同

意。

閒置模式(Idle mode)議題

R2-1802157 Service based cell reselection ITRI, ASUSTeK discussion

NR_newRAT-Core R2-1801344

在 Idle mode 的議題中，我們與 ASUSTeK 共提了一篇技術文件是關於

基於服務形態的細胞重選機制的設計，但由於時間關係，本議題未於會議

中討論。

系統資訊(SI)

SI 的討論，主要分成三個部分，第一個部分討論 SI 應該要包含哪一

些內容；第二個部分是 SI 的更新；第三個部分則是 stored SI 的有效性判

18

定。關於 SI 的內容，主要是透過會期前的一個電子郵件討論：

R2-1802313 Summary of email discussion [NR-AH1801#11] System

information content/structure Ericsson discussion

首先先假設 Minimum SI 只包含了 MIB和 SIB1，因為 RAN1 對於 SIB1

的大小還沒有決定出來，所以需要等 RAN1 決定後，才有辦法判斷是否需

要將 SIB1 分成兩個部分。對於 MIB 和 SIB1 是兩個不同的 RRC 訊息，對

於其他的 SIB 則會用 SI message 的方式傳送，跟 LTE 相似。NR R15 的 SIB

也會包含有關細胞重選的資訊。另外，SIB1 會包含一個指標，未來使用於

標示 CSG 設定，也會包含 SI message 的排程資訊。基本上，跟 LTE 的 SIB1

相似。其他的細節與會議決議如下：

Agreements

1 Working assumption that minimum system information consists of MIB and SIB1, while all

other NR-SIBs are part of other system information. This working assumption can be

re-evaluated after checking with RAN1 if the expected size of the SIB1 is problematic.

2 MIB and SIB1 are separate RRC messages, while all other SIBs are transmitted in SI messages

scheduled in SIB1 (similar to LTE).

3 NR Rel-15 will contain SIBs for Common cell re-selection information (similar to LTE SIB3),

Neighbouring cell information for intra-frequency cell re-selection (similar to LTE SIB4),

Information relevant for inter-frequency cell re-selection (similar to LTE SIB5) and

Information relevant for inter-RAT cell re-selection to E-UTRAN.

4 NR Rel-15 will contain SIBs for ETWS primary notification, ETWS secondary notification

and CMAS.

5 An indication for forward compatibility purposes (e.g. for CSG) is introduced in SIB1, but no

further SIBs for functionality related to Cell reselection to UTRA, Cell reselection to GERAN,

cell reselection to CDMA2000, Home eNB, MBMS, EAB, WLAN interworking, Sidelink, or

V2X are specified for NR Rel-15.

6 SIB containing GNSS and UTC information (corresponding to LTE SIB16) will be specified

for NR Rel-15.

19

7 SIB1 contains Scheduling Info List and SI Window Length

8 SIB1 contains Cell Selection Info

9a SIB1 contains information elements relevant for initial access from

ServingCellConfigCommon. (May be revisited if WA is not confirmed)

10 SIB1 contains Cell Access Related Info (May be revisited if WA is not confirmed)

11: SIB1 for ANR purposes in NSA deployments will have minimal content

SI 的更新機制也是先透過電子郵件討論；另外，有關 stored SI 的有效

性也在此在電子郵件中，一併討論，文件如下：

R2-1803422 Report of email discussion on [NR-AH1801#12][NR] System

information procedures Samsung (Email rapporteur) R&D Institute India

report Late

首先先討論有關 SI 改變，這個部分大部分都是沿用 LTE 的方法，包

括：透過 paging 來通知 UE需要進行 SI 更新，無論 UE是處在 RRC_IDLE、

RRC_INACTIVE、或 RRC_CONNECTED 狀態，都需要去監聽 paging 來

知道 SI 是否改變。其中，改變的指示會放在 Paging message 中，但是，因

為 RAN1 也不排除該指示可以放在 DCI 中，所以 RAN2 也不排除放在 DCI

的技術選項。其他的細節與 LTE 都相似，決議原文如下：

Agreements for SI modification

2.1.1: Like LTE, the SI change/update is indicated to UEs through paging.

2.1.2a: RRC_IDLE and RRC_INACTIVE UEs shall monitors for SI update notification in its own

paging occasion every DRX cycle.

2.1.2b: RRC_CONNECTED UE monitors for SI update notification in any paging occasion (if the UE

is provided with common search space to monitor paging in connected)

2.1.3: In NR, adopt the LTE concept of modification period for SI update handling.

2.1.4a: SI update indication included in paging message is supported (can be revisited if the DCI

design allows the SI update indication and scheduling of a paging message in parallel)

2.1.4b: SI update indication included in DCI is supported

FFS Detail content of the SI update indication within paging message and DCI.

20

2.2.1: For NR, adopt LTE principle; UE acquires SI immediately for ETWS/CMAS notifications and

for SI update indications in paging UE acquires SI at next modification period boundary.

FFS If any different handling is required for AC related parameters.

2.2.2: If UE receives SI update indication in paging, then UE acquires the updated SI at the next

modification period boundary assuming NW broadcasts updated SI (even if the updated SI is

on-demand SI).

有關於 SI 的排程，也是採用跟 LTE 相似的方法，也就是 SIB1 會放

SI message 相關的排程訊息；其中值得注意的是，兩個 SI message 的週期

是否可以重疊，現場公司考慮 beamforming 的影響，希望可以重疊，但是

有公司持不同的意見（這個部分與 LTE 不相同），所以這個部分保留繼續

討論，其他的決議內容如下：

Agreements for SI scheduling

3.1.1: In NR, adopt the “LTE scheduling framework” characterized as follows:

• SIBs (other than SIB 1) are transmitted in SI messages.

• SIB 1 indicates mapping of SIBs to SI messages.

• Each SIB is contained in only a single SI message.

• Only SIBs having the same periodicity can be mapped to the same SI message.

3.2.1a: Only a single SI message is scheduled within one SI-window.

FFS: Whether SI-windows can overlap

3.2.2: The SI-window length is common for all SI-messages.

3.2.3: Segmentation of SIB/SI messages is not allowed except ETWS/CMAS SIBs.

對於 stored SI，這個部分對於 value tag 與 area ID 的架構歧見比較多，

所以針對比較有共識的部分先決議，包括：每一個 SIB 都有自己的 value tag；

stored SI 的 SIB 可以分為 cell specific 跟 area specific，基本上，對於 cell

specific 的 SIB，會沿用 LTE 的方式來判斷是否有效。另外，area ID 也確

定會跟 value tag 分開給。一個 SIB 會被配置為 cell specific 或者是 area

specific。對於 area ID 的需求上，最後也同意只會有一個 area ID；詳細的

決議如下：

21

Agreements on stored SI

1.1.1: Value tag associated with each SIB of Other SI (OSI) available in cell is included in SIB1

regardless of whether the SIB is broadcasted or provided on demand.

FFS size of value tag

1.1.2: For “cell specific” SIB the LTE principle is applicable for determining the validity of the stored

information corresponding to that SIB

FFS Whether it is necessary to support a case where a SIB is area specific but within that area there are

some cells which provide cell specific version of the SIB.

1.2.1: Adopt the LTE principle for validity of stored system information based on expiry of validity

timer regardless of the SIB is “cell-specific” or “area-specific”. Single validity timer for all

cases is the baseline.

1.2.2: The SI storage and management of stored SI can be left to UE implementation. Decision to store

a SIB and how many to store is UE implementation.

1.3.1: System Info Area ID, if signalled, is signalled in SIB1 separately and in addition to value tags

associated with each SIB available in the cell.

1.3.2a: The rules for defining whether a stored SIB is valid in the current cell will be clearly defined in

the spec, and if the UE doesn't have a valid stored SIB for the current cell then the UE must

acquire.

2 A SIB can be configured to be cell specific or area specific (not applicable SIB1). Whether this

is configured per SIB or configured per SI message to be concluded when ASN.1 is specified.

3 At most one AreaID can be indicated within SIB1, and if indicated then applies to all area

specific SIBs available in the cell.

2. 新無線電技術(NR)–用戶平面(UP)

媒體存取控制(MAC)層

本次會議釐清 BWP 在隨機存取程序中，使用者如何知道要去哪一個

22

下行 BWP 收取 RAR，共討論三篇技術文件。

R2-1801815 Further considerations on RACH related BWP issues Huawei,

HiSilicon discussion Rel-15 NR_newRAT-Core

R2-1803203 BWP selection and RA Ericsson discussion Rel-15

NR_newRAT-Core

R2-1803061 BWP ambiguilty in contention-based RACH procedure

MediaTek Inc. discussion

在討論華為的技術文件時，諾基亞表示有些提案建議將 PRACH 配置

和資源與下行 BWP 做連結即可解決。因此使用者只需要在相對應的下行

頻寬收取 RAR。接著討論愛立信和聯發科的技術文件後，做出以下決議：

Agreements

=> For FDD and CBRA, PRACH configuration/resources are linked with DL BWPs

(implicitly or explicitly). The UE only monitors RAR on DL BWPs that are linked to the used

PRACH resources

=> Working assumption: UL BWP k is linked with DL BWP k. If the UE intends to

transmit preamble on UL BWP k, then the active DL BWP has to be DL BWP k. ASN.1

signalling supports this

至於細節內容包括BWP連結方式及使用程序將以電子郵件討論進行，

於下次會期再做確認。

BFR 議題以 RAN1 送來的技術文件為基礎進行討論。

R2-1803981 LS reply on beam failure recovery RAN1

由於 RAN2 認為 RAN1 設計的參數 beamFailureRecoveryTimer，僅用

來做停止繼續尋找候選波束，從 RAN2 角度這個參數並不需要，只需要一

個計數器用來計算Beam Failure通知即可。重新討論了BFR的運作流程後，

決定只有一個 maxpreamble 參數運作在隨機存取程序，在 MAC 接收實體

層送來的 Beam Failure 通知後，啟動計時器以作為重新將 BFR 計數器歸零

的動作; 當計時器期滿終止時則將計數器歸零，而計數器歸零則停止 BFR

程序。如果啟動中的 BWP 有 PRACH 的資源，則直接在啟動中的 BFR 進

23

行隨機存取處理；否則會回到初始 BWP 處理。不論在哪一個 BWP，處理

優先權是一樣的，先進行非競爭模式，接著是競爭模式。最後決議如下：

Agreements

1 Single maxpreamble, powerampingstep and received target power parameters are used

that can have different values depending on why the random access is used (BFR or not).

3 From RAN2 point of view beamFailureRecoveryTimer is not supported

4 Assume that at least CFRA BFR can be configured for SCell using ASN.1. FFS if there

are any major impacts to support this in UP

5 PHY delivers to MAC “beam failure instance” notifications only and MAC maintains a

timer for resetting the counter:

- the timer is (re)started upon every new reception of “beam-failure instance”.

- At timer expiry the counter is reset.

6 A BFR counter is maintained and incremented at every “beam-failure instance” indication.

When the counter reaches MaxBFI the UE trigger BFR

7 Timer is configured in number of periods (periodicity of BFD RS). Nokia will trigger email

discussion on deciding the values for timer using [CB 180]

8 As in all other cases the UE performs random access for BFR on active BWP if RACH

resources are available, otherwise it falls back to initial BWP. On each BWP the same

prioritization rule is applied (CFRA and then CBRA).

在 SR 議題對於觸發和取消的條件再進行釐清，討論技術文件有四

篇：

R2-1801811 Discussion on immediate transmission Huawei, HiSilicon

discussion Rel-15 NR_newRAT-Core

R2-1802624 Issue of triggering SR when UL-SCH resources are available

for BSR and TP for TS38.321 Samsung R&D Institute UK discussion

R2-1802809 SR Triggering in NR InterDigital discussion Rel-15

NR_newRAT-Core

R2-1803207 On the immediate transmission Ericsson, Nokia, Nokia

Shanghai Bell discussion Rel-15 NR_newRAT-Core

因為實體層可以動態地排程傳輸區塊的時間，因此當一個傳輸區塊組

合完成，並不會立即傳送，而是依據排程的時間點，過一段區間後才傳送。

討論過程中有公司建議直接刪除立即傳送字句，也有公司建議不管任何條

24

件都會觸發 SR，高通表達不明確說明傳送傳輸區塊的時間點，但描述傳

輸區塊組合完成與傳送時間點的關係以規範 SR 的觸發條件。經過討論後

的決議為，含緩衝區狀態報告的傳輸區塊在組合完成一直到送出的這段期

間，若有 SR 且有上行資源可以傳送，就允許進行 SR 觸發。而當含緩衝區

狀態報告的傳輸區塊送出後，相對應的 SR 則會取消。最後決議如下：

=> We will not specify when the UE generates the MAC PDU

=> An SR may be transmitted during the period of MAC PDU scheduling and

transmission of BSR

=> An SR may/shall? be cancelled if at the time of transmission the BSR includes

the information of the logical channel that triggered the SR.

SPS 議題方面，在電子郵件討論中已確認，不論是動態授予的時槽聚

合，還是配置授予的重複傳送，皆視為混合型自動重傳請求 HARQ 的一次

重傳程序，會議中僅對標準文件如何修改的文句用語再做細部的修改和確

認，討論技術文件如下：

R2-1802212 Summary of [NR-AH1801#5][NR UP/MAC] Repetition aspects

Huawei, HiSilicon discussion Rel-15 38.321 NR_newRAT-Core

R2-1802213 TP for [NR-AH1801#5][NR UP/MAC] Repetition aspects

Huawei, HiSilicon discussion Rel-15 38.321 NR_newRAT-Core

修改內容包括以一綑傳送的傳輸機會描述，取代各別重複傳送的字句;

對非適應性傳送與適應性傳送的描述做刪除修正; 為了標準文件的整潔，

HARQ 不註解時槽聚合或重複傳送字眼，僅標示重傳條件等，最後產出技

術文件如下：

R2-1803859 TP for [NR-AH1801#5][NR UP/MAC] Repetition aspects

Huawei, HiSilicon discussion Decision

3. 新無線電技術(NR)–UE capability

在本次會議中，本團隊有一篇關於 UE capability 技術貢獻被處理，說明如

25

下：

R2-1803271 Discussion on agreements on UE capabilities for NR measurement HTC

Corporation discussion (Accepted)

Agreements

1 NR event A series measurement reporting is mandatory with IoT for a UE supporting

EN-DC.

2 NR periodical measurement reporting is mandatory with IoT for a UE supporting EN-DC.

這篇提案討論對於支援 EN-DC 功能的 UE，下列有關 NR 量測結果回報功

能是否為選擇性支援或必須支援的 UE capability：

(1) LTE event B series NR measurement reporting

(2) LTE periodic NR measurement reporting

(3) NR event A series measurement reporting

(4) NR periodic measurement reporting

本提案從以下兩個觀點切入，提案上述有關 NR 量測報告功能列為 UE 必

須支援的 UE capability：

a) LTE eNB 為了設定 UE 進行 EN-DC 模式所需得到 UE 之量測結果；以及

b)進入 EN-DC模式後 NR gNB為了進行無線資源管理所需得到 UE之量測

結果

本提案提出七項提議，希望 RAN2 能夠採用：

Proposal 1: Event B1 NR measurement reporting in LTE connected is mandatory for a UE

supporting EN-DC.

Proposal 2: Periodical NR measurement reporting in LTE connected is mandatory for a UE

supporting EN-DC.

Proposal 3: Event B2 NR measurement reporting in LTE connected is mandatory for a UE

supporting EN-DC.

Proposal 4: There is no capability signaling for event B1, event B2 and periodical NR measurement

reportings in the UE-EUTRA-Capability.

Proposal 5: NR event A series measurement reporting is mandatory for a UE supporting EN-DC.

Proposal 6: NR periodical measurement reporting is mandatory for a UE supporting EN-DC.

Proposal 7: There is no capability signaling for NR event A series measurement reporting and NR

periodical reporting in the UE-NR-Capability.

經過討論，R2-1803217 中的 Proposals 5-6 於會議中被接受，唯 Proposal 7

26

在討論時少數公司希望有 IOT bits，因此未被接受。最後決議請見上述

agreements 1-2。此外，Proposal 4 於討論技術貢獻 R2-1803932 時被接受，詳情

請見底下敘述。

這次會議也進行其他 UE capability 的議題討論，底下為相關討論文件與決

議。

關於 UE capability 的電子郵件討論

R2-1803932 Email disc. on [NR-AH1801#10][NR] UE Capabilities (Intel) Intel Corporation

report Rel-15 NR_newRAT-Core Late

Agreements

1 No new L2/3 capability is introduced for skipUplinkTxConfiguredGrant. It will be

conditional mandatory if the UE supports Configured Grant.

2 No new L2/3 capability is introduced for dedicated bearer on split DRB.

3 For EN-DC, 8 bearers can be supported regardless of bearer types.

FFS: Need of capability/IOT signaling in LTE for support of the additional measurement gap

configurations defined for Rel15 ? Whether it is separate for TDD/FDD also needs to be

discussed (To be checked whether the NR measurements can be performed with the legacy gap

patterns).

4 Capability/IOT signaling for non-default bearer on SCG is removed

5 Capability for multipleSR-Configurations is an ENUMERATED {supported} and if

supported UE supports 8 SR configurations, otherwise 1 SR config is supported

FFS: Whether to align the number to what the configuration signalling can support.

6 Capability for multipleConfiguredGrantConfigurations is an ENUMERATED {supported}

and if supported UE supports 16 configured grant configurations, otherwise 1 ConfiguredGrant

config is supported

FFS: Whether to align the number to what the configuration signalling can support, and to

consider whether the 16 refers to the configurations or the active ones only (as they are within the

BWP).

7 Capability/IOT signaling for directSN-Addition is removed and it becomes mandatory w/o

IOT bit.

8 Capability/IOT signaling for split DRB with UL data TX on only MCG or only SCG is

removed and it becomes mandatory w/o IOT bit.

9 The following L2/3 capabilities are defined as mandatory with IOT bit:

- longDRX-Cycle, shortDRX-Cycle, amWithShortSN, umWithShortSN, umWIthLongSN,

shortSN*, , intraAndInterF-MeasAndReport*, eventA-MeasAndReport*,

27

10 The following L2/3 capabilities are defined as optional:

- multipleSR-Configurations, multipleConfiguredGrantConfigurations, supportedROHC-Profiles,

maxNumberROHC-ContextSessions, uplinkOnlyROHC-Profiles, continueROHC-Context,

independentGapConfig

11 dataRateDRB-IP is removed from the March freeze of ASN.1

12 NR measurements & reporting (at least periodical reporting) in LTE connected mode*,

Measurement reporting event B1 for NR in LTE connected* are mandatory without IOT

13 The following L2/3 capabilities are defined as optional: lcp-Restriction, sstd-MeasType1

14 MultipleTimingAdvances for NR CA: Mandatory with IOT bit for inter-band NR CA;

otherwise optional

15 L2/3 capabilities with signalling that are not yet defined as mandatory with IOT or optional

should be further discussed as part of a RAN plenary discussion.

16 FDD/TDD separation is needed for volteOverNR-PDCP (LTE capability signalling)

17 Split DRB with UL TX on both MCG and SCG are signalled as UE-MRDC-Capability.

技術貢獻 R2-1803932 提議將“NR measurements & reporting (at least

periodical reporting) in LTE connected mode”與“Measurement reporting event B1

for NR in LTE connected”列為 mandatory with IOT bits，此與 HTC 技術貢獻

R2-1803271 中的 Proposal 4 不同。底下為節錄自技術貢獻 R2-1803932 結論章

節：

9) The following L2/3 capabilities are defined as mandatory with IOT bit:

- longDRX-Cycle, shortDRX-Cycle, amWithShortSN, umWithShortSN, umWIthLongSN, shortSN*, NR

measurements & reporting (at least periodical reporting) in LTE connected mode*, Measurement reporting event B1 for

NR in LTE connected*, intraAndInterF-MeasAndReport*, eventA-MeasAndReport*, Split DRB (with NR PDCP) with UL

TX on MCG or SCG*

Note*: Number of companies proposed to change it to be mandatory w/o IOT bit and there was no consensus.

However there was consensus it is mandatory.

於會議中討論技術貢獻 R2-1803932 時，本團隊成員透過率先舉手發言，

引起其他公司注意與覆議認同，改變技術貢獻 R2-1803932 原本的提議內容，

使得會議決議“ NR measurements & reporting (at least periodical reporting) in LTE

connected mode”與“Measurement reporting event B1 for NR in LTE connected”兩

28

種功能列為 mandatory without IOT bits（如上述的 agreement 12），也就是 UE

必須支援此兩種功能而且無需針對此兩種功能定義 IOT bits，此決議與

R2-1803271 的 Proposal 4 相同。

有關 SRB3 的 UE capability 的議題討論：

R2-1803151 Covering note for SRB3 Nokia, Nokia Shanghai Bell, NTT DOCOMO INC.,

Deutsche Telekom AG, MediaTek Inc., Interdigital LLC, Vodafone GmbH, CATT, AT&T,

Verizon Wireless discussion Rel-15 NR_newRAT

Agreements

1 Capability/IOT bit is added for SRB3 (no conclusion on mandatory with IOT or optional)

提案公司希望將支援 SRB3 列為必要的 UE capability，但是與會的某些公

司不同意，因此最後決議為將此 UE capability 以 capability 或是 IOT bit 的方式

來通知 gNB 是否支援。

七、心得與建議

心得

由於 NR 在本次會議之前開始討論關於獨立運作的設計，因此在本次

會期之中與 Idle mode 以及存取控制機制相關的 NR 設計已經開始進

行討論。而在演進版通用陸地無線接取網路-新無線電技術雙連結

(EN-DC)的部分，大部分的程序已經完備，而在 NR的量測回報配置、

量測配置則是討論相較比較細節的程序部分。NR 基本 Handover 程

序設計完成之後，如何達成0ms的需求以及如何引進條件式Handover

都是我們在未來需要持續關注的部份。這次會期很多時間花在抽象語

法符號(ASN.1)確認上，甚至也開了一個平行議程來討論，勢必要在

這次會期將 ASN.1 完成，因此可以看到整個 NR 的輪廓跟細節了。

在用戶平面的討論大部分是標準文件的最後確認修改，但仍有一些有

趣的議題可以關注，例如邏輯通道優先權的設計，是否會對上層的傳

輸控制協定產生影響，BFR 在 RAN2 與 RAN1 的整合設計等，都值

得繼續關注。

29

此次會議處理了許多標準細節討論與修正，於本次會議後將完成

EN-DC 功能的 NR 標準規格。然而礙於會議時間有限，此 NR 標準

規格可說是在匆促中完成，很有可能仍有少數錯誤存在。

此次會議已有比較多有關 NR 獨立運作功能的討論，下次會議相關功

能的議題將會是討論重點。

建議

建議詳細研讀此 NR 標準規格，從中找出錯誤，提出更正 CR 的技術

貢獻，可增加技術貢獻被處理的機會。

針對 NR 獨立運作建議提案內容除了提議外，還要附上與提議相符的

規格書章節內容或是直接提出 CR 的技術貢獻，增加被處理的機會。

由於目前 NR 討論的議題相當繁多，各家公司與廠商都視其為一個未

來佈局的機會，所以眾多相當細節與意見都被提出，在會場討論的氣

氛都相當熱烈與相對激烈，不僅議程短，議題多，平行議程多，如果

可以更多的人來投入參加會議，應該可以得到比較多的訊息。