3GPP RAN2 #93

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

3GPP RAN2 #93

出國人員：包偉丞、鄭靜紋、吳志祥、謝景融

派赴國家：馬爾他/聖朱利安斯

出國期間：105年 2月 13日至 103年 2月 22日

報告日期：105年 4月 7日

2

摘要

本次 3GPP RAN2 #93會議於馬爾他舉行，本研發團隊依規劃有 4

位成員出席參與。此行主要任務說明如下：

1. 多載波負載分佈(Multicarrier Load Distribution in LTE, MCLD)

MCLD 的議題，於上會期正式結束，其新增功能包含：優先順序

權值的擴充、信號與干擾加雜訊比的量測、整合再選方案之運作；

主要目的在於擴充現行規格書中之載波頻段的優先順序權值、避

免閒置模式(Idle mode)下的用戶設備(UE)集中於特定載波，進而達

成負載分佈平衡及增進連線模式(Connected mode)下的系統吞吐

量(throughput)。

2. 授權頻帶輔助存取(Licensed-Assisted Access, LAA)

LAA議題主要搭配著無線存取網路第 1工作組(RAN1)的需求，於

相對應的標準規格書中做修正；討論議題包含接收訊號強度指標

(RSSI)的測量方法，以及先聽後說(listen-before-talk, LBT)優先權級

別(priority classes)和服務品質級別指標(QoS Class Identifier, QCI)

的對應表格設定。

3. 窄頻段物聯網(Narrow Band Internet of Things, NB-IoT)

NB-IoT 議題針對窄頻段且低耗能設備的無線資源控制(Radio

Resource Control, RRC)程序、系統資訊(System Information, SI)內容、

以及用戶平面通訊協定修訂。

技術貢獻：

在這次會議，本團隊在 RAN2#93會議上提出了 7篇標準貢獻提

案及信件討論。本團隊為了掌握 LTE-Advanced 第十三版(Release 13,

R13)的發展方向，持續關注在 R13 主要的工作項目，如 LAA、LTE

3

與無線區域網路聚合(LTE-WLAN Aggregation, LWA)、機器型態通訊

於 LTE實體層的進一步增強(Further LTE Physical Layer Enhancements

for MTC, eMTC)、超過 5 個載波的 LTE 載波聚合增強(LTE Carrier

Aggregation Enhancement Beyond 5 Carriers, CA enh)、MCLD、路測最

小化的進一步增強(Further MDT enhancements)、鄰近服務增強(ProSe

enhancements)、單細胞之點對多點傳輸(Single-Cell Point-to-Multipoint,

SCPTM)、以及 NB-IoT 等，並同時著手進行研究。本團隊針對各個

研究項目及工作項目都持續有成員投入參與標準會議，以便掌握會議

期間各家廠商對於不同議題之立場與看法，並且收集各並行會議之最

新發展狀況與討論結果，了解各項重要研究議題與技術之現況，並與

各家公司交換對於R13新議題的看法，並表明我方之立場。另一方面，

本團隊成員也持續提出標準貢獻提案發表我們於各項議題的看法與

分析研究，以提升本團隊於標準會議的影響力和佈局本團隊於這些研

究議題所做的前瞻性研發成果。

會議解說：

上一次 RAN2會議結束後，還有一些工作項目還沒討論完，因此

RAN plenary同意MTC和 LTE-WLAN還可以在這一次會期討論還沒

完成的議題，因此 RAN2在 2016年第一季還是著重在完成 R13工作

項目以 ASN.1的檢查校正，在 2016年 4月時 RAN2才會開始 Release

14的工作項目。本次 3GPP RAN2#93會議於馬爾他舉行，主要關注

議題包括MCLD、 LAA、和 NB-IoT等技術議題。

1. MCLD

本次會期中，主要檢視規格書修改及新增方式，是否符合之前會

期已經同意的內容，並將相關文字修正，讓規格書更易閱讀，其

中包含相關的細部設定和參數定義。

4

2. LAA

本次會期中，除了檢視規格書修改及新增方式外，著重於接收訊

號強度指標(RSSI)的測量方法，以及 LBT priority classes和 QCI的

對應表格設定；其他議題尚包含裝置內共存(In-Device Co-existence,

IDC)和用戶設備能力設計議題。

3. NB-IoT

本會期達成控制平面(Control Plane, CP) 方案與用戶平面(User

Plane, UP)方案的無線資源控制(Radio Resource Control, RRC)程序，

包括個訊息的安全性考量、以及第三訊息(Message 3)的長度；用

戶平面的通訊協定則以媒體存取控制 (Medium Access Control,

MAC)有較多進展。

5

目錄

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

一、會議名稱 ............................................................................................. 6

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

三、會議時間 ............................................................................................. 6

四、會議地點 ............................................................................................. 6

五、會議議程 ............................................................................................. 6

六、會議紀要 ............................................................................................. 9

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

6

一、會議名稱

3GPP TSG RAN2 #93

二、參加會議目的及效益

參與 MCLD、 Further MDT enhancements、 LAA、 ProSe

enhancements、SCPTM、 CA enh、eMTC、NB-IoT 等討論及

尋找可研究的題目。

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

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

交流。

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

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

開展未來合作機會。

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

三、會議時間

15th February– 19th February 2016

四、會議地點

InterContinental Hotel, St. Julians , Malta

五、會議議程

RAN2#93的會議議程如下 15th February– 19th February 2016

Schedule Main room

(meeting hotel)

LTE Breakout room

(meeting hotel)

UMTS room

(meeting hotel)

NB-IoT room

(The Palace Hotel)

Mon 09:00

-> 13:00

[1], [2], [3], [4]

7

10:30 -> [5.1], [5.2] [5.3]

[6.2.1.1] DC max UL TX

timing difference

[7.9] DRX corrections

[7.18] CIoT

optimisations for non

NB-IoT UEs

[8][9] UMTS

Rel-8/9/10/11

[10] Rel-12

14:00 -> [6.x] Legacy LTE

(start 7.x if time allows)

[6.1.2, 6.2.9.2] Legacy LTE user

plane

[7.4.6, 7.4.3] MTCe user plane

and random access

(any documents from 7.4.6, 7.4.3

not covered may be treated in

main room later in the week)

[12] ASN.1 review

16:30 ->

Tuesday

08:30 -> [7.4] MTC

[12] ASN.1 cont’ if needed

11:00 ->

14:30 -> [7.6] LTE/WLAN

(starting with LWI)

(7.6.1, 7.6.3 LWI, 7.6.2.1

LWA Stage 2, 7.6.2.3

LWA UP )

[7.5] ProSe corrections

(may cover some ProSe specific

papers from 7.19)

[11.2, 11.3, 11.4] NAICS,

DL TPC, EVS

[11.2] Power saving enh.

[11.8] Indoor positioning

[7.16] NB-IOT

(7.16.1, 7.16.2)

17:00 ->

Wednesda

y

08:30 -> [7.19] ASN.1 review

[7.x] R13 corrections

(7.1 LAA)

[11.1] DL enhancements [7.16] NB-IOT (full

day possible)

(7.16.3, 7.16.2)

11:00 -> [11.6] Dual Band HSUPA

[11.11] UMTS TEI13

Comebacks

14:30 -> [7.15] LTE/WLAN for

legacy AP

[7.9] V2X

17:00 -> [7.6] LTE/WLAN

(7.6.2.2 LWA CP)

Thursday

08:30 -> [7.x] R13 corrections

(7.2 CA-enh, 7.8

DC-enh, 7.3 SC-PTM)

[7.7] MCLD, [7.13] MDT, [7.3]

SC-PTM corrections

(to be determined by Wednesday

[12] ASN.1 and comebacks [7.16] NB-IOT (full

day possible)

(7.16.2, 7.16.1,

11:00 ->

8

if these will be in parallel session

or main room)

comebacks)

14:30 -> [7.x] R13 corrections

(7.12 MIMO, 7.7

MCLD, 7.13 MDT, 7.14

IPos)

[7.17] Other LTE R13

WIs

[7.18] TEI13

(possibly some selected

7.x comebacks)

[7.5] ProSe correction comebacks

17:00 ->

Friday

08:30 ->

until 17:00

Left-overs, Comebacks

including Joint

LTE/UMTS

9

六、會議紀要

1. LTE 之多載波負載分散(Multicarrier Load Distribution in LTE,

MCLD)

R2-161019 Further LS to R4-156637 = R2-156034 on RS-SINR measurement report

mapping (R4-158389; contact: Ericsson) RAN4 LS in to: RAN2 Rel-13

LTE_MC_load-Core

moved froom 3.2 to 7.7

=> Noted

來自無線存取網路第 4工作組(RAN4)的聯絡說明(LS)，對於信號

與干擾加雜訊比(SINR)的量測回報範圍，回報範圍介於-23dB至 40dB，

間格 0.5dB為一回報數值，然而其實際量測數值尚未獲得共識；量測

回報對應表則會定義於規格書 TS 36.133，對應表如下所示：

RS-SINR measurement report mapping

Reported Value Measured Quantity Value Unit

RS-SINR_000 RS-SINR -23 dB

RS-SINR_001 -23 RS-SINR < -22.5 dB

… … …

RS-SINR_126 39.5 RS-SINR < 40 dB

RS-SINR_127 40 RS-SINR dB

R2-161954 Idle mode load distribution Samsung Telecommunications CR 36.304

13.0.0 0290 1 F Rel-13 LTE_MC_load-Core R2-161224

=> Agreed

此份修正要求(CR)是將規格書編號 TS 36.304中的文字敘述，重

新描述並加入更多細節，讓用戶設備(UE)的行為能符合期望；其修正

內容包含：

a) The ordered list compiled by the UE concerns candidate targets

(cell or frequency), one per frequency

http://www.3gpp.org/DATA/3GPP/RAN2/Docs/R2-161019.zip

http://www.3gpp.org/DATA/3GPP/TSGR2/TSGR2_92/Docs/R2-156034.zip



10

用戶設備所排序的頻率或細胞名單，每個頻率只會有一個候選

目標。

b) The list only includes frequencies supported by the UE

排序中的名單僅包含用戶設備能支援的頻率。

c) The list only includes frequencies for which redistribution info is

provide i.e. redistributionInterFreqInfo is included

排序中的名單僅含有提供再選參數 redistributionInterFreqInfo

的頻率。

d) The UE applies redistributionFactorFreq also if

redistributionNeighCellList is not included (i.e. not only if the best

cell on the frequency is not included in that list)

再選參數不含 redistributionNeighCellList 時，用戶設備也可使

用再選參數 redistributionFactorFreq。

R2-161318 Correction to E-UTRAN Inter-frequency Redistribution procedure_alt2 ITRI

CR 36.304 13.0.0 0295 - F Alt. 2 CR for Correction to

E-UTRAN Inter-frequency Redistribution procedure Rel-13

LTE_MC_load-Core

=> Agreed in R2-161951 CR rev 1

此份修正要求是在修正規格書編號 TS 36.306中，用戶設備的行

為，以符合之前會議共識中的內容；整合再選方案之運作中，當網路

端有提供再選參數 redistrOnPagingOnly時，用戶設備必須等呼叫訊息

(paging message)，才能啟動整合再選方案之運作，然而規格書中的敘

述遺漏了此限制條件，因此有可能造成用戶設備，當再選參數 T360

時間倒數終止後，即馬上執行整合再選方案，而非等待呼叫訊息來啟

動再選方案之運作；因此，此份修正要求即在判斷條件中，加入此等

待呼叫訊息的限制，使得用戶設備的行為得以符合預期。

R2-161448 The introduction of UE capability concerning extended E-UTRA frequency

priorities Nokia Networks, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell

CR 36.306 13.0.0 0334 - B Rel-13




11

LTE_MC_load_Core

NOTE: CR cat.B is not allowed for closed WI

=> Agreed in R2-161952 CR rev 1 Cat F

此份修正要求是針對規格書編號 TS 36.306，有關用戶設備能力

於優先順序權值的擴充 (Extension of Frequency Priorities)的描述，即

基於目前的載波優先順序權值進行擴充，加入次優先順序權值，例如

0.2；主要在於用戶設備會通知網路端，是否支援此優先順序權值擴

充的功能，即次優先順序權值。

R2-161446 The introduction of UE capability concerning extended E-UTRA frequency

priorities Nokia Networks, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell

CR 36.331 13.0.0 2048 - B Rel-13

LTE_MC_load_Core

NOTE: CR cat.B is not allowed for closed WI

=> Agreed in R2-161953 CR rev 1 Cat F

此份修正要求是對應於用戶設備能力，修改於規格書編號 TS

36.331，在於用戶設備會通知網路端，是否支援此優先順序權值擴充

的功能；此修正，在於對應到規格書編號 TS 36.306的功能描述。

2. 授權頻帶輔助存取(Licensed Assisted Access, LAA)技術

R2-161548 Mapping between Channel Access Priority Classes and QCI values

Ericsson, Huawei, HiSilicon, Qualcomm Incorporated discussion

此文稿針對無線存取網路第 1 工作組(RAN1)，於 LBT priority

classes和 QCI的對應方式；LBT priority classes定義及參數。RAN1

定義了 4個存取優先權，不同的優先權有不同的參數設定如下．其中

最高優先權為 1，最低優先權為 4，最高優先權會有比較多機會傳送

出資料．





12

Channel

Access

Priority Class

( p )

pm pCWmin, pCWmax, pmT cot, allowed pCW sizes

1 1 3 7 2 ms {3,7}

2 1 7 15 3 ms {7,15}

3 3 15 63 8 or 10 ms {15,31,63}

4 7 15 1023 8 or 10 ms {15,31,63,127,255,511,1023}

這些優先權必需對應到目前 3GPP 所定義的資料類型的分類，

3GPP對於不同的資料類型，制定不同的服務品質級別指標（QoS Class

Identifier, QCI)，以下是各種不同的 QCI對應到的應用:

13

QCI Resource

Type

Priority Level Packet

Delay

Budget

Packet Error

Loss

Rate

Example Services

1 2 100 ms 10-2

Conversational Voice

2

GBR

4 150 ms 10-3

Conversational Video

(Live Streaming)

3 3 50 ms 10-3

Real Time Gaming

4 5 300 ms 10-6

Non-Conversational

Video (Buffered

Streaming)

65 0.7 75 ms

10-2

Mission Critical user

plane Push To Talk

voice (e.g., MCPTT)

66

2

100 ms

10-2

Non-Mission-Critical

user plane Push To

Talk voice

5 1 100 ms 10-6

IMS Signalling

6

6

300 ms

10-6

Video (Buffered

Streaming)

TCP-based (e.g., www,

e-mail, chat, ftp, p2p file

sharing, progressive

video, etc.)

7 Non-GBR

7

100 ms

10-3

Voice,

Video (Live Streaming)

Interactive Gaming

8

8

300 ms

10-6

Video (Buffered

Streaming)

TCP-based (e.g., www,

e-mail, chat, ftp, p2p file

9 9 sharing, progressive

video, etc.)

69 0.5 60 ms 10-6

Mission Critical delay

sensitive signalling

(e.g., MC-PTT

signalling)

70 5.5 200 ms 10-6

Mission Critical Data

14

(e.g. example services

are the same as QCI

6/8/9)

在這個表裏沒有考慮 QCI 4的對應，QCI 4用在電信公司特定的

類別，有的公司認為 QCI 4也應該被考慮在內，最後經由私下討論，

RAN2的決議：CQI 4被對應到第 3個優先權。

此對應設計原則為有較高的封包延遲要求(Packet Delay Budget)，

則對應到較高優先類別，因此最後決議的對應表格，呈現如下：

Agreements:

1 QCI 1 is mapped to priority class 1













R2-161921 Mapping between Channel Access Priority Classes and QCI values

Ericsson, Huawei, HiSilicon, Qualcomm Incorporated CR 36.300 13.2.0

0842 1 F Rel-13 LTE_LAA-Core R2-161549

=> Agreed

此份修正要求是依據上述會議共識，於規格書編號 TS 36.300作

相對應的修正；其建議對應表格，呈現如下：



15

Mapping between Channel Access Priority Classes and QCI

Channel Access Priority Class ( p ) QCI

1 1, 3, 5, 65, 66, 69, 70

2 2, 7

3 4, 6, 8, 9

4 -

另外 RAN1通過如何合併傳送來自不同優先權的資料，其內容如

下．RAN2把 RAN1這項決議寫到標準規格 36.300裏面．

Agreements:

• If a DL transmission burst with PDSCH is transmitted, for which

channel access has been obtained using LBT priority class X (1...4), the

eNB shall ensure that:

– The transmission duration shall not be longer than the minimum

possible duration needed to transmit all available buffered

traffic corresponding to LBT priority classes ≤ X

– The transmission duration shall not be longer than the MCOT

for priority class X

– Additional traffic corresponding to LBT priority classes >X

may only be included in the DL transmission burst once

inclusion of traffic corresponding to LBT priority classes ≤ X

has been exhausted. In such cases, the eNB should maximise

occupancy of the remaining transmission resources in the DL

transmission burst with this additional traffic.

• The above requirements shall be captured within RAN2 specifications.

RAN1 kindly requests RAN2 to take the above agreements into account.

而其他營運商所設定的 QCI，也可以參考此表格，將資料類別做

適當的對應。

16

R2-161922 Multiplexing of data in LAA Ericsson, Huawei, HiSilicon, Qualcomm

Incorporated CR 36.300 13.2.0 0843 2 F Rel-13

LTE_LAA-Core R2-161920

=> Agreed

基於上述同意事項，基地台(eNB)在下行傳輸時，基地台會依據

通道存取優先權級別(Channel Access Priority Classes)，遵守其資料傳

輸和多工的方式；此份修正要求，則補充其敘述於規格書編號 TS

36.300，將會有專門章節敘述其運作方式；其細節呈現如下：

5.7.X Multiplexing of data

Four Channel Access Priority Classes are defined in [6]. If a DL transmission burst

with PDSCH is transmitted, for which channel access has been obtained using

Channel Access Priority Class P (1...4), E-UTRAN shall ensure the following

where a DL transmission burst refers to the continuous transmission by E-UTRAN

after a successful LBT:

- the transmission duration of the DL transmission burst shall not exceed the minimum

duration needed to transmit all available buffered traffic corresponding to Channel Access

Priority Class(es) ≤ P;

- the transmission duration of the DL transmission burst shall not exceed the Maximum

Channel Occupancy Time ( pmT cot, as defined in Table 15.1.1-1 of [6]) for Channel Access

Priority Class P;

- additional traffic corresponding to Channel Access Priority Class(s) > P may only be

included in the DL transmission burst once no more data corresponding to Channel Access

Priority Class ≤ P is available for transmission. In such cases, E-UTRAN should maximise

occupancy of the remaining transmission resources in the DL transmission burst with this

additional traffic.

R2-161916 corrections on RSSI measurment Beijing Xinwei Telecom Techn. CR 36.331

13.0.0 2006 1 F Rel-13 LTE_LAA-Core R2-161158

=> Correct " fisrt "

=> Agreed in R2-162003 CR rev 2

根據 RAN1上次會議送給 RAN2的連繫文件，RAN1定義了幾個

LAA 參數，這些參數必需透過 RRC 訊息，從基地台傳給 UE，但其





17

中有關 RSSI測量相關的參數，並沒有提到這些參數如何使用，因此

這次會議有公司提出使用這些參數的方法，大致上是依照探索參考訊

號 (Discovery Reference Signal, DRS) 測量時間組態 (DRS

Measurement Timing Configuration, DMTC)的計算方式，來計自接收訊

號強度指標(Received Signal Strength Indicator, RSSI)量測的時間點．

此份修正要求，即是有關接收訊號強度指標(RSSI)的量測方式；

由於缺少對於探索參考訊號量測時間配置(DRS measurement timing

configuration, DMTC)的定義，以及其相關的參數，可能造成用戶設備

無法在正確的時間量測接收訊號強度指標；規格書編號 TS 36.331，

將會新增對接收訊號強度指標量測的時間參數設定，其細節呈現如

下：

5.5.2.xx RSSI measurement timing configuration

The UE shall setup the RSSI measurement timing configuraton (RMTC) in

accordance with the received rmtc-Period, rmtc-SubframeOffset if configured

otherwise determined by the UE randomly, i.e. the first symbol of each RMTC

occasion occurs at fisrt symbol of an SFN and subframe of the PCell meeting the

following condition:

SFN mod T = FLOOR(rmtc-SubframeOffset/10);

subframe = rmtc-SubframeOffset mod 10;

with T = rmtc-Period/10;

On the concerned frequency, the UE shall not consider RSSI measurements outside

the configured RMTC occasion which lasts for measDuration for RSSI and channel

occupancy measurements.

在裝置內共存(In-Device Co-existence, IDC)方面，去年 RAN2認

為不需要強化目前的 IDC 就足以達到 LAA 和 WiFi 共存的目標，因

為目前 IDC 的功能已經足夠，基地台只要設定 UE 執行 IDC 的功能

即可。有公司希望把基地台設定 UE去執行 IDC這個動作，明確制定

18

在標準規格內，最後因為時間有限，連同用戶設備能力設計議題將在

會後，再以 email的方式討論．

R2-161978 IDC support in LAA Intel Corporation, BlackBerry, Samsung CR 36.300

13.2.0 0829 1 F Rel-13 LTE_LAA-Core R2-161236

[93#xx][LTE/LAA] IDC for LAA (Intel)

Intended outcome: Agreed CR for RAN (conclusion could be no CR to be

sent to RAN)

R2-161554 Leftover UE capabilities for LAA Ericsson CR 36.331 13.0.0 2061 -

F Rel-13 LTE_LAA-Core

[93#xx][LTE/LAA] 331 and 306 CRs (Ericsson)

Intended outcome: Agreed CRs to RAN (if RAN1 provide input from their

meeting)

3. 窄頻段物聯網(Narrow Band Internet of Things, NB-IoT)

R2-161757 E-Mail discussion and companies view on NB-IOT Positioning

Vodafone GmbH report

此提案根據各公司觀點，決定 R13 的基地台(eNB)有可能支援

NB-IoT裝置定位。對此，RAN2假設在位置服務(Location Service, LCS)

架構下，即使 R13的 NB-IoT UE不支援量測回報，eNB可根據本身

的量測而執行 NB-IoT裝置定位。

R2-161362 RRC procedures - stage 3 aspects Neul, Huawei, HiSilicon,

discussion

此提案分析 RRC 連線建立時所需的訊息與參數，討論 NB-IoT

所需的 RRC連線參數。

經由討論，RAN2達成下列協議(agreements)：

- eNB藉由 RRC Connection Setup訊息，將建立第一訊號無線承

載(Signaling Radio Bearer 1, SRB1)所需的訊號無線承載(SRB)、

MAC、實體層(PHY)組態參數傳送給 UE；




19

- 若 UE未收到來自 eNB的 SRB1相關組態參數，則使用預設或

預存的相關組態參數；其中，預存的組態參數適用於使用者平

面方案；

- UE 以 RRC Connection Setup Complete 訊息傳送

SelectedPLMN-Identity參數給 eNB，供 eNB選擇 NB-IoT繞送

的行動管理單元(Mobility Management Element, MME)；此協議

適用於控制平面和使用者平面方案；

- NB-IoT 的 RRC 連線釋放原因至少需定義下列項目： others,

loadBalancingTAUrequired；此協議適用於控制平面和使用者平

面方案；

R2-161166 Summary of email discussion: [NBAH#04][NBIOT/Resume] RRC

Functions for suspend – resume Huawei report result of email

discussion [NBAH#04] Rel-13 NB_IOT-Core

此提案根據上一會期的決議：eNB以 RRCConnectionRelese訊息

命令 UE暫停(suspend) RRC連線、並進入 RRC_IDLE狀態，收集各

公司觀點，以期進一步訂定 RRC 連線暫停與恢復的程序與訊息內

容。

經討論後，RAN2達成下列協議：

- 在 RRCConnectionRelease 以新的釋出原因(release cause)命令

UE暫停 RRC連線；

- RRC 連線暫停之後，不以計時器(timer)限制存取層(Access

Stratum, AS)內文(Context)的有效時間；

- 用戶平面方案中，第三訊息(Message 3)不會同時帶共通控制

通道 (Common Control Channel, CCCH)和專用訊務通道

(Dedicated Traffic Channel, DTCH)的內容，即 RRC Resume

Request 訊息不能同時傳送控制平面的訊息與用戶平面的資

料；

20

- RRC 連線恢復時，UE 重設分封數據匯聚協定(PDCP) 計數

(COUNT)；

- 恢復 RRC連線的程序可用組態差異(delta configuration)的方式

設定組態；

- eNB 用第四訊息(Message 4)對 UE 提供下一跳點連鎖計數

(Next hop Chaining Count, NCC)；

- 單次傳輸可同時攜帶具有安全性與不具安全性的複數個訊

息；

- 重複使用 RRC reestablishment 的 ShortMAC-I 作為認證代碼

(token)，由 UE以Message 3提供；

- 不支援重算金鑰(re-keying)；

- 若 UE 順利恢復接取層內文(AS Context)，則以 RRC Resume

Complete訊息（即第五訊息(Message 5)）通知 eNB，此訊息具

有安全性；

- eNB可用RRC Resume Reject訊息拒絕RRC Resume Request；

RRC resume失敗時，eNB可用 RRC Connection Setup使 UE

建立 RRC連線。

R2-162019 Reply LS on Clarifications on RRC Resume Request Response to LS

(R2-161048 / S3-160337) on Clarifications on RRC Resume Request

此聯絡說明(LS)用以通知 SA3、SA2、RAN3有關 RAN2在 RRC

Resume Request的決議，並根據這些決議回答 SA3在 S3-160337所提

出的問題，

包括下列項目：

- eNB用Message 4對 UE提供 NCC；

- 單次傳輸可同時攜帶具有安全性與不具安全性的複數個訊

息；

- 重複使用 RRC reestablishment 的 ShortMAC-I 作為認證代碼

(token)，由 UE以Message 3提供；

21

- 不支援重算金鑰(re-keying)；

- 若 UE 順利恢復接取層內文(AS Context)，則以 RRC Resume

Complete訊息（即Message 5）通知 eNB，此訊息具有安全性；

- eNB可用RRC Resume Reject訊息拒絕RRC Resume Request；

RRC resume失敗時，eNB可用 RRC Connection Setup使 UE

建立 RRC連線；

R2-161745 Email discussion report on Message 3 size for NB-IoT Ericsson

(Rapporteur) report

result of email discussion [NBAH#03] Rel-13 NB_IOT-Core

此提案考慮三種Message 3的使用情境：RRCConnectionRequest、

RRCConnectionReestablishmentRequest 、以及

RRCConnectionResumeRequest（此項目的名稱尚未定案），討論

Message 3所需的長度。

RAN2討論RRCConnectiounResumeRequest應具有的參數與所需

長度，其中又以恢復識別碼(Resume ID)是否必須唯一表示一個 cell

為討論重點。RAN2以舉手表決的方式，採多數決，選擇 64 bits的方

案(即Message 3長度 64 bits，Resume ID 長度 25 bits)。

RRC RESUME, Main Options

80 bits:

- Resume ID 40 bits (unspecified)

- Est Cause 3 bits

- Short MAC-I 16 bits

- DVI 4 bits

- MAC overhead 8 bits

- RRC Overhead 4 bits

- Spare 5 bits

64 bits:

- Resume ID 25 bits (CRNTI + PCI)

- Est Cause 3 bits

- Short MAC-I 16 bits

22

- DVI 4 bits

- MAC overhead 8 bits

- RRC Overhead 4 bits

- Spare 3 bits

R2-161530 Establishment Cause for NB-IoT UE NTT DOCOMO INC.,

KDDI Corporation discussion

此提案建議 eNB應可從要求建立 RRC連線的參數，區分 NB-IoT

的一般報告(normal report)或非 NB-IoT的使用者端資料傳輸。

RAN2討論後，獲得下列協議：

- NB-IoT 的建立 RRC 連線要求，不使用 ”emergency”

或 ”delaytolerantaccess”作為原因(cause)參數的值；

- NB-IoT 的建立 RRC 連線要求， cause 參數的值可以

是 ”mt-Access” 、 “mo-Signalling” 、 ”mo-Data” 、

或 ”mo-ExceptionData”。

- 確認 NB-IoT 在 ASN.1對應的 RRC連線要求，cause參數的值

可擴充。

R2-161254 Report of email discussion [NBAH#05][NBIOT/SI] System

Information Intel Corporation discussion

根據 RAN1的決議：

- “NB-PBCH is transmitted in subframe 0 in every radio frame",

- "time interval where MIB remains unchanged is 640 ms"， and

- " NB-PBCH consists of 8 independently decodable blocks of 80

ms duration”

此提案用於各公司對主資訊區塊(Master Information Block, MIB)

和系統資訊區塊(System Information Block,SIB)的內容與傳送頻率凝

聚共識。

經討論後，RAN2 達成下列與 MIB 和 SIB 傳送週期與內容的相

關協議：

23

- NB-IoT 的系統訊框編號(system frame number, SFN)長度與

LTE 相同，為 10 位元(bits)，週期為 10.24 秒，但 NB-IoT 的

MIB 只會傳送 SFN 中最高位的 4 個 bits (4 most significant

bits)；

- 為了解決超過最大 SFN 長度的週期標示問題，引用 LTE R13

的超系統訊框編號(Hyper System Frame Number, H-SFN)來輔

助，NS-IoT所使用的 H-SFN長度與 LTE R13相同；

- H-SFN以 SIB1傳送；

- 系統資訊的數值標籤(value tag)參數 systemInfoValueTag 的值

域為 INTEGER (0..31)，經由MIB傳送；

- MIB 會有一個 bit 標示存取控制(access control, AC)是激活

(activation)或去激活(deactivation)狀態；

- 基礎的廣播控制通道(Broadcast Control Channel, BCCH)變動

週期的範圍為 40.96秒，需視 RAN1或 RAN2的 SIB設計而決

定是否可展延 BCCH變動週期；

- 若MIB和 SIB1改變，不會造成 BCCH變動；

- NB-IoT的MIB所傳送的 value tag有效期限固定為 24小時；

- R13 NB-IoT只支援下列 SIBs:

SIB1-nb - Cell access/selection, other SIB scheduling

SIB2-nb - radio resource configuration information

SIB3-nb - Cell re-selection information for intra-frequency,

inter-frequency

SIB4-nb - Neighboring cell related information relevant for

intra-frequency cell re-selection

SIB5-nb - Neighboring cell related information relevant for

inter-frequency cell re-selection

SIB16-nb - GPS time and UTC info (we can reuse the LTE SIB16).

SIB14-nb - Access barring

24

對於以呼叫(paging)方式對 UE進行系統資訊通知(SI notification)，

RAN2達成下列相關協議：

- 若 UE使用的非連續接收週期(DRX cycle)大於 BCCH變動週

期， RRC_IDLE 狀態的 UE 不應由

systemInformationModification判斷系統資訊改變；

- 若 UE 使用的 DRX cycle 小於或等於 BCCH 變動週期，

RRC_IDLE狀態的 UE，應根據 systemInformationModification

判斷系統資訊是否發生改變；

- NB-IoT 沿用延伸非連續接收 (Extended Discontinuous

Reception, eDRX)以呼叫方式對 UE 進行系統資訊變更通知的

定義；

R2-161155 Open issues of SI content CATT discussion

此提案建議 R13 的 NB-IoT 只針對分頻雙工(Frequency Division

Duplex, FDD) UE，但不排除之後可支援分時雙工(Time Division

Duplex, TDD) UE；並討論寬頻的量測參數以及用於漫遊的相關參數

之必要性。

RAN2討論後，獲得下列協議：

- R13不支援 TDD，因此不需要 tdd-Config參數；

- ASN.1保留未來支援 TDD NB-IoT的可能性；

- NB-IoT不討論 intraFreqBlackCellList或類似的同頻存取控制、

或 cellSelectionInfo-v1130等參數。

R2-161307 Idle mode mobility in NB-IoT Ericsson discussion

此提案由負載平衡(load balance)出發，討論 LTE 細胞評等(cell

ranking)用於 NB-IoT細胞重選(cell re-selection)所需的調整。

RAN2獲得下列協議：

- 支援 NB-IoT 的 UE，也須支援最大覆蓋加強層級(maximum

coverage enhancement level)；

25

- NB-IoT 支援參考信號接收功率 (Reference Signal Received

Power, RSRP)；

- NB-IoT 是否支援支援參考訊號接收品質 (Reference Signal

Received Quality, RSRQ)量測，仍待討論；

- NB-IoT的細胞適用標準 S準則(criteria S)為同時滿足 Srxlev >

0和 Squal > 0；

- NB-IoT不支援 Qrxlevminoffset以及 Qqualminoffset；

- NB-IoT支援 Qoffsettemp以及相關功能；

- NB-IoT的 criteria S定義為：

- NB-IoT支援同頻段的特定細胞補償(cell specific offsets)，不支

援跨頻段的補償；

- NB-IoT 支援同頻段與跨頻段量測使用不同量測臨界值，即

SIntraSearch和 SnonIntraSearch；

- 若 NB-IoT UE的服務基地台(serving cell)訊號強度與品質皆高

於同頻量測臨界值，則 UE不需要執行同頻量測；

- 若 NB-IoT UE的 serving cell訊號強度與品質皆高於跨頻段量

測臨界值，則 UE不需要執行跨頻段量測；

- 當 NB-IoT UE 的 serving cell 限制存取時，NB-IoT 支援 cell

reselection indicator (intraFreqReselection)，可逕行同頻內重選

非限制存取的可用基地台進行連線；

- RAN2 假設 NB-IoT支援搜尋更高優先權的公用陸地移動網路

(Public Land Mobile Network, PLMN)；

- RAN2假設 NB-IoT支援手動選擇 PLMN。

R2-161384 Idle Mode Mobility Huawei, HiSilicon, Neul discussion

Srxlev = Qrxlevmeas – Qrxlevmin - Qoffsettemp – Pcompensation (FFS)

FFS: Squal = Qqualmeas – Qqualmin – Qoffsettemp

26

此提案分別以是否跨運營商、以及 UE 是否支援覆蓋增強

(coverage enhancement)，討論 cell selection和 cell reselection的標準

(criteria)。決議如下：

- 對於 cell selection，只有一套 S criteria，不區分一般覆蓋(normal

coverage)或延伸覆蓋(extended coverage)。

R2-161413 E-Mail Discussion and companies view on Inter Frequency Load

Balancing Vodafone GmbH report

此提案分別就 RRC_IDLE 和 RRC_CONNECTED兩種模式，收

集各公司對於是否支援負載平衡、以及達成負載平衡的方法之意見。

決議如下：

- 以細胞評等的方法，用於 NB-IoT的跨頻段細胞搜尋；

- 不支援以優先權為基礎的跨頻段移動；

- 以重新導向的方式達到負載平衡，並以 RRC 訊息傳送重新導

向的資訊；

- RRC connection release或 RRC connection suspend包含重新導

向的資訊。

R2-161386 Paging Stage 3 Analysis Huawei, HiSilicon, Neul

discussion

呼叫(paging)和系統資訊(system information)的 value tag參數，都

可讓 UE在建立 RRC連線之前，獲知系統資訊是否有改變；而 paging

的方式，需要藉由 DRX或 eDRX的方式使 RRC_IDLE模式的 UE保

持可聯繫(reachable)。

本提案列出需要討論的 paging相關議題，包括 paging DRX cycle、

以及 paging訊息的內容。

RAN2討論之後，獲得下列協議：

- eDRX是自選項目(optional)；

- 一個訊框(frame)為 10ms；

- SFN (System Frame Number)的範圍為 0~4095；

27

- HSFN (Hyper SFN)的範圍與 LTE R13的定義相同(10 bits)；

- 最大 paging eDRX cycle是 1024個 hyper frames；

- 使用 LTE R12的呼叫時機(paging occasion, PO)算法以計算重

複 paging的起始點；

- 以國際移動用戶識別碼(International Mobile Subscriber Identity,

IMSI)和系統架構演進之暫時移動用戶識別碼(SAE-Temporary

Mobile Subscriber Identity, S-TMSI)作為 paging的用戶識別。

R2-161311 Paging and DRX in Idle mode in NB-IoT Ericsson

discussion

此提案建議 UE根據廣播的 RSRP量測臨界值，而判斷用於偵聽

paging 的覆蓋延伸層級(coverage extension)；並建議在系統資訊中廣

播各延伸層級的窄頻實體下行控制通道 NB-PDCCH 和窄頻實體下行

共用通道(NB-PDSCH)重複次數。

RAN2達成下列協議：

- Paging occasion 參考開始重複 NB-PDCCH 的子訊框

(subframe)；

- RAN2 假設能以廣播的方式，協助 UE 在不同覆蓋層級接收

paging；

- RAN2假設從 MME傳送到 eNB的 paging訊息，不包含 short

DRX cycle length；

- RAN2假設NB-IoT paging可使用 S1介面的 eDRX paging資訊，

例如 eDRX cycle或呼叫傳送週期(Paging Transmission Window

Time, PTWT)；

R2-161312 Physical channels for paging in NB-IoT Ericsson discussion

此提案討論使用實體通道（包括 NB-PDCCH和 NB-PDSCH）對

UE通知系統資訊變更。

RAN2達成的協議如下：

28

- NB-IoT可使用單一 paging訊息，同時呼叫多個 UEs；

- UE 用呼叫無線網路暫時識別碼(Paging RNTI, P-RNTI)偵聽

NB-PDCCH的 paging。

R2-161387 Random Access Procedure Huawei, HiSilicon, Neul

discussion

此提案建議 NB-IoT 只需支援競爭型(contention based)的隨機存

取(random access)程序；在競爭基礎的隨機存取程序中，根據覆蓋層

級(coverage level)而選擇前置符元群組(preamble group)。此外，此提

案雖未討論隨機存取無線網路暫時識別碼 (random access RNTI,

RA-RNTI)，但建議新定義 NB-IoT所需的 RA-RNTI計算方法。

RAN2的協議如下：

- NB-IoT只支援競爭基礎的隨機存取程序；

- RAN2假設下行資料接收需支援 PDCCH 指派(order)；

- UE根據 coverage level而選擇 preamble group。

R2-161391 Analysis on preamble transmission related issues in NB-IoT ZTE

Corporation discussion

此提案討論 RA-RNTI的計算方法。決議如下：

- NB-IoT的隨機存取回應時窗(random access response window)

應比 R12的時窗更長；

- 設計 RA-RNTI 計算方法時，應考慮特定實體隨機存取通道

(Physical Random Access Channel, PRACH)的第一個無線電訊

框(radio frame)之系統訊框指標(system frame index)；

RAN2協議 NB-IoT的 RA-RNTI計算方法可定義如下：

- RA-RNTI calculation formula may be defined as follows (FFS):

o RA-RNTI=1+t_id + 10*freTone_id + k1*(SFN mod (W/10)), with the

Code information in the RAR, OR

o RA-RNTI=1+t_id+10*(SFN mod (W/10), with the Tone information

in the RAR,

Where:

29

o t_id is the index of the first subframe of the specified PRACH (0≤

t_id <10) within an attempt,

o freTone_id is the index of the specified frequency resource

location within that subframe, in ascending order of frequency

domain (the range of freTone_id can be configured, e.g.

0≤freTone_id <12, if 15kHz Single Tone is used),

o SFN is the index of the first radio frame of the specified PRACH,

o W is RAR MAX window size (in subframes).

o K1 depends on the number for freq tones.

R2-161153 Volume indication for NB-IoT data CATT discussion

此提案考量在建立連線之前，可藉由指示待傳輸資料量的多寡，

協助 eNB判斷連線建立方式。


- NB-IoT可在Message 3傳送資料量指示(volume indication)；

- 控制平面方案與用戶平面方案使用相同的 volume indication機

制。

R2-161941 RAN1-RAN2 sync on Scheduling and HARQ design for NB-IoT

Disc Ericsson

此提案根據 RAN1的協議，討論 RAN2在MAC層的排程和混合

型自動重傳請求(HARQ)相關設計。


- 上行與下行的資料傳輸排程資訊皆以窄頻實體下行控制通道

(NB-PDCCH)傳送；

- 已被排程的上行資料由窄頻實體上行共用通道(NB-PUSCH)傳

送；已被排程的下行資料由窄頻實體下行共用通道

(NB-PDSCH)傳送；

- 窄頻段物聯網只支援跨子訊框(cross-subframe)的排程方式，不

支援相同子訊框(same-subframe)的排程方式；

30

- NB-PDCCH、NB-PDSCH、NB-PUSCH 的傳輸期(transmission

duration)皆可用子訊框的數量表示；

- NB-PDCCH 的傳輸期以子訊框的數量表示，數值為半固定

(semi-static)， NB-PDSCH 或 NB-PUSCH 的排程資訊由

NB-PDCCH傳送；

- NB-PDSCH 或 NB-PUSCH 相對於 NB-PDCCH 的起始時間屬

於排程資訊的一部份；

- 下行 HARQ 的回饋資訊由上行的實體通道傳送（尚未決定使

用哪個實體通道）；上行 HARQ 的回饋資訊由 NB-PDCCH 傳

送；

- UE不可因為未在 NB-PDCCH收到上行 HARQ的回饋資訊，

而引發上行 HARQ重傳；

- 上行與下行的 HARQ重傳皆為非對稱性。

R2-161643 RLC AM considerations for NB-IoT Ericsson discussion

之前會期決議 NB-IoT 只支援無線鏈路控制(RLC)的回報模式

(acknowledge mode, AM)模式。此提案建議使用 R12 LTE的 RLC AM

功能，並提出藉由計數器與參數的方式，為 NB-IoT功能改善 RLC AM

效能。


- 確認 RLC AM功能適用於 NB-IoT，包括依序傳送(in-sequence

delivery)、以及偵測重複 (duplicate detection)、重新分割

(re-segmentation)的功能；

- 確認 NB-IoT的用戶平面方案支援 RLC重建的功能，但控制平

面方案則無此需求；

- 確認 NB-IoT的用戶平面方案支援 PDCP重建的功能，但控制

平面方案則無此需求；

- NB-IoT的 t-PollRetransmit計數器，根據不同覆蓋層級而使用

不同內建值；

31

- RAN2決議認為：若對 UE輪詢(poll)，則也要搭配對應的上行

許可，使 UE可利用該上行許可傳送狀態報告(Status Report)；

亦即，受到輪詢的 UE不需要為了傳送狀態報告而產生排程要

求(scheduling request)；

- RAN2決議認為：邏輯通道排程要求(logical channel scheduling

request)的禁止計數器(prohibit timer)可達到上述功能；

- NB-IoT 支援此禁止計數器，因此當 UE 已執行排程要求，不

須傳送上行許可給 UE；

- 支援邏輯通道排程要求的禁止計數器為 NB-IoT UE 之必要功

能。

4. 機器型態通訊於 LTE實體層的進一步增強(Furhter LTE Physical

Layer Enhancements for MTC, eMTC)

在資料控制部分，RAN2討論當隨機存取程序在競爭階段失敗後

要如何選取下一個隨機程序要傳送的控制碼，有的公司提案當競爭階

段失敗時，UE 移動到下一個等級，根據下一個等級的參數，選擇隨

機程序要傳送的控制碼，但其他公司提醒 RAN2原本已經決定當競爭

阰段失敗時，UE 要停留在原本的等級，不需要跳到下一個等級，所

以最後這個提案沒被接受。

另外因為基地台會設定UE要連續重傳隨機程序的控制碼多少次，

因此 UE會連續多次重傳隨機程序的控制碼，因此有一件必需釐清，

要在何時開始接收隨機存取回應，這有兩個選項，第一個選項是當傳

完控制碼後，馬上開始，第二個選項是當重傳完後再開始，最後 RAN2

決定要重傳完後再開始接收隨機存取回應。

另外基地台也會重複傳送隨機存取回應，但重複傳送中的第一次

傳送的時間則是由基地台決定並告訴 UE，這個第一次傳送的時間點

稱為開始點，所以應該當 UE重複傳送隨機存機控制碼完後，理應要

在之後出現的第一個開始點接收隨機存取回應，而不是照舊版標準規

32

格，等三個 subframe 後就可以開始接收隨機存取回應，但有些公司

說他們不想太複雜的設計，所以還是維持舊版的方法，只要等三個

subframe後就開始接收隨機存取回應。

UE 在接收隨機存取回應時，必需先算出一隨機存取無線網路暫

時識別碼 (Random Access-Radio Network Temporary Identifier,

RA-RNTI)，用以驗證是否接收到的是 UE 想要的隨機存取回應，

RA-RNTI 是根據傳送隨機存取控制碼的時間以及頻率來計算，但本

會期則有公司建議要把目前所在的等級等也列入產生 RA-RNTI 的公

式，最後只有把系統訊框編號(SFN)考慮進來，新的公式如下：

在設定隨機程序控制碼的傳送功率方面，有其他公司有不同於原

本標準規格的想法，RAN2目前同意引進一個計數器，用來計算在某

一個等級裏，隨機程序控制碼已經傳送多少次，而原本就有一個計數

器在計算 UE總共重傳隨機程序控制碼多少次，這個重傳次數在之前

的標準規格裏被用來設定傳送隨機存取控器碼的能量大小，但現在有

公司建議應該用在某一個等級裏重傳的次數作為設定能量大小的依

據，而不是 UE總共重傳的次數，最後經過辯論後決定還是用 UE總

共重傳的次數來設定傳送功率的大小。

在上次的 email討論裏，各家公司有針對上行資料重送時，基地

台要如何告知 UE，因為 RAN1 上行資料重送的機制為非同步傳送，

而且 MTC 也不支援基地台傳送混合型自動重傳請求 (Hybrid

Automatic Repeat request, HARQ)確認(Acknowledge, ACK)或否定確

認(Negative Acknowledge, NACK)給 UE，所以 RAN2同意如果基地台

要 UE 重送上行資料，則必需傳送下行控制資訊給 UE，告知 UE 是

否執行資料重送。

另外一個重要的議題是有關要不要清除 HARQ 的暫存器資料。

在同步重傳的機制裏，如果有資料在 HARQ的暫存器裏，則 UE會自

RA-RNTI=1+t_id + 10*f_id + 60*(SFN_id mod (Wmax/10))

33

動執行重傳，但現在上行資料重傳機制是非同步傳送，所以 UE不能

自己執行自動重傳，所以可以不清除 HARQ 的暫存器，只有當時序

校準計時器(Timing Alignment Timer, TAT)計數歸零時，UE才會清除

HARQ的暫存器內容。

此外，原本 UE是根據上行資料重傳次數來決定何時清除 HARQ

的暫存器，如依據上述決議，而那麼 UE還需不需要計數重傳次數？

目前非連續接收(Discontinuous Reception, DRX)也根據重傳次數作為

判別是否要讀取 PDCCH的條件之一，最後 RAN2同意 UE不需計數

重傳次數，但引進兩個計時器分別為上行混合型自動重傳請求來回計

時器(UL HARQ RTT Timer)和上行非連續接收上行重傳計時器(DRX

UL Retransmission Timer)，這兩個計時器類似下行的 DL HARQ RTT

Timer和 DRX DL retransmission timer。

七、心得與建議

多載波負載分佈(MCLD)的議題，已針對其所新設計的功能，再

次檢視其運作的可行性，包含用戶設備和網路端的修正，此會期順利

處理再選方案運作和優先順序權值擴充功能，於規格書中的相關書寫

與修正，因此未來須注意此技術的商業運用情境。

授權頻帶輔助存取(LAA)的議題，仍在繼續討論發展中，除目前

已討論的下行傳輸設計外，也開始討論上行傳輸的可能性，因此未來

更要注意其技術的延伸，以及整體授權頻帶輔助存取技術發展走向。

窄頻物聯網(NB-IoT)的議題，控制平面方案相關的議題已初步完

成；用戶平面方案則仍有部分通訊協定細節待修訂。此議題衍生之終

端設備節能方案、以及 RRC_IDLE 狀態的終端設備可聯繫性，符合

物聯網應用情境的低耗能、低傳輸量需求。值得注意的是此議題所發

展之窄頻段接取網路技術，與 GSM頻段回收利用，是否可創造維運

效益；以及是否因此發展出不同的應用情境與技術需求。

34

這次會討論很多有關 eMTC的議題而且大部分都有決議，eMTC

接下來會花一些時間在校訂標準規格上面，所以也應該快制定完成

了。

RAN plenary已經通過一些 Rel-14的工作項目(work item)，例如

LAA方面 RAN plenary已經通過 R14的 LAA work item，由 RAN1在

這次會期先討論有關 LAA 上行的部分，RAN2 則從下次開始討論，

到時候會有比較的議題需要討論。

另外 RAN plenary也在討論 5G的內容，預料討論完 5G的需求

和可能的應用場景後，將會有 5G的工作項目開始被提出，到時就會

有更詳細的 5G討論．

3GPP RAN2 #93

Documents