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

3GPP TSG RAN WG2 #70bis會議

出國報告

出國人員：王竣彥、林香君、陳俊嘉、

羅耿介、吳志強、劉舒慈、

陳秋紋、吳志祥、陳德鳴、

Mamadou Kone

派赴國家：瑞典斯德哥爾摩

出國期間：99年 06月 26日至

99年 07月 04日

報告日期：99年 07月 07日

2

摘 要

本次 3GPP TSG RAN2會議於於六月底在瑞典斯德哥爾摩舉行，本研發團隊依規

劃有 10位成員出席參與 RAN2相關議題之討論。

3GPP LTE-Advanced：

為了配合 ITU-R的 IMT-Advanced制定進度，3GPP RAN2必須在 2010年底完成

Release 10(LTE-Advanced) 的制定工作。其中由於 Carrier Aggregation 是為了符合

IMT-Advanced 的要求的必要項目，目前會議將約 1/4 的時間用在討論 Carrier

Aggregation的議題上。因此也壓縮了其他議題的討論時間。

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

作為將來提案至 ITU-R 的候選系統。經過先前幾次 RAN2 會議的討論，目前

LTE-Advanced的系統規格要求已大致完成。3GPP RAN工作群組將針對 LTE-Advanced

系統規格要求，逐步展開相關技術討論與標準制定。本研發團隊為掌握目前

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

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

3GPP LTE：

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

分工作以掌握現況為主；MAC、RLC、PDCP、RRC release 8和 release 9的部份，功

能大致上都已經完成，現在在做細部的修定，因此，參與同仁將配合目前實作系統之

技術發展，適時提出技術提案。

由於 Release 8 跟 Release 9都已經 release，因此目前只是在進行一些修訂的工

作。目前主要討論的議題是在Minimisation of Drive Test這個WI。MDT的部份由於必

須在今年年底前完成制定的工作，因此討論的時間比較多。另外就是 Machine Type

Communication 這個 SI，此次會議傾向在這些議題上面可以達成一些共識與結論，這

3

次會議已經就 push的方案達成了共識。

4

目 錄

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

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

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

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

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

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

5

一、會議名稱

ASN.1 seminar

3GPP TSG RAN2 #70bis Meeting

二、參加會議目的及效益

參與 LTE/LTE-Advanced，HeNB，CA，MBMS等討論及尋找可研究的題目

參與 Carrier aggregation，Relay與MDT方面的討論及尋找可研究的題目

提案報告與參與技術討論

了解各公司對於標準的立場，以便進行技術的佈局

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

三、會議時間

27 June- 27 June 2010

28 June- 2 July 2010

四、會議地點

Clarion Hotel Stockholm, Stockholm, Sweden

五、會議過程

(一)會議議程

ASN.1 seminar (27 June 2010):

Venue: Hotel Clarion, Stockholm, Sweden

Meeting room: C19

Time: From 09:00 to 19:00

RAN2的會議議程如下 (28 June-2 July 2010):

6

Indicative Time-schedule Main room UMTS room

Monday AI [2]: GeneralAI [3]: Incoming liaisonsAI [4]: UMTS/LTE joint session

Tuesday AI [5]: LTE Release 8AI [6]: LTE Release 9AI [7.1.1]: Carrier aggregation: Stage-2

AI [8], AI [9.2], AI [9.4], AI [9.5]

Wednesday AI [7.1.1]: Carrier aggregation: Stage-2

AI [9.3] AI [10.2]

Thu: before morning coffeeThu: morning coffee -> lunch

AI [7.1.2]: Carrier aggregation: Stage-3 Control PlaneAI[7.3] MBMS enhancementsAI [7.4]: TEI10: control plane

Thu: lunch -> afternoon coffeeThu: after afternoon coffee

AI [7.2]: Remaining of [7.x]

All day:AI [10.1], AI [10.3], AI [10.4], AI [10.5]

After-Lunch: Come-backs

Fri: before morning coffeeFri: morning coffee -> lunch

Come –backs

Fri: lunch -> until 5pm

AI [12]: Left-oversAI [13]: Outgoing LS and output to other groups for LTEAI [14]: Any other business

7

(二)會議紀要

LTE Rel-10: Activation/Deactivation

在前次 RAN2#70次會期中，大家對於是否要繼續支援聚合載波的激活(activation)

與去激活(deactivation)概念，做了許多的討論，但最後並未能達成一致的決議。於是

在此次 RAN2#70bis 會議開始之前，由 Ericsson 開啟一個關於此議題的 E-mail

discussion，並邀請眾家公司提供其觀點。詳細的討論則可見下面這篇標準貢獻提案的

整理：

1. R2-103878:Summary of email discussion [70#14] LTE CA: Removal of Activation/De-

activation from Rel-10? (Ericsson)

這篇標準貢獻提案整理了關於是否要維持 activation/deactivation 的 E-MAIL

discussion 結果。大部分的公司認為移除 activation/deactivation 後，將會增加 RRC

signalling 的負載情況並且會增加 UE battery consumption，所以傾向維持原本的

activation/deactivation機制。然而，NTT DOCOMO針對移除 activation/deactivation後

之 RRC signalling的負載狀況，提出了以下這篇標準貢獻提案：

2. R2-104042:RRC overhead comparison of loose and tight CC management policies (NTT

DCM)

這篇標準貢獻提案針對具有 activation/deactivation機制(loose management)、與沒

有 activation/deactivation機制(tight management)下之 RRC signalling負載的情況，提供

了底下之模擬結果。

8

0

0.05

0.1

0.15

0.2

0.25

loose management tight management

scenario #1

MR for PCC management

MR for SCC management

0

0.05

0.1

0.15

0.2

0.25

loose management tight management

scenario #1

CC removalCC additionScell changePcell change

(a) Number of transmitted MRs per UE [1/s] (b) Number of RRC reconfigurations per

UE [1/s]

Figure: Simulation results for scenario #1.

上圖是根據 deployment scenario #1之模擬結果。從模擬結果中我們不難發現，loose

management與 tight management在 deployment scenario #1下所需之 RRC signalling的

負載，其實根本相去無幾。

9

0

0.05

0.1

0.15

0.2

0.25

loose management tight management

scenario #3

MR for PCC management

MR for SCC management

0

0.05

0.1

0.15

0.2

0.25

loose management tight management

scenario #3

CC removalCC additionScell changePcell change

(a) Number of transmitted MRs per UE [1/s] (b) Number of RRC reconfigurations per

UE [1/s]

Figure: Simulation results for scenario #3.

上圖則是根據 deployment scenario #3 之模擬結果。從上圖中可以發現，tight

management比起 loose management為了處理 Pcell改變的情形，多出了約 1.5倍的 RRC

signalling。這是因為 tight management總是試圖去換手到訊號品質最佳的 Pcell上。至

於在 Scell的新增和移除方面，tight management仍舊比起 loose management需要更多

的 RRC signalling。然而，NTT DOCOMO認為這樣的差異其實並不大，因為實際上真

正被配置多載波傳輸的 UEs數量，其實為數不多。因此，多出這些 RRC signalling的

10

負載差異，事實上對整體系統的效能影響不大。

不過由於傾向維持原先 activation/deactivation 機制的公司，仍佔了相對多數。因

此，雖然大多數的模擬結果均指出 activation/deactivation 機制其實並沒有帶來太多好

處，但是最終會議的結論仍決定維持現有的 activation/deactivation的機制。

另外，在這次會期中，我們還針對了 Intra-band聚合載波下，可能造成之RF retuning

的問題，做了相關的討論。最後大家雖然沒達成共識，不過主席亦將大家目前的討論

情況，摘要如下所示：

Status summary:

At DL act/deact, allow intra-band RF retuning or not ?

Solution A: No glitch

1. No glitch at act/deact and measurement deactivated Scell:

single intra-band RF UE will have to keep open the RF at deactivation;

double intra-band RF UE can switch off the Scell RF at deactivation

Solution B: RF retuning solution (glitch)

1. Intra-band RF retuning with glitch at act/deactivation and for measurement on

deactivated Scells

2. Detailed handling of glitch (e.g. is eNB aware?) at act/deact and measurements of

deactivated Scells is FFS

Measurement performance requirements for deactivated Scells can be discussed

independantly:

Intraband, they will probably result in glitches in solution B and not in solution A.

For solution B, FFS if we have to make the eNB aware of the glitches or if they

happen infrequent enough

Assumption is that act/deact of Scells in bandx, or measurements on deactivated Scells in

bandx will not cause glitches on other bands.

11

LTE Rel-10: Pathloss reference

在載波聚合中，RAN2 #70 以及更早以前的會議討論 DL CC的 pathloss reference

當作 UL CC power control 的議題。RAN2 送了一份文件到 RAN4去釐清相關議題，

在 RAN4的回應中提到了：

LTE的是基於收而後傳之運作原則(transmit after receive)，UE需要根據所收到的

DL訊號的指示去傳送 UL訊號。

UE 的上行載波之傳輸功率需要根據估計下行載波的路徑衰落而決定。而上行載

波參考哪一個下行載波需要網路信令指示：

此下行載波需與上行載波在相同一個頻帶上(in the same frequency band)。

此上、下行載波可以是 SIB2 based linkage 或是透過 dedicatedly signalled

linkage。

在 Rel-10中排除了只配置上行載波而不配置其對應的下行載波的情況。

在 RAN4 的回應中，給了一個例子，如圖 1，UL CC#1 的路徑衰落應從 DL CC#1

的路徑衰落來估算，而且 DL CC #1 與 UL CC #1的連結需由網路來指示。DL CC #2

和 UL CC #2的情況亦相似。並且，圖 1指出(UL) CC #1的路徑衰落無法由 CC #2 DL

RSRP來估算，因為 DL CC #2 是透由 RRH到 UE，而 DL CC #1是透由 eNB直接到

UE。RAN4也指出，假設具有 RRH與 Het Net的場景之載波聚合路徑估算，不只會發

生在 inter-band non-contiguous CA 亦可能發生在 intra-band contiguous CA。

12

Macro

RRH

↓↑ ↑ ↓CC #1 CC #2 CC #1 CC #2

Pa

th lo

ss

X

X

CC #1 path loss could not be estimated by CC #2 DL RSRP.

CC #1

CC #2

Macro

RRH

Macro

RRH

↓↑ ↑ ↓CC #1 CC #2 CC #1 CC #2

Pa

th lo

ss

X

X

CC #1 path loss could not be estimated by CC #2 DL RSRP.

CC #1

CC #2

圖 1

在 pathloss reference CC 議題上，我們也提出了一篇 contribution 進一步釐清

pathloss reference CC的 linking 的使用以及 pathloss reference DL CC訊號過差時，網

路端以及 UE端該有的對應行為模式。這議題在會場上討論之後，獲得共識如下：

Agreements on pathloss reference:

1. From a UE point of view, every UL CC is only part of only 1 Pcell/Scell; i.e. even if two

cells would be using the same UL, then for only one of the cells the UE is told to use the

UL CC.

2. Pathloss reference will be configurable between SIB2 linked DL CC or Pcell

3. UE is not required to do RL monitoring for Scells (in line with previous agreement).

4. There is no UE autonomous action when the Scell quality goes below certain quality

levels/out of sync situation.

LTE Rel-10: S-measure in CA

在 RAN2 #70會議中，CA中 Smeasure相關的議題被討論，會議中的結論/共識如

下：

Agreements:

1. Baseline approach for Smeas will be that Smeas will work on the Pcell, and if the Pcell

quality is above quality all non-serving cell measurements can be disabled.

13

Further optimizations are FFS.

然而，當 Pcell的 RARP優於 S-measure，則 UE停止所有 non-serving cell的量測，

會影響到 Scell的 management，例如：UE無法進行 Scell replacement, Scell addition等

等。因此，在 RAN2 #70bis會議之前，有一個 mail discussion 對 S-measure目前的結

論是否要進一步優化，進行討論。其中可能的選項有七項：

- Option 1: current agreement is enough

- Option 2: single Smeas only Pcell disabling all non-serving cell measurements +

possibility to exclude certain objects Smeas

- Option 3: single Smeas working over all Pcell/Scells disabling all non-serving cell

measurements i.e. when one of the cells goes below threshold, we start all

non-serving cell measurements

- Option 4: single Smeas but working independantly on Pcell and Scells. when one of

the serving cells go below threshold, the corresponding non-serving cell

measurements/events are started

- Option 5: different s-Measures to control measurements on different frequencies.

Main difference from Option 4 is to compare s-Measure with only Pcell

quality.

- Option 6: almost same as Option 4. But, RSRQ also can be considered as criteria as

similar to idle mode.

- Option 7: different s-Measure is introduced for inter-RAT measurement in addition

to Option 1. This can help to use high s-Measure for intra-LTE in order to

solve identified issues without performing inter-RAT measurement by using

higher s-Measure value for inter-RAT.

Mail discussion的結論中，提出根據討論的結果，大多公司同意除了 option 1 之

外，應該要有額外的 mechanism去處理 CC management的問題。Mail discussion的 way

forward建議 Option 2 為 baseline解法。然而在會議上討論時，仍有多數公司傾向保持

原本的 option 1 提案，當需要進行 CC management時，則將 S-measure disable，以簡

化 S-measure的運作。經過舉手表決之票數如下：

14

Option 1 (no enhancement): [13]

Option 2 (excluding certain LTE freq from Smeas): [13]

有一半的公司傾向維持 option 1，因此這次會議對於 S-measure的共識決議仍決定

維持原本的 option 1，結論如下：

Agreements on S-measure:

1. Will make no further enhancements related to Smeas in Rel-10.

2. RSRP/RSRQ monitoring for Pcell/ Scell is anyway needed irrespective of s-Measure

handling, e.g. A1-SCC/A2-SCC or A1-PCC/A2-PCC always works regardless of Smeas.

LTE Rel-10: Power Headroom Report

email討論

R2-103580 Summary of e-mail discussion [70#15] LTE CA: PHR Handling Ericsson,

ST-Ericsson Report

這篇 e-mail 討論主要針對幾個 PHR的問題作討論，由於在 e-mail討論中，大部

分的議題，許多公司都已經有共識，所以這邊的結論很快就被同意了，結論如下：

Agreements:

1: There shall be one dl-PathlossChange parameter per UE.

2: There shall be one periodicPHR-Timer timer per UE i.e. only 1 value configured, and

only 1 timer running in the UE valid for all CC's

3: It shall be allowed to transmit a PHR report on any UL CC, e.g. PHR of CC1 can be sent

on CC2.

4: Only one prohibitPHR-Timer value is configured. FFS if we have a timer running per

CC or for the UE as whole.

PHR Type 1/2

針對 PHR的型態使用，RAN1通過有兩種型態可以使用，針對這個部分，大會也

針對兩篇 contributions作討論：

15

R2-103984: Consideration on PHR Type ITRI

這一篇分別討論 Scell 與 Pcell 的情況：針對 Pcell 又分為是否支援 PUCCH 與

PUSCH同時傳的情況，這一篇的假設是同一個時間只傳送一種型態的 PHR。

R2-103551: Discussion on Type 2 PHR Samsung

這一篇只討論 PUCCH與 PUSCH支援同時傳下的 Pcell情況，這篇提議需要

同時傳送兩種型態的 PHR在同一個 TTI裡，這樣 eNB可以知道 UE使用多少的功率

在 PUCCH上。

針對 Scell的部分，沒有公司有異議，所以通過只使用類型 1的 PHR。Pcell的部

分，如果不支援 PUCCH與 PUSCH同時傳的情況下，只使用類型 1的 PHR。如果支

援 PUCCH與 PUSCH同時傳且同一個 TTI PUCCH與 PUSCH同時傳送的話，則需要

同時回報類型 1和 2的 PHR。至於只有傳送 PUCCH或者 PUSCH，是否需要傳送兩種

類型的 PHR則需要進一步討論，有關的會議結論如下：

Agreements:

Scell:

1. For Scell PHR we only use Type 1 PHR.

Pcell:

2. If parallel PUCCH&PUSCH allocation is not supported (FFS if this case exists):

- Type 1 PHR is used for Pcell and Scell, i.e., PHR is the same as in Rel-8/9.

3. If parallel PUCCH&PUSCH allocation is supported, if there is PUCCH and PUSCH

transmission on the Pcell in this TTI:

- Pcell transmits Type1 and Type2 PHR together

Following cases are kept FFS:

4. If parallel PUCCH&PUSCH allocation is supported, if there is only PUSCH

transmission on the Pcell in this TTI:

a) Type 1 & Type2

16

b) Only Type 1

5. If parallel PUCCH&PUSCH allocation is supported, if there is only PUCCH

transmission on the Pcell in this TTI:

a) No PHR for Pcell

b) Type 1 & Type 2

- assume zero power for PUSCH or some virtual PUSCH format ?

c) Only Type 2

- assume zero power for PUSCH or some virtual PUSCH format ?

Reporting w.r.t. multiple UL CC's

由於 email討論，大部分公司都贊同在一個 CC 上面船所有的 PHR，所以接著就

討論，需要傳送哪些 CC的 PHR，選項包括: Scheduled CC 或者 configured CC。這次

討論了下面三篇的 contributions：

R2-103600: Details of cross-carrier power headroom reports Panasonic

R2-103558: Details of PHR for carrier aggregation Nokia Siemens Networks, Nokia

Corporation

R2-103666: Group triggering and reporting of PHR for carrier aggregation New

Postcom

後來經過討論後，兩方的講的都有道理，所以主席後來使用舉手表決，結果如下：

a) all configured (and activated if we have UL activation) UL CCs always report PHR [14]

b) all scheduled UL CC's only [4]

所以就通過，PHR回報的時候，需要回報所有 configured的 CC；結論如下：

Agreement:

1) When PHR report is triggered, PHR is reported for all configured CC's.

- FFS if further restricted by UL CC activation

- FFS how we define a virtual/ref format

FFS if the network should further be able to restrict the PHR reporting by excluding PHR

reporting for certain CC's.

17

是否進一步限縮回報的 CC，則需要進一步討論。

UE PHR

這個議題主要是有公司想要提回報 UE的 PHR，因為他們覺得 UE的 PHR更可反

映真實 UE可以使用的功率剩多少。主要討論的 contributions為下列兩篇：

R2-103634: Per UE PHR for carrier aggregation MediaTek

R2-103558: Details of PHR for carrier aggregation Nokia Siemens Networks,

Nokia Corporation

因為 RAN2一直覺得這是 RAN1的議題，應該要交由 RAN1來討論是否需要，在

offline討論之後，有公司建議送 LS到 RAN1去詢問 RAN1的意見，後來 RAN2也同

意，送一份 LS到 RAN1。

Agenda Item 4.3.2 : Machine type communications

4.3.2.2 RAN overload

由於 RAN overload 是 RAN2#69會議中決議的最優先處理的議題，經過上次

會議的討論之後，這個議題仍是這次會議裡關於 MTC 主要討論的部份，其中又可以

分為幾個子議題:

(1)關於 Current RACH capacity的部份

R2-103973: RACH collision probability analysis

本篇提案是 Huawei所提出的關於MTC的 RACH碰撞的機率分析，因為 Huawei覺得

之前 Vodafone提出的 RACH碰撞的機率公式有些問題，因此他們提出了修正的公式，

並且提議將這些公式用來取代原本的公式。但是在討論的過程當中，許多的公司覺得

這兩組公式的定義並不相同，原本 Vodafone 的公式的定義是當一個 UE 選擇了一個

Preamble時，這個 Preamble剛好被其他人也選擇到的機率是什麼?然而 Huawei所提出

的公式所計算的碰撞機率則是扣除掉一個 RACH slot 最多只有一個 attempt 的機率，

NSN認為之前已經同意的公式是比較好的計算方式，由於沒有其他的公司站出來支持

18

Huawei 的提案，因此主席做結論不修改目前已經同意的版本。Huawei 的第二個提案

建議大會討論並對目前優先處理的MTC對象訂出一個最大可以允許的 RACH碰撞機

率，以免影響一般由人所控制的 UE的資源，但是 CATT認為若是要避免這個問題，

比較好的做法還是將 MTC 的資源獨立出來，由於沒有人支持這個提案，所以建議並

沒有被接受，我們也是認為明確地定出一個可以允許的值在實際上並沒有必要，而且

也會影響系統的彈性。

R2-103906: RACH evaluation for MTC in LTE Ericsson, ST-Ericsson

本提案模擬了兩種 case下MTC RACH造成的 packet delay: arrival intensity 1200 users

跟 arrival intensity 30000 users。Ericsson強調從他們的模擬結果得到的結論是 LTE目

前的設計已經可以 handle大量的MTC device同時 RACH的狀況，因此沒有必要花太

多時間討論這個問題。但是幾家公司覺得這個提案只是顯示出MTC的 delay的部份，

對於大量的MTC device同時做RACH而對一般的使用者所造成的 delay的影響並沒有

在這個提案當中被檢視，所以並不能完全排除大量MTC device做 RACH會對系統產

生影響，經過許多的討論之後，本提案的模擬結果被同意收入到 Technical report當中，

但是同時也強調對一般使用者的影響的部份也必須被列入考慮之中。

R2-103692: Primary Analysis on RACH Capacity for LCR TDD

本提案是針對 LCR TDD的 RACH capacity進行模擬分析的提案，本提案的出發點在

於之前的提案是針對 LTE 以及 WCDMA 的部份，但 LCR TDD 的 random access

procedure與這兩種系統是不一樣的，因此必須另外針對 LCR TDD系統做分析。根據

模擬的結果 CATT 認為只要適當地設定參數的話，LCR TDD 系統將可以支援到超過

500 attempts/s/per carrier的能力，不過 TD tech建議先不要同意這個模擬的結果，下次

會議他們會提供同樣參數的模擬結果，並且將模擬更多的 cases，例如不同數量的

FPACH/PRACH ，因此主席裁定模擬的參數可以被同意，並且在下個會議中希望針對

LCR TDD的部分可以做結論，並希望透過會議外的溝通協調可以先取得共識。

(2)關於 RACH overload protection的部份

19

R2-103606: Analyses of the SA2 Solutions for Access Restriction

本提案是針對之前的許多提案分析他們對 RAN2規格的影響，目前在 SA2討論的幾個

解決方案主要有三種 : SGSN/MME rejects signalling connection requests from MTC

Devices, Broadcasting Access Baring, and RRC connection reject。Panasonic 認為

NAS-based的解決方案對 RAN2的規格影響最小，paging- based的解決方案則對 eNB

以及 RRC signals沒有影響，但是對於 NAS protocol會造成影響，ACB-based以及 RRC

connection reject-based解決方案則會對 RAN2的規格有較的的影響，而且所有的 eNB

都必須要修改以採用新的方法。Panasonic的建議是因為時間緊迫的考慮，建議 RAN2

只考慮對規格影響較小的解決方案，並且通知 SA2也以這個前題來做為討論的方向。

不過別的公司有不同的意見，CMCC認為現在還只是在 Sudy Item的階段，所以目前

就決定以對 RAN2影響較小的方案這個方向有點太早了，Deutsche Telekom則是認為

SA2 並沒有辦法獨立決定哪種方案對 RAN 的影響是較小的，因此要他們以這為前題

去考慮似乎有點奇怪，最後的決議是不接受這樣的提案，但是如果 RAN2有任何的進

展，會通知 SA2。

R2-103742: Evaluation of Rach congestion solutions

這篇提案也是針對之前提出的幾個解決方案進行評估，分別是 ACB based solution,

back off based solution and separate RACH resources。提案中針對這幾種方案所得到的

MTC devices 的 access delay 做模擬以得到模擬的結果，根據模擬的結果發現有增加

RACH resources 的必要，並建議幾個可能的解決方案，分別是在 time domain 跟

frequency domain來增加 RACH resources。並且建議基於 PUSCH的 load來動態地設定

這些額外的 RACH resources。在討論的過程當中由於許多的公司對於模擬的結果有疑

問，因此最後的決議是透過 E-mail discussion 來討論出一個有共識的模擬參數，以免

每次要浪費時間在參數的討論上。

Agenda Item 7.2 : Relays

本次提案針對 header compression方向做討論，本團隊相關的提案如下

R2-103565 Specification impacts and complexity analysis for two header compression

20

proposals

主要是討論 Relay 在 header compression 的做法比較，針對上次會期決議的

“double compression with GTP header uncompressed” 的 壓 縮 方 式 和 用

“Stripping+RoHC”的壓縮方式，討論兩種壓縮方式為使無線資源使用達到進一步最

佳化會產生的複雜度：包括對標準條文所須的更動及額外負載的影響，以方便選擇適

合 LTE Rel-10 Relays 所使用的壓縮方式。本提案在分析兩種壓縮方式對系統的利弊

後，提出兩個提案供討論，如以下所示

Proposal 1: If considering specification impact only, double compression with GTP header

uncompressed proposal should be selected.

Proposal 2: If considering processing overhead and header compression

efficiency, stripping + RoHC proposal should be selected.

本提案在分析得到的結論為：若考慮標準條文所須的更動，則 double compression

with GTP header uncompressed”的壓縮方式會比較適合；若考慮額外負載的影響，則

“Stripping+RoHC”的壓縮方式會比較適合。關於 header compression的議題，再經過

各家廠商討論後，本次會議做成了如下的決議：“No header compression enhancements

for Un in Rel-10”

此外，針對Control Plane的討論，由於各家廠商在這次的會議未對Radio link failure

handling by RN和 RN indicates的議題達成共識，會再藉由 email繼續討論相關議題。

不過，針對 RACH access outside RLF及其它議題，本次會議做成了如下的決議：

(1) D-SR failure/UL data arrival in unsync

D-SR failure results in contention based RACH like in Rel89

21

In case a Type-1 RN performs contention based RACH access (apart from RLF),

it suspends the Un subframe configuration. The Un subframe configuration is

resumed at successfull RACH procedure completion (i.e. after the RN has

received Msg4).

For Type-1a and Type-1b, assumption is that normal procedures apply.

Suspend Un subframe configuration:

- not apply Subframe reception restriction; receive PDCCH. It is up to RN

implementation what it does with the RN-Uu.

(2) Intra-cell handover/DL data arrival in unsync

In case of a Type-1 RN performing non-contention RACH, it suspends the Un

subframe configuration. The Un subframe configuration is resumed at

successfull RACH procedure completion (i.e. after receiving Msg2).

For Type-1a and Type-1b, assumption is that normal procedures apply.

Suspend Un subframe configuration:

- not apply Subframe reception restriction; receive PDCCH. It is up to RN

implementation what it does with the RN-Uu.

(3) RB's on Un

For Rel-10, we will support 8 or 11 Un-DRB's. Choice between 8 or 11 will be made at next

meeting

22

(4) SPS

- For Type1a, Type1b, there is no change so in principle SPS is supported on Un

- For Type1, SPS is not supported on Un

(5) Uplink rate control

No need to specify additional mechanisms/constraints for uplink rate control by the

RN

LTE Rel-9 RRC CDMA2000 Report

2 件關於 LTE Rel-9 RRC 規範的修正提案，其目的是澄清有關 CDMA2000 之參

數，此兩件提案已為 3GPP RAN2所接受並合併於 R2-104173。

R2-103927: Clarification on UL handover preparation transfer

R2-103931: Clarification on HandoverFromEUTRAPreparationRequest message

R2-104173: Clarification on UL handover preparation transfer

另 1件提案則是澄清有關 LTE Rel-9 LPP stage-2規範(3GPP TS 36.305)裡之 session

identifier，此件提案已為 3GPP RAN2所接受。

R2-104078: Corrections on LPP session identifier in Stage 2 HTC

除了以上的提案之外，在 LTE Rel-10中，有一個值得我們關注的重要議題，是關

於 SCell activation/deactivation，相關討論文件和結論詳敘如下。

R2-103878: Summary of email discussion [70#14] LTE CA: Removal of

ctivation/Deactivation from Rel-10? Ericsson Report

23

之前 RAN2 已經同意於 Rel-10 支援 SCell activation/deactivation，此篇 e-mail

discussion主要是討論是否需要在 Rel-10 支援 Scell activation/deactivation，根據參與會

議公司的討論，決定仍然保留 Scell activation/deactivation。

相關討論文件：

R2-104042: RRC overhead comparison of loose and tight CC management policies NTT

DOCOMO, INC. Disc

R2-103708: Performance analysis of secondary carrier activation vs. configuration

Qualcomm Incorporated Disc

R2-103549: On the necessity of DRX enhancement Samsung Disc

R2-103962: DL SCell activation/deactivation without glitches NTT DOCOMO INC. Disc

R2-103535: Activation & Deactivation of SCells Nokia Corporation, Nokia Siemens

Networks Disc

上述除了 Qualcomm與 Samsung文件表達不需要 activation/deactivation的機制於

Rel-10，其餘文件皆希望維持原來的決議，即支援 activation/deactivation。此外，由於

activation/deactivation的關係而延伸另外一個議題，是有關於 RF glitch。此議題於會議

中之初步結論如下

Status summary:

At DL act/deact, allow intra-band RF retuning or not ?

Solution A: No glitch

2. No glitch at act/deact and measurement deactivated Scell:

single intra-band RF UE will have to keep open the RF at

deactivation; double intra-band RF UE can switch off the Scell

RF at deactivation

24

Solution B: RF retuning solution (glitch)

3. Intra-band RF retuning with glitch at act/deactivation and for

measurement on deactivated Scells

4. Detailed handling of glitch (e.g. is eNB aware?) at act/deact and

measurements of deactivated Scells is FFS

Measurement performance requirements for deactivated Scells can be discussed

independantly:

Intraband, they will probably result in glitches in solution B and not in

solution A.

For solution B, FFS if we have to make the eNB aware of the glitches or if

they happen infrequent enough

Assumption is that act/deact of Scells in bandx, or measurements on deactivated

Scells in bandx will not cause glitches on other bands.

除了上述結論外，RAN2還同意發送一 LS (R2-104181)給 RAN4詢問如下問題：

(1) How often does RAN4 expect measurement to be taken on deactivated CC's?

(2) Does RAN4 have any common understanding on the size of the glitch?

(3) Does RAN4 see a significant power consumption benefit from having RF retuning

for deactivated Scells?