3gpp ran2 #97bis 會議報告

41
會議報告(會議類別:其他) 3GPP RAN2 #97bis 會議報告 出席人員:陳宏鎮、陳俊嘉、鄭靜紋、陳德鳴、吳志祥、楊豐銘 派赴地區:美國/斯波坎 會議期間:106 04 03 日至 106 04 07 報告日期:106 5 15

Upload: others

Post on 16-Oct-2021

1 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: 3GPP RAN2 #97bis 會議報告

會議報告(會議類別:其他)

3GPP RAN2 #97bis 會議報告

出席人員:陳宏鎮、陳俊嘉、鄭靜紋、陳德鳴、吳志祥、楊豐銘

派赴地區:美國/斯波坎

會議期間:106 年 04 月 03 日至 106 年 04 月 07 日

報告日期:106 年 5 月 15 日

Page 2: 3GPP RAN2 #97bis 會議報告

2

摘 要

本次 3GPP RAN2#97bis 會議於美國華盛頓州的斯波坎舉行,本計畫團隊

依規劃有 3 位成員出席,參與 3GPP R15 的標準制定,其中以 NR 的工作項目

為主,本計畫團隊著重在 CP 與 UP 之各個議題;在會議期間表達我方之意見

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

議題之立場與看法。

本次會議針對 NR 議題中 RAN2 負責的新標準規格書,確認 rapporteur 人

選以及新規格書的架構。NR 初期優先考慮 non-standalone 布建,NR 與 LTE 會

以 DC 方式互動,所以相關議題則優先討論。另一重點是 beamforming 技術引

發的波束偵測、量測、傳輸等議題,但因為這些議題與 RAN1 的決議息息相關,

所以需要 RAN1 與 RAN2 密切合作。

為了能在 2018 年產生第一個可實施的 5G 規範,本次會議不僅對 NR 的各

項議題討論區分優先順序,且自星期三開始將 CP 與 UP 相關議題分開討論,

以兩個平行的議程同時進行;因為平行議程的增加,建議研擬投入 5G 開發或

派員參加 3GPP RAN2 會議的公司需要把人員與議題都列入考量。

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

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

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

5th Generation Mobile Communication 5G 第五代行動通訊系統

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

Acknowledgement mode AM 確認模式

Automatic Retransmission Request ARQ 自動重傳請求

beam

波束

beamforming

波束成型

Bearer

載體

Buffer Status Report BSR 緩衝區狀態回報

Cell Group

細胞群

cell quality 細胞訊號品質

Change Request CR 修正要求

Channel State Information-Reference

Signals CSI-RS 通道狀態資訊參考訊號

Page 3: 3GPP RAN2 #97bis 會議報告

3

CONNECTED Mode

連線模式

Control Element CE 控制元件

Control Plane CP 控制平面

core network CN 核心網路

Criteria

準則

Data Radio Bearer DRB 數據連線載體

Dual Connectivity DC 雙連結

eNB

基地台

Enhanced LTE-WLAN Aggregation eLWA 增強型 LTE 與無線區域

網路聚合

Enhanced Machine Type

Communications eMTC 強型機器類通信

Enhancements of Dedicated

Core Networks selection mechanism eDECOR 增強型核心網路選擇機制

filter

過濾器

First Missing COUNT FMC 第一個遺失計數

First Missing Sequence FMS 第一個遺失序號

Further Enhanced MTC for LTE FeMTC 進階增強型機器類通信

handover HO 換手

Header

標頭

Identity ID 識別

IDLE mode

閒置模式

IDLE Reference Signal IDLE RS 閒置狀態參考訊號

INACTIVE mode

非活躍模式

inter-cell

跨細胞

layer 1 L1 第一層

layer 3 L3 第三層

Light Connection 輕量連結

logical channel 邏輯通道

logical channel group LCG 邏輯通道群組

logical channel group identity LCG ID 邏輯通道群組識別

logical channel identity LCID 邏輯通道識別

Long Term Evolution LTE 長程演進技術

LTE-NR Dual Connectivity EN-DC 長程演進技術與新無線電

技術雙連結

Master Cell Group MCG 主細胞群

Page 4: 3GPP RAN2 #97bis 會議報告

4

Master Cell Group split bearer MCG split

bearer 主細胞群分流載體

Master eNB MeNB 主基地台

Master gNB MgNB 新世代主基地台

Master Node MN 主節點

MCG Split SRB

分流主細胞群訊號無線載

Measurement Object

量測物件

Medium Access Control MAC 媒體存取控制

Medium Access Control Control Element MAC CE 媒體存取控制之控制元件

Message 1 Msg1 第一訊息

Message 3 Msg3 第三訊息

Minimum System Information Minimum SI 基礎系統資訊

Multiple beams

多波束

Narrowband IoT NB-IoT 窄頻段物聯網

New Generation NB gNB 新世代基地台

New Radio NR 新無線電

New Radio Technology NR 新無線電技術

New Radio Technology Secondary

Synchronization Signal NR-SSS

新無線電技術次要同步訊

Non Access Stratum NAS 非存取層

Non-Standalone

非獨立運作

Numerology 實體層參數

On-demand System Information On-demand SI 隨選系統資訊

Other System Information Other SI 其他系統資訊

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

Packet Data Unit PDU 封包數據單元

Packet Data Unit session PDU session 封包數據單元會談

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

Preamble

前置符元

Quality of Service QoS 服務品質

Quality of Service flow QoS flow 服務品質流

Quality of Service flow identify QoS flow ID 服務品質流識別碼

Quality of Service marking QoS marking 服務品質印記

Radio Link Control RLC 無線鏈路控制

Radio Link Failure RLF 無線鏈路故障

Page 5: 3GPP RAN2 #97bis 會議報告

5

Radio Resource Control RRC 無線資源控制

Radio Resource Management RRM 無線電資源管理

RAN1

無線存取網路第 1 工作組

RAN2

無線存取網路第 2 工作組

rapporteur 主筆

Reference Signal Received Power RSRP 參考信號接收功率

Reference Signal Received Quality RSRQ 參考信號接收品質

Release 14 R14 第 14 版

Release 15 R15 第 15 版

Scheduling Information

排程資訊

Secondary Cell Group SCG 次細胞群

Secondary Cell Group split bearer SCG split

bearer 次細胞群分流載體

Secondary eNB SeNB 次基地台

Secondary gNB SgNB 新世代次基地台

Secondary Node SN 次節點

segmentation 分割

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

Service Data Unit SDU 服務數據單元

Serving cell

服務細胞

Signaling Radio Bearer SRB 訊號無線載體

Split SCG SRB

分流次細胞群訊號無線載

subheader 次標頭

Synchronization Signal SS 同步訊號

Synchronization Signal block SS block 同步訊號區塊

system architecture SA 系統架構

system architecture WG2 SA2 系統架構第 2 工作組

System Information SI 系統資訊

threshold 臨界值

Transmission Time Interval TTI 傳輸時間區間

Ultra Reliable and Low Latency

Communication URLLC 超高可靠性與低延遲通訊

Unacknowledgement mode UM 非確認模式

User Equipment UE 用戶設備

User plane UP 用戶平面

Page 6: 3GPP RAN2 #97bis 會議報告

6

技術貢獻:

在這次會議,本計畫團隊在 RAN2 會議上提出了 15 篇技術貢獻、會前信

件討論、以及 CR 提案等,其中 9 篇 CR 提案被大會接受,相關的主題包括

eDECOR、NB-IoT、eLWA、DC、以及 eMTC 等.

會議解說:

本次 3GPP TSG RAN2 #79b 會議於美國斯波坎舉行,在上次 RAN Plenary

決定這次會議將專注在 R14 的修正及 ANS.1 的檢閱,因此沒有新的 R15 的工

作項目,新的 R15 工作項目將會在 5 月會議開始。除了 Light Connection 這個

工作項目之外,所有 RAN2 相關的 Rel-14 工作項目都已完成,Light connection

目前的 CR 被延遲到 R15 以配合 SA 群組同意一項新的研究項目有關 CN 方面

研究.

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

在 UP 來說,主要分成 QoS、PDCP、RLC、MAC 四層,所以這邊的討論主

要是從這四層的功能分別去討論:

服務品質(QoS)

這部分主要關注的是上下行封包是否需要攜帶 QoS flow ID,會議決

議上行的部分由網路端配置決定;下行的部分,目前只決定在上行封包的

QoS flow ID如果由網路端配置,則可以不需要下行封包攜帶QoS flow ID,

其他情況則需要進一步討論。

分封數據匯聚協定(PDCP)

這個部分主要關注的是 PDCP 層是否要支援重傳機制與排序功能,會

議上討論在 DC 和 HO 情況下是需要支援重傳的機制,至於其他情況,則

需要進一步討論;至於排序功能,考慮很多應用服務如果有排序可能會造

成延遲,所以決定這個排序功能是可以關閉的。

Page 7: 3GPP RAN2 #97bis 會議報告

7

無線鏈路控制(RLC)

我們關注的是 RLC 層是否可以動態的去關閉 segmentation 功能,但是

會場上,大部分公司主張不需要,但是我們認為有些情況關閉 segmentation

功能是有好處的,所以會場的結論是以永遠開啟 segmentation功能為基礎,

再考慮其他情況是否有需要動態去關閉 segmentation 功能。

媒體存取控制(MAC)

這邊我們關注的是 MAC 層的 PDU 組成排序,PDU 的組成包含

subheader、SDU、MAC CE,主要考量是 MAC CE 的位置,最後會議結論

是:上行的 MAC CE 都放在 PDU 的最後位置,允許可以從 PDU 的後面開

始處理封包,但是對於下行的 MAC CE 位置,意見還是分期,所以這個部

分下個會期會繼續討論。

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

本次會期是 NR 工作項目的第一次會期討論,由於在本年度結束前必須

要優先完成 Non-Standalone 的相關議題,也就是 EN-DC 下的各種信令程序

要如何運作,相關的程序包括了次節點(SN)變更程序、RRC 訊息的故障處

置、SRB 的類型與設定與 RLF 處理機制等。在次節點變更程序方面,容許

MeNB 能夠發起次節點變更程序,而當 SeNB 發起次節點變更程序時,MeNB

能夠接受或是拒絕這個程序,同時也能夠根據本身所得到的量測報告結果選

擇另外一個次節點來變更,且 MeNB 無法從 SeNB 處取得任何與 NR 相關的

量測結果。在 RRC 訊息的故障處置方面,則是同意當從 MeNB 收到 RRC

訊息時,不論此 RRC 訊息包含了 MeNB 或是 SeNB 的設定,只要發生了 RRC

訊息的故障,一律都會啟動無線連線重建機制。在 SRB 方面,則是排除了

Split SCG SRB 的引入,而 SCG SRB 則是由 SeNB 決定並設定之,為了因應

MCG Split SRB 的存在,LTE 的 PDCP 層必須要有對之進行重覆封包檢測與

捨棄之功能。在 RLF 的處理機制方面,當用戶設備偵測到 MCG 的 RLF 時,

將會啟動無線連線重建機制,而當用戶設備偵測到 SCG 的 RLF 時,則是會

暫停資料的傳輸並且將故障的原因回報給 MeNB 知悉。RRM 方面, UE 可

Page 8: 3GPP RAN2 #97bis 會議報告

8

量測 CSI-RS 以評估 cell quality;對於以波束成型技術收送訊號的細胞,用

戶終端須根據多個波束的量測結果評估 cell quality。

NR 獨立運作的相關議題仍以 SI 為要,本會期討論 On-demand SI 的方式,

達成協議為:網路端可控制用戶設備以隨機存取程序的 Msg1 或 Msg3 向網

路端發送 SI 要求。

3. 新規範的 rapporteur

38.300 (Stage 2) - Benoist Sebire (Nokia)

38.304 (Idle mode) - Ozcan Ozturk (Qualcomm)

38.306 (UE capabilities) - Kyeongin Jeong (Intel)

38.321 (MAC) - Jaehyuk Jang (Samsung)

38.322 (RLC) - Pavan Nuggehalli (MediaTek)

38.323 (PDCP) - SeungJune Yi (LGE)

38.331 (RRC) - Kai-Erik Sunell (Ericsson)

37.3xx (New QoS layer) - Hao Bi (Huawei)

37.340 (New stage 2 DC/MC) - Sergio Parolari (ZTE)

Page 9: 3GPP RAN2 #97bis 會議報告

9

目 錄

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

一、會議名稱 .................................................................................. 10

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

三、會議時間 .................................................................................. 10

四、會議地點 .................................................................................. 10

五、會議議程 .................................................................................. 10

六、會議紀要 .................................................................................. 12

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

Page 10: 3GPP RAN2 #97bis 會議報告

10

一、會議名稱

3GPP RAN2 #97bis

二、參加會議目的及效益

參與 NB-IoT、eLWA、NR 等議題之討論及尋找具前瞻特性之研究

題目。

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

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

流。

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

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

開展未來合作機會。

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

探詢未來啟動新 SI 的可能

三、會議時間

3rd – 7th April, 2017

四、會議地點

Spokane, USA

五、會議議程

本次 3GPP RAN2 #97bis 會議議程如下:

Schedule Main room

300A/B

Breakout room 1

300C/D

Breakout room 2

303AB

ASN.1 Breakout

room

301

UMTS room

303A

Monday

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

[6] Rel12 and earlier

11:00 -> [8.2] R14 V2V [11][12] UMTS

Page 11: 3GPP RAN2 #97bis 會議報告

11

[7] Rel-13 and earlier

(not eMTC/NB-IoT)

[8.5] R14 eLWA

[8.15] R14 meas gap

[8.25] TEI14

[18] Outgoing LSs

(Diana)

Rel-8/9/10/11/12

[13] UMTS Rel-13

[14.1] RRC opt

[14.2] DTX/DRX

[14.3] MC

[14.4] QoE

[14.5] TEI14

14:30 -> NR [2]

Stage 2 and common

CP/UP issues

[10.1] Org

[10.2.1] Stage 2 TSs

[10.2.2, apart from

10.2.2.3] NSA

[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

[9.2] R15 sTTI [0.5]

(Diana)

17:00 ->

Tuesday

08:30 -> NR [4]

Stage 2 and common

CP/UP issues

Continue Monday NR

schedule

[10.2.3, apart from

10.2.3.1] NSA/SA

common

[10.2.4, apart from

10.2.4.3] SA

[7.4] Rel-13 NB-IoT

[7.3] Rel-13 eMTC

[8.11] R14 NB-IoT

[8.12] R14 feMTC

[4] (Johan)

[8.13] R14 V2X

(Diana)

[14.6] ASN.1

review

11:00 ->

14:30 -> [9.1] R15 feD2D

[2] (Diana)

17:00 ->

Wednesday

08:30 -> NR [4]

Stage 2 and common

CP/UP issues

[10.2.2.3] NSA UP

[10.2.3.1] SA UP

[8.26] Rel-14 ASN.1

review

[4] (TBD)

Potential NR

break out (but not

fully clear at what

stage of the week

we will be ready

[15.1] DL int mit [1]

[15.2] SI sched enh

[1]

Comebacks

11:00 ->

14:30 ->

17:00 ->

Page 12: 3GPP RAN2 #97bis 會議報告

12

[10.2.4.3] QoS

[10.3.1.1] MAC TS

[10.3.2.1] RLC TS

[10.3.3.1] PDCP TS

[10.3.4.1] QoS TS

[10.4.1] RRC TS

Continue Tuesday NR

schedule

NOTE 1

to break into NR

parallel streams)

Thursday

08:30 -> NR [4]

Stage 3 CP

[10.4]

[9.3] Rel-15 UDC [2]

(Hu Nan)

NR break out

Stage 3 UP

[10.3]

[8.26] Rel-14

ASN.1 review

(Kai-Eric)

11:00 ->

14:30 -> [8.6] R14 eMob

[8.10] R14 feMBMS

[8.18] R14 eVolte

(Hu Nan)

[8.26] Rel-14 ASN.1

review

(Kai-Eric), if required

17:00 ->

Friday

08:30 ->

until 17:00

Comebacks

LTE Comebacks (if

separate LTE

comeback sessions is

needed)

六、會議紀要

1. 新無線電技術(NR)–獨立運作議題

R2-1703252 NR+NR DC : QOS architecture Samsung Telecommunications

discussion

本篇提案重點提出 DC 結構下對於 QoS 之影響,RAN2#96 會期的共識對

於單連線架構下,PDU session 可以對應一個或一個以上的 DRB,如下圖,若

Page 13: 3GPP RAN2 #97bis 會議報告

13

考量 NR 架構下的 DC 連接方式,整筆的 PDU session 若從原先 NR MgNB 切換

到 SgNB 將會產生問題,例如當 MgNB 的固網通道可能需要保留原有的 QoS

Flow,但因為其他的 QoS Flow 切換到 SgNB,而原有 QOS flow 也會強制被切

換到 SgNB,造成 PDU session 與 DRB 對應上的錯亂。

NR + NR DC QOS architecture (Option 1)

對此本篇提案提出解決方案,如下圖,MgNB 可以詢問後端網路,於相同

的 PDU session 平行式啟動兩條後端網路通道,允許 QoS Flow可以在 MgNB 與

SgNB 之間切換。然而,PDU session 與 DRB 對應將會更有彈性。

Page 14: 3GPP RAN2 #97bis 會議報告

14

NR + NR DC QOS architecture (Option 2)

RAN2 同意無線存取技術架構下的 DC 連接方式,相同的 PDU session 允許

QOS flow 可以在 NR 的 MeNB 與 SeNB 之間切換,而先前討論的 SDAP 層則放

在 MgNB 的 PDCP 層之上。

R2-1703431 Stage 2 message flows for 5G QoS Intel Corporation discussion

Rel-15 NR_newRAT-Core

本篇提案基於 TS 23.501 A-type 與 B-type QoS flow,提出四種 QoS 流程程

序欲寫入 TS 38.300。

1. PDU session 建立

CN 藉由 NAS 訊息傳送 DRB 相關資訊給 UE 以建立 DRB,再回報

CN 建立 PDU session,資料 QoS 標頭存放 QoS flow ID,使用 QoS

marking 的方式提供給傳收端。

2. 經由相同 DRB 傳遞新的 QoS flow

同上 PDU session 使用 QoS marking 的方式,同一 DRB 內若需要不

同 QoS flows 傳送,CN 可提供 QoS flow ID 給傳收端。

Page 15: 3GPP RAN2 #97bis 會議報告

15

3. 結合上述兩種方式

採用 NAS 訊息通知 QoS flow ID 給傳收端,建立 PDU session 通道

和 DRB 連線。

4. 由 UE 啟動上行 QoS flow

對於上行資料,UE 可以自行提供 QoS flow ID 給 CN,爾後建立 DRB

連線。

最後大會決議將 QoS flow 訊息相關的細節,交付後續於信件討論。

R2-1702755 RAN aspects of QoS parameters Ericsson discussion Rel-15

NR_newRAT-Core

本篇提案列出 NR 的 QoS 框架有別於 LTE 版的差異如下:

1. 多個 QoS flows 對應單 Tunnel 傳送;服務品質流識別(QoS flows ID)

可定義在封包的標頭內。

2. 服務品質參數與 5G級別指標(5G Identifier, 5GI)用來定義服務品質流,

且會依照 TS 23.203 服務品質級別指標(QoS Class Identifier, QCI)的設

計法。

3. 新增 Notification control 欄位功能,主要為 gNB 通知 Session

Management Function (SMF)是否 QoS flow 滿足需求。

針對上述的條件下,封包延遲要求對於 URLLC 高需求的流量是沒有辦法

滿足 2%延遲容忍度,可考慮忽略 MAC 層 HARQ 和 RLC 層 ARQ 的重傳方式。

在網絡擁擠的情況下, 非保證速率承載需要承受降低速率的要求,無法

佔用固定的資源,但存在無法滿足最小傳送量,故有需要考慮預設最小傳送量

的方式。

以上討論 RAN2 還需要和 SA2 作更細節的討論。

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

Page 16: 3GPP RAN2 #97bis 會議報告

16

本次會議對於 UP 討論非常多,結論是除非必要更改,否則大多數都是

以沿用 LTE 技術為基礎。以下針對 UP 的 QoS、PDCP、RLC、MAC 等,分

層摘錄重要的結論:

服務品質(QoS)

R2-1702793 New AS layer PDU design Ericsson discussion

Rel-15 NR_newRAT-Core

在 NR 引進了新的封包服務品質機制,因此在 PDCP 上層新增了一

QoS 層(該層正式名稱為 SDAP),此篇提出了三個提案:

Proposal 1 New AS layer PDU is PDCP SDU

Proposal 2 AS layer header include the Flow ID in depending on

network configuration

Proposal 3 AS layer header is byte-aligned

提案一與提案三在會議上沒有甚麼異議;因為提案一基於架構,本

該如此;提案三基本上也是符合目前 LTE 的設計,所以重點則著重

在提案二,但是因為在下行與上行的 QoS Flow ID 用途並不相同,

所以應該要分開討論,並不完全都是靠網路配置。

R2-1702525 Discussion on the Inclusion of QoS Flow ID over Uu

TCL Communication Ltd. discussion FS_NR_newRAT

針對 cell quality 的部分,主席接著討論上述這一篇,因為下行的 cell

quality 是用來做上行 cell quality 的對應,所以如果上行 cell quality

沒有使用下行 cell quality 的對應,下行 cell quality 則沒有存在的需

要。但是對於上行 cell quality 是否需要存在,則可以根據網路的配

置來決定是否需要攜帶。針對這個議題,會議決議如下:

Agreements on QoS layer:

- New AS layer PDU is PDCP SDU

- AS layer header is byte-aligned

- DL packets over Uu are not marked with “Flow ID” at least for cases where UL AS reflective

mapping and NAS reflective QoS is not configured for DRB.

Page 17: 3GPP RAN2 #97bis 會議報告

17

- AS layer header include the UL “Flow ID” depending on network configuration

R2-1703145 Discussion on omitting QoS flow ID ITRI, MediaTek

Inc.

本計畫團隊在這一篇文稿中,提到有些情況是可以省略攜帶 QoS

flow ID,例如:上行的一個 DRB 只包含一個 QoS flow,這時在網

路端並不需要靠 cell quality 來辨識傳送路徑;下行來說,如果上行

cell quality 沒有使用下行 cell quality 的對應,下行 cell quality 則沒

有存在的需要,這一點與會議結論第三點一致;另外,我們也提到

下行的 cell quality 並不需要一直存在,因為只有更換 QoS flow 所在

的 DRB 才需要告知用戶設備 (UE) 端,用戶設備端再依據更換的

結果來更新上行端的 QoS flow 與 DRB 的配對。這個部分在會議上

尚未討論,未來,本計畫團隊可以再進一步針對這一點提案。

分封數據匯聚協定(PDCP)

R2-1703516 PDCP ARQ LG Electronics Inc. discussion Rel-15

NR_newRAT-Core

這一篇討論是否 PDCP 層也需要支援 ARQ,會場上有公司質疑,為

什麼 RLC 層有 ARQ 機制,PDCP 層還需要同樣的機制?LG 指出這

個 ARQ 機制與 RLC 層的 ARQ 不一樣,目前 DC 架構已經存在同

樣的機制,主要是針對 DC架構下,不同路徑造成的數據封包遺失,

希望可以重傳。會議上公司對於使用的情境有所保留,但是至少對

於 HO 時與 DC 架構下,PDCP 層至少可以支援資料重傳根據 PDCP

層的狀態回報,所以會議的結論如下:

Agreements on PDCP recovery

=> Some PDCP recovery mechanism based of PDCP status report is supported at least for the

handover case and DC. FFS if there are other cases in which this may be performed.

R2-1703435 PDCP reordering in NR Intel Corporation discussion

Rel-15 NR_newRAT-Core

在 NR 的架構下,封包的排序功能已經放到 PDCP 層來做,這一篇

Page 18: 3GPP RAN2 #97bis 會議報告

18

討論只要是針對 DRB、SRB、UM、AM 下,希望可以有一套排序

的方式就好,不要因為不同的情況,有不同的排序機制,會議結論

也是達成單一機制的決議。另一個議題是是否這個排序的機制可以

關閉,因為針對有些應用,排序機制可能會造成延遲,所以不需要

排序這個功能,因此也決議對於排序功能需要有關閉的功能。另一

個跟 LTE 的 PDCP 層比較不一樣的是 NR 在 PDCP 狀態回報中攜帶

的是 FMC,而不是 LTE PDCP 狀態回報的 FMS,在 NR 的設計中,

因為資料量大,且想要避免會有序號重複的問題,所以改用計數來

代表其序號。相關的會議結論如下:

Agreements on PDCP reordering

- A unified re-ordering schemes is used for DRB(s)/SRB(s) and UM and AM, with LTE as

baseline.

- It is desirable to disable PDCP reordering. FFS how to signal it

- Use First Missing COUNT (FMC) instead of FMS in the PDCP Status Report.

無線鏈路控制(RLC)

R2-1702646 Email discussion report on SO segmentation NTT

DOCOMO INC., Nokia, Samsung, NEC, MediaTek, Intel, LG, ZTE, KT,

Ericsson, OPPO, Panasonic, III, ITRI, vivo, Fujitsu, CATT, Huawei,

HiSilicon, Lenovo, Qualcomm, Sequans, NTT DOCOMO report

Rel-15 NR_newRAT-Core

這一篇提案主要是透過電子郵件的方式來進行討論,大部分的結論

都變成了會議決議,公司間也沒有太大的歧見,也與本計畫團隊的

立場大部分都一致,其中比較有爭議的是:RLC AM 是否都需要支

持 segmentation 的功能?在電子郵件討論過程中,只有 ITRI 贊成

segmentation 的功能可以視情況開啟或者關閉,有些公司則持保留

的態度,但在會議上,有 Intel、Qualcomm、OPPO 等公司出來表示

支持 segmentation 的功能可以開啟或者是關閉,但是大部分公司還

是覺得基本上應該都要開啟,因此決議基本上 segmentation 的功能

Page 19: 3GPP RAN2 #97bis 會議報告

19

都需要開啟,但是可以進一步研究有哪些情況是可以關閉的;會議

的決議如下:

Agreements RLC segmentation:

- As a baseline, segmentation is always enabled for RLC-AM and RLC-UM. FFS if there are

cases in which it is beneficial to disable segmentation

- An RLC SDU for UM and AM can be associated with only one RLC SN, i.e., the byte

segments from an RLC SDU can be associated with the same RLC SN.

- Segmentation and re-segmentation is based on RLC SDU, i.e., SO field indicates byte

position of the RLC SDU

- RLC header is to be designed in following principles:

- RLC header indicates if RLC PDU carries a complete RLC SDU or RLC SDU segments.

- RLC header does not include SO field if RLC PDU carries a complete RLC SDU.

- RLC header does not include SO field when the beginning of the RLC SDU is segmented.

- RLC header includes SO field when the middle or end of the RLC SDU is segmented.

- RLC header indicates whether the RLC PDU contains the end part of RLC SDU segment or

not when the middle or end of the RLC SDU is segmented.

媒體存取控制(MAC)

R2-1702899 MAC PDU encoding principles Nokia, Alcatel-Lucent

Shanghai Bell discussion Rel-15 NR_newRAT

R2-1702759 Remaining issues on MAC control element HTC

Corporation discussion Rel-14

R2-1702597 MAC PDU Format Huawei, HiSilicon discussion

Rel-15 NR_newRAT-Core

R2-1703511 Placement of MAC CEs in the MAC PDU LG Electronics

Inc. discussion Rel-15 NR_newRAT-Core

以上幾篇提案都是針對 MAC 層的 PDU 組成排序作建議,PDU 的

組成包含 subheader、SDU、以及 MAC CE,排序的主要考量包含:

Page 20: 3GPP RAN2 #97bis 會議報告

20

在用戶設備的傳送端希望可以預先組成部分的 PDU,以加快處理的

速度。在基地台與用戶設備端,希望可以提早處理 MAC CE,以加

快處理相關的控制訊號。考量以上的因素,結論是:subheader 都放

在相對應的 SDU 前面,上行的 MAC CE 都放在 PDU 的最後位置,

允許可以從 PDU 的後面開始處理封包,但是對於下行的 MAC CE

位置,有公司認為要跟上行一致,有公司認為應該要讓 UE 可以盡

快處理,所以應該要放在前面,所以這個部分下個會期會繼續討論;

會議的相關結論如下:

Agreements on MAC PDU format:

- MAC SDUs, MAC subheaders, and MAC PDU are byte aligned (i.e., multiple of 8 bits).

- MAC subheaders are placed immediately in front of the corresponding MAC SDUs, MAC

CEs, or padding. The possibility to parse the MAC PDU from the back is not precluded.

- MAC CEs are grouped together

- UL MAC CE(s) is placed after all the MAC SDUs. For DL the placement will be

deterministic (i.e. it should not be up to the network to decide). FFS if we have the same

behaviour for both or for DL the MAC CE is placed at the front

R2-1702667 E-mail discussion report [97#62] Ericsson (rapporteur) discussion Rel-15

NR_newRAT-Core

本篇綜合前兩次會期的提案一起作討論,非別針對 gNB 需新增以下訊息為

考量:

1. 流量特徵:不同種類的需求流量,考慮排程請求結構與 BSR 回報方式

可否針對需求流量種類 UE 提出請求與回報。

2. Logical channel/LCG:不同種類的需求流量可否考慮有所屬特定的

LCG ID 與 LCID。

3. 可傳資料總量:主要是針對排程請求結構下,是否夾帶可傳資料總量

來降低 BSR 回報的複雜程度,更進一步提升加快上行資料傳輸。

Page 21: 3GPP RAN2 #97bis 會議報告

21

4. Numerology/TTI 的相關資料: 主要是針對 BSR 回報下,對於 NR 不同

的與 Numerology 和 TTI 進行回報資料。

5. 資料優先權:不同種類的需求流量可存在不同優先權順序,故需要討

論針對的不同的資料優先權進行 BSR 回報,或可以藉由排程請求回報

區間來分辨資料優先權的方式。

RAN2 同意 NR 的排程請求需有區分 Numerology/TTI 之能力,而 BSR 回

報這一部分,以現存的 LTE 運作方式為基準,但回報的精細度由下次會期進行

討論。

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

本次會議在控制平面的部分主要聚焦於 EN-DC 下的各種信令程序要如何

運作,相關的程序包括了次節點(SN)變更程序、RRC 訊息的故障處置、SRB 的

類型與設定與 RLF 處理機制等。

次節點變更程序

R2-1703653 Discussion on secondary node change procedure Huawei,

HiSilicon discussion Rel-15 NR_newRAT-Core

華為的這篇技術貢獻認為過去在 LTE 的雙連結技術中,在載體型態

改變、安全金鑰更新以及在 MeNB 換手但是 SeNB 沒有改變的情境

之下,都會啟動次節點變更程序來完成之,所以在 LTE 與 NR 雙連

結下應該要延續這些原則,而且要由 MeNB 做最終是否要執行次節

點變更程序的決定,但是部分公司對於誰能夠決定下一個要替換的

次節點有不同的意見,MeNB 與 SeNB 是否都能夠取得運作 NR 的

頻率上的量測報告也可能與量測的設定相關,因此僅在與 LTE 的雙

連結技術中相關原則的部分達成共識:

Agreements:

1: The master node could initiate the intra-secondary node change for the following purposes: bearer

Page 22: 3GPP RAN2 #97bis 會議報告

22

type change, security key update, inter-MeNB handover without secondary node change.

R2-1703830 Summary on offline discussion 23 on secondary node

change Huawei, HiSilicon discussion Rel-15 NR_newRAT-Core

由華為負責的次節點變更程序相關討論,其結論於這篇技術提案中

呈現,結論包括了 LTE 的 MeNB 能夠量測到其他未被 SeNB 使用的

NR 頻率,但是如何協調 MeNB 與 SeNB 間的量測設定則有待後續

討論,當 SeNB 發起次節點變更程序時,MeNB 能夠接受或是拒絕

這個程序,同時也能夠根據本身所得到的量測報告結果選擇另外一

個次節點來變更,且 MeNB 無法從 SeNB 處取得任何與 NR 相關的

量測結果。基本上與會公司都同意 MeNB 能夠根據與目標節點間

Xx 介面是否存在以及其負載狀況來決定是否要同意次節點變更的

請求,然而 MeNB 與 SeNB 之間是否要有協調量測設定的程序或是

任何量測上的限制則沒有足夠的共識。根據討論的結果,主席做出

下列的決議:

Agreements:

1: On receiving the request for SN change, the master accepts/rejects (e.g. taking into account

available information, network connectivity, etc) whether to carry out the requested

inter-secondary nodes change (i.e. different Xx interface). The master may select a different

target node in different frequency for the SN change based on the NR inter-frequency

measurement maintained by master itself;

1a: MN can also trigger an inter-frequency the SN node change without any request from the SN.

2: Final RRC message for the inter-SN change will be generated from master node

3: SN does not provide the NR measurement results to the MN;

FFS: UE can be configured with MN NR measurement configuration and SN NR measurement

configuration on inter frequencies which are different from the serving frequencies used in SN.

UE cannot be configured with MN NR measurement configuration on the serving SN

Page 23: 3GPP RAN2 #97bis 會議報告

23

frequencies. (This does not preclude MN NR measurement configuration to include inter-freq

events that include the serving cell measurement)

FFS on how to coordinate the NR measurement configuration between MN and SN;

FFS how to allow the MN to perform inter-RAT measurement for potential handover to the serving SN

frequency.

R2-1703092 Control plane procedures for LTE and NR interworking

CATT discussion Rel-15

大唐的這篇技術貢獻則是認為當 SeNB 的 serving cell 改變時,即便

沒有涉及到 PDCP 層的改變與重建,也會因為需要與 MeNB 進行用

戶設備能力協調的需求而需要告之 MeNB。各公司對此看法表示認

同,因此主席做出下列的決議:

Agreements

1: The MN should be involved in the SN cell change without PDCP change at least in the case

where the UE capability coordination is required due to SN cell reconfiguration. (e.g. NR SCell

change may require UE capability coordination)

RRC 訊息的故障處置

R2-1703429 MCG SCG reconfiguration coordination and failure

handling Intel Corporation discussion Rel-15

NR_newRAT-Core

英特爾的這篇技術貢獻討論了RRC訊息的故障處置,首先一個RRC

訊息可能會同時包括了 MeNB 與 SeNB 的設定,其中一種可能就是

在進行完用戶設備能力協調的過程後,為了要確保協調後的 MeNB

與 SeNB 的設定能夠同時抵達用戶設備,所以將 MeNB 與 SeNB 的

設定包含在同一個RRC訊息,如果想要優化RRC訊息的故障處置,

將 MeNB 與 SeNB 的設定發生錯誤的情況分開處置,需要避免將與

用戶設備能力協調無關的 MeNB 與 SeNB 的設定放在同一個 RRC

Page 24: 3GPP RAN2 #97bis 會議報告

24

訊息或是利用一個位元來指示是哪一種情況導致 MeNB 與 SeNB 的

設定放在同一個 RRC 訊息的,考慮到 RRC 訊息的故障出現的機率

相當的低,這些優化都是不必要的,因此建議遵循過去 LTE 的處理

原則,不論此 RRC 訊息包含了 MeNB 或是 SeNB 的設定,只要發

生了 RRC 訊息的故障,一律都會啟動無線連線重建機制。反對方

的公司則認為應該要考量到服務中斷的問題,如果只是 SeNB 的設

定發生故障,不應該影響到 MeNB 的正常運作。由於支持遵循過去

LTE 的處理原則的公司稍佔多數,因此主席做出下列的決議:

Agreements

1: When both MCG and SCG reconfiguration is required due to coordination, the SCG

reconfiguration message must be encapsulated in an MCG RRC message that also carries the

corresponding MCG reconfiguration that ensures that the combined configuration is valid.

2: UE uses a joint success failure for messages in an encapsulating MN RRC message.

3: A failure of the MN RRC messages, including one encapsulating SN RRC message with or

without any MN reconfiguration fields triggers a re-establishment procedure.

4: Each SN RRC message should have its own RRC response message even when the SCG

request message is encapsulated in an MCG RRC message. SCG response message is

forwarded over Xx to SN.

5: For MCG reconfiguration containing a SCG reconfiguration, UE sends a MN RRC response

message that encapsulates the SN RRC response message.

SRB 的類型與設定

R2-1702777 Split SCG SRB for LTE-NR dual connectivity Nokia,

Alcatel-Lucent Shanghai Bell discussion Rel-15 NR_newRAT

諾基亞的這篇技術貢獻主要是認為支援 Split SCG SRB 將可以使得

SeNB 的 RRC 訊息得到多樣性的好處,也就是有兩條路徑可以傳輸

其 RRC 訊息,雖然都科摩也表態支持,但多數公司認為這將會導

致設計上的困難度,因此主席做出下列的決議:

=> Split SCG SRB for LTE/NR dual connectivity will not be supported in Rel-15

Page 25: 3GPP RAN2 #97bis 會議報告

25

R2-1702705 SCG SRB configuration and use in LTE-NR interworking

Ericsson discussion Rel-15 NR_newRAT-Core

愛立信的這篇技術貢獻認為 SCG SRB 應該如同 DRB 一樣則是由

MeNB 決定再通知 SeNB 設定之,但是多數公司認為 SCG SRB 應

該由 SeNB 決定並設定之,原因包括了 MeNB 可能不知道 SeNB 是

否有設定 SCG SRB 的能力或是是否有其他的設定的考量等。根據

討論的結果,主席做出下列的決議:

Agreements:

1 SCG SRB can be configured based on network decision.

2 Addition of SCG SRB is decided by SN.

FFS Whether the MN can request establishment of SCG SRB

3 SCG SRB configuration is provided by NR RRC from SN.

4 NR RRC complete messages and measurement reports are mapped to the same SRB as the

message initiating the procedure.

FFS Whether there are any exceptional cases for the complete messages

FFS Whether explicit configuration is also supported for measurement reports.

5 All LTE RRC messages are mapped to MCG SRB.

6 EN-DC can only be configured after security activation on LTE.

R2-1702706 Handling of PDCP duplication for SRB in LTE-NR

interworking Ericsson discussion Rel-15 NR_newRAT-Core

愛立信的這篇技術貢獻認為為了因應 MCG Split SRB 的存在,LTE

的 PDCP 層必須要有對之進行重覆封包檢測與捨棄之功能,才能避

免完整性保護發生錯誤而導致啟動無線連線重建機制。與會公司都

同意此一看法,因此主席做出下列的決議:

Agreements

1 Duplicate detection and discard functionalities for SRBs should be introduced in LTE PDCP to

support duplication via split SRB in LTE-NR tight interworking scenarios where LTE is the

MN.

Page 26: 3GPP RAN2 #97bis 會議報告

26

RLF 處理機制

R2-1703018 RLF Procedure for LTE-NR Interworking Samsung

Electronics Co., Ltd discussion

三星的這篇技術提案討論 RLF 的處理機制,建議遵循過去 LTE 中

雙連結技術的設計原則,當用戶設備偵測到 MCG 的 RLF 時,將會

啟動無線連線重建機制,而當用戶設備偵測到 SCG 的 RLF 時,則

是會暫停資料的傳輸並且將故障的原因回報給 MeNB 知悉。與會公

司都同意此一看法,因此主席做出下列的決議:

Agreement

1: If radio link failure is detected for MCG, UE initiates RRC connection re-establishment

procedure with the PCell.

2: If radio link failure is detected for SCG, UE suspends all SCG radio bearers (including SCG

split bearers) and SCG transmissions for split radio bearers, and reports SCG failure

information to MN.

R2-1703655 Handling on MN failure and SN failure for LTE NR tight

interworking Huawei, HiSilicon discussion Rel-15

NR_newRAT-Core

華為的這篇技術提案討論則是進一步討論 SCG 的 RLF 的原因以及

回報時需要採取的行動,除了原本雙連結技術的設計之外,由於

SCG SRB 的存在,其完整性檢查也可能會出錯,而透過 SCG SRB

直接傳送的 RRC 訊息也可能會發生故障,這些原因都必須要回報

給 MeNB 知悉。與會公司都同意此一看法,因此主席做出下列的決

議:

Agreements:

1: In LTE-NR DC, following SgNB failure cases need to be supported:

- SgNB RLF;

- SgNB change failure;

- exceeding the maximum uplink transmission timing difference (if EN-DC supports the

Page 27: 3GPP RAN2 #97bis 會議報告

27

synchronised operation case which is RAN1 decision);

- SgNB configuration failure (only for message on SCG SRB);

- SgNB RRC integrity check failure;

2: In LTE-NR DC, the UE shall report the SCGFailureInformation to the MeNB instead of triggering

the reestablishment upon SgNB failure.

3: Upon SgNB failures, UE shall:

- Suspend all SCG DRBs and suspend SCG transmission for MCG split DRBs, and SCG split

DRBs;

- Suspend direct SCG SRB and SCG transmission for MCG split SRB;

- Reset SCG-MAC;

- send the SCGFailureInformation message to the MeNB with corresponding cause values .

無線電資源管理(RRM)

本會期討論 cell quality 評估與量測方式,對於以波束成型技術收送訊號的

細胞,用戶終端先篩選波束,再根據篩選後的波束訊號品質量測結果估算

cell quality。

會中以下列三篇技術提案做為討論基礎:

R2-1703721 RRM Measurement in NR: The Details of Filtering

Samsung Electronics discussion

三星這篇技術提案討論 NR 的 RRM 量測需考慮波束量測結果合併

與波束選擇,提出三種波束量測結果合併與波束選擇的選項:

1. 在 L1 filter 之前做波束量測結果合併與波束選擇;

2. 在 L1 filter 和 L3 filter 之間做波束量測結果合併與波束選

擇;

3. 在 L3 filter 之後做波束量測結果合併與波束選擇。

三星支持經由 RRC 的組態設定,用戶設備在 L1 filter 之後做波束量

測結果合併與波束選擇,並可由一或多個波束訊號品質估算 cell

quality。

Page 28: 3GPP RAN2 #97bis 會議報告

28

Layer 1

filtering

Layer 3

filtering

Evaluation

of reporting

criteria

A D B C

C'

RRC configures

parameters

RRC configures

parameters

Source: R2-1703721, Figure 1 Measurement model in LTE [3GPP TS 36.300]

R2-1703417 Filter, serving cell quality and remaining issues in RRM

Intel Corporation discussion

英特爾在這篇技術提案中,考量在量測過程需暫存過濾器量測結果、

以及用戶設備實施複雜度,支持在 L3 filter 之後做波束量測結果合

併與波束選擇。cell quality 則由一或多個達到訊號品質條件的波束

訊號品質平均數表示。

R2-1702796 Measurement model and cell quality derivation in NR

Ericsson discussion

因 NR 支持單波束與多波束的情境,愛立信的技術提案提出用戶設

備在一個量測時間點,可偵測到分別由多個波束傳送的多個 SS

Block,考量用戶終端的複雜度,支持在 L1 filter 之前做波束量測結

果合併與波束選擇。

與會公司認為高頻訊號衰減快、RRM 應著重於波束管理而非波束

過濾,同意波束量測結果合併與波束選擇應在 L1 filter 之後執行。

RRM 的量測模型應包含由 L1 filter 篩選波束量測的結果,由一或多

個波束的訊號品質估算 cell quality,由 L3 filter 篩選 cell quality,由

RRC 控制 RRM 的量測回報 criteria。

會議中對於波束量測結果合併與波束選擇所達成的協議如下:

Agreements

Page 29: 3GPP RAN2 #97bis 會議報告

29

1 The RRC configured beam consolidation/selection of beam quality of gNB detected beams to

derive a cell quality shall be performed after the L1 filter.

2 The L1 filter filters signal quality corresponding to gNB beams detected by the UE

3: The measurement model (applicable for both multi beam and single beam case) in NR shall consist

of the following:

a- L1 filtering of beam measurements

FFS Whether there is any additional specified filtering of the beam measurements

b- Derivation of cell quality from one or more gNB beam quality

c- L3 filter (RRC configured) of cell quality

d- Evaluation reporting criteria (RRC configured)

R2-1703386 Cell quality derivation from multiple beam quality Huawei,

HiSilicon discussion

以波束成型技術收送訊號的情境下,需考慮 cell quality 估算自一或

多個波束的訊號品質、用戶設備偵測到的各個波束是否都達到 RRC

設定的訊號品質條件、以及 cell quality 的估算方式。

會中以華為這篇技術提案作為以多波束估算 cell quality 的討論基礎,

達成以多波束訊號品質的平均值作為 cell quality 的估算方式。達成

的協議內容如下:

Agreements

1 Averaging is used to derive the cell quality from multiple beams (if number of beams is larger

than 1). Details averaging are FFS

R2-1702922 On the Quality of Serving Cell CMCC discussion

serving cell的訊號品質與 inter-cell量測和換手有關,服務 cell quality

估算方式會影響用戶設備執行跨細胞量測或換手的時機與頻率。

中國移動通信在這篇技術提案中提出論述,若以服務 cell quality 最

佳的波束、或是用戶設備正在使用的服務波束品質代表 serving cell

的訊號品質,可能造成用戶設備太慢換手;若以指定數量的波束品

質代表 serving cell 的訊號品質,可能因為其中數個波束的訊號品質

較差而引起頻繁跨細胞量測或造成不必要的換手。中國移動建議

Page 30: 3GPP RAN2 #97bis 會議報告

30

serving cell 與鄰近細胞的 cell quality 應從指定數量的波束品質估算,

serving cell 與鄰近細胞可用不同數量的波束訊號品質估算 cell

quality。

經討論之後,達成 serving cell 與鄰近細胞都以數個最佳波束的訊號

品質估算 cell quality;至於最佳波束的數量還需進一步研究。

決議如下:

Agreement

1 Serving cell quality is derived in the same way as neighbour cell quality (i.e. N best).

FFS whether a UE can be configured with a different values of N for the serving cell, and for specific

neighbour cells.

R2-1703724 Cell measurement with NR-SS and CSI-RS Samsung

Electronics discussion

用戶設備以 NR-SS 和 CSI-RS 作波束訊號品質量測,NR-SS 和

CSI-RS 的量測結果不能混用於 cell quality 估算;多個細胞之間的訊

號品質進行比較時,基於 CSI-RS 量測所估算的 cell quality、和基於

NR-SS 量測所估算出的 cell quality 必須分別比較。

Agreements

1: NR UE shall not consolidate NR-SS beam measurements and CSI-RS beam measurements together

to derive a cell level measurement.

2: NR UE shall compare cell level measurements of different cells using the same type of RS(s). In

another words, NR does not support comparison between NR-SS based measurement of a cell and

CSI-RS based measurement of another cell.

R2-1703724 Measurement report content for A1-A6 events

Ericsson discussion

用戶設備回報量測結果時,可以回報 cell quality,例如 RSRP,RSRQ。

若基地台指定回報特定數量的最佳波束量測結果,且用戶終端因為

SS block 的量測結果符合基地台所設定的回報條件而發送量測報告

給基地台,則用戶設備可將各最佳波束的 SS block 識別包含在回報

給基地台的量測報告內。

Page 31: 3GPP RAN2 #97bis 會議報告

31

Agreements

1 In NR, as in LTE, it should be possible to include cell quality (e.g. RSRP and/or RSRQ) in the

measurement report.

2 UE can indicate the SS block identifier (terminology to be confirmed by RAN1 LS) of x best

beams where x is configurable in measurement reports triggered by the events on SS block.

FFS whether it is needed for all events.

FFS how the UE can choose the best beams.

FFS whether quality of the beams are also reported

FFS whether the same applies for CSI-RS

R2-1703387 Measurement configuration and reporting for additional

RS Huawei, HiSilicon discussion

華為在這篇技術文件中,認為 NR 的 SS 通常會以寬波束傳送以降

低控制通道傳輸造成的負荷,以 NR 的 SS 所量測的訊號品質可反

映寬波束的訊號品質;另方面,資料通道通常用窄波束傳送以提高

傳輸速率,而 CSI-RS 用窄波束傳輸,以 CSI-RS 所量測的訊號品質

可反映窄波束資料通道的訊號品質。由於寬波束和窄波束的波束成

型增益有差異,以NR的SS和CSI-RS所量測的訊號品質會有偏移,

不適合將這兩種參考訊號量測結果互相比較而判斷是否驅動量測

回報。

CSI-RS 的量測結果可用於判斷細胞的訊號品質,因此適用於評估

serving cell 或鄰近細胞的訊號品質是否劣於或優於特定臨界值、或

比較 serving cell 與鄰近細胞的訊號品質優劣。

會中達成協議:基於 CSI-RS 量測所獲得的訊號品質可用於估算 cell

quality;CSI-RS 量測所得的訊號品質可用 A1-A6 事件,以判斷是

否傳送量測回報給基地台;當 serving cell的品質比預設的臨界值好,

用戶設備就不需量測鄰近基地台的閒置模式參考訊號或 CSI-RS 的

訊號品質。

Agreements

1: CSI-RS configured for RRM purpose can be used to derive a cell level quality

2: Events A1-A6 can be configured to use CSI-RS. Events are evaluated on the cell level quality.

Page 32: 3GPP RAN2 #97bis 會議報告

32

3 Previous agreements on measurement model and cell quality derivation are also applicable for

CSI-RS.

4 When the serving cell quality is above S-Measure, the UE is not required to measure the IDLR RS

and CSI-RS for neighbour cells.

R2-1702771 RRM Measurement in CONNECTED based on NR-SS and

CSI-RS MediaTek Inc. discussion

聯發科技在這篇技術文件中引用 RAN1#88 會議的決議,指出 RAN1

決定以 NR-SSS 作為閒置模式用戶設備下行 RRM 的 L3 移動管理參

考訊號;對於 CONNECTED mode 用戶設備的 L3 移動管理,除了

參考 NR-SSS 之外,也可用 CSI-RS 作為額外的參考訊號。

會議中討論CSI-RS是否只用於RRM的量測,還是可有其他用途(例

如波束的訊號品質量測),並決議以 measurement object 組態的

CSI-RS 可用於 RRM 量測;至於是否可做其他用途,則因需求再行

討論。

詳細協議內容如下:

Agreements

1 In NR, a measurement object is corresponding to one carrier frequency.

2 As part of the Measurement Object it is possible to configure a list of CSI-RS resource specific

configurations for RRM measurement. (If this CSI-RS configuration is found to be usable for

other purposes then its placement in the measurement object can be reconsidered)

系統資訊(SI)

上一會期對於用戶設備是否可用隨機存取程序的 Msg 1 或 Msg 3 向基地台

要求 on-demand SI 尚未達成決議,本會期用下列兩篇技術文件再次討論此

議題。

R2-1702970 On Demand SI Request TX Samsung Electronics Co.,

Ltd, Mediatek Inc., NEC, Nokia, Alcatel-Lucent Shanghai Bell, Lenovo,

Motorola Mobility

這篇多家會員公司合提的技術文件,從降低用戶設備電耗與用戶設

Page 33: 3GPP RAN2 #97bis 會議報告

33

備測試的觀點,認為 Msg3 的方法是基礎,Msg1 的方法需要保留足

夠的 preamble,建議 NR 支援 Msg1 和 Msg3,並可由網路端決定用

戶設備當下該用Msg1或Msg3的方法向網路端要求on-demand SI。

雖然支援兩種方法會增加測試的負荷,但提案公司認為值得。

R2-1702857 Open issues of on-demand SI Ericsson discussion

愛立信在這篇技術文件以隨機存取通道的負載量和 preamble 的成

功偵測率提出不同論點,認為網路端可動態更改 SI 中的 scheduling

information,出現在 scheduling information 中的 SI 都會被廣播。用

戶設備可以根據排程資訊的內容判斷所需的 SI 是否會被廣播,若不

會被廣播,則用戶終端用 Msg1 要求網路廣播。網路端只要收到

Msg1 的 SI 要求,就廣播所有的 on-demand SI,而不需進一步區別

個用戶設備需要的是哪幾個特定的 SI。

經討論之後,多數公司贊成 Msg1 和 Msg3 兩種方法都應該被採納,

由網路端決定 idle mode 或 inactive mode 的用戶設備該用哪種方法

向網路端發送 SI 要求。若 minimum SI 已指示各 PRACH 資源或

preamble 與要求各特定 SI 的對應關係,則用戶設備用 Msg1 的方法

要求特定 on-demand SI;反之,若 minimum SI 並未指示這種對應

關係,則用戶設備用 Msg3 的方法要求特定 on-demand SI。

詳細決議如下:

Agreements for on demand request of broadcast SI transmission.

1: For idle and inactive mode, there will be network control whether MSG1 or MSG3 can be

used to transmit SI request .

2: If the PRACH preamble and/or PRACH resource specific to each SIB or set of SIBs which

the UE needs to acquire is included in minimum SI then SI request is indicated using

MSG 1.

3: If the PRACH preamble and/or PRACH resource specific to each SIB or set of SIBs which

the UE needs to acquire is not included in minimum SI then SI request is included in

MSG3.

FFS Error handing in case SI is not received

FFS whether the request delivered in MSG 3 can be used for unicast delivery or for delivery of

SI by dedicated signalling after a transition into connected, or other options

Page 34: 3GPP RAN2 #97bis 會議報告

34

R2-1703140 Discussion on indicating the broadcast of on-demand SIBs

ITRI discussion

用戶設備可從細胞的排程資訊得知該細胞提供的 other SI,但無法

得知這些 other SI 是週期性廣播或是 on-demand SI。當用戶設備所

需的 SI 並非週期性廣播,用戶設備可像基地台發送 SI 要求,以取

得所需的 SI。RAN2 上一會期認為該進一步研究額外指示特定 other

SI 在當下的 SI 週期是否會被廣播的需要性。

本計畫團隊這篇技術文件,考量基地台以波束成型方式傳送 SI 的應

用情境,提出額外指示在每個 SI 週期出現的頻率需大於或等於允許

用戶設備傳送 SI 要求的上行傳輸資源出現頻率才有效益;另方面,

為了協助不特定用戶設備判斷是否需要傳送 SI 要求,額外指示必須

被週期性廣播,或伴隨著 on-demand SI 一起出現。基地台以多波束

傳送 SI 的情境下,每個波束的用戶終端可能要求不同隨選資訊,但

不論隨選資訊是否會被廣播,每個波束對每個隨選資訊都要標示額

外資訊;另方面,若持續時間有多個用戶設備要求相同隨選資訊,

基地台可能改為週期性傳送這些隨選資訊,因此本技術文件提出以

額外資訊標示隨選資訊在當下的 SI 週期是否會被廣播並無效益,並

建議 RAN2 考量額外資訊在多波束傳輸情境下造成的額外訊務負

荷。

這個部分在會議上尚未討論,未來,本計畫團隊可以再進一步針對

這一點提案。

4. 新規範的 rapporteur

主席私下與幾家公司已經談好新規範的 rapporteur,在這次會議上,正式

經過大會的同意,名單如下:

38.300 (Stage 2) - Benoist Sebire (Nokia)

Page 35: 3GPP RAN2 #97bis 會議報告

35

38.304 (Idle mode) - Ozcan Ozturk (Qualcomm)

38.306 (UE capabilities) - Kyeongin Jeong (Intel)

38.321 (MAC) - Jaehyuk Jang (Samsung)

38.322 (RLC) - Pavan Nuggehalli (MediaTek)

38.323 (PDCP) - SeungJune Yi (LGE)

38.331 (RRC) - Kai-Erik Sunell (Ericsson)

37.3xx (New QoS layer) - Hao Bi (Huawei)

37.340 (New stage 2 DC/MC) - Sergio Parolari (ZTE)

5. 其他重要提案說明

R2-1702749 UL data split in Dual connectivity

Proposal 1 Reuse LTE-UL-split threshold based solution in NR.

Proposal 2 NR UL split threshold is configurable by RRC and dynamically

adaptable by PDCP control signalling.

Proposal 3 The prioritized UL transmission direction (similar as

ul-DataSplitDRB-ViaSCG), should be configurable by RRC and dynamically

adaptable by PDCP control signaling.

R2-1703572 Pre-processing for NR-NR DC

Proposal 1. RAN2 in principle agree to take the hard-split based approach in

NR-NR DC and LTE-NR DC and work on the details during NR WI phase.

R2-1702749 這一篇 Ericsson 主要提議要和 LTE 一樣使用上行 threshold

解決方案控制哪時候要分流資料,在 LTE 的 DC 裏,上行資料量如果小於一

個 threshold 時,資料會用高優先權的 cell group 送,當上行資料量大於此

threshold 時,就會分流到其它的 cell group.Ericsson 希望 NR 的 DC 沿用 LTE

DC的方法,但Samsung在R2-1703572指出,LTE DC的做法不適法用在NR,

因為 NR 一個主要特色為 PDCP 及 RLC 的 PDU 可以在還沒收到基站分配的

傳送資料的資源時先行處理資料,但如果沿用 LTE DC 的方法的話,可能無

法先行處理資料,所以他們提議使用所謂的硬切的方法來分流資料,就是不

會根據資料量改變分流的方式,而是手機事前就知道哪個 PDU 要用哪個 cell

Page 36: 3GPP RAN2 #97bis 會議報告

36

group 傳送,例如基站給手機一個比率值,手機自己按照這個比例值決定資

料要往哪送.

R2-1703508 PDCP SN length change at handover LG Electronics Inc.

Proposal1: No special mechanism is needed for PDCP SN length change at

handover from LTE to NR.

Proposal2: To avoid HFN de-synchronization problem at handover from NR

to LTE, the NR PDCP provides the COUNT value of the first missing PDCP

SDU to the LTE PDCP.

Proposal3: Do not support PDCP SN length change at handover within NR.

R2-1703508 主要提到 PDCP 序號轉換會發生什麼問題以及如何避免問

題發生,當從 NR 換手 LTE 時,也許會發生序號轉換問題,背景是假設 NR

PDCP 序號的長度大於 LTE PDCP 序號的長度時,在這個假設下為了要保證

無資料漏失的換手,必需有一些機制來保證資料不會掉,但問題是 NR 還沒

討論 PDPC 序號的長度應該多少,所以目前談這個問題似忽太早,應該等決

定 NR 的 PDCP 序號長度後再來討論,如果 NR 的序號長度不用變大,該問

題自然不存在.

R2-1703402 Bearer type combinations in LTE-NR DC

Proposal 1: RAN2 to agree that from a UE point of view, there is no need to

support each of the following combinations of bearer types in LTE-NR DC

simultaneously:

o MCG split bearer and SCG split bearer

o MCG split bearer and SCG bearer (same as LTE DC)

R2-1703402 在討論哪一種載體型態組合是不需要的,他們認為因為

MCG split bearer 和 SCG split bearer 的功能都是要增加手機的傳輸速度,這兩

種 bearer 同時存在看來不是很需要,另外同時有 MCG split bearer 和 SCG

bearer 這種組合也不需要因為 MCG split bearer 已經可以使用 SCG 的資源,

所以沒必需再有 SCG bearer,最後 RAN2 同意提議如下,也就是只要有 MCG

Page 37: 3GPP RAN2 #97bis 會議報告

37

split bearer 就不需要有 SCG bearer 或 SCG split bearer.

Agreements

1: The following combinations of bearer types cannot be configured

simultaneously in LTE-NR DC simultaneously for user plane DRBs:

• MCG split bearer and SCG split bearer

• MCG split bearer and SCG bearer (same as LTE DC)

R2-1703650 Allowed bearer type change options for LTE-NR DC

To

From

MCG bearer MCG Split

bearer

SCG bearer SCG split

bearer

MCG

bearer

Y Y Y Y

MCG

Split bearer

Y Y

N N

SCG

bearer

Y

N Y

N

SCG

split bearer

Y N N Y

在 NR 裏有 4 種 bearer 型態,分別是 MCG bearer,MCG split bearer, SCG

bear,SCG split bearer,一個 bearer 的型態可以轉換到其它型態,R2-1703650

主要討論哪些型態的轉換是 NR 必需支援,在 LTE DC 裏支援下例 bearer 型

態的轉換,可以看見的是 LTE 不支援直接從 MCG split bearer 轉成 SCG bearer

o MCG bearer to/from MCG split bearer,

o MCG bearer to/from SCG bearer,

o MCG bearer to MCG bearer,

o SCG bearer to SCG bearer,

o MCG Split bearer to MCG split bearer

此篇提議按照 LTE 的做法支援 bearer 型態轉換,但因為 NR 有 SCG split

bearer,這是新的 bearer 型態,所以此篇文章針對這個新型態的 bearer 建議

Page 38: 3GPP RAN2 #97bis 會議報告

38

MCG/SCG bearer 可以成 SCG split bearer,以下為 RAN2 的決議:

Agreements

1: LTE-NR DC should support at least following bearer type change

options

- MCG bearer to/from MCG split bearer,

- MCG bearer to/from SCG bearer,

- MCG bearer to MCG bearer,

- SCG bearer to SCG bearer,

- MCG split bearer to MCG split bearer

2: LTE-NR DC should not support the direct bearer type change

between MCG split bearer and SCG bearer.

3: LTE-NR DC should support the one step bearer type change between

MCG bearer to/from SCG split bearer.

4 LTE-NR DC shall support the bearer type change between SCG

bearer and SCG split bearer.

6: LTE-NR DC should support the bearer type change between SCG

split bearer and SCG split bearer.

FFS: Whether LTE-NR DC shall support the direct type change

between MCG split bearer to/from SCG split bearer.

R2-1702632 Overview of Duplication

Proposal 1: RRC configures the radio protocols of the UE with separate RLC

entities and logical channels to handle duplicates (referred to as “legs”).

Proposal 2: only one additional leg is configured for PDCP duplicates.

Proposal 3: the original PDCP PDU and the corresponding duplicate shall not

be transmitted on the same transport block.

Proposal 4: in duplication, the logical channels of the different legs shall not

be transmitted on the same transport block

Proposal 5: logical channel mapping restrictions need to be introduced to

Page 39: 3GPP RAN2 #97bis 會議報告

39

handle duplicates in within one MAC entity (CA).

Proposal 6: duplication follows the same framework as for CA with

configuration done by RRC and activation dynamically done by L2.

R2-1702632 是有關 PDCP PDU 複製議題的文章,之前 RAN2 會議討論

要如何支援 URLLC,最後同意在 CA 的部份,利用傳多同份相同的 PDU 以

增加資料傳送的可靠度,以及降低成功傳送資料的時間,上次 RAN2 的決議

如下:

Agreements:

1: Packet duplication is supported for user plane and control

plane in NR-PDCP (This agreement does not preclude discussion of other

mechanisms to improve mobility robustness)

FFS whether packet duplication should also be supported for LTE-NR

dual connectivity

2 The PDCP function in the transmitter supports packet

duplication and the PDCP function in the receiver supports duplicate

packet removal.

接續上次的討論,這篇文章繼續討論一些細節,包括要使用多少個 MAC

單元以及 RLC 單元,及一些與 LCP 有關的細節,最後 RAN2 決議如下:

Agreements:

1: RRC configures PDCP for duplication and the radio protocols

of the UE with separate RLC entities and logical channels to handle

duplicates (referred to as “legs”)

2: only one additional leg is configured for PDCP duplicates.

3: the original PDCP PDU and the corresponding duplicate shall

not be transmitted on the same transport block.

FFS whether in CA case to support PDCP duplicates on the same

carrier with some restriction to prevent them from being transmitted

Page 40: 3GPP RAN2 #97bis 會議報告

40

on the same transport block. (Noting that we have already agreed that

they can be sent on different carriers)

4: PDCP duplication solution for CA requires only one MAC entity.

5 logical channel mapping restrictions need to be introduced to

handle duplicates in within one MAC entity (CA).

其中有一項待議事項,原本的提議是希望一個傳送單元只包含一個邏輯

通道的資料,因為這樣資料排程會比較簡單,但有公司目前不想排除一個傳

送單元可以放兩個邏輯通道的資料(只要這兩份資料不是屬於相同 PDCP

PDU 即可).另外還有其它公司提出要支援動態的開關這個傳送重覆資料的

方法,而其它公司則懷疑是否需要這樣的功能,所以主席要求會後大家使用

電子郵件的方式來討論出一個結果,如果需要這個功能,則也要討論出如何

做到開關傳送重覆資料的方法

七、心得與建議

心得:

這次會議在 R14 的部分專注修正及 ANS.1 的檢閱,已無新議題加

入討論。

NR 工作項目階段於本會期開始,無論是在 CP 或是 UP 的部分,本

年度結束前必須要優先完成非獨立運作的相關議題,也就是 EN-DC

下的各種信令程序要如何運作,因此對於 EN-DC 相關的議題與技

術開發都要加緊腳步以爭取時效,雖然非獨立運作的相關議題有其

優先性,但是與獨立運作共通的部分仍要合併研究,以期未來能夠

順利整合這兩個部分。波束成型是 NR 的主要特徵之一,與之相關

的訊號品質量測和系統資源管理也可預見是接下來幾次會期的重

點。此外,NR 的 L2 大都以 LTE 為基礎,在這個基礎上根據 NR

的需求再做強化。

為提供足夠的 QoS 類型給不同的應用服務,DRB 承載根據服務品

Page 41: 3GPP RAN2 #97bis 會議報告

41

質不同來定義服務品質流,預期 URLLC 高需求的流量將納入接下

來討論範圍。

建議:

從 NR 研究項目開始,各個公司參與 RAN2 的人數有明顯的增加,

尤其以中國大陸的公司,不只人數增加,參與標準的公司也增加許

多,例如:小米、OPPO、vivo 等。工作項目從這個會期開始,尤

其會議以 CP 與 UP 平行討論,擬派人參加會議的公司,需要將人

數與議題做考量;另外,由於 NR 議題很多,導致一年會議次數也

變多(今年至少有八次會議),建議本計畫的經費與人員增加都需

要列入考量。

對於 NR 除了 RAN2 相關討論外,也要注意其它工作群組的討論如

此才能比較快掌握訊息