3gpp ct1 #90 meeting 會議報告

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

3GPP CT1 #90 Meeting 會議報告

出席人員：莊明道

派赴地區：義大利/Sorrento

會議期間：104 年 02 月 02 日至 02 月 06 日

報告日期：104 年 03 月 12 日

1

摘要

本團隊出席在義大利 Sorrento 舉辦的 3GPP CT1 #90 meeting，時間從

2015年 2月 2日至 6日。本次參與的目的是聚焦在CT1最新的LTE-Advanced

Release 13 議題，以發掘 Rel-13 可提出貢獻的潛在機會，並且關注在 ProSe

這個議題，關於 ProSe Rel-12 CR 的修訂，以及未來 Rel-13 鄰近服務限制性

直接發現（ProSe Restricted Direct Discovery）議題的走向。

本團隊這次在 ProSe 議題提出兩篇提案，其中一篇 Tdoc 是關注未來

Rel-13 鄰近服務限制性直接發現的動向，另外一篇 CR 是修正在 Rel-12 規格

書（TS 24.334）中容易被讀者誤解的文字描述。其中這篇 CR 在經過會議討

論之後，再與 Qualcomm 和 Intel 大廠面對面研究修改方式，終於在修正版

的 CR 提案獲會議接受。

由於現任主席 Huawei 的 Georg Mayer 已經當了兩任，下次 CT1 #91 在

Bratislava 的會議即將有主席改選，目前得知有兩位候選人要角逐，候選人

之一是 Ericsson 的 Atle Monrad，他目前是 CT Plenary 主席，而另一位候選

人是 Intel 的 Chen-Ho CHIN。雙方均極力的固樁，相信下次會議的主席選舉

將精采可期。

技術貢獻

此次會議中，本團隊共提出 2篇技術貢獻，其中 1篇獲接受。

本團隊的 ProSe提案如下：

1. C1-150099 “Discussion Restricted Direct Discovery”, Acer Incorporated

<Treated>

2. C1-150475 “ Proximity Request Validation”, Acer Incorporated

<Accepted>

2

會議解說

本次3GPP CT1＃90會議在義大利Sorrento舉辦，共有101位出席參與。

本次參加會議主要任務為發表本團隊的標準提案，參與 ProSe 議案討論，

並關注新的 SI 和 WI，以掌握 3GPP 標準現況與技術發展趨勢。

與會成員工作分配

成員任務

莊明道 1. 報告本團隊的 ProSe 提案

2. 參加 CT1 會議討論有關 ProSe D2D 的主題

3. 尋找在 LTE/LTE Advanced 潛在的問題

3

目錄

摘要 ............................................................................................................................ 1

一. 會議名稱 ............................................................................................................. 4

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

三. 會議時間 ............................................................................................................. 4

四. 會議地點 ............................................................................................................. 4

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

六. 會議紀要 ........................................................................................................... 11

(一) ProSe 相關主題 ............................................................................................... 11

(二) Rel-13 主題 ..................................................................................................... 16

七. 心得及建議 ....................................................................................................... 22

八. 附件 ................................................................................................................... 24

4

一 . 會議名稱

3GPP CT1 #90 Meeting

二 . 參加會議目的及效益

1.追蹤 CT1 在 Rel-13 目前正在探討的議題和未來可能的計畫。

2.發掘在 5G 技術發展過程中可能提出貢獻之機會。

3.追蹤其他公司 ProSe 主題的 Working Items 以及 Change Requests

三 . 會議時間

2015/02/02 ~ 2015/02/06

四 . 會議地點

義大利/Sorrento

HILTON SORRENTO PALACE

Via S. Antonio n. 13, Sorrento, Italy 80067

Tel: +39-081-8784141

Fax: +39-081-8783933

5

五. 會議議程

這次的 3GPP CT1＃90 會議在義大利 Sorrento 舉辦，共有 101 位出席參與。

這次會議的議程如下：

Main Session Breakout (only one at a time)

Monday start: 09:00 / end: latest 20:00

Room:

Tdocs so far:

1+2+4 Opening ()

3 Liaisons ()

13.2.1 new Rel-13 Work Items ()

13.2.2 new WID docs ()

12.5 ProSe (CT6 relevant issues)

12.6 SINE (initial discussion)

Common agenda items

12.11 WORM-CT ()

12.12 WLAN_NS-CT ()

12.20 bSRVCC ()

12.21 SMSMI-CT ()

12.22 TURAN-CT ()

13.4 ePCSCF_WLAN ()

12.19.3 SAES3-non3GPP ()

13.11.3 SAES4-non3GPP ()

tdocs of common / special interest (orange)

()

*if* time permits, start with Tuesday Main

Agenda Items

no breakout on Monday

Tuesday start: 09:00 / end: latest 20:00

Room:

Tdocs so far:

Rel-13 non-IMS tdocs

13.3 ACDC-CT ()

13.4 WSR_EPS ()

Rel-12 non-IMS tdocs

start: 09:00 / end: latest 15:30

Room:

chaired by Peter Leis

Tdocs so far:

IMS issues – Rel-11 and earlier

7.1 Rel-7 and earlier IMS issues ()

8.1 Rel-8 IMS issues ()

6

12.1 Documentation ()

12.2 LIMONET-LIPA ()

12.3 REP-WMD ()

12.4 MTCe-UEPCOP-CT ()

12.5 ProSe ()

12.6 SINE ()

12.7 SCM_LTE-CT ()

12.8 UTRA_LT_WLAN_iwk ()

12.9 OPIIS-CT ()

12.10 eSaMOG_St3 ()

12.13 LIMONET-SIPTO ()

12.14 Dia_SGSN_SMS ()

12.15 GCSE_LTE-CT ()

12.16 MSRD_VAMOS ()

12.17 DMCG ()

12.18 NewToN ()

Low Priority Items (if time permits)

12.19 SAES3, SAES3-CSFB ()

13.11 SAES4, SAES4-CSFB ()

12.48.2 other TEI12 issues ()

13.13.2 other TEI13 issues ()

Most likely there will be common session again in

the main room during the afternoon/evening




Low Priority Items (if time permits – see

Wed main session)

12.47 IMSProtoc6 ()

13.12 IMSProtoc7 ()

12.48.1 IMS TEI12 ()

13.13.1 IMS TEI13 ()

Most likely there will be common session again

in the main room during the

afternoon/evening

Wednesday start: 09:00 / end: latest 20:00

Room:

Tdocs so far:

Rel-13 IMS tdocs

13.6 QOSE2EMTSI-CT ()

13.7 DruMS-CT ()

13.8 INNB_IW ()

13.9 rtp-mux ()

Rel-12 IMS tdocs

12.23 IMS_TELEP ()

12.24 eDRVCC ()

12.25 EMC_PC ()

12.26 IMS_regCon-CT ()

12.27 BusTI-CT ()

12.28 UP6665 ()

12.29 eIODB ()

12.30 IMS_WebRTC ()

12.31 ISAT ()

12.32 ETSI E2NA Transf ()

12.33 NNI_RS ()

12.34 USSD_MS ()

12.35 USSI-NET ()

start: 09:00 / end: latest 20:00

Room:

chaired by Chen-Ho Chin

Tdocs so far:

Rel-11 and earlier non IMS issues

7.2 Rel-7 and earlier non-IMS issues ()

8.2 Rel-8 non-IMS issues ()




Low Priority Items (if time permits – see

Tue main session)

12.19 SAES3, SAES3-CSFB

13.3 SAES4, SAES4-CSFB

12.47.2 other TEI12 issues

13.13.2 other TEI13 issues

afterwards common session in main room

7

12.36 RFC7044 ()

12.37 FS_NNI_RS ()

12.38 eMEDIASEC_CT ()

12.39 IMS_SSFDD ()

12.40 CVO-CT ()

12.41 SIS_CT ()

12.42 REVOLTE_IMS ()

12.43 NETLOC_TWAN_CT ()

12.44 ALTC ()

12.45 PCSCF_RES ()

12.46 EVS_codec-CT ()

Low Priority Items (if time permits)

12.47 IMSProtoc6 ()

13.12 IMSProtoc7 ()

12.48.1 IMS TEI12 ()

13.13.1 IMS TEI13 ()

Common Session (afterwards, if time allows)

common issues from TEI12/TEI11-ish WIs

Thursday start: 09:00 / end: latest 20:00

Room:

if time allows: some input papers which have

not been

treated yet (spill over from Mon/Tue/Wed)

14 Outgoing LS's ()

13.9.3 Future Work Item status ()

15 Late tdocs (if time allows) ()

all AIs Start of Revisions

no breakout on Thursday

Friday start: 09:00 / end: latest 16:00

Room:

14 Outgoing Liaisons

all AIs Revisions

4.2 Workplan, IANA, IETF, etc

16 Any Other Business

17 Closing of Meeting

no breakout on Friday

8

ProSe 相關的主題：

編號篇名提案公司收錄章節

C1-150068 Corrections to XML schema for direct discovery Ericsson / Ivo 24.333

C1-150069 Corrections to usage information report policies Ericsson / Ivo 24.333

C1-150099 Discussion Restricted Direct Discovery Acer Incorporated discussion

C1-150134 Removal of Editor’s notes on MO identifiers in TS 24.333

Qualcomm Incorporated / Lena

24.333

C1-150135 Removal of Editor’s note on XML schema namespace in TS 24.334


24.334

C1-150136 Update of scope of TS 24.334 Qualcomm Incorporated / Lena

24.334

C1-150139 Transport protocol for ProSe usage information reporting


discussion

C1-150140 Addition of transport protocol for ProSe usage inforrmation reporting


24.334

C1-150157 Clarification on the geographical area(s) CATT 24.334

C1-150159 Correction of application identity check when announce request is not accepted by the ProSe function

Qualcomm Incorporated / Zhibin

24.334

C1-150160 Removal of text that should have been marked as deleted in agreed C1-144911


24.334

C1-150163 Change the data type of EPUID in XML schema Qualcomm Incorporated / Zhibin

24.334

C1-150164 Multi-carrier support across PLMNs Qualcomm Incorporated / Zhibin

discussion

C1-150197 Scope clarification for ProSe direct discovery in TS 24.334– alternative 1

LG Electronics/Taehun 24.334







C1-150201 Clarification for service continuity of ProSe direct communication service


C1-150204 TAU procedure for Prose Service ZTE, ZTE Mobile/Fei 24.334

C1-150323 Update scope of TS 24.334 Huawei, HiSilicon /shulin

24.334

C1-150379 Clarification on ProSe for UEs in limited service LG Electronics / Jae 24.334

http://empty/

9


state

C1-150390 Clarification for out of coverage authorisation Samsung/Hoon 24.334

C1-150391 Clarification of location on one-to-many direct communication

Samsung/Hoon 24.334

C1-150394 Addition of proximity services group identifier Orange/Youssef 24.334

C1-150404 Corrections to XML schema for direct discovery Ericsson / Ivo 24.333

C1-150429 Usage information report - formats Ericsson / Ivo 24.334

C1-150430 Usage information report - procedures Ericsson / Ivo 24.334

C1-150475 Proximity Request Validation Acer Incorporated 24.334

C1-150476 Information for IANA registration of MIME type application/3gpp-prose+xml


24.334

C1-150477 Update of definition for UTC-based counter in TS 24.334


24.334

C1-150479 Radio parameters and geographical areas for ProSe direct communication

ZTE, ZTE Mobile/Fei 24.334

C1-150480 start of validity timer on the UE side during announce request procedure

CATT 24.334

C1-150482 SA2 Alignment for multi-carrier support Huawei, HiSilicon /heyue

24.334

C1-150484 Update of RadioParameterContents leaves in ProSe MOs


24.333

C1-150485 UE behaviour when moving out of a geographical area while performing ProSe direct communication


24.334

C1-150486 TAU for ProSe Direct Discovery and ProSe Direct Communication

InterDigital 24.334

C1-150487 Parameters of PDN connection to be used to reach HPLMN ProSe Function

Ericsson, Telecom Italia / Ivo

24.333

C1-150488 Update of XML semantic descriptions for ProSe discovery messages to include extensible XML elements


24.334

C1-150489 Corrections to one-to-many direct communication Samsung/Ricky, Qualcomm Incorporated

24.334

C1-150490 Invalid Application Layer User ID for EPC level discovery

InterDigital 24.334

C1-150493 Clarification on the ProSe Application Code Allocation

Huawei, HiSilicon /heyue

24.334

C1-150704 Clarification on the application identity check CATT 24.334

http://empty/

http://empty/

10


C1-150711 Correction on conditions for activating ProSe direct discovery features

BlackBerry UK Ltd. 24.333

C1-150761 Update of provisioning parameters for usage information reporting configuration in ProSe Public Safety Direct Services Provisioning MO


24.333

C1-150812 Adding behavior description of receiving UE for ProSe direct communication


24.334

C1-150813 Allow in-coverage UE to use provisioned radio resource for ProSe direct communication


24.334

C1-150814 Discovery Type element in PC3 message InterDigital 24.334

C1-150815 Update clause 4 Huawei, HiSilicon /shulin

24.334

C1-150816 Clarification on limited service state Samsung/Hoon 23.122

C1-150817 Misalignment on User Profile in EPC-level discovery

Samsung/Hoon 24.334

C1-150854 Specifying PDN connection to be used to reach HPLMN ProSe Function

Ericsson, Telecom Italia / Ivo

24.334

C1-150856 PLMN selection triggered by ProSe direct communication


23.122



23.122



24.334

http://empty/

http://empty/

http://empty/

http://empty/

11

六 . 會議紀要

(一) ProSe 相關主題

1. C1-150475 Proximity Request Validation

來源： Acer Incorporated

這篇 CR 是修正在 ProSe Rel-12 規格書（TS 24.334）中容易被讀者誤解

的文字描述。修改的理由有下列兩點：

a. 在章節 7.2.8.3 的第一段落，我們容易誤解成 UE B 有權力能同意或

拒絕每個不同 UE（舉例來說，例如同意 UE A 和拒絕 UE C）。

b. 原來的文字描述“從其他的使用者，UE A（from another user, UE A）”

並沒有和章節 7.2.8.3 一致，使用“從其他的使用者們（from other

users）”能夠使章節 7.2.8.3 的三個段落更加一致，也更能使整個章

節 7.2.8 連貫起來。

以下表格一是規格書 TS24.334 章節 7.2.8.3 原文以及修訂後的文字：

7.2.8.3 Proximity request validation procedure in the UE

Upon receiving a PROXIMITY_REQUEST_VALIDATION message, UE B checks whether the

application corresponding to the Application ID included in the message is ready for accepting a

proximity request from other users.

If the application corresponding to the Application ID contained in the

PROXIMITY_REQUEST_VALIDATION message is ready for accepting proximity requests

from other users, the targeted UE shall send the

PROXIMITY_REQUEST_VALIDATION_ACCEPT message to the ProSe Function.

If the application corresponding to the Application ID contained in the

PROXIMITY_REQUEST_VALIDATION message is not ready for accepting proximity

requests from other users, the targeted UE shall send the

PROXIMITY_REQUEST_VALIDATION_RESPONSE message with PC3 EPC Control

Protocol cause value #9 "Application disabled temporarily".

表格一：C1-150475 修訂前後的文字

12

從其他段落使用“從其他的使用者們（from other users）”，而且批准

（validation）程序是用來批准應用程式是否已經準備完成。把文字修改成

“從其他的使用者們”會使整個章節 7.2.8.3 更加的簡潔與一致性。所以我

們提議改變成文字“從其他的使用者們”。如果沒有修改這些文字的話，我

們會容易誤以為 UE B 有權力能同意或拒絕每個不同 UE。

這篇 CR 是從技術提案 C1-150098 修訂過來的，在原先的 C1-150098 技

術提案當中，我們認為在規格書 TS 24.334 的章節 7.2.8.3 描述當 UE B 收到

PROXIMITY_REQUEST_VALIDATION 訊息之後，UE B 要檢查此訊息內是

否關於此應用程式的應用程式使用者身分（Application ID）是準備用來接受

其他使用者的鄰近請求（proximity request），例如 UE A。而 UE B 需要知道

UE A 送出此請求，但是在章節 11.2.4.17 的＜PROXIMITY_REQUEST_

VALIDATION＞內卻沒有 UE A 的應用程式層使用者身分（Application Layer

User ID）欄位。

11.2.4.17 Semantics of <PROXIMITY_REQUEST_VALIDATION>

The <PROXIMITY_REQUEST_VALIDATION> element contains one or more of the

following elements:

1) One or more <proximity-request-validation> element which contains transactions sent by

the ProSe Function to the targeted UE (UE B) to request confirmation of permission for

proximity request. Each <proximity-request-validation> consists of:

a) a <transaction-ID> element containing the parameter defined in subclause 12.3.2.1;

b) an <application-identity> element containing the parameter defined in

subclause 12.3.2.3; and

c) an <Application-Layer-User-ID-A> element containing the parameter defined in

subclause 12.3.2.4.

表格二：C1-150098 修訂前後的文字

13

本團隊原先的主張是將章節 11.2.4.17 中的 PROXIMITY_REQUEST_

VALIDATION 內加入 UE A 的應用程式層使用者身分欄位，如果沒有這樣加

的話，UE B 將不會知道誰發起了鄰近請求（proximity request），也就是說

UE B 只看到有人需要抓取自己當下的位置，卻不知道是哪位使用者提出的

需求，將會造成隱私權的問題。詳細原文修改方式如上表格二。

圖一：TS 23.303 章節 5.5.5 鄰近請求（Proximity Request）程序

但是 C1-150098 的文字修改方式，Qualcomm 與 Intel 認為不大妥當，原

因如上圖一，在規格書 TS 23.303 章節 5.5.5 中，ProSe Function B 不會收到

應用程式層使用者身份 A（Application Layer User ID A），縮寫為 ALUID_A。

所以 ProSe Function B 就不會對 UE B 送出 ALUID_A，因此無法得知誰發起

的鄰近請求。而另一方面來說，App Server 就可以判斷 UE A 是否有權限可

以蒐集 UE B 的位置，交給 App Server 做此功能即可。

8a. LCS Location Reporting Request (A)

7b. Proximity Request Ack ([WLLID_B], B's loc)

3. MAP Response (EPUID_B, PFID_B)

2. MAP Request (ALUID_A, ALUID_B)

(EPUID_A, Application ID, ALUID_A, ALUID_B, window, Range, A's loc, [WLAN ind.])

4. Proximity Request (EPUID_B, EPUID_A, Application ID, window, A's loc, [WLAN ind.], SUPL Config)

UE A UE B SLP A SLP B ProSe Function A App Server ProSe Function B HSS 1. Proximity Request

5a. Location Request (B)

5b. Proximity Request Reject (Cause)

5c. Proximity Request Reject (Cause)

6. Proximity Request Validation ()

7a. LCS Location Reporting Request (B)

8b. Proximity Request Ack

14

因此，在會議中報告之後，Qualcomm 與 Intel 等大廠針對 C1-150098

的技術提案有些意見，因此本團隊經由會後與大廠們面對面以及使用 e-mail

研究修改方式之後，取得一致的共識在會議現場將技術提案修改成

C1-150475，將容易被讀者誤解的文字描述“從其他的使用者，UE A（from

another user, UE A）”修正成“從其他的使用者們（from other users）”，

詳細的文字修改如上表格一，這樣就不會誤解成 UE B 有權力能同意或拒絕

每個不同 UE，終於在修正版的 C1-150475 提案獲會議接受。

2. C1-150099 Discussion about ProSe Restricted Discovery

來源： Acer Incorporated

這篇 discussion paper 是建議 CT1 能討論有關鄰近服務限制性發現

（ProSe Restricted Discovery）的議題。

5.1.1 Restricted ProSe Discovery Use Case

5.1.1.2 Pre-Conditions

- Mary and John are friends;

- John and Peter are friends;

- Mary and Peter are not friends;

- Mary’s UE detects that John’s UE is in its proximity;

- John’s UE detects that Mary’s UE is in its proximity;

- Mary’s UE does not detect that Peter’s UE is in its proximity;

- Peter’s UE does not detect that Mary’s UE is in its proximity;

表格三：TR 22.803 章節 5.1.1 限制性鄰近服務發現的使用情況

15

5.3 ProSe Direct Discovery

5.3.1 General

5.3.1.1 Overview

There are two types of ProSe Direct Discovery: open and restricted. Open is the case where

there is no explicit permission that is needed from the UE being discovered, whereas restricted

discovery only takes place with explicit permission from the UE that is being discovered.

表格四：TS 23.303 章節 5.3 對於鄰近服務限制性發現程序的描述

在 SA1 的規格書 TR 22.803 章節 5.1.1 提及了也同意了鄰近服務限制性

發現的使用情況（use cases），如上表格三，而且在 SA2 的規格書 TS 23.303

章節 5.3 也提到了鄰近服務限制性發現程序，如上表格四，文字中描述：

“鄰近服務直接發現（ProSe Direct Discovery）總共有兩種：開放的（open）

與限制的（restricted）。開放是指說 UE 被人發現並不需要特殊的許可就能達

成，然而限制性的發現（restricted discovery）只有發生在特殊的條件之下允

許這個 UE 被其他人發現到。”

但是在 TS 24.334 的規格書中都沒有任何關於限制性發現（restricted

discovery）的解法，只有開放式的發現（open discovery）有被討論到，因此

我們希望CT1能夠討論有關鄰近服務限制性發現（ProSe Restricted Discovery）

的議題。

本團隊在會議中報告之後，Qualcomm 提出等到鄰近服務 Rel-13 的

working item 被提出之後，就可以開始討論有關鄰近服務限制性發現的議

題。

16

(二) Rel-13 主題

這次 Rel-13 的議題，新增了兩個在會議中被接受的 work item，分別是屢

次嘗試限制以改善系統效能（Retry restriction for Improving System Efficiency，

RISE），以及 IMS 信令激發追蹤（IMS Signaling Activated Trace），其餘則是繼續

討論在前次會期已被接受的議題，本團隊聚焦在災害應變和急難救助相關的議

題，分別是應用程式特定的數據通訊壅塞控制（Application specific Congestion

control for Data Communication，ACDC）與基地台端的警告狀態回報（Warning

Status Report，WSR_EPS）。

1. C1-150844 Retry restriction for Improving System Efficiency (RISE)

來源： Huawei, HiSilicon

在 Release 12 的時候，網路效能信令改善（Signaling Improvements for

Network Efficiency, SINE）的產生是為了改善網路端能夠掌控使用者裝置行為

的效能。

使用者裝置行為的屢次嘗試（retry）限制是 SINE 主要的任務，侵略性的

以及永無止盡的使用者裝置屢次嘗試（尤其是智慧型手機）將會嚴重浪費網

路端的資源，使用者裝置的電池消耗也會非常的快。然而在 Rel-12 中，並非

所有限制屢次嘗試的問題都能夠被討論到以及被解決，因為會議的時間有限，

所以在有些情況下屢次嘗試的問題仍然會存在，舉例如下：

a. 如果使用者裝置註冊到新的PLMN，這個PLMN是列在等效PLMN

（equivalent PLMN）當中，屢次嘗試的問題就沒有被定義到要如

何解決。

b. 如果使用者裝置註冊到新的 PLMN，這個 PLMN 並不是列在等效

PLMN（equivalent PLMN）當中，屢次嘗試的問題就沒有被定義

到要如何解決。

因此這個 work item 的範圍是包含：

17

a. 分析與定義 Rel-12 當中屢次嘗試限制問題沒有被解決的地方，包

含了使用者裝置註冊到新的PLMN，這個PLMN是列在等效PLMN

當中，或是並不是列在等效 PLMN 當中。

b. 提供上述這些屢次嘗試限制問題有個有效的解法。

目前網路擁擠控制以及 CS fallback 也排除在這次的 work item 之外。

如果使用者裝置註冊到新的 PLMN，這個 PLMN 並不是列在等效 PLMN

當中，屢次嘗試的問題就會產生，如果解法會影響到其他 working group，那

麼影響性就要再做評估。

目前影響到的規格書有 TS 24.008 與 TS 24.301，要修改的問題如下：描述

NAS 層某些拒絕的原因會造成使用者裝置（MS）的行為會永無止盡且不必要

的屢次嘗試。增強現有的使用者裝置行為以避免造成信令迴圈或限制能夠重複

嘗試的次數。

目前這個 work item“RISE”獲得了華為、中國移動、中國聯通、海思、

阿爾卡特、阿爾卡特上海貝爾實驗室，以及 LG 電子的支持。

2. C1-150426 IMS Signaling Activated Trace

來源： Vodafone

用戶端以及裝置的追蹤在電話的方面，提供了一個或多個移動用戶非常

詳盡的資訊，這些額外資訊的數據提供效能的量測以及允許未來更嚴密的監

控以及最佳化的操作。

此 work item 信令激發追蹤（signaling activated tracing）是為了改善以及

簡化終端對終端服務的診斷，而且能夠增強電信業者的能力以管理這複雜的

服務。信令激發追蹤主要目標是在終端對終端服務的診斷，並不是在每個節

點的追蹤。根據定義，信令激發追蹤是在某個服務鏈中有捕捉與錄製每個元

件（component）的相關資訊的能力，結合使用者端或是元件端初始的服務，

詳細內容請看 OMA 的文件。

18

在 CT 群組內的信令激發追蹤的任務需求如下：

a. CT1 追蹤 IMS 的會話發起協議（SIP）激發/反激發。

b. CT4 追蹤在 Cx 與 Sh 節點的激發/反激發。

c. CT1、CT3 與 CT4 在 IMS 的端點與端點追蹤。

這個 work item 的主要目的是更新上述所提及的通訊協定介面，以包含

定義在 SA5 會議 TS 32.422 的程序“追蹤控制與配置管理”。通訊協定更新

是必須的，以追蹤激發（activation）與運送信令激發追蹤指示（signaling

activated tracing indicator）。上述的更新必須併入 3GPP IMS 的 SIP 支援以支

援信令激發追蹤。

此 work item 影響到一些規格書，詳列如下：

a. TS 24.229，有關增加、閱讀、與移除 SIP 信令指示的程序必須被錄製。

b. TS 24.323，追蹤管理物件。

c. TS 23.008，增加 IMS 信令激發追蹤的配置資訊到 IMS 用戶資料內。

d. TS 24.292，在Rel-13的TS 24.292將會需要一個MSC伺服器來增加 IMS

信令激發追蹤配置。

e. TS 24.237，在 Rel-13 的 TS 24.237 將會需要一個 EATF 來增加 IMS 信

令激發追蹤配置。

目前這個 work item“IMS 信令激發追蹤”獲得了 Vodafone、Telecom

Italia、Ericsson，以及 Huawei 的支持。

3. C1-150781 ACDC Scope of TS 24.105

來源： LG Electronics

應用程式特定的數據通訊壅塞控制（Application specific Congestion control

for Data Communication，ACDC）這主題在 CT1 #88 bis 獲大會接受。在災難

的情況下，必須支援重要的的通訊服務，為了減輕在這災害環境下網路高度

19

壅塞的狀況，在使用者裝置（UE）內有個有個電信業者定義的應用程式，在

災難發生時有個機制去允許/預防新的接入嘗試（new access attempts）。

ACDC 比較重要的需求如下：

a. ACDC 必須能支援 UTRAN 和 E-UTRAN。

b. 本地網路（home network）必須支援至少四種 ACDC 的種類，這個種類

是由電信業者定義的。

c. 服務中的網路（serving network）必須能夠廣播一個獲多個 RAN 區域，

控制每個 ACDC 種類的資訊，指示堵塞率（barring rates）以及是否漫遊

的使用者裝置必須收到 ACDC 的控制。

d. 使用者裝置必須在某應用程式允許的狀況下，使用者裝置基於廣播的訊

息能夠控制是否要做接入嘗試（access attempts）。

這份 P-CR 定義了讓管理元件（Management Object，MO）能夠配置使用者

裝置有關 ACDC 功能的參數。這 MO 要能夠和 OMA 的裝置管理（Device

Management，DM）版本 1.2 以上兼容。

以下有三種 ACDC 的檢查方式供選擇：

a. NAS 層檢查 ACDC：

以這種方式，收到上層來的會議（session）建立請求時，如果使用者裝置

在 EMM-IDLE 模式，NAS 會做下面的事情：

1. 決定應用程式的 OS APP id 以驅動請求。

2. 決定這個 OS APP id 屬於哪個 ACDC 種類（根據主電信業者經由

OMA 或是 USIM 提供給使用者裝置的資訊）。

3. 從 RRC 得到此 ACDC 種類的堵塞率（barring factor）

4. 執行 ACDC 檢查。

5. 如果 ACDC 檢查成功，著手服務請求（Service Request）程序。

優點：此方式與現有應用程式能搭配。

20

缺點：ACDC 檢查結果有可能與 SIB 的資訊不搭配（由於 SIB 資訊更改

的關係），因為 ACDC 在 NAS 層檢查，而 SIB 是在 RRC 層檢查。

b. RRC 層檢查 ACDC－沒有 NAS 層的影響：

以這種方式，當收到接入嘗試請求時，如果使用者裝置在 RRC_IDLE 狀

態，RRC 會做下面的事情：

1. 決定應用程式的 OS APP id 以驅動接入嘗試請求。



3. 根據 SIB 資訊給予的 ACDC 種類，執行 ACDC 檢查。

4. 如果 ACDC 檢查成功，繼續進行接入嘗試。

優點：1. 此方式與現有應用程式能搭配。

2. 沒有 NAS 層的影響。

缺點：1. 需要 RRC 層決定決定應用程式的 OS APP id 以驅動接入嘗試請

求。

2. 需要 RRC 層意識到 ACDC 資訊經由 OMA 或是 USIM 提供給使

用者裝置。

c. RRC 層檢查 ACDC－些許 NAS 層的影響：

以這種方式，收到會議（session）建立請求時，如果使用者裝置在

EMM-IDLE 模式，NAS 會做下面的事情：

1. 決定應用程式的 OS APP id 以驅動會議建立請求。



3. 將相關的ACDC種類結合服務請求與呼叫形式，傳送給RRC層。

優點：此方式與現有應用程式能搭配。

21

缺點：1. 需要 NAS 層決定應用程式的 OS APP id 以驅動會議建立請求。

2. 需要額外的介面在 NAS 與 RRC 之間以運送 ACDC 種類和給定

服務請求。

分析：a選擇需要想辦法解決ACDC檢查結果和 SIB的資訊不搭配的問題，

b 選擇與 c 選擇的主要差異在是 NAS 層或 RRC 層決定應用程式的 OS APP id

以驅動會議建立請求，因為 NAS 層與應用程式層之間本來就已經有介面，所

以會建議 c 選擇來實作 ACDC 會比較好。

4. C1-150807 WSR_EPS Scope for TR 23.712

來源： one2many, AT&T, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell

訊息來源者（例如移動網路的電信業者或是政府授權部門想要廣播公共警

告訊息（Public Warning Messages））需要知道是否警告人群有成功。移動電信

業者需要知道是否他們已經完成了服務需求，以及是否真的廣播出去警告訊

息（Warning Messages）給市民。

目前的機制是重複數次傳送警告訊息完成後，就任務達成，沒有任何的回

報機制有關這個廣播是成功或是失敗。第二點，必須要有能力回報有哪些基

地台沒有確實的將警告訊息傳送給一般大眾。

這個 work item 的主要目的是增強在 LTE 有關警告訊息傳送（Warning

Message Delivery）回報的能力。此主題將會考慮或評估下面列出的能力：

a. 基地台（(H)eNB）回報在警告區域（Warning area）的每個 cell 最後

廣播的時間以及廣播了多久，是否有廣播成功或是部分成功部分失敗，

以及回報如果沒有廣播成功的原因為何。

b. 基地台回報在警告區域的 cell 是否有支援 PWS，如果不支援的話回

報原因為何。

相關的 3GPP 規格書為 TS 23.041，也就是我們常看到的細胞廣播（cell

broadcast）規格書。

22

而新的規格書 TR 23.712 則是增強現有 TS23.041 Rel-12 的警告狀態回報

（Warning Status Report）機制，研究內容包含：

a. 定義警告狀態回報（Warning Status Report）的需求。

b. 定義和評估警告狀態回報的方法。

c. 分析與原有機制的交互行為。

d. 建議選擇的方式。

這研究的成果將會有可能用當 3GPP 規格書中有關增強性警告狀態回報

（enhanced Warning Status reporting）機制。

七 . 心得及建議

這次的 CT1 #90 會議通過了兩個新的 Rel-13 work item，分別為屢次嘗

試限制以改善系統效能（RISE），以及 IMS 信令激發追蹤（IMS Signaling

Activated Trace）。原有已被通過的 Rel-13 work item 也持續在討論，其中包

括在災害應變和急難救助相關的議題，分別是應用程式特定的數據通訊壅

塞控制（ACDC）與基地台端的警告狀態回報（WSR_EPS），詳細的內容如

第六章的會議紀要。

另外在 Rel-12 規格書的後續追蹤，雖然在 Rel-12 上面已經不能新增功

能，但是規格書中描述不清楚需要釐清與澄清的地方（可能影響 Rel-13 的

發展方向），或是規格書中有誤值的文字等等，也是有相當多的公司提案在

Rel-12。其中最多公司提案的是鄰近服務（ProSe）主題，當然本團隊也提

出了一篇 CR 提案（C1-150475）獲會議接受，如第八章的附件所述。我們

將持續關注 ProSe 議題在未來 Rel-13 的發展，例如鄰近服務限制性直接發

現（ProSe Restricted Direct Discovery）議題的走向。

23

Rel-12 除了較受矚目的主題鄰近服務之外，網路效能的信令改善

（Signaling Improvements for Network Efficiency, SINE）是比較有爭議性的

主題，SINE 主要是說有些比較侵略性的應用程式會一直對底層（NAS 層）

送服務請求（Service Request），這會造成用戶端與網路端之間造成大量且

頻繁的信令，例如一直想要重複建立 PDP 連線，或是被 NAS 層拒絕，或是

NAS 層的計時器屆滿之後，又一直永無止盡的屢屢想重試。這將會嚴重的

浪費網路的資源，也會讓智慧型使用者裝置的電力耗竭。因此需要網路端

的協助來改善裝置的行為，以減少不必要的屢屢嘗試，例如網路端定義新

的拒絕原因（reject cause）。在這次 SINE 的議題，大意是說如果網路端提

供了 back-off timer，終端就不能在同個 APN 屢次嘗試（E）SM request，直

到計時器屆滿，則終端將關閉或是移到不是在等效 PLMN 欄位內的電信業

者。除此之外，終端接下來的行為根據網路端提供的再次嘗試指示（reattempt

indicator），如果網路端表示可以在換 RAT 時做再次嘗試，則終端在換 RAT

到 UTRAN 或 GERAN 的時候可以對同一個 PDP context 做再次嘗試指示。

主要歧見在於終端收到網路端來的拒絕原因時，back-off timer 與 T3396 的

處理方式，在會議中主席還發起了表決，表決結果是以 Nokia 為首的提案

獲得了贊成 17 票/反對 2 票，而以 Intel 為首的提案獲得了贊成 4 票/反對 4

票，最終通過以 Nokia 為首的提案。

關於下次 CT1 #91 在 Bratislava 的主席改選，由於現任主席 Huawei 的

Georg Mayer 已經當了兩任，目前得知有兩位候選人要角逐，候選人之一是

Ericsson 的 Atle Monrad，他目前是 CT Plenary 主席，而另一位候選人是 Intel

的 Chen-Ho CHIN。一個是基地台端的代表，一個是使用者裝置端的代表，

雙方均極力的固樁，相信下次會議的主席選舉將精采可期。

24

八 . 附件

技術貢獻提案清單

3GPP CT1#90 (2nd Feb – 6th Feb 2015)，Sorrento，Italy (2:2:1)

1. C1-150099 Discussion Restricted Direct Discovery, Acer Incorporated,

<Treated>

2. C1-150475 Proximity Request Validation, Acer Incorporated, <Accepted>

3gpp ct1 #90 meeting 會議報告

Documents