出國報告（出國類別：其他）

3GPP TSG RAN WG2 #75

會議報告

出國人員：陳俊嘉、邱俊淵、王竣彥、吳志祥、

陳德明、Mamadou Kone、張博裕、

陳秋紋、劉舒慈、許俊彥、蘇志偉

派赴國家：希臘/雅典

出國期間：100年 8月 20日至

100年 8月 28日

報告日期：100年 9月 30日

2

摘 要

本次 3GPP TSG RAN1與 RAN2會議於 希臘/雅典舉行，本研發團隊依規劃有

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

技術貢獻：

在這次會議，本團隊共有 12篇 RAN2 contributions。RAN2的標準貢獻提案中，

有 2篇被討論，1篇被接受。

會議解說：

本團隊掌握目前 LTE/LTE-Advanced的各項進度，尤其是在 MTC、Relay等議

題上。在 Relay 部分，則繼續延續 Rel-10 的現有架構做修正，以及 L2

measurement的相關討論。MTC討論的重點則在於利用 Extended Access Barring

(EAB)的設計，來避免 RAN overload 的機制。另外，RAN2 Chairman /

Vice-chairmen也在本次會議中進行改選。最後由 Ericsson拿下 Chairman的職

位；由 Huawei當選 UMTS session的副主席；LG當選 LTE session的副主席。

3GPP LTE-Advanced：

3GPP為配合 ITU-R IMT-Advanced標準評選時程，相對應地準備以

LTE-Advanced作為將來提案至 ITU-R的候選系統。經過 2010與 2011年 RAN2

會議的討論，目前 LTE-Advanced 的系統技術規格 Stage 3標準制定已完成。

3GPP RAN工作群組將針對 LTE-Advanced Release 10系統規格做改進，目前

3

已展開相關要求與技術的討論。本研發團隊為掌握目前 LTE-Advanced Release

11的各項進度，為未來規畫參與 3GPP LTE-Advanced之標準制定預作準備，

此次派出多位成員出席，期能充份掌握會議期間，各個並行會議之最新發展狀

況。

3GPP LTE：

現階段 LTE標準已進入 Stage 3，PHY Layer部分已在細節、小部分修訂，

此部分工作以掌握現況為主；MAC、RLC、PDCP、RRC release 10及 release 11

的部份，而 release 10功能大致上都已經完成，現在在做細部的修定，因此，

參與同仁將會視情況適時提出技術提案。

4

目 錄

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

一、會議名稱............................................................................................ 5

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

三、會議時間............................................................................................ 5

四、會議地點............................................................................................ 5

五、會議議程............................................................................................ 5

六、會議紀要............................................................................................ 8

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

5

一、會議名稱

3GPP TSG RAN2 #75 Meeting

二、參加會議目的及效益

參與 LTE-A、Carrier aggregation、CA enhancement、Relay、eICIC、LPP、

MTC、eICIC、與MDT等討論及尋找可研究的題目

報告本團隊所發表的文章

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

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

三、會議時間

22 Aug - 26 Aug 2011

四、會議地點

Hotel Athenaeum InterContinental (Athens, Greece)

五、會議議程

RAN2的會議議程如下 (22 Aug - 26 Aug 2011):

IndicativeTime-schedule

Main room UMTS room

Mon 09:00 -> [2],[3],[4]

Tue 08:30 -> Rel-89 [5] Rel-10 [6]

[8 non-TDD][8, 9.7 TDD only]

Wed 8:30 -> CAenh[7.1]DivData[7.2]

[9.2][9.4][9.5][9.7 non-TDD][9.8][10.1]

Thu 8:30 -> MBMS [7.3]eICIC [7.5]Indev [7.7]NBP[7.4]

[10.2][10.3][10.6]After Lunch:

6

Hetnet mob[7.8] Comebacks[10.4][10.5][10.7]

Fri 8:30 -> Comebacks[14] if time allows

Fri: lunch -> until 5pm

Hetnet mob[7.8]Left-overs, Comebacks, [12][13][14]

7

1. Opening of the meeting

2. General

3. Incoming liaisons

4. UMTS/LTE joint session

4.1 LTE Release 9 and earlier releases

4.2 Release 10

4.3 Release 11

5. LTE Release 9 and earlier releases

6. LTE Release 10

6.1 WI: Carrier aggregation (RP-100661), UL-MIMO, eDL-MIMO

6.1.1 Stage-2 / Stage-3 Common

6.1.2 Stage-3 Control Plane

6.1.3 Stage-3 User Plane

6.2 WI: Relays (RP-110911)

6.3 WI: MBMS enhancements (RP-101244)

6.4 WI: Minimisation of Drive Test (RP-100360)

6.5 WI: eICIC (RP-100383)

6.6 WI: TEI10

6.7 WI: Other LTE Rel-10 WIs

6.8 Other LTE Rel-10 topics

7. LTE Release 11

7.1 WI: CA enhancements (RP-110732)

7.2 WI: Enhancements for diverse data applications (RP-110454)

7.3 WI: Service continuity improvements/location info for MBMS (RP-110452)

7.4 WI: Network-Based positioning Support for LTE (RP-101446)

7.5 WI: Further Enhanced Non CA-based ICIC for LTE (RP-110824)

7.6 WI: Other Rel-11 WIs

7.7 SI: In-device coexistence interference avoidance (RP-100671)

7.8 SI: Hetnet mobility enhancements (RP-110709)

7.9 SI: RAN improvements for Machine Type Comm (SI: RP-100330)

7.10 SI: Other Rel-11 Sis

8. UTRA Release 9 and earlier releases

9. UTRA Release 10

9.1 WI: LCR TDD MC-HSUPA (RP-090990)

9.2 WI: 4C-HSDPA (RP-100991)

9.3 WI: RF pattern matching in UMTS (RP-091427)

9.4 WI: Minimisation of Drive Test (RP-100360)

9.5 WI: ANR for UTRA (RP-100688)

8

9.6 WI: Interfrequency detected set measurements (RP-101015)

9.7 WI: TEI10

10. UTRA Release 11

10.1 WI: Further enhancements to CELL_FACH (RP-110913)

10.2 WI: 8C-HSDPA (RP-101419)

10.3 WI: Other Rel-11 WIs

10.4 SI: HSDPA multi-point transmission (RP-101439)

10.5 SI: UL MIMO (RP-101432)

10.6 SI: RAN improvements for Machine Type Comm (SI: RP-100330)

10.7 SI: Other Rel-11 SIs

11. Outgoing LS and email discussions for UTRA

12. Left-overs

13. Outgoing LS and output to other groups for LTE/joint

14. Any other business

15. Closing of the meeting

六、會議紀要

1. Machine Type Communication (MTC)

此次會議有關MTC的討論分為核心網路負載(Rel-10 WI，RP-101026)和接

取網路負載(Rel-11 SI，RP-100300)兩大議題。

Agenda item: 4.2.2 WI: RAN mechanisms to avoid CN overload due to MTC (RP-101026)

關於核心網路負載的議題，目前的標準規範中， eNB 可以用

RRCConnectionRelease 裡的 extendedWaitTime 來告知 UE，核心網路目前處於

超載且需要 UE等待一段時間才能再次嘗試建立連線至核心網路的訊息。然而

在 UMTS系統下，由於 UE可能同時建立 PS和 CS兩個不同核心網路領域的連

線，用目前的 RRCConnectionRelease並沒有辦法告知 UE是那種核心網路發生

超載。為了避免 ASN.1 的改變，RAN2 在上次的會議中決定不採用在

9

RRCConnectionRelease 裡加入 domain indicator 的方法來解決這個問題。因此

RAN2在此次會議討論了其他可能的解決方法如下：

1. 根據 RRCConnectionRelease 所對應的 RRCConnectionRequest 裡的 domain

indicator來決定(參考 R2-114151，NSN)。

2. 根據上一個配置的核心網路領域來決定(參考 R2-113992，Huawei)。

3. 當 PS 和 CS 同時存在時， eNB 用 SignallingConnectionRelease 裡的

extendedWaitTime和 cn-DomainIdentity來告知UE那個核心網路發生超載(參

考 R2-113973，CATT)。

由於方法 2和方法 3都必須修改目前的標準以規範 eNB的行為來達到解決

此問題的目的，經過各間公司於休息時間短暫的交換意見過後，均一致同意採

用不必做任何修改的方法 1來解決這個問題。整個議題最後的決議如下：

Agreements:

1) If the timer is included in the connection release, it will apply to the domain indicated in the connection request.

2) No need to forward information on domain from connection request in SRNS relocation, since

assumption is that this connection release will typically be used quickly after connection request

(in case of after SRNS relocation, network will have to use SCR to address a specific domain).

R2-114567: CN Domain for eWaitTime Nokia Siemens Networks, Nokia Corporation CR

主要提出在 UMTS中，UE會先在 RRC CONNRECTION REQUEST中帶

delay tolerant access 的資訊，當 eWaitTime 包含在 RRC CONNECTION

RELEASE訊息時，UE會將收到的 eWaitTime傳送到 NAS layer。然而 CS與

10

PS 是否共用同一套 EPC 此篇提案並未說明清楚。QC 則擔心若在 connection

release 收到前，request 的 indication 就移除，會不會造成錯誤的情況發生，想

要討論其他 error free 的方法。NSN 等其他家公司則認為應著重在 RAN2 的

agreement上，所以本篇 CR最後一致通過贊成。

R2-113971: Clarification of supporting delay tolerant access CATT CR

提出在 LTE中，若 RRC訊息夾帶 extendedWaitTime時，則代表此為一 delay

tolerant access的連線。然而其欲新增的文字被大部分的公司認為是不需要的，

所以其欲新增"support delay tolerant access"的文字反而容易混淆，因此此篇提案

未被採納。

Agenda item: 4.3.1 SI: RAN improvements for Machine Type communication (RP-100330)

根據 RAN#52的決議：RAN improvements for Machine Type communication

這個 SI將延續討論到 2011年九月，但是將主要著重於"RAN overload handling"

的討論。joint UMTS/LTE的提案，例如：scenario related contributions, generic

solutions,...等則在 agenda item 4.3.1中討論；LTE specific solutions在 agenda item

7.9中討論；UMTS specific solutions則在 agenda item 10.6中討論。然而，這次

會議因為時程的關係，所以 agenda item 7.9與 10.6尚未被討論，本次會議主要

著重在 joint UMTS/LTE中 RAN improvement的討論，討論內容如下：

R2-113985: Text proposal for TR 37.868 to conclude the study on RAN overload control

11

Huawei, HiSilicon TP 37.868

QualComm認為還需要一點時間review加以確認，並提出想要移除"without

the need to introduce any new access classes"。然而ZTE等公司則認為SA1的

主要共識就是不用新的AC，所以否決了QualComm的要求。QualComm則提

出因為新的EAB參數只是用MTC devices所以還是需要有一個新的AC來區

分不同的服務，DT則認為AC的定義已非常清楚，所以不需要。最後在各公

司的討論下決議：加入”FFS whether we can avoid duplicating all EAB

information to limit the overhead on broadcast”的文字說明，並以此為TR

37.868 v1.0.0，送至RAN group中。

在 Extended Access Barring (EAB)的討論中，由於 EAB 是來避免 RAN

overload的機制，因此設計前提是要能夠將大量、同時進入網路的MTC設備阻

擋在網路系統之外。討論內容大致可分成「一個 UE 是否一定適用(或不適

用)EAB？」、「EAB應該在 AS還是 NAS控制？」、「EAB的內容為何？」、「多

個 PLMN共享 RAN時的特殊考量」、「EAB改變的頻率？」等等，分述如下：

在 RAN2 #73b 的會議中決定採用擴充的存取限制 (Extended Access

Barring，EAB)作為主要的方法，並在上次的會議中決定了由 BCCH來廣播 EAB

的資訊。因此 RAN2在此次會議就針對 EAB的各項細部議題做進一步的討論，

包括：

12

1. 當 UE配置 EAB但卻擁有特別的存取等級(如 AC11-15)時，是任何的連線建

立請求都可以忽略 EAB？還是根據連線對應的上層應用而定？相反的，當 UE

配置 EAB且只擁有普通的存取等級(如 AC0-9)時，是任何的連線建立請求都必

須遵循 EAB？還是根據連線對應的上層應用而定？

2. 如果當 UE 配置 EAB 且遵循 EAB 與否只跟是否擁有特別的存取等級有關

時，UE是否可以根據上層應用來動態的決定是否配置 EAB？

3. 如果存取網路的動作通過 EAB 之後，是否還需要遵循舊有的存取等級限制

(Access Class Barring，ACB)機制？

4. 應該在 AS層還是在 NAS層運作 EAB機制？

5. EAB機制應該包含那些參數？

6. 當考慮 EAB 也可應用於核心網路負載的問題時，在不同的核心網路業者共

用相同接取網路的架構下，EAB該如何運作？

7. EAB的更新與獲取機制？

其中問題 1 和問題 2 需要 SA1和 CT1討論，因此最後 RAN2決議送一個

LS (參考 R2-114570) 到 SA1和 CT1詢問。另外關於問題 3和問題 6較無爭議，

前者 RAN2 決議與 Rel-10 一致，後者 RAN2 決議 EAB 資訊可以是

PLMN-specific，最後同意的文字如下：

Agreements:

0: RAN2 assumes that somehow per RRC connection establishment, AS will know whether to apply EAB or not

- this is a requirement if EAB is applied in AS, otherwise it is not needed.

13

3: If access is not barred by EAB then UE shall be subject to the legacy ACB.

4: In the case of multiple core networks sharing the same access network, EAB information can be PLMN

specific. FFS whether we can avoid duplicating all EAB information to limit the overhead on broadcast.

關於問題 4，此次會議討論了兩篇提案:

R2-113766: EAB Handling in AS or NAS Nokia Siemens Networks, Nokia Corporation

Disc

R2-114456: EAB model in UE LG Electronics Inc. Disc

在 AS 層或是在 NAS 層運作 EAB 機制都是可行的選項，差別在於如果在

AS層運作 EAB，NAS層需要提供例如是否配置 EAB、UE在所選擇的 PLMN

裡屬於那一個 EAB分類群組等資訊給 AS層。反之，如果在 NAS層運作 EAB，

AS層需要提供從 SIB讀取的 EAB資訊給 NAS層。ZTE和 LG等贊成在 NAS

層的公司主要認為如此方便實現根據上層應用來決定是否遵循 EAB 的機制。

而 Nokia、CATT、Vodafone、Huawei 和 STE 等贊成在 AS 層的公司主要認為

GERAN已經同意在 AS層運作 EAB的機制，必需考量到不同 RATs間的一致

性。RAN2最後決議在 AS層運作 EAB機制，決議內容如下：

Agreements:

1) EAB will be executed at AS layer

關於問題 5，主要有下列 3個可能的選項：

1. UMTS和 LTE的 EAB參數都如同 UMTS的 ACB參數，每個存取等級

用 1個 bit來表示是否限制存取。

2. UMTS和 LTE的 EAB參數都如同 LTE的 ACB參數，根據不同的連線

建立請求原因(establishmentCause)採用不同的 barring factor 和 barring

14

time。

3. UMTS和 LTE的 EAB參數都如同各自的 ACB參數。

支持選項 1的公司如 NSN、NTT DCM、LG、DT和 Vodafone等認為不同 RATs

間的一致性是重要的，而 GERAN的 EAB已經決定每個存取等級用 1個 bit來

表示是否限制存取。此外，這些公司也認為 UMTS 和 LTE 對 EAB 的要求和

GERAN相同，所以應該用選項 1就足夠。支持選項 3的公司如 Huawei、ZTE、

Intel、CATT和 Samsung等認為在 LTE只用 1個 bit來表示是否限制存取無法

有效的解決接取網路負載的問題。在 UMTS 可行是因為 UMTS 有其他限制機

制配合，而 LTE並沒有。Qualcomm和 Ericsson則認為這個問題需要進一步的

研究，現在做決定還太早。因此，RAN2最後的決議如下：

Agreements:

1) UMTS: EAB will be 1 bit per AC

2) LTE: EAB will either be 1 bit per AC solution, or a solution conform LTE ACB i.e. probability factor and barring

time.

Note: In general further solutions/mechanisms can always be discussed/proposed based on consensus.

問題 7討論 EAB的更新與獲取機制，主要有下列 4個可能的方法：

(1)延用目前 LTE規範的系統參數更新與獲取機制。

(2)強制 UE存取網路前一定要更新 EAB參數。

(3)用類似目前 LTE的 ETWS參數更新與獲取機制。

(4)在 RAR內用一個 Indication表示 EAB參數是否有變動。

最後由於時間的關係，問題 7留到下次會議討論。

15

由於接取網路負載(Rel-11 SI，RP-100300)這個研究項目在此次會議後即將

結束，之後會有一個工作項目繼續這部份的標準制定，因此這次會議的最後一

天也完成了最後版本的 TR 37.868 (參考 R2-114815)。很可惜我們有兩篇關於

EAB 更新與獲取機制的提案因為時間的關係沒有討論，不過在最後版本的 TR

37.868裡已經有相關的文字同意了我們提案裡的部分訴求，如下：

5.1.1.2 Extended Access Barring

…

EAB enforcement will be implemented in the UE AS layer and interwork with legacy Access Class Barring, it

should ensure that the corresponding requirement specified in [11] section 4.3.4 could be satisfied. To ensure that the

network can react fast enough to prevent overload in critical scenarios, different alternatives for EAB information

update and acquisition could be considered.

而本次會議其他 EAB提案內容簡述如下：

Is one UE always yes/no “configured for EAB”?

R2-114017: Handling of UE with Special ACs configured with EAB Vodafone Disc

探討適用EAB的UE在使用access class 11-15時的流程。

R2-113987: Further discussion on EAB requirements Huawei, HiSilicon Disc

主張UE config to EAB一定是delay tolerant device，且MTC一定是使用Access

class 0~9。

R2-114549: Further discussion on EAB for RAN overload handling Intel Corporation

Disc

主張1) delay tolerant device一定是 low priority, 2)EAB應該在AS處理, 3)

EAB不需要SSAC，SSAC直接apply ACB與 4) EAB info change不受

16

modification period的限制。

Is EAB handled at AS or NAS?

R2-113766: EAB Handling in AS or NAS Nokia Siemens Networks, Nokia Corporation

Disc

比較EAB在AS與NAS layer處理的差異，並主張EAB應該在AS處理。

R2-114456: EAB model in UE LG Electronics Inc. Disc

主張EAB在NAS處理，當UE在SIB收到EAB info的時候就要在將EAB info

送到NAS。

Contents of EAB:

R2-114530: Is EAB Mechanism Sufficient for RAN Overload Control? CATT Disc

模擬結果發現EAB對access delay的影響極大，須確認是否可以接受這樣的

delay？

R2-114429: Consideration of EAB Institute for Information Industry (III), Coiler Corporation

Disc

主張EAB的設計應該沿用LTE ACB的方式。

R2-113767: EAB content and other related issues Nokia Siemens Networks, Nokia

Corporation Disc

主張EAB的設計應該沿用UMTS ACB的方式。

R2-114391: Integrated Slotted Access with EAB for MTC Alcatel-Lucent, Alcatel-Lucent

Shanghai Bell Disc

17

主張slotted access，並以模擬結果與EAB互相比較。

R2-114275: EAB for MTC traffic Alcatel-Lucent Disc

主張EAB的設計應該沿用UMTS ACB的方式。

R2-114343: Implementing Enhanced Access Barring in UMTS and LTE Renesas Mobile Europe

Ltd. Disc

主張EAB的設計應該沿用LTE ACB的方式，並且不需要SSAC。

R2-113988: General consideration of EAB in LTE Huawei, HiSilicon Disc

討論UE檢查EAB的流程。

R2-113989: General consideration of EAB in UMTS Huawei, HiSilicon Disc

主張EAB在AS處理，並且每一個access class有各自的EAB。

PLMN sharing:

R2-114012: Applicability of EAB in a Shared Network Environment Vodafone Disc

討論在PLMN sharing的情況下，EAB information是否應該要PLMN specific。

R2-113975: Impact to EAB Considering Network Sharing CATT Disc

主張在PLMN sharing的情況下，EAB information不需要PLMN specific。

Speed of change:

R2-113767: EAB content and other related issues Nokia Siemens Networks, Nokia

Corporation Disc

探討EAB應該如何廣播。

R2-114216: Discussion on mechanisms for EAB information update and acquisition ITRI

18

Disc

主張EAB應該放在新的SIB中廣播。

R2-113798: Considerations for EAB ZTE Disc

主張EAB應該允許頻繁的更動，並且需要新的機制來配合。

R2-114395: Detailed description for EAB solutions Samsung Disc

主張EAB應該放在新的SIB中廣播，並且以paging message來通知是否EAB

有更動。

R2-114217: Further discussion on EAB enhancement ITRIDisc

主張UE通過EAB檢查之後，還需要backoff才能去access network。

Other mechanisms:

R2-114458: Discussion on RAN overload solution LG Electronics Inc. Disc

主張在RAR中指定extended backoff時間。

R2-114396: Overview for RACH enhancement Samsung Disc

主張使用pre-backoff來避免RAN overload。

R2-114508: Way forward for pull based approach LG Electronics Inc. Disc

主張pull based approach來避免RAN overloadd。

R2-114161: Is EAB enough to control RACH overload? LG Electronics Inc. Disc

認為EAB並不足以解決RACH overload的問題。

19

2. WI: Relays (RP-101417)

由於上次 RAN Plenary 並無新的 SID 或是 WID 被通過，因此，延續之前的

議題，包括原先 Rel-10 的修正部份再討論。

R2-113768: Addition of L2 measurements for Data Loss for RNs Nokia Siemens Networks,

Nokia Corporation, Huawei, Ericsson, ST-Ericsson

這篇CR是跟據SA5的決議，在RAN2做相對應的調整。跟據S5-112147的描

述，在Packet loss rate已經通過，要分成eNB 和UEs之間，以及eNB 和RNs

之間的介面做分開量測。其相對應的章節分別是4.1.5.2及4.1.5.3。針對這篇

提案，CATT提出是否應該將4.1.5.2的標題及第一段也做相對應的更正。對

此，NSN提出反駁，覺得不應該將4.1.5.2的標題做更動。最後決議，此篇

CR做調整，並通過新版文件R2-114759。

R2-114528: Correction on PUCCH configuration for Un interface CATT

這篇CR是依據RAN1對PUCCH的設定，提出RAN2也需要相對應的把

PUCCH的設定加入對應的規格書裡。在原本Relay的設定中，缺乏對於

PUCCH的HARQ的ACK資源及程序之描述，因此，需要把RAN2的規格跟

RAN1的規格相調整。在調整過後，CR被准許通過。

R2-114398: Clarification on RN mobility HTC

這篇CR是假設Relay是可以在DeNB間做移動，若Relay仍使用舊的設定，

Relay將無法收到相對應該在新的DeNB在傳送的訊息中所夾帶的資料。

20

Relay在連接的狀態下，Relay需要得到有效的System Information資訊，因此

在handover的時候，Relay將因為轉到新的DeNB而無法取得相關有效的資

訊。因此，本CR是希望Relay在handover到新的DeNB時，可以將舊有的設

定釋放，以便接收新的設定。在討論時，RIM認為RN Mobility仍未是目前

Rel-10的規格，NTT DoCoMo及Huawei亦贊成這個想法，而NSN跟ALU則

是覺得Relay並無支援所有的handover類型，而目前handover的規定並無

HTC所描述的問題。在最後討論過後，本CR並未被接受。

3. Multiple Timing Advance (TA)

接續上次 Multiple timing advance 的討論，本次會議主要針對 Timing

advance timer (TAT)的數目、RACH procedure的相關議題以及 Timing advance

(TA) group reconfiguration…等問題，有了諸多討論其結論如下：

TAT的數目

這個議題上次也有討論過，不過因為還要考慮在 UL asynchronous 下，如

何防止 SRS的傳輸，所以這次會議繼續討論。因為上次通過 TA group的概

念，所以這個議題的選項，就只剩下兩個:

A. TAT per UEB. TAT per TA group

針對這各兩選項，分別討論了兩篇提案:

R2-114170: Single TAT for multiple TA Ericsson, ST-Ericsson Disc

R2-114265: TAT Operation in LTE R11 CA InterDigital Communications Disc

Ericsson主張一個 TAT就夠了，因為只需要維持 UE的 UL 同步，eNB會

21

知道哪些 UL CC是有同步，哪些沒有同步，完全由 eNB來維持 UL CC的

同步與否。另外一些公司則主張是一個 TA group 有一個 TAT。每一個 TA

group的 UL CC同步與否完全由一個 TAT來控制。在這個議題中，大多數

公司都贊成一個 TA group有一個 TAT。接著就是，是否每一個 TA group會

有自己的 TAT值。關於這個議題，有公司考慮小 cell的情況，TAT可能可

以設小一點，也有公司想要設為無限大，這樣就會跟一個 TAT一樣。但是

也有公司認為 TAT 跟 UE的移動有關係，所以值應該都要一樣大，最後，

先決議可以有不同的值。當 PCell TAG 的 TA timer 逾時，UE 必須遵行

Rel-10上的所有步驟，包括：release PUCCH/SRS…等，唯一一個不一樣的

是: SCell上的 SRS configuration是否需要 release。目前這個部分還有爭議，

所以就放入 FFS。整個議題最後的決議如下：

Agreements:

1a) Will go for solution with one TAT per TAG

1b) Will enable usage of separate values for the different TAG's

2: When the TAT associated with Pcell expires, all TAT's are considered expired i.e. and the UE follows

the R10 behavior, i.e. the UE flushes all HARQ buffers, clears any configured assignments/grants,

and RRC releases PUCCH/SRS for all configured serving cells.

4: When the TAT associated with an Scell TAG expires,

- SRS transmissions in Scell TAG shall be stopped (FFS if SRS configuration is released)

- CQI/PMI/RI reporting configuration for the SCells is maintained.

- MAC flushes all uplink HARQ buffers for the concerned SCells.

RACH procedure

首先是討論有關 RACH 激發的幾個議題:

R2-114319: Parallel RACH Alcatel-Lucent, Alcatel-Lucent Shanghai Bell

22

Disc

這一篇討論是否要支援多個 RACH同時執行。有公司認為這個議題會跟是

否要支援 contention based RA 有關；但是公司認為 UE不需要支援兩個以

上的執行。最後決議如下:

Agreement:

=> Agree the UE does not need to support execution of 2 parallel RACH procedures in parallel.

R2-113994: RACH issues for supporting multiple TAs Huawei, HiSilicon Disc

由於上次會議中，高通(QC)建議賦予 SCell trigger RACH procedure具有相

當助益，例如當這個 SCell 有新的資訊要上傳到基地站(eNB)，因此本次會

議討論了這一篇 Huawei的提案。討論是否支援由 UE發動 RA，目的是因

為 UE有 UL data想要傳輸，但大部分公司認為沒有帶來任何好處，且不需

要，但是有公司認為可以有 load balance的好處，最後決議如下：

Agreements:

=> The UE does not initiate a RA procedure on a SCell in case of new UL data.

If serious problems are found, we can reconsider.

另一個議題是有關 RA procedure中Msg. 2的位置。

R2-113829: Random Access procedure for multiple TA Panasonic Disc

R2-113995: Location of Msg2 for RACH on SCell Huawei, HiSilicon Disc

R2-114320: Contention based RACH for SCellAlcatel-Lucent, Alcatel-Lucent

Shanghai Bell Disc

關於這議題，有三篇文稿被討論，不過這個議題牽涉到是否需要支援

contention based的 RA，還有是否需要支援 cross carrier scheduling。但是關

於這兩個議題，由於大部分公司都贊成需要支援 cross carrier scheduling，且

23

不要支援 contention based RA，但是有公司還是有其它的考量，以至於，目

前只有初步結論，沒有決議；也就是:

1) RACH on Scell with no reliable PDCCH on that Scell (hetnet):

=> Most companies seem to think this should be supported

2) Contention based RACH:

=> Majority of companies seem to think this is not so essential, but should maybe not

exclude this now. ?

因為無法達到有效的決議，所以 Msg.2的位置，就要放入 email discussion

了。這個 email discussion主要要先釐清，是否有需要 cross carrier scheduling

和 contention based RA，然後再把目前可能Msg.2位置的幾個可能方案，減

少到最低。

至於其它相關的 RACH procedure issue，本次會議也討論了一篇如下：

R2-114267: RACH Procedure for SCell TA InterDigitalCommunications

這篇提案建議 UE必須讓 PCell的 RACH procedure擁有最高的優先權，也

就是當 PCell RACH正在進行，此時必須忽略掉所有 PDCCH驅動 SCell去

執行 RACH的命令，或是當 SCell正在執行一個 RACH procedure，如果這

時候有個 PDCCH命令另一個 serving cell(PCell or any SCell) 執行 RACH

procedure，這時 UE必須放棄正在 SCell上執行的 RACH procedure。此提

議未獲多數支持但卻也懸案未了，主席決定可以下次討論。另外一個提議

是希望 UE在 activated SCell上也要執行 Radio Link Monitoring(RLM)，並

且當 SCell發現自己上行通道品質不好的時候(透過 RLM偵測)，SCell不會

24

執行任何 RACH procedure。此提議雖獲 NTT DOCOMO等公司支持，但是

依然沒有在會議上被同意，但是之後都還可能在被討論。

TA group Change

這個議題，延伸上次會期通過的 TA group，主要是要討論，當 TA group成

員中有 TA改變時，eNB如何知道要改變，是否需要透過 UE提供一些資訊，

還是 eNB可以自己偵測，決定哪些 UL CC是屬於同一個 TA group，在這個

議題，有三篇文稿被討論：

R2-114169: Group management for multiple TA Ericsson, ST-Ericsson Disc

R2-113996: TA Group Management Huawei, HiSilicon Disc

R2-113832: Comparison of Uplink Time Alignment Synchronization methods for

SCell TA groups Panasonic

這個議題，有公司提出，UE 可以藉由偵測 DL CC 間時間差的改變，得知

UL CC 的 TA 也會跟著改變，UE 可以提供這個時間差的資訊給 eNB，由

NB來決定是否需要更改 TA group的 member。但是，考慮到 Rel-10的 Pcell

TA group，Rel-10的 TA group 成員無法改變，所以決議 TA group的成員不

能改變，只能針對 Scell TA group。另外，大部分公司覺得 eNB可以藉由

UL transmission和 SRS傳輸，得知哪些 UL CC是屬於同一個 TA group，所

以決議目前沒有很強的理由需要由 UE提供相關的輔助資訊，決議如下：

Agreements:

1) We need to support TAG change except for Pcell.

2) So far no strong need identified for additional assistance information from UE. Discussion can continue.

25

4. PHR reporting

這次會議 Inter digital也提了一篇關於在 Rel-11下 PHR reporting必須有所

修正，雖因為時間不多未獲討論，但還是值得深入探討。

R2-114263: Inter-band and RRH PHR InterDigital Communications

在這篇文件裡提到，由於 Rel-10上行都是 intra-band carrier aggregation，因

此基地站(eNB)能經由個別的 Pcmax,c(configured maximum output power for

the cell)推斷出 UE的 Pcmax(configured maximum output power for the UE)，

因此 UE不必在 PHR裡提供 eNB關於 Pcmax的資訊。然而考慮 Rel-11的

上行通道有可能是 inter-band carrier aggregation，由於不同 band之間的功率

衰退(power reduction)的計算方式是各自獨立的，也就是 MPR、A-MPR、

P-MPR…等參數在不同 band之間都是各自獨立的參數(在 intra-band carrier

aggregation，我們可以將每個 carrier component的MPR(或 A-MPR、P-MPR)

視為同一數值，也就是 MPRc=MPR)。因此，在 Rel-11，eNB 無法單單藉

由個別的 Pcmax,c推論出 UE的 Pcmax。此時，假如 UE做了輸出功率調整，

eNB 將無法自行發現。(也就是當所有的 Pcmax,c 的總和大過 Pcmax 的時

候，UE必須作輸出功率調整，然而 eNB並無法自行推估 UE的 Pcmax，因

此 eNB 沒有辦法判斷 UE 是不是有輸出功率調整的行為產生)。因此 inter

digital認為，在 Rel-11，Pcmax 必須被”適時”的加到 PHR。然而把 Pcmax

納入 PHR裡面，只有在某些時候會有效益(也就是當 inter-band uplink)，因

此如果每次 PHR都納入 Pcmax，則會顯得太多沒有必要的傳輸浪費，因此

在這篇提案，inter digital提出了何時可以考慮將 Pcmax納入 PHR的時機。

詳見此提案。

5. Release 10 Change Requests:

這次會期我們所提出的 CR在會場上討論的情況如下:

R2-114224: Discussion on L2 Re-establishment Order (co-source with New Postcom)

R2-114225: CR regarding the L2 Re-establishment Order (co-source with New Postom)

26

這一篇 discussion & CR主要是討論 RRC 在重建 PDCP & RLC的順序問

題，這個問題曾被 ZTE & New Postcom質疑和提出，然而一直沒有被通過，

我們覺得既然在 RRC SPEC的 requirement裡，明確規定在一個 sub-clause

裡頭，需要照順序執行，這個順序便是應該遵守的。然而在會場上，有些

公司傾向用 RRC, PDCP & RLC實作時的 coordination，讓 PDCP等待，以

避開順序不對而可能導致的問題，於是這篇 CR只有被 noted，沒有被通過。

R2-114226: Clarification regarding speed dependent reselection parameters

我們在這篇 CR 裡提出兩種方法來修改定義錯誤的參數。有兩家公司贊同

我們的方法一，有一家公司贊同我們的方法二，有一家公司認為改和不改

都可以，有一家公司持反對立場，而主席的裁決是 no strong support 所以

只有被 noted。(另一個潛在不改的理由是，這個錯誤在 UMTS的 SPEC也

存在，所以若變更的話，將會變更到許多 SPEC。)

R2-114227: CR regarding SRB1 resuming during RRC connection re-establishment

這篇 CR是關於將 SRB1 resuming移至 security更新後，以避免再次重建的

問題。有許多公司參與這個議題的討論，剛開始手機廠偏向在基地台端解

決這個問題，請基地台不要在還沒收到 response 前送下一個 message 來解

決，而基地台廠商則偏向手機內部作好等待協調的防護措施來解決，後來

經過 offline discussion後，有公司指出，spec有一段話，若採用某一種解讀

方式，可限制了手機的行為而避開此問題。雖然不同公司有不同的解讀方

27

式，但由於有些公司採用了某種可避開問題的解讀方式，所以此篇 CR 只

有被 noted.

R2-114565 Miscellaneous corrections to 37.320

本團隊提案修正規範 37.320 上的一些缺失，在這份提案中，我們對規範

37.320做了四項修正如下：

(1)為了和 stage-3的規範維持一致性，我們將規範 37.320章節 5.1.1.3.2裡

頭的用語 should改成 shall。

(2)改進章節 5.2.1.3 的文字敘述，將”Normal RRC signalling in E-UTRA

procedures are enhanced to support this”改成 ”RRC signalling in E-UTRA

is enhanced to support the reporting of detailed location information”

(3)修正章節 5.2.2和 5.3.2關於 logged MDT描述，修正如以下：

5.2.2 RRC_IDLE

For UE in RRC_IDLE idle state Logged MDT procedures as described in 5.1.1 apply.

Logged MDT measurements retrieval is carriedare sent on Signalling Radio Bearer

SRB2 in RRC_CONNECTED state.

5.3.2 UTRA Idle

For UEs in UTRA Idle mode Logged MDT procedures as described in 5.1.1 apply.

Logged MDT measurements retrieval is carriedare sent on Signalling Radio Bearer

SRB4 in RRC Connected mode.

(4)也是在 5.3.1分別對 logged MDT以及 immediate MDT的描述做修正如

下：

5.3.1 UTRA RRC Connected

In CELL_PCH and URA_PCH states UE supports Logged MDT as described in 5.1.1.

In CELL_DCH state UE supports Immediate MDT as described in 5.1.2. In

CELL_FACH state MDT is not supported in the current release.

28

6. MBMS Service Continuity

R2-114407:Summary of Email Discussion [74#34] - LTE: Rel-11 MBMS Huawei

(Rapporteur) Report

這篇標準貢獻提案討論關於廣播與群播服務連續性的議題，係由 Rapporteur

華偉收集各家公司於 E-Mail Discussion上的意見，整理而成。在這個 E-MAIL

Discussion的討論裡，總共有 23家公司參與此廣播與群播服務連續性議題的討

論，大致的意見可以歸納如下：

有 22家公司認為行動用戶能否在 non-camping的 cell上接收，應該取決

於手機的實作。

有 18 家公司認為閒置狀態的行動用戶，只有當它有興趣的廣播與群播

服務快要開始、或已經開始了，才應該把該廣播與群播服務的頻道設為

最高優先權，

所有公司都同意廣播與群播服務可以在多個頻率上提供。

有 21 家公司表示廣播與群播服務的頻率，在不同位置上可能會有所改

變。

有 18 家公司認為行動用戶應該要被通知有哪些廣播與群播服務在鄰近

的廣播與群播服務頻率上提供。

有 17家公司表示應該在系統廣播訊息裡，加入一個新的參數MBMS

Frequency Indicator，來指明哪些頻率是廣播與群播服務的頻率。

有 22家公司同意應該對現有的 RRC訊息做些修改，以便讓

29

RRC_CONNECTED狀態的用戶，回報其廣播與群播服務的接收狀態。

有 20家公司認為應該由網路端決定單播服務與廣播與群播服務的優先

權。

根據這個 E-MAIL Discussion討論的結果，這次會議為廣播與群播服務的連

續性達成了以下決議：

Agreements:

General:3a: MBMS can be provided on more than one frequency. 3b: While an MBMS service is being received, the mechanisms introduced for service continuity

target an MBMS service provided in the same frequency/same MBSFN area in neighbouring cells.

4: MBMS frequencies may not apply for whole PLMN and may change from one geographic area to another.

5: The UE is provided with necessary information to inform it about which services are provided on neighbour cells of MBMS frequency.- we will ignore in Rel-11 the case that the network would not be able to provide this information (bad luck)FFS if this is also relevant for connected

IDLE:1: Support of MBMS reception in a non-camping cell is left to UE implementation.2: The UE which is interested to receive MBMS service(s) makes the MBMS frequency highest

priority when it intends to receive the MBMS service and a session is already available or about to start via MBSFN.

- FFS how the UE becomes aware of this.

CONN:7: For RRC connected mode UEs, some change to RRC signalling procedures is introduced for the

network to provide continuity of MBMS services during handover8a: UE informs the network that he wants to receive MBMS.

R2-114222:MBMS enhancements for REL-1 (2), Connected Samsung

這篇由 Samsung 所提出的標準貢獻提案，主要是討論當換手的情境發生

時，基地台如何為 RRC_CONNECTED狀態的行動用戶，當決定其接收的基地

台。在某些情況下，行動用戶可能具有單播傳輸的服務，同時又在接收廣播與

群播服務。當這個用戶面臨換手需求時，基地台理當優先將其換手到有提供廣

播與群播服務的基地台。但是某些情況下，該提供廣播與群播服務的基地台可

30

能處於超載(overload)的情況，如果將該用戶換手到該廣播與群播服務的基地

台，這個基地台可能無法滿足這個用戶的單播傳輸的需求。因此，原先服務基

地臺將面臨兩難：到底應該將該用戶換手到有支援廣播與群播服務的基地台，

還是應該將其換手到可支援其單播服務的基地台。透過這篇標準提案的討論，

在本次會議最後達成了底下幾個關於提供 RRC_CONNECTED UE的廣播與群

播服務連續性的結論。

關於MBMS和 unicast之間優先順序的結論：

Agreements:

2 It is up to the UE/ user to decide which service it prioritises i.e. a UE could prioritise MBMS over unicast

3 The objective of the REL-11 service continuity enhancements is to introduce mechanisms that enable the UE to indicate one MBMS frequency it wants to receive

關於 UE 在 RRC_CONNECTED 狀態下，接收廣播與群播服務能力的

結論：

Agreements:

1 Adopt the "network control option" as the basic architecture for the handling of (MBMS) i.e. network is informed about the UE's interest in MBMS by the UE, and then the network tries to ensure that the UE is able to receive MBMS (and unicast services).

2 The UE provides MBMS interest information at the level of a frequency (rather than of an individual service). Other info is FFS.

5 Introduce a new message, the MBMSInterestIndication message, by which the UE indicates its interest in MBMS frequency reception

7 The UE sends the concerned message whenever the interest changes w.r.t. the signalled information- FFS if we can limit signalling further

R2-113914:eMBMS Service Continuity and UE capability Qualcomm Incorporated

這篇由高通(Qualcomm)提出的標準貢獻提案，主要是探討說廣播與群播服

務的行動裝置，可能也具有載波聚合的能力。基地台或許可以透過該用戶回報

31

的載波聚合的能力，來得知除了 PCell 之外，該用戶還可以經由哪些頻率來接

收廣播與群播服務。此次會議也同意這個觀念，並達成了以下決議：

Agreements:

1 Reuse the existing SupportedBandCombination IE to derive MBMS related reception capabilities: I.e. if the network wants to ensure the UE is able to receive MBMS and unicast bearers, it has to ensure that all unicast frequencies and the MBMS frequency are indicated as on supported combination in the SupportedBandCombination signalling.

FFS whether we need additional UE signalling to indicate it supports MBMS reception in only Pcell, or in all frequencies of a bandcombination.

7. Hetnet mobility enhancements

本次會議，各公司也針對 Hetnet mobility 的議題提出各自的模擬結論，以

下是此次會議的共識：

Agreements:

0: TR should clearly indicate that HOF and RLF definitions are different from RRC0': Add the purpose of the calibration clearly in the TR e.g. explaining that in certain cases simulation assumption are simplified to enable calibration1: For the purpose of RLF monitoring, the basic L1 processing configurations should be: L1 sample rate is once every 10ms, theL1 samples are filtered by a linear filter with a sliding window of 200ms.2 When a UE detected a HO failure in state 2, the UE will be removed from the simulation3: For the purpose of PDCCH failure monitoring in state 2, the L1 sample rate is once every 10ms, the L1 samples are filtered by a linear filter with a sliding window of 200ms.4: For the purpose of PDCCH failure monitoring in state 3: the L1 sample rate should be at least two samples during the 40ms (handover execution time) and averaged over 40ms.

The following proposal are carried over from the email discussion:5: For calibration only, companies should use a hotspot simulation circle size of 200 m in diameter for the ISD=500 m case. For the case of ISD = 1732 m, the circle size is FFS.6: Adopt Number of RLFs per UE per second as the metric for logging the RLFs.7: Adopt Ping-pong rate = (number of ping-pongs)/(total number of successful handovers excl. handover failures) [where: a ping-pong is defined in TR36.839 v0.1.0]8: Macro-to-macro handover functions should be simulated, but logging the macro-to-macro handover related metrics is not required. Companies are allowed to log the macro-to-macro handover metrics. However, the macro-to-macro handover results shall be logged separately from the macro/pico results, and the macro-to-macro handovers shall not be included into the total number of handovers for macro/pico HO failure rate calculation.9: Add the clarification on the correlation distance: “NOTE: this is the distance where correlation is 0.5 (not 1/e as defined in TR 36.814 B.1.2.1.1)”.10: At the mean time, whenever there is a handover failure, the time of state should not be logged. For the case of handover failure time-of-stay is not defined currently and is FFS.11: Log the RLF in state 3 is not needed

32

七、心得與建議

在 MTC 的部份，因為 Study item: RAN improvements for Machine Type

communication規畫時程已經屆滿，RAN2在本次會議後將提交 TR 37.868 v1.0.0

至 RAN#53。總結來說，最後同意 EAB 為主要的解決方法。不過實際上 EAB

參數為何，如何運行，如何更新等細節都尚未定案，此部分尚有許多研究的價

值與空間。因此，其後續相關的工作項目仍會是我們關注的焦點。這次除了討

論 EAB 外，CATT 在本會期有一提案，探討是否只需要 EAB 就足以避免

overload，根據其模擬結果顯示 EAB會造成高達 30分鐘的 access delay，這樣

大的 delay 對 MTC 而言是否可以接受，其實是值得再行討論的，然而這不是

RAN2的範疇，所以未來會交由 SA1討論。另外，在多個 PLMN共享一個 RAN

的情況下，EAB可以由各 PLMN各自設定，不過由於 EAB是以廣播（Broadcast）

的方式來通知給 UE，如果每一個 PLMN都各自廣播自己的 EAB，對 RAN可

能造成可觀的廣播負擔，因此如何降低廣播負擔是一個未來需要考慮的課題。

另一方面，繼核心網路負載及接取網路負載的研究告一段落之後，其他 MTC

重要的議題如：如何省電、如何節省硬體成本，如何小資料傳輸最佳化、如何

遠端驅動 MTC 裝置等問題都可能是下一波討論的重點，而我們計畫會提早開

始這些議題的研究。最後，有感於MTC許多議題的討論不僅僅包含 AS層和無

線接取網路，還都涉及了 NAS 層甚至於應用層與核心網路的部分，因此，我

33

們未來也會加強這部分的相關知識。

這次 Relay的討論還是延續 L2量測的討論，並且將會期討論的結果彙整成

相關對規格，並在開會時同意相關規格的更動。由於 L2量測對於 Relay的部份

在 Rel-10最後已討論收斂，而大部份的 Relay討論已經在上次 RAN Plenary的

報告中提到已近完成度，因此 Rel-10部份已確定完成。

Multiple TA 這個議題在這次的會期，感覺沒有很大的進展，大家可以獲得

的共識似乎不多，另一方面，也可能下次會期會換新的主席，所以把這個議題

留待到下一次會期再討論。不過，從公司的文稿中，已經可以看出大部分公司

的傾向，也許下一個會期會有更好的進展。

關於實作 CR (Change Request)的發表和討論，可以看出通訊大廠在 CR的

同意與否，佔有決定性的因素，即便有些 CR的確能修改 spec上的錯誤或混淆，

也有許多廠商贊同，但若大廠沒能完全同意，此 CR可能就只會被 noted，而無

法被 agreed。有鑒於此，日後要努力從系統實作角度，找出 SPEC當中會導致

系統發生嚴重錯誤的問題來提出 CR，使得遭反對的可能性降到最低，並設想

在會場上可能有的反對理由和提問，使得 CR的論述充分而紮實。

另外，在此次 LTE RAN2#75會議中，RAN2共開啟了以下四個關於MBMS

與 CA議題的 E-MAIL discussion討論：

[75#20] – LTE: Capture agreements on Rel-11 Carrier Aggregation enhancements [Nokia]

- Capture agreements on Carrier Aggregation enhancements (multiple timing advance) in CR to

36.300.

34

=> Intended output: Technically endorsed CR to 36.300 in R2-114774 (will not be submitted to RAN)

[75#22] – LTE: Capture agreements on Rel-11 MBMS [Huawei]

- Capture agreements on MBMS Service Continuity in CR to 36.300.

=> Intended output: Technically endorsed CR to 36.300 in R2-114777 (will not be submitted to RAN)

[75#33] – LTE: Carrier Aggregation scenarios and resulting requirements [NTT DCM]

- Discuss deployment scenarios and based on that answer need for cross carrier Msg2 and

contention based access

- Try to reduce the number of possible solutions.

=> Intended output: Email discussion report to RAN#76

[75#35] – LTE: MBMS Service Continuity [Huawei]

- What to broadcast in assistance information? Rely on ESG for session timing and linking MBMS

service to MBSFN service area id? Or broadcast a list of starting/ongoing sessions in other

frequencies?

- Who takes the initiative to release the EPS bearers (and unicast bearers) in case of congestion on

the MBMS layer? Would it concern all unicast bearers or only GBR bearers? How is the bearer

re-established after congestion?

=> Intended output: Email discussion report to RAN#76.

因此，在下一次 RAN2#75bis 會議開始前，我們需密切注意這四個 e-mail

discussion的發展以及相關的內容討論。

經過此次 LTE RAN2#75會議後，各個 work item的細節都大致底定，但是

仍有其他值得討論的議題。本團隊在下次 3GPP RAN2會議開始前，密切觀察

與注意其相關的發展與內容討論。目前 Rel-11有較多的討論議題，我們將持續

密切注意。