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

3GPP RAN2 #82會議報告

出國人員：邱俊淵、陳俊嘉、陳宏鎮、王鴻翔

派赴國家：日本/福岡

出國期間：102年 05月 19日至 102年 05月 25日

報告日期：102年 06月 21日

2

摘 要

本次 3GPP RAN2 #82會議於日本的福岡舉行，本研發團隊依規

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

1. [MTC Enhancements] 目前 SA2 正在討論關於 MTC 小資料傳送

(Small Data and Device Triggering Enhancements，SDDTE)和電源消

耗問題(UE Power Consumptions Optimizations，UEPCOP)的改善方

法，且已經提出許多候選的解決方案並記載於 TR 23.887中。其中

有不少方法會對 RAN層級的通訊協定有影響，因此 RAN2也於上

次會議開始討論這個問題，評估當採用這些方法時 RAN層級的通

訊協定所需要做的改變及其效能。上次會議主要將 TR23.887 內

SDDTE和 UEPCOP方面許多的改善方法各分成 5類和 3類，並決

定了 11 項的評估準則，至於技術評估的細節討論則都留由 email

討論。但因這兩次會議間隔的時間較短，且待討論的技術項目繁

多的關係，email討論後並未能有較明確的結論。因此，此次 RAN2

會議在這個議題上最主要的目的就是延續 email 討論完成技術評

估的細節。而我們這次任務的主要目的則是向各間公司更清楚的

釐清我們在 email討論裡提出的看法，同時透過與各公司的討論進

一步分析不同解決方法的優缺點，以期能掌握此議題未來的技術

風向。

2. [HetNet Mobility Enhancements] 異 質 網 路 (Heterogeneous

Network, HetNet)是指宏基地台(macro eNB)下佈建不同功率或低

功率的基地台，此次會議主要的工作在於解決異質網路間的兩項

主要議題，分別是異頻小細胞偵測方法的改良(Improved Small Cell

Discovery)以及無線鏈接失敗後之回復改良 (Improvements to

recovery from RLF)，由於這兩項議題都有多個可能的解決方式存

在，因此主要的任務乃是透過與各公司的討論，分析與探討不同

解決方式的優劣，以期能預先掌握未來 Rel-12 中可能導入的增強

3

與改善技術，並獲取更多此項議題的相關資訊，以做為未來研究

方向參考之用。

3. [Small Cell Enhancements – Higher Layer] 微小區網路的增強主要

是針對宏小區上的流量卸載(offloading)至微小區(small cell)，本次

的討論著重在可能的技術挑戰與可能的解決方法；另一個議題則

是不同基地台間的無線電資源聚合 (Inter-Node Radio Resource

Plane) 架構的討論。由於 CP 架構與 UP 架構相當多元，所以這

次的任務主要是和其它公司討論這兩個架構的所有可能通訊協定

堆疊方式 (protocol stack) 和未來哪一種通訊協定堆疊可能被採

用，以作為研究方向之參考。

技術貢獻：

在這次會議，本團隊在 RAN2會議上提出了 4篇標準貢獻提案，

並有 1篇 CR被接受。

RAN2 目前在 LTE-Advanced Release 12 有三個主要的研究項目

及一個工作項目。本團隊為了掌握 LTE-Advanced Release 12 的發展

方向，不僅於會議之前積極參與各議題的 email 討論，發表我們對各

項技術議題的想法，也派出多位成員出席本次會議，以便掌握會議期

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

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

早佈局相關之研究。另一方面，本團隊成員也持續提出標準貢獻提

案，提升本團隊於標準會議的影響力。

會議解說：

本次 3GPP TSG RAN #82會議於日本的福岡舉行，主要議題包括

MTC Enhancements、HetNet Mobility Enhancements以及 Small Cell

4

enhancements等技術議題。

1. [MTC Enhancements]

此次會議延續 email 討論完成技術評估的細節，會議期間達成了三

項主要的共識。第一是完成 Connectionless Approaches此類方法在

RAN 部分的技術細節，及其對現有協定的可能影響；第二是完成

SDDTE 其他 4 類方法在 11 項評估準則裡的初步結果；第三是完

成 UEPCOP 的 3 類方法對現有 RAN 層級通訊協定的可能影響。

此次會議並利用禮拜三晚上加開了兩個小時的 Ad Hoc會議，整合

目前 RAN2的共識與結論，準備擬一份 Liaison在會議結束後傳給

SA2，回報 RAN2 初步的分析結果。另外，除了目前 SDDTE 的 5

類方法和 UEPCOP的 3類方法外，RAN2也決定將討論 TR23.887

內其他可能對 RAN有影響的解決方案，如「Lean Service Request

Procedure」、「Optimized Service Request procedure for UEs with a

single bearer」和「Power Saving State」等。最後也決定將由 ZTE

和 Huawei 分別召開一個 email 討論來進一步比較 SDDTE 裡各個

方法的信令開銷和 UEPCOP裡各個方法的電源消耗。

2. [HetNet Mobility Enhancements]

此次會議主要的工作在於解決異質網路間的兩項主要議題，分別

是異頻小細胞偵測方法的改良(Improved Small Cell Discovery)以

及無線鏈接失敗後之回復改良 (Improvements to recovery from

RLF)。針對小細胞偵測方法的改良，主要討論了三大類可能採用

的解決方法，分別是放寬的異頻測量 (Relaxed inter-frequency

measurements) 、 與 速 度 相 關 之 改 善 方 法 (Speed related

enhancements )以及指紋與其他鄰近偵測(Fingerprinting and other

proximity detection)的方法，在會議中僅對各個方法進行討論，並

做成若干決議，但尚未排除或決定採用某一改良技術，後續工作

將留待下次會議中繼續進行；而針對無線鏈接失敗後之回復改

5

良，目前也有兩大類可能採用的解決方法，一為提早觸發無線鏈

接失敗(early RLF trigger)，以避免導致換手失敗後而造成的無線鏈

接失敗，二為重建的增強(Enhanced re-establishment)，其目標在於

當無線鏈接失敗發生時，讓用戶設備可以更快速地重新建立連

線，但在會議中並未做出決議，而是希望透過會後的信件討論來

釐清相關方法的優缺點，以便在下次會議中繼續討論此項議題。

3. [Small Cell Enhancements – Higher Layer]

主要的議題是不同基地台間的無線電資源聚合 (Inter-Node Radio

Resource Aggregation) ，其中包括了 CP (Control Plane) 架構與 UP

(User Plane) 架構的討論。目前結論為：可能的 CP架構有兩種，

UP架構則有 9種。

6

目 錄

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

一、會議名稱 ............................................................................................. 7

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

三、會議時間 ............................................................................................. 7

四、會議地點 ............................................................................................. 7

五、會議議程 ............................................................................................. 7

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

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

7

一、會議名稱

3GPP TSG RAN2 #82 Meeting

二、參加會議目的及效益

參與 MTC enhancement、HetNet mobility enhancements 以及

small cell enhancements等討論及尋找可研究的題目

報告本團隊所發表的文章

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

交流

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

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

開展未來合作機會。

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

三、會議時間

20th May -24th May 2013

四、會議地點

Hilton Fukuoka Sea Hawk Hotel, Fukuoka, Japan

五、會議議程

RAN2#82的會議議程如下 20th May -24th May 2013：

Schedule Main room LTE UP room UMTS room

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

[5.3] BeiDou

[5.4] Other: HeNB enh.

[5.1] WLAN/3GPP

8

Tue 08:30 -> 12:30 [5.2] MTCe

Tue 14:00 -> 19:00 [6.1] LTE Rel-8/9/10 CP

[6.x] Rel-11 CP

[6.1] LTE Rel-8/9/10 UP

[6.x] Rel-11 UP

[8.1] Rel-8 and earlier

[8.2] Rel-9

[8.3] Rel-10

[9.1] Rel-11 FE FACH

[9.2] Rel-11 Multiflow

Tue ~19:00 Offline ad-hoc on WLAN

inter-working (if needed)

Wed 08:30 -> 12:30 [6.x] Rel-11 CP

[6.x] Rel-11 UP [9.3] Other Rel-11 WI

[9.4] Rel-11 TEI11

Wed 14:00 -> 16:00 [7.2] SCE Higher Layer

Wed 16:30 -> 19:00 [10.2] UMTS Het-Net

Wed ~19:00 Offline ad-hoc on MTCe

(if needed)

Thu 8:30 -> [7.2] SCE Higher Layer

Comebacks

[10.2] UMTS Het-Net

Thu 11:00 -> [10.4] HNB

Thu 14:00 -> 17:30 [7.1] HetNet Mobility

([7.3] NCT)

[10.2] Rel-12 F EUL

Thu 17:45 -> SCE HL: Joint Session with

RAN3

Thu 19:00 -> [10.3] LCR TDD

Fri 8:30 -> Left-overs, Comebacks Comebacks and leftovers

Fri: 14:00 ->

until 17:00

Left-overs, Comebacks

(Joint topics), [12][13][14]

9

六、會議紀要

1. MTC Enhancements (Rel-12) 議題

目前 SDDTE和 UEPCOP主要有下列幾類解決方案：

SDDTE：

Optimized RRC connection management：此類方法的概念是縮

減連線建立過程中的 RRC訊息交換以降低控制訊息成本。

Control Plane solutions：此類方法的概念是當要傳送小資料時

並不建立資料無線承載，而是利用連線建立過程中的 RRC訊

息來夾帶所要傳送的資料。

Connectionless approaches：此類方法的概念是當要傳送小資

料時並不建立連線，而是透過一個新設計的無線接取網路介

面傳送小資料。

S1/Iu-only optimizations：此類方法的概念是縮減連線建立過

程中的核心網路訊息交換以降低控制訊息成本。

Keep the UE in connected mode：此類方法的概念是不讓頻繁

傳送小資料的 UE進入 IDLE狀態。

UEPCOP：

Extended DRX in idle mode：此類方法藉由延長 UE在閒置模

式下監聽 paging訊息的間隔以達到省電的目的。

Long DRX cycles in connected mode：此類方法藉由延長 UE

在連線模式下監聽 PDCCH的間隔以達到省電的目的。

Transmission delay until better coverage conditions：此類方法藉

由 UE 主動等待有較好的通道品質後才發起上行資料流傳送

來達到省電的目的。

這次會議利用禮拜二上午的時間延續 email討論裡未完成的技術

評估細節，包括 Connectionless Approaches 此類方法在 RAN 部分的

技術細節、SDDTE 其他 4 類方法在 11 項評估準則裡的初步結果和

UEPCOP的 3類方法對現有 RAN層級通訊協定的可能影響等。以下

分別針對這 3部分做詳細的說明。

10

Connectionless Approaches

這類方法主要的概念是讓一個處於閒置模式下的UE可以在不用

向 MME發起連線建立請求的情況下直接傳送小資料到 S-GW。方法

即是讓處於閒置模式下的UE可以透過某種新的方式完成與 eNB之間

的資料溝通管道建立，這個溝通管道可以是目前 LTE 標準裡的信令

無線承載(Signalling Radio Bearer，SRB)或是資料無線承載(Data Radio

Bearer，DRB)。傳統 SRB與 DRB的建立程序是先向MME發起連線

建立請求，然後由 MME 發起演進封包系統承載(Evolved Packet

System bearer，EPS bearer)的建立程序，最後在 EPS bearer 的建立程

序中完成 SRB與 DRB的建立，而這樣繁瑣的建立程序對於小資料傳

送而言是高成本沒有效率的。如下圖所示，在 UE透過某種新的方式

完成與 eNB 之間的資料溝通管道建立後，即可透過此管道將小資料

傳給 eNB。但是由於 UE並未完成完整的 EPS bearer建立，所以 UE

需要把目標 S-GW的通道端點識別(Tunnel Endpoint ID，TEID)附在所

傳送的小資料封包裡，讓 eNB 知道要把收到的小資料封包傳往哪一

個 S-GW。也因如此，在此 UE第一次連上 LTE網路且進入閒置模式

前，UE 必須讓網路知道它有小資料傳送的需求，如此網路才可以在

此UE進入閒置模式前將預定處理此UE小資料傳送的 S-GW的TEID

傳給此 UE。

UE

1. Uu

eNB MME S-GW P-GW

2. GTP-U3. GTP-U IP

IP4. GTP-U5. GTP-U

6. Uu

7. Timeout

of fast path

7. Timeout

of fast path

7. Timeout

of fast path

由於原本 SA2 並未討論 UE 該如何與 eNB 建立小資料傳送的溝

通管道，並在 TR23.887 裡註明這是 RAN 的議題。所以在上次

RAN2#81bis 會議結束後，由 Ericsson 召開了一個 email 討論深入其

技術細節的研究。在 email 討論期間各間公司對於該建立 SRB 或是

11

DRB 並沒有明確的共識，且對於建立的程序也都有各自的看法。而

另一方面 SA2卻也在最新版本的 TR23.887裡提出了兩種可能的建立

程序，因此也讓 email討論裡的爭論更加擴大。有的公司認為最新版

本的 TR23.887 已經提供了建立方法，所以其他的方法不應該被考慮

進來；但也有公司認為這是 RAN 的議題，SA2 提供的建立程序只是

參考，最終的決議權仍在 RAN，所以不應該排除任何可能的方法。

最後 email 討論並未達成明確的共識。而在此次會議中，首先決定了

不排除任何可能的方法，且將 SA2 提出的 2 種建立程序也列入候選

的方案之一，暫時的平息了這場紛爭。

SDDTE

SDDTE的 5類方法中，除了 Connectionless Approaches 在 RAN

層級的細部設計尚未確定外，其他 4 類方法 SA2 都有給了明確的技

術細節。因此在上次 RAN2#81bis 會議結束後，由 ZTE 召開了一個

email 討論進一步研究各個方法對現有標準的影響。在「Optimized

RRC connection management」這類方法中，主要的概念是縮減連線建

立過程中的 RRC 訊息交換以降低控制訊息成本。如下圖所示，當一

個處於閒置模式的 UE 想傳送小資料時，直接把本應在 RRC 連線建

立完成後才傳給 MME 的服務請求/連線建立請求訊息(即 UE 傳送

RRCConnectionSetupComplete時)直接在RRC連線建立之前就夾帶在

RRCConnectionRequest 訊息裡傳給 MME 。且在 eNB 回覆

RRCConnectionSetup 訊息給 UE時就同時完成了 SRB1 和 DRB的建

立。

UEs eNodeB MME S-GW P-GW

2. Initial UE Message (Service Request)

3. Initial Context Setup Request

1. RRCConnectionRequest(ServiceRequest)

Small Data PacketSmall Data Packet

4. RRCConnectionSetup(SRB1 and DRB config, security context)

5. RRCConnectionSetupComplete

6. Steps 7-12 of Service Request: 23.401 Section 5.3.4.1

12

這 種 方 法 對 現 有 標 準 有 很 大 的 影 響 。 第 一 ， 由 於

RRCConnectionRequest 訊 息 的 大 小 有 上 限 ， 而 目 前 的

RRCConnectionRequest 訊息大小已經不可能再夾帶服務請求/連線建

立請求訊息。因此，必須要額外定義新的隨機存取前導信令(preamble)

群組，讓 eNB 在收到這群組的 preamble 時知道要分配更大的上行資

源給 UE傳送更大的 RRCConnectionRequest 訊息。第二，由於 UE傳

送 RRCConnectionRequest 訊息時是透過 SRB0 來傳送，因為此時可

靠度更佳的 SRB1 尚未建立完成，所以透過 RRCConnectionRequest

訊息來傳送服務請求/連線建立請求訊息可能會因訊息量變大而讓

RRCConnectionRequest 的傳送失敗。第三，原本 DRB 的建立必須在

UE與 eNB之間完成加密初始化之後，但是此類方法在 UE與 eNB之

間完成加密初始化之前就交換 DRB 的配置參數，對存取層(access

stratum)的安全性仍須進一步評估。因此在此次會議的討論上許多公

司都不太贊同這類方法。

在「Control Plane solutions」這類方法中，主要的概念是當要傳

送小資料時並不建立 DRB，而是利用 SRB 傳送 RRC 訊息來夾帶所

要傳送的資料。如下圖所示，當 UE 在建立 RRC 連線時，需要先讓

eNB 知道此次的連線建立並不要建立 DRB。可行的方法可以是在

RRCConnectionRequest 或 RRCConnectionSetupComplete 訊息裡帶一

個 small data indicator；或是直接把 RRCConnectionRequest 裡的 RRC

建立原因參數設成 mo-signalling。在目前 LTE 的標準規範中，當 UE

只是要做追蹤區域更新(Tracking Area Update，TAU)時，會把 RRC建

立原因參數設成 mo-signalling 來建立 RRC 連線，如此 eNB 就知道

UE 建立 RRC 連線的原因不是有資料要傳，就不會為此 UE 建立

DRB。但是這樣做是使用高優先權的 RRC 建立原因來傳送低優先權

的小資料傳送，因此有些公司並不認同這樣的做法。在「Control Plane

solutions」的方法裡建立好 RRC 連線之後，UE 就直接在 RRC 訊息

裡，如 RRCConnectionSetupComplete，夾帶所要傳送的資料。在此次

會議的討論中，大部分公司認為這類方法能節省的控制訊息成本有

限，僅適合用於較不頻繁的小資料傳送。

13

eNB MMEUES-GW/

P-GW

Random Access Response

RRC Connection Request (S-

TMSI, small data indicator)

RRC Connection Setup

RRC Connection Setup

Complete (KSI, EPS Bearer

ID, UDP/IP packet)

Initial UE message (S-TMSI,

KSI, EPS Bearer ID, UDP/IP

packet)

Random Access Preamble

Downlink Data Notification

(Bearer ID, UDP/IP response

packet)

RRC Connection Release

(UDP/IP response packet)

Downlink NAS Transport

(Release Command, UDP/IP

response packet)

GTP-U (TEID, UDP/IP packet)

UE subscribed to small

data operation

small data indicator inhibits

eNB sending Measurment

Configuration to the UE

此外，在下行資料流的情況下，SA2 也提出了一個利用 RRC 訊

息來夾帶下行封包的方法來節省控制訊息成本。如下圖所示，當 MME

收到通知，知道某個 UE有下行封包時，會直接收到此下行封包。當

MME發現此 UE處於閒置模式需要 paging時，會直接把此封包夾帶

在 MME送給 eNB的 paging請求訊息裡。而 eNB則是在 paging完此

UE ， 等 到 此 UE 建 立 RRC 連 線 時 ， 將 此 封 包 夾 帶 在

RRCConnectionSetup訊息裡傳給 UE。這樣的方法會有許多的缺點。

首先，所有處於此 UE追蹤區域表(Tracking Area List)裡的 eNB都會

收到此下行封包，且必須設計一個機制當 paging不到這個 UE時丟棄

它；再來 RRCConnectionSetup訊息是透過 SRB0來傳送，因為 SRB0

是不會對封包做切割重組的程序，所以 RRCConnectionSetup 訊息必

須在一個子訊框內傳完，也因此夾帶在 RRCConnectionSetup 訊息裡

的封包也有大小上限。因為這些缺點，此次會議 RAN2也決議這個方

法並不是合適的解決方案。

14

UE eNB MME MTC-IWF

1a.(Small data,IMSI)

2.paging(Small data)

4.RRC connection

request

5.RRC connection setup( Small data)

6.RRC connection setup complete(small data

ACK)

7.S1-AP(small data ACK)

8a.Delivery Report

3.paging(small data flag)

9.RRC connection Release or initiate

communicate

small data submission(refer to the step1 to step 6 in clause

5.2.1 of TS 23.682.)

SGW/PGW

Small data packet arrives at

SGW

1b.Downlink Data Notification (small data)

8b.Delivery Report

此次會議中也討論了「S1/Iu-only optimizations」和「Keep the UE

in connected mode」這兩類方法。前者主要的概念是縮減連線建立過

程中核心網路的訊息交換以降低控制訊息成本，RAN2評估此類方法

對 RAN 層級的通訊協定並沒有明顯的影響。後者主要的概念是不讓

頻繁傳送小資料的 UE 進入 IDLE 狀態以節省頻繁建立釋放連線的控

制信令開銷。關於這類方法在 email討論時大部分公司認為只適用於

不太移動的 UE，因為移動性較高的 UE 處於連線狀態時必須頻繁的

執行 Handover 程序，這會導致更多的控制信令開銷。關於這個議題

此次會議也討論了 Ericsson 和 Huawei 的兩篇技術貢獻。這兩篇技術

貢獻主要分析 SDDTE各類方法所能節省的信令開銷比率，且都認為

「Keep the UE in connected mode」這類方法可以節省最多。不過這部

分的比較結果目前尚不成熟，因此最後主席也決議在 email討論做進

一步的探討。另外，除了上述 SDDTE 的 5 類方法外，RAN2 也決定

將討論 TR23.887 內其他可能對 RAN 有影響的解決方案，如「Lean

Service Request Procedure」和「Optimized Service Request procedure for

UEs with a single bearer」等。

UEPCOP

15

UEPCOP的 3類方法中，大部分時間是在討論「Extended DRX in

idle mode」這類方法。此類方法的主要想法是藉由延長 UE在閒置模

式下監聽 paging 訊息的間隔以達到省電的目的。但此類方法對 RAN

層級的通訊協定有下列幾個影響：

Paging Frame (PF)的計算：根據目前 LTE標準的規範，UE是

根據 eNB 在 MIB 裡所廣播的系統訊框編號(System Frame

Number，SFN)和自己的識別碼來判斷目前的系統訊框是否為

PF。SFN 的範圍是 0~1023。因此當 DRX cycle 大於 1024 個

無線訊框時，由於系統訊框會重新編號，導致此 UE 在 DRX

cycle還未到達時就會誤判以為 PF已經到來。

系統參數的更新：在 LTE 系統裡，Paging 訊息也被用來通知

UE系統參數有更新。如果一個 UE收到一個通知系統參數更

新的 Paging 訊息時，此 UE 知道系統參數將在下一個到來的

Modification Period Boundary (MPB)時更新。反之如果一個UE

在一個 Modification Period (MP)期間都沒收到通知系統參數

更新的 Paging 訊息時，此 UE 會假設系統參數將不會在下一

個到來的 MPB時更新。因此，如果一個 UE的 DRX cycle 比

一個MP還要長時，此 UE有可能會錯失通知系統參數更新的

Paging訊息。

eNB 需要額外的暫存空間：當 MME 要 paging 一個 UE 時，

因為 MME 並不知道此 UE 在哪個 eNB 的涵蓋範圍內，所以

也無法推測此 UE 的 PF。因此當 eNB 收到從 MME 傳來的

paging 要求時，可能需要暫存此 paging 訊息以等待此 UE 的

PF到來。

接收 Paging訊息的可靠性：因為 DRX cycle很長的緣故，如

果被 paging 的 UE 因為短暫的通訊品質不好而錯過 paging 訊

息時，必須經過很長的時間之後才有機會再 paging到此UE(即

下一個 PF)。

下行資料會有較長的延遲：因為傳送下行資料給一個閒置的

UE 前必須先 paging 此 UE，所以使用較長 DRX cycle 的 UE

會有較長的下行資料延遲。

小區重選(cell reselection)可能無法適當運作：因為處於閒置狀

態的 UE 會利用監聽 paging 的機會順便對鄰近小區的訊號做

量測，以利此 UE移動出原本所在的小區後執行小區重選的運

16

作。但若 DRX cycle 很長時，不頻繁的鄰近小區量測有可能

會使小區重選的運作失敗。

不符合緊急資訊的接收延遲需求：有些緊急資訊，如地震和

海嘯預警系統 (Earthquake and Tsunami Warning System，

ETWS)，有很嚴格的接收延遲要求，但如之前所述，使用較

長 DRX cycle的 UE會有較長的下行資料延遲。

此次會議因時間的關係並未討論到上述這些問題的解決方法，因

此最後主席也決議在 email討論做進一步的探討。另外在「Long DRX

cycles in connected mode」這類方法的討論與 SDDTE裡的「Keep the

UE in connected mode」的討論相似，大部分公司認為只適用於不太移

動的 UE，因為可能會影響到 Handover 程序的成功率。而在

「Transmission delay until better coverage conditions」這類方法上大多

數公司則是有共識的認為此類方法屬於 UE的實作方法，並不需要且

不適合在標準文件中加以規範。關於這個議題此次會議也討論了

Qualcomm 和 Samsung 的兩篇技術貢獻。這兩篇技術貢獻主要分析

「Extended DRX in idle mode」這類方法所能節省的電源消耗比率，

且都認為此類方法有一個最佳的 DRX cycle 上限，超出此上限後的省

電效果並不顯著，如下圖所示。

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

1 10 100 1000 10000 100000

DRX cycle [sec]DRX cycle [sec]

Re

lati

vep

ow

er c

on

sum

pti

on

Reference, DRX cycle = 2.56 s

DRX cycle = 327.68 sAdditionally, 5 SFN bits

DRX cycle = 10.24 swithout SFN extension

另外，除了上述 UEPCOP 的 3 類方法外，RAN2 也決定將討論

17

TR23.887內其他可能對 RAN有影響的解決方案，如「Power Saving

State」。最後，此次會議利用禮拜三晚上加開兩個小時的 Ad Hoc 會

議，整合目前 RAN2 的共識與結論，準備擬一份 Liaison 在會議結束

後傳給 SA2，回報 RAN2 初步的分析結果。

2. HetNet Mobility Enhancements (Rel-12) 議題

此次會議的目的乃是討論異質網路布建所衍生的兩項課題，分別

是異頻小細胞偵測方法的改良(Improved Small Cell Discovery)以及無

線鏈接失敗後之回復改良(Improvements to recovery from RLF)，在上

一次會議結束後，也分別針對這兩項課題先行進行了相關的信件討

論，而各公司的意見及討論結果也一併在此次會議中發表。

小細胞偵測方法的改良

關於小細胞偵測方法的改良，主要可以分為三類可能採用的解決

方 法 ， 分 別 是 放 寬 的 異 頻 測 量 (Relaxed inter-frequency

measurements)、與速度相關之改善方法(Speed related enhancements )

以及指紋與其他鄰近偵測(Fingerprinting and other proximity detection)

的方法，在會議中針對了這三類解決方法都進行了探討，希望能夠尋

求基本的共識。

放寬的異頻測量

R2-131653 Analysis on Inter-frequency Small Cell Discovery; ZTE; Disc;

在這篇提案中，ZTE根據上個會議後對於放寬的異頻測量這

個方法所舉行的信件討論的結果進行討論，ZTE認為當要引入一

個新的小細胞偵測技術時，這個新的技術應該只能當用戶設備由

宏細胞服務而想要尋找小細胞以實現卸載(offload)目的時才可以

執行，在這個前提下，一個用戶設備只需要有一個測量間隔

(measurement gap)來進行異頻測量，也就是基於移動(mobility)目

的時，網路端會配置一般的測量間隔給用戶設備，反之如果是基

於卸載目的時，網路端則會配置一個新的放寬的測量間隔給用戶

設備，針對是否需要配置一個以上的測量間隔給用戶設備，有正

反雙方的意見，但多數公司認為現階段的布建場景中，不太可能

存在有一個載波為了卸載的目的存在，而有另外兩個載波為了移

18

動的目的存在，因此單一個測量間隔已經足夠。另外，ZTE也認

為應該要請RAN4決定為了小細胞偵測而放寬的測量間隔的需求

為何，而可能的作法會是一個新的放寬的測量間隔或是一個用戶

設備自主性的測量間隔(autonomous gap)，有部分公司認為採用自

主性的測量間隔也是一個可能的選項，也可以考慮讓用戶設備在

非連續接收模式中執行此自主性的測量，但其他公司則認為利用

性的測量間隔可能很難確保小細胞偵測的效率，而且尚未有任何

的分析數據，所以不應該在現階段將自主性的測量間隔考慮進

來。最終，在經過充分的討論之後，相關的會議結論如下：

Agreements

In the context of relaxed measurement performance requirements…

1 The new proposed small cell discovery mechanism aims at detection of

small cells that are deployed for offloading purpose.

2 At any point in time, a UE may only be configured with a single

measurement gap that applies to all inter-frequency layers for which

measurements are configured. The NW may configure the gap pattern

for the UE according to the most demanding measurements (e.g. 40/80

ms if measurements are required for coverage reasons and relaxed if

needed for offloading).

3 If RAN4 intends to use autonomous gaps RAN2 would prefer that those

do not interfere with ongoing data transmission. That means, the UE

should only measure autonomously while being in DRX.

與速度相關之改善方法

R2-131774 Avoiding Fast UEs in Small Cells; MediaTek Inc; Disc;

在此篇提案中，MTK建議高速移動的閒置用戶設備(Idle UE)

在進行異頻的細胞重選(cell reselection)時，應該要優先選擇宏細

胞，也就是應該要讓細胞重選機制也要同時考量到用戶設備的移

動速度，此外，為了能夠得到更為豐富的用戶設備移動資訊，也

建議用戶設備在從閒置模式切換至連線模式時，也要將在閒置模

式中的相關移動資訊一併上傳給網路端參考。雖然有部分公司認

為可以考慮這個建議，但多數公司希望在這工作項目中只專注於

改善用戶設備在連線模式的部分，應該將閒置模式的部分擱置；

而對於用戶設備在從閒置模式切換至連線模式時，將在閒置模式

中的相關移動資訊一併上傳給網路端參考的部分，多數公司則表

19

示支持。因此，最終的會議決議如下：

Agreements

1 The UE shall provide mobility information to the network at RRC

connection setup. The details (granularity, …) are FFS.

指紋與其他鄰近偵測的方法

R2-132076 Small Cell Discovery; Huawei, HiSilicon; Disc;

在這篇提案中，華為認為利用鄰近偵測方法來進行小細胞偵

測不但可以支援舊型的用戶設備，而且也可以有效地用戶設備的

節省電能損耗，其中鄰近偵測方法可以分為用戶端與網路端兩

種，用戶端的鄰近偵測方法因為完全仰賴各用戶設備裝置的內部

設計，因此對於現行標準的影響較小，但舊型的用戶設備就無法

從中得利；反之網路端的鄰近偵測方法，例如讓超微細胞(pico cell)

來監聽鄰近用戶設備的上行鏈路訊號(uplink signal)，而此方法則

可以服務舊型的用戶設備，因此華為建議考慮採用網路端的鄰近

偵測方法，亦即是讓超微細胞來監聽鄰近用戶設備，作為新的小

細胞偵測方法。然而多數公司認為讓超微細胞來監聽鄰近用戶設

備的鄰近偵測方法將會導致超微細胞設計的困難度，同時也會導

致信令負擔的增加，此外，也有公司認為採用鄰近偵測方法沒有

辦法讓用戶設備偵測到從來沒有造訪過的細胞，任何新的小細胞

偵測方法都應該要能夠讓用戶設備能夠偵測到從來沒有造訪過

的細胞為原則。因此，最終的會議決議如下：

=> RAN2 agrees that a solution should support discovery of not-yet-visited

cells. Discovery behaviour of inter-frequency pico cells shall be predictable.

無線鏈接失敗後之回復改良

關於無線鏈接失敗後之回復改良主要有兩個可能的做法，一

為提早觸發無線鏈接失敗(early RLF trigger)，以避免導致換手失

敗後而造成的無線鏈接失敗，二為重建的增強 (Enhanced

re-establishment)，其目標在於當無線鏈接失敗發生時，讓用戶設

備可以更快速地重新建立連線。

在討論此項議題前，主席首先確認了無線鏈接失敗後之回復

改良為異質網路中的一項挑戰：

20

=> RAN2 agrees that HOF/RLF is more likely to occur in heterogeneous

networks and one way to reduce the impact of those could be to improve the

recovery from RLF.

提早觸發無線鏈接失敗

R2-131663 RLF recovery enhancements; Qualcomm Incorporated; Disc;

在此篇提案中，高通介紹了提早觸發無線鏈接失敗的方法，

也就是當所服務的細胞訊號強度低於門檻值啟動 T310 後，如果

鄰近細胞的訊號強度比當前服務細胞強度還好，且觸發了 A3 事

件時，這個時候不會啟動換手機制，而是提前觸發無線鏈接失

敗，以避免導致換手失敗後而造成的無線鏈接失敗。

Serving cell signal

Neighbour cell signalQout detected

T310 terminated

Neighbour cell A3 offset better than serving

TTT

T310

UE triggered RRC connection re-establishment

部分公司認為配置較短的 T310 也可以得到一樣的效果，而

主席則認為針對這個作法應該要先釐清提早觸發無線鏈接失敗

所節省下的時間長短，如果節省的時間太長，那麼就應該要考慮

降低換手失敗率而非提前進行無線鏈接失敗後之回復。因此，會

議的決議如下：

=> Should understand how much more reestablishments (towards unprepared

cells) would happen if pico cells would always configure a shorter T310.

=> Investigate whether a short T310 should be applied rather than triggering

reestablishment immediately when Qout is met.

=> We should also investigate whether Oout is usually triggered before or after

A3/TTT.

=> What are the actual outage times (in s) per HOF with and without this

enhancement.

21

重建的增強

這部分的提案主要都在於如何保存或分布用戶設備的紀錄

(UE context)來達成快速重新建立連線的目標，但由於時間的因

素，相關的提案並未加以討論。

3. Small Cell Enhancements (Rel-12) 議題

主要的議題為：基地台間的無線電資源聚合 (Inter-Node Radio

Resource Aggregation)，由於需要兩個基地台間 (宏小區與微小區) 搭

配，所以 UP 和 CP的架構需要進一步討論，討論所有的可能性。

UP (User Plane) 可能的協定堆疊架構 (Protocol stack

architecture) 選項

- R2-131621Email Discussion Report on U-Plane Alternatives [81bis#19];

Nokia Siemens Networks (Rapporteur); Report; related to email

discussion [81bis#19];

- R2-132225 TP for U-Plane Alternatives Nokia Siemens Networks

(Rapporteur) TP 36.842

由於上次會議 UP 的部分沒有時間討論，因此放進了 email

discussion 討論，在這個討論中，先分為傳送至微小區(SeNB)資料需

不需要經由宏小區 (MeNB)，經由宏小區又可分為是否宏小區可以幫

忙傳送，所以總共有三種可能性：

- Option 1: S1-U also terminates in SeNB;

- Option 2: S1-U terminates in MeNB, no bearer split in RAN;

- Option 3: S1-U terminates in MeNB, bearer split in RAN.

Option 3Option 1

MeNB

SeNB

EPS bearer #1

EPS bearer #2

UE

S-GW

Option 2

MeNB

SeNB

EPS bearer #1

EPS bearer #2

UE

S-GW

MeNB

EPS bearer #1

SeNB

EPS bearer #2

UE

S-GW

22

接著是有關協定堆疊的可能性，基本上分成四類：

- Independent PDCPs

- Master-Slave PDCPs

- Independent RLCs

- Master-Slave RLCs

搭配前述的三種可能的資料流向，總共有 9種方式的微小區與宏小區

的協定堆疊：

- 1A: S1-U terminates in SeNB + independent PDCPs (no bearer split);

- 2A: S1-U terminates in MeNB + no bearer split in MeNB + independent

PDCP at SeNB;

- 2B: S1-U terminates in MeNB + no bearer split in MeNB + master-slave

PDCPs;

- 2C: S1-U terminates in MeNB + no bearer split in MeNB + independent

RLC at SeNB;

- 2D: S1-U terminates in MeNB + no bearer split in MeNB + master-slave

RLCs;

- 3A: S1-U terminates in MeNB + bearer split in MeNB + independent

PDCPs for split bearers;

- 3B: S1-U terminates in MeNB + bearer split in MeNB + master-slave

PDCPs for split bearers;

- 3C: S1-U terminates in MeNB + bearer split in MeNB + independent RLCs

for split bearers;

- 3D: S1-U terminates in MeNB + bearer split in MeNB + master-slave RLCs

for split bearers.

以下圖表示九種可能性：

23

最後會議結論，這些可能的架構都會被寫入 TR (Technique Report)

文件中。

R2-131993 Backhaul Issue List; NTT DOCOMO, INC.; Disc;

R2-132115 Analysis of backhaul requirements for macro eNB

routing; Huawei, HiSilicon; Disc;

這個議題主要是討論，宏小區與微小區之間的後端網路需不需要

一些限制，由於這些討論牽涉到 RAN3 的議題，所以 RAN2 這邊無

法給出具體的結論，但是 RAN2覺得發生在宏小區與微小區之間的封

包遺失機率是非常低的，且這兩個小區之間的介面不應該是網路的瓶

頸。另外，由於有些架構中，至微小區的封包會經由宏小區轉送，所

以宏小區所增加的負載不可以被忽略；封包要不要經過宏小區的架構

都需要被研究；所以會議的結論如下：

Agreements

3 Packet loss on the interface between MeNB and SeNB is rare if the Xn

is not the bottleneck.

=> RAN2 agrees that the load increase due to routing via the MeNB is not

negligible

=> For the time being we investigate solutions where data is routed via the

24

MeNB as well as those where the data is split in the CN.

CP (Control Plane) 可能的協定堆疊架構 (Protocol stack

architecture) 選項

- R2-131673 Summary of email discussion [81bis#18][LTE/SCE-HL] CP

protocol and architecture alternatives; Ericsson; Report; related to email

discussion [81bis#18] ;

由於時間的關係，有關 CP 架構的部分，只有討論 email

discussion的部分。這份 email discussion主要討論了兩方面：

第一方面：由 手機 (UE) 的角度來看 RRC function，可分為

四個選項：

Alt C1: 手機端只有一個 RRC 實體；只有錨基地台

(Anchor eNB)有 RRC實體。RRC訊息都是經由錨基地台

傳送與接收，不經過助理基地台(Assisting eNB)。

Alt C2: 手機端只有一個 RRC 實體；只有錨基地台有

RRC 實體。RRC 訊息可以經由錨基地台或者助理基地台

傳送。

Alt C3: 手機端只有一個 RRC 實體；錨基地台與助理基

地台都有 RRC實體，但是彼此之間有一些分工關係。

Alt C4: 手機端有兩個 RRC 實體對應到錨基地台與助理

基地台；錨基地台與助理基地台都有 RRC 實體，但是彼

此之間有一些分工關係。

示意圖如下：

Control Plane

Alternative 1

Assisting eNB

Control Plane

Alternative 2

UuUu

Uu

Xx

Xx

Anchor eNB

RRC

L2/L1

UE

RRC

L2/L1

Anchor eNB

RRC

L2/L1

UE

RRC

L2/L1

Assisting eNB

L2/L1

25

Control Plane

Alternative 3Control Plane

Alternative 4

Anchor eNB

Assisting eNB

UE

Anchor RRC

L2/L1

AssistingRRC

L2/L1

Anchor RRC

L2/L1

AssistingRRC

L2/L1

Uu

Uu

Xx

Anchor eNB

Assisting eNB

UE

RRC

L2/L1

Anchor RRC

L2/L1

AssistingRRC

L2/L1

Uu

Uu

Xx

第二方面：由基地台(eNB) 的角度來看無線電資源管理 RRM

(Radio Resource Management)，這個部分分成兩個：

Alternative R1: 集中式的無線電資源管理位於錨基地台。

Alternative R2: 分散式的無線電資源管理位於錨基地台

與助理基地台。

示意圖如下：

RRM Alternative 1

Anchor eNB Assisting eNB

RRM

Xx

R R M A l t e r n a t i v e 2

A n c h o r e N B A s s i s t i n g e N B

RRM AssistingRRM

Xx

會場上討論 RRC 架構時，由於大家的認知有些差距，最後歸納

出兩個基本的架構：

- Option 1: 只有主要基地台 (MeNB, Master eNB) 會產生 RRC

訊息，手機的 RRC 實體只會看到一個 RRC 實體且在主要基

地台上，手機也只會回 RRC訊息給主要基地台。

- Option 2: 主要基地台和次要基地台 (SeNB, Secondary eNB)

都可以產生 RRC 訊息，也可以直接傳送給手機；手機需回

26

RRC訊息給對應的基地台。

細節部分，則留在 email discussion。有關於這部分討論的結論如下：

Agreements

1 The UE is either IDLE or CONNECTED.

From a functional point of view there are two alternatives…

Option 1:

Only the master eNB generates the final RRC messages. The UE RRC entity

sees all messages coming only from one entity (in the MeNB) and the UE only

replies back to that entity.

L2 transport of these messages is FFS (e.g. transfer via SeNB)

Option 2:

MeNB and SeNB can generate final RRC messages and may send those

directly to the UE (depending on L2 architecture) and the UE replies

accordingly.

How and whether to distinguish source and destination RRC entity is FFS.

How to route UL messages is FFS.

L2 transport of these messages is FFS (e.g. transfer via SeNB).

4. WLAN/3GPP Radio Interworking 相關議題

本次的討論主要集中在 Network Selection and Traffic Steering 的

解決方案。在目前的文件(TR37.834)制定中，主要定義了三種解決方

案的方向：

由 3GPPP RAN 提供相關的資訊及由 ANDSF 提供規則給

UE，讓 UE 藉此決定將資料由 3GPP 或 WLAN 進行傳輸；

適用的情境為 UEs 處在 RRC IDLE ，RRC CONNECTED

states for E-UTRAN, UE IDLE mode for UTRAN 以及

CELL_DCH, CELL_FACH, CELL_PCH 和 URA_PCH states

for UTRAN。

由 3GPPP RAN提供相關的選擇參數(如 thresholds, priorities,

rules等等)給 UE，讓 UE藉此決定將資料由 3GPP或WLAN

進行傳輸；適用的情境為 UEs in RRC IDLE 與 RRC

CONNECTED states for E-UTRAN，UE IDLE mode for

27

UTRAN 以及 CELL_FACH, CELL_PCH, URA_PCH 和

CELL_DCH states for UTRAN。

由 3GPP RAN進行選擇網路的決定，透過專屬的通訊界面來

告訴處於 RRC CONNECTED/CELL_DCH 狀態的 UE。決定

的方法可能包含所量測到的 WLAN 狀況。此方式對處於

IDLE mode，CELL_PCH 和 URA_PCH 狀態的 UE會和上述

方法 2接近。與上述方法 1的關聯性則待討論。

對於 ANDSF相關的討論摘錄如下：

在會議前的 e-mail 討論串中，各公司認同 ANDSF rules不應

該太頻繁的更新。

Operator：Vodafone認為 ANDSF還沒開始應用在系統中，應

該也評估是否其他能提供相關功能的方法。AT&T 表示想要

在系統中使用 ANDSF。DT 認同 Vodafone的考量，但認為

使用 ANDSF是基本的選項。

贊同使用 ANDSF 的公司：Broadcom 認為可利用 ANDSF

進行改善的方法。NSN認為已有 UE支援 ANDSF功能，藉

由與 3GPP 結合可以在未來讓 ANDSF 的布建更為普及。

Motorola認為應該嘗試使用 ANDSF。

對使用 ANDSF表示懷疑的公司：Huawei認為應該暫緩討論

這方面的方法。 QualComm 認為使用 ANDSF 是讓 operator

能控制 traffic的經由 3GPP或是 WLAN，而 UE的決定應該

為 implement issue。

R2-132092 Further description of access network selection and traffic

steering solutions 1 and 2 (Intel Corporation, AT&T, CATT,

Broadcom; Disc)

本文中針對解決方案 方向 1與 2提出方法建議：

Solution 1 direction：eNB/RNC 藉由 broadcast 或 dedicated

RRC signaling 而 WLAN 藉由 via Beacon frames, Probe

Response frames or 802.11u ANQP message exchange 提供相

關協助資訊給 UE。

Solution 2 direction：eNB/RNC 藉由 broadcast 或 dedicated

RRC signaling提供相關資訊與 policy給 UE。

28

下圖為 R2-132092所提 Solution 1&2方法架構。

AP1

AP2

eNB1

NodeB1

eNB2

Beacon

ProbeResponse

ProbeRequest

SIB

Dedicated RRC Message

SIB

根據 802.11規範，WLAN可提供的相關資訊內容有：

BSS Load IE that contains the following information: Station

Count, Channel Utilization and Available Admission Capacity

(for different QoS categories defined in IEEE 802.11)

Supported Rates IE

HT Capabilities IE that contains Supported Channel Width

(20MHz or 40MHz), Supported MCS and other information

WLAN WAN metric including backhaul speed

依據不同的資訊提供，歸納出下列方法

Solution 1a – 直接提供 UMTS/LTE load 資訊。 e.g. in

percentage.

Solution 1b – 間接提供 UMTS/LTE load資訊。 e.g. using

different load levels or offload preference indicator (low,

medium, high).

Solution 1c – maximum resource allocation the UE may

receive on UMTS/LTE.

Solution 1d – 提供 WLAN RSSI threshold v WLAN BSS

load threshold v WLAN WAN Metric threshold

Solution 1e – 提 供 UMTS/LTE load level, e.g.

high/medium/low或 RSRP/RSCP thresholds

29

Solution 1f –提供WLAN RSSI threshold 或WLAN BSS load

threshold 或 WLAN WAN Metric threshold 或 3GPP RAN

RSRP threshold 或 3GPP RAN load threshold 或 Priority

between 3GPP and WLAN

相關討論情形摘要如下：

AT&T 澄清方法 1e 中所提的 RSSI threshold 係指 cellular

channel，並非 WiFi的 channel資訊。

DT 質疑方法 1a 與 1b 中 UE 要如何使用 load 的資訊；Intel

認為可藉此進一步改進 ANDSF 所提供的規則讓 UE 進行

WiFi Network 的選擇。但 DT 認為只需 1-bit 的指示就足夠

了；Intel 則認為會有多種的選擇可能。AT&T則表示認同告

知 3GPP load與 channel quality資訊。

Motorola 與 DT 均質疑告知 UE 關於 3GPP 端 load 情形的資

訊需要性；Broadcom 認為這個資訊會應用在 ANDSF 的規

則。NSN 與 DT 則認為告知 load 資訊在實現上有是不實際

的，應該直接告訴 UE是否使用 WiFi。

對兩種解決方案方向再次進行釐清：

a. In Solution direction 1 the rules are not provided by the RAN (but

e.g. by ANDSF) and use assistance information, threhsolds and

measurements of the RAN.

Example:

ANDSF: if (RAN_RSRQ > x) {attempt to use WiFi})

RAN: The RAN_RSRQ threshold might be provided by the RAN and

used in the ANDSF rule. Other thresholds might also be provided by

the ANDSF itself.

b. In Solution direction 2 the threshold are provided by RAN and may

relate to channel quality measurements. We specify the rules (in RAN2

specification) how to use the thresholds.

Example:

RAN: if (RAN_RSRQ > x) {attempt to use WiFi}

(if RAN does not want UEs to move to WiFi (e.g. low load) it may

stop indicating the rule)

If the UE, based on these rules, should attempt to use WiFi, the UE

may still apply ANDSF rules which may indicate that the UE shall not

offload (certain traffic) to WiFi (ANDSF overrides RAN rule).

30

關於 threshold的討論摘要如下：

AT&T 和 DT 認為 1e 中的 RSCP threshold 是由 RAN 提供。

Chairman 和 LG認為符合解決方案方向 2。

DT 認為 RAN 可提供 RSCP/RSRP/RSRQ threshold 給 UE，

再由UE配合ANDSF rule來進行判斷是否切換到WiFi。ALU

認為 RSRQ資訊可以來自 ANDSF；Huawei則認為若如此需

要 RAN動態依據WLAN AP 與 eNB的距離遠近來調整涵蓋

範圍，而 threshold值也會和 cell下有多少個WLAN AP有關。

Vodafone則認為不該有不同的 threshold值設定。

NSN表示特定的 RSRP/RSRQ threshold是否能讓 ANDSF做

為參考是有待商榷的，如果要使用的話建議發出 LS到 SA2。

MTK則表示是否只有 RSRP或 RSRQ threshold。

DT表示認同 threshold值應要由 RAN端提供。

對兩種解決方向的討論摘要如下：

IDT，ALU與 Broadcom認為 solution 1 中 threshold 由 RAN

端提供，但由 ANDSF rule 來決定如何使用。Kyocera 認為

solution 1 的假設前提為 ANDSF 一直存在，DT 認為若無

ANDSF則由 UE端進行。

Broadcom 認為 solution 2 中 RAN 無法告知 UE 是否切換到

WiFi，但 ANDSF 需要這些資訊，因此可能會有 RAN 與

ANDSF間的資訊衝突問題。

Vodafone詢問 solution 2如何讓 user由WiFi切回 3GPP，Intel

和 Huawei表示因 UE仍然與 RAN保持連線，因此仍可提供

一 threshold來達成此目的。

R2-131790 Solution 3: Connected mode solutions for network selection for

WLAN/3GPP interworking (Qualcomm Incorporated)

本篇文件中 Qualcomm提出 solution 3 的信令設計。相關的討論

摘要如下：

AT&T 詢問此方法是否會造成額外的 latency。Qualcomm 回

答和 solution 1&2一樣會面對的主要問題在於WLAN本身的

31

associate 時間 delay，量測訊號和切換動作的 latency 相對

latency較低。

Qualcomm 認為所提方法的好處在於當 ANDSF 發生錯誤時

仍能達到 load balance的目標。

Orange 表示認同專屬控制的作法，因對所有在 RRC

connected mode 的 UE有較好的控制能力。並表示 UE-based

的解決方法應予以排除，因無法得知或控制其他 UE 的行

為。TI也認為在 connect mode 時有專屬控制是最佳的作法，

但須考慮 ANDSF rule是否允許 UE轉入 WiFi。但 Vodafone

認為不需要專屬的信令設計，因 solution 1&2也可達到同樣

的效果。DT認為 solution 2&3 都可以使用專屬的控制。

DT認為 Idle mode 的 UE因無資料傳送情形故不需要考慮，

Orange表示認同。

Chairman 認為應先決定選擇策略是要將 RAN 中 heavy load

user移出，或是盡可能把 user移出。MTK表示 Idle Mode user

仍會進行資料傳送，故不須依 user狀態進行區分。

Vodafone 想要在 RAN 端最簡單達成的 solution，ALU 表示

solution 3 direction 是最複雜的。CATT、同時代表 CMCC、

表示支持 solution 3 direction。

會議中討論尚未定案，之後會繼續透過 e-mail 討論。

七、心得與建議

在 MTC enhancements的議題上，RAN2已經完成了初步的討論

結果。雖然目前仍無法預測出最後的技術趨勢，但我們認為在 SDDTE

方面「Connectionless approaches」和「Keep the UE in connected mode」

有較大的機會；在 UEPCOP方面我們認為「Power Saving State」是較

合適的方法。為了掌握此議題未來的標準走向，我們仍會持續的關注

這個議題，分析比較這些解決方案的優缺點，進而挖掘出可能的研究

議題並完成技術佈局。

現階段關於 Rel-12 異質網路之移動性管理的部份，主要討論的

議題集中在異頻小細胞偵測方法的改良與無線鏈接失敗後之回復改

良，但目前對於異頻小細胞偵測方法的改良仍然有多種可能的技術可

32

供選擇，各公司對於其所開發之技術各有堅持，因此仍未取得關鍵之

共識，但我們所建議之技術仍然在可能的選項之中，也符合了目前對

於小細胞偵測方法的初步要求，因此仍可持續在未來的會期中與其他

公司進行溝通與討論，讓相關的觀念與技術能夠被標準所採用，而無

線鏈接失敗後之回復改良這個議題，目前也有多種方式可供選擇，但

其中的利弊得失仍有待進一步地分析與探討，此後可以繼續關注各公

司對於此項議題之信件討論，以便掌握未來相關的討論重點。

有關於基地台間無線電資源聚合的議題，主要著重在 CP 和 UP

的架構，目前可能的選項還很多，將來進入標準化階段時，將會從這

些架構選出一個，所以這些架構都需要進一步研究，找出最可能將來

被選為標準的架構，因此這個議題需要繼續關注。

本次在WLAN/3GPP Interworking的討論中提到了關於WLAN的

associate latency問題。由於WLAN association這部分所引入的 latency

是無法被 3GPP RAN所掌握的，不論最後哪一種 solution被採用，都

必須面對這個問題。此外討論中顯示不建議有 network loading 的資訊

傳送或交換，而傾向由網路端告知 UE進行 network selection的動作，

而 RAN 端則至少會提供相關資訊如 RSCP/RSRP/RSRQ。另外

Operator 偏好較簡單的解決方案，並由網路端進行決策直接告知 UE

網路的選擇方式，因為對原有系統的變更最少；然而研發公司的意見

中並不排除在 UE端進行 network selection 功能。另在本次討論中點

出對於切換網路必須同時滿足移出與移回 RAN network的情形，這部

分建議可進一步思考可能的問題點。