出國報告電子檔規格std-share.itri.org.tw/content/files/report/files/bsmi... · web...

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

3GPP CT1 #95 Meeting 會議報告

出席人員：陳陪蓉派赴地區：美國/安那翰會議期間：104 年 11 月 16 日至 104 年 11 月 20 日報告日期：104 年 12 月 2 日

摘要本團隊出席在美國安那翰舉辦的第三代合作夥伴計畫（3GPP）核心網

路及終端第一工作群（CT1）第 95 次會議，時間從 2015 年 11 月 16 日至 20

日。本次參與的目的是聚焦在核心網路及終端第一工作群最新的長程演進技術升級版（LTE-Advanced）第 13 版（R13）議題，以發掘第 13 版可提出貢獻的潛在機會，並且關注在延伸非連續接收 (Extended Discontinuous

Reception, eDRX)，以及延伸改進鄰近服務(Enhancements to Proximity-based

Services - Extensions, eProSe-Ext)等議題。本團隊這次在延伸非連續接收提出一篇提案，針對因為延長非連續接

收週期而產生的簡訊議題，依據服務與系統面第二工作群(SA2)已經達成的共識，進一步修正改進核心網路及終端的標準規格書，使其支援用戶設備簡訊接收。然而會議中有公司對於本篇提出的方法表示疑義，並且其他公司認為本篇的敘述並無需要，因此最後本篇提案並未被大會接受。

技術貢獻此次會議中，本團隊共 1篇提案，但未被接受

1. C1-154148 “Indicate follow-on proceed in routing area update accept for stored MT SMS of eDRX MS”, <Treated>

會議解說本次 3GPP CT1＃95 會議在美國安那翰舉辦，共有 166 位出席參與。本次參加會議主要任務為發表本團隊的標準提案，參與延伸非連續接

收以及延伸改進鄰近服務議案討論，並關注新的研究項目（Study Item,

2

SI）和工作項目（Work Item, WI），以掌握 3GPP 標準現況與技術發展趨勢。

與會成員工作分配成員任務

陳陪蓉 1. 報告本團隊的延伸非連續接收提案2. 參加 CT1 會議討論有關延伸非連續接收以及延伸

改進鄰近服務等主題3. 尋找在長程演進技術(LTE)和長程演進技術升級版

潛在的問題

3

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

技術貢獻......................................................................................................................2

會議解說......................................................................................................................2

與會成員工作分配......................................................................................................3

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

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

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

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

五. 會議紀要..........................................................................................................14

六. 心得及建議......................................................................................................24

七. 技術貢獻提案清單..........................................................................................25

4

一. 會議名稱3GPP CT1 #95 Meeting

二. 參加會議目的及效益1.追蹤 CT1 在第 13 版目前正在探討的議題和未來可能的計畫。2.發掘在第五代行動通訊（5G）技術發展過程中可能提出貢獻之機會。3.追蹤其他公司延伸非連續接收主題與延伸加強鄰近服務主題的工作項目（Work Item，WI）以及修改請求（Change Request, CR）

三. 會議時間2015/11/16 ~ 2015/11/20

四. 會議地點美國/安那翰Hotel Address and Contact Information:

Hilton Anaheim

777 Convention Way

Anaheim, CA 92802, US

Tel: +1 714 750 4321

Fax: +1 714 740 4460

5

會議議程這次的 3GPP CT1＃95 會議在美國安那翰舉辦，共有 166 位出席參與。這次會議的議程如下, 其中藍色醒目提示部分為本團隊參與之議題：

Main Session Breakout (only one at a time)Monday start: 09:00 / end: latest 20:00

1+2+4 Opening ()

3 Liaisons (30)

4 IANA, etc, early as needed ()

13.1.1 new Rel-13 Work Items (6)

13.1.2 new WID docs (2)

13.1.3 docs on other WIDs ()

Common agenda items

13.3 ACDC-CT (4)

13.4 eProSe-Ext-CT (selected)(32)

13.5 RISE (4)

13.6 MCPTT (selected) ()

13.8 WSR_EPS (2)

13.9 ePCSCF_WLAN ()

13.18 SEW1-CT (3)

13.10.3 SAES4-non3GPP (selected) (7)

tdocs of common / special interest (orange) ()

*if* time permits, start with Tuesday Main Agenda Items

no breakout on Monday

6

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

Room:

Tdocs so far:

MCPTT – “Common session 09:00 – 12:30”

13.6.1 MCPTT general ()

13.6.2 MCPTT 24.279(10 / 27)

13.6.3 MCPTT 24.380(18 / 24)

13.6.4 MCPTT 24.381(0 / 3)

13.6.5 MCPTT 24.382 ()

13.6.6 MCPTT 24.383 ()

13.6.7 MCPTT other(0 / 1)

13.7 MCPTT-Prof (1 / 3)

Rel-13 non-IMS tdocs 14:00 – 20:00

13.4 eProSe-Ext-CT (32)

13.11 EVSoCS-CT ()

13.12 MONTE-CT ()

13.13 MEI_WLAN (1)

13.14 ASI_WLAN (11)

13.15 NBIFOM-CT (22)

13.16 GROUPE-CT (1)

13.17 eDRX-CT (21)

13.19 DECOR-CT (2)

*if* time permits, start with Wednesday Main Agenda Items

start: 14:00 / end: latest 20:00

Room:

Tdocs so far:

Rel-13 IMS tdocs

13.20 voE-UTRAN_PPD-CT (1)

13.21 QOSE2EMTSI-CT (1)

13.22 ISAT ()

13.23 DruMS-CT (1)

13.24 RTCP-MUX (1)

13.26 PCSCF_RES_WLAN (4)

13.27 INNB_IW (1)

13.28 mSRVCC (3)

13.29 eWebRTCi_CT ()

13.30 ROI-CT ()

Rel-12 IMS tdocs

12.20 bSRVCC ()

12.21 SMSMI-CT ()

12.22 TURAN-CT ()

12.23 IMS_TELEP (3)

12.24 eDRVCC ()

12.25 EMC_PC ()

12.26 IMS_regCon-CT ()

12.27 BusTI-CT (2)

12.28 UP6665 ()

12.29 eIODB ()

12.30 IMS_WebRTC (24)

12.32 ETSI E2NA Transf ()

12.33 NNI_RS ()

12.34 USSD_MS ()

12.35 USSI-NET ()

12.36 RFC7044 ()

7

12.37 FS_NNI_RS ()

12.38 eMEDIASEC_CT (1)

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 (2)

12.46 EVS_codec-CT ()

IMS issues – Rel-11 and earlier

8.1 Rel-8 IMS issues (13)

9.1 Rel-9 IMS issues ()



*if* time permits, start with Thursday IMS-BO Agenda Items

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

Room:

Tdocs so far:

Rel-12 non-IMS tdocs

12.1 Documentation ()

12.2 LIMONET-LIPA ()

12.3 REP-WMD ()

12.4 MTCe-UEPCOP-CT ()

12.5 ProSe (4)

12.6 SINE ()

12.7 SCM_LTE-CT ()

12.8 UTRA_LT_WLAN_iwk ()


Room:

Tdocs so far:

IMS issues – Rel-11 and earlier





*if* time permits, start with Thursday IMS-BO Agenda Items

MCPTT may have an evening session from 18:10 8

12.9 OPIIS-CT ()

12.10 eSaMOG_St3 ()

12.11 WORM-CT ()

12.12 WLAN_NS-CT ()

12.13 LIMONET-SIPTO ()

12.14 Dia_SGSN_SMS ()

12.15 GCSE_LTE-CT (2)

12.16 MSRD_VAMOS ()

12.17 DMCG ()

12.18 NewToN ()

Rel-11 and earlier non IMS issues

8.2 Rel-8 non-IMS issues ()




*if* time permits, start with Thursday Main Agenda Items

– 20:00 if this is found necessary. If this is needed, the IMS-BO will stop at 18:00

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

Room:

Note that it will be a common session on:

MCPTT – “remaining Tdocs & revisions 14:00 – 15:30”

13.6 MCPTT ()

Tdocs so far:

Low Priority Items

12.19 SAES3 (all aspects) (4)

13.10 SAES4(all aspects) (22)

12.48.2 other TEI12 issues (4)


Room:

Note that it will be a common session on:

MCPTT – “remaining Tdocs & revisions 14:00 – 15:30”

13.6 MCPTT ()

Tdocs so far:

Low Priority Items

12.47 IMSProtoc6 ()

13.25 IMSProtoc7 (8)

12.48.1 IMS TEI12 (5)

9

13.31.2 other TEI13 issues (36)

if time allows: some input papers which have not been

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

14 Outgoing SAE-legacy-related LS's ()

15 Late tdocs (if time allows) ()

all AIs Revisions

13.31.1 IMS TEI13 (18)

if time allows: some input papers which have not been

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

14 Outgoing IMS-related LS's ()

15 Late tdocs (if time allows) ()

all AIs Revisions

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

Room:

14 Outgoing Liaisons

all AIs Revisions

4.2 Workplan, IETF, etc

16 Any Other Business

17 Closing of Meeting

10

eDRX 相關的主題編號標題提案公司收錄章節C1-153540 eDRX abbreviation, reference to TS

24.008 and some correctionsHuawei, HiSilicon /Christian 24.301

C1-153542 eDRX and emergency bearer services Huawei, HiSilicon /Christian 24.301C1-153543 eDRX and emergency bearer services Huawei, HiSilicon /Christian 24.008C1-153833 MT-SMS absent subscriber due to eDRX Alcatel-Lucent, Alcatel-

Lucent Shanghai Bell /Jennifer

23.040

C1-153839 Extended DRX accepted by the network Ericsson 24.301C1-153840 Support of eDRX in the UE Huawei, HiSilicon /Christian 24.301C1-153948 Extended DRX accepted by the network Ericsson 24.008C1-153959 Support of eDRX in the MS Huawei, HiSilicon /Christian 24.008C1-153960 Interaction between PSM and eDRX Huawei, HiSilicon /Christian 24.301C1-153996 Lack of requirement on mandating

repeating the request of eDRX at TAUHuawei, HiSilicon /Christian 24.301

C1-153997 Lack of requirement on mandating repeating the request of eDRX at RAU

Huawei, HiSilicon /Christian 24.008

C1-154132 use of the eDRX parameters provided by the network

CATT / Yanchao 24.301

C1-154133 use of the eDRX parameters provided by the network

CATT / Yanchao 24.008

C1-154148 Indicate follow-on proceed in routing area update accept for stored MT SMS of eDRX MS

Acer Incorporated 24.008

C1-154314 eDRX definition, abbreviation and some corrections


C1-154315 Interaction between PSM and eDRX Huawei, HiSilicon /Christian 24.008C1-154371 Discussion on the solution for enabling

eDRX through TAU Reject with T3346LG Electronics / SangMin Disc

C1-154372 Enabling eDRX in TAU reject with T3346 – Alt1

LG Electronics / SangMin 24.301

C1-154373 Enabling eDRX in RAU reject with T3346 – Alt1


C1-154374 Enabling eDRX in TAU reject with T3346 – Alt2


C1-154375 Enabling eDRX in RAU reject with T3346 – Alt2


C1-154634 Extended DRX IE addition Ericsson 24.301C1-154635 IMSI paging without eDRX parameters Ericsson / Mikael 24.008C1-154636 UE temporarily unreachable due to eDRX Qualcomm Incorporated /

Amer29.118

C1-154637 MS using power saving Qualcomm Incorporated / Amer

23.040

C1-154638 Paging for a UE which the network accepted to use eDRX


C1-154639 Paging for an MS which the network accepted to use eDRX


C1-154706 Extended DRX IE addition Ericsson 24.008

11

eProSe 相關的主題編號標題提案公司收錄章

節C1-153440 Trigger to start Discoveree Procedure INTERDIGITAL

COMMUNICATIONS24.334

C1-153347 Timer update ZTE, ZTE Mobile 24.334C1-153345 Removal of Editor’s Notes for Discovery Filter Update ZTE, ZTE Mobile 24.334C1-153437 Correction of ProSe Discovery UE ID provisioning and

Wrong ReferenceQualcomm Incorporated 24.333

C1-153681 Update of ProSe service authorisation for one-to-one communication

Qualcomm Incorporated 24.334

C1-153869 Dynamic metadata support in Open direct discovery Huawei, HiSilican / Yue 24.334C1-153875 The granularity for application authorization check CATT/Yanchao 24.334C1-153876 Timer T4007 handling for on-demanding announcing CATT/Yanchao 24.334C1-153882 Metadata upload during Discovery Request procedure INTERDIGITAL

COMMUNICATIONS24.334

C1-153883 New ProSe Discovery Update message ZTE, ZTE Mobile 24.334C1-153884 Scope Clarification of ProSe Direct discovery when not

served by E-UTRANLG Electronics/ Taehun 24.334

C1-153885 Scope Clarification of ProSe Direct discovery when not served by E-UTRAN

LG Electronics/ Taehun 24.333

C1-153886 Figure clarification for Direct discovery update procedure for open discovery

CATT/Yanchao 24.334

C1-153887 Clean up for TS 24.334 Qualcomm Incorporated 24.334C1-153917 Addition of UE handling of parameters Current Time and

Max OffsetQualcomm Incorporated 24.334

C1-153930 Configuration for ProSe Function-initiated PC3 procedures for ProSe direct discovery


C1-153931 Service authorisation trigger at the expiry of T4015 ZTE, ZTE Mobile 24.334C1-153937 Error handling for restricted discovery when application-

controlled extension is usedQualcomm Incorporated 24.334

C1-153944 Mandanate the target RPAUID in the DISCOVERY_RESPONSE message for restricted ProSe direct discovery model B

CATT/Yanchao 24.334

C1-153952 Associate the Target RPAUID and corresponding discovery filters

CATT/Yanchao 24.334

C1-153955 Add ProSe Application Code check in the monitor request procedure

Huawei, HiSilican / Yue 24.334

C1-153995 Announcing Alert procedure update Huawei, HiSilican / Yue 24.334C1-154090 Discussion on size of parameters of ProSe discovery for

public safety useEricsson / Ivo Disc

C1-154091 Discussion on coding of Target Info parameter in Group Member Discovery Solicitation

Ericsson / Ivo Disc

C1-154390 ProSe direct discovery for public safety use - coding Samsung R&D Institute UK

24.334

C1-154149 PC5 discovery message format for PS discovery and Relay discovery additional Information

Ericsson / Ivo 24.334

C1-154394 Proposals for Remote UE Report delivery mechanism Samsung R&D Institute UK

Disc

C1-154396 Remote UE info report to the network (Alternative 1) Samsung R&D Institute UK

24.301

C1-154397 Remote UE info report to the network(Alternative2) Samsung R&D Institute 24.301

12

UKC1-154404 ESM procedure to provide ProSe UE-to-network relay

serviceSamsung R&D Institute UK

24.301

C1-154134 Authorisation check when the UE’s context exist CATT / Yanchao 24.334C1-154377 New ProSe access type in P-Access-Network-Info header

fieldQualcomm Incorporated / Lena

Disc

C1-154299 PC5_DISCOVERY message format for restricted ProSe direct discovery


C1-154360 Non- Zero Discovery Entry ID ZTE, ZTE Mobile DiscC1-154177 Value range of Requested Timer parameter Qualcomm Incorporated 24.334C1-154358 UE Timer handling ZTE, ZTE Mobile 24.334C1-154264 eProSe-Ext-CT impacts Qualcomm Incorporated

/ LenaInfo

C1-154457 New access type value for ProSe UE-to-Network Relay Qualcomm Incorporated / Lena

24.229

C1-154466 ProSe direct discovery for public safety use - coding Ericsson / Ivo 24.334C1-154467 PC5 discovery message format for PS discovery and

Relay discovery additional InformationSamsung R&D Institute UK

24.334

C1-154601 Inter-PLMN discovery transmission Qualcomm Incorporated 24.334C1-154602 Authorisation check when the UE’s context exist CATT 24.334C1-154603 Per PLMN check authorisation ZTE, ZTE Mobile 24.334C1-154606 Announcement of Relay Discovery Additional

Information for public safety useSamsung R&D Institute UK

24.334

C1-154608 ProSe Per-Packet Priority Qualcomm Incorporated 24.334C1-154609 PC5 signalling protocol for one-to-one ProSe direct

communicationQualcomm Incorporated 24.334

C1-154611 Non-Zero Discovery Entry ID ZTE, ZTE Mobile 24.334C1-154613 Match report procedure for restricted ProSe direct

discovery Model AQualcomm Incorporated 24.334

C1-154614 Match report procedure for restricted ProSe direct discovery Model B


C1-154615 Provisiong ProSe parameters for public safety use Samsung R&D Institute UK

24.333

C1-154495Discussion on size of parameters of ProSe discovery for public safety use

U.S. Department of Commerce Disc

C1-154643 Clarification on PF behaviour for open discovery ZTE, ZTE Mobile 24.334C1-154660 Add the missed ACE-enabled-indicator in the XML

SchemaHuawei, HiSilicon/Yue 24.334

C1-154661 Add a ProSe Discovery UE ID related validity timer in the ProSe Function

Huawei, HiSilicon/Yue 24.334

C1-154689 ProSe direct discovery for public safety use - UE-to-network relay procedures


C1-154690 ProSe direct discovery for public safety use - group member discovery procedures


C1-154691 Correct a mistake about Discovery Type Huawei, HiSilicon/Yue 24.334C1-154704 Invalid suffix information error in the Discovery Request

messageINTERDIGITAL COMMUNICATIONS

24.334

C1-154703 UE-to-network relay selection and reselection procedure Qualcomm Incorporated 24.334C1-154709 Remote UE Report procedure addition Ericsson / Mikael 24.301C1-154824 Cell ID announcement request procedure Huawei, HiSilicon/Yue 24.334C1-154825 TMGI monitoring request procedure for eMBMS traffic

relayHuawei, HiSilican / Yue 24.334

C1-154834 Update the Monitor request procedure for restricted ProSe direct discovery for the latest metadata receiving

Huawei, HiSilicon/Yue 24.334

13

五. 會議紀要本團隊提案的處理狀況:

文件編號文件名稱提案公司狀態C1-154148 Indicate follow-on proceed in routing

area update accept for stored MT SMS of eDRX MS

Acer Incorporated Treated

本團隊提案的詳細討論過程1. C1-154148 Indicate follow-on proceed in Routing Area Update Accept for

stored MT SMS of eDRX MS (eDRX)

提案公司: Acer Incorporated

提案源由:

延伸非連續接收是一個延長用戶設備(User Equipment, UE)非連續接收週期(DRX cycle)的機制，用意是增加用戶設備的休眠時間，達到增進省電的效果。延伸非連續接收機制是第 13 版的議題，針對機器型態通訊(Machine-Type Communication, MTC)等需要高度省電的應用所產生的研究，其機制詳解的概念流程首先在服務與系統面第二工作群被討論。除了延伸非連續接收機制本身的流程之外，更動非連續接收週期造成的相關議題，例如用戶設備呼叫(Paging)、移動裝置接收簡訊(MT SMS)、GPRS隧道協定重傳計時器(GTP re-transmission timer)設置等等，也列入了服務與系統面第二工作群的討論範圍之內。針對上述諸議題，服務與系統面第二工作群在今年 7 月的 SA2#110 會議中已經達成協議，形成原則性的解法，所有討論後達成共識的結果集大成在 TR 23.770 報告之中。

今年 9 月，核心網路與終端第一工作群組通過了工作項目 eDRX-CT。承接服務與系統面第二工作群的成果，依據 TR 23.770 所述的原則性解法，開始制定核心網路與終端詳細的規範，包括用戶設備非存取層(Non Access

Stratum, NAS)行為、用戶設備呼叫、非存取層計時器設置、移動裝置接收簡訊等等。

14

本篇提案針對移動裝置接收簡訊議題，對標準 24.008 提出修正要求(Change

Request, CR)。提案內容

由於延伸非連續接收機制加長了非連續接收週期長度，用戶設備在閒置模式(Idle mode)的呼叫週期(Paging cycle)也被延長。在延長的呼叫週期內，可能會有簡訊需要用戶設備接收，然而因為用戶設備此時進入睡眠，網路無法呼叫該設備，過長的睡眠時間使得簡訊接收延遲時間隨之增長，並且，因為網路無法呼叫睡眠中的用戶設備，使得簡訊服務中心(Short

Message Service - Service Center, SMS-SC)遞送失敗，簡訊服務中心進一步啟動的失敗重傳也無效。為解決此問題，依據 TR 23.770 的原則性解法指示，當用戶設備啟用延伸非連續接收機制，網路會通知簡訊服務中心該用戶設備目前無法被呼叫，簡訊服務中心因此可以停止無效的簡訊遞送失敗重傳。當網路依據延伸非連續接收週期設定呼叫用戶設備，或是用戶設備自行離開睡眠發動資料傳送、追蹤區更新(Tracking Area Update, TAU)，此時用戶設備重新進入可以被網路呼叫的狀態，網路可以呼叫用戶設備並且遞送睡眠期間累積在網路端的簡訊。

除了長程演進技術之外，上述 TR 23.770 的解法原則同樣也能應用在通用分封無線服務(General Packet Radio Service, GPRS)。在通用分封無線服務中，當用戶設備進行路由區域更新(Routing Area Update, RAU)成功，網路端可以在路由區域更新接受訊息中設置 Follow-on proceed，通知用戶設備在路由區域更新之後 PS signalling將會被延長。本篇提案貢獻因此提出，當網路端收到路由區域更新請求，如果網路端發現該用戶設備已經啟用延伸非連續接收機制，並且在網路有累積該用戶設備的簡訊需要傳送，則網路端可以在路由區域更新成功訊息中設置 Follow-on proceed，藉此告知用戶設備在網路端有需要接收的簡訊，並且網路將會使用與路由區域更新同樣的 PS signalling 來遞送累積的簡訊。當收到 Follow-on proceed，該用戶設備即得知有簡訊需要接收，此時如果無線資源控制連線(Radio

Resource Control Connection, RRC Connection)被基地台釋放，用戶設備可15

以自行發動服務請求(Service Request, SR)，重新建立無線資源控制連線，接收來自網路的簡訊。

相關討論:

總共有 InterDigital、Qualcomm 和 Huawei 等三家公司在會議中對這篇文件提出意見討論，其主要陳述意見如下：

InterDigital質疑 Follow-on proceed 的使用方式，認為 Follow-on

proceed 的用意是要協助減少在路由區域更新後，如果用戶設備需要發起資料或簡訊傳送，但是用戶設備端與網路端對於 PS signalling 延長狀態的認知不一致而出現的額外信令浪費。InterDigital 認為把 Follow-on proceed 的功能放在通知用戶設備接收簡訊，並不符合原意。

Qualcomm 表示這篇提案所提出的 Follow-on proceed描述事實上並未增加任何新的行為，就行為來看，本提案之敘述不影響網路決定是否設置Follow-on proceed，用戶設備自身也可以發動服務請求。

Huawei同意 Qualcomm 的看法，認為這篇提案沒有新增網路或是用戶設備行為。Huawei 並且認為延伸非連續接收的移動裝置接收簡訊議題可以被 24.008文件的其他章節妥善處理，因此本篇並無需要。

經過一系列的討論之後，最後因為多數公司認為本文件在標準中新增之描述並無需要，大會決議不接受本篇提案。其他公司的重要提案和討論過程1. C1-154243: UE temporarily unreachable due to eDRX

提案公司: Qualcomm Incorporated

提案源由:

在 TS 29.118 中定義了 SGs介面在 SGsAP-UE-UNREACHABLE 訊息中返回給訪客位址註冊(Visitor Location Register, VLR)的原因值(cause

value)。然而規格書中現有的原因值並沒有一個值適合表達因為啟用延伸非連續接收機制，導致用戶設備暫時無法被呼叫的狀況。

16

延伸非連續接收機制導致的用戶設備無法被呼叫狀況，與另一種用戶設備永久無法被呼叫的狀況並不相同，因此最好將此兩種狀況區分開來，有助於網路處理簡訊傳送失敗等異常狀況。在階段 2 的文件 23.272 中也清楚描述了需要新的原因值來表達延伸非連續接收造成的用戶設備無法被呼叫狀況。

提案內容:

-在章節 5.1.3.1 中增加描述用戶設備因為啟用延伸非連續接收機制所導致的暫時無法被呼叫狀況

-在章節 9.4.18 新增原因值相關討論:

總共有 Huawei、Ericsson兩家公司對此篇文件提出討論，主要意見描述如下：

Ericsson 表示不了解此文件所新增之原因值“UE temporarily

unreachable”和現有的原因值“UE unreachable”，兩者的差異為何。Qualcomm回應差異在於前者是可以協助網路了解異常狀況的發生原因是延伸非連續接收，但是後者無法。Ericsson 接受 Qualcomm 的解釋。

Huawei 認為沒有必要新增原因值，認為現有的原因值“UE

unreachable”已經足夠網路處理異常狀況。Ericsson 表示核心網路及終端第四工作群已經達成共識，VLR將會依據網路現狀(例如：用戶設備啟用延伸非連續接收機制)，傳送新的計時器給簡訊服務中心。Qualcomm 表示如果沒有新的原因值，VLR 無法區分網路目前面對的狀況，VLR 無法產生適當的計時器值給簡訊服務中心。Qualcomm 表示新的原因值可以提供營運商分辨用戶設備無法呼叫原因的方法。Huawei 表示這份文件並未顯示出Ericsson 所提第四工作群該份共識文件的參考來源。主席要求 Qualcomm

補充該共識文件之來源。Huawei 表示除了以上問題之外，這份提案牽涉到VLR，顯然是電路交換(Circuit-Switching, CS)的提案，然而延伸非連續接收機制只適用在封包交換(Packet-Switching, PS)。

17

由於第四工作群文件參考來源未加入，以及各公司在 VLR 牽涉到的電路交換、封包交換上並未達到共識，最後大會決議這篇文件擱置(Postponed)。2. C1-154371: Discussion on the solution for enabling eDRX through TAU

Reject with T3346

提案公司: LG Electronics

提案源由在現行的規格書中，用戶設備可以透過在追蹤區域更新/路由區域更新

請求訊息中攜帶延伸非連續接收參數，向網路請求使用延伸非連續接收機制。網路端透過在對應的追蹤區域更新/路由區域更新接受訊息中攜帶延伸非連續接收參數，告知用戶設備成功啟用延伸非連續接收機制。當用戶設備請求使用延伸非連續接收機制的追蹤區域更新/路由區域更新請求訊息遭到網路使用原因值#22拒絕，並且拒絕訊息中攜帶後退定時器(back-off

timer)T3346，我們可以假定此時用戶設備不應該使用延伸非連續接收機制且必須進入閒置模式，因為該用戶設備的追蹤區域更新/路由區域更新請求並未成功。然而，即使網路原意是想要接受用戶設備的延伸非連續接收機制啟用請求，網路端卻因為壅塞而拒絕追蹤區域更新/路由區域更新請求，使得用戶設備無法啟用延伸非連續接收機制，並且在後退定時器 T3346 到期或停止之前，該用戶設備都不能重新請求使用延伸非連續接收機制。

在前一次會議，LG曾經提出一篇提案貢獻(C1-153601)，分析允許網路透過追蹤區域更新拒絕訊息(拒絕原因值#22)啟用用戶設備的延伸非連續接收機制，可以增進用戶設備的省電效能，並且不會造成無法呼叫用戶設備的狀況，如下圖所示。

18

提案內容:

LG 建議允許網路使用追蹤區域更新拒絕訊息(原因值#22)來啟用用戶設備的延伸非連續接收機制。LG首先分析適合使用此解法的情境，如下：

情境一：用戶設備曾經在追蹤區域更新請求中，攜帶延伸非連續接收參數。換言之，用戶設備曾經請求網路允許使用延伸非連續接收機制。

情境二：在用戶設備送出追蹤區域更新請求時，該用戶設備已經使用延伸非連續接收機制。換言之，用戶設備希望在下個追蹤區域更新週期內繼續使用延伸非連續接收機制。

LG 認為解法在情境一可以適用。因為延伸非連續接收機制是以協商為基礎的機制，在用戶設備與網路協商過機制參數之後，才能確認啟用。延伸非連續接收機制這樣設計的原因是，網路在用戶設備發出請求之前並不會知道該用戶設備支援的延伸非連續接收能力如何，如果網路沒有跟用戶設備協商就直接給定參數，有可能該用戶設備無法使用給予的參數，網路必須重新調整，這將造成不必要的非存取層信令浪費。允許網路使用追蹤區域更新拒絕訊息(原因值#22)來啟用用戶設備的延伸非連續接收機制符合以協商為基礎的作法，因此適用。情境二又可再細分為兩個狀況，如下圖所示：

19

狀況#1 表示用戶設備原先尚未使用延伸非連續接收機制。用戶設備發動追蹤區域更新請求，並且向網路請求使用延伸非連續接收機制，但是網路拒絕此追蹤區域更新請求，拒絕訊息中攜帶拒絕原因值#22 以及倒退計時器 T3346。狀況#2 表示用戶設備原先已經在使用延伸非連續接收機制。用戶設備發動追蹤區域更新請求，並且向網路請求繼續使用延伸非連續接收機制。換言之，狀況#1 是『初始請求使用延伸非連續接收機制』，狀況#2則是『請求繼續使用延伸非連續接收機制』。LG 認為狀況#1 與#2皆可以適用所提案的解法，因為不論是哪一個狀況，允許使用追蹤區域更新拒絕訊息來啟用延伸非連續接收機制並沒有明顯的錯誤或是異常。經由上述分析，LG 有以下提案：提案一：允許使用追蹤區域更新拒絕訊息來啟用延伸非連續接收機制只能用在，當用戶設備在該次追蹤區域更新請求訊息中攜帶要求使用延伸非連續接收機制之參數。提案二：允許使用追蹤區域更新拒絕訊息來啟用延伸非連續接收機制的使用，不受到用戶設備當下是否已經啟用延伸非連續接收機制之影響。

20

在實作解法方面，LG 提出兩個作法：作法一：在追蹤區域更新拒絕訊息中，攜帶延伸非連續接收機制參數作法二：在追蹤區域更新拒絕訊息中，攜帶指示使用用戶設備請求之延伸非連續接收機制參數在前一次會議中，延伸非連續接收機制參數已經被定義，因此可以在追蹤區域更新拒絕訊息中直接加入此定義，不需再另外設計新參數。作法一的優點是，網路可以將修改欲給用戶設備的參數，改成與用戶設備請求不同的值，因此作法一也可說是一種基於協商的解法。要實作作法一，將會在追蹤區域更新拒絕訊息增加 4 個 octect。作法二是只在追蹤區域更新拒絕訊息放入一個指示子，表示網路”接受用戶設備在追蹤區域更新請求訊息中攜帶之延伸非連續接收參數”。此法的優點是在追蹤區域更新拒絕訊息中，不必新增如作法一那麼多的 octect。然而此法的缺點是，網路無法使用其他不同於用戶設備請求值的參數。比較作法一與作法二，前者是基於協商的解法，並且可以提供網路更彈性的參數設置空間，因此 LG 建議使用作法一，作為實作允許使用追蹤區域更新拒絕訊息啟用延伸非連續接收機制的方法。相關討論總共有 HTC、Huawei、InterDigital 和 Ericsson 四家公司針對這篇提案提出意見，主要意見列舉如下：

HTC 表示拒絕原因#22 是少見的狀況，並且後退計時器 T3346 時間很短，在這段時間內允許用戶設備使用延伸非連續機制，可以獲得的省電效益不高。HTC另外指出，此份文件只考慮到核心網路端壅塞，並未考慮到基地台端壅塞的狀況。InterDigital 表示對這份文件的技術內容沒有意見，但是建議 LG 可以將省電模式(Power Saving Mode, PSM)也納入考量。Huawei指出此文件的解法可能發生安全性上的問題，當用戶設備進行追蹤區域更新時，如果該用戶設備進入了新的追蹤區域，則當時追蹤區域更新拒絕訊息並沒有加密保護，延伸非

21

連續接收參數可能遭到惡意竄改。Ericsson同意 Huawei 的意見，認為必須就安全性問題進行修正。經過一系列的討論之後，主席要求 LG 修正安全性問題，LG 表示將在下次會議再提出修正版本。3. C1-154267: Multiple ProSe Application Codes in <response -announce>

element of DISCOVERY_RESPONSE message

提案公司: Qualcomm Incorporated

提案源由在開放鄰近服務直接探索(open ProSe direct discovery)的宣告請求(annouce

request)步驟中，宣告者用戶設備(announcing UE)傳送一個探索請求訊息(DISCOVERY_REQUEST message)給鄰近服務功能單元(ProSe function)，此訊息攜帶一個探索請求單元(<discovery-request> element)，單元中包含了用戶設備上層要求使用的鄰近服務應用識別(ProSe Application ID)。鄰近服務功能單元回傳一個探索回應(DISCOVERY_RESPONSE)訊息給宣告者用戶設備，此訊息中包含宣告回應單元(<response-announce> element)，該單元攜帶了鄰近服務應用碼(ProSe Application Code)，用戶設備於是可以開始進行宣告(annoucing)。

依據規格書 24.334 規定，宣告回應單元只能攜帶一個鄰近服務應用碼。C1-154267 這份文件分析了在一個宣告回應單元中攜帶多個鄰近服務應用碼的優點，並且提出實作解法。提案內容:鄰近服務應用識別的結構如下圖所示：

並且，在規格書 23.003 中有如下規範：22

由上述內容可看出，規格書定義鄰近服務應用識別名稱(ProSe Application ID

Name)是一個階層式架構，其格式的使用方式彈性極高。因此，在某些狀況中，傳送單一鄰近服務應用識別可以同時包含數個鄰近服務應用識別，例如：數個鄰近服務應用識別"ProSeApp.Food.Restaurants.French"、 “ProSeApp.Food.Shop.French”以及 “ProSeApp.Food.Delivery.French”，可以使用單一個“ProSeApp.Food.*.French”來取代，如此一來用戶設備便不需要傳送三個探索請求，只要傳送一個探索請求即可達成其目的。如果要回應此類探索請求，鄰近服務功能單元必須要配置多個鄰近服務應用碼。然而在現行的規格書 24.334 中規定，一個宣告回應單元僅能攜帶一個鄰近服務應用碼：

Qualcomm 因此提案修改 24.334，使一個宣告回應單元可以攜帶多個鄰近服務應用碼。相關討論總共有 CATT、InterDigital 以及 Huawei 等三家公司針對這篇提案提出意見，主要意見列舉如下：CATT 提問如果一個宣告回應單元可以攜帶多個鄰近服務應用碼，宣告者用戶設備如何得知該使用哪一個應用碼？偵聽者用戶設備(monitoring UE)該使用哪一個過濾器(filter)？Qualcomm回應宣告者用戶設備可以使用包含在該宣告回應

23

單元中的任何應用碼。如果偵聽者用戶設備請求了所有應用服務，那麼該偵聽者用戶設備將擁有所有應用碼的過濾器。InterDigital 表示文件中修改後的6.2.2.1 敘述似乎與說明部分並不一致。Qualcomm 表示會進行修正。Huawei 表示即使鄰近服務功能單元可以在一個訊息中配置多個應用碼給用戶設備，當用戶設備進行宣告的時候，仍然必須使用多個 PC5介面探索訊息(PC5_DISCOVERY)。Qualcomm同意 Huawei 的意見，現行規範中用戶設備在宣告時一次只能使用一個應用碼。經過一系列的討論之後，主席要求 Qualcomm 修正文件內容不一致的部分，經過修改之後，新文件 C1-154680 獲得大會同意。重要的新工作項目1. C1-154412 New Work Item for the core network aspects of AE-CIoT

目標機器型態通訊的大量成長對於第三代合作夥伴計畫的經濟生態系統

(ecosystem)是個非常重要的機會。為了支援物聯網(Internet of Things, IoT)，第三代合作夥伴計畫的營運商列出許多重要的應用情境以及裝置需求，例如室內與地下室應用、更廣的覆蓋(coverage)、可支撐裝置長達數年的不更換電池的省電效率、可滿足巨量裝置佈建的低成本等等。在無線存取網路工作組(RAN work group)已經通過窄頻帶物聯網(Narrowband IoT)工作項目。在服務及系統面第二工作群已經在行動物聯網網路架構增強(AE_CIoT)工作項目達成部分共識，並且即將針對這些共識，討論對於規格書 23.401 與 23.682 的影響。

核心網路及終端工作群必須開始討論相關的規格撰寫工作，因此提案新的工作項目 AE_CIoT-CT。

討論過程主要有 Ericsson, Alcatel-Lucent 以及 Huawei 等三家公司提供相關意見

24

1 Ericsson 認為這個工作項目提案列了太多服務及系統面第二工作群的報告細節內容，核心網路及終端第一工作群的工作目標不夠清楚。

2 Alcatel-Lucent 表示原則上支持這個工作項目提案，但是認為目前要同意通過還太早，因為連服務及系統面第二工作群都才剛開始進行對規格書的影響討論。

3 Intel 表示行動物聯網網路架構增強是一個特例，目前各個工作群組都已經認同在第 13 版中需要完成部分內容，所以核心網路及終端第一工作群也必須要達成某些成就。

4 Huawei 表示這份提案文件在工作目標中提到，在 GPRS隧道協定新增原因值、支援 S8介面漫遊，以及非 IP類型資料傳輸等項目，可能需要由第四工作群主導，然而現在通過此提案的話，第四工作群組實際上並沒有機會檢閱這個工作項目的內容。Huawei 認為需要先通知並等待第四工作群組。

5 Intel 表示我們可以暫且先擱置或是刪除某些有爭議的項目，先檢視目前的階段，核心網路及終端第一工作群可以進行的工作是哪些。

6 Alcatel-Lucent 認為，既然已經確認第 13 版無論如何都要在行動物聯網網路架構增強上達成某些成就，那麼第一工作群應該要通過這個工作項目，關於服務及系統面第二工作群方面，可以要求：如果有達成任何新的共識或是結論，第二工作群要發送聯絡說明(Liaison Statement, LS)到核心網路及終端第一工作群，以便更新最新狀況。

在經由一連串相關討論之後，Intel 修正本篇提案，在新的提案文件中刪去原先有爭議的細節內容，最終核心網路及終端第一工作組同意新增此工作項目。未來如何針對此工作項目進行研究討論

關於行動物聯網網路架構增強的工作項目，目前定義在 3GPP TR 23.720當中。相關工作進行方式預計會是，針對每一個項目，由服務及系統面第二工作群先完成部分規範，再移動到該項目到核心網路及終端第一工作組，繼續制定階段 3 的協定詳細內容。下面表格描述在此工作項目的討論中核心網路及終端第一工作組預計修改的文件。

25

Affected existing specifications [None in the case of Study Items]

Spec No.CRSubject of the CR Approved at plenary# Comments

24.301 Impacts to handle "small data" transactions CT#71 March 2016 CT1 responsibility

24.008 Possible impact to common IEs CT#71 March 2016 CT1 responsibility

29.272 Support for NB-IOT RAT Type, non IP PDN Type in subscription CT#71 March 2016 CT4 responsibility

29.274 GTPv2 Protocol Support for the aspects of Cellular Internet of Things, e.g. conveying NB-IOT RAT Type

CT#71 March 2016 CT4 responsibility

23.008 Possible storage impact for the aspects of Cellular Internet of Things CT#71 March 2016 CT4 responsibility

23.007 Possible impacts for restoration procedures for the aspects of Cellular Internet of Thing


23.003 Possible impacts to support addition of new identifiers for the aspects of Cellular Internet of Thing.


29.128 Possible impacts to support Non-IP data between the MME and SCEF (T6a/T6b) CT#71 March 2016 CT4 responsibility

29.061 Possible impact for the delivery of non IP data from PGW to external AS CT#71 March 2016 CT3 responsibility

29.212 Possible PCC impacts for Cellular Internet of Things CT#71 March 2016 CT3 responsibility

31.102 Possible impact to update support for NB-IOT RAT CT#71 March 2016 CT6 responsibility

26

六. 心得及建議這次的 CT1 #95 會議通過了一個重要的新第 13 版工作項目，此工作項

目為行動物聯網網路架構增強-核心網路及終端(Architecture enhancements

for Cellular Internet of Things, AE_CIoT-CT)，其主要目的是針對服務及系統面第二工作群已達成的要求規範，進行相關階段 3 的協定詳細內容工作規格書撰寫。這個提案較為特殊，因為事實上服務及系統面第二工作群目前尚未達成足夠的規範共識，不少公司質疑此時通過此工作項目是否言之過早。但是由於第三代合作夥伴計畫各工作群組已經同意，在第 13 版中必須對行動物聯網完成一定程度的規格制訂，因此最終核心網路及終端第一工作組通過了此提案。此項目可說是第 13 版中較遲才確定的工作，可以預期接下來核心網路及終端第一工作組必定會密集的討論研究此工作項目，而行動物聯網是非常重要的機會，本團隊建議在從此次會期開始，應該針對此項工作項目去進行更深度的研究，並且積極參與討論，以期能在早期規格制訂上取得先機。

在此次會議我們可以看到，延伸非連續接收(eDRX-CT)是許多公司都極重視的工作項目，延伸非連續接收可以大幅提升裝置的省電效能，在機器型態通訊及物聯網方興未艾的現在，許多公司都高度關注此議題，包括Qualcomm、Ericsson、Huawei、LG、Alcatel-Lucent 等等。除了實現延伸非連續接收機制的階段 3 規格細節內容制訂之外，由延伸非連續接收主題所衍生出的相關議題，例如用戶設備呼叫、移動設備接收簡訊，以及如何在核心網路非存取層步驟上面作改進，以達到更好省電效能等等，都在會議上有相當多討論。至目前為止延伸非連續接收主題依舊有很大的研究空間，本團隊建議繼續深化研究此議題，密切關注其走向。

在延伸改進鄰近服務(Enhancements to Proximity-based Services -

Extensions, eProSe-Ext)主題上，限制型鄰近服務探索(Restricted ProSe

discovery)是階段 3 規格制定重點之一，限制型服務探索有許多需要新增的功能，因此將對原先只有開放型服務探索(Open discovery)的規格書進行大幅新增與修改。相較開放型服務探索，限制型服務探索提供更多用戶設備

27

應用，不論在商用或是公共安全皆有極大機會，本團隊建議密切關注限制型服務探索議題的討論，積極參與規格制訂，以期能獲得更大的研發能量。

七. 技術貢獻提案清單 3GPP CT1#95 Meeting (16th Nov. -20nd Nov. 2015), Anaheim, USA(1,1,0)

1. C1-154148 “Indicate follow-on proceed in routing area update accept for stored MT SMS

of eDRX MS”, Acer Incorporated <Treated>

28

出國報告電子檔規格std-share.itri.org.tw/content/files/report/files/bsmi... · web...

Documents