3GPP SA2 #96 meeting

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

3GPP SA2 #96 meeting

會議報告

出國人員：許俊彥、蔡宜學

廖青毓、Kundan Tiwari

葛達、鄭靜紋

派赴國家：美國/聖地牙哥

出國期間：102 年 4 月 06 日至

102 年 4 月 14 日

報告日期：102 年 5 月 30 日

1

摘要

本次 3GPP SA2 #96 會議於 4 月在美國聖地牙哥舉行，本研發團隊依規劃有 6 位成員出席，此

行主要任務說明如下：

本團隊在本次 SA2 會議關注的議題可概分為下列項目：

FS_ProSe；

GCSE_LTE；

UPCON；

MTCe；

New SI/WI (Study Item/Work Item)。

技術貢獻

這次會議，本團隊共有 2 篇 MTCe，10 篇 FS_ProSe，2 篇 UPCON 相關議題提案。

會議解說

3GPP SA2 #96 meeting 會期於 2013 年 4 月 08 日至 2013 年 4 月 12 日在美國聖地牙哥舉行，共

有 181 位來自 142 個會員公司的代表參加。本次參加會議主要任務為發表本團隊的標準提案，

參與 ProSe、GCSE_LTE、SaMOG、WLAN_NS、MTCe-SDDTE 議案討論，並關注新的 SI 和

WI，以掌握 3GPP 標準現況與技術發展趨勢。

2

與會成員與工作分配

成員任務

Kundan

Tiwari

掌握 LTE/LTE-A 系統架構的相關議題，提出技術提案、參與技術

討論及協商, 以 ProSe 為主。

廖青毓掌握 LTE/LTE-A 系統架構的相關議題，提出技術提案、參與技

術討論及協商, 以 ProSe、MTCe、GCSE_LTE、 Rel-11 為主。

許俊彥掌握 UPCON 和 MTCe 技術發展現況、提出技術提案、參與技術

討論及協商。

蔡宜學掌握 LTE/LTE-A 標準發展現況、提出技術提案、參與技術討論及

協商，以 ProSe、GCSE_LTE 為主。

鄭靜紋參與 ProSe、GCSE_LTE、WLAN interworking 相關發展與技術討

論，追蹤標準發展方向與相關議題。

葛達負責 ProSe, MTCe-SDDTE 和 WLAN_NS 的現況與相關技術發

展，參與技術討論與協商。

3

目錄

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

技術貢獻 ................................................. 1

會議解說 ................................................. 1

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

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

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

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

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

五、會議摘要：會議議程及會議紀要 ......................... 4

六、未來標準會議目標 .................................... 28

七、心得及建議 .......................................... 29

八、附件 ................................................ 29

4

一、會議名稱

3GPP SA2 #96 Meeting

參與代表 181 人

二、參加會議目的及效益

參與 Rel-12 包括 MTCe、FS_ProSe、GCSE_LTE、WLAN_NS 的討論

報告本團隊所發表之文章

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

追蹤 3GPP 會議相關工作項目的規格制定方向及進度

三、會議時間

April 08, 2013 ~ April 12, 2013

四、會議地點

San Diego, US

五、會議摘要：會議議程及會議紀要

（一）會議議程：

Monday Tuesday Wednesday Thursday Friday

08.00

08:50

♠ 07:30 UPCON

(7.6)

<reserved>

07:30 BusTi (8.4.1)

07:30 3GPP Access

Maint (5.1), (6.1)

♠ 07:30

WLAN_NS (7.7.x)

07:30 IMS_RegCon

(8.4.2)

<reserved>

09.00

10.30

09:00 ♠ Opening,

Reports,

Common IMS/

non-IMS, (1-4) ,

Pre-Rel-12

♠ GCSE_LTE (7.5)

architecture,

overview

FS_WORM (7.12)

♠ MTCe-SDDTE

(7.2.1)

FS_SaMOG (7.11)

♠ ProSe (7.4)

<reserved>

♠ Parallel Session

Reports, Revisions

5

Maintenance (5),

especialy LSs, WIDs

(9.1), Planning future

meetings (9.3)

11.00

12.30

♠ UPCON (7.6)

3GPP Access Maint

(5.1)

♠ GCSE_LTE (7.5)

architecture,

overview, P-CRs

<reserved>

♠ FS_CNO (7.10)

P4C-F (7.3.1)

♠ MTCe-SDDTE

(7.2.1)

Non-3GPP Maint

(5.3), (6.3), (7.1.3)

♠ Revisions

14.00

15.30

♠ MTCe-SDDTE

(7.2.1)

PCC/QoS Maint

(5.2), (6.2), (7.1.2)

♠ WLAN_NS

(7.7.x)

drafting FS_CNO

♠ ProSe (7.4)

WLAN_NS (7.7.x)

<reserved>

♠ Revisions

Parallel Revisions

♠ Revisions, Planning

future meetings (9.3),

AOB (11)

Close of meeting (12)

at 16:00

16.00

17:30

♠ ProSe (7.4)

IMS LSs,

Maintenance, etc

(8.1, 8.2, 8.3, 8.5),

IMS WIDs (8.6.1)

♠ ProSe (7.4)

ABC (7.8)

♠ ProSe (7.4)

IMS-Related

Maintenance (5.4),

(6.4), (7.1.4)

♠ Revisions

Parallel Revisions

18:00

19:30

♠ UPCON (7.6)

LIMONET

(7.9), (7.1.1)

♠ JM1 with CT1 on

topics (JM1.1-5)

FS_SaMOG (7.11)

♠ JM2 with SA1 on

GCSE_LTE (JM2)

P4C-TI (7.3.2)

♠ Revisions

until late

（二）會議紀要

2.1 研發團隊提案

本研發團隊參與 SA2 會議，任務除了觀察 SA2 目前的進度與議題討論，於此次會議提出 14

件提案，包括 2 件 MTCe，10 件 FS_ProSe，2 件 UPCON 工作項目，其會議結論詳敘如下。

6

提案編號來源提案主題提案成果

S2-131479 Intel, Broadcom

Corporation,

CATT, III, LG

Electronics,

Radisys, Sony

Key Issue on EPC-level ProSe

Discovery

Accepted

S2-131481 Intel, III, Sony,

Radisys, HTC

Three Key Issues: EPC-level ProSe

Discovery, EPC Support for WLAN

Direct Communications, Service

Continuity

Accepted

S2-131482 Intel, III,

Radisys, Sony,

Qualcomm

ProSe service continuity Accepted


Radisys, Sony

Solution for EPC-level ProSe

Discovery

Posted


Radisys, Sony

Solution for EPC Support for WLAN

Direct Communications

Posted


Radisys, Sony

Solution for Service Continuity Posted

S2-131400 Intel, III Update on Key Issue #2 to reflect

congestion abatement awareness

Accepted

S2-131103 Intel, III S1-U Congestion Mitigation Solution Posted

S2-131501 Huawei,

HiSilicon, Intel,

Nokia Siemens

Networks, HTC,

ZTE, LG

Electronics,

Verizon, KT

Corp, KPN,

China Mobile

Update of T5 Triggering Accepted

S2-131508 Huawei,

HiSilicon, Intel,

Nokia Siemens

Networks, ZTE,

HTC, CATT, LG

Electronics,

Updates for T5 Small Data Service Accepted

7

Verizon, KT

Corp, KPN,

China Mobile

S2-130896 HTC Proposal for general architecture

requirements of ProSe

Noted

S2-131391 Renesas Mobile

Europe Ltd.,

Qualcomm,

HTC

Key issue for ProSe System

Architecture

Accepted

S2-131394 ITRI,

Qualcomm

Incorporated,

HTC

Key issue for configuration for direct

discovery and communication

Accepted

S2-131422 HTC Key issue of Configuration and

Capability Handling for ProSe

Accepted

MTCe-SDDTE

MTCe-SDDTE, S2-131501:

此提案針對 T5 triggering 解決方案提出更新。此更新中主要將 triggering 與 delivery

service 分開，並移除相關 delivery 服務的相關敘述，而改為使用 T5 small data 服務來

傳遞 trigger。此外，增入評估 T4 與 T5 triggering 特性的比較。

更新要點如下：

- UE/Network 支援訊息交換：針對 T5 triggering 將不需要任何的 capability

information 的交換，因為 T5 triggering 主要是由 T5 small data 服務來提供，因此

僅需配合相關 T5 small data 所需的處理。

- 付費機制：由 MTC-IWF 產生 CDR 並考慮成功與失敗的傳遞。在漫遊服務中，由

VPLMN的 visited MTC-IWF產生CDR，此機制需要在 small data中加入識別 trigger

的指標。

- Subscription: 在 Rel-11 的 trigger service 中已有相關的 subscription，此 trigger

delivery via T5 small data 服務將需要的是有效的 T5 small data subscription。由

8

serving node 及 MTC-IWF 根據 UE 的 subscfription 來檢查使用 T5 small data 服務

的有效性。

- T5 trigger delivery: 使用 T5 Trigger delivery 服務已詳列於 TS 23.682 中，僅使用

T5 而無任何 T4 的交互機制可以使用 T5 small data 服務。

許多營運商表示支持此提案，包括：Verizon, Telecom Italia, China Mobile, China

Unicom, KPN，此提案在本次會議中通過。

MTCe-SDDTE, S2-131508: Updates for T5 Small Data Service

本提案針對 T5 傳遞 small data 提出方案更新以滿足不同的應用服務需求，包括安全

機制，傳遞效能，特定機制設定，以及資源使用。

本提案考慮兩種應用服務，第一種是需要在 UE 與 SCS server 間 end-to-end 安全傳遞

的 small data 服務, 第二種是需要較少的處理與設定僅需要網路針對特定 UE 增加必

要的 ID 以及保護 data unit 的安全機制。

更新要點如下：

- 新增 SCS 為傳遞 small data 的起點

- 每個 SDT PDU 可以指定 sender/receiver/application 的 sub-address(可以是 port

number 或是 name string)，並允許 encryption 和 integrity protection。

- 漫遊考量：在漫遊網路 VPLMN 中使用 visited MTC-IWF 的理由是可以檢查傳輸

數據的完整性並提供跨營運商的付費機制，因為 visited MTC-IWF 可以在傳遞到

終端用戶的 serving network node 前過濾並檢查終端訊息。而針對發送端訊息，

visited MTC-IWF 也可以檢查 UE 提供的 integrity 保護機制或是自己提供 integrity

保護機制。此外，針對發送端的 small data，VPLMN 的 serving node 可以設定相

對應的 visited MTC-IWF 來傳遞漫遊 UE 所傳送的 small data 以便於計費以及提供

訊息保護機制。此外針對在 VPLMN 的收送端 UE，其 serving node 在 HSS 註冊其

visited MTC-IWF 位址，因此 MTC-IWF 便可加入 small data 在傳送到 serving node

前的傳送路徑。

- 針對 charing 以及 lawful interception，都在 MTC-IWF 執行。

9

許多營運商表示支持此提案，包括：Verizon, Telecom Italia, China Mobile, China

Unicom, KPN，此提案在本次會議中通過。

FS_ProSe:

本團隊於 ProSe 工作項目的提案包括：

S2-131140 =>S2-131418 => S2-131481: Three Key Issues: EPC level ProSe Discovery,

EPC Support for WLAN Direct Communications, Service Continuity

提案公司：英特爾(Intel)、資策會(III)、Radisys、索尼(Sony)、宏達電(HTC)

提案分併：部分合併至 S2-131236 與 S2-131239

提案摘要：

- 提出了需要列入標準技術報告(TR)的核心網路支援鄰近探索、WLAN 直接通訊及

服務連續性等三個關鍵問題.

提案討論：

- 檢視於第 5.Y 節未被合併的關鍵問題。應該予以修正合併至其他文件中的引用章

節部分。有與會人員指出部分章節僅複製第 1 階段的需求。高通(Qualcomm)的代

表解釋雖然這不是一個好作法，但許多提案都直接複製引用。工作小組代表

(Rapporteur) 被要求於實作第 2 階段的文件時需進行修正。於接下來提案的修訂版

應考慮對弈的修正。大唐電信集團(CATT)要求修訂接下來的版本刪除『WLAN 直

接溝通之請求』。

提案結果：核准 (accepted)

S2-131239 =>S2-131417 =>S2-131479: Key Issue on EPC level ProSe Discovery

提案公司：英特爾(Intel)、博通公司(Broadcom Corporation)、大唐電信集團(CATT)、

資策會(III)、樂金電子(LG Electronics)、Radisys、索尼(Sony)

提案分併：合併 S2-130921, S2-130985, S2-131021, S2-131140 等提案之部分內容

提案摘要：合併提案

提案討論：

10

- 這個提案被討論且部分與會人員提出一些顧慮。並於非會議時間討論(off-line

discussion)並修正為 S2-131417 提案。進行複審時，華為(Huawei)建議通信路徑不

需一定是直接連接。英特爾(Intel)解釋說本提案僅適用於直接通訊的選項。高通

(Qualcomm )要求不要使用括號而是直接引用參考章節的參考文件。


S2-131236=>S2-131419 =>S2-131482: ProSe service continuity

提案公司：高通(Qualcomm)、英特爾(Intel)、資策會(III)、Radisys、索尼(Sony)

提案分併：分離自 S2-131140 提案之部分內容並合併 S2-131140, S2-130859

提案摘要：Proposes three key issues as in the title for inclusion in the TR.

提案討論：

- 此提案被討論和修訂以刪除註解並澄清已被討論的 S2-131419提案中的其他文字。

愛立信(Ericsson)要求修正部分內容和華為(Huawei)要求澄清『IPv4 設備』的文字。

『IPv4 設備』的文字在非會議時間討論(off-line discussion)並修正。


S2-131237=>S2-131394: Key issue for configuration for direct discovery and

communication

提案公司：工研院(ITRI)、高通(Qualcomm)、宏達電(HTC)

提案分併：分離自 S2-130980 提案之部分內容，並合併 S2-131108, S2-130854

提案摘要：proposes a new key issue for configuration for ProSe direct discovery and

communication in TR 23.703.

提案討論：

- ProSe direct discovery 是一種特定的 ProSe discovery 型態；

- 此提案被討論和修訂以用於 configuration for ProSe direct discovery。


ProSe, S2-131391: Key Issue of ProSe system architecture

11

此 PCR 提案建議設立 ProSe 系統架構（System Architecture）為關鍵議題, 在 ProSe 系

統架構中，應該支援相關的ProSe及Public safety功能，包括：discovery, communication,

以及 service continuity, authorization, security, charging。

以下為此關鍵議題必須解決的問題：

- 新增的網路元件及其支援的功能

- 可能需要新增的使用者註冊資料及數據儲存

- 決定 User/control plane 在介於 RAN 及 EPC 間的 Reference point 或 interface

- 從架構的觀點以及可能受影響的 AS/NAS 層評估對 UE 及現有網路元件的影響

- 對現有系統效能的影響

- 評估 ProSe 系統架構如何支援 WLAN direct communication

- 評估 ProSe 系統架構如何支援 public safety

- 在系統架構中區分影響的層級是在 RAN 或 CN 元件（必須與 RAN 及 CT 工作群

一起合作）

- 針對 SA2 的權責訂定 ProSe 運作的 stage 2 程序

此提案在本次會議中通過。

ProSe, S2-131422: Key issue of Configuration and Capability Handling for ProSe

根據 stage1 規格書 TS 22.278 中支援 ProSe 的基本需求，本提案提出設立關鍵議題來

解決以下問題：

- 支援 ProSe discovery, E-UTRA ProSe communication, ProSe-assisted WLAN direct

communication, 及 public safety 在 UE 及網路端所需新增的功能

- UE 與網路如何交換支援 ProSe 能力的訊息

- 如何設定（configure）ProSe UE 的 ProSe capability feature

- 決定有哪些設定資訊（configuration information）是必要設定在支援 ProSe UE

- 決定網路授權機制以讓 ProSe UE 來使用 ProSe 相關的功能

原始提案 S2-130980 經由討論依照關鍵議題分為三篇提案，包括：S2-131422,

S2-131394 以及 S2-131418。

12

此提案在本次會議中通過。

ProSe, S2-130896:

此提案根據 stage1 的需求列表挑出對系統架構具有影響的四個基本架構需求，經修

改為 stage2 的需求列表後依然被與會公司反對引用 stage1 需求，但是相關需求項目

包括漫遊及 share network 的支援部分已列入基本架構章節(於 S2-131355)。

此提案在本次會議中報告後被否決。

2.2 其他與會公司提出且通過的相關提案

ProSe

S2-131479 : Architecture Considerations for ProSe Discovery

提案公司：博通公司(Broadcom Corporation)

提案摘要：這個提案提出通用的鄰近探索(ProSe Discovery)之可行的系統架構。

提案討論：合併提案

提案結果：註記 (Noted)

S2-130985: Key issue of ProSe Discovery by network

提案公司：大唐電信集團(CATT)

提案分併：合併至 S2-131239

提案摘要：這個提案提出核心網路支援鄰近探索(ProSe Discovery)之關鍵問題。



S2-131021：Key Issue on the ProSe Discovery

提案公司：樂金電子(LG Electronics)

提案分併：合併至 S2-131239

提案摘要：這個提案提出支援鄰近探索(ProSe Discovery)之關鍵問題。


13


S2-130770：LS from SA WG3LI: LS on Proximity Services and Lawful Interception

提案單位：SA WG3-LI

提案摘要：

- SA WG3-LI 大會於本週討論鄰近服務(Proximity Services, ProSe)，大會同意向提供

相關訊息並協助 SA2 於截止日期(freeze date)前完成第 12 版(Release 12)的規範工

作(normative work)。許多於階段 1 之 TS 33.106 標準文件提及的合法(Lawful

Interception, LI)監聽的需求可以適用於鄰近服務，但 SA WG3-LI 能然需要藉由澄

清一些鄰近服務的能力(如探索、鄰近服務中繼器(Relay)，鄰近服務群組與廣播等)

來強化 TS33.106 標準文件，而且這項工作項目才剛剛開始。在一般情況下，網路

中的所有電信服務應該是能夠滿足合法監聽(LI)的規範。並且也可以進一步藉由國

家法規限制被監聽者可能使用的通信服務。目前，合法監聽(LI)的功能位於核心網

路(core network)中。為了完成合法監聽(LI)的功能，由 3GPP 運營商提供的網路服

務必須識別和隔離被監聽者之裝置或用戶的通訊信號。系統於監聽時若改變無線

接入技術或域名需確保服務連續性，並進一步提供相關被監聽者的監聽通信內容。

其必須做到不可被用戶偵測到。終端(UE)間的直接通訊能力將使其無法被核心網

路(core network)之合法監聽(LI)功能所監控。解決這個問題的可能選項為切換被監

聽者終端(UE)間的直接通訊至網路通訊，或關閉被監聽者的終端(UE)間的直接通

訊功能。然而，解決方案仍然需考慮偵測的問題。SA WG3-LI 有興趣討論任何 SA

WG2 提供的可能選項。由於合法監聽(LI)功能要求位置報告，SA WG3-LI 對於鄰

近服務用於提供監聽位置感到興趣。在一些國家中，只有網路信任的位置資訊才

可能會回報給執法部門。其他國家則要求將所有可用的位置資訊及其信任度一起

回報給執法部門。目前 SA WG3-LI 工作小組還不清楚什麼樣的特定頻譜將被用於

商業鄰近服務(如供應商授權頻譜、免執照頻譜及其他授權頻譜)。中繼器的功能是

否將預期提供商業用戶使用？就現有鄰近服務的應用情境(Use cases)下，SA

14

WG3-LI工作小組目前還不清楚網路需要何種訓令(signalling)亦或鄰近服務僅存在

終端(UE)間的直接通訊。SA WG3-LI 工作小組需要額外的信息來確定對於合法監

聽(LI)功能的影響。此外，加密通信亦是合法監聽的一個待解問題。

提案討論：

- 這個 LS 提案在 SA1 與 SA2 的聯合會議決議。最終回復在 S2-131522。


S2-130864 =>S2-131522：Reply LS on Proximity Services and Lawful Interception

提案公司：高通 (Qualcomm)

提案摘要：提供 SA WG3-LI 之 LS 關於鄰近服務和合法監聽的答案。

提案討論：

- 這是提案在 SA1 與 SA2 的聯合會議被簡要地討論。由於高通(Qualcomm)提案關於

解決合法監聽(Lawful Interception)的關鍵問題(Key Issue)於合併時被刪除，意大利

電信(Telecom Italia)建議 SA2 需要進一步討論合法監聽的關鍵問題。

提案結果：核准 (Accepted)

UPCON

UPCON 此次討論的主題為 Terminology, Architecture, Principles、New Key Issues、New Solutions

– Congestion Awareness、New Solutions – Congestion Mitigation 等四個主題，分述如下：

Terminology, Architecture, Principles 部分，處理的提案有 S2-130813、S2-131539 與

S2-130949 等三篇。

S2-130813: UPCON terminology

此提案建議定義 Open-loop UPCON solution 與 Closed-loop UPCON solution 以便更清

楚的表示。

Open-loop UPCON solution: A UPCON solution where the CN supplies QoS information

to the RAN based on which the RAN performs the QoS differentiation. CN does not

require congestion feedback from RAN.

15

Closed-loop UPCON solution: A UPCON solution where the RAN supplies congestion

feedback based on which the CN attempts to reduce the amount of traffic going to the

RAN.

討論結果：雖然並沒有反對的意見，但是也沒有積極支持的聲音，可見定義這兩個名

詞對標準內容而言屬於無關要緊的事項，故此提案為 Noted。

S2-131539: Proposed Architectural Requirements for CN-based Solutions for RAN User

Plane Congestion

此提案列出已經普遍受到認同的 architectural requirements，其最早的版本是

S2-130871，經過幾輪的討論修改之後，此提案 Accepted。

S2-130949: Solution analysis and architectural requirements for RAN user plane

congestion

此提案建議將 UPCON 的技術分成 RAN user plane congestion awareness 與 RAN user

plane congestion mitigation 兩類：

For RAN user plane congestion awareness: Congestion information shall be provided to

the network without being affected by the congestion situation of the user plane where the

target traffic is being transported. The volume and frequency of congestion notifications

from the RAN should be able to be controlled by the receiving functional entity in the

mobile core network.

For RAN user plane congestion mitigation: When a specific UE needs to take an action for

congestion mitigation, a mitigation policy that can take congestion information into

account shall be provided to the UE in advance. When a specific UE needs to take an

action for congestion mitigation, a trigger to activate a mitigation policy installed in the

UE shall be provided to the UE at an appropriate timing.

討論結果：此提案的內容並非參與廠商普遍的共識，因此許多廠商對於為何要將

UPCON 技術分成這兩類以及其分別的內容定義有諸多疑惑，因此此提案 Noted。

16

New Key Issues 部分，處理的提案有 S2-131491、S2-131358、S2-130814、S2-131359、

S2-130950、S2-131090、S2-131399、S2-131400 與 S2-130815 等九篇，分述如下：

S2-131491: New key issue on differentiated treatment for non deducible service data

flows in case of RAN user plane congestion

此提案對UPCON提出一項新的 key issue，亦即當RAN user plane發生 congestion時，

如何處理無法限制流量的應用，這一類的應用最常見的就是 very short-lived parallel

UDP and/or TCP data flows，因為其連線存在時間很短，通常在系統能夠對其做出限

制流量的措施之前就已經結束，然而這一類的應用又普遍存在現今的網路之中，因此

需要特別探討如何在系統發生 congestion 時限制這種無法限制流量的應用。

討論結果：此提案 Accepted。

S2-131358: Key issue on video delivery during congestion periods

此提案欲增加一個 Key Issue 使得電信運營商能夠根據各別用戶的優先權來決定影像

的傳輸模式與編碼，其目的是希望盡量讓頂級客戶能夠擁有最好的影像品質，而一般

客戶能夠維持可接受的影像品質，一旦當 RAN user plane 發生壅塞時，則適當降低頂

級客戶的影像品質，盡量讓所有客戶都能夠擁有可接受的影像品質。

未來在此Key Issue之下的 Solution 將考慮不同的影像技術(例如可變動或者不可變動

速率)與不同的傳輸技術(TCP 與 UDP)的影響。

討論結果：此提案 Accepted。

S2-130814: Existing closed loop congestion control mechanisms and their relation to

UPCON

此提案在 off-line 討論時被併入 S2-131358 中因而為 Noted。

S2-131359: RAN user plane congestion awareness in UE

此提案討論讓 UE 也能夠 Aware 到 RAN user plane 發生壅塞了，UE 因此可以自行決

定是否要 offload 到不同的網路去，例如 WLAN。

17

討論結果：大部分的廠商不認同讓 UE 有能力知曉網路發生壅塞，經過 off-lline 討論

之後此提案 Withdrawn。

S2-130950: Key issue on Push Service during RAN User Plane Congestion

此提案分析了當 RAN user plane 發生壅塞時，Push services 對行動網路的影響。此提

案並提出新增一個 Key Issue 來解決這個問題。

討論結果：此提案為 Noted，但是主席鼓勵原作者將 solution 設計好之後再次提案。

S2-131090: Key Issue－Performance Differentiation

此提案修改 TR 23.705 的 Key Issue－Performance Differentiation 部分的內容，不過大

部分的廠商均認為並沒有修改的必要性。

討論結果：因為此提案未獲支持，因此為 Noted。

S2-131399: Key Issue－Uplink Traffic Prioritization

此提案在 UPCON 中增加上行鍊路交通的優先權分類，可以 per-flow 與 per-user 的方

式來分類。

討論結果：雖然此提案仍有疑義待澄清，然而經過小幅修改之後此提案 Accepted。

S2-131400: Update on Key Issue #2 to reflect congestion abatement awareness

此提案建議增加一個 congestion abatement awareness 的 Key issue，當 RAN user plane

congestion 解除時，需要讓核心網路知曉此一狀況。

討論結果：經過小部分修改之後，此提案 Accepted。

S2-130815: Challenges for closed loop UPCON solutions

此提案列舉了 closed-loop UPCOP 需要解決的問題，但是其欲修改 TR 23.705 的方式

受到質疑，絕大多數的廠商認為此提案的內容並不適合放入 TR 23.705。

討論結果：此提案的部分內容可與 S2-131539 合併，故此提案為 Noted。

New Solutions – Congestion Awareness 部分，處理的提案有 S2-131492、S2-130913、

S2-131167、S2-131034 與 S2-130998 等五篇，分述如下：

S2-131492: RAN User Plane congestion awareness by GTP-U extension

此提案建議使用 GTP-U 擴充標頭來將 RAN user plane 壅塞的資訊傳送到核心網路，

18

核心網路可以據以實施流量管制，因此，TR 23.705 中的 5.2 Key Issue #2 與 5.1 Key

Issue #1 就可以一併被解決。

討論結果：此提案經過討論與修改之後，此提案 Accepted。

S2-130913: Optimizing congestion notification

此提案建議使用 GTP-U 標頭來攜帶 RAN user plane 壅塞的資訊，以便讓核心網路了

解 RAN user plane 壅塞。

討論結果：此提案內容與 S2-131492 相似，因此併入 S2-131492，此提案為 Noted。

S2-131167: Proposal for a user-plane congestion indication mechanism

此提案建議將 RAN user plane 壅塞的資訊以 piggy back 的方式通知核心網路，以便讓

核心網路了解 RAN user plane 壅塞。

討論結果：此提案內容與 S2-131492 相似，因此併入 S2-131492，此提案為 Noted。

S2-131034: Solution for RAN User Plane Congestion awareness and mitigation

S2-130998: Alternate Solution for congestion awareness by centralized equipment

以上兩篇提案內容相近，均為在現有的網路架構中新增 network entity or network

function entity 來處理使用者資料流優先權的事務，因此整合成 S2-131260，以上兩篇

提案 Noted。但 S2-131260 因時間因素此會期未被討論。

New Solutions – Congestion Mitigation 部分，處理的提案有 S2-131493、S2-131494、

S2-131205 與 S2-130895 等四篇，分述如下：

S2-131493: High-level Solution proposal for UPCON based on RAN and CN based

Congestion Mitigation

此提案內容為如下圖所示的 RAN 與核心網路的減緩壅塞的基本方法架構，經過討論

與修改之後，此提案 Accepted。

19

圖 1. User-plane Congestion Management – High-level View (Source: S2-131493, Figure X)

S2-131494: Prioritization of IP flows mapped to the same QCI

此提案提出了 Differentiation of IP flows mapped to the same QCI 的 UPCON 解決方案

架構，如下圖所示。經過討論與修改之後，此提案 Accepted。

圖 2. RAN congestion mitigation based on the FPI (Source: S2-131494, Figure 6.X.2-1)

IP services

RAN UE

CN - based congestion mitigation

Internet

Core

Network

(user and control plane)

Congestion Pred./Detection

1 Congestion indication

2

RAN - based congestion mitigation

4 Service/QoS information for RAN - based

congestion mitigation

5 a 5 b

Decision on mitigation measures based on

congestion information

3

20

S2-131205: Classification of IP flows mapped to the same QCI

S2-130895: Leverage SCI for RAN congestion mitigation

以上兩篇提案內容相近，均為基於 Service Class Indicator 來將使用者的資料流分優先

權，因此整合成 S2-131392，以上兩篇提案 Noted。但 S2-131392 因時間因素此會期

未被討論。

GCSE_LTE

S2-131054: GCSE_LTE TR 23.768 Skeleton

TR 23.768 的架構，Study on architecture enhancement to support Group Communication

System Enablers for LTE (GCSE_LTE)。

S2-131484: Scope for GCSE TR 23.768

以 TS 22.468 作為 stage 1 requirements 依據；

討論項目包括:

- 以 E-UTRAN 提供 group members 之間的 group communication；

- 以 ProSe UE-to-Network Relay 方式，在以 E-UTRAN 進行 group communication 的

group members 和使用 ProSe communication path 的 group members 之間進行 group

communication；

- GCSE 和 ProSe 間的 group communication 關係。

S2-131536: GCSE/Multipoint Service Architecture consideration for the TR

圖 3 是 NSN 提出的 GCSE 參考架構，其中 GCSE Application Server 屬於 application

layer，而 MuSe (Multipoint Service) function 則屬於 3GPP EPS layer。由 MuSe function

與其他 3GPP EPS entities 的 interaction 以提供 multipoint service 的能力。

Key issue 包括須決定應該由 3GPP EPS layer 或由 application layer 決定以

point-to-point 或以 point-to-multipoint distribution 方式傳送 group 訊息。

21

UE eNBMBMS

GWBM-SC

GCSE

Application

server

MME P-GW

Uu GC3

S1-MME

SG-imb

SGi

SG-mb

GC2

S-GW

GC4 S11 S5

S1-U

GCSE

Application

UE

GCSE

Application

ProSe Communication

UEGC1GCSE

Application

MuSe

GC5Media

圖 3. Overall of high level architecture view for GCSE_LTE (Source: S2-131536, figure 4.1-1)

S2-131509: Architecture & functional requirements for GCSE_LTE

Qualcomm 提出以 eMBMS 為基礎的 GCSE 參考架構與功能需求。

此提案以 eMBMS 作為 GCSE_LTE downlink (DL) multipoint service 的方案，並以

unicast 作為 uplink (UL)的方案。

參考架構如圖 4，UE 配置 GCSE Application client，GCSE Application server 經由 EPC

與 UE 聯繫。

此方案以 PCRF作為GCSE application server 與BM-SC之間交換 eMBMS控制訊息的

介面。可行性待進一步討論。

程序如圖 5 所示。E-UTRAN 決定使用 point-to-point 或 point-to-multipoint

transmission。

22

UE eNBMBMS

GWBM-SC

GCSE

Application

server

MCE MME P-GW

Uu M1

M2

M3

SG-imb

SGi

SG-mb

PCRFRx

Gxn

S-GW

Sm S11 S5

S1-U

GCSE

Application

UE

GCSE

Application

ProSe Communication

圖 4. Architecture for 3GPP GCSE service (Source S2-131509, Figure 6.x.1)

23

UE E- UTRAN BM-SC PCRF

2. Request TMGI

GCSE AS

3. TMGI Reserved

8. Establish eMBMS bearers7. Establish eMBMS

Bearer

1. Request TMGI

4. TMGI Reserved

9. Establish eMBMS Bearer

6. Request bearer

10. BearerResponse

12. Return TMGI for GCSE group(s) to UE

11. Register with GCSE Application Server

13. Group Communication Setup

UE wants to initiate group

setup

5.Maintain TMGI to GCSE group identifier mapping

14.Group Communication Traffic

Group Communication

Server decides to use eMBMS

bearers for DL

圖 5 The interaction between UE and GCSE Application Server (Source S2-131509)

MTCe-SDDTE

S2-131498: Push Proxy/Device Agent Function for reducing heartbeat/keep-alive of

applications

Huawei、CATR、Ericsson 共同提出。Push Proxy/Device Agent 收集 PDN connection

status，以減少 application layer heartbeat/keep-alive signalling 的方法。

24

參考架構如圖 6。EPS 於 UE 與 Application Sever 之間的 User Plan path 上設置 Push

Proxy/Device Agent，使 application data traffic 經過 Push Prosy，並繞過 NAT/firewall，

免除 keep-alive signalling。 PGW 由 SGi 界面使 Push Proxy 獲得 PDN connection 的資

訊，包括 external ID 和 internal IP address 的 mapping，Push Proxy 更新 DNS。若有

MTC AAA，則執行在 proxy mode。

執行範例如圖 7 所示。

Push Proxy/ Device Agent

UE RAN and CN P-GW/GGSN NAT/firewall App App

Application Server (AS)

User Plane User Plane

(S)Gi Radius

/Diameter

DNS

MTC

AAA

圖 6. Using a push proxy/device agent function to bypass NAT/firewall (Source S2-131498, Figure 5.1.2.3.x.1-1)

UEGGSN

/P-GWDevice Agent/

Proxy

1. Activate PDN connection 2. Device Agent allocates

internal IP address to the

UE

7. TCP connect7. TCP connect

AS

6. TCP connect

DNS

4. Add records to DNS

5. DNS lookup

3. Registration

圖 7. Application level solution for reducing keep-alive messages using DNS (Source S2-131498, Figure

5.1.2.3.x.1-2)

S2-131500: Core Network assisted eNB parameters tuning for small data transfer

Alcatel-Lucent，NEC，Samsung 共同提出。以 MME 的資訊調整 eNB 上的 timers 設

定。

圖 8 是 MME 在 RRC signaling connection setup 時，將 CN/RAN info 傳送至 eNB 的

25

範例。

MME

4. MME stores date/time of S1 connection release and RAN assistance data

UE

On-going signalling connection

eNodeB

Expiry of RRC user inactivity timer in eNB 1. S1-AP UE Context Release Request (user inactivity cause)

2. S1-AP UE Context Release Command

3. S1-AP UE Context Release Complete(RAN assistance data for next signalling connection)

New small data availablefor transmission 5. NAS Service Request

6. MME sets CN assistance data based on subscription data and/or dynamic monitoring of

UE activity, e.g. MME detects frequent transitions between idle and connected states.

8. S1-AP Initial Context Setup Complete

7. S1-AP Initial Context Setup Request(CN assistance data and/or RAN assistance data)Radio Bearer Establishment

eNB adjusts the RRC user Inactivity timer and/or DRX parameters

to reduce Idle <> connected transition frequency and optimize battery usage

圖 8. Core Network assisted eNB parameters tuning for small data transfer (Source: S2-131500, Figure 5.1.2.3.x.1-1)

S2-131292: "Device Trigger Report" handling for Recall and Replace

Acission 提出。當 MTC-IWF 收到要求 recall/replace 本來的 message 時，若該 message

尚未被送出，則 recall/replace 該 message，並在 Device Trigger Report 的 Result 註記

recall/replace。

S2-131014: Recall/Replace for T5 device triggering

LGE 與 Intel 共同提案。在 MTC-IWF 有 store and forward 能力的前提之下，提出 T5

device triggering message 的 recall 與 replace 方案。

圖 9 與圖 10 分別為 Device Trigger Replace 與 Device Trigger Recall 的程序。

26

UE HSS/HLR SGSN

MME

MTC-IWF

2a. Delete the stored trigger message and Store the new

trigger message

1. Check if the trigger message has been sent to the UE or is pending

at MTC-IWF

A)

3b. Deliver new trigger message

B)

4a. Deliver new trigger message

3a. Replace request=Success

2b. Replace request=Fail

圖 9. T5 Device Trigger Replace procedure (Source: S2-131014, Figure 5.2.3.3.1.1.3-1)

UE HSS/HLR SGSN

MME

MTC-IWF

2a. Delete the stored trigger message

1. Check if the trigger message has been sent to the UE or is pending

at MTC-IWF

A)

B)

3a. Recall request=Success

2b. Recall request=Fail

圖 10. T5 Device Trigger Recall procedure (Source: S2-131014, Figure 5.2.3.3.1.1.3-2)

S1-131434: connectionless data solution enhancements and addition of sub-option

Alcatel-Lucent, NTT DOCOMO, Silver Spring Networks 共同提出。UE 與 eNB 儲存

27

security context，並以 Token 輔助，取代每次傳送 small data 時的完整 security mode

procedure，可降低 eNB 與 MME 的 interaction。

提出 token based security context set up，如圖 12。

UEs eNodeB MME S-GW P-GW

4. Initial UE Message

(Service Request)

5. Initial Context Setup Request

(S-GW addr., S1-TEID(s) (UL),

Security Contex)

1. RRCConnectionRequest

8. RRCConnectionReconfig

(DRB(s) config.)

DRB

Small Data Packet+DL TEID

9. RRC Connection Reconfig

Complete

6. SecurityModeCommand

(SecurityAlgorithmConfig) +TOKEN

7. SecurityModeComplete

2. RRCConnectionSetup

(SRB1 config.)

3. RRCConnectionSetupComplete

(ServiceRequest*)

Small Data Packet+connection IDSmall Data Packet

S1 Tunnel

Small Data Packet Small Data PacketSmall Data Packet

ModifyBearerReq/Rsp

10. Initial Context Setup Response

圖 11. Updated Service Request Procedure with Token exchange and security context caching (Source: S2-131434,

Figure 5.1.1.3.6.3.1-1)

28

UEs eNodeB MME S-GW P-GW

1. RRCConnectionRequest

4. RRCConnectionReconfig

(DRB(s) config.)

DRB

S1 Tunnel

Small Data Packet+DL TEID

5. RRC Connection Reconfig

Complete

2. RRCConnectionSetup

(SRB1 config.)

3. RRCConnectionSetupComplete (Connection

ID’s+ TOKEN + signature)

Small Data Packet+connection IDSmall Data Packet

Small Data Packet Small Data Packet

Small Data Packet

圖 12. Service Request Procedure with Token passing (Source: S2-131434, Figure 5.1.1.3.6.3.1-2)

六、未來標準會議目標

1. 關注 FS_ProSe 相關議題，包括 E-UTRA based ProSe 和 WLAN based direct

communication。

2. 關注 GCSE_LTE 的發展，包括系統需求以及支援 group communication 可能需要的核心

網路(CN)和無線存取網路(RAN)設計。

3. 關注與 WLAN 的 interworking 相關議題，包括 WLAN_NS，以及保持訊務連續性的

FS_WORM。

4. 本團隊將依據 Release 12 工作項目優先順序調整提案方向。

29

七、心得及建議

ProSe 和 GSCE_LTE 皆被列為高優先權的議題，本次會議 ProSe 列出數項 key issues，可供

有心投入 ProSe 發展者之參考。GCSE_LTE 的初步工作重點將是凝聚與會公司共識以決定

point-to-point 與 point-to-multipoing 通訊的基礎架構。

八、附件

1. Overall SA2 agenda：

Topic Specs Rapporteur

1 Opening of the meeting 09:00 on Monday

2 Approval of the agenda

2.1 Handling of Postponed Work

2.2 IPR Call Reminder

2A Elections

The Chairman and one Vice Chairman Position elections are to be decided at

SA2 96.

3 Meeting reports

4 General issues and Incoming LSs

5 Pre-Release 12 Essential Corrections (NO TEI CRs)

Member companies are asked to focus their input for Rel-8 and Rel-9 solely

on essential technical corrections of specifications where doing nothing

would lead to frequent and serious misoperation (FASMO).

(Please do not submit documents directly to this agenda item.)

5.1 SAE: 23.401, 23.060; CSFB & SMSoSGs - 23.272;, HENB, LIPA_SIPTO,

NIMTC, VPLMN Autonomous CSG Roaming (VCSG), System

Improvements for Machine-Type Communications including Dual Priority

(SIMTC), SA2 Part of GERAN Network Sharing

(FULL_MOCN-GERAN); SA2 Part of GERAN Gateway Core Network

Sharing for GERAN (GWCN_GERAN)

5.2 SAE: QoS and PCC aspects; PEST, eVocoder, policy related aspects of

other WIs, etc. Rel-11 PCC/QoS: Service Awareness and Privacy Policies

(SAPP), QoS Control Based on Subscriber Spending Limits (QoS_SSL),

30

Service Identification for RRC Improvements in GERAN (Stage 2/3)

(SIRIG)

5.3 SAE: 23.402 (including eANDSF, MUPSAP, MAPCON, FlowMob,

SMOG), Data identification in ANDSF (DIDA), LOcation-Based Selection

of gaTEways foR WLAN (LOBSTER), S2a Mobility based On GTP and

WLAN access to EPC (SaMOG_WLAN) BBF Interworking Building Block

(BBAI) I, II

5.4 Other + IMS Related: 23.216, 23.237, 23.167, 23.228 (e.g Emergency,

eMBMS, eMPS, SRVCC etc.), Single Radio Voice Call Continuity from

UTRAN/GERAN to E-UTRAN/HSPA (rSRVCC), Support of IMS

Emergency Sessions with Other Media on UTRAN and e-UTRAN

(NOVES-IMSESOM), Network Provided Location Information for IMS

(NetLoc), Roaming Architecture for Voice over IMS with Local Breakout

(RAVEL), Single Radio Video Call Continuity for 3G-CS (vSRVCC),

Single Radio Voice Call Continuity (SRVCC) aspect of enhancements for

Multimedia Priority Service (eMPS_SRVCC)

6TEI Maintenance

TEI9, TEI10 or TEI11 Category F CRs only are expected, minimum 3 cosigning

companies. For the following:

(1) Stage 2 and Stage 3 are incomplete or wrong: Correction.

(2) Stage 3 is complete & correct, stage 2 is inconsistent: Alignment.

Note clarification, technical improvements, minor clean up and internal stage 2

alignment are not on the agenda. Renaming of IEs, modification of definition

sections and terminology clean up - even if arguably alignment as per (2) - will be

considered after other CRs (if at all.)

Please remember to submit the original work item abbreviation of the feature

maintained as part of the work item code as agreed: e.g. to maintain MUPSAP

(rel-10 feature) only in rel-11, use “TEI11, MUPSAP”.


6.1 3GPP Packet Access, TEI9, TEI10 or TEI11 Cat F *

6.2 PCC/QoS Aspects and SIRIG, TEI9, TEI10, TEI11 Cat F *

6.3 Non-3GPP Packet Access Maintenance, TEI11 Cat F *

6.4 IMS-Related Maintenance, TEI9, TEI10, TEI11 Cat F *

7 Release 12 (Please do not submit documents directly to this agenda item.)

7.1 Release 12 Maintenance (for WIDs that complete before the conclusion of

Release 12) (Please do not submit documents directly to this agenda item.) –

Category F CRs only.

7.1.1 3GPP Packet Access: LIPA Mobility and SIPTO at the Local Network 23.060,

23.401 Fenqin Zhu

(Huawei)

31

(LIMONET)

7.1.2 PCC/QoS Aspects: Usage Monitoring Control enhancement – SA2 Part

(UMONC)

7.1.3 Non-3GPP Packet Access Maintenance: Operator Policies for IP Interface

Selection (OPIIS)

7.1.4 IMS-Related Maintenance, (SMSMI)

7.2 Machine Type Communications Enhancements for Rel-12 (MTCe)


23.887 Puneet Jain (Intel)

7.2.1 (BB1): Small Data and Device Triggering Enhancements (MTCe-SDDTE) 23.887 Puneet Jain (Intel)

7.2.2 (BB3): UE Power Consumption Optimizations (MTCe-UEPCOP) 23.887 Peter Hedman

(Ericsson)

7.3 WID for Policy and Charging Control for supporting fixed broadband

Access networks (P4C) (Please do not submit documents directly to this

agenda item.)

23.896,

23.839

Marco Spini

(Huawei)

7.3.1 (BB1): WID for BB for Policy and Charging Control for supporting traffic from fixed

terminals and NSWO traffic from 3GPP Ues traffic (P4C-F)

23.896 Marco Spini

(Huawei)

7.3.2 (BB2): Policy and Charging Control for 3GPP UE terminals connected to Broadband

Forum access network as Trusted network in Interworking scenario (P4C-TI)

23.839 Konstantin Livanos

(Alcatel-Lucent)

7.4 Proximity Services (ProSe)

23.703 Haris Zisimopoulos

(Qualcomm)

7.5 (GCSE_LTE)

For the first sessions, please submit only Skeleton, Scope and Discussion Papers

(NOT P-CRs), on

- technical description of functionality expected

- architecture

- overview of expected stage 2 specification: procedures, state and configuration

requiredAs time permits in the second session – P-CRs will be opened.

23.7xx Curt Wong (Nokia

Siemens Networks)

7.6 User Plane Congestion Management (UPCON) 23.705 Stefan Schmid

(NEC)

7.7 WLAN Network Selection for 3GPP Terminals (WLAN_NS) (Please do

not submit documents directly to this agenda item.)

23.865 Vivek Gupta (Intel)

7.7.1 Enhancement/Modification of ANDSF and Network Selection to include

consideration of Hotspot 2.0 policies and address shortcomings of WLAN PLMN

selection

[Key issue 1, 5]


7.7.2 Harmonization of HotSpot 2.0 Policies and 3GPP Policies and management

information (delivered by ANDSF, configured, etc.)

[Key issue 2]


32

7.7.3 Other ANDSF and network selection enhancements

[Key issue 3]


7.7.4 Implications of specific parameters obtained via 802.11u (ANQP)

[Key issue 4, 7, 8]


7.7.5 Roaming Scenarios and ANDSF

[Key issue 6]


7.8 Application Based Charging (ABC) 23.203 Alla Goldner (Allot

Communications)

7.9 3GPP Packet Access: LIPA Mobility and SIPTO at the Local Network

(LIMONET) – Category B and C CRs only

23.060,

23.401

7.10 Study on Core Network Overload solutions (FS_CNO)

Phase 2 submissions.

23.843 John Kaippallimalil

(Huawei)

7.11 Study on S2a Mobility based On GTP and WLAN access to EPC

(FS_SaMOG)

23.852 Chunhui Zhu (ZTE)

7.12 Study on Optimizing Offloading to WLAN in 3GPP RAT mobility

(FS_WORM)

23.890 Steve Barrett

(Research In Motion)

7.13 Technical Enhancements and Improvements (TEI12) – Category B and C

only, no corrections, alignments, clarifications, etc.

7.14 Minor Corrections and Clean Up (TEI12) – Category F only, no stage 3

impact.

8 IMS Parallel Stream – see separate Table below in Section 2.

9 Project Planning and Management

9.1 New and Revised Work Items

9.2 Review of the Work Plan

9.3 Planning future meetings

10 AOB

11 Close of the Meeting

16:00 on Friday

2. 技術貢獻提案清單

3GPP LTE SA2 #96 (08 April-12 April, 2013) San Diego,US (14:10:9)

2.1 S2-131479, “Key Issue on EPC-level ProSe Discovery”, Intel, Broadcom

Corporation, CATT, III, LG Electronics, Radisys, Sony, <Accepted>

2.2 S2-131481, “Three Key Issues: EPC-level ProSe Discovery, EPC Support for

WLAN Direct Communications, Service Continuity”, Intel, III, Sony, Radisys, HTC,

<Accepted>

2.3 S2-131482, “ProSe service continuity”, Intel, III, Radisys, Sony, Qualcomm,

33

<Accepted>

2.4 S2-131141, “Solution for EPC-level ProSe Discovery”, Intel, III, Radisys, Sony,

<Posted>

2.5 S2-131142, “Solution for EPC Support for WLAN Direct Communications”, Intel,

III, Radisys, Sony, <Posted>

2.6 S2-131143, “Solution for Service Continuity”, Intel, III, Radisys, Sony, <Posted>

2.7 S2-131400, “Update on Key Issue #2 to reflect congestion abatement awareness”,

Intel, III, <Accepted>

2.8 S2-131103, “S1-U Congestion Mitigation Solution”, Intel, III, <Posted>

2.9 S2-131501, “Update of T5 Triggering”, Huawei, HiSilicon, Intel, Nokia Siemens

Networks, HTC, ZTE, LG Electronics, Verizon, KT Corp, KPN, China Mobile,

<Accepted>

2.10 S2-131508, “Updates for T5 Small Data Service”, Huawei, HiSilicon, Intel, Nokia

Siemens Networks, ZTE, HTC, CATT, LG Electronics, Verizon, KT Corp, KPN,

China Mobile, <Accepted>

2.11 S2-130896, “Proposal for general architecture requirements of ProSe”, HTC,

<Posted>

2.12 S2-131391, “Key issue for ProSe System Architecture”, Renesas Mobile Europe

Ltd., Qualcomm, HTC, <Accepted>

2.13 S2-131394, “Key issue for configuration for direct discovery and communication”,

ITRI, Qualcomm Incorporated, HTC, <Accepted>

2.14 S2-131422, “Key issue of Configuration and Capability Handling for ProSe”, HTC,

<Accepted>

34

Date post:	22-Feb-2022
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

3GPP SA2 #96 meeting

Documents