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

3GPP TSG RAN WG2 #73會議

報告

派赴國家：台灣台北

出國期間：100年 02月 21日至 100年 02月 25日

報告日期：100年 04月 7日

1

摘要

本次 3GPP TSG RAN2會議於二月在台灣台北舉行，本研發團隊共有 14位

成員出席，此行主要任務說明如下：

技術貢獻：

這次會議，本團隊共提出 16篇技術貢獻， 11 篇在會議中被討論，其中 7篇通

過。

會議解說：

3GPP LTE-Advanced：

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 10的部份，功

2

能大致上都已經完成，現在在做細部的修定，因此，參與同仁將會視情況適時

提出技術提案。

本次會議完成 RAN2 Relays Work Item 以及 RAN mechanisms to avoid CN

overload due to MTC 的工作，未來將有新的 Relay 相關 Study Item 或 Work

Item，在 MTC 技術上，將繼續討論 RAN overload control的議題。

3

目錄

摘要 1

一、 會議名稱 4

二、 參加會議目的及效益 4

三、 會議時間 4

四、 會議地點 4

五、 會議過程 4

六、 會議紀要 5

七、 心得與建議 17

八、 附件 17

4

一、會議名稱3GPP TSG RAN2 #73 Meeting

二、參加會議目的及效益參與 Carrier aggregation，Relay，eICIC，LPP，MTC與MDT方面的討論及

尋找可研究的題目

提出技術提案

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

三、會議時間February 21, 2011 ~ February 25, 2011

四、會議地點38 SongRen Road, Xinyi District, 110

Le Méridien Taipei

Taipei, TAIWAN

五、會議過程

3GPP RAN2 Session #73會議的議程如下：

Indicative Time-schedule Main room LTE room2 UMTS roomMon 09:00 - 19:00 [2],[3],[4]

Tue 08:30 -> [5][6] + CA [7.1.1][7.1.2] [8 non-TDD][9]

[8 TDD]

Wed: 8:30 -> CA CP [7.1.3],MBMS [7.3],MDT [7.4],

TEI-10 CP [7.6]ASN.1 rev [7.10]

RLF [7.7]

CA UP [7.1.4] LCR TDD [10.1]4C [10.2]

ANR [10.5]RFPM[10.3]MDT [10.4]

Thu: 8:30 -> RN [7.2]TEI-10 [7.6]

Capability [7.10]eICIC [7.5]InDev [7.8]

All day:TEI-10 [10.7]Other [10.8]

[10.9]After-Lunch: Come-back

session

Fri: 8:30 -> Come –back session

Fri: lunch -> until 5pm

InDev[7.8],Left-overs, [12][13][14]

Comebacks

5

六、會議紀要

1 36.331規範相關議題

在本次會議，本團隊針對 36.331規範上的一些缺失，共有兩件修正提案被接受

(如下表)：

R2-110816 Parameters confusion of non-CA and CA configurations

R2-110823 Clarification on trackingAreacode acquisition

關於文件 R2-110816，我們修正了現行規範中會令人產生誤解的參數。我們在

36.331 的 5.3.10.3b和 6.2.2兩個章節，分別將參數名稱 radioResourceConfigCom和

radioResourceConfigDedicated 修 正 為 radioResourceConfigCommonSCell 與

radioResourceConfigDedicatedSCell避免造成規範解讀上的誤解。

而另一篇文件 R2-110823，我們修正了 36.331 現行規範中一個上下文不連貫的

缺失。在 cgi的 information element 裡面我們可以知道，當 serving eNB對 UE發出

reportCGI 的要求時，UE 必須回報 cellGlobalId, trackingAreaCode, plmn-IdentityList,

相對應的 information element 如下：

MeasResultEUTRA ::= SEQUENCE {physCellId PhysCellId,cgi-Info SEQUENCE {

cellGlobalId CellGlobalIdEUTRA,trackingAreaCode TrackingAreaCode,plmn-IdentityList PLMN-IdentityList2 OPTIONAL

} OPTIONAL,measResult SEQUENCE {

rsrpResult RSRP-Range OPTIONAL,rsrqResult RSRQ-Range OPTIONAL,...,[[ additionalSI-Info-r9 AdditionalSI-Info-r9 OPTIONAL]]

}}

但是在 5.5.3.1章節裡，現行規範漏掉了 UE必須獲得 trackingAreaCode這個行

為，因此我們提出這篇修正文件。

此外，在一些重點主題方面，各家廠商也提出了許多不錯的見解。例如：

Extended PHR 格式

因為在現行規範中，手機會因為 MPR、A-MPR 的增減或是其它 power

6

management 的因素作一些 power 的調整，我們稱作 power back-off。，在 R2-

110941裡面提到，為了因應 eNB了解手機(UE)做 power back-off 的原因是否來

自於 MPR、A-MPR 的增加或減少，因此提出了在現行的 Extended PHR format

中，使用一個 bit，我們稱作 P-bit，來標示。也就是說，當 eNB 收到一個

Extended PHR 後，發現相對應的 Serving cell 的 P-bit 值為”1”，就知道這個

Serving cell因為 MPR、A-MPR而做了 power back-off的動作，因為這會直接反

應到相對應的 PCMAX,c。Extended PHR format 如下：

PH (Type 1, PCell)

PCMAX,c 1

VR

R

RC1C2C3C4C5C6C7

P

PH (Type 1, SCell 1)

PCMAX,c 2

VR

R P

PH (Type 1, SCell n)

PCMAX,c m

VR

R P

...

Measurement on deactivated cells

由於 RAN4 在 LS 提到希望 deactivated cells 也要能夠做訊號量測，因此

SAMSUNG在 R2-111721提出利用 RRC來控制量測訊號的週期，其細節如下：

MeasObjectEUTRA information element-- ASN1START

MeasObjectEUTRA ::= SEQUENCE {carrierFreq ARFCN-ValueEUTRA,allowedMeasBandwidth AllowedMeasBandwidth,presenceAntennaPort1 PresenceAntennaPort1,neighCellConfig NeighCellConfig,offsetFreq Q-OffsetRange DEFAULT dB0,-- Cell listcellsToRemoveList CellIndexList OPTIONAL, -- Need ONcellsToAddModList CellsToAddModList OPTIONAL, -- Need ON-- Black listblackCellsToRemoveList CellIndexList OPTIONAL, -- Need ONblackCellsToAddModList BlackCellsToAddModList OPTIONAL, -- Need ONcellForWhichToReportCGI PhysCellId OPTIONAL, -- Need ON...,[[measCycleSCell-v10x0 MeasCycleSCell-v10x0 DEFAULT sf320]]

}

CellsToAddModList ::= SEQUENCE (SIZE (1..maxCellMeas)) OF CellsToAddMod

CellsToAddMod ::= SEQUENCE {cellIndex INTEGER (1..maxCellMeas),

7

physCellId PhysCellId,cellIndividualOffset Q-OffsetRange

}

BlackCellsToAddModList ::= SEQUENCE (SIZE (1..maxCellMeas)) OF BlackCellsToAddMod

BlackCellsToAddMod ::= SEQUENCE {cellIndex INTEGER (1..maxCellMeas),physCellIdRange PhysCellIdRange

}

MeasCycleSCell-v10x0 ::= ENUMERATED {sf160, sf256, sf320, sf512,sf640, sf1024, sf1280, spare1}

-- ASN1STOP

measCycleSCellParameter [TBD]: See TS 36.133 [16]. The parameter is used only when an SCell is configured on the frequency indicated by the measObject and is in deactivated state, but the field may also be signalled when an SCell is not configured.

CSI reporting priority

在 RAN1 的 LS 提到，RAN2 必須解決當多個 serving cell 的 CQI reporting

mode/type相同時，該讓哪個 serving cell優先上報 CQI？在 R2-111010，ZTE提

出應該由 ServCellIndex值最小的 serving cell優先上報 CQI，而 R2-110894中，

Panasonic建議讓擁有最大上報 CQI週期的 serving cell優先上報。此兩派說法經

過討論，RAN2傾向 ZTE的說法，因此有以下決議：

Agreements:

1: When DL CC is determined according to a priority, if the reporting mode/type is the same for multiple Cells, the Cell with smallest value of ServCellIndex has the highest priority.

2: Send a reply LS to RAN1 to indicate the priority determination method based on proposal 1 if it is agreed in RAN2. (see R2-110880)

eICIC ABS definition

這是關於 eICIC ABS 的定義，我們討論了兩篇文件(R2-111040、R2-111372)。

最後經由 Alcatel-Lucent 主持的會後討論，決定將以下關於 ABS 的定義列入現

行規範 36.300的章節 16.1.5：

For the time domain ICIC, Almost Blank Subframes (ABSs) are used to protect resources receiving strong inter-cell interference. Almost blank subframes are subframes with reduced transmit power (including no transmission) on some physical channels and/or reduced activity. The eNB ensures backwards compatibility towards UEs by transmitting necessary control channels and physical signals as well as System Information. MBSFN subframes can be used for time domain ICIC when they are also included in ABS patterns. The eNB cannot configure MBSFN subframes [4] as ABSs when these MBSFN subframes are used for other usages (e.g., MBMS, LCS).

8

eICIC DRX⋯

這次會議也針對 eICIC DRX、eICIC TDD tail issue還有 eICIC RSRQ做了許多討

論。其中 RAN2認為 DRX不需要繼續討論，而關於 eICIC TDD tail issue則發了

一個 LS(R2-111335)到 RAN3尋求協助，RSRQ則還需等待 RAN4的決議。這些

相關文件如下：

eICIC DRXR2-111233: UE power saving for eICIC Research In Motion UK Limited DiscR2-111021: Considerations on DRX in eICIC scenario Huawei, HiSilicon Disc

eICIC TDD tail issueR2-111261: Impact of the TDD Tail Problem CATT Disc

eICIC RSRQR2-111330: Filtering effects on RSRQ measurement accuracy for eICICMotorola Solutions

DiscR2-111195: inter-frequency RRM and time domain ICIC enhancement Alcatel-LucentDiscR2-111212: Measurements restrictions for RSRQ Motorola Mobility DiscR2-111008: Discussion on Inter-frequency eICIC ZTE DiscR2-111317: Open issues for Rel-10 UE measurement restriction configurations Nokia Siemens

Networks, Nokia Corporation, Renesas Electronics Europe Disc

PHR triggering

這次會議關於 PHR triggering主要討論了兩篇文件如下：

R2-111155: Further Discussion on PHR Trigger for SARInterDigitalR2-111245: P-MPR related PHR triggering condition NTT DOCOMO, INC.

關於 R2-111155 ，Interdigital為了減少不必要的 PHR被觸發，因此提出了觸發

PHR的其中一個修正案如下，然而並未被接受，必須先等待 RAN4的決議。

- prohibitPHR-Timer expires or has expired and the effect on PCMAX,c of power backoff due to power management (as allowed by P-MPR [10]) for at least one activated Serving Cell with configured uplink and a valid grant has changed more than dl-PathlossChange dB since the last transmission of a PHR when UE has UL resources for new transmissio

而 R2-111245也是討論關於 PHR的觸發條件。NTT DOCOMO考慮如果手機只

是短暫的做 power back-off，這樣會導致 UE很頻繁的觸發 PHR，這也許不是我

們想要的結果，因此提出了三個方法避免：

9

1.Multiple prohibitPHR-Timers

2.Multiple dl-PathLossChanges

3.Time To Trigger for PHR triggering

然而此提案也未被接受，但是能夠進一步思考這類的問題以及提案。

2 RAN mechanisms to avoid CN overload due to MTC議題

關於 RAN mechanisms to avoid CN overload due to MTC (WI: RP-101026)之提案說

明

R2-111011: [72b#20] – UMTS/LTE: MTC CRs

有鑑於 Delay Tolerant Indicator 的位置，應該是放置在 RRCConnectionRquest 訊息還

是在RRCConnectionSetupComplete 訊息中，一直沒有定論。另外，有關 eWaitTime

IE 的設定與處理程序也沒有定論。在 RAN2 #72bis 會議中，RAN2 同意就 Delay

Tolerant Indicator 的位置與 eWaitTime IE 的議題進行 Email discussion。

此 Email discussion 的要點如下：

針對 R2-110612至R2-110615這四篇提案進行討論

分別對 Delay Tolerant Indicator 放置在 RRCConnectionRquest 訊息還是在

RRCConnectionSetupComplete 訊息兩種不同的作法，得到可被採納的CR

討論 CR 對如何處理 spare cause values、對 RAN behavior以及對其他 WG 的

影響

儘可能的得到一個整合的解決方案

經過約三週的 Email discussion，參與廠商仍然分成兩大陣營，各自堅持立場，僅少

數小細節部分得到共識，在討論時，Vodafone 為首的陣營堅持要以

RRCConnectionSetupComplete 訊息來傳遞Delay Tolerant Indicator，雙方僵持不下，

經過 offline discussion 之後，決議如下：

1. 不使用新的 release causes。

10

2. 對 MTC device，不限制 eWaitTime 的使用時機，唯一的例外是在 UMTS 中，

RRCConnectionRelease 訊息中包含了 eWaitTime ，且 WaitTime 必須設為0。

3. 針對 eWaitTime 是否只能對 MTC device 使用的結論為 FFS (於將來再討論)。

4. 對RAN全會提出四個 CR:

1) LTE部分:

a) 使用spare cause

b) 明定對spare cause的處理方式

2) UMTS部分:

a) 使用spare cause

b) 使用extended establishment cause

R2-111348: CN Overload Control by Extending Access Timer

根據 RAN2 #72bis 的會議結果：RAN2同意 delay tolerant indicator 放在 Connection

Request 或是Connection Setup Complete 中；同時 extended wait timer 會傳送到 NAS

層處理。當 CN 過載發生時，MME 會啟動 Overload Start 程序，eNB 進而會拒絕或

釋放 RRC 連線來避免 CN 過載的情況繼續發生。然而，當 CN 過載只是一個短暫的

情況時，直接拒絕或釋放 RRC 連線可能會造成較高的signaling overhead。於是本篇

提案提出讓 eNB 先 buffer 帶有 delay tolerant indicator 的 Connection Request 訊息，

直到短暫的 CN 過載情況解除或是延長的 Connection response timer 終止時，eNB 才

會傳送拒絕的訊息給 delay tolerant device 的做法，藉以達到降低 signaling overhead

以及減少對 CN 的影響。在討論時多家公司建議將這類做法將留待後續的 release 時

再討論。

R2-111630 : Support of Delay Tolerant access requests

這篇提案是規範 UMTS UE 收到 Extended Wait Time 之後的處理程序。

11

R2-111703: Support of Delay Tolerant access requests

這篇提案是規範 LTE UE 收到 Extended Wait Time 之後的處理程序。

3 eICIC議題

R2-111609: CR on ABS definition 36.300 CR0330

這篇提案主要是定義在時域 ICIC 的 Almost Blank Subframes (ABSs)，其中最主要

的定義是說這些 ABSs 子訊框它的傳送功率是可以被降低的，包含完全不傳送任何

的訊號，或是降低在這個子訊框的傳輸活動。而 eNB 必須要物理層傳送基本所需的

控制通道以及系統資訊，使得以舊的版本實現的 UE 可以相容於這個子訊框。這個

提案獲得20個公司的支持，但在討論過程當中，Qualcomm 質疑根據 RAN1 的決

議，功率控制的方式已經被 RAN1 所排除，所以只能寫說降低在這個子訊框的傳輸

活動，而必須移除降低傳送功率等句子。RIM 則指出降低功率的方式已經寫在

RAN1 送給RAN3 的文件當中，因此並無排除降低功率的方式。

最後結論:

由於大多數的公司同意這樣的定義，因此這篇提案獲得通過，但是送一個聯絡文件

給 RAN1說明RAN2的決議與認知。

4 Relay議題

討論以下三件Relay相關的跨組聯繫提案(Liaison)

R2-110734: LS on Security for LTE relay nodes

SA3會議針對Relay Node的安全性解決方案摘要如下：

保護所有在PDCP層元以上的訊務傳輸。

所選擇的解決方案將同時支持個別認證型態和共享密鑰型態的密鑰管理機

制。

12

binding of the RN platform to the RN UICC will be based on UICC secure

channel.

針對RN平台到RN UICC的通訊，將透過UICC安全性通道進行。

R2-110712: Relay LSin – ITU-R

因相關技術在Release-10尚未完全議定，SA建議Relay Node暫時不納入IMT-

Advanced提案內容。

ITU-R Ad Hoc報告摘要：

RAN1提交Relay規範書TS 36.216，擬於RAN Plenary會議核准納入

Release-10。

關於RAN1、RAN2、及RAN3的Relay Working Item之修正請求(CR)，將

提交RAN Plenary會議複核。

RAN4擬新增一Relay相關規範文件，編號TS 36.116，提交提交RAN

Plenary會議複核。

ITU-R Ad Hoc針對將於2011四月召開之ITU-R WP5D#10會議，提出一項

Way Forward “Relaying fuctionality is supported under development for

SRIT and for both FDD and TDD RITs.”

R2-110742: Uu and Un Mapping

SA5詢問RAN2以下有關Uu與Un介面的對應問題：

Q1: In one sub-network, is it possible that different DeNBs have different mappings of the Uu

bearers to Un Bearers? Or shall all the DeNBs in one sub-network have the same mapping?

Answer: Yes, it is possible that RNs within the same sub-network have different mappings.

Q2: In one DeNB, is it possible the DeNB has different mappings of the Uu bearers to Un

bearers to different RNs?

Answer: Yes, it is possible that RNs served by the same DeNB have different mappings.

it is possible that RNs served by the same DeNB have different Uu - Un mappings

RAN2會議針對Relay議題完成以下結論：

加入針對KUPint 之規範敘述。

13

針對PDCP序號：同意採納12bit 之PDCP CN，另外 7bit保留作未來其他用

途。

此外，本團隊亦參與由CMCC、CATT主導之Mobile Relay技術討論，擬於RAN

Plenary提出New Study Item。

Mobile Relay技術目的在於提供多種通訊服務可在高速移動之高速鐵路車廂

中，可以獲得良好之通訊品質。

此外，可改善Group mobility造成的換手成功率。

5 MDT議題進展

本次大會中MDT議題涵蓋以下議程：

3.1 Liaison in

4.3.1 LTE/UMTS joint session

7.4 LTE specific: CR for 36.331

10.4 UMTS specific: CR for 25.331

在預訂的時程中， Release-10的MDT工作項目將在本次會議結束後告一段落，

因此會避免對於目前釋出TS 37.320 v10.0.0的標準作太大的更動，主要是進行一些收

尾的動作，例如對stage 2作一些細部的修改、對應於TS 36.300和TS36.331作stage 3

的CR等。然而由於最近幾次會議中陸續有來自SA工作團隊所提出資安上的疑慮，

由其是“用戶同意”(User Consent)方面的相關問題，有可能會和當初制定標準時的假

設前提相互牴觸，而成為討論的重點，與會的各家廠商必須努力思考解決之道，避

免延誤規劃的進度。最後由於還有數份文件有待SA回覆，估計本次會後MDT整體

完成度達90%，並會在接下來舉行的RAN Plenary會議中決定本議題未來的走向。

本團隊的技術提案是希望MDT的標準中可以納入對於用戶端設備電力狀態的考

量，即在電池狀態低於一臨界值時，量測活動將暫停，避免MDT功能耗盡所有的電

力，造成使用者的負面印象，降低其參與MDT的意願。而該臨界值的選定需進一步

的研究，可以為一固定值，或由營運商經組態訊息去個別設定，也可以由手持裝置

14

設備商在實作時自行決定。本提案雖有獲大會treated，不過多數的意見是認為由於

Release10的工作項已近尾聲，類似想法宜在下一個版本提出，作為討論和功能補強

的依據。若可以針對此作法的效益和實施的複雜度方面多做分析，充實內容後再於

未來的會議中提出，應有被標準所採納的潛力。

本次會議MDT議題相關決議如下：

對於訊令基礎的MDT(signaling based MDT)， OAM在通知eNB前選擇進行MDT

的用戶端設備時，會將用戶意願的狀態納入考量。

對於管理基礎的MDT(Management based MDT)，假設需要通知eNB關於用戶意

願狀態的資訊。將通知RAN3、CT4、和SA5這幾個工作小組對於這個假設的看

法並請它們進行相對標準的必要修改。

用戶同意之撤銷應於上層進行，不需有用戶端設備內上層和AS層之間的互動。

用戶端設備關機後清除組態和已紀錄量測資料的動作改為必要的動作。

鄰近細胞的量測數據收集將加入對於CDMA2000技術的支援

對於SA3提出TCE傳送IP位址的問題提出四個解決方案供其權衡與抉擇

6 舉辦 3GPP會議

這次會議是由臺灣廠商(宏達電與中華電信)與法人（工研院）合作主辦，在這

次會議中有來自全球15個國家，300家公司的近千人參與，包括主要電信業者

（Verizon, AT&T, NTT DoCoMo, China Mobile）、晶片大廠（Qualcomm, Broadcom,

Intel）、網路設備大廠（Ericsson, Alcatel-Lucent, NSN）、手機/設備大廠（Nokia,

Motorola, Samsung、HTC, Huawei、ZTE）等公司，將在本次會議中進行關於3GPP

R10之LTE-Advanced 4G 行動通信標準技術制定。

在會議第一天晚上的歡迎晚宴上，在工研院資通所陳逸萍組長精彩的主持下，

將在RAN1~RAN5制定相關標準的人員全部邀請齊聚一堂，讓在平常只見其字(相關

會議記錄)不見其人的與會人士，有了面對面的機會。在當晚的晚宴上，宏達電周永

明執行長，中華電信呂學錦董事長，工研院徐爵民院長，分別代表致詞。在這些致

15

詞中可以發現不論研究單位或是企業對於通訊產業的發展都抱持相當大的期望與信

心。透過此次在台舉辦的國際標準會議，希望能展現台灣有能力而且有信心來主辦

此一等級之國際標準會議，並且向各與會廠商說明，國內企業與研究單位對於通信

發展之技術與專業現況。

左起 RAN3主席 Dino Flore (Qualcomm), RAN5主席 Phillip Brown (NTT DoCoMo), RAN2主席Gert-Jan van Lieshout (Samsung), RAN1主席Matthrew Baker (Alcatel-Lucent), RAN4主席 Takaharu Nakamura (Fujitsu), 以及工研院資通所陳逸萍組長

16

左起: 工研院徐爵民院長、宏達電周永明執行長、中華電信呂學錦董事長

RAN1~RAN5與會人士

17

七、心得與建議

在這次會議之後本團隊有下列幾項建議與心得：

此次會議於台北舉行，對於提高國內公司的國際能見度非常有幫助，可以參

與會議的國內人員也增加許多。因此，建議可以朝多增加舉辦的次數的方向

進行。

此次 LTE RAN2#73 會議對於許多的 WI 的議題的皆有很大的進展，像 Relay

的 WI 的完成度已經到達 100%的階段，預計在 RAN#51會議會有新的 Study

Item或Work Item產生，因為本團隊也開始規劃下一階段的參與方向。

此外，各個 work item的細節都大致底定，但是仍有其他值得討論的議題。本

團隊在下次 3GPP RAN2會議開始前，密切觀察與注意其相關的發展與內容討

論，比如說 PHR 的觸發條件，必須參考 RAN4方面的資訊，決定較適當的觸

發條件，避免不必要且太頻繁的觸發 PHR。

目前尚有 MTC、In-device coexistence interference avoidance 有較多的討論議

題，我們將持續密切注意，並且開始著手 Rel-11 的規劃。尤其 MTC 的 RAN

mechanism for CN overload也在這次會議中有了技術的共識，並將於 RAN#51

做最後的決議。未來將針對 RAN improvement for MTC 的相關議題進行下一

階段的討論與參與。

對於 3GPP的生態，以及各大公司的立場已經較為熟悉。此次與會，也結識到

更多的朋友，與這些朋友們有更進一步的討論，藉由這些討論，可以將相關

議題中不清楚的地方釐清。

八、附件

1 本次會議本團隊所提技術提案詳見

（http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_73/Docs/）

18

2 本次 3GPP會議相關新聞報導

TV-非凡財金台

2/21經濟日報

19

2/22 太平洋新聞網

2/24 中國時報

20

2/ 24台灣商報

21

2/24 都會時報

3/1 台灣時報

22

2/21 PChome新聞

2/22 PChome新聞

23

2/22 Msn新聞

2/21聯合新聞網

24

2/23聯合新聞網

2/21 iThome

25

2/21 中央日報

2/21中時電子報

26

2/22 財金文化

2/21 鉅亨網

27

2/21 財訊快報

2/21 Yahoo新聞

28

2/22 經濟部通訊產業發展推動小組網站