You are on page 1of 265

1

Overview of 3GPP Release 11 V0.1.1 (2012-06)

Overview of 3GPP Release 11 V0.1.1 (2012-06)
Contents
Contents....................................................................................................................................................1 Foreword...................................................................................................................................................6 1 Scope......................................................................................................................................................7 2 References..............................................................................................................................................7
2.1 Specifications.........................................................................................................................................................7 2.2 Tdocs 7 2.3 Work Plan, Work Items and Study Items...............................................................................................................8 2.4 Change Request database.......................................................................................................................................8

3 Abbreviations.........................................................................................................................................8 4 SA1 Features..........................................................................................................................................9
4.1 Advanced IP Interconnection of Services (IPXS) UID_470051...........................................................................9 4.2 System Improvements to Machine-Type Communications (SIMTC) UID_480030...........................................11 4.3 Unstructured Supplementary Service Data (USSD) simulation service in IMS (USSI) UID_480031..............17 4.4 SIPTO Service Continuity of IP Data Session (SIPTO_SC) UID_490030........................................................19 4.5 QoS Control Based on Subscriber Spending Limits (QoS_SSL) UID_490031.................................................20 4.6 Optimized Service Charging and Allocation of Resources in IMS whilst Roaming (OSCAR) UID_490032...22 4.7 Non Voice Emergency Services (NOVES) UID_500030..................................................................................25 4.8 Support for 3GPP Voice Interworking with Enterprise IP-PBX (VINE) UID_510047......................................26 4.x IMS Network-Independent Public User Identities (INIPUI) UID_520027 (moved to Rel-12)..........................27 4.9 Anonymous Call Rejection in the CS domain (ACR_CS) UID_520028...........................................................28

5 SA2 Features........................................................................................................................................30
5.1 Support BroadBand Forum Accesses Interworking (BBAI) UID_460026........................................................31 5.2 SRVCC aspect of eMPS (eMPS_SRVCC) UID_480035...................................................................................35 5.3 Single Radio Video Call Continuity for 3G-CS (vSRVCC) UID_500026..........................................................36 5.4 Network Provided Location Information for IMS (NWK-PL2IMS) UID_480038............................................38 5.5 Service Awareness and Privacy Policies (SAPP) UID_500032.........................................................................41 5.6 VPLMN Autonomous CSG Roaming (VCSG) UID_500033............................................................................43 5.7 Data Identification in ANDSF (DIDA) UID_510048.........................................................................................45 5.8 Location-Based Selection of gateways for WLAN (LOBSTER) UID_510050.................................................47 5.9 Single Radio Voice Call Continuity from UTRAN/GERAN to E-UTRAN/HSPA (rSRVCC) UID_530001...48 5.10 S2a Mobility based On GTP and WLAN access to EPC (SaMOG) UID_530046...........................................51 5.11 Roaming Architecture for Voice over IMS with Local Breakout (RAVEL) UID_540029...............................53

6 SA3 Features - Rel-11 Security small Enhancements (SEC11) UID_520030)....................................55
6.1 EEA3 and EIA3 (new Encryption & Integrity EPS security algorithms) UID_440055.....................................55 6.2 Specification of Protection against Unsolicited Communication for IMS (SPUCI) UID_480039....................57 6.3 H(e)NB security features for UE mobility scenarios (HNB_mob_Sec) UID_510053........................................59 6.y Security enhancements for usage of GBA from the browser (Web_GBA) UID_520031 (moved to Rel-12)....59 6.4 Generic Bootstrapping Architecture extensions for re-use of SIP Digest credentials (GBA-ext) UID_540012.60 6.5 Lawful Interception in the 3GPP Rel-11 (LI11) UID_520032...........................................................................62

7 SA4 Features........................................................................................................................................63
7.1 Extensions of Acoustic Test Specifications in TS 26.131 and TS 26.132 (Ext_ATS) UID_520033..................63 7.2 Enhancements to Multimedia: PSS, MMS, and MBMS Enhancements and Performance Improvements UID_530048..............................................................................................................................................64 7.3 Coordination of Video Orientation (CVO) UID_560040....................................................................................71 7.4 Mobile 3D Video Coding (M3DV) UID_560041................................................................................................72

8 SA5 Features - Rel-11 Operations, Administration, Maintenance and Provisioning UID_510051......73
8.1 IRP framework enhancements to support Management of Converged Networks UID_510056........................73 8.2 Management for Carrier Aggregation for LTE UID_530049.............................................................................75

3GPP

2

Overview of 3GPP Release 11 V0.1.1 (2012-06)

8.3 Network Management for 3GPP Interworking WLAN UID_530050................................................................77 8.4 IMS Performance Management enhancements UID_510057.............................................................................80 8.5 Enhanced Management of UE based network performance measurements UID_510058.................................81 8.6 CN performance measurements enhancement UID_520034..............................................................................83 8.7 UTRAN Self-Organizing Networks (SON) management UID_510059............................................................84 8.8 LTE Self-Organizing Networks (SON) coordination management UID_530051..............................................86 8.9 Inter-RAT Energy Saving Management UID_540031.......................................................................................88 8.10 Rel-11 Charging Management small Enhancements UID_510052..................................................................90 8.11 Add solutions for Rc - reference point within the Online Charging System UID_470045..............................90 8.12 Charging for Policy Enhancements for Sponsored Connectivity and Coherent Access to Policy related Data Bases UID_510060..................................................................................................................................91 8.13 Unification of Charging session from SIP AS and SRVCC functions in IMS UID_550019...........................92 8.14 Transit Inter Operator Identifier for IMS Interconnection Charging in multi operator environment UID_510029..............................................................................................................................................93

9 CT Features..........................................................................................................................................94
9.1 User Data Convergence - Data Model (UDC_DM) UID_480011......................................................................95 9.2 Definition of the UICC Application for Hosting Party Module (HPM_UICC) UID_510004...........................96 9.3 Usability improvement of II-NNI specification for inter-connection by means of Option Item list (NNI_OI) UID_520007..............................................................................................................................................97 9.4 enhanced Nodes Restoration for EPC (eNR_EPC) UID_520008.......................................................................98 9.5 Reference Location Information (RLI) UID_520009.........................................................................................99 9.6 IMS Stage-3 IETF Protocol Alignment (IMSProtoc5) UID_520010...............................................................100 9.7 IMS Emergency PSAP Callback (Stage 3) (EMC_PC) UID_530018..............................................................101 9.8 SAE Protocol Development (Stage 3) (SAES2) UID_530019.........................................................................103 9.9 GCSMSC and GCR Redundancy for VGCS/VBS (Stage 2/3) (RT_VGCS_Red) UID_530020.....................104 9.x Enhancement of the Protocols for SMS over SGs (PROTOC_SMS_SGs) UID_540016 (CP#56 stopped)....105 9.10 Support of RFC 6140 in IMS (GINI) UID_540015........................................................................................106 9.11 Enhancements for Multimedia Priority Service (MPS) – Gateway Control Priority (eMPS_Gateway) UID_540017............................................................................................................................................107 9.12 Service Identification for RRC Improvements in GERAN (SIRIG) UID_530003........................................108 9.13 AT commands for Universal Resource Identifier (URI) support (ATURI) UID_560005..............................110 9.14 PS Additional Number (Stage 3) (PSAN) UID_560006.................................................................................111 9.15 Generic IMS User Group Over Sh (GenUG_Sh) UID_560007......................................................................113

10 UTRA, LTE Features.......................................................................................................................114
10.1 Extending 850 MHz Upper Band (814 – 849 MHz) UID_500020.................................................................114 10.2 Further Self Optimizing Networks (SON) enhancements UID_530030........................................................116 10.3 Enhancement of Minimization of Drive Tests for E-UTRAN and UTRAN UID_530033............................118 10.4 E-UTRA medium range and MSR medium range/local area BS class requirements UID_530037...............118 10.5 Verification of radiated multi-antenna reception performance of UEs in LTE/UMTS UID_550016............119 10.6 Further enhancements to H(e)NB mobility - Part 1 UID_560013..................................................................119 10.7 Further enhancements to H(e)NB mobility - Part 1 UID_560014..................................................................119

11 LTE Features....................................................................................................................................120
11.1 Network-Based Positioning Support for LTE UID_430011...........................................................................122 11.2 Service continuity improvements for MBMS for LTE UID_480026.............................................................124 11.3 LTE-Advanced Carrier Aggregation of Band 3 and Band 7 UID_480023....................................................126 11.4 LTE Advanced Carrier Aggregation of Band 4 and Band 17 UID_500017...................................................127 11.5 LTE Advanced Carrier Aggregation of Band 4 and Band 13 UID_500018...................................................128 11.6 Further Enhanced Non CA-based ICIC for LTE UID_510021......................................................................129 11.7 LTE Advanced Carrier Aggregation of Band 4 and Band 12 UID_510022...................................................131 11.8 LTE Advanced Carrier Aggregation of Band 5 and Band 12 UID_510023...................................................132 11.9 LTE Advanced Carrier Aggregation of Band 7 and Band 20 UID_510024...................................................133 11.10 LTE Advanced Carrier Aggregation Band 2 and Band 17 UID_510025.....................................................134 11.11 LTE Advanced Carrier Aggregation Band 4 and Band 5 UID_510026.......................................................135 11.12 LTE Advanced Carrier Aggregation Band 5 and Band 17 UID_510027.....................................................136 11.13 New Band LTE Downlink FDD 716-728 MHz UID_510028......................................................................137 11.14 LTE Carrier Aggregation Enhancements UID_510030................................................................................139 11.15 LTE RAN Enhancements for Diverse Data Applications UID_510031......................................................141 11.16 LTE E850 - Lower Band for Region 2 (non-US) UID_510032...................................................................143 11.17 Carrier based HetNet ICIC for LTE UID_510033........................................................................................145 11.18 LTE Advanced Carrier Aggregation in Band 38 UID_520015....................................................................146

3GPP

3

Overview of 3GPP Release 11 V0.1.1 (2012-06)

11.19 LTE Advanced Carrier Aggregation in Band 41 UID_520016....................................................................147 11.20 LTE for 700 MHz Digital Dividend UID_520017.......................................................................................148 11.21 Relays for LTE (part 2) UID_520019...........................................................................................................150 11.22 LTE Advanced Carrier Aggregation of Band 3 and Band 20 UID_530023.................................................151 11.23 LTE Advanced Carrier Aggregation of Band 8 and Band 20 UID_530024.................................................151 11.24 LTE Advanced Carrier Aggregation of Band 1 and Band 7 UID_530025...................................................152 11.25 LTE Advanced Carrier Aggregation of Band 3 and Band 5 UID_530026...................................................152 11.26 LTE Advanced Carrier Aggregation of Band 4 and Band 7 UID_530027...................................................153 11.27 LTE Advanced Carrier Aggregation in Band 7 UID_530028......................................................................153 11.y LTE Advanced Carrier Aggregation Intra-Band, Non-Contiguous in Band 25 UID_530029 (moved to Rel12)...........................................................................................................................................................154 11.28 Signalling and Procedure for Interference Avoidance for in-device coexistence UID_530031...................154 11.29 Coordinated Multi-Point Operation for LTE UID_530032..........................................................................155 11.30 Network Energy Saving for E-UTRAN UID_530036..................................................................................156 11.31 LTE Advanced Carrier Aggregation of Band 11 and Band 18 UID_540020...............................................157 11.32 LTE Advanced Carrier Aggregation of Band 1 and Band 18 UID_540021.................................................157 11.33 LTE Advanced Carrier Aggregation of Band 1 and Band 19 UID_540022.................................................158 11.34 LTE Advanced Carrier Aggregation of Band 1 and Band 21 UID_540023.................................................158 11.35 Enhanced downlink control channel(s) for LTE Advanced UID_540025....................................................159 11.a LTE Advanced Carrier Aggregation of Band 3 and Band 5 with 2UL UID_550010 (moved to Rel-12)......159 11.b Intra-band, Non-contiguous CA for Band 3 for LTE Advanced UID_550011 (moved to Rel-12)................160 11.36 Public Safety Broadband High Power UE for Band 14 for Region 2 UID_550012.....................................160 11.37 Improved Minimum Performance Requirements for E-UTRA: Interference Rejection UID_550013........160 11.38 Additional special subframe configuration for LTE TDD UID_550014......................................................161 11.39 LTE in the 1670-1675 MHz Band for US UID_550017...............................................................................161 11.x LTE Advanced Carrier Aggregation of Band 3 and Band 8 UID_550018 (moved to Rel-12)......................162

12 UTRA Features................................................................................................................................163
12.1 UE over the air conf. testing methodology - Laptop mounted equipment free space test UID_450016.........164 12.2 Eight carrier HSDPA UID_500019................................................................................................................165 12.3 UE demodulation performance requirements under multiple-cell scenario for 1.28Mcps TDD UID_500021 .................................................................................................................................................................167 12.4 Uplink Transmit Diversity for HSPA UID_500022.......................................................................................168 12.5 Introduction of New Configuration for 4C-HSDPA UID_510018.................................................................172 12.6 Non-contiguous 4C-HSDPA operation UID_510019.....................................................................................173 12.7 Further Enhancements to CELL_FACH UID_510020...................................................................................175 12.8 HSDPA Multiflow Data Transmission UID_530034.....................................................................................177 12.9 Four Branch MIMO transmission for HSDPA UID_530035.........................................................................177 12.10 MIMO with 64QAM for HSUPA UID_540009...........................................................................................178 12.11 HSDPA Dual-Band Multi-Carrier combinations UID_540024....................................................................178

13 GERAN Features.............................................................................................................................179
13.1 Full Support of Multi-Operator Core Network by GERAN (Full_MOCN-GERAN) UID_510001..............179 13.2 Introduction of ER-GSM band for GSM-R (RT_ERGSM) UID_530002.......................................................182 13.3 Medium range/local area requirements for multicarrier BTS (MRLA) UID_540003.....................................183 13.4 Domain Specific Access Control in GERAN (GDSAC) UID_550023...........................................................184

14 SA1 Studies......................................................................................................................................185
14.1 Study on IMS based Peer-to-Peer Content Distribution Services UID_450047.............................................186 14.2 Study on Non Voice Emergency Services (FS_NOVES) UID_460024.........................................................187 14.3 Study on Support for 3GPP Voice Interworking with Enterprise IP-PBX (FS_VINE) UID_480033...........188 14.4 Study on IMS Network-Independent Public User Identities (FS_INIPUI) UID_490033..............................189

15 SA2 Studies......................................................................................................................................190
15.1 Study on IMS Evolution (FS_eIMS) UID_410041........................................................................................190 15.2 Study on Policy solutions and enhancements (FS_PP) UID_440047..............................................................192 15.3 Study on IPv6 Migration (FS_IP6M) UID_440048........................................................................................194 15.4 Study on SR Voice Call Continuity from UTRAN/GERAN to E-UTRAN/HSPA (FS_rSRVCC) UID_460030............................................................................................................................................195 15.5 Study on Roaming Architecture for Voice over IMS with Local Breakout (FS_RAVEL) UID_510044.......196

16 SA3 Studies......................................................................................................................................198
16.1 Study on UTRAN key management enhancements UID_380084..................................................................198

3GPP

4

Overview of 3GPP Release 11 V0.1.1 (2012-06)

16.x Study on Extended IMS Media Plane Security features UID_480043 (moved to Rel-12)............................198 16.2 Study on Single Sign On (SSO) Application Security for IMS - based on SIP Digest UID_480048............199

17 SA4 Studies......................................................................................................................................201
17.1 Study on Mobile 3D Video Coding (FS_M3DVC) UID_520036...................................................................201 17.x Study on Improved Support for Dynamic Adaptive Streaming over HTTP in 3GPP UID_540033 (moved to Rel-12).....................................................................................................................................................203

18 SA5 Studies......................................................................................................................................204
18.1 Study on version handling UID_470050.........................................................................................................204 18.2 Study on Management of Converged Networks UID_480047.......................................................................205 18.3 Study on UDC information model handling and provisioning: Example Use Cases UID_490039...............206 18.4 Study on OAM aspects of inter-RAT Energy Saving UID_510045...............................................................207 18.x Study on management of Heterogeneous Networks UID_510046 (moved to Rel-12).................................208 18.y Study on OAM aspects of Network Sharing UID_540032 (moved to Rel-12).............................................208

19 CT Studies........................................................................................................................................209
19.1 Study on impacts on UE-Core Network signalling from Energy Saving UID_480015.................................209 19.2 Study on EPC Nodes Restoration UID_490014.............................................................................................210

20 GERAN Studies...............................................................................................................................211
20.1 Study on GERAN improvements for Machine-Type Communications UID_460001...................................211 20.2 Study on Signal Precoding enhancements for EGPRS2 DL UID_480003.....................................................213 20.3 Study on Solutions for GSM/EDGE BTS Energy Saving UID_490006........................................................214 20.4 Study on VAMOS enhancements UID_520001.............................................................................................215 20.5 Study on GERAN enhancements for Mobile Data Applications UID_520002..............................................216

21 LTE Studies.....................................................................................................................................218
21.1 Study on Coordinated Multi-Point operation for LTE UID_470014..............................................................218 21.2 Study on Signalling and procedure for interference avoidance for in-device coexistence UID_480028.......220 21.3 Study on Inclusion of RF Pattern Matching as a positioning method in the E-UTRAN UID_500016..........222 21.4 Study on HetNet mobility improvements for LTE UID_510034...................................................................223 21.x Study on Enhanced Uplink Transmission for LTE UID_510035 (RP#56 stopped).......................................224 21.5 Study on further Downlink MIMO enhancements for LTE-Advanced UID_510037....................................225 21.6 Study on Further Enhancements to LTE TDD for DL-UL Interference Management and Traffic Adaptation UID_510039............................................................................................................................................227 21.7 Study on Provision of low-cost MTC UEs based on LTE UID_530052........................................................228 21.8 Study on LTE Coverage Enhancements UID_530053...................................................................................230 21.9 Study on Mobile Relay for E-UTRA UID_530054........................................................................................231 21.10 Study on Enhanced performance requirement for LTE UE UID_530055....................................................233 21.11 Study on LTE-HRPD (High Rate Packet Data in 3GPP2) inter-RAT SON UID_550020...........................234 21.12 Study on Measurements of radio performances for LTE terminals - TRP and TRS test methodology UID_550022............................................................................................................................................235

22 UTRA, LTE Studies.........................................................................................................................237
22.1 Study on Measurement of Radiated Performance for MIMO and multi-antenna reception for HSPA and LTE terminals UID_430020...........................................................................................................................237 22.2 Study on Extending 850 MHz UID_440016...................................................................................................239 22.3 Study on RAN improvements for Machine-Type Communications UID_450015........................................240 22.4 Study on UE Application Layer Data Throughput Performance UID_500002..............................................241 22.5 Study on further enhancements for HNB and HeNB UID_510036................................................................243 22.6 Study on Interference analysis between 800~900 MHz bands UID_510038.................................................244 22.7 Study on UMTS/LTE in 900 MHz band (Japan, Korea) UID_520018..........................................................245 22.8 Study on RF and EMC requirements for active Antenna Array System (AAS) Base Station UID_530056. 246 22.9 Study on Passive InterModulation (PIM) handling for for UTRA and LTE Base Stations UID_550021.....247

23 UTRA Studies..................................................................................................................................248
23.1 Study on Uplink MIMO UID_500014............................................................................................................248 23.2 Study on HSDPA Multipoint Transmission UID_500015..............................................................................249 23.3 Study on UE Over The Air (OTA) test method with Head and Hand Phantoms UID_530057.....................250 23.4 Study on HSPA feedback and signalling efficiency enhancements for LCR TDD UID_540026..................250

3GPP

5

Overview of 3GPP Release 11 V0.1.1 (2012-06)

24 Rel-11 Completed Features and Studies...........................................................................................252 25 Rel-11 Deleted Features and Studies................................................................................................258 TSG#56 completed Rel-11 Studies.......................................................................................................259
Release 11 Studies (non-RAN)................................................................................................................................259 Release 11 RAN Studies..........................................................................................................................................259

TSG#56 completed/stopped Rel-11 Features........................................................................................260
Release 11 Features (non-RAN)..............................................................................................................................260 Release 11 RAN Features........................................................................................................................................263

TSG#56 New Rel-11 Features).............................................................................................................263
Release 11 Features (non-RAN)..............................................................................................................................263 Release 11 RAN Features........................................................................................................................................265

TSG#56 New Rel-11 Testing................................................................................................................265 TSG#56 New Rel-11 IETF dependency................................................................................................265

3GPP

6 Overview of 3GPP Release 11 V0. ongoing. Stopped Features and Studies are listed at the end of the present document. completed. who wishes to thank all the contributors for their dedication and quality of inputs. Adrian Scrase VP International Partnership Projects.1. RT.g. Legend: Completed WI Ongoing WI Moved WI to/from another Release Stopped WI The present document has been produced by the ETSI MCC department headed by Adrian Scrase. The overall document was coordinated by Adrian Zoicas (MCC Work Plan Coordinator).1 (2012-06) Foreword The coloured highlight of the Unique IDentifier (UID) reflects the status of the work items e. etc. ETSI 3GPP Support 3GPP Support Team Team RAN2 RAN RAN RAN3 SA3 SA5 SA SA2 CT1 CT6 CT CT4 SCP Specifications Kevin Flynn Marketing & Communication John Meredith Manager Adrian Zoicas Work Plan Coordinator MSG. RT TFES Joern Krause Alain Sultan Juha Korhonen Dionisio Zumerle Mirko Cano Soveri Jiwan Han Gwiho Chun Maurice Pope Ingbert Sigovich Frédé ric Firmin Xavier Piednoir Kimmo Kymalainen Patrick Mé rias SA1 MSG CT3 RAN5 GERAN3 RAN1 GERAN2 GERAN GERAN1 SA4 Gert Thomasen Paolo Usai Issam Toufik IssamToufik 2011 03 2009 12 RAN4 3GPP .

1. thus all TSs pertaining to a Release may not necessarily be frozen at the time the Release itself is functionally frozen.7 Overview of 3GPP Release 11 V0. test specs may lag by some considerable time.'.y 3GPP TS 41.. Phase 2+ Release 11 .3gpp.3gpp.101 Freeze Dates Release Rel-11 TS/TR version) 11. indicative only (see note) Stage 1 frozen Sep 2011 Stage 2 freeze March 2012 Stage 3 freeze September 2012 (protocols stable three months later) Note: After "freezing". Its latest version is available at: http://www. are available at: http://www.3gpp. 2 References [1] [2] [3] 3GPP TR 21.x. a Release can have no further additional functions added. detailed protocol specifications (stage 3) may not yet be complete.3gpp.101 GSM/EDGE.y Functional freeze date.101: "Technical Specifications and Technical Reports for a UTRAN-based 3GPP system".See Version 11 of TR 41. 3GPP TS 21. for all Releases. containing the most recent corrections and additions. and are the inputs for elaborating the specs. Indeed since Release 7.101: "Technical Specifications and Technical Reports for a GERAN-based 3GPP system".1 Specifications Global information on the Specifications (also called “specs”) can be found at: http://www.3gpp. In addition.org/ftp/ starting with 'tsg.org/ftp/Specs/Archive/ where the specifications are sorted by series and then by folders containing all the available versions of a given spec (one folder per spec). the trend has been to freeze each of the three stages independently.x.htm The latest versions of all 3GPP specifications..x. 3GPP .1 (2012-06) 1 Scope The present document contains a high-level description of the 3GPP Release 11 Features. They are available (sorted by 3GPP technical groups (Technical Specification Groups (TSGs) and Working Groups (WGs)) at: http://www..See version 11 of TR 21. 2. other than to align earlier stages with later stages.org/specs/specs. Version 11. However.org/ftp/Specs/latest/ For specific purposes.y 2.905: "Vocabulary for 3GPP Specifications".org/ftp/Information/WORK_PLAN/Description_Releases/ 3G Release 11 . Version 11. older versions might be needed. A "frozen" Technical Specification is one which can have no further category B or C (new or modified functionality) Change Requests. These versions are available at: http://www.2 Tdocs The Temporary Documents (tdocs) are mainly the original papers written by the 3GPP Members.

org/specs/CR. a CR number that is unique for a certain specification (different CR versions are possible.905 [1] and the following apply. When it is considered to be 80% complete. periodically updated. WIDs / SIDs are stored in: http://www.4 Change Request database A specification is originally drafted and maintained by a rapporteur. who compiles the contents from discussions in the WGs and TSGs.3gpp. Work Items and Study Items Work Item Description (WID) / Study Item Description (SID) is a form which initial version provides the target to be reached before starting the work.org/ftp/Information/Databases/Change_Request/ Further information on CR is available at: http://www. The CR database contains information on CRs including a Work Item code. EPC EPS E-UTRAN IMS LTE SAES Evolved Packet System IP Multimedia Subsystem System Architecture Evolution Specification 3GPP . After this. The 3GPP Work Plan is available at: http://www.3gpp. its starting date and (foreseen or actual) completion date. references to the source Individual 3GPP Member(s) and relevant WG/TSG temporary documents numbers and meetings. the actual progress.3 Work Plan. as: the WG in charge of it. it is brought under a so-called "change control" process. changes to the specification can only be made using Change Requests (CRs) that are usually agreed by consensus in the WG responsible for the specification. as well as summary information for each WI. containing the full list of Work Items and Study Items.org/ftp/Information/WI_sheets/ The 3GPP Work Plan is a living document.1.1 (2012-06) 2. Potential subsequent versions precise the target and foreseen completion dates according the actual work progress. the status of each CR. but only one can ever be approved).8 Overview of 3GPP Release 11 V0. etc.org/ftp/Information/WORK_PLAN/ 2. and then formally approved by the relevant TSG. the abbreviations given in TR 21. This database is available in: http://www.3gpp.3gpp.htm 3 Abbreviations For the purposes of the present document.

Service principles). However.C1.S2.101(Service aspects.C3. to introduce a new clause in TS 22. it is also recognized that some of the identified requirements only concern IMS and Interconnection of IP Multimedia Networks.C1.C3 WI_rapporteur Telefónica KPN Deutsche Telekom Vodafone Vodafone Vodafone AT&T Qualcomm Tatara Systems Alcatel-Lucent 4.S2.IETF S1.S2.C3 S1.1.e.S5.C3 S1.C1. For such requirements the proposal is to introduce a new clause in TS 22. Belgacom.893 UID_380083 Study on advanced requirements for IP interconnect (FS_IPXS) New requirements for the IP-interconnection of operators using an IP-interconnection Intermediate Carrier have been identified in clauses 5 and 6 of TR 22.S5. GSMA) are obtained and also included in the changes to 3GPP specifications.C3 WI_rapporteur Telefónica Telefónica Ericsson Ericsson UID 470052 500025 Name Stage 1 Stage 2 Resource S1 S2 Finish 21/09/2011 14/12/2011 Hyperlink SP-100876 SP-100876 WI_rapporteur Telefónica Ericsson Notes SP#53 completed SP#54 completed TSs_and_TRs 22.g. KPN. TR 22. Overlapping with activities carried out by GSMA (e. These clauses are used as a basis for introducing new requirements into the 3GPP specifications. 22.C6.C3 S1 S2 C1.101. Stage 1). Triggered by Rel-10 TR 22.C1.S3.S2 S1.893.228 23.C4.9 Overview of 3GPP Release 11 V0. IPX) and other bodies in the area of IP interconnection should be avoided.228 (Service requirements for the Internet Protocol (IP) multimedia core network subsystem (IMS). I.g.C3 S1 S1. as far as possible.C3.1 Advanced IP Interconnection of Services (IPXS) UID_470051 Resources: UID 470051 470052 500025 530004 S1.S2.893 also recommends that requirements from other organisations working on IP Interconnection (e.1 (2012-06) 4 SA1 Features UID 47005 1 48003 0 48003 1 49003 0 49003 1 49003 2 53002 1 50003 0 51004 7 52002 8 Name Advanced IP Interconnection of Services System Improvements to Machine-Type Communications Unstructured Supplementary Service Data (USSD) simulation service in IMS SIPTO Service Continuity of IP Data Session QoS Control Based on Subscriber Spending Limits Optimized Service Charging and Allocation of Resources in IMS whilst Roaming Inclusion of Media Resource Broker (Stage 2/3) Non Voice Emergency Services Support for 3GPP Voice Interworking with Enterprise IP-PBX Anonymous Call Rejection in the CS domain Acronym IPXS SIMTC USSI SIPTO_SC QoS_SSL OSCAR MRB NOVES VINE ACR_CS Resource S1.S2 C1.R 3 S1.R2. TR 22.228 Supporting Companies: Telefonica. new requirements are captured in a single place in an existing specification.C1 S1. InterDigital. Orange.C4.C3 Name Advanced IP Interconnection of Services Stage 1 Stage 2 Stage 3 Acronym IPXS IPXS IPXS IPXS Resource S1.S2. Justification 3GPP .893 recommends that.C1.

In particular. Charging Aspects: To be determined. toll-free. ETSI TISPAN). Objective: To specify the technical requirements for carrier grade inter-operator IP Interconnection of Services for the support of Multimedia services provided by IMS and for legacy voice PTSN/PLMN services transported over IP infrastructure (e. premium rate and emergency calls). new models of interconnection may emerge in the market where Network Operators expose network capabilities to 3rd party Application Providers including user plane connectivity for the media related to the service.g. service level aspects for national transit IP interconnect and service level aspects for next generation corporate network IP interconnect (peer-to-peer business trunking). There are currently a number of initiatives underway outside 3GPP addressing IP Interconnection of services scenarios and commercial models to achieve this.229 29.g. Resource C1.10 Overview of 3GPP Release 11 V0. GSMA. for example.e. as well as the underpinning transport for delivering IMS based multi-media services. These initiatives require the use of appropriate technical solutions and corresponding technical standards.1. Service Aspects: UID 530004 530104 530204 Define interoperability requirements of IP based services to ensure transparency to the end user. some of which are already available and others which will require development in 3GPP. Security Aspects: To be determined. Moreover. • • To ensure that requirements are identified for the Stage 2 & 3 work to identify relevant existing specifications. Service level aspects for IP Interconnection (service control and user plane aspects) between Operators and 3rd party Application Providers. Specifically the work will cover: • Service level aspects for direct IP inter-connection between Operators. initiate enhancements and the development of the new specifications as necessary.C3 C1 C3 Finish 12/09/2012 12/09/2012 07/09/2012 Comp 25% 50% 0% Hyperlink CP-110646 CP-110646 CP-110646 TSs_and_TRs Stage 3 24. Any new requirements identified should not overlap with requirements already defined by other bodies (e. These technical requirements should cover the new interconnect models developed by GSMA (i. focus on the new feature of Providing IMS application services in transit network scenarios as specified in 23. 3GPP .g. Also. the IPX interconnect model) and take into account interconnect models between national operators (including transit functionality) and peering based business trunking. appropriate interconnect solutions are required to support communications between users connected to different networks. VoIP). ETSI has recently defined requirements and use case scenarios for IP Interconnection of services. the GSM Association has developed the IPX (IP Packet Exchange). In order to ensure carrier grade end to end performance.228 Service Aspects: Define interoperability requirements of IP based services to ensure transparency to the end user. Service layer aspects for interconnection of voice services (e.165 Name Stage 3 CT1 part of Stage 3 CT3 part of Stage 3 Objective: to specify stage 3 aspects of advanced IP interconnection of Services as originating from stage 2 architecture deriving from the 3GPP SA2 work item described in this document.1 (2012-06) IP is being introduced in both fixed and mobile networks as a more cost-effective alternative to circuit switched technology in the legacy PSTN/PLMN.

272.221.221.868 TBD SIMTCSec S3 50% SP-110877 3GPP .682 new 23.S3. Was Rel-10 UID_450028 (TR on Stage 2 for NIMTC) SP#56 completed SP#56 completed SP#54 completed SP#56 completed TSs_and_TRs new TR 23.1 (2012-06) 4.C3.C4 S3 S5 R2.C4.888 52002 1 52022 1 52032 1 52042 1 BB1: Stage 2 Reachability Aspects of SIMTC On-line device trigger MTC Addressing Identifiers – especially removal of MSISDN dependencies in the architecture MSISDN-less / PSOnly MTC related interfaces and functional entities to support above features (MTCsp. new 23.R3.2 System Improvements to Machine-Type Communications (SIMTC) UID_480030 Resources: UID 480030 480130 480230 490028 530005 520021 530006 560002 520024 540019 530009 S1.682 23.C6 S2 C1.C6.R3 Acronym SIMTC SIMTC SIMTC SIMTC SIMTC-CS SIMTC-Reach SIMTC-Reach SIMTC-PS_Only SIMTC-Sec SIMTC-CH SIMTC-RAN_OC Resource S1 S2 S3 C4.060.C1. 23.C1. new 23.C6 C1.1.368 SA2 part for SIMTC UID 48023 0 Name TR on Stage 2 for SIMTC Acronym SIMTC Resource S2 Finish 12/09/201 2 Hyperlink SP110877 Notes SP#56 completion 06/12=>09/12.682 52052 1 54001 4 SIMTCReach SIMTCReach S2 S2 07/03/201 2 07/03/201 2 SP110877 SP110877 SP#55 completed SP#55 completed 23.11 Overview of 3GPP Release 11 V0. etc. new 23. SP#55 TR 23.C3.888v160 for Information.682 new 23.C6 WI_rapporteur KPN KPN Intel Samsung Ericsson Intel Ericsson Ericsson Samsung Ericsson Huawei Name System Improvements to Machine-Type Communications Stage 1 for SIMTC TR on Stage 2 for SIMTC TR on Security aspects of SIMTC Stage 2/3 for CS aspects for SIMTC BB1: Stage 2 Reachability Aspects of SIMTC BB1: Stage 3 (CS+PS) Reachability Aspects of SIMTC Stage 2/3 for SMS in MME architecture option and related PSonly service subscription BB4: Secure Connection and Privacy of SIMTC BB5: Charging of SIMTC (Stage 2/3) RAN overload control for Machine-Type Communications Enhancements to Rel-10 Feature UID_410031 (NIMTC) based on Rel-11 Study on enhancements to MTC SA1 part for SIMTC UID 480130 Name Stage 1 for SIMTC Resource S1 Finish 21/09/2011 Hyperlink SP-110877 Notes SP#53 completed TSs_and_TRs 22.682 SA3 part for SIMTC UID 49002 8 52002 4 Name TR on Security aspects of SIMTC BB4: Secure Connection and Privacy of SIMTC Acronym SIMTC Resource S3 Finish 20/06/201 2 20/06/201 2 Comp 50% Hyperlink SP-110877 Notes Was Rel-10 UID_460023 (Security for NIMTC) TSs_and_TRs new TR 33.S5.368 new 23.S2.R2.C1.C4.) SIMTCReach SIMTCReach SIMTCReach SIMTCReach S2 S2 S2 S2 20/06/201 2 20/06/201 2 14/12/201 1 20/06/201 2 SP110877 SP110877 SP110877 SP110877 23.

BB4: "Secure Connection and Privacy" includes . At the same time the identified NIMTC stage 1 requirements in TS 22. 32.368. TeliaSonera. Nokia Siemens Networks.” The study on Machine-to-Machine communications indicated the potential for machine-type communications over mobile networks. Sierra Wireless.1 (2012-06) 50% 50% SP-110877 SP-110877 TBD TBD SA5 part for SIMTC UID 54001 9 Name BB5: Charging of SIMTC (Stage 2/3) Acronym SIMTCCH Resource S5 Finish 12/09/201 2 Comp 50% Hyperlink SP110877 Notes TSs_and_TRs 32. Ericsson. Samsung. Interdigital.MTC related interfaces and functional entities to support above features.12 52012 4 53005 8 Secure Connection MTC Feature (TS 22. Motorola Mobility. .240. Bridgewater Enhancements to Rel-10 Feature UID_410031 (Network Improvements for Machine Type Communications) based on Rel-11 Study on enhancements to MTC. 32. TS 22. Stage 2 objectives: to provide stage 2 for the requirements identified in TS 22. Orange. MediaTek. ST-Ericsson. but are less optimal for machine-to-machine. Acision. Intel. alarm systems and other applications can also be identified.251. Due to time constrains. Renesas. The current mobile networks are optimally designed for Human-to-Human communications.e. In particular it is possible to identify potential applications for mass M2M service. consumer products manufacturers could keep in touch with their products after they are shipped – car manufacturers could serve as an example for that.101 and TR 23. Identifiers – especially removal of MSISDN dependencies in the architecture. NEC. it is important to optimise their support for machine-type communications. to match the expectations of mass-market machine-type services and applications. machine-to-human. use cases and functionality specified in Rel-10 NIMTC in TS 22. There is a need to create a new WI to allow completion of these aspects. e.368 are expected to be subject to further refinement. this TS was completed within the Rel-10.368. MTC Location Privacy Concerns related to the MTC features in the scope of this same Work Item 3GPP . Verizon Wireless. CATT. 32.1. China Mobile.g. Zigbee) in combination with fixed network communications are also a contender for the implementation of such applications.368 specifies the Machine-to-Machine communications requirements.Secure Connection MTC Feature (TS 22. SA3 shall have the primary responsibility for the following BB. However. TS 22.368. Addressing. the market segments that are currently using M2M.368 the stage 2 and stage 3 work could not be completed in the same R10 timeframe.868 on Machine-to-Machine communications: “It appears that there is market potential for M2M beyond the current "premium M2M market segment" i.368). for example wireless sensor networks (e. Panasonic.10) MTC Location Privacy SIMTCSec SIMTCPriv S3 S3 20/06/201 2 20/06/201 2 Overview of 3GPP Release 11 V0.298. or human-to-machine applications.888. including clarifications and extension due to the results of the studies related to stage 2 developments.299 Supporting Companies: KPN. Sagem Orga. 7. LG Electronics.g. ZTE. Stage 1 objectives: to refine existing reqs. for several MTC features described in TS 22. It is also important to enable network operators to offer machine-type communication services at a low cost level. SA2 shall have the primary responsibility for the following Building Blocks (BB): BB1: “Reachability Aspects” requirements include Device Triggering On-line. Alcatel-Lucent. PS Only support. Justification Excerpt from TR22. Another example is in the home environment where remote maintenance of heating and air condition. Huawei.2. For mobile networks to be competitive for mass machine-type applications. Telecom Italia.

3GPP . as an assessor of the security implications and resulting required changes to technical specifications. However. session initiation and control) for machine-type data communication service should be investigated and leveraged if feasible.13 Overview of 3GPP Release 11 V0.1 (2012-06) Further. Reuse of existing 3GPP functions (e. Work ongoing in external standard bodies shall be considered. A service optimized for MTC is likely to differ from a service optimized for human-to-human communications. BB5: "Charging Aspects" includes: Charging Requirements (TS 22. but the applications themselves are out of scope of this WID. MTC aspects of (x)SIMs and/or new models for the management of (x)SIM are out of scope of this WID.1. if any.368). Charging Aspects: undertaken by SA5 with help from SA2 to support to the functionality identified in TS 22. may be relevant to the machine-type applications involved. There are many different applications which may make use of machine-type data communication. Security Aspects: undertaken by SA3 to support to the functionality identified in TS 22.368. not all charging requirements can be fulfilled within Rel-11 scope. Service Aspects: MTC is seen as a form of data communication which involves one or more entities that do not necessarily need human interaction. specification of these applications themselves is outside the scope of this WID. Note: dependent on prioritization of Rel-11.368. MMI-Aspects.g. SA3 shall have secondary responsibility for the BBs 1listed above.

23.012. 29.C4.003. and the stage 3 parts shall be started only after the applicable normative stage 2 specification is available. 3GPP .214.272.C1.008.002.282.C6 Finish 07/09/201 2 07/09/201 2 07/09/201 2 07/09/201 2 Comp 49% Notes CP#56 updated WID CP110756=>CP-120276 CP#56 updated WID CP110756=>CP-120276 CP#56 updated WID CP110756=>CP-120276.008 31. 29.C3. 24.008. 24.040.102. Most likely not relevant for CT6 anymore according to current status at SA2 23.008.1. 29.338 3 Justification Provide stage 3 and stage 2 specification for CS. 29. Also back-off timer handling needs to be enhanced to allow dual priority levels used by UEs. The work shall be prioritised accordingly.C4.061.060. 24.272.102 UID 530006 530106 530206 530306 Name BB1: Stage 3 (CS+PS) Reachability Aspects of SIMTC CT1 part CT3 part CT4 part Resource C1. new TS (29. 24.C3.C4. 29.234. 24. 29. 29.C4 Finish 07/09/201 2 Comp 50% 56010 2 56020 2 CT1 part CT4 part C1 C4 07/09/201 2 07/09/201 2 50% 50% Notes New Stage 2 i/f btw MME & SMS central functions requires a Diameter based protocol as it applies to MME.275. LTE operators with SMS in MME architecture but w/o 3GPP 2G/3G services (CDMA).008. 23. 29.368 29. for the requirements identified in TS 22.040. new TS 29.1 (2012-06) Resources: UID 53000 5 53000 6 56000 2 C1. 29. to allow UEs to over-ride Low Priority configuration and initiate NAS requests without indication of Low priority. Provide stage 3 specification to support Dual Priority.C6 C1 C6 Finish 07/09/201 2 07/09/201 2 07/09/201 2 07/09/201 2 07/09/201 2 Comp 2% 5% 0% 0% 0% Notes CP#56 updated WID CP-110756=>CP120276.002.111 UID 56000 2 Name Stage 2/3 for SMS in MME architecture option and related PS-only service subscription Resource C1. 29.301. 29. 29. Dual Priority shall be an operator controlled UE configuration option.368 v100 for Information CP#56 updated WID CP110756=>CP-120276 TSs_and_TRs Stage 3 C1 C3 C4 50% 65% 70% 530406 CT6 part C6 07/09/201 2 10% CP#56 updated WID CP110756=>CP-120276.368 23. 29.C3.305.C4 Hyperlink CP120418 CP120418 CP120418 Name Stage 2/3 for CS aspects for SIMTC BB1: Stage 3 (CS+PS) Reachability Aspects of SIMTC Stage 2/3 for SMS in MME architecture option and related PS-only service subscription UID 53000 5 53010 5 53020 5 53030 5 53040 5 Name Stage 2/3 for CS aspects for SIMTC Stage 2 Stage 3 CT1 part CT6 part Resource C4. TS 29.305. 29.C6 C4 C1.274.337) 31.14 Overview of 3GPP Release 11 V0.118 23.212.336.301.C6 C1. 31.C6 C1.012 Stage 3 24. 31. CP#56 updated WID CP-110756=>CP120276 CP#56 updated WID CP-110756=>CP120276 TSs_and_TRs Stage 2/3 23. 23.368. 29.213. Completion 06/12=>09/12 - TSs_and_TRs Stage 2/3 23. 24. need not deploy Diameter based solution & MAP if only SMS via PS req.011. 29.103. new TS 29.C6 Acronym SIMTC-CS SIMTC-Reach SIMTCPS_Only Resource C4.003.230.215. 29.C1. 29.

TS 36.272) 2) 3) 4) This WI does not cover further enhancements and corrections for issues originally covered by the NIMTC work. Dual Priority.1. 7.g.682). so not MAP based. 3GPP . TS 23. SMS in MME (TS 23. This may cause intolerable delays. packet loss or even service unavailability.221). One work item acronym has been allocated per key area to improve possibilities for planning and tracking of the work.331.060. Resources: UID 53000 9 53010 9 R2.R3. to deploy a Diameter based solution. Work on a stage 3 key area shall only begin when normative stage 2 specification is available.060 and TS 23.304. "Extended Access Barring for UTRAN and E-UTRAN for CT groups".368.301 31.331. SIMTC-PS_Only PS-only Service Provision (TS 23. 7. LTE Name RAN overload control for Machine-Type Communications Core part R2.1. A Diameter based protocol between the HSS and the central SMS functions is also justified to answer the requirement for operators having a LTE network with SMS in MME architecture but without 3GPP 2G/3G Services (e. 36.15 Overview of 3GPP Release 11 V0. It will require a Diameter based protocol as it applies to MME. 24.682). 25.368.1.008.3 TSs_and_TRs UTRA. Other charging aspects covered by SA5 WID. SIMTC-Reach Device Triggering (TS 22.331) "Reachability Aspects". thus the network has to face increased load as well as possible surges of MTC traffic. TS 23.413 UID 53020 9 53030 9 53040 9 Name Stage 3 (CS+PS) Extended Access Barring for UTRAN and E-UTRAN CT1 part of Stage 3 CT6 part of Stage 3 Resource C1. 7.102 3 Justification A large number of MTC devices are expected to be deployed in a specific area. 36.C6 Resource Finish 14/09/201 2 07/09/201 2 Comp 64% Hyperlink RP111373 RP111373 Status_Report Notes Stage 2.5. 24.3 and TS 23. Radio network congestion may happen due to the mass concurrent data and signalling transmission.2). "PS-Only".C6 Finish 14/09/201 2 Comp 49% Hyperlink CP120418 WI_rapporteur Ericsson Notes CP#56 updated WID CP110756=>CP120276 CP#56 completed CP#56 updated WID CP110756=>CP120276 TSs_and_TRs Stage 3 C1 C6 15/06/201 2 14/09/201 2 100% 10% CP120418 CP120418 Ericsson ST Ericsson 23. Addressing (TS 22. 1) "CS aspects for CT groups".368). and avoid a deployment of MAP if only SMS via PS is required.R3 90% RP-120490 RP#56 completion 06/12=>09/12 25.1 (2012-06) Provide stage 2 and stage 3 specification changes needed for the SMS in MME architecture option and related PSonly service subscription. 36. SIMTC-RAN_OC Updates to CT1 specifications for support of Extended Access Barring for UTRAN and E-UTRAN (TS 22. CDMA networks). Add any associated stage 3 impacts to CS protocols. 25.368.413.122. Stage 2 has defined a new interface between MME and SMS central functions. 4. 7 Charging Aspects PCC might be affected.331 and TS 25.368.C1.682.2 and TS 23.especially removal of MSISDN dependencies in the architecture (TS 22.1.304. Identifiers . Objective: to develop SIMTC stage 2 and stage 3 for CS and SIMTC stage 3 PS solutions for the key areas as listed below. SIMTC-CS Updates to CS location management procedures (TS 22.4.

3.1.4). the control of signalling congestion and overloading of RAN nodes due to MTC devices have been identified as the first priority improvement area as concluded in DRAFT TR 37.868.011.16 Overview of 3GPP Release 11 V0. 3GPP . Objective: for both UMTS and LTE to specify Extended Access Barring mechanisms for RAN overload control (corresponding requirement is specified in TS 22. Therefore. RAN level mechanisms to guarantee network availability and help network to meet performance requirements under such MTC load need to be investigated and specified. section 4. The EAB mechanism should be suitable for but not limited to Machine-Type Communications.1 (2012-06) Within the Study Item ‘Study on RAN improvements for Machine-Type Communications’.

e. The functionality should be available for Multimedia Telephony. dials "*101#<SEND>". This could happen either via the Ut interface as XCAP data using http or in a SIP message.1 (2012-06) 4. e. 3GPP .g. i.3 Unstructured Supplementary Service Data (USSD) simulation service in IMS (USSI) UID_480031 Introduction (document S1-101066 from SA1#50 Venice. is done via the range of the feature code. Italy.1.C3 Resource S1. Only the simulation of mobile initiated USSD – MMI mode for HPLMN use should be supported.g. This is not the intention as it creates too much overhead. This problem can be avoided when introducing completely new services. the message is forwarded to the HPLMN and further to the IN system where the account balance is checked and finally the current value is transferred to the user in a short answer string. e. if USSD are intended for HPLMN or VPLMN use. One variant could be that the UE when being attached via the EPS to the IMS encapsulates the USSD codes in IP messages and forwards them to the network. to activate or deactivate certain features or to interrogate some parameter settings. in the format “*<feature code># <SEND>”.g. conversion. Interdigital.g. The prepaid user e.g.17 Overview of 3GPP Release 11 V0.g. e. this code is forwarded to the home network and answered with a text string providing the requested information. However we are talking about existing services with a broad customer base that is accustomed to use USSD codes as they are fast and simple to use. Proposal To specify an easy solution having no architectural impact. Telecom Italia.g.C1. using the Ut) and have some architectural impact (considering all possible roaming scenarios for the IMS).40". e. The idea is to specify a light weight solution which provides the same look and feel for the user but uses existing network mechanisms. Specify a "CS domain USSD" like service over IMS (see GSM Mobile User Initiated USSD) TSs_and_TRs 22. The differentiation. Possible solutions There are several possibilities to solve this issue. i. Further handling of messages (e. The user dials a certain feature code. only to simulate the USSD service. onward routing. Specify a "CS domain USSD"-like service over IMS (see GSM Mobile User Initiated USSD). A typical use case is the interrogation of the account balance in a prepaid service. "Balance: € 35. Unlike common SMS the string is displayed immediately and not stored on the UE.g.C3 S1 C1.173 Supporting Companies: 3 Justification Deutsche Telekom. Dependent on the access he would have to use different mechanisms for controlling the active UE. Then mechanisms can be used that are available via all access networks.e.C3 WI_rapporteur Deutsche Telekom Deutsche Telekom Deutsche Telekom Name Unstructured Supplementary Service Data (USSD) simulation service in IMS Stage 1 Stage 3 UID 48013 1 Name Stage 1 Resource S1 Finish 10/06/201 0 Hyperlink SP100408 Notes SP#48 completed. data base interrogation) is out of scope of the specifications. web interfaces via GPRS or EPS. If USSD for VPLMN use were to be supported / simulated this may prevent certain solutions (e. it can be implemented with the MMTel UE client and USSD messages are sent to and answered by the MMTel AS. So e. Resources: UID 480031 480131 520003 S1. It should be noted that there are also user initiated MMI mode USSDs for VPLMN use. 0 – 14 May 2010) Today mobile initiated unstructured SS data in MMI mode are widely used to interact with proprietary home-network provided services. a business customer who is subscribed to a certain multi SIM service will use his UEs via CS and EPS/IMS. Problem statement The mentioned functionality is not available in the EPS. Another use case is controlling the active UE for incoming calls and messages in case of a hunting service / multi SIM service.C1. One would be to re-introduce USSD in EPS. Huawei.

UID 52000 3 52010 3 52020 3 Name Stage 3 CT1 part of Stage 3 CT3 part of Stage 3 Resource C1. Objective: to specify service requirements for the provision of USSD-like service over IMS.18 Overview of 3GPP Release 11 V0.090. Service Aspects: MMI-Aspects: It is expected that the same user experience as for the CS USSD service is preserved. MMI & Charging Aspects. the look and feel of the service is independent of the transport mechanism used to convey the USSD payload to the network).173. Applicable to UE and AS which are intended to support user configuration of supplementary services. like the well known "GSM Mobile User Initiated USSD" feature. operators would benefit from re-using the already deployed servers also when the user accesses services that make use of USSD over IMS. It is therefore desirable to create in 3GPP a service which provides the same capabilities for the user. MMI-mode USSD is for the transparent transport of MMI strings entered by the user to the Application Server (AS) and for the transparent transport of text strings back to the User Equipment (UE) to be displayed for user information.390 29. Charging Aspects: No additional requirements compared to the CS USSD service are foreseen.e. 24. 3GPP . It is expected that the same user experience as for the CS USSD service is preserved. For the user. Add USSD to SA5 MultiMedia Telephony charging.229.C3 C1 C3 Finish 07/09/201 2 07/09/201 2 07/09/201 2 Comp 43% 85% 0% Hyperlink CP110534 CP110534 CP110534 Notes No stage 2 impact. as reuse existing IMS architecture in TS 23. It is expected that the same user experience as for CS USSD service is preserved on Service.390 for Information CP#56 completion 03/12=>09/12 TSs_and_TRs 24.1. Objective : to specify the stage 3 for the MMI-mode USSD service using the IMS multimedia telephony communication service. Therefore Multimedia Telephony Service shall provide a consistent service experience to the user using Unstructured Supplementary Service Data (USSD) in MMI-mode according to TS 22.165 As USSD is widely used in the CS domain it is expected that operators will benefit from being able to re-use the already deployed servers also when the user attempts to access services that make use of USSD over IMS.173 and 3GPP TS 22. it is important that the user experience is transparent (I.228 CP#56 TS 24.090. based on the stage 1 requirements in 3GPP TS 22. new TS 24.1 (2012-06) As USSD is widely used in CS domain.

NTT DoCoMo. moves between H(e)NBs in an enterprise/residential environment Service continuity of IP data session(s) when a UE.4 SIPTO Service Continuity of IP Data Session (SIPTO_SC) UID_490030 Resources: UID 490030 490130 S1 Name SIPTO Service Continuity of IP Data Session Stage 1 Acronym SIPTO_SC SIPTO_SC Resource S1 S1 WI_rapporteur Vodafone Vodafone UID 49003 0 49013 0 Name SIPTO Service Continuity of IP Data Session Stage 1 Finish 21/09/201 1 21/09/201 1 Hyperlink SP100589 SP100589 Notes Linked to Rel-10 Local IP Access and Selected Internet IP Traffic Offload (LIPA_SIPTO) SP#53 completed TSs_and_TRs Stage 1 22.19 Overview of 3GPP Release 11 V0. Cisco In Rel-10. BT. whose data is offloaded.220 Supporting Companies: Justification Verizon Wireless. 3GPP has specified requirements for the support of Selected IP Traffic Offload (SIPTO) from the macro network and from H(e)NB subsystems in an enterprise/residential environment (subsequently called a H(e)NB-involved network). as well as improving the user experience. However.1. moves between (e)NBs in the macro network Service continuity of IP data session(s) when a UE. whose data is offloaded.101. Alcatel-Lucent. whose data is offloaded. 22.1 (2012-06) 4. moves between the macro-network and H(e)NB sub-system in an enterprise/residential environment Charging Aspects: addressed Security Aspects: addressed 3GPP . China Mobile. Objective: to specify requirements for the following scenarios: Service continuity of IP data session(s) when a UE. requirements related to the service continuity of existing IP data sessions during mobility events in the macro network when SIPTO is used and also between macro-network and H(e)NB-involved network have not been provided in detail. Vodafone. The current work item aims to review use cases and develop requirements for a system that will enable the mobile operators to provide services in a more effective manner.

296 Justification Currently.115. the subscriber could be given the opportunity to purchase additional credit that increases the spending limit. Huawei Huawei Name QoS Control Based on Subscriber Spending Limits Stage 1 Stage 2 Charging (Stage 2) CT3 aspects (Stage 3) Supporting Companies: Vodafone. This allows the operator to have an additional means of shaping the subscriber’s traffic in order to avoid subscribers monopolising the network resource at any one time. KDDI UID 49003 1 Name QoS Control Based on Subscriber Spending Limits Stage 1 Resource S1. China Unicom.C3 Resource S1. Telcordia. Openet. negotiation of QoS at session setup. it needs to be possible to provide support for roaming subscribers without impact on the visited network. To provide use cases and service requirements that allow: • • Modification of QoS based on subscriber’s spending limits Enforcing of spending limits for roaming subscribers without impact on the visited network The work item is expected to create CRs to TS 22. 32. the QoS of a subscriber’s session could be modified when this spending level is reached. NTT DoCoMo. SA2 Stage 2 objectives: The objective is to update the normative specifications with regard to functionality and interfaces for supporting modification of QoS and gating control based on subscriber’s spending limits. Upon triggers based on the operator’s charging models. etc.S5.S2. Use cases & service requirements to allow: 1) modification of QoS based on subscriber’s spending limits 2) enforcing of spending limits for roaming subscribers without having dedicated support in the visited network SP#53 completed SP#56 completed 22.115 as well as solution outlined in TR 23.813. .C 3 Finish 20/06/201 2 Hyperlink SP110519 Notes TSG#56 completed TSs_and_TRs - 49013 1 S1 21/09/201 1 SP110519 51004 3 50002 9 Stage 2 Charging (Stage 2) S2 S5 21/09/201 1 20/06/201 2 SP110519 SP110519 SP#53 completed. a mobile operator has several means to control subscribers’ usage of the network resources.S5.S2. key issue 3 and will include the following: • Procedures between the OCS and PCRF to allow the PCRF to adapt the QoS of a service according to spending status for the user 3GPP .S5. Objective Stage 1 objectives.1 (2012-06) 4.240. Tekelec. ZTE. However. China Mobile. but the purchasing action may have an impact on the QoS of a subscriber’s session. a mobile operator needs to have a much finer granularity of control of the subscribers’ usage of the network resources by linking the subscribers’ session QoS with a spending limit. Verizon Wireless. Huawei. Telecom Italia.115 23. AT&T.C3 S1 S2 S5 C3 WI_rapporteur Vodafone Vodafone Huawei Nokia Siemens Networks.5 QoS Control Based on Subscriber Spending Limits (QoS_SSL) UID_490031 Resources: UID 490031 490131 510043 500029 520004 S1. Nokia Siemens Networks. It would be useful if. in addition. Since support for roaming scenarios is needed.S2. Ericsson. Alcatel-Lucent.203 32. NEC. such as admission control policies.20 Overview of 3GPP Release 11 V0. This gives the operator the ability to deny a subscriber access to particular services if the subscriber has reached his allocated spending limit within a certain time period. The solution will be provided per requirements identified in TS 22. The way such purchase is carried out is out of the scope of this feature. Allot Communications.1.

212. It would be useful if. which supports the following functions: Request of charging status reporting from PCRF to OCS. SA5 Stage 2 objectives: • Provide stage 2 specification for the requirements identified in TS 22. TS 29. Upon triggers based on the operator’s charging models.115. the subscriber could be given the opportunity to purchase additional credit that increases the spending limit.203. The following stage 3 aspects have to be specified within this WI: • • • Define the Sy reference in the architecture in TS 29. in addition.21 Overview of 3GPP Release 11 V0.213.g. Notification of policy counter status change from OCS to PCRF. Objective: to specify Stage 3 aspects of QoS Control Based on Subscriber Spending Limits according to TS 23. The work item is expected to create CRs to TS 23.296 for the modification of the OCS architecture and logical function definition for spending limit control SA5 TS 32. o o o Service Aspects This work item aims to provide the operator a means to control access to certain services and QoS of data sessions based on a subscriber’s spending limits.215 Update the PCRF functionality to include Sy related procedure (e. but the purchasing action may have an impact on the QoS of a subscriber’s session. -Cancellation of charging status reporting from PCRF to OCS.214 and TS 29.219 SA5 TS 32.203. UID 52000 4 Name CT3 aspects (Stage 3) Resource C3 Finish 15/06/201 2 Hyperlink CP120203 Notes CP#56 completed TSs_and_TRs 29.214.212. Coordinate with SA5 which defines the charging requirements • - Charging Aspects: 3GPP . the QoS of a subscriber’s session could be modified when this spending level is reached. 29. 29. The way such purchase is carried out is out of the scope of this feature.1 (2012-06) • Information flows between OCS and PCRF. This allows the operator to have an additional means of shaping the subscriber’s traffic in order to avoid subscribers monopolising the network resource at any one time. it needs to be possible to provide support for roaming subscribers without impact on the visited network. Since support for roaming scenarios is needed.213 Adding Sy interface between PCRF and OCS.240 for charging document umbrella SA5 TS 32.299 for potential impact on Diameter application description Justification A mobile operator needs to have a much finer granularity of control of the subscribers’ usage of the network resources by linking the subscribers’ session QoS with a spending limit. new TS 29. This gives the operator the ability to deny a subscriber access to particular services if the subscriber has reached his allocated spending limit within a certain time period.215. Describe the Sy related interactions with the PCRF procedures in TS 29.1. policy decision basing on the Sy input). 29.

g.6 Optimized Service Charging and Allocation of Resources in IMS whilst Roaming (OSCAR) UID_490032 Resources: UID 49003 2 49013 2 49023 2 49033 2 53002 1 S1.S2 Finish 07/03/201 2 Hyperlink SP110347 490132 490232 490332 S2 S1 S2 07/03/201 2 21/09/201 1 07/03/201 2 SP110347 SP110347 SP110347 Notes SP#55 completed (Stage 2/3 specified under CT1 Rel-11 Feature MRB (Inclusion of Media Resource Broker) UID_530021. These features include conferencing. However.Stage 2 Inclusion of Media Resource Broker (Stage 2/3) UID 490032 Name Optimized Service Charging and Allocation of Resources in IMS whilst Roaming TR on Stage 2 aspects Stage 1 Deleted .228 None Supporting Companies: Justification Vodafone.173. Ericsson. the media plane is typically re-directed back to the home network to perform these functions. the subscriber will also experience a cut-out of media whilst the re-direction is performed (if redirected mid-call e. for tone/announcement insertion). 22. SP#55 no normative work in SA2.S2 Acronym OSCAR OSCAR OSCAR OSCAR MRB Resource S1. For transcoding. Verizon Wireless The capability to allow media to be routed in an optimal manner between IMS operators when the subscriber is roaming was introduced in Rel-10.115 and evaluate the need to add new requirements to existing TS and/or new TS. GENBAND.173. tones insertion and announcement insertion.g. Deutsche Telekom.IETF WI_rapporteur Vodafone Vodafone Vodafone Vodafone AT&T Name Optimized Service Charging and Allocation of Resources in IMS whilst Roaming TR on Stage 2 aspects Stage 1 Deleted . 22. In these cases.115.22 Overview of 3GPP Release 11 V0.S2 S2 S1 S2 C1. Triggered by S1102236/GSMA RILTE 10_007r1 (IREG LS_038 to 3GPP on Optimal Media Routing drawbacks) SP#55 completed SP#53 completed SP#55 no normative work in SA2.1. Stage 2/3 to be done in under CT1 Rel-11 Feature MRB (Inclusion of Media Resource Broker) UID_530021 3GPP . This increases the risk of the call being cut-off (e. the media would have to stay routed through the home network for the duration of the call. In addition. if the redirect fails for some reason). for tone and announcement insertion. neither of these solutions is ideal from a subscriber's perspective as it potentially introduces delay between the call parties. transcoding. there is the possibility to temporarily re-direct the media plane though the home network only for the duration of the tone/announcement. 22. Unfortunately. Stage 2/3 to be done in under CT1 Rel-11 Feature MRB (Inclusion of Media Resource Broker) UID_530021 TSs_and_TRs - new TR 23.1 (2012-06) 4.Stage 2 Resource S1. However. certain features may require that the media is controlled by the home network. Objective Stage 1: to provide service requirements that allow a home network to control a visited network to perform the following functions for IMS: o o o o conferencing transcoding tone insertion announcement insertion Objective Stage 2: to provide stage 2 specification for the requirements identified in TS 22.849 22.

or by using a configuration option.23 Overview of 3GPP Release 11 V0. and the MRF and the MRB are part of the toolkit of providing those applications in a flexible manner.1. 4.165 draft-ietfmediactrl-mrb 29. and the interfaces associated with it. Applications in IMS are meant to be provided outside the requirements of standardisation. but this work is intended to be generic and not tied to any other specific work or study item. 29. Related Study Item or Feature (if any) UID Title 49003 Optimized Service Charging and Allocation of 2 Resources in IMS whilst Roaming (OSCAR) Nature of relationship Provides requirements for identifying MRB/MRF resources in a VPLMN at registration or session initiation. Additionally for interoperator scenarios. and the interfaces associated with it. for example. Ericsson. 3GPP . but the IETF work in the MEDIACTRL working group was insufficiently mature to document it. Objective to: 1.IETF C1 C1.1 (2012-06) Service Aspects: aims to improve IMS services for roaming users by allowing conferencing. There are a number of current work and study items (including OSCAR) that could use the MRF in a more flexible manner with the provision of the MRB.IETF C1 C1 C1-IETF WI_rapporteur AT&T AT&T AT&T Keith Drage UID 53002 1 53012 1 53022 1 53032 1 53100 5 56000 3 Name Inclusion of Media Resource Broker (Stage 2/3) Stage 2 Stage 3 CT1 part of Stage 3 (IETF) CT3 part of Stage 3 Resource C1.C3. transcoding and tone/announcement insertion to be performed by the visited network.229. 2.218.229.IETF Name Inclusion of Media Resource Broker (Stage 2/3) Stage 2 Stage 3 (IETF) Acronym MRB MRB MRB MRB Resource C1. Charging Aspects: Charging aspects when media is routed in an optimal manner for a roaming subscriber will be considered as part of the RAVEL work item.1 Inclusion of Media Resource Broker (Stage 2/3) (MRB) UID_530021 Resources: UID 530021 530121 530221 531005 C1. the MRB was identified as a useful function within the IMS architecture. Interdigital.218 24. Provide a stage 2 specification in 3GPP TS 23.C3. Telcordia MRB provides additional flexibility in delivering MRF resources in the same manner already provided in Rel-5 Stage 1.165 Supporting Companies: Alcatel-Lucent. Liaise with appropriate SA working groups to update their documentation appropriately. AT&T. specify procedures for MRB/MRF discovery for OSCAR scenarios based on information provided from the visited network to the home network at registration or session establishment.IETF C1 C1-IETF C3 Finish 07/09/201 2 07/09/201 2 07/09/201 2 07/09/201 2 07/09/201 2 07/09/201 2 59% 90% 45% 50% 50% 0% Hyperlink CP-120277 CP-120277 CP-120277 CP-120277 CP-120277 CP-120277 Notes Stage 1 and TR on Stage 2 in Rel-11 Feature OSCAR UID_490032 CP#56 completion 06/12=>09/12 CP#56 completion 06/12=>09/12 Not completed internet-draft CP#56 updated WID CP110642=>C1-121669 (added CT3 part) TSs_and_TRs Stage 2/3 23. It is therefore proposed to revise the IMS specifications to include this functionality. 3. Justification In work item MRFC and MRFC-TS undertaken in the Rel-8. the current work in IETF internet-draft draft-ietf-mediactrl-mrb.6. Provide a stage 3 specification in 3GPP TS 24. That work has now matured in. It is intended that the MRB may also be used in interoperator scenarios. identifying the MRB as a new functional entity.

1.24 Overview of 3GPP Release 11 V0. Security Aspects: will be handled by TSG SA in their own appropriate work items.1 (2012-06) Charging Aspects: will be handled by TSG SA in their own appropriate work items. 3GPP .

T-Mobile US Triggered by SA1 Rel-11 TR 22. and support of any specific media by an originating network or UE may be subject to regulatory requirements. Functionality includes: • • • • • Media types to be supported are specified in TS 22. in a manner similar to IMS emergency voice sessions. 23. 23. Qualcomm.203. ZTE. Alcatel Lucent.060.871 has identified use cases and potential requirements for session based non-voice-initiated emergency service requests and recommends that these requirements are included in TS22. TR22.101.1. The originating network delivers all media to the same IP PSAP throughout the duration of the IMS emergency call.101.167. TCS. Adding. An originating network or UE may support some or all of these other media types. MMI-Aspects: Charging Aspects: Security Aspects: UID 53004 5 included in NOVES device requirements will be determined by regional regulatory requirements included in NOVES device requirements Acronym NOVESIMSESOM Resource S2 Finish 07/03/201 2 Hyperlink SP110644 Notes SP#55 completed TSs_and_TRs 23. Research in Motion.S2 Acronym NOVES NOVES NOVESIMSESOM Resource S1.25 Overview of 3GPP Release 11 V0.7 Non Voice Emergency Services (NOVES) UID_500030 Resources: UID 50003 0 50013 0 53004 5 S1. In addition. IMS emergency sessions with other media support providing location of the UE. removing and modifying individual media to/from an IMS emergency session is allowed.101 Rel-11: End-to-End General Requirements (normative) NOVES Device Requirements (normative) IMS Network Requirements (normative) Emergency Services IP Network Requirements (informative) NOVES will be based on IMS. Objective: enhance “Support for IMS Emergency Calls over GPRS and EPS” (IMS_EMER_GPRS_EPS) capabilities on UTRAN and E-UTRAN to allow other media types during an IMS emergency session when the network supports IMS voice emergency calls and the UE also supports other media types.871 Study on Non Voice Emergency Services (FS_NOVES) Justification: The NOVES study.101 has identified requirements for session based IMS emergency sessions that allow the UE to use other media and communication types than voice and GTT during an IMS emergency session when the network supports IMS voice emergency calls and the UE also supports other media or communication types.S2 S1 S2 WI_rapporteur Qualcomm Qualcomm Alcatel-Lucent Name Non Voice Emergency Services Stage 1 Stage 2 (Support of IMS Emergency Sessions with Other Media on UTRAN and E-UTRAN) UID 500130 Name Stage 1 Acronym NOVES Resource S1 Finish 21/09/2011 Hyperlink SP-100884 WI_rapporteur Qualcomm Notes SP#53 completed TSs_and_TRs 22. Objective: Include requirements into TS22. Support of NOVES may be subject to regional regulatory requirements. Charging Aspects: enhancements to be considered by SA5 Security Aspects: analysis to be undertaken by SA3 3GPP .1 (2012-06) 4. 23.401 Name Stage 2 (Support of IMS Emergency Sessions with Other Media on UTRAN and E-UTRAN) Justification: NOVES Stage 1 in TS 22. network support for individual NOVES features will be subject to the existence of regional regulatory requirements.101 Supporting Companies: AT&T.

228. conferencing.809 Study on Support for 3GPP Voice Interworking with Enterprise IP-PBX (FS_VINE) UID_480033 Justification There is interest among operators to support Interworking between 3GPP networks and Enterprise environments to provide enterprise voice services via UEs.g. The Technical Report also proposed requirements for input into TS 22. management and operation of interworking with IP-PBX services Mobile operator control of availability of IP-PBX services to UEs Continuity when an IMS session is transferred between UEs and IP-PBX devices 5 Service Aspects The following services aspects will be covered in this Work Item:    Mobile operator IMS services Enterprise specific value-added services (e. transfer of sessions to a softphone on a PC. " 3GPP . Alcatel-Lucent.229 Justification The justification for the parent feature was: "There is interest among operators to support Interworking between 3GPP networks and Enterprise environments to provide enterprise voice services via UEs. UID 530010 530110 Name Stage 2 Stage 3 Acronym VINE-CT1 VINE-CT1 Resource C1 C1 Finish 07/09/2012 07/09/2012 Comp 50% 0% Hyperlink CP-110641 CP-110641 TSs_and_TRs 23. Cisco.1. "short code dialling". The study item concluded that the various use cases are valid and within 3GPP scope. Tatara Systems.C1 S1 C1 C1 WI_rapporteur Tatara Systems Tatara Systems Alcatel-Lucent Alcatel-Lucent Name Support for 3GPP Voice Interworking with Enterprise IP-PBX Stage 1 Stage 2 Stage 3 UID 510147 Name Stage 1 Acronym VINE Resource S1 Finish 21/09/2011 Hyperlink SP-110176 Notes SP#53 completed TSs_and_TRs 22. The Technical Report also proposed requirements for input into TS 22. Nokia Triggered by Rel-11 TR 22. etc) Interaction between services provided by the mobile operator and services provided by the enterprise 7 Charging Aspects Charging requirements for enterprise services provided to UEs will be considered.8 Support for 3GPP Voice Interworking with Enterprise IP-PBX (VINE) UID_510047 Resources: UID 510047 510147 530010 530110 S1.26 Overview of 3GPP Release 11 V0. Objective: to provide requirements for the following aspects of 3GPP voice interworking with Enterprise IP-PBX:  Support for IMS voice services interworking with IP-PBX services while at the same time maintaining full operator visibility and operator control of the related voice service signalling in the mobile operator’s core network    Mobile operator control of security.228.218 24.1 (2012-06) 4.C1 Acronym VINE VINE VINE-CT1 VINE-CT1 Resource S1. The study item concluded that the various use cases are valid and within 3GPP scope. Vodafone. RIM. Ericsson.228 Supporting Companies: Siemens Networks Verizon Wireless.

It is understood the subscription set of the UEs involved in VINE will be managed on the HSS of the PLMN and therefore there are no changes to HSS involved.218 which is owned by CT. and 3GPP SA5 on charging issues prior to initiating the stage 3 work. 4 Objective As defined for the parent feature "This work item aims to provide requirements for the following aspects of 3GPP voice interworking with Enterprise IPPBX:  Support for IMS voice services interworking with IP-PBX services while at the same time maintaining full operator visibility and operator control of the related voice service signalling in the mobile operator’s core network    Mobile operator control of security. 3GPP . The detailed stage 2 work is 3GPP TS 23. Huawei Triggered by Rel-11 TR 22. Input will be needed to discussions to occur in 3GPP SA3 on security issues.115.228 and corresponding enhancements are now needed at stage 2 and stage 3. China Mobile. Charging Aspects: Input needed to discussions to occur in SA5 on charging issues prior to initiating the stage 3 work. any architectural changes will also need to be documented in SA2 architectural overview documentation. 4. and is therefore included in this WID. Nokia Siemens Networks.228 Name IMS NetworkIndependent Public User Identities Stage 1 Supporting Companies: Vodafone. ZTE. Additionally.27 Overview of 3GPP Release 11 V0.x IMS Network-Independent Public User Identities (INIPUI) UID_520027 (moved to Rel-12) Resources: UID 520027 520127 S1 Hyperlink SP110381 SP110381 WI_rapporteur Vodafone Vodafone Notes SP#53 Stage 1 completed. Alcatel-Lucent.1.894 Study of IMS Network-Independent Public User Identities (FS_INIPUI) UID_490033 SP#53 completed TSs_and_TRs Stage 1 22.1 (2012-06) Those changes have now been made to 3GPP TS 22. 22. AT&T. This WID will not define the functionality of the PBX. management and operation of interworking with IP-PBX services Mobile operator control of availability of IP-PBX services to UEs Continuity when an IMS session is transferred between UEs and IP-PBX devices" The objective is the detailed stage 2 and stage 3 work for the above. It is assumed that such work in those other groups will be dealt with in the appropriate SA work item. Security Aspects: Input needed to discussions to occur in SA3 on security issues prior to initiating the stage 3 work. although will define the interface connecting the PBX to the public network. Triggered by Rel-11 TR 22. Ericsson.894 Study of IMS Network-Independent Public User Identities (FS_INIPUI) UID_490033. Telefónica.

23.interactions between ACR and other supplementary services such as CLI. 22. e. ACR in the CS CN allows the subscription to trigger the network to reject incoming anonymous calls early in the call establishment and therefore optimise the handling of network resources. 22.088 CR#0003. or to allow the calling party to successfully establish a new call by authorising its CLI to be presented to the terminating party. ZTE.088.088 Supporting Companies: Vodafone.082. This also enables to provide the calling party with an indication of why the call was rejected. UID 53001 1 53011 1 53021 1 Name Core Network aspects CT4 part (Stage 2/3) CT3 part (Stage 3) Resource C4.C3 WI_rapporteur Alcatel-Lucent Alcatel-Lucent Alcatel-Lucent UID 52012 8 Name Stage 1 Resource S1 Hyperlink SP110421 Notes SP#52 completed under TEI11.C3 Name Anonymous Call Rejection in the CS domain Stage 1 Core Network aspects Acronym ACR_CS ACR_CS ACR_CS-CN Resource S1. Approved WID and CRs in SP-110376 (22. Ericsson. .C3 S1 C4.011 29.g. 3GPP TS 24.018.081. with the benefits to avoid repeated call attempts with CLI presentation still restricted.082 CR#0005.205. via a specific announcement.C3 C4 C3 Finish 02/12/201 1 02/12/201 1 16/09/201 1 Hyperlink CP-110587 CP-110587 CP-110587 Notes CP#54 completed CP#54 completed CP#53 completed TSs_and_TRs Stage 2/3 23.1 (2012-06) 4.082.C4.it is not foreseen to specify a new SS-code for ACR.080).g. or to allow the calling party to successfully establish a new call by authorising its CLI to be presented to the terminating party. 22. 29.004. 23. Objective : to specify stage 2 and stage 3 requirements to support the new ACR in the CS domain service requirements and describe interactions between ACR and other supplementary services.procedures in the GMSC to release the call in case of ACR and return specific indication to the calling party e. 23. with the benefits to avoid repeated call attempts with CLI presentation still restricted. This also enables to provide the calling party with an indication of why the call was rejected.231. announcement and/or specific cause code when releasing the call. Objective: to specify stage 1 to support the new ACR in the CS domain service requirements and describe interactions between ACR and other supplementary services. 23. Telefónica. 23. e. 22. 29.163. 22.081 CR#0007.292 3 Justification SA1 has define new service requirements introducing support of the Anonymous Call Rejection supplementary service in the CS domain.004 CR#0013) TSs_and_TRs 22.C4.088. 23. It is intended to minimize protocol changes when carrying out this work: .e.9 Anonymous Call Rejection in the CS domain (ACR_CS) UID_520028 Resources: UID 520028 520128 530011 S1. 22. 22.28 Overview of 3GPP Release 11 V0. China Mobile.085 CR#0004. AT&T.081. 24. Alcatel-Lucent. .it is not foreseen to modify the mobile radio interface layer 3 for supplementary services (i. . This will cover the following aspects in particular: . 29. via a specific announcement. 3GPP .085. Huawei Justification SA1 defined new service requirements introducing support of the Anonymous Call Rejection supplementary service in the CS domain. ACR in the CS CN allows the subscription to trigger the network to reject incoming anonymous calls early in the call establishment and therefore optimise the handling of network resources.085.g. Nokia Siemens Networks.1.updates to the MAP SRI procedure to support ACR. 22.002.

1.1 (2012-06) - USSD is expected to be used to activate and deactivate the ACR supplementary service.29 Overview of 3GPP Release 11 V0. 3GPP .

C3.C4 S2.C3.C1.1.S5.R3 S2.C1.C3 S2.C4.C1 S2.C4.C1 S2.C4 S2.C3.S1.C4 S2.G2.IETF S2.R2.C3 WI_rapporteur Ericsson NTT DoCoMo Samsung T-Mobile Allot Communications Qualcomm Qualcomm ZTE Orange ZTE Deutsche Telekom 3GPP .C3.30 Overview of 3GPP Release 11 V0.C4.C1.C3.C1.IETF S2 S2.C4.1 (2012-06) 5 SA2 Features UID 46002 6 48003 5 50002 6 48003 8 50003 2 50003 3 51004 8 51005 0 53000 1 53004 6 54002 9 Name Support for BroadBand Forum Accesses Interworking Single Radio Voice Call Continuity (SRVCC) aspect of enhancements for Multimedia Priority Service Single Radio Video Call Continuity for 3G-CS Network Provided Location Information for IMS (NETLOC) Service Awareness and Privacy Policies VPLMN Autonomous CSG Roaming Data Identification in Access Network Discovery and Selection Function (ANDSF) LOcation-Based Selection of gaTEways foR WLAN Single Radio Voice Call Continuity from UTRAN/GERAN to E-UTRAN/HSPA S2a Mobility based On GTP and WLAN access to EPC Roaming Architecture for Voice over IMS with Local Breakout Acronym BBAI eMPS_SRVCC vSRVCC NWK-PL2IMS SAPP VCSG DIDA LOBSTER rSRVCC SaMOG_WLAN RAVEL Resource S2.S1.S5.C1.S1.

This high level requirement is likely to uncover additional detailed requirements to support technology and business models used by fixed access providers.C4.139 no internet-draft available yet 22. Alcatel-Lucent.203. BT. ZTE.1 (2012-06) 5.203. Provide service requirements for supporting interworking between 3GPP EPS and the fixed broadband accesses defined by BBF SP#56 updated WID SP110647=>SP-120382 (TR 23.278 Supporting Companies: Verizon Wireless. Ericsson.401.402.278 CR#0058 47002 2 TR on Stage 2 S2 20/06/201 2 SP-120419 new TR 23. Further work with the original as well as additional use cases for interworking with both 3GPP accesses and 3GPP Core Network are underway in BBF.839 v140 for Information SP#56 completed Public address for NAT-traversal for new TS 23. Orange.278 clause 7. Cisco. Motorola. AT&T. Nokia Siemens. 3GPP .1 Support BroadBand Forum Accesses Interworking (BBAI) UID_460026 Resources: S2. Annex A. China Mobile.31 Overview of 3GPP Release 11 V0. Qualcomm. There is already an overall requirement in TS 22.1. TeliaSonera.C4 S1 WI_rapporteur Ericsson Ericsson Ericsson Ericsson ZTE Ericsson Ericsson Ericsson Ericsson Huawei SA part fo BBAI UID 46012 6 Name Stage 1 BB I Resource S1 Finish 25/03/201 0 Hyperlink SP-120419 Notes SP#47 completed.IETF BB Building Block BBF BroadBand Forum UID 46002 6 46012 6 47002 2 47002 3 54100 1 53001 2 49002 6 47002 4 53001 3 49002 7 Name Support for BroadBand Forum Accesses Interworking Stage 1 BB I: BBF interworking with home routed traffic for WLAN and H(e)NB TR on Stage 2 for BBAI Stage 2 BB I (IETF) Stage 2 BB I Stage 3 BB I .Core Network impacts Stage 1 BB II: BBF interworking with offload in access network for WLAN and for H(e)NB Stage 2 BB II Stage 3 BB II .139 SP#53 completed SP#56 completed SP#53 completed TSs_and_TRs 22. SP#54 TR 23.C3.278 23.839 not Approved in Rel-11.Core Network impacts Stage 1 BB III: BBF convergence and network based mobility Acronym BBAI BBAI BBAI BBAI BBAI BBAI_BBI-CT BBAI BBAI BBAI_BBII-CT BBAI Resource S1 S2 S2 S2-IETF C1.C3.C4 S1 S2 C3.C1.3 to support fixed accesses.139 22. LG Electronics The collaboration between 3GPP and BBF started end of summer 2008 with an LS dialogue between BBF and TSG SA. 23. 23. Fujitsu. moved to Rel-12 Feature P4C).S1. new 23. Deutsche Telekom.C1. Telecom Italia. Juniper.2 (CR#0058) as asked by SA in LS (SP-080650/S1-083175) and forwarded them to BBF in LS S1-084364. Huawei. NEC.839 47002 3 54100 1 49002 6 47002 4 49002 7 Stage 2 BB I (IETF) Stage 2 BB I Stage 1 BB II Stage 2 BB II Stage 1 BB III S2 S2-IETF S1 S2 S1 20/06/201 2 19/09/201 2 21/09/201 1 20/06/201 2 21/09/201 1 SP-120419 S2-114484 SP-120419 SP-120419 SP-120419 23. 23.278. SA1 then captured some use cases in TS 22.1.

on top of Rel-10 baseline architecture. Cooperation and technical exchanges between 3GPP and BBF moved beyond specification for interworking to the support of BBF use cases for policies/QoS management. WT-203 serves as one basis for 3GPP Stage-1.839 covers the architectural agreements. Each BB can come to conclusions independently regarding normative work. Stage-2 work described in this WID will be based on 3GPP Stage-1 TS or CR(s) TS 22. including identities. authentication and charging. TR 23. The basis for the work is a set of requirements documented in BBF WT-203 and Broadband Policy Control Framework documented in WT-134. security and OA&M. Changes expected to H(e)NB subsystem – broadband network QoS interworking. As a result of the Workshop. WT-134 serves as one basis for 3GPP work. This work provides detailed service requirements for supporting interworking between the 3GPP EPS and the fixed broadband accesses as defined by BBF. SA5 and CT WGs. Policy and QoS interworking between 3GPP and BBF architectures considering the following scenarios:  When H(e)NB is being used and traffic is routed back to the EPC  When WLAN is being used and traffic is routed back to the EPC Multi-access PDN Connectivity. The BBII (building on interworking functionality of BBI) will cover the stage 1 and the stage 2 aspects related to: − Policy and QoS interworking between 3GPP and BBF architectures considering the following scenario: 3GPP . This includes the area treated in BBF WT-134. architecture.1. it has been identified that several working groups in 3GPP will need to work on: requirements. − IP Flow Mobility and seamless WLAN offloading. and the TR will follow this structure of the work. No change to radio interface expected. stage 2 procedures and open topics between 3GPP and BBF. Stage-2 work described in this WID will be based on 3GPP Stage-1. Objective: work for supporting BBF Access will be conducted in separate Building Blocks (BBs). This SA1work should clarify the work to be done in 3GPP by SA2.220 Other source of stage 1 information Clause Remarks Stage 1 H(e)NB and LIPA_SIPTO requirements Justification The collaborative work between 3GPP and BBF has resulted in a Workshop focusing on Fixed-Mobile Convergence. the following stage 2 aspects will be covered in BBI: − − − − Aspects on basic connectivity.32 Overview of 3GPP Release 11 V0. This Work Item aims to identify the topics that need to be addressed in 3GPP. Unique ID EHNB eANDSF IMS_EMER_GPRS_EPS EHNBF IFOM MAPCON Related Study Item or Feature (if any) Title Enhanced Home NodeB / eNodeB Access Network Discovery and Selection Enhancement Support for IMS Emergency Calls over GPRS and EPS H(e)NB enhancements IP Flow Mobility and seamless WLAN offload Multi Access PDN Connectivity Nature of relationship Building Block I Building Block I and II Building Block I and II BBII Building Block I Building Block I Stage 1 Organization BBF BBF Document WT-203 WT-134 Source of external requirements (if any) Remarks Initial work based on draft versions of WT-203. and network-based mobility for untrusted accesses (S2b) on top of Rel-10 baseline architecture including network discovery/selection functions and IP address allocation. Interworking between 3GPP and BBF architectures for authentication. SA3. IP Flow Mobility and seamless WLAN offload (IFOM) and Inter-UE Transfer (IUT) may have requirements for interworking with fixed broadband accesses. Based on stage 1. Local IP Access (LIPA) to residential/corporate local networks.1 (2012-06) New features in 3GPP such as H(e)NB. host-based mobility (S2c). Selected IP Traffic Offload (SIPTO) for H(e)NB. Stage 2 will be studied based on stage 1 normative specifications and the results of the 3GPP-BBF FMC collaboration.

008.e. host-based mobility (S2c). TR 29.When WLAN is being used and traffic is routed back to the EPC Multi-access PDN Connectivity. Main input for stage 3 work in CT3 is a new normative annex in TS 23. on top of Release 10 baseline architecture.139 and TS 23.839 draft-so-ipsecmeikev2-cpext 24. Each BB can come to conclusions independently based on Stage 2 work completion for each BB. The work on the BBF access interworking feature will be conducted in three BBs.139 C1 C3 C4 60% 90% 75% Justification: Specify Stage 3 to support BBF access as specified in TS 23.33 Overview of 3GPP Release 11 V0. IP flow Mobility and seamless WLAN offloading when a 3GPP UE connects to EPC using a BBF defined access network.203 for BBI.C4 C1 Finish 07/09/201 2 15/06/201 2 Comp 83% 100% Hyperlink CP120419 CP120419 Notes CP#56 updated WID CP-120195=> CP-120419 CP#56 completed. security aspects) CP#56 completed.1 (2012-06)  When WLAN is being used and traffic is offloaded in the local wireline network (i. and network-based mobility for untrusted accesses (S2b) on top of Rel-10 baseline architecture including network discovery/selection functions and IP address allocation.1. new TS 24.213.302 (on access authentication & authorization and tunnel management. including identities. Both UE and network impacts are expected. Main input for stage 3 work in CT1/4 is new normative text in TS 23. 29.C3. Charging Aspects: Security Aspects: It is assumed that BBF will carry out a study on the requirements for a BBF access to comply with the trusted and untrusted Non-3GPP access model defined in 3GPP TS 33.273. Objective: to define Stage 3 for supporting BBF Access network. o Note: For the offloading scenarios only WLAN offloading will be considered in this release.402 to describe Fixed access interworking with EPC.839 v100 for Information and Approval Draft removed from 3GPP documentation TSs_and_TRs Stage 3 new TR 24. 29.402 and TS 23. Policy and QoS interworking between 3GPP and BBF architectures considering the following scenarios: . 3GPP . Stage 2 concluded that existing TSs provide support for multi-access PDN connectivity.820 550005 551002 530212 530312 530412 TR on Stage 3 BB I f Deleted (IETF) on Stage 3 BB I CT1 part of Stage 3 BB I CT3 part of Stage 3 BB I: CT4 part of Stage 3 BB C4 C4-IETF 15/06/201 2 15/06/201 2 07/09/201 2 07/09/201 2 07/09/201 2 100% 100% CP120419 CP120419 CP120419 CP120419 CP120419 new TR 29.139.274. Based on stage 2 for BBI.212. TR 24.When H(e)NB is being used and traffic is routed back to the EPC .820 v100 for Information and Approval. non-seamless WLAN offloading) The BBIII (building on overall results of BBI) will define the Stage 1 related to:: − Converged policy management and charging for the scenarios with traffic routed to EPC and offloaded at the BBF access network for operators providing both 3GPP and BBF accesses. 29.402. will be added later. IP mobility mode selection. IP Flow Mobility and seamless WLAN offloading. new TS 29.229. TS 23. UID 530012 530112 Name Stage 3 BB I TR on Stage 3 BB I Resource C1. as defined for BBI.139 29. Identify additional FMC specific procedures in addition to those in 24. Interworking between 3GPP and BBF architectures for authentication.203 to describe Fixed access interworking with EPC.215 23. 29. the following stage 3 aspects will be covered: Aspects on basic connectivity.

as defined for BBII.320 29.203. 29. TR 24. Gxx and S9 interfaces considering the following scenarios:  When WLAN is being used and traffic is offloaded in the local wireline network (i. Based on stage 2 requirements for BBII.139.139 and TS 23.273 Justification: Specify Stage 3 to support BBF as specified in TS 23.1 (2012-06) UID 53001 3 53011 3 53021 3 53031 3 53041 3 Name Stage 3 BB II TR on Stage 3 BB II CT1 part of Stage 3 BB II CT3 part of Stage 3 BB II CT4 part of Stage 3 BB II Resource C3. the following stage 3 aspects will be covered: − Policy and QoS interworking between 3GPP and BBF architectures.820 v100 for Information and Approval. Main input for stage 3 work in CT1/4 is new normative text in TS 23. 3GPP . Main input for stage 3 work in CT3 is a new normative annex in TS 23.402 and TS 23. 29. This may be revised based on outcome of stage 2 work in TS 23.34 Overview of 3GPP Release 11 V0. - TSs_and_TRs Stage 3 24. non-seamless WLAN offloading) Both UE and network impacts are expected.820 new TS 24.215 23. TS 23.1. Objective: to define stage 3 for supporting BBF Access network. Each BB can come to conclusions independently based on Stage 2 work completion for each BB. The work on the BBF access interworking feature will be conducted in three BBs.203 for BBII. implemented by a new S9a reference point between PCRF and BPCF and including extension of Gx.008.139 and TS 23.203.213. 29.C1.C4 C1 C1 C3 C4 Finish 07/09/201 2 15/06/201 2 06/09/201 2 07/09/201 2 02/03/201 2 Comp 83% 100% 60% 85% 100% Hyperlink CP120420 CP120420 CP120420 CP120420 CP120420 Notes CP#56 updated WID CP120193=>CP-120420 CP#56 completed.e.212.402.

KDDI.2 SRVCC aspect of eMPS (eMPS_SRVCC) UID_480035 Resources: UID 48003 5 48013 5 48023 5 S2 WI_rapporteur NTT DoCoMo NTT DoCoMo NTT DoCoMo Name Single Radio Voice Call Continuity (SRVCC) aspect of enhancements for Multimedia Priority Service TR on SRVCC for eMPS Stage 2 on SRVCC for eMPS UID 480135 480235 Name TR on SRVCC for eMPS Stage 2 on SRVCC for eMPS Resource S2 S2 Finish 08/06/2011 14/12/2011 Hyperlink SP-110346 SP-110346 Notes SP#52 completed SP#54 completed TSs_and_TRs new TR 23. The following is excerpt from 23. 23. Qualcomm.237 Supporting Companies: NTT DoCoMo. specification work may be done. it is useful to forward priority indication of IMS based voice call over LTE with priority to Circuit Switch of GERAN/UTRAN or 1xCS so that the call can be forwarded to the Circuit Switch of GERAN/UTRAN or 1xCS with prioritized way compared to other normal IMS based voice call if Single Radio Voice Call Continuity (SRVCC) is performed. sessions shall continue to get priority treatment in the network during and after the handover). ST-Ericsson. A mechanism to properly handle SRVCC for an IMS based priority call established in LTE in order for the network to successfully hand over the call from LTE to CS in GERAN/UTRAN or 1xCS.9: "MPS shall be supported during and after the handover (i. Motorola Mobility.854 23. priority needs to be supported. Ericsson. then when the call is handed over from LTE to GERAN/UTRAN or 1xCS using SRVCC procedure. Justification Enhancements for Multimedia Priority Service (eMPS) has started to develop the priority treatment of IMS based multimedia services. 3GPP . Nokia Siemens Networks. priority call handling for SRVCC needs to be investigated and if necessary.35 Overview of 3GPP Release 11 V0.1 (2012-06) 5. depending on regulatory requirement in a region.. the procedure can be prioritized depending on regulatory requirements/operator policy even under network congestion situation. Priority handling of intra/inter MSC handover is out of scope of this WID.e.1.153 sub clause 5. Stage1 specification mentions that even during handover procedure. NTC.216. Service Aspects: When the user has on-going IMS voice call and the call is prioritized using eMPS. Therefore. Objective: to analyze and if needed specify mechanisms for the priority handling of SRVCC with regard to LTE/EPC. Sharp." Therefore.

203.C4 Acronym vSRVCC vSRVCC vSRVCC-CT Resource S2.886: • • Mid-call handling for more than one active/held video-call and/or voice-call at the same time Identification of correlation between voice and video bearers in the eNB if more than one active/held video-call and/or voice-call at the same time are allowed Services other than video-calls shall not be impacted. Objective: to complete Stage 2 in order to support single radio video call continuity from E-UTRAN to UTRAN-CS based on the architecture alternative & resolutions for the following outstanding issues identified in TR 23. Resource C1.C3.3 Single Radio Video Call Continuity for 3G-CS (vSRVCC) UID_500026 Resources: UID 500026 500126 520005 S2.213.203.008.886 "Feasibility Study of Single Radio Video Call Continuity" (FS_vSRVCC) studied Stage 2 system considerations in order to provide a solution for supporting single radio video call continuity from E-UTRAN to UTRAN-CS. 23. Rel-10 TR 23.216.36 Overview of 3GPP Release 11 V0. This needs to be supported as one of the key services for 3G-CS.215 29. 23. 29.1 (2012-06) 5. 24. Samsung. In Rel-8 and Rel-9 SRVCC. LTE and beyond.237. 29.C4 WI_rapporteur Samsung Samsung NEC Name Single Radio Video Call Continuity for 3G-CS Stage 2 CN aspects UID 50002 6 50012 6 Name Single Radio Video Call Continuity for 3GCS Stage 2 Finish 15/06/201 2 21/09/201 1 Hyperlink SP100704 SP100704 Notes CP#56 completed.216. The development of stage 3 specification work should be started. 24. This provides basic SRVCC for voice call. originated in E-UTRAN and the UE moves to UTRAN and continues the service over UTRAN in the CS domain. Provide Single Radio VIDEO Call Continuity from E-UTRAN to UTRAN-CS based on the agreed architecture alternative in TR 23.278 that “Service continuity at domain and RAT change for TS 11. CP#56 completed.212.C4 S2 C1. NEC.280 Service Aspects: UID 52000 5 52010 5 52020 5 52030 5 Name CN aspects of vSRVCC CT1 aspects CT3 aspects CT4 aspects Justification The stage 2 specification work for vSRVCC (video call handover from E-UTRAN to 3G-CS for service continuity) has been completed for Rel-11 by SA2. This WI proposes to carry out normative stage 3 work for video call handover as specified in 23. TS 12 and equivalent PS services” shall be supported.C3. LG Electronics.C4 C1 C3 C4 Finish 15/06/201 2 15/06/201 2 02/12/201 1 02/12/201 1 Hyperlink CP120278 CP120278 CP120278 CP120278 Notes Stage 3. and the mechanisms to resolve the key issues. the video call handover from E-UTRAN to 3G-CS for service continuity is not specified.C1. 29. The study was performed to the scenarios where IMS session using bidirectional voice and synchronised video such as defined in TS 22.C3.886 UID_470048 Study on Single Radio Video Call Continuity for 3G-CS (FS_vSRVCC) TSs_and_TRs - 23. KT.211. 23.173. Updated WID CP-110757=>CP-120278 CP#56 completed CP#54 completed CP#54 completed TSs_and_TRs 24.C3. Triggered by Feasibility Study on video call handover capability in TR 23. NTC Justification In Rel-8 SRVCC requirement. 23.1. 3GPP . It is also required that service shall be maintained during and following a change of network in either direction between a Rel-7 and earlier network and an Evolved Packet System. Conclusions have been reached on the Architecture alternative to provide Single Radio Video-call continuity. SA1 has specified in TS 22.301 29.237.237 Supporting Companies: NTT DoCoMo.C1.886 SP#53 completed.

3GPP . Additionally. − video bearers in signalling across Sv interface. A general objective is to have minimum disruption time for the ongoing video call in progress during this transfer. − vSRVCC specific indicators (separate from SRVCC related ones) in NAS signalling. One is the IMS/EPC aspects involving SCC AS and ensuring that the relevant information is passed to the EPC side regarding the video call to be transferred. − indication related to video bearer on Gx and Gxx interfaces. In more detail.37 Overview of 3GPP Release 11 V0.1 (2012-06) Objective: to define stage 3 for Single Radio video call continuity (vSRVCC) from E-UTRAN to UTRAN-CS for calls that are anchored in IMS (SCC AS) when the UE is capable of transmitting/receiving on only one of those access networks at a given time.1. The other is for PCC to identify the video call subject to vSRVCC and signal appropriately to EPC. the following enhancements in functionality will be specified on the protocol level: − vSRVCC specific flag in subscription data and HSS interfaces. There are two aspects of making the video call transfer from E-UTRAN to UTRAN-CS. codec re-negotiation and example message flow. enhancements for stage 2 of handover procedures will be documented. − transfer of video bearer related indication and deletion of video marked bearers in S5/S11 interfaces. − update of service continuity procedures for video bearers incl.

it is required that the network provides the cell-ID for following scenarios: • • Lawful interception needs network provided cell-ID. Other source of stage 1 information TS or CR(s) Clause Remarks 22. 23.C4. 23. Telefonica. UID 500027 480138 480238 Name Stage 1 TR on Stage 2 Stage 2 Resource S1 S2 S2 Finish 21/09/2011 14/12/2011 07/03/2012 Hyperlink SP-110631 SP-110631 Notes SP#53 completed SP#54 completed SP#55 completed TSs_and_TRs 22. In this case cell-ID must be network provided due to requirements from national regulators.1.401 Supporting Companies: China Mobile.228.C1 Acronym NWK-PL2IMS NWK-PL2IMS NWK-PL2IMS NWK-PL2IMS NWK-PL2IMS_CH NWK-PL2IMS_CT Resource S1 S2 S2 S5 C3. Deutsche Telekom. IMS session charging records need the current cell-ID information. the MSC can get the current cell-ID information provided by RNC/BSC. This information is needed to fulfil legal obligations in the case where regulators disallow the use of the untrusted UE provided cell ID. In the IMS. Also. Verizon Wireless. ZTE.115 new TR 23.1 (2012-06) 5. Normally the LCS location information is provided in the geographical information format. Network provided cell-ID shall be available to any IMS AS subject to appropriate authorization. Minimal impact on the session set-up time for obtaining the network provided cell-ID is preferred.203. This work aims to identify and specify solutions for the provision of a network provided Cell ID to the IMS nodes.842 23.101 22.4 Network Provided Location Information for IMS (NWKPL2IMS) UID_480038 Resources: UID 48003 8 50002 7 48013 8 48023 8 49002 9 55000 8 S2. the user shall not experience differences when his sessions are intercepted. which is not suitable for charging purposes as it lacks access network information. The destination for VoIP emergency calls shall be selected according to cell-ID.C1 WI_rapporteur T-Mobile n/a T-Mobile T-Mobile Nokia Siemens Networks Huawei Name Network Provided Location Information for IMS (NETLOC) Stage 1 TR on Stage 2 Stage 2 Charging CT aspects Architecture solutions making Cell/PLMN ID (the UE is camped on) available to IMS nodes when the mobile operator needs to record this information either to fulfil legal obligations or for charging purposes. Nokia Siemens Networks.C3. The CDRs generated within IMS have to contain a network provided cell-ID. IMS services may need the cell-ID information to trigger localized services. ST-Ericsson.S5. This applies for all CDRs from any user/session. Orange. Minimal impact on the session set-up time for obtaining the network provided cell-ID is preferred. As the cell-ID information provided by the UE cannot be trusted. In the circuit switched network when a UE initiates a CS call or sends an SMS message. cell-ID information is provided currently by the UE. Huawei. Telecom Italia. which can be used for charging purposes and/or for recording the location of a subscriber for whom the government authority requests communication history. 23. Minimal impact on the session set-up time for obtaining the network provided cell-ID is preferred.C4. TeliaSonera.115 3 Justification LCS for EPS has been defined in Rel-9.38 Overview of 3GPP Release 11 V0.S1. Ericsson. NTT DoCoMo .060. Architecture solutions making Cell/PLMN ID (the UE is camped on) available to IMS nodes when the mobile operator needs to record this information either to fulfil legal obligations or for charging purposes. • • 3GPP .

For this reason it is required that a network trusted location information both for mobile and for fixed networks is provided. efficient use of signalling. The location information shall be provided for both offline and online charging mechanisms.1. change requests will be created against the affected core specifications. The solution candidates will also describe what IP Multimedia Subsystem elements are affected in order to obtain the network provided Cell ID / PLMN ID. Security Aspects: The network provided cell ID shall be securely delivered to the IMS nodes requesting it. Ericsson. Deutsche Telekom.260).g. 3GPP . e. A study will be performed in order to gather the various existing regulatory requirements that the solution needs to be fulfilled. The solutions produced will then be assessed against the following items (non exhaustive list): complexity. in particular the following aspects will need to be analyzed: whether the provision of the network provided cell-ID is applicable a) to the users served by the network (i.240. and across a comprehensive set of services. speed. If enhancements to the security architecture are needed they will be considered by SA3. capability of meeting regulatory requirements. Once a solution has been selected. ZTE Justification Alcatel-Lucent. if used. cell-ID. architecture enhancements and new functionality needed in the EPS and GPRS networks. The destination for VoIP emergency calls shall be recorded by IMS Charging with trusted location information. “non-roaming” subscribers and inbound roamers). irrespective of the access type. it is not usable for a list of features: • • • IMS Charging records need the current location information. when transferred between networks) The study is then expected to produce solution candidates which detail the necessary Stage 2 message flows. Nokia Siemens In the IMS Charging. Also a mechanism to provide this information to the IMS network needs to be defined.g.299) Supporting Companies: Networks. Additionally. Objective: to specify the solutions for IMS Charging with trusted Location information. network operators require that this information can be exchanged between and evaluated by several network operators. 7 Charging Aspects Trusted location information shall be added to IMS Charging. This applies for all CDRs from any user/session. However this mechanism is not efficient and. China Mobile. b) to the users served by the network which are also subscribers of that network. Network provided location information shall be available to any IMS AS subject to appropriate charging and billing. e. Objective: to investigate and specify the architecture solutions for making the cell-ID / PLMN ID the UE is camped on available to the IMS nodes when the mobile operator needs to record this information either to fulfil legal obligations or for charging purposes. location information is provided currently by the UE via SIP P-Access-Network-Information header.e. The CDRs generated within IMS have to contain network provided location information. 32. IMS Charging needs the location information to charge localized services. Openet. UID 49002 9 Name Charging Resource S5 Finish 12/09/201 2 Comp 70% Hyperlink SP110700 WI_rapporteur Nokia Siemens Networks Notes TSs_and_TRs Stage 2 (32. will cause a huge message load on the PS access network. AT&T. As this information provided by the UE cannot be trusted.39 Overview of 3GPP Release 11 V0. Stage 3 (32.1 (2012-06) The PGW/GGSN can get the current cell-ID information if it subscribes to location changing notification. what events trigger the need to retrieve the cell ID of the user what accuracy is required and what accuracy is allowed (e.g. accuracy. add the cell-ID / PLMN ID the UE is camped on available for LTE to the IMS Charging when the operator needs to record this information for charging purposes.298. A more efficient mechanism needs to be defined that allows the network provided cell-ID to be made available only when it is needed. 32.

29. 29.328. the user is not expected to experience differences when his sessions are intercepted.292 29. CP#56 updated WID CP-120081=>CP-120359 CP#56 completed - Justification Network is required to Provide The Location Information (NPLI) for following scenarios: • • • • Lawful interception needs NPLI due to requirements from national regulators.230.1. and whether the NPLI is required in the INVITE request or in a subsequent message MSC Server is providing the location information to IMS when a MSC Server enhanced for ICS is used Support HSS based retrieval when NPLI is required but not already available (e. 29.40 UID 55000 8 55010 8 55020 8 55030 8 Name CT aspects CT3 part CT4 part CT1 part Finish 07/09/201 2 07/09/201 2 15/06/201 2 07/09/201 2 Comp 65% 80% 100% 30% Hyperlink CP-120359 CP-120359 CP-120359 CP-120359 Overview of 3GPP Release 11 V0.165. 29. Also. 29. The CDRs generated within IMS have to contain a NPLI. The destination for VoIP emergency calls can be selected according to cell-ID. This applies for all CDRs from any user/session. Policies in the P-CSCF determine whether the NPLI (Network-Provided Location Information) needs to be retrieved for a particular scenario.213. Objective : This CT-wide WID covers the following works: • Support a PCC-based solution (procedure invoked by the P-CSCF) to obtain the NPLI. 29.274. 29. when required in an INVITE request.163. Minimal impact on the session set-up time for obtaining the NPLI is preferred. when it is needed prior to session delivery. 29.229 Notes Stage 3. 29.329 24. Minimal impact on the session set-up time for obtaining the NPLI is preferred.060. 29. Minimal impact on the session setup time for obtaining the NPLI is preferred.002. IMS services may need the cell-ID information to trigger localized services. 29.272. NPLI shall be available to any IMS AS subject to appropriate authorization.1 (2012-06) TSs_and_TRs 29.214. or when call is broken out to a MGCF) Procedures to retrieve and transfer the NPLI within IMS Support NPLI for emergency sessions where network provided location is required and LRFbased procedures are not used • • • • 3GPP .212. 29.g.305..215. 29.

2. The feature comprises the request to detect the specified application traffic. To facilitate this.203 Supporting Companies: Allot Communications.C3 S1 S2 C3 WI_rapporteur Allot Communications Allot Communications Allot Communications Allot Communications UID 50013 2 Name Stage 1 Resource S1 Finish 15/12/201 0 Hyperlink SP100882 50023 2 Stage 2 S2[99%] 21/09/201 1 SP100882 Notes For deep packet inspection (i. GENBAND. Samsung.S1. justify: For deep packet inspection (i. Traffic Detection Functionality) SA1 indicated that no new requirements are needed (see Objective of FS_PP SA1. It is identified that the normative specifications. Both solicited and unsolicited application reporting models to the PCRF are possible.e.1. reporting to the PCRF and application of specified enforcement actions. ZTE If no identified source of stage 1 information. For the 3GPP ..1 (2012-06) 5.212. its functionality and interfaces. Update S9 reference point in roaming scenarios TSs_and_TRs Stage 3: 29. The solution will be provided as outlined in TR 23.e. Deutsche Telecom.41 Overview of 3GPP Release 11 V0.215 1. Vodafone. Justification Policy enhancements to the 3GPP architecture were studied in detail in TR23. Telecom Italia.213. Traffic Detection Function) SA1 has indicated in the past that no new requirements are needed and this is documented in the FS_PP study item objective’s text. Traffic detection functionality and corresponding notification can be implemented by a standalone entity as well as be collocated with PCEF. AT&T.214. 3. Objective: to update the normative specifications with regard to Traffic Detection Function definition.813 resulting in the conclusion that further standardisation is required in the area of Service Awareness and Privacy Policy. Stage 3 to support Application Detection and Control Functionality. Session termination mechanisms between PCRF and TDF In addition potential mechanisms to enable steering of user traffic either to a particular TDF or to bypass this TDF will be studied. which handle PCC.5 Service Awareness and Privacy Policies (SAPP) UID_500032 Resources: UID 500032 500132 500232 510003 S2. China Mobile.813) SP#53 completed TSs_and_TRs - 23. 29. Update Gx / introduce Sd reference points and procedures. Nokia Siemens Networks. 29. Bridgewater systems. Ericsson. Telcordia.S1.SA2 Rel-10 Study on Policy solutions and enhancements UID_440047 TR 23. 29.C3 Name Service Awareness and Privacy Policies Stage 1 Stage 2 CT3 part Acronym SAPP SAPP SAPP SAPP-CT3 Resource S2. A key aspect of the evaluation will be the ability to ensure a subscriber’s downlink traffic can be steered to the same TDF which is handling the uplink traffic. Alcatel-Lucent. including the corresponding notification from TDF to PCRF and possible enforcement actions 4. UID 510003 Name CT3 part Finish 02/12/201 1 Hyperlink CP110136 Notes CP#54 completed. Justification Service traffic detection mechanisms help to achieve service awareness. Rogers Wireless. Camiant. should be updated in order to cover the agreed architecture modifications.813. a new entity known as a Traffic Detection Function is proposed for definition in Rel-11 along with corresponding policy control signalling. key issue 4 and will include the following aspects: Session establishment mechanisms between PCRF and TDF The interfaces between PCRF and TDF The mechanisms in case of start of service traffic detection/end of service traffic detection. Huawei. Sandvine.

203.42 Overview of 3GPP Release 11 V0. 3GPP .212. the use of service traffic detection mechanisms should be in accordance with user profile configuration. The following stage 3 aspects have to be specified within this WI: − Update Gx reference point and procedures to cover application detection and control functionality − Introduce Sd reference point and its procedures for application detection and control functionality − Update S9 Reference Point to support application detection and control functionality in roaming scenarios NOTE: For the Sd definition. Objective: to specify the stage 3 aspects of Service Awareness and Privacy Policies according to 3GPP TS 23.214 and referenced from TS 29.1.1 (2012-06) solicited application reporting model. the solicited application reporting model will be introduced to TS 29. impacts on Gx.212 and the unsolicited application reporting model will be introduced to TS 29. S9 procedures and reference points and definition of Sd procedures and reference point.

23. 23.002.008.220: The visited network needs to access the HSS/HLR in the home network of the subscriber in order to update the CSG information for the subscriber. This includes the following functionalities: Support for the HPLMN to instruct the VPLMN to disable VPLMN Autonomous CSG Roaming.002. Objective: to specify the requirements from TS 22.002.43 Overview of 3GPP Release 11 V0.e. 29. ZTE. Deutsche Telekom. No service should be impacted as a result of this work. 29. The corresponding impacts to the stage 3 Technical Specifications need to be specified. Samsung . This WI proposes to develop the supporting functions for VPLMN autonomous CSG roaming to satisfy the SA1 requirements.272 Justification A new feature called VPLMN Autonomous CSG roaming specified in 3GPP TS 23. If allowed by the HPLMN. for example.220. Support for the VPLMN to store and manage CSG subscription information for roaming UEs. if the home network does not support CSGs when the home network is Rel-7.060.012.6 VPLMN Autonomous CSG Roaming (VCSG) UID_500033 Resources: UID 500033 500133 530017 S2. 23. Objective: to specify the stage 3 impacts to support VPLMN Autonomous CSG roaming (VCSG) as follows: 3GPP . Service Aspects: Charging Aspects: Current charging is applied to this work Security Aspects: UID 53001 7 Name CT aspects to be considered for the functionality listed in the Objective Resource C4 Finish 07/09/201 2 Comp 85% Hyperlink CP-120196 TSs_and_TRs 23.1 (2012-06) 5.007. Juniper Networks. i. 23.230. for HPLMN CSG Roaming as defined in TS 22.401 is optionally supported by a VPLMN.C4 S2 C4 WI_rapporteur Qualcomm Qualcomm ZTE UID 500133 Name Stage 2 Acronym VCSG Resource S2 Finish 14/12/2011 Hyperlink SP-100706 Notes SP#54 completed TSs_and_TRs 23. 23.060 and 23.401 Supporting Companies: Unique ID 450053 Qualcomm. the CSG Subscriber Server (CSS) in the VPLMN stores and manages the related CSG subscription information for the roaming UEs without interaction with the HLR/HSS. LG Electronics. In some cases the visited network may not have access to this function in the home network.003.1. 29. Nokia Related Study Item or Feature (if any) Title Nature of relationship Enhanced Home NodeB / eNodeB (EHNB) Implements Rel-9 requirements for CSG support Justification The following limitation exists for CSG provisioning if the subscriber is roaming on a CSG in a VPLMN. Support for the VPLMN to store and manage CSG subscription information for roaming UEs.C4 Name VPLMN Autonomous CSG Roaming Stage 2 CT aspects Acronym VCSG VCSG VCSG-St3 Resource S2. To solve this problem SA1 introduced a new feature called VPLMN autonomous CSG roaming in TS 22. The requirement has been specified in Stage 2 which has the following functionalities: Support for the HPLMN to allow the VPLMN to enable VPLMN Autonomous CSG Roaming..220 for VPLMN autonomous CSG roaming. 23.

Define the MME/SGSN/VLR behaviour to validate the membership of the UE. Define the new DIAMETER codes and identifiers for S7a/S7d interfaces.1. Update of MAP protocol to specify the interactions between the SGSN/VLR-CSS. and specify the interactions between SGSN-CSS. 3GPP . and specify the interactions between MME-CSS. . including the VLR-CSS signalling flows and the detailed behaviour of SGSN/VLR and CSS. including the detailed behaviour of MME and CSS.44 Overview of 3GPP Release 11 V0. including the detailed behaviour of SGSN and CSS.Define the Diameter protocol for theS7a reference point (MME-CSS).1 (2012-06) - - Update of MME and SGSN related interfaces based on Diameter protocol: .Define the Diameter protocol for the S7d reference point (SGSN-CSS). Define the additional data storage for VCSG in the MME/SGSN/VLR and CSS.

To take this into account. www. Telecom Italia. The destination port number the UE connects to. No service should be impacted as a result of this work. Based on the current Rel-10 specification the operator can indicate different preferred or forbidden radio access technologies as a function of the type of traffic the UE sends. Verizon Wireless.com) and web browsing (e.7 Data Identification in ANDSF (DIDA) UID_510048 Resources: UID 51004 8 51014 8 51024 8 55000 3 S2 Acronym DIDA DIDA DIDA DIDA-CT Resource S2. www. Motorola Mobility.1 (2012-06) 5. The destination IP address the UE sends traffic to.45 Overview of 3GPP Release 11 V0. A combination of the three elements above. Specifically an ISRP can be based on: The PDN identifier (i.1. The current specification has already limitations on how the traffic is identified due to the clear of aggregation of the Internet traffic into few transport ports which has emerged in recent years.C1 S2 S2 C1 WI_rapporteur Qualcomm Qualcomm Qualcomm Qualcomm Name Data Identification in Access Network Discovery and Selection Function (ANDSF) TR on Stage 2 Stage 2 CT aspects Stage 3 UID 510148 510248 Name TR on Stage 2 Stage 2 Resource S2 S2 Finish 14/12/2011 07/03/2012 Hyperlink SP-110084 SP-110084 Notes SP#54 completed (1-step approval) SP#55 completed TSs_and_TRs New TR 23. Current security architecture applies to this work as well.google. APN) the UE uses for a given connection. Any extension to the ANDSF framework which is not related to identification of traffic is outside the scope of this WID. Nokia. IFOM and non seamless WLAN offload. Extensions to the ANDSF MO to convey these additional ways over S14. the ANDSF framework has been enhanced with the introduction of Inter System Routing Policies (ISRP). Samsung. Current charging mechanisms are applied to this work. Research In Motion. Bridgewater.youtube. Specifically this WID will specify: Additional ways to identify classes of traffic a ISRP applies to. Orange.e. LG Electronics UID 45004 3 Title Related Study Item or Feature (if any) Nature of relationship Defines IP flow mobility. There is therefore a need to define improvements of the ANDSF framework in order for the operator to have a better control on how network resources are used.855 23.g. Objective: to specify ANDSF extensions to provide to operators a better control of the network resources used for each application or IP flow.402 Supporting Companies: Qualcomm. 3GPP . allowing the operator to provide policies based on the traffic exchanged by the UE. seamless and non seamless WLAN offload and respective ANDSF extensions IP Flow Mobility and seamless WLAN offload Justification In Rel-10 simultaneous network connections to multiple radio access technologies have been enabled by MAPCON.com). This trend has impacts on the applicability of ANDSF policies and the ability for the operator to specify how traffic should be routed.g. For example the operator with the current framework is not able to discriminate between video streaming (e.

The destination IP address the UE sends traffic to. the ANDSF framework has been enhanced with the introduction of Inter System Routing Policies (ISRP). Specifically this WID will specify stage 3 details to define: FQDN representation of traffic in ANDSF. This trend has impacts on the applicability of ANDSF policies and the ability for the operator to specify how traffic should be routed. Application-ID representation of traffic in ANDSF. There is therefore a need to define improvements of the ANDSF framework in order for the operator to have a better control on how network resources are used. Any extension to the ANDSF framework which is not related to identification of traffic by the means of FQDN or application IDis outside the scope of this WID. For example the operator with the current framework is not able to discriminate between video streaming and web browsing. APN) the UE uses for a given connection. A combination of the three elements above. To take this into account. Specifically an ISRP can be based on: The PDN identifier (i. IFOM and non seamless WLAN offload.1. Objective: to specify ANDSF extensions and the procedures to use such extensions to provide to operators a better control of the network resources used for each application or IP flow.312 Justification In Rel-10 simultaneous network connections to multiple radio access technologies have been enabled by MAPCON. 24.302 (if required) definition of usage of the OMA-DM leaves added to ANDSF MO Approved at plenary# Comments CT#57 CT1 responsibility CT#57 CT1 responsibility 3GPP .302. R C Subject 24. 10 Expected Output and Time scale Affected existing specifications Spec No.46 UID 550003 Name CT aspects Stage 3 Resource C1 Finish 13/09/2012 Overview of 3GPP Release 11 V0.312 Addition of OMA-DM leaves for new solution of data identification 24.1 (2012-06) Comp 10% Hyperlink CP-120089 Notes Stage 3 TSs_and_TRs 24. The extensions apply only to IFOM and non-seamless WLAN offload branches of ISRP branch of ANDSF. Based on the current Release 10 specification the operator can indicate different preferred or forbidden radio access technologies as a function of the type of traffic the UE sends. The destination port number the UE connects to. allowing the operator to provide policies based on the traffic exchanged by the UE.e. The current specification has already limitations on how the traffic is identified due to the trend of aggregation of the Internet traffic into few transport ports which has emerged in recent years.

No service should be impacted as a result of this work.C1 Acronym LOBSTER LOBSTER LOBSTER-CT LOBSTER-CT Resource S2. Charging aspects to be considered by SA5 Security analysis to be undertaken by SA3 UID 54001 0 54011 0 54021 0 Name CT aspects CT4 part of CT aspects CT1 part of CT aspects Resource C4 C4 C1 Finish 15/06/201 2 15/06/201 2 15/06/201 2 Hyperlink CP120252 CP120252 CP120252 Notes Stage 3. China Telecom.302 3GPP .8 Location-Based Selection of gateways for WLAN (LOBSTER) UID_510050 Resources: UID 510050 510150 540010 540110 S2.1 (2012-06) 5. Updated WID CP110803=>CP-120252 (no CT1 impact) TSs_and_TRs Stage 3 29. There is therefore a need to improve the ePDG and PDN-GW selections based on the location of the UE for the WLAN Access to EPC in S2c case.C4 S2 C4 C4 WI_rapporteur ZTE ZTE ZTE ZTE Name LOcation-Based Selection of gaTEways foR WLAN Stage 2 CT aspects CT4 part of CT aspects UID 510150 Name Stage 2 Acronym LOBSTER Resource S2 Finish 14/12/2011 Hyperlink SP-110752 WI_rapporteur ZTE Notes SP#54 completed TSs_and_TRs 23.47 Overview of 3GPP Release 11 V0. CP#56 completed. However. Telecom Italia Nature of relationship Rel-8 BB-level WI under which non-3GPP accesses (including WLAN) support in EPS was defined.1. Qualcomm. the current PDN GW selection for S2c in TS 23.402 Supporting Companies: ZTE. Orange.C4. Alcatel-Lucent.402 has not considered the UE location.273 24. so the routing from the UE to the PDN GWmay not be optimized. China Mobile. Objective: to specify enhancements to the PDN GW selection function for S2c based on UE location. Updated WID CP110803=>CP-120252 (no CT1 impact) CP#56 completed CP#56 stopped. Related Study Item or Feature (if any) UID Title 35002 SAE for support for non-3GPP accesses (SAES7 SA-FP_n3GPP) Justification The WLAN Access to EPC with IP address continuity has been defined in Release 8 and then extended in Release 10 with IFOM and MAPCON.

based on the solution recommended in TR 23. China Mobile. 24. 24. 24.G2.165.2. ST-Ericsson. 23.278 clause 7.R2.278 has contained stage-1 requirements for single radio voice call continuity between UTRAN/GERAN and EUTRAN/HSPA in both directions since Rel-8.C3. ATT. 10 Expected Output and Time scale Affected existing specifications Spec No.885.C4. 9 and 10.003. 24. Triggered by Rel-11 TR 23.216 23.230. TeliaSonera.C3. ZTE. Objective: to complete the normative work for the stage-2 system aspects in order to support Single Radio Voice Call Continuity from UTRAN/GERAN to E-UTRAN/HSPA.272.885 “Study on SR-VCC for UTRAN/GERAN to E-UTRAN/HSPA service continuity”. Ericsson. Telenor. However the service continuity from UTRAN/GERAN CS access to E-UTRAN/HSPA was not specified in Releases 8.008.009.305. 23.328 Justification TS 22.4.9 Single Radio Voice Call Continuity from UTRAN/GERAN to E-UTRAN/HSPA (rSRVCC) UID_530001 Resources: UID 53000 1 53010 1 53020 1 53060 1 53070 1 S2.C4.C1. NTT DOCOMO. In TR 23. and one of them was recommended for standardization in Release 11.002.885 Study on Single Radio Voice Call Continuity from UTRAN/GERAN to EUTRAN/HSPA (FS_rSRVCC) UID_460030 SP#56 completed TSs_and_TRs UTRA 53010 1 Stage 2 rSRVCC S2 20/06/201 2 SP110475 23. 29.R2.237.1. 29. NEC UID 53000 1 Name Single Radio Voice Call Continuity from UTRAN/GERAN to E-UTRAN/HSPA Acronym rSRVCC Resource Finish 07/09/201 2 Hyperlink SP110475 Notes Stage 1 in Rel-8 TS 22.G2.48 Overview of 3GPP Release 11 V0.229.280.1 (2012-06) 5.1. while there are some clear use cases for this.008. Alcatel-Lucent. 29.C1. 29. 24.R2 WI_rapporteur Orange Orange Ericsson ZTE Huawei Name Single Radio Voice Call Continuity from UTRAN/GERAN to E-UTRAN/HSPA Stage 2 CT aspects (Stage 3) GERAN aspects UTRAN aspects Supporting Companies: Orange.C4 G2 R3.301 29.R3 S2 C1. CR Subject Approved at plenary# Comments 23.292. 29.237 SA#55 (03/2012) SA#55 (03/2012) UID 53020 1 53030 1 53040 1 53050 1 Name CT aspects (Stage 3) CT1 part CT3 part CT4 part Finish 07/09/201 2 07/09/201 2 07/09/201 2 07/09/201 2 Comp 53% 60% 30% 70% Hyperlink CP110726 CP110726 CP110726 CP110726 TSs_and_TRs Stage 3 23.C3.303.216.R3 Acronym rSRVCC rSRVCC rSRVCC-CT rSRVCC-GERAN rSRVCCRAN_UTRA Resource S2. LG Electronics. Deutsche Telekom.237 Justification Release 8 had defined the requirements for supporting SRVCC between UTRAN/GERAN and E-UTRAN/HSPA in both directions. 29. 3GPP . 29. Huawei.292 23. solutions were studied for providing Single Radio Voice Call Continuity from UTRAN/GERAN to E-UTRAN/HSPA. 29.

R C Subject 23.292 Registration through the ATCF 24. CT#57 Sep 2012 CT4 resp.280 Requesting of the Relocation Preparation procedure for the voice component from BSC/RSC via Sv reference point 29. 29. To achieve this.009 Handover Procedure updates related to this WID 24.018. impacts on GERAN specifications are listed below: • Enable the BSS to support seamless service continuity when MS handovers from GERAN CS access to E-UTRAN/HSPA for voice call initiated in LTE and handed over to 2G/3G CS access as well as for the voice call directly initiated in 2G/3G CS access.008 Supporting Companies: Justification ZTE. 3GPP . GP#51 approved WID TSs_and_TRs 44. Huawei Rel-8 had defined the requirements for supporting SRVCC between UTRAN/GERAN and E-UTRAN/HSPA in both directions. alternatives were studied for providing Single Radio Voice Call Continuity from UTRAN/GERAN to E-UTRAN/HSPA.1 (2012-06) The single radio voice call continuity from E-UTRAN/HSPA to UTRAN/GERAN CS access was specified in Rel-8 in the stage-3 specifications. CT4 resp.1.165 Impacts on the Inter-IMS Network to Network Interface due to the Access Transfer Notification. UID 53060 1 Name GERAN aspects Acronym rSRVCCGERAN Resource G2 Finish 31/08/201 2 Comp 40% Hyperlink GP111290 Notes Stage 3. CT4 resp.272 Updates of MME and SGSN related interfaces based on Diameter protocol related to this WID 29. SA2 WID rSRVCC has been agreed with objective to provide the stage-2 work covering single radio voice call continuity from UTRAN/GERAN to E-UTRAN/HSPA. SA2 WID rSRVCC has been agreed with objective to provide the stage-2 work covering single radio voice call continuity from UTRAN/GERAN to E-UTRAN/HSPA. CT#57 Sep 2012 CT1 resp. In TR 23.303 Updates of the domain name system procedures related to this WID 29. 48. CT4 resp.292 CS-IMS signalling interworking aspects of this WID 29.229 Annex A updates.008 Information stored in HSS related to this WID 23. CT4 resp.305 Updates of interworking function between MAP based and Diameter based interfaces related to this WID 29. CT#57 Sep 2012 CT1 resp. China Mobile. CT4 resp. CT#57 Sep 2012 CT1 resp. CT#57 Sep 2012 CT1 resp. Objective: to specify the single radio voice call continuity from GERAN to E-UTRAN/HSPA in the stage-3 GERAN specifications based on related stage-2 and stage-1 (which is an outcome of the solution recommended in TR 23. Orange.49 Overview of 3GPP Release 11 V0.301 "rSRVCC capability indication" in the NAS signalling 29. CT4 resp. ST-Ericsson. However the service continuity from UTRAN/GERAN CS access to E-UTRAN/HSPA is not specified yet. if required 24.237 SIP based procedure for single radio voice call continuity from UTRAN/GERAN to EUTRAN/HSPA 24. CT3 resp. Objective: to specify the single radio voice call continuity from UTRAN/GERAN CS access to E-UTRAN/HSPA in the stage-3 specifications based on the related stage-2 and stage-1 requirements. CT3 resp. CT#57 Sep 2012 CT1/CT4 resp.008 "rSRVCC capability indication" in the NAS signalling 24. Single radio call continuity from UTRAN/GERAN CS access to E-UTRAN/HSPA of media other than voice is out of scope of this work item.885). Alcatel-Lucent. CT#57 Sep 2012 CT#57 Sep 2012 CT#57 Sep 2012 CT#57 Sep 2012 CT#57 Sep 2012 CT#57 Sep 2012 CT#57 Sep 2012 CT#57 Sep 2012 CT#57 Sep 2012 CT#57 Sep 2012 CT1 resp.003 Addressing and Identification aspects of this WID 23.230 Updates of 3GPP specific codes and identifiers for Diameter applications related to this WID 29.885 “Study on SRVCC for UTRAN/GERAN to E-UTRAN/HSPA service continuity”. Ericsson.002 Updates of MAP specification related to this WID 29. the single radio voice call continuity from UTRAN/GERAN CS access to EUTRAN/HSPA is not specified yet in the stage-3 specifications. 10 Expected Output and Time scale Affected existing specifications Spec No. However. CT4 resp. and a full solution was recommended for standardization.328 rSRVCC allowed indication as part of the subscriber data Approved at plenary# Comments CT#57 Sep 2012 CT4 resp.

In TR 23.331.Provide to the RNC relative UE capability information. R C Subject 25. Expected Output and Time scale Affected existing specifications Spec No.1 (2012-06) • Enable the MS to support seamless service continuity when MS handovers from GERAN CS access to E-UTRAN/HSPA for voice call initiated in LTE and handed over to 2G/3G CS access as well as for the voice call directly initiated in 2G/3G CS access. ZTE.413 UTRAN Iu interface Radio Access Network Application Part (RANAP) signalling 25. 9 and 10.413 Supporting Companies: Justification Huawei.008 Mobile Switching Centre-Base Station System(MSC-BSS) interface.R2 Finish 07/09/201 2 07/09/201 2 Comp 70% 70% Hyperlink RP111334 RP111334 Status_Report RP-120828 TSs_and_TRs UTRA 25. Orange.R2 R3. Layer 3 specification Approved at plenary# Comments GERAN#55 Aug 2012 GERAN#55 Aug 2012 UID 530701 530801 Name UTRAN aspects Core part Acronym rSRVCCRAN_UTRA rSRVCCRAN_UTRA-Core Resource R3.331 Radio Resource Control (RRC). 25. SA2 WID rSRVCC has been agreed with objective to provide the stage-2 work covering single radio voice call continuity from UTRAN/GERAN to E-UTRAN/HSPA. 10 Expected Output and Time scale Affected existing specifications Spec No. Ericsson. based on the solution recommended in TR 23.885. and one of them was recommended for standardization in Release 11. R C Subject 44.401. while there are some clear use cases for this.401 UTRAN overall description 25.50 Overview of 3GPP Release 11 V0.1. Hisilicon.018 Radio Resource Control (RRC) protocol 48. Objective: to complete the normative work for the UTRA stage-3 aspects in order to support Single Radio Voice Call Continuity from UTRAN/GERAN to E-UTRAN/HSPA. Telenor. NEC.885 “Study on SR-VCC for UTRAN/GERAN to E-UTRAN/HSPA service continuity”. TeliaSonera Release 8 had defined the requirements for supporting SRVCC between UTRAN/GERAN and E-UTRAN/HSPA in both directions. solutions were studied for providing Single Radio Voice Call Continuity from UTRAN/GERAN to E-UTRAN/HSPA. Protocol specification Approved at plenary# Comments RAN#56 Jun 2012 RAN#57 Sep 2012 RAN#57 Sep 2012 3GPP .Enable the RNC to perform rSRVCC HO . The following UTRAN impacts are foreseen: . 25. However the service continuity from UTRAN/GERAN CS access to E-UTRAN/HSPA was not specified in Releases 8.

23.C3.51 Overview of 3GPP Release 11 V0. Charging Aspects: Security Aspects: UID 54001 1 Name CN aspects to be considered by SA5. The reasons to use S2a for WLAN to access EPC may vary from operator to operator and depend on the operator’s network deployment policy.IETF S2 C4.IETF WI_rapporteur ZTE ZTE Alcatel-Lucent Name S2a Mobility based On GTP and WLAN access to EPC Stage 2 CN aspects UID 530146 Name Stage 2 Resource S2 Finish 07/03/2012 Hyperlink SP-110642 WI_rapporteur ZTE Notes SP#55 completed TSs_and_TRs 23. The QoS control associated with the Trusted WLAN AN connected via S2a is included in TS 23.C3 Acronym SaMOG_WLAN SaMOG_WLAN SaMOG_WLAN-CN Resource S2. Rel-8 UID_350027 SAE for support for non-3GPP accesses (defines PMIP-S2a).139 (BBAI phase 3). Huawei. Trusted WLAN as a BBF access is documented as part of TS 23. The limitations determined in TR 23. to be considered by SA3. Deutsche Telekom. 23. One example is that many terminals do not support 3GPP extensions IKEv2/IPsec.1. More specifically.C1.852 FS_SaMOG UID_510061.402 while the QoS control for WLAN AN in Fixed Broadband Access (BBF) for interworking and convergence scenarios with 3GPP/EPS Access is handled by BBAI and is included in TS 23.1 (2012-06) 5. While the internal implementation of WLAN AN is out of this work item’s scope.852.C1.203.C1.C4.002. Upon specifying GTP based S2a for trusted access to EPC. the necessary prerequisites regarding the WLAN AN functionality for trusted WLAN access to EPC are listed as part of this WI. Telecom Italia. mobile operators also would like to provide PS service to the UE which access to EPC via WLAN. MediaTek. No usage of WLAN access to EPC over S2a is currently documented in 3GPP specifications whereas deciding whether a non 3GPP access network is to be considered as trusted should not be mandated by the technology of this non 3GPP access. HTC. ZTE Triggered by Rel-11 TR 23. Another example is that in some cases the WLAN can be considered secure and it is acceptable for the operator to consider it as trusted by use of S2a to access EPC. China Telecom. Juniper Networks.C3. Nokia Siemens Networks. Alcatel-Lucent. KDDI.IETF Finish 07/09/201 2 Comp 90% Hyperlink CP110802 Notes Stage 3 TSs_and_TRs Stage 3 3GPP . Specifically. Nokia. BT.852 for the no-UE-impact case will be applied.C1.402 Supporting Companies: AT&T. operators are more eager to offload data traffic to widely deployed WLAN access over the fixed broadband network to lower the wireless infrastructure cost. Objective: to enable GTPv2 and PMIPv6 based S2a access to EPC through WLAN access.C3. Whether GTP or PMIP is used in the network for S2a is transparent to the UE.139. To specify the no-UEimpact solution based on the SaMOG study TR 23. Ericsson.10 S2a Mobility based On GTP and WLAN access to EPC (SaMOG) UID_530046 Resources: UID 530046 530146 540011 S2. Related Study Item or Feature (if any) UID Title 51004 Study on S2a Mobility based On GTP and WLAN access to 3 EPC 35002 SAE for support for non-3GPP accesses (SAES-SA7 FP_n3GPP) Nature of relationship Study phase Define PMIP-S2a Justification With the increasing deployment of multi-media mobile terminals and 3rd party mobile applications to inflate the network capacity demand. There are requirements from some operators to use GTP or PMIP S2a for WLAN to access EPC. China Mobile. WLAN access to EPC will apply for both GTP and PMIPv6 based interfaces. ST-Ericsson.C4. Resource C4. A main output of this activity is to define the support of GTPv2 over S2a and to build a list of 3GPP requirements for a trusted WLAN AN. Telefonica.

52
54011 1 56101 0 54021 1 54031 1 CT4 part (IETF) CT4 part CT1 part CT3 part C4 C4-IETF 07/09/201 2 07/09/201 2 15/06/201 2 15/06/201 2 97% 50% CP110802 CP110802 CP110802 CP110802

Overview of 3GPP Release 11 V0.1.1 (2012-06)
CP#56 completion 06/12=>09/12 CP#56 added IETF dependency. Work in progress (Introduced with C4-120828) CP#56 stopped (no CT1 impact) CP#56 completed 23.003, 23.007, 23.008, 29.273, 29.274, 29.281, 29.303 IETF Draft draft-ietfradext-ieee802ext-01 (RADIUS Attributes for 802 Networks) 24.302 29.212, 29.213, 29.215

C1 C3

100% 100%

3GPP

53

Overview of 3GPP Release 11 V0.1.1 (2012-06)

5.11 Roaming Architecture for Voice over IMS with Local Breakout (RAVEL) UID_540029
Resources:
UID 54002 9 54012 9 54003 0 55000 4

S2,S5,C1,C3
Acronym RAVEL RAVEL RAVELCH RAVEL-CT Resource S2,S5,C1,C3 S2 S5 C1,C3 WI_rapporteur Deutsche Telekom Deutsche Telekom Nokia Siemens Networks Deutsche Telekom

Name Roaming Architecture for Voice over IMS with Local Breakout Stage 2 Charging CT aspects (Stage 3)

Supporting Companies: Alcatel-Lucent, Deutsche Telekom, Ericsson, Huawei, KDDI, Nokia Siemens Network, NTT DOCOMO, Orange, ST Ericsson, Telecom Italia, TeliaSonera, Vodafone, ZTE Triggered by Rel-11 TR 23.850 Study on Roaming Architecture for Voice over IMS with Local Breakout (FS_RAVEL). GSMA CPWP LS_in S5-102806 asked 3GPP SA5 to check if CS voice charging principles also apply to voice over IMS
UID 540129 Name Stage 2 Acronym RAVEL Resource S2 Finish 14/12/2011 Hyperlink SP-110885 Notes SP#54 completed TSs_and_TRs 23.002, 23.228

Justification The GSM Association requested 3GPP to check if the replication of the charging principles that apply to circuit switched voice can also be applied to voice over IMS (see the liaison statement from GSMA CPWP to 3GPP SA5 in S5-102806). SA2 has performed a thorough analysis of the possible changes to the network needed to realize this requirement and captured them in TR 23.850 Objective: to implement the recommendations given in TR 23.850. to be determined by SA3.
Acronym RAVEL-CH Resource S5 Finish 12/09/201 2 Comp 50% Hyperlink SP-110886 Notes Stage 2/3 TSs_and_TRs 32.240, 32.260, 32.298, 32.299

Security Aspects:
UID 54003 0 Name Charging

Objective: to implement the charging aspects according to the requirements and procedures stated in TS 23.228, based on the conclusions given in TR 23.850. Security Aspects: a secure interchange of carrier identities (e.g. Inter Operator Identifiers) must be granted. Potential security gaps need to be analysed and solved together with SA3. 10 Expected Output and Time scale
Spec CR Subject No. 32.240 - Charging Architecture and Principles 32.260 - Add Charging Principles for RAVEL (Stage 2) Affected existing specifications Approved at Comments plenary# TSG SA#56 (Jun Add description for RAVEL charging 2012) TSG SA#56 (Jun Add description for RAVEL charging 2012) Add potential new RAVEL-related charging parameters to IP Multimedia Subsystem (IMS) charging.

32.298 32.299

Modify IMS handling to grant secure interchange of carrier identities (e.g. IOI handling) Align TS 32.298 with Stage 2 TS TSG SA#57 (Sep Add potential new RAVEL-related parameters to Charging Data 32.260 2012) Record (CDR) parameter description Align TS 32.299 with Stage 2 TS TSG SA#57 (Sep Add potential new RAVEL-related parameters to Diameter charging 32.260 2012) application

UID

Name

Acronym

Resource

Finish

Comp

Hyperlink

Notes

TSs_and_TRs

3GPP

54
550004 550104 550204 CT aspects (Stage 3) CT1 part CT3 part RAVELCT RAVELCT RAVELCT C1,C3 C1 C3 07/09/201 2 07/09/201 2 07/09/201 2 48% 55% 40%

Overview of 3GPP Release 11 V0.1.1 (2012-06)
CP120088 CP120088 CP120088 Stage 3 CP#56 Work can only begin when CT1 has decided the technical solution Stage 3 24.229, 24.292, 24.237 29.165, 29.162, 29.079

3GPP

55

Overview of 3GPP Release 11 V0.1.1 (2012-06)

6 SA3 Features - Rel-11 Security small Enhancements (SEC11) UID_520030)
UID 52003 0 44005 5 56000 9 48003 9 51005 3 54001 2 52003 2 Name Rel-11 Security small Enhancements ZUC EEA3 and EIA3 (new Encryption & Integrity EPS security Algorithms) Conformance Test Aspects – ZUC (EEA3 and EIA3 Encryption & Integrity EPS security Algorithms) Specification of Protection against Unsolicited Communication for IMS (produced TR-only) H(e)NB security features for UE mobility scenarios (Stage 2) Generic Bootstrapping Architecture (GBA) extensions for re-use of SIP Digest credentials Lawful Interception in the 3GPP Rel-11 Acronym SEC11 EEA3_EIA3 EEA3_EIA3_UEConTest SPUCI HNB_mob_Sec GBA-ext LI11 Resource S3,C4,C1,R5 S3 R5 S3 S3 S3,C4,C1 S3 WI_rapporteur CATR CATR NEC Huawei Nokia PIDS, AlcatelLucent

6.1 EEA3 and EIA3 (new Encryption & Integrity EPS security algorithms) UID_440055
Resources:
UID 44005 5 56000 9

S3,R5
Acronym EEA3_EIA3 EEA3_EIA3_UEConTest Resource S3 R5 WI_rapporteur CATR CATR

Name ZUC EEA3 and EIA3 (new Encryption & Integrity EPS security Algorithms) Conformance Test Aspects – ZUC (EEA3 and EIA3 Encryption & Integrity EPS security Algorithms)

UID 44005 5

Name ZUC EEA3 and EIA3 (new Encryption & Integrity EPS security Algorithms)

Acronym EEA3_EIA3

Resource S3

Finish 14/12/201 1

Hyperlink SP090457

WI_rapporteur CATR

Notes SP#54 TR 35.924 v200 for Approval. SP#53 completed new EPS algorithms e.g. for China. V100 new 35.221, 35.222, 35.223 for 1step Approval

TSs_and_TRs 33.401, new (35.221, 35.222, 35.223, 35.924)

Supporting Companies: Alcatel-Lucent, Alcatel Shanghai Bell, China Mobile, China Unicom, Datang Mobile, Huawei, Nokia, Nokia Siemens Networks, CATR, ZTE. Different nations will have different policies for algorithm usage of communication system. The current defined EPS algorithm may not be used in some nations according to strict policies which depend on nation’s security laws, e.g. in China. Meanwhile, operators shall implement their networks depending on national communication policies. To introduce a new algorithm for EPS security will give operators more alternatives to decide in order to obey national requirements. The current 3GPP specifications for LTE/SAE security support a flexible algorithm negotiation mechanism. In current phase, 3GPP defines that there are two algorithms used in EPS security, i.e. SNOW 3G and AES. The remaining values have been reserved for future use. So it is technically feasible for supporting new algorithm for LTE/SAE ciphering and integrity protection. Furthermore works has been done by the Chinese academic institutes to adapt LTE security to national requirements about cryptography of LTE/SAE system, i.e. designing a new algorithm of EPS security, which is named ZUC (i.e. Zu

3GPP

56

Overview of 3GPP Release 11 V0.1.1 (2012-06)

Chongzhi, a famous Chinese scientist name in history). Certainly the new algorithm should be fundamentally different from SNOW 3G and AES, so that an attack on one algorithm is very unlikely to translate into an attack on the other. The objective of this work item is to standardise a new algorithm in EPS. This will include the following tasks: • • • To develop new algorithms for confidentiality and integrity protection for E-UTRAN To enable operators to quickly start to support the new algorithm • Not to introduce any obstacle for R8 or R9 roaming UE

The following issues should at least be handled in the WI: • • Agree requirement specification with ETSI SAGE for development of new algorithms Delivery of algorithm specification, test data and design and evaluation reports

The algorithm is provided for 3GPP usage on royalty-free basis. The algorithm shall undergo a sequential three-stage evaluation process involving first ETSI SAGE, then selected teams of cryptanalysts from academia and finally the general public.

6.1.1 Conformance Test Aspects – ZUC (EEA3 and EIA3) UID_560009
Resources:
UID 56000 9

R5
Acronym EEA3_EIA3_UEConTest Finish 01/03/201 3 Comp 0% Hyperlink RP120631 WI_rapporteur CATR Notes Testing for SA3 TSs 33.401, new (35.221, 35.222, 35.223) TSs_and_TRs 36.523-1, 36.523-2, 36.523-3

Name Conformance Test Aspects – ZUC (EEA3 and EIA3 Encryption & Integrity EPS security Algorithms)

3GPP

The points to be further studied and potentially specified are: • • • Information to be stored in the HSS.2 Specification of Protection against Unsolicited Communication for IMS (SPUCI) UID_480039 Resources: UID 48003 9 S3 Finish 07/03/201 2 Hyperlink SP100428 WI_rapporteur NEC Notes SP#55 completed (No normative work). Subscribers should be protected against the annoyance that UC causes. and operators should be protected against the bandwidth use. NDS. Rogers Wireless. TR 33.g. Solve the Introduction Problem. Softbank Mobile.g. but not that related to common IMS. 3GPP . Since the same may become true also for IMS based communication (e. As unsolicited communication is expected to target IMS services. A technical report (TR 33. recommendations and solutions should be developed against UC in IMS that protects end customers and operator services. recommendations and solutions for protection against UC in common IMS should be developed by 3GPP SA3.937 "Study of Mechanisms for Protection against Unsolicited Communication for IMS (PUCI)". e-mail) to numerous recipients can be automated easily at no or negligible cost to the sender. Response from SS or 3rd party PUCI AS with possible SCORE and/or other PUCI information depending on configuration. NEC. AT&T. This development hinges upon the fact that setting up of communication (e. and SS. KDDI.1. UC can thus jeopardize the success of IMS and have strong impact on mobile operator’s business especially because IMS is expected to provide core services like voice. White Lists. NTT DoCoMo. Nokia.237. as opposed to real-time evaluation during session establishment. which is limited to offline checking of stored content. this could range from a simple flag up to a complete PUCI profile of the user because it is possible to store selected information in the HSS or in the PUCI AS. Therefore. The work done in IETF (RFC 5039) concludes that a combination of several techniques is needed and that four core recommendations that can be made: Strong Identity. the risk of denial-of-service.57 Overview of 3GPP Release 11 V0. Continuation of Rel-9 UID_410027/410029. Invoking of 3rd party PUCI AS or Supplementary Services (SS) depending on configuration. Nokia Siemens Networks. ST-Ericsson. Related Study Item or Feature (if any) UID Title 41002 Protection against Unsolicited 9 Communications in IMS (PUCI) Nature of relationship Builds on TR 33.937 Study of Mechanisms for PUCI TSs_and_TRs new TR 33. With the above issues in mind UC prevention solutions are being developed in several standardization bodies.937) on PUCI was developed by 3GPP SA3 where the identification. abandoned new TS 33. marking and reacting (IMR) and extension of supplementary services (SS) as well as using contextual information in combination with IMR and SS were studied. for IMS VoIP) – especially when IMS peering on a global scale starts to emerge – there is a real threat that UC will occur also in mobile communications networks developed by 3GPP. Therefore this WID proposes to start a more focused TR and TS on PUCI concentrating on specific items.237 Name Specification of Protection against Unsolicited Communication for IMS (produced TRonly) Supporting Companies: Alcatel-Lucent.937 studied general background and high level solution possibilities for PUCI and in the course of the work issues needing further studies were identified. TR 33.1 (2012-06) 6. and bad reputation that follows with UC. OMA is developing solutions on Categorization Based Content Screening (CBCS). Protection against UC in IMS should take advantage of IMS specific strengths and should minimize impact (if possible) and reuse already standardized solutions such as strong identities. TISPAN has already concluded a general feasibility study on preventing UC in the NGN in TR 187 009 and will now specify UC prevention solutions that handles specific issues related to TISPAN access in TS 187 034. and Don't Wait Until It's Too Late.838v200 for Approval & abandoned new TS 33. incorrect charging.937 "Study of Mechanisms for Protection against Unsolicited Communication for IMS (PUCI)" Justification In the e-mail environment the instance of spam – the common name used to refer to bulk Unsolicited Communication (UC) where the benefit is weighted in favour of the sender – has proliferated in recent years.838. Objective: to perform a focused study and develop a specification based on items identified in TR 33. Ericsson. China Mobile. 3GPP has the resp. Builds on TR 33. to take care of the common IMS part.

MMI-Aspects: Since UC prevention services may block certain traffic from the recipient user.1. initial Filtering Criteria. UC prevention services are expected to give customers more confidence in using existing and future IMS based communication services. Illustrative use of standardized PUCI features in typical deployment scenarios. Mitigation of source identity spoofing. The PUCI solution will adhere to the following design principles: • • • • • • • • • • • • No new capabilities are required on the IMS Core elements. how this information should be structured. contextual information). as not to impact the UE or usage experience. messaging. Furthermore. The SCORE and other PUCI related information will be defined at a generic level. ICS. special care must be taken to allow the user sufficient control over these services. For example SCORE and other PUCI related information can be carried in the SIP header as an optional information element. but if there is user notification. scoring information. thresholds. There will be new originating and terminating S-CSCF triggers. Charging Aspects: a customer may be charged for UC prevention services 3GPP . Use of existing methods of user notification for PUCI communication. Thereby being transparent to the IMS Core. If SCORE and other PUCI related information needs to be signalled between carriers. or even between which nodes the information should be sent.1 (2012-06) • • • • • • • • • What type of PUCI information should be exchanged (e. and how the different types of communication affect the PUCI solution. especially from non-IMS networks. Interworking with non-IMS networks. including PSTN users. only existing methods will be used. For example the support of iFC. where the thresholds are based on operator policy. Mapping of SCORE and other PUCI related information between carriers will be per interconnection agreements. PUCIF to PUCIF communication.g. PUCI processing may be performed on behalf of IMS and non-IMS users. with their specific meanings being left to operator policy. PUCI may apply to all IMS services to include and not limited to: session based services (voice. The invocation of PUCI. Types of communication that should/can be covered by PUCI. Also regulatory requirements concerning customer protection need to be satisfied. The TS will not mandate user notification or user interaction. National legislature and/or operator policy may impact the PUCI actions to be taken. No impacts to the UEs or its interfaces. If and how PUCI information should be sent inside SIP.58 Overview of 3GPP Release 11 V0. in S-CSCF as the basic IMS function is good enough to redirect SIP signals to a PUCI AS. it shall originate and terminate in a PUCI AS. and actions taken will be based on the contractual relationship between the user and the carrier. How much of PUCI that can be achieved via prevention and how much needs to be done via treatment. PUCI processing will be performed in an Application Server. video). and data delivery. If and how the proposed PUCI solutions interwork with SRVCC. and service continuity. For example PUCI AS can be triggered by utilizing the existing iFC. including the Gm interface or user interface. on the effectiveness of the PUCI mechanism. This will likely mean also coordination with IETF. Service Aspects: Allow operators to provide new UC prevention services for IMS to their customers (beyond what is available in today’s network).

59

Overview of 3GPP Release 11 V0.1.1 (2012-06)

6.3 H(e)NB security features for UE mobility scenarios (HNB_mob_Sec) UID_510053
Resources:
UID 51005 3

S3
Acronym HNB_mob_Sec Finish 07/03/201 2 Hyperlink SP110025 WI_rapporteur Huawei Notes SP#55 completed. Add HeNB Security extensions to Extended H(e)NB Features (EHNBF) UID_450053 TSs_and_TRs 33.320 Stage 2

Name H(e)NB security features for UE mobility scenarios (Stage 2)

Supporting Companies:

Alcatel-Lucent, Huawei, HiSilicon, NEC, ZTE
Nature of relationship adds extensions to features of Home NodeB/eNodeB

Related Study Item or Feature (if any) UID Title 450053 Extended H(e)NB Features (EHNBF)

Justification In Rele-8, Rel-9, and Rel-10, 3GPP has specified functionalities for the support of Home Node B (HNB) and Home eNodeB (HeNB). With ongoing work in RAN specification groups on various enhancements to support UE mobility between H(e)NBs, SA3 could not complete such security enhancements in support of work in RAN groups in Rel-10 timeframe. Objective: to specify security requirements for the following functionalities:

Support of UE mobility scenarios utilizing direct x2 interface between HeNB and HeNB Support of UE mobility scenario utilizing direct Iurh interface between HNB and HNB The work item applies to HeNB Subsystems and HNB Subsystems. Service Aspects: as defined in SA1 TS 22.220.

6.y Security enhancements for usage of GBA from the browser (Web_GBA) UID_520031 (moved to Rel-12)
Resources:
UID 52003 1

S3
Acronym Web_GBA Finish 20/06/201 2 Comp 50% Hyperlink SP110254 WI_rapporteur Nokia Notes Stage 2. SP#55 completion 03/12=>06/12 TSs_and_TRs 33.220, 33.222, new TR 33.823

Name Security enhancements for usage of Generic Bootstrapping Architecture (GBA) from the browser

Supporting Companies:

Nokia, Nokia Siemens Networks, China Mobile, AT&T, ST-Ericsson, Ericsson

3GPP

60

Overview of 3GPP Release 11 V0.1.1 (2012-06)

6.4 Generic Bootstrapping Architecture extensions for reuse of SIP Digest credentials (GBA-ext) UID_540012
Resources:
UID 54001 2 54011 2 54021 2

S3,C4,C1
Resource S3,C4,C1 S3 C4,C1 WI_rapporteur Nokia Nokia Alcatel-Lucent

Name Generic Bootstrapping Architecture (GBA) extensions for re-use of SIP Digest credentials Stage 2 Stage 3

UID 54011 2

Name Stage 2 for GBA extensions for re-use of SIP Digest credentials

Resource S3

Finish 07/03/201 2

Hyperlink SP110884

WI_rapporteur Nokia

Notes SP#55 completed

TSs_and_TRs 33.220

Supporting Companies: Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, AT&T, British Telecom, China Mobile, Ericsson, ST-Ericsson, Nokia Corporation, Nokia Siemens Networks, Qualcomm, Rogers Wireless , Intel Justification: This Work Item defines an extension of the Generic Bootstrapping Architecture (GBA) to allow the re-use of bootstrapping procedure based on a particular type of non-UICC credentials, namely SIP Digest credentials. GBA is a generic security tool or security enabler which can be used for a variety of purposes, e.g. bootstrapping security for accessing XCAP servers for user self-management over the 3GPP-defined Ut interface. The Generic Bootstrapping Architecture (GBA), as defined in 3GPP TS 33.220, provides a bootstrapping mechanism, but it is limited to UICC-based credentials. This means that SIP Digest credentials cannot benefit from GBA. SIP Digest credentials are user names and shared secrets, or passwords, which are stored in the HSS, and either in the terminal or held by the user. Extending the GBA bootstrapping procedure to re-use SIP Digest credentials for bootstrapping specific security would bring the benefit of not requiring a separate bootstrapping security infrastructure. In this way, using SIP Digest credentials as part of GBA bootstrapping procedure would reduce the cost of the security infrastructure for the operator whose subscribers use SIP Digest credentials, but do not have a UICC available. Objective : to specify Stage 2 requirements and mechanisms for allowing SIP Digest credentials to be re-used by an extension of the GBA bootstrapping procedures. Especially the following will be done; specify needed extensions to: Ub reference point to support re-use of SIP digest credentials for GBA Zh reference point to support re-use of SIP digest credentials for GBA Zn reference point to support re-use of SIP digest credentials for GBA, if any are identified

Currently no extensions are envisaged for Ua reference point since Ua reference point is application specific. The use of the extension of GBA that is the subject of this WID shall be restricted to environments where the UICC is not available to subscribers. Service Aspects The envisaged extension of GBA will permit devices with SIP Digest credentials, but without UICC to bootstrap security for manifold services, e.g. secure access to XCAP servers for user self-management, without the need for the deployment of a separate security infrastructure. This would ease the introduction of new services for the operators whose subscribers use SIPbased credentials. MMI-Aspects The MMI will be involved if the SIP Digest password is held by the user. Alternatively, the SIP Digest password can be securely stored in the terminal. The envisaged GBA extension could lead to an improved user experience on the MMI.
UID 540212 Name Stage 3 Resource C4,C1 Finish 07/09/2012 Comp 45% Hyperlink CP-110804 WI_rapporteur Alcatel-Lucent Notes Stage 3 TSs_and_TRs Stage 3

3GPP

61
540312 540412 CT4 part of Stage 3 CT1 part of Stage 3 C4 C1 07/09/2012 07/09/2012 90% 0%

Overview of 3GPP Release 11 V0.1.1 (2012-06)
CP-110804 CP-110804 Alcatel-Lucent Alcatel-Lucent 29.109 24.109

Justification: This Work Item defines an extension of the Stage 3 protocols of the Generic Bootstrapping Architecture (GBA) to allow the re-use of bootstrapping procedure based on a particular type of non-UICC credentials, namely SIP Digest credentials. GBA is a generic security tool or security enabler which can be used for a variety of purposes, e.g. bootstrapping security for accessing XCAP servers for user self-management over the 3GPP-defined Ut interface. The Generic Bootstrapping Architecture (GBA), as defined in 3GPP TS 33.220, provides a bootstrapping mechanism, but it is limited to UICC-based credentials. This means that SIP Digest credentials cannot benefit from GBA. SIP Digest credentials are user names and shared secrets, or passwords, which are stored in the HSS, and either in the terminal or held by the user. Extending the protocols of the GBA bootstrapping procedure to re-use SIP Digest credentials for bootstrapping specific security would bring the benefit of not requiring a separate bootstrapping security infrastructure. In this way, using SIP Digest credentials as part of GBA bootstrapping procedure would reduce the cost of the security infrastructure for the operator whose subscribers use SIP Digest credentials, but do not have a UICC available. Objective : to specify Stage 3 protocols additions for allowing SIP Digest credentials to be re-used by the extension of the GBA bootstrapping procedures. Especially the following will be done; specify needed protocols extensions to: Ub reference point to support re-use of SIP digest credentials for GBA if any are identified Zh reference point to support re-use of SIP digest credentials for GBA Zn reference point to support re-use of SIP digest credentials for GBA, if any are identified

No protocols extensions are envisaged for Ua reference point since Ua reference point is application specific. The use of the extension of GBA that is the subject of this WID shall be restricted to environments where the UICC is not available to subscribers. In particular, the extension of GBA shall not be used on terminals that support 3GPP access capabilities. MMI-Aspects The MMI will be involved when the SIP Digest password is held by the user, rather than in the terminal. The envisaged GBA extension could lead to an improved user experience on the MMI. 10 Expected Output and Time scale
Affected existing specifications Spec No. CRSubject Approved at plenary# Comments TS 29.109 Protocol extensions for SIP-Digest over Zh and possibly Zn CT#57 Sep 2012 Stage 3 specifications for GBA CT4 responsibility TS 24.109 Protocol possible extensions for SIP-Digest over Ub. CT#57 Sep 2012 Stage 3 specifications for GBA CT1 responsibility

3GPP

62

Overview of 3GPP Release 11 V0.1.1 (2012-06)

6.5 Lawful Interception in the 3GPP Rel-11 (LI11) UID_520032
Resources:
UID 520032

S3
Acronym LI11 Finish 20/06/201 2 Hyperlink SP110424 WI_rapporteur PIDS, AlcatelLucent Notes Stage 1/2/3. SP#56 completed TSs_and_TRs 33.106, 33.107, 33.108

Name Lawful Interception in the 3GPP Rel-11

Supporting Companies: Ministry of Economics and Technology (DE), Ericsson, Rogers Wireless, National Technical Assistance Centre (UK), Ministere de l'economie des finances et de l'industrie, BT, PIDS (NL), AT&T, Alcatel-Lucent, Vodafone, Federal Office for the Protection of the Constitution (DE), Technical Program Section (USA), Nokia Siemens Networks, Research In Motion. Justification: Study all relevant function and services of Rel-11 to fulfil the national requirements on interception. LI Considerations are necessary at least for following topics: o o o o o o o o o o Objective : CAT (Customer Alerting Tones) & CRS (Customized Ringing Signal), VCC (Voice Call Continuity) & Service Continuity IMS Media security, H(e)NB also with Local IP Access and Selected IP Traffic Offload eMBMS LCLS SIMTC IMS Enhancements EPS Enhancements Enhanced Location Reporting

to update LI specifications for the latest Rel-11 architecture and services as described above.

The enhancements to specifications TS 33.106, TS 33.107 and TS 33.108 addresses the additional work to specify the HI2 (Intercepted Related Information) and the HI3 (Content) interfaces to delivery to the Law Enforcement Monitoring Facilities for 3G networks for Rel-11. Additionally, SA3-LI has considered updating or withdrawing GSM LI's TR 41.033, TS 42.033 and TS 43.033.

3GPP

63

Overview of 3GPP Release 11 V0.1.1 (2012-06)

7 SA4 Features
UID 52003 3 53004 8 56004 0 56004 1 Name Extensions of Acoustic Test Specifications in TS 26.131 and TS 26.132 Enhancements to Multimedia: PSS, MMS, and MBMS Enhancements and Performance Improvements Coordination of Video Orientation Mobile 3D Video Coding Acronym Ext_ATS EMM CVO M3DV WI_rapporteur Orange, Qualcomm Qualcomm Ericsson Orange

7.1 Extensions of Acoustic Test Specifications in TS 26.131 and TS 26.132 (Ext_ATS) UID_520033
Resources:
UID 52003 3

S4
Acronym Ext_ATS Finish 12/09/201 2 Comp 60% Hyperlink SP110309 WI_rapporteur Orange, Qualcomm Notes TSs_and_TRs 26.131, 26.132

Name Extensions of Acoustic Test Specifications in TS 26.131 and TS 26.132

Supporting Companies:

Orange, Nokia, Qualcomm, Sony-Ericsson, Research in Motion

Justification Acoustics and speech processing in terminals have a strong impact on the perceived quality of voice services. The audio test specifications in TS 26.131 and TS 26.132 do not completely reflect all aspects influencing user experience. In particular, the existing objective methods are not sufficient to characterize modern voice quality enhancements embedded in terminals, such as noise reduction. Furthermore, some scenarios are not covered by 3GPP test specifications at all, e.g. Double Talk performance. Global Certification Forum (GCF) has liaised to 3GPP SA4 requesting enhancements of existing tests and the inclusion of new audio tests. Objective: to extend the requirements and test methods specified in TS 26.131 and TS 26.132, in particular in the area of Voice Quality Enhancement (VQE) embedded in terminals such as noise reduction, in particular: o o o o o Delay Tests Uplink Tests – including level dependency of SLR, background noise, etc Downlink Tests – including switching characteristics, speech quality, etc Extended Echo Tests Double talk Performance

No impact is expected in service requirements or architecture.
Affected existing specifications Spec No. CRSubject 26.131 Terminal acoustic characteristics for telephony; Requirements 26.132 Speech and video telephony terminal acoustic test specification Approved at plenary# SA#57 SA#57 Comments

3GPP

MMS. PSS. RAN2 notified SA4 that they have identified that current MBMS design does not take full account of service access or service continuity under certain conditions as listed below. and MBMS Enhancements and Performance Improvements UID_530048 Resources: UID 53004 8 53014 8 53024 8 53034 8 S4 Acronym EMM EMMEFEC EMM-DDE EMMIPME WI_rapporteur Qualcomm Qualcomm Qualcomm InterDigital Communications Name Enhancements to Multimedia: PSS.140. MMS. tablets). respectively. MMS and MBMS enhancements have to be specified in a consistent manner for UE capabilities and content preparation. Given that delivery of Dynamic Adaptive Streaming over HTTP (DASH) media segments over MBMS is possible to realize streaming services. it is felt necessary to review and extend the support of QoE in that context. AT&T.2 Enhancements to Multimedia: PSS. It is important for SA4 to continue enhancing the features and improving system performance for these services. MMS and MBMS services such as: • Given the Rel-10 and Rel-11 changes on video encoding and decoding capabilities in MTSI and PSS.g. The same would apply to PSS and MBMS services which may require upgrade of mandatory and recommended codec support given the wider availability of UEs with higher video rendering capabilities (e. 26.234. Intel. ST-Ericsson. In an LS (S4-110846). Fraunhofer Gesellschaft. Ericsson. Verizon Wireless Related Study Item or Feature (if any) UID Title 48004 PSS and MBMS enhancements 0 47003 Optimization of IMS based PSS and MBMS User 3 Service 47003 HTTP-based Streaming and Download Services 4 Nature of relationship Work to enhance and improve PSS and MBMS services Work to enhance and improve IMS-based PSS and MBMS services Work to specify 3GPP Dynamic Adaptive Streaming over HTTP (3GDASH) 3 Justification PSS services have been developed and enhanced over the last several releases in 3GPP SA4.263 support.247 Supporting Companies: Qualcomm. For example MMS encoding capabilities could be aligned to MTSI mandatory H. Current MBMS QoE metrics and/or reception reporting are focused on MBMS streaming and download delivery methods.2 as opposed to current H. With the introduction of eMBMS there has been a renewed interest in the MBMS User Service. 26. it is felt that MMS encoding capabilities would require an upgrade. Several aspects can be addressed to improve performance and enhance features in PSS.These upgrades would both improve user experience and simplify implementations. and MBMS Enhancements and Performance Improvements Enhancement to FEC for MBMS Download Delivery Enhancements for MBMS IMS-based PSS and MBMS Streaming Synchronization Enhancements UID 53004 8 Name Enhancements to Multimedia: PSS.1 (2012-06) 7.264 Constrained Baseline Profile level 1. Huawei. InterDigital.64 Overview of 3GPP Release 11 V0.  The circumstance of an MBMS user service being offered in an area where MBMS services are offered on a variety of radio frequencies • • 3GPP .1. MMS. and MBMS Enhancements and Performance Improvements Finish 12/09/201 2 Comp 55% Hyperlink SP120025 Notes Stage 3 TSs_and_TRs 26.

H.1 (2012-06)  • • The circumstance of an MBMS user service being available in less than all provisioned geographic MBMS service areas. Introduce a mechanism to assist service continuity. Support of synchronized media presentation across multiple devices can be enabled by defining procedures for synchronization of IMS-based PSS and MBMS streaming as described in the building block work item description for EMM-IPME. Modify or extend the QoE metrics and/or reception reporting to improve the applicability of the reported metrics. e. • Enhance IMS-based PSS and MBMS streaming in support of synchronized media presentation across multiple devices as described in the building block work item description for EMM-IPME. The performance and usability of the MBMS download delivery service can be improved to increase battery life and better support transport of DASH fragments over MBMS as described in the building block work item description for EMM-DDE.g. e. MMS and MBMS services in a consistent manner to improve video quality and simplify content preparation/adaptation. The PSS capability exchange mechanism can be enhanced to optimize multimedia delivery through the introduction of new UAProf attributes. • Improve the performance and usability of the MBMS download delivery service to improve battery life and optimize support for the transport of DASH fragments over MBMS as described in the building block work item description for EMM-DDE.264. for example in terms of radio frequency channels delivering the service and geographic areas where the service is available. 3GPP .g.65 Overview of 3GPP Release 11 V0. • • No impact is expected in service requirements or architecture. • • • Enhance PSS capability exchange mechanism by introducing new UAProf attributes into the PSS vocabulary in order to optimize multimedia delivery • Enhance the MBMS application layer FEC for more efficient and reliable operation as described in the building block work item description for EMM-EFEC. The objectives of the individual building block work items are independent of each other and can be completed according to their respective work plans. to better support live streaming of media segments of DASH over MBMS download. Objective to: • Update video codec support of PSS. align MMS support to MTSI video codec support and improve PSS/MBMS video codec mandatory support with e. The performance of the MBMS streaming and download delivery services can be enhanced by using a more efficient Forward Error Correction (FEC) as described in the building block work item description for EMM-EFEC.g.1.

After development of the initial MBMS specifications. e. the selection process shall favour open and available standardized FEC solutions.1 (2012-06) 7. Such FEC improvements can also provide more efficient support of MBMS use cases. Performance requirements for FEC decoders.66 Overview of 3GPP Release 11 V0. but are not limited to.346. Aspects of system performance which would provide benefit to the system include. new TR 26. • • • • Improving the bandwidth efficiency of streaming and download services delivery over MBMS Improving the reliability of streaming and download services delivery over MBMS. and test vectors for FEC encoders shall be specified. Architecture and functional description. by increasing the amount of tolerable lost packets for a given FEC overhead Reducing the required computational and memory resources for decoding in UEs Addressing backward compatibility issues by considering deployments of pre-Rel-11 MBMS FEC FEC solutions with similar evaluation results.2.” 3 Justification The on-going commercialization of LTE networks has precipitated increasing interest in the deployment of eMBMS. As the industry is considering the first deployments of eMBMS it is important to enhance the performance and usability of its core features.947 Name Enhancement to FEC for MBMS The proposed work is based on the existing Stage 2 specification TS 23.246 “Multimedia Broadcast/Multicast Service (MBMS). 3GPP .g. SA4 has focused its subsequent work on adding new features to the service. While application layer FEC usage in support of download and streaming delivery methods have been specified since Rel-6. Examples of ongoing FEC enhancement efforts are the latest activities in IETF’s RMT and FECFRAME working groups. those mechanisms have not been updated to reflect performance improvement developments in more recent years.947 v100 for Information TSs_and_TRs 26. Objective The objective of the work item is to investigate and evaluate the proposed FEC technologies and adopt one which provides the most significant enhancement to the performance of the MBMS system over the Rel-6 application layer FEC in MBMS.1. No impact is expected to the service requirements or architecture.1 Enhancement to FEC for MBMS (EMM-EFEC) UID_530148 Resources: UID 53014 8 S4 Acronym EMMEFEC Finish 12/09/201 2 Comp 65% Hyperlink SP120182 WI_rapporteur Qualcomm Notes SP#56 TR 26.

it is desirable to employ a single application transport protocol. offering benefits such as the ability of mobile clients to seamlessly and dynamically change content rate in reaction to changes in available bandwidth.g. As the industry is considering the first deployments of eMBMS it is important to enhance the performance and usability of its core MBMS user service features. Adaptive HTTP streaming has become the technology of choice for unicast multimedia content delivery in the Internet. user interactivity. targeted ads. new TR 26..234 and 3GP-DASH (Dynamic Adaptive Streaming over HTTP) in TS 26. with a focus on more efficient battery usage in MBMS devices. 3GPP . Other optimizations of the download delivery may be considered for improved support of emerging requirements. magazine distribution.) that can be enabled on an MBMS system have varying delivery requirements on file size and latency. A number of file delivery applications (catch-up TV. as more features and functions are incorporated into mobile devices. although mainly intended for Unicast transport with HTTP. DASH/HTTP streaming delivery is particularly attractive over mobile networks. the DASH segment format. and especially smart phones. Massive deployment of media content delivery using HTTP is likely to represent a strong alternative to. In the meantime. No impact is expected to the service requirements or architecture. Currently in MBMS. Benefits include enabling support for new non-real-time service types. the use of RTP for streaming content delivery. by providing the client with timing information and/or location information on when/where to switch on/off the MBMS reception. streaming and download services are delivered using different application transport protocols. if not replace. for both download and streaming services delivery.247 from Rel-10. For simplicity at both the network and user device sides. etc. is agnostic of the delivery environment being unicast or multicast.9yz (TR on EMM. thus making it necessary to continually enhance the service to improve battery consumption.246 “Multimedia Broadcast/Multicast Service (MBMS). Objective to: • Optimise the performance of download delivery over MBMS. Streaming services delivery employ RTP. The scheduling of available files for transmission should strive to optimize the utilization of available delivery resources. 3GPP specified HTTP streaming over mobile networks as AHS (Adaptive HTTP Streaming) in Rel-9 TS 26. MBMS download delivery is an attractive service alternative for offloading HTTP-based unicast download delivery. namely FLUTE. Architecture and functional description. provision of contents that complement MBMS streaming services.346 (Rel-9) already indicates the possibility for AHS/DASHformatted content to be transmitted using MBMS download delivery with the FLUTE protocol. whereas download services are delivered using FLUTE/ALC. The MBMS User Service specification TS 26. There is a need to optimize and give guidelines on the delivery of live streamed DASH content over MBMS download.2. avoiding the separate use of RTP for broadcast streaming delivery. leveraging the use of standard HTTP servers and caches in Content Delivery Networks (CDN). and leveraging the increasing storage capacity on devices. In addition. and ease of NAT and firewall traversal using HTTP. DDE and IPME Aspects) Name Download Delivery Enhancements for MBMS The proposed work is based on the existing Stage 2 specification TS 23.2 Download Delivery Enhancements for MBMS (EMM-DDE) UID_530248 Resources: UID 53024 8 S4 Acronym EMMDDE Finish 11/09/201 2 Comp 50% Hyperlink SP120025 WI_rapporteur Qualcomm Notes TSs_and_TRs 26. firmware and software updates.” 3 Justification The on-going commercialization of LTE networks has precipitated increasing interest in the deployment of eMBMS.1. battery life consumption continues to be a key factor impacting the user experience. e. It is also important for user experience to maintain the level of service continuity provided by RTP over MBMS and Unicast (PSS streaming) with DASH over HTTP unicast and MBMS broadcast.1 (2012-06) 7. The deployment of MBMS has the potential to further load mobile device batteries.67 Overview of 3GPP Release 11 V0.346.

1 (2012-06) • Develop enhancements to enable more efficient use of available transmission resources to meet varying requirements of download delivery applications. WG(s)Presented for information at plenary# SA4 SA#56 Affected existing specifications Subject Multimedia Broadcast/Multicast Service (MBMS). allowing for varying FEC protection.9yz Technical Report on EMM.g. media segments of DASH. in particular. QoS. Define optimizations and guidelines for live streaming of media segments. 26. Protocols and codecs Approved at plenary# SA#57 Comments Approved at plenary#Comments SA#57 3GPP . by enabling MBMS services to be separated across several MBMS bearers.346 New specifications Prime rsp.g.. 26.. over MBMS download Define mechanisms to enable continuity between unicast/HTTP and broadcast/FLUTE delivery of DASH content • • • The use cases.. DDE and IPME Aspects Spec CR No. working assumptions. by enabling MBMS services to be multiplexed onto an MBMS bearer thereby reducing TMGI proliferation (of firmware over-the-air for example). e. WG2ndary rsp.1.68 Overview of 3GPP Release 11 V0. e. Improve the usability of download delivery over MBMS. solution proposals. 10 Expected Output and Time scale Spec Title No. requirements. etc. evaluation and conclusion will be documented in a TR.

These devices may be connected to the core network/multimedia service provider via different access networks and experience different delays. No impact is expected in service requirements or architecture. Enhance IMS-based PSS and MBMS streaming user service delivery in support of synchronized media presentation across multiple devices belonging to the same IMS subscription.246 “Multimedia Broadcast/Multicast Service (MBMS).114.9xy (TR on EMM. Objective to: • • Identify use cases to be addressed for synchronized media presentation across multiple devices. o Multi-device synchronization handling in inter-UE transfer and replication The use cases. requirements. evaluation and conclusion will be documented in a TR.237. in order to ensure presentation synchronization between media components. DDE and IPME Aspects) Name IMS-based PSS and MBMS Streaming Synchronization Enhancements The proposed work is based on the existing Stage 2 specifications TS 23. Stage 2.69 Overview of 3GPP Release 11 V0. e. and document the adopted use cases in a TR.2.3 IMS-based PSS and MBMS Streaming Synchronization Enhancements (EMM-IPME) UID_530348 Resources: UID 53034 8 S4 Acronym EMMIPME Finish 12/09/201 2 Comp 50% Hyperlink SP120025 WI_rapporteur InterDigital Communications Notes TSs_and_TRs 26. or video and audio bitrates change. the problem of presentation synchronization is further exacerbated when media sessions or media flows require synchronization when being presented on different UEs. working assumptions. no standard procedures currently exist in 3GPP to facilitate such multi-device playback synchronization.” and TS 23. for example audio and video lip sync.” TS 23.g. However.” Justification Ensuring media presentation synchronization is important in PSS and MBMS streaming services. a number of techniques can be applied such as those specified in 3GPP TS 26. such as football games.g.1 (2012-06) 7. new TR 26.228 “IP Multimedia Subsystem (IMS). Architecture and functional description. e. the video is sent to a mobile device or a large display but the audio is sent to a sound system. or the access networks change. include definition of the procedures for o Multi-device synchronized session initiation o Multi-device synchronized session termination o Modification of the group of devices that are synchronized. For example. despite watching on different screens. • 10 Expected Output and Time scale 3GPP . for example. Nonsynchronized playback is a bad user experience. The lip sync across user devices is required as a video stream and its associated audio streams are sent to different devices for playback. The media presentation should keep synchronized across multiple devices when the underlying network conditions.1. solution proposals.237 “IP Multimedia Subsystem (IMS) Service Continuity. e.g. This may. When media flows are received by a user device (UE). However. when a device does not want to be synchronized with other devices any more.237 and TS 26. 3/4G to WiFi or vice versa. Synchronized media presentation across multiple UEs is required for good user quality of experience in certain PSS and MBMS services. The enhancements to 3GPP PSS and MBMS streaming services delivery to support standardised and interoperable methods of media presentation synchronization across multiple devices will improve user quality of experience. users want to be synchronized in live services or certain on-demand services. Stage 2.

1.237 Prime rsp.70 Overview of 3GPP Release 11 V0.9yz TR on EMM. Protocols 3GPP . 26.1 (2012-06) Spec Title No. WG SA4 Subject New specifications 2ndary rsp. WG(s) Presented for information at plenary# Approved at Comments plenary# SA#56 SA#57 Affected existing specifications Approved at plenary# SA#57 Comments IP Multimedia Subsystem (IMS) based Packet Switch Streaming (PSS) and Multimedia Broadcast/Multicast Service (MBMS) User Service. 26. DDE and IPME Aspects Spec CR No.

a device may be sending video of landscape format (width > height) to another device whose display was rotated to a portrait format (width < height). Orange. PSS and MBMS services.346 Name Coordination of Video Orientation Supporting Companies: Ericsson. IR.346) for services where the capturing device may be rotated.74.1 (2012-06) 7. used to capture. Objective: To resolve the video orientation mis-alignment issues experienced in MTSI real-time video communication via interaction between MTSI video clients at both call setup and during mid-call of the video orientation for correct local rendering. This typically happens when the sending device’s camera does not encode the captured image’s width and height in accordance with a gravity sensor.234) and MBMS (Multimedia Broadcast/Multicast Service – TS 26. R C Subject Approved at plenary# Comments 26. Note that the problem on the sender side is hidden when the device orientation happens to align with the camera sensor orientation.TS 22.94 profiles. the orientation of the transmitted image will under certain conditions not align correctly with the receiving device display.84 and IR.346 Video orientation for MBMS 58 26. ST-Ericsson.1.141. Several examples of such mis-alignments are detailed in Tdocs S4-120684 and S4-120718. the solution should also be applicable to CSI (Combination of CS and IMS services . but it should be applicable to CSI.3 Coordination of Video Orientation (CVO) UID_560040 Resources: UID 56004 0 S4 Finish 12/12/201 2 Comp 0% Hyperlink SP120228 WI_rapporteur Ericsson Notes resolve backward compatible video orientation misalignment issues in MTSI realtime video communication via interaction between MTSI video clients at call setup & during mid-call of the video orientation for correct local rendering TSs_and_TRs 26. Useful solutions that are not only applicable to 3GPP should be taken to be specified in IETF. 26.234 Video orientation for PSS 58 26. Therefore in the course of this work TSG SA WG4 should communicate with IETF to get guidance in what solution to prefer for dynamically changing image and video orientation during an established session.114 Video orientation for MTSI 58 26. 26. Research In Motion Justification With the introduction of gravity sensors in recent mobile devices. 10 Expected Output and Time scale Affected existing specifications Spec No.71 Overview of 3GPP Release 11 V0. Interdigital Communications. The solution should be backward compatible.84 (RCS video share)).74 and IR. While the main objective is focused on MTSI. profiled in GSMA IR.279 and TS 26. HiSilicon. RealNetworks. compress and transmit images.141. and when the receiving device display does use a gravity sensor to adapt display contents. Huawei.141 Video orientation for CSI 58 3GPP . A solution is in particular required for GSMA IR. or vice versa (camera uses a gravity sensor but the display does not). Verizon Wireless. For example. This can occur at session setup and during the session.234. A standardized solution to this mis-alignment problem is urgently required by the industry to ensure proper operation of MTSI video between devices of various shapes and display resolutions. Samsung. RTP based PSS (Packet Switch Streaming – TS 26. No impact is expected in service requirements or architecture.114. the display content can commonly be rotated to be aligned with the device orientation. Service Aspects: MTSI is the main service targeted. 26. When the mobile device used for real-time video communication has one or more integrated cameras.

MBMS. Deutsche Telekom. The technical objective is to enable 3D use cases in selected 3GPP services. RealNetworks. For each use case. ST-Ericsson. Interdigital Communications. 10 Expected Output and Time scale Affected existing specifications Spec No. Objective: to focus on the main 3D use cases.905. as well as download and progressive download services.1 (2012-06) 7. possibly including 3D Timed Text and Graphics. Download and Progressive Download. 26. Motorola Mobility Related Study Item or Feature (if any) Unique ID Title 520036 Study On Mobile 3D Video Coding Nature of relationship The study-item objectives were to collect 3D use cases and identify the deltas to existing TS to support these use cases.346. No impact is expected in service requirements or architecture. 26. MBMS. 26. R C Subject Approved at plenary# Comments 26.245 Mobile 3D Video Coding in Timed Text Format 57 3GPP . For each set of omissions. Qualcomm.905 “Mobile Stereoscopic 3D Video” recommends the inclusion of 3D video into selected 3GPP services. thanks to rendering technologies such as a parallax barrier or a lenticular lens sheet. The emerging 3GPP access networks such as LTE. MMS.430 Mobile 3D Video Coding in Timed Graphics 57 26.4 Mobile 3D Video Coding (M3DV) UID_560041 Resources: UID 56004 1 S4 Finish 12/09/201 2 Comp 0% Hyperlink SP120229 WI_rapporteur Orange Notes Triggered by UID_520036 Rel-11 Study on Mobile 3D Video Coding (FS_M3DVC) TR 26. The produced Technical Report TR 26. in the following identified services: PSS. In support of this.244 Mobile 3D Video Coding File Format 57 26. HiSilicon.905.234 Mobile 3D Video Coding for PSS 57 26. when applicable • signalling and format support • legacy and backward-compatibility issues The evaluation and selection process for the proposed improvements will be documented in TR 26. This includes. 26. Nokia.247. Justification The first 3D video capable mobile devices were released in 2011.245.346 Mobile 3D Video Coding for MBMS 57 26. Ericsson. 26.72 Overview of 3GPP Release 11 V0. but is not limited to: • Selection of the 3D stereo formats (and if applicable the corresponding codecs) • codec profiling. DASH.905. technical solutions need to be specified in the relevant 3GPP specifications. Intel. They offer a 3D experience based on the depth rendering of stereoscopic 3D video contents.140 Mobile 3D Video Coding for MMS 57 26. and DASH.430. the corresponding gaps are documented in TR 26. such as streaming over PSS.140.247 Mobile 3D Video Coding for DASH 57 26. The listed services are provided in the order of priority and the objective of the work item is expected to be achieved even if only a subset of the listed service specifications would be updated.905 Name Mobile 3D Video Coding Supporting Companies: Orange. Huawei. 26. 26. Samsung.244. by virtue of providing increased bitrates compared to pre-LTE radio access technologies will enable a better quality of experience of the 3D content delivery. the TR identifies the gaps in the relevant 3GPP specifications in order to support the prioritized 3D use cases. Fraunhofer IIS. Service Aspects: The updates of the 3GPP specifications will enable support for 3GPP stereoscopic 3D video. The recent Study Item on Mobile 3D Video Coding has collected a set of 3D use cases and provided corresponding technical analysis and performance evaluations.1.234. TSs_and_TRs 26.905 Further findings on Mobile 3D Video Coding 57 26.

Ericsson. Different parts of the large FMC network may be managed by different organizations. Huawei 8.xy1. the services offered to end users need resources from networks of different technologies.1. Maintenance and Provisioning (OAM&P) Rel-11 Network Infrastructure Management IRP framework enhancements to support Management of Converged Networks Management of Carrier Aggregation for LTE Network Management for 3GPP Interworking WLAN Rel-11 Performance Management IMS Performance Management enhancements Enhanced Management of UE based network performance measurements CN performance measurements enhancement Rel-11 Self-Organizing Networks (SON) . Ericsson. Their managed resource models are mostly different from one another. Maintenance and Provisioning UID_510051 UID 51005 1 51015 1 51005 6 53004 9 53005 0 51025 1 51005 7 51005 8 52003 4 51035 1 51005 9 53005 1 54003 1 Name Rel-11 Operations.622. Ericsson China Mobile ZTE Huawei.73 Overview of 3GPP Release 11 V0. NM standards of different technologies are the responsibilities of various standardization organizations (SDOs).abc (Various existing NRM IRPs). Administration. Various SDOs may have defined different NM protocols to manage their respective network resources.1 IRP framework enhancements to support Management of Converged Networks UID_510056 Resources: UID 510056 S5 Acronym OAMFMC-IRP Finish 12/09/201 2 Comp 45% Hyperlink SP110139 WI_rapporteur Nokia Siemens Networks. 32. Our key challenge of IRP Framework Enhancements in support of Management of Converged Networks is to recommend a set of specifications whose implementations would a) reduce FMC operators’ CAPEX and OPEX and b) facilitate OSS to integrate the various NM services consumed into the so-called “end-to-end” view of the FMC network under management. 32.xy3) Name IRP framework enhancements to support Management of Converged Networks Supporting Companies: Justification Alcatel-Lucent. 32. Huawei.101. Administration. 32. NEC.OAM aspects UTRAN Self-Organizing Networks (SON) management LTE Self-Organizing Networks (SON) coordination management Inter-RAT Energy Saving Management Acronym OAM11 OAM11-NIM OAM-FMC-IRP OAM-CA OAM-IWLAN OAM11-PM OAM-ePM-IMS OAM-ePM-UE OAM-ePM-CN OAM11-SON OAM-SON-UTRAN OAM-SONLTE_COORD OAM-IRAT-ESM WI_rapporteur Nokia Siemens Networks.833. Nokia Siemens Networks Nokia Siemens Networks.828.831 TSs_and_TRs 32. Nokia Siemens Networks In a Fixed Mobile Convergent (FMC) network.Rel-11 Operations.152. Ericsson Notes Triggered by SA5 Studies TR 32.xy2. Motorola.1 (2012-06) 8 SA5 Features . 3GPP . Nokia Siemens Networks China Mobile Huawei Huawei. Ericsson Nokia Siemens Networks. 32. 32. 32. new TS (32.

3].101: Telecommunication management.1.622: Telecommunication management. Configuration Management (CM). Issue CRs to “TS 32. that identifies various network resource models and their relations among each other. its stage 1 specification will capture the Requirements. 2. this WI needs also to produce recommendations on NM standard governance and working procedures with SDOs involved. IRP IS UML repertoire to capture new stereotypes required for the support of Resource Model Enhancements in support of Management of Converged Networks.g. Transport Network Interface IRP) to support the Management of Converged Networks.831: Study on Alignment of 3GPP Performance Management and TIP Performance Management. Principles and high level requirements” to capture the concept. context and use cases for the Management of Converged Networks. • • • • • This WI will also take into account use cases and requirements developed by NGMN relating to the management of converged networks.828: Study on Alignment of 3GPP Generic NRM IRP and TMF SID Model. Issue CRs to “TS 32. called Federated Network Model (FNM). Ref [1]: 3GPP TR 32. 3GPP . this new TS series will also capture the Working Procedures and Governance that are required to be established to support requirements for Management of Converged Networks Issue CRs to “TS 32.1 (2012-06) Since definitions of network resource models are from different SDOs and the provision of the “end-to-end” view requires defined relations among network resource models.833: Study on Management of Converged Networks. Since some specifications recommended. its stage 2 specification will capture the list of NRM IRPs and Interface IRPs that support the requirements for Management of Converged Networks. general requirement and FNM.152: Telecommunication management. Network Resource Model (NRM)” to align its model to support the Management of Converged Networks. Generic network resources Integration Reference Point (IRP). this WI will produce a model architecture. Ref [2]: 3GPP TR 32. benefits. Keep backward compatibility with existing 3GPP NRMs as much as possible. Ref [3]: 3GPP TR 32. including the network resource models. Objective: • Based on the recommendations and studies results of [1. Issue CRs to various NRM IRP specifications (e.74 Overview of 3GPP Release 11 V0. are from other SDO than 3GPP. the objectives of this WI are to: Create a new TS series on Management of Converged Networks.

part: Carrier Aggregation for LTE (LTE_CA-Perf) TS TSG RAN Rel-10 Feature 36. 36.1. for example how to measure number of users/E-RABs in the measured EUtran Cell which acts as Pcell or Scell for some UEs. China Unicom.502.541. The management aspects that need to be particularly taken into account for CA include: • • performance measurements and KPIs to evaluate the E-UTRAN that supports CA. and at RRC connection re-establishment/handover. Ericsson Notes Stage 2 in Rel10 RAN Feature UID_460007 Carrier Aggregation for LTE (LTE_CA). 36.413.133.501. TAI).211. 36. 32.e. Alcatel- Corresponding stage 2 work item (if any) UID Title 46000 7 46010 7 46020 7 Carrier Aggregation for LTE (LTE_CA) Core part: Carrier Aggregation for LTE (LTE_CA-Core) Perf.761.133. Huawei. 36. 36.2 Management for Carrier Aggregation for LTE UID_530049 Resources: UID 530049 S5 Acronym OAM-CA Finish 12/09/201 2 Comp 30% Hyperlink SP110636 WI_rapporteur Nokia Siemens Networks.1 (2012-06) 8. 32.321. 36.104 36.808) Parent Building Block Unique Title ID 510151 Network Infrastructure Management 510251 Performance Management 510351 Self-Organizing Networks (SON) .212.104. existing mechanisms (e.511.104.306.75 Overview of 3GPP Release 11 V0.141. 37. the management aspects required for CA also need to be addressed.302. CA is supported for both contiguous and non-contiguous CCs. CCs originating from the same eNB need not to provide the same coverage. China Mobile. 32. 36.101.141.762.807. 32. two or more component carriers (CCs) are aggregated in order to support wider transmission bandwidths (up to 100MHz). SON) TSs_and_TRs 32.331. the UE only has one RRC connection with the network. NEC Nokia Siemens Networks.g. 3GPP .g. 32. PM. 32. 36. 32.766 Name Management of Carrier Aggregation for LTE Supporting Companies: Lucent.506. 32. 37. When CA is configured. 36. 32.450. 36. PCell can only be changed with handover procedure (i. with security key change and RACH procedure). 36. 36. At RRC connection establishment/re-establishment/handover. 32.101. required configurations to support CA. 36. barring) may be used to avoid Rel-8/9 UEs to camp on a CC. only the PCell provides the security input. 32. new TR (36. 36. In Carrier Aggregation (CA). CCs are LTE Rel-8/9 compatible. Ericsson.425. 36.300. To support CA. ZTE. Secondary Cells (SCells) can be configured to form together with the PCell a set of serving cells.451.213. only the Primary Cell (PCell) provides the NAS mobility information (e.423. 36. 32. WT under 3 SA5 Rel-11 BBs (NIM.OAM aspects TS N/A N/A N/A Justification Carrier Aggregation (CA) in LTE is a feature supported from Rel-10.551.522. For each SCell the usage of uplink resources by the UE in addition to the downlink ones is configurable (the number of DL SCCs (Secondary Component Carriers) configured must always be larger or equal to the number of UL SCCs and no SCell can be configured for usage of uplink resources only).521. Depending on UE capabilities.526. 32. 32. Nevertheless.

EM-centralized and distributed SON architectures. MRO.761 SA#57 Sep 2012 E-UTRAN NRM IRP Requirements 32. to take the radio bearer reconfiguration/failures with Scell(s) also into account in MRO.76 Overview of 3GPP Release 11 V0..502 SA#57 Sep 2012 Self-establishment of eNodeBs: Information Service 32.451 SA#57 Sep 2012 E-UTRAN KPI: Requirements 32.1 (2012-06) • • Objective to: - enhancements to support SON functionalities for CA in NM-centralized.541 SA#57 Sep 2012 Self-healing Requirements 32.551 SA#57 Sep 2012 Energy Saving Management: Concepts and Requirements 32. the existing mechanisms and definitions shall be reused as much as possible.1.511 SA#57 Sep 2012 ANR Concepts and Requirements 32. To minimize the backward impact introduced by CA management.766 SA#57 Sep 2012 E-UTRAN NRM IRP Solution Sets 32.501 SA#57 Sep 2012 Self-establishment of eNodeBs: Requirements 32. e. CCO and Self-healing in CA. MLB. and provide solutions identify the use cases and requirements for Energy Saving in CA and provide solution extensions address other management aspects for CA if any To fulfil the objectives above. identify required performance measurements and KPIs to support CA management specify required configurations for CA management identify the use cases and requirements for SON functionality Self-establishment of eNodeB.506 SA#57 Sep 2012 Self-establishment of eNodeBs: Solution Sets 3GPP .g.521 SA#57 Sep 2012 SON Policy NRM IRP Requirements 32. R C Subject pproved at plenary# A Comments 32. coordination with RAN groups may be needed. energy saving perspective in CA.522 SA#57 Sep 2012 SON Policy NRM IRP Information Service 32.526 SA#57 Sep 2012 SON Policy NRM IRP Solution Sets 32.425 SA#57 Sep 2012 E-UTRAN performance measurements 32.762 SA#57 Sep 2012 E-UTRAN NRM IRP Information Service 32. E-UTRAN ANR.450 SA#57 Sep 2012 E-UTRAN KPI: Definitions 32. 10 Expected Output and Time scale Affected existing specifications Spec No.

234 TS 23. Rel-8 Mobility between 3GPP-WLAN Interworking and 3GPP Systems (IWLAN_Mob) 23. 32. Specifically.327: "Mobility between 3GPP-Wireless Local Area Network(WLAN) interworking and 3GPP systems". Performance measurements) Name Network Management for 3GPP Interworking WLAN Supporting Companies: China Mobile.234 provides the system description for inter-working between 3GPP systems and WLANs. WAG WLAN Access Gateway PDG Packet Data Gateway 3GPP AAA Server 3GPP AAA proxy 3GPP . 32.234.77 Overview of 3GPP Release 11 V0. Rel-7 WLAN Interworking – Private Network access from WLAN 3GPP IP Access (WLANPNA) 23. IS.roaming and roaming WLAN inter-working reference models are presented. AT&T. information management objects and performance data serving for inter-working architecture between 3GPP system and WLAN have not been defined yet.1.752.756. The inter-working architecture between 3GPP system and WLAN has been specified in several SA2 specifications. 8 new TS (3GPP interworking WLAN NRM IRP: Reqs.234 TS 23.327.234. the following TS specification is proposed to specify IWLAN architecture and corresponding procedures 3GPP TS 23. System description". Huwei.234: "3GPP system to Wireless Local Area Network (WLAN) interworking. WT under 2 SA5 Rel-11 BBs TSs_and_TRs 32. However. ETRI. TS 23. Some new network elements have been introduced as listed below. SS.1 (2012-06) 8.3 Network Management for 3GPP Interworking WLAN UID_530050 Resources: UID 53005 0 S5 Acronym OAMIWLAN Finish 12/09/201 2 Comp 15% Hyperlink SP110521 WI_rapporteur China Mobile Notes Stage 2 in Rel-6 WLAN-UMTS Interworking (WLAN) 23.632.636. Deutsche Telekom TS TS 23.327 Corresponding stage 2 work item (if any) Unique Title ID 31012 32110 370049 Rel-6 WLAN-UMTS Interworking Rel-6 (WLAN) Rel-7 WLAN Interworking – Private Network access from WLAN 3GPP IP Access (WLANPNA) Rel-8 Mobility between 3GPP-WLAN Interworking and 3GPP Systems (IWLAN_Mob) Parent Building Block Unique Title ID 510151 Network Infrastructure Management 510251 Performance Management TS N/A N/A Justification Network Resource Model (NRM) and Performance Management (PM) are important for operators to manage their networks. 32. ZTE. Regarding to 3GPP network interworking with WLAN. Intel. the non. 3GPP TS 23.

s2b and s2c) have been introduced to perform IP mobility. Objective to: • Specify NRM IRP requirements for 3GPP inter-working WLAN • Specify NRM for 3GPP inter-working WLAN including new defined network elements (WAG. PDG. HA. Information Service (IS) 3GPP interworking WLAN Network Resource Model (NRM). TS 23. Solution Set (SS) definitions Performance Management (PM).1 (2012-06) Accordingly. Integration Reference Point (IRP). Several new reference points(s2a. 3GPP AAA server/proxy. Presented for Approved at plenary# WG information at plenary# SA5 SA#56 Jun 2012 SA#57 Sep 2012 SA5 SA5 SA5 SA5 SA5 SA5 SA5 SA#56 Jun 2012 SA#56 Jun 2012 SA#56 Jun 2012 SA#56 Jun 2012 SA#56 Jun 2012 SA#56 Jun 2012 SA#56 Jun 2012 SA#57 Sep 2012 SA#57 Sep 2012 SA#57 Sep 2012 SA#57 Sep 2012 SA#57 Sep 2012 SA#57 Sep 2012 SA#57 Sep 2012 3GPP . Integration Reference Point (IRP).402 provides the architecture for interworking between Evolved 3GPP Packet Switched network and WLAN.4xx 3GPP interworking WLAN Resource Model (NRM). Integration Reference Point (IRP). Wi.xxx TS xx.327 has addressed some issues related to IP mobility. Wi. the following TS specification is proposed to specify IWLAN architecture and corresponding procedures 3GPP TS 23. Gn'. Information Service (IS) Evolved 3GPP interworking WLAN Network Resource Model (NRM). Solution Set (SS) definitions Performance Management (PM). Requirements Evolved 3GPP interworking WLAN Network Resource Model (NRM).78 Overview of 3GPP Release 11 V0. Performance measurements for evolved 3GPP interworking WLAN Prime rsp. Regarding to evolved 3GPP interworking with WLAN. Integration Reference Point (IRP).xxx TS xx. etc) • • • Specify Solution Set for 3GPP inter-working WLAN Specify performance measurements for 3GPP inter-working WLAN Specify NRM IRP requirements for evolved 3GPP network inter-working WLAN • Specify NRM for evolved 3GPP network inter-working WLAN including new defined network elements (ePDG. Management Information Objects and Performance Management data for these new network elements and interfaces should be added in order to fulfil the management requirements from the growing 3GPP/WLAN interworking network. s2b and s2c) • • Specify performance measurements for evolved 3GPP inter-working WLAN Specify Solution Set for evolved 3GPP inter-working WLAN 10 Expected Output and Time scale New specifications Spec No. LMA and MAG) and related reference points(s2a.402: "Architecture enhancements for non-3GPP accesses". etc) have been introduced as well. in which Home Agent (HA) and a new reference point H1 are introduced. Integration Reference Point (IRP). Wu. TS 23. Performance measurements for 3GPP interworking WLAN Evolved 3GPP interworking WLAN Resource Model (NRM).1. Integration Reference Point (IRP).xxx TS xx. 3GPP AAA server/proxy and HA) and related reference points(Wn.xxx TS xx. Depending on the IWLAN architecture. Evolved Packet Data Gateway (ePDG) has been introduce to handle untrusted non-3GPP IP access.Title TS xx.xxx TS xx.4xx TS xx. Requirements 3GPP interworking WLAN Network Resource Model (NRM). some new reference points (Wn. Wp.xxx TS xx.

79 Overview of 3GPP Release 11 V0. Core network resources IRP.1.636 TS 32. Solution 2012 Set Definitions SA#57 Sep Configuration Management. GERAN network resources IRP.632 TS 32.1 (2012-06) Spec No. GERAN network resources IRP.756 Add 3GPP interworking WLAN management Add 3GPP interworking WLAN management Add 3GPP interworking WLAN management Add 3GPP interworking WLAN management Affected existing specifications Approved at Comments plenary# SA#57 Sep Configuration Management. 2012 Network Resource Model SA#57 Sep Configuration Management. Core Network Resources IRP. CR Subject TS 32.752 TS 32. 2012 Solution Set definitions 3GPP . Network 2012 Resource Model SA#57 Sep Configuration Management.

237.883 23. ECT.4 IMS Performance Management enhancements UID_510057 Resources: UID 510057 S5 Acronym OAM-ePMIMS Finish 07/03/201 2 Hyperlink SP110134 WI_rapporteur ZTE Notes SP#55 completed TSs_and_TRs 32. 23.173 22. CF.101 Justification Performance Management (PM) is important for operators to manage their networks.167 UID 40004 4 44015 2 47002 7 Else. Vodafone. CCNR.228 22. CCBS.g. 23.409 SA#54 Dec 2011 Affected existing specifications Comments Performance measurements IP Multimedia Subsystem (IMS) 3GPP . a number of additional ones still need to be defined such as ACR. corresponding stage 1 work item Title Stage 1 for eMMTel Rel-9 Stage 1 .409. 23. etc. Orange Corresponding stage 2 work item (if any) Title Stage 2 .1. 23.838. China Unicom. Examples of IMS performance measurements for standardization: • • • Emergency session related measurements MMTel AS and supplementary services related measurements IMS Service Continuity related measurements 10 Expected Output and Time scale Spec No. Policy and Interactions Rel-9 Stage 2 . 3PTY. 23. MWI. FA.1 (2012-06) 8. a set of performance management measurement definitions shall be defined based on well described use cases.409 Name IMS Performance Management enhancements Supporting Companies: Stage 3 UID 410034 410035 450029 470028 ZTE. In order to monitor and evaluate the whole IMS network performance. Furthermore.292. CAT. not only MMTel AS supplementary services but also other IMS based services e.80 Overview of 3GPP Release 11 V0.292. Although some IMS supplementary services related measurements have been described in TS 32. CD. MCID. 23.IMS Centralized Services Rel-9 Stage 2 . Objective: For IMS performance measurement enhancement work. Currently performance measurements for IMS have been defined in SA5 TS 32.292. CUG.831 23. the related IMS services performance management enhancements should be made.IMS Service Continuity Enhancements: Service. emergency call services IMS Centralized Services and IMS Service Continuity have been studied and standardised in 3GPP. CW. CRSubject Approved at plenary# 32.237.216 23.IMS Inter-UE Transfer enhancements Stage 2 for IMS Emergency Session Enhancements Rel-10 TS 23.409 but the content is still far away from completion.IMS Service Continuity – Inter Device Transfer enhancements Stage 1 for IMS Emergency Session Enhancements Rel-10 TS 22.. with the evolved IMS specifications in 3GPP stage 1 and stage 2. China Mobile.

32.5 Enhanced Management of UE based network performance measurements UID_510058 Resources: UID 51005 8 S5 Acronym OAMePM-UE Finish 12/09/201 2 Comp 60% Hyperlink SP110135 WI_rapporteur Huawei. Nokia Siemens Networks Notes TSs_and_TRs 32. The operations for MDT management and procedures for MDT data propagation will make use of the existing SA5 solutions as much as possible.1 (2012-06) 8. 32. Alcatel-Lucent. The following aspects are required to be specified: Define the procedures/mechanisms to get accurate location information. Investigate whether MDT needs to be enhanced to further reduce OPEX.  Define the configuration support to more MDT measurements according to RAN working progress. The location availability was intensively discussed in Rel-10 but could not be finalized due to time limitation. NEC. It would be beneficial to continue the work in Rel-11:  Location coordination in eNB  Location coordination in MME Location coordination in UE      Device capability: More operator controllable device capability criteria like battery status. etc. position capabilities etc. Objective: Enhance MDT OAM requirements and solutions for UMTS and LTE in line with the RAN Rel-10 work on "Minimization of Drive Tests for E-UTRAN and UTRAN" (UID_460003).  Investigate whether MDT can be further enhanced to further reduce OPEX and define the corresponding solutions. Investigate the possible enhanced device capability criteria to provide better operator control for UE selection and define the corresponding management and procedure support. and further coverage optimization.81 Overview of 3GPP Release 11 V0.446 Name Enhanced Management of UE based network performance measurements Supporting Companies: Huawei.423. accurate location is important for MDT and it’s the base for accurate analysis. 32.421.   10 Expected Output and Time scale 3GPP . Accurate location information can improve the granularity in coverage hole detection. China Mobile.1. Vodafone. Orange. But there are some important enhancement required to be further investigated based on Rel-10 agreement on the following aspect:  Accurate location acquisition: From operator point of view. 32. 32.442. may be needed for better control of the selection of UE for the MDT campaign. The following location coordination options were discussed to acquire the accurate location for MDT measurements in Rel-10. AT&T. Nokia Siemens Networks. Motorola Solutions. memory size. coverage map visualization. Ericsson.422. Support of more MDT measurements according to the TSG RAN discussion on MDT (if needed). The work in SA5 has dependencies with other SA or RAN groups and the features in this work item will require co-ordination/discussion with the related groups.441. Ericsson. Deutsche Telekom Justification SA5 Rel-10 work on "Management of UE based network performance measurements" (UID_470042) provides the solutions for supporting of MDT RAN functionality in Rel-10. ZTE.

32.4 46 Subject Enhanced Management of UE performance measurements Enhanced Management of UE performance measurements Enhanced Management of UE performance measurements Enhanced Management of UE performance measurements Enhanced Management of UE performance measurements Enhanced Management of UE performance measurements Affected existing specifications Approved at plenary# based network SA#56 Jun 2012 based network SA#57 Sep 2012 based network SA#58 Dec 2012 based network SA#56 Jun 2012 based network SA#57 Sep 2012 based network SA#58 Dec 2012 Comments Trace concepts and requirements Trace control and configuration management Trace data definition and management Trace Management IRP Requirements Trace Management IRP Information Service (IS) Trace Management IRP Solution Set (SS) definitions 3GPP .44 2 32.1 (2012-06) Spec CR No.42 1 32.82 Overview of 3GPP Release 11 V0.42 3 32.42 2 32.1.44 1 32.

406 SA#54 Dec 2011 Performance measurements.406 and TS 32.426 SA#54 Dec 2011 Performance measurements Evolved Packet Core network (EPC) 3GPP . 10 Expected Output and Time scale Affected existing specifications [None in the case of Study Items] Spec No. 4 Objective For core network performance measurement enhancement work.Intra-MscServer or inter-MscServer handover performance based on ALink and IucsLink .426 Name CN performance measurements enhancement Justification Performance Management (PM) is important for operators to manage their networks.406.426. In the case of Direct Tunnel function enabled.6 CN performance measurements enhancement UID_520034 Resources: UID 52003 4 S5 Acronym OAMePM-CN Finish 12/09/201 2 Comp 90% Hyperlink SP110275 WI_rapporteur China Mobile Notes TSs_and_TRs 32. which is in Iu mode that allows the SGSN to establish a direct user plane tunnel between RAN and GGSN (for connectivity with GGSN through Gn/Gp) or S-GW (for connectivity through S4) within the PS domain. R C Subject pproved at plenary# A Comments 32. According to network operation and management requirement. 32. Core Network (CN) Circuit Switched (CS) domain 32.407. since they are very useful to analyze network load balance and predict traffic etc.1. such as handover. The following are examples of core network performance measurements for standardization: . a set of performance management measurement definitions shall be defined based on well described use cases. specific measurements related to common core network for GSM and UMTS need to be enhanced. Currently performance measurements for core network have been defined in TS 32.Direct Tunnel related measurements. the network performance should be monitored.406 and TS 32.407 SA#54 Dec 2011 Performance measurements.1 (2012-06) 8. MO and MT related measurements must be distinguished with GSM and UMTS.MO and MT calls related measurements based on ALink and IucsLink .407. 32. Core Network (CN) Packet Switched (PS) domain 32.83 Overview of 3GPP Release 11 V0. but the related measurements are not defined in current specification TS 32.

Ericsson.1.e: • • ANR from E-UTRAN to GERAN. Nokia Siemens Networks Justification For LTE. TSG RAN introduced SON ANR in UTRAN as well (UID_480020 Automatic Neighbour Relation (ANR) for UTRAN). specified in the LTE context. Objectives: A) Identify the management aspects for the following SON use cases in the context of UTRAN: 1) Automatic Neighbour Relation (ANR).521. Qualcomm. 32. including • Intra-UTRAN ANR.522. i. • 10 Expected Output and Time scale 3GPP .646 Name UTRAN SelfOrganizing Networks (SON) management Supporting Companies: Huawei. 2) Self-optimization a.1 (2012-06) 8. 32. AT&T.7 UTRAN Self-Organizing Networks (SON) management UID_510059 Resources: UID 51005 9 S5 Acronym OAMSONUTRAN Finish 12/09/201 2 Comp 80% Hyperlink SP110518 WI_rapporteur Huawei Notes TSs_and_TRs UTRA 32. 32. ANR from E-UTRAN to UTRAN. Capacity and Coverage Optimization (CCO) for UTRAN should also be considered in UTRAN SON activities. Other self-optimization use cases are FFS B) Specify UTRAN SON management solutions capturing the unique aspects of UTRAN SON management C) Specify common SON management solution capturing the common SON management part of E-UTRAN and UTRAN D) Update if needed existing SON management specs according to UTRAN SON and common SON management agreement E) In addition to UTRAN ANR. Capacity and Coverage Optimization (CCO) b. ANR can help the operators to avoid the burden of manual neighbour cell relations management. Automatic Neighbour Relation (ANR) function. Introducing SON functions into the UTRAN legacy is also very important for operators to minimize OPEX.526.84 Overview of 3GPP Release 11 V0. AlcatelLucent. 32.642. With the help of standardized UTRAN MDT solutions. Self-optimization functionalities will monitor and analyze performance measurements.511. Minimization of Drive Tests (MDT) for E-UTRAN and UTRAN is an important topic in 3GPP Rel-10. Vodafone.500. Telecom Italia. Deutsche Telekom. Orange. 32. SON (Self-Organizing Networks) concept and many features have been discussed and standardised. The SON target is to maintain network quality and performance with minimum manual intervention from the operator. notifications. 32. • UTRAN IRAT ANR from UTRAN to GERAN. identify management aspect for E-UTRAN IRAT ANR.405. and • UTRAN IRAT ANR from UTRAN to E-UTRAN. This will significantly reduce manual interventions and replace them with automatically triggered re-optimizations or re-configurations thereby helping to reduce operating expenses. and self-test results and will automatically trigger re-configuration actions on the affected network node(s) when necessary. automates the discovery of neighbour relations. 32. and ANR from E-UTRAN to CDMA2000.

5 Add UTRAN SON 00 Management 32. UTRAN network resources IRP Solution Set (SS) 2012 definitions 3GPP .5 Add UTRAN SON 26 Management 32. Performance measurements (UTRAN) 2012 SA#56 Jun SON Concepts and requirements 2012 SA#56 Jun Automatic Neighbour Relation (ANR) management.5 Add UTRAN SON 11 Management 32.5 Add UTRAN SON 22 Management 32.4 Add UTRAN SON 05 Management 32. 2012 Concepts and requirements SA#56 Jun SON Policy NRM IRP Requirements 2012 SA#57 Sep SON Policy NRM IRP Information Service (IS) 2012 SA#57 Sep SON Policy NRM IRP Solution Set (SS) definitions 2012 SA#57 Sep CM. UTRAN network resources IRP NRM 2012 SA#57 Sep CM.6 Add UTRAN SON 42 Management 32.1.85 Overview of 3GPP Release 11 V0.5 Add UTRAN SON 21 Management 32.6 Add UTRAN SON 46 Management Affected existing specifications Approved at Comments plenary# SA#57 Sep PM. R 32.1 (2012-06) Spec C Subject No.

32. As more and more SON function management solutions being standardized. b) Coordination between configuration changes triggered by distributed SON functions. Deutsche Telekom. preference. Note the coordination here is not a general statement which means the coordination is needed between every SON functions.500. The coordination is usually needed for preventing or resolving the conflicting configuration parameter changes triggered by different SON functions and/or between SON function(s) and bulk/basic CM. The coordination includes several typical scenarios: a) Coordination between configuration changes triggered by EM centralized SON functions and distributed SON functions. ETRI. etc.. 32.522. weight. Nokia Siemens Networks. the SON coordination is becoming more important. 10 Expected Output and Time scale 3GPP .) and methods for preventing or resolving conflicts between SON functions.g.526. preference. 3GPP Rel-10 work mainly focused on independent SON function. AT&T. c) Coordination between SON functions to make these SON functions run well and not make negative impacts on each other. Besides this kind of typical case.) and methods for preventing or resolving conflicts between bulk/basic CM and SON functions. etc. 32. is a good example of that. Intel. weight.762.86 Overview of 3GPP Release 11 V0. The coordination should be analyzed on a case by case basis. Alcatel-Lucent. 2) Coordination between different SON functions below Itf-N based on case by case approach.g. 32. Nokia Siemens Networks Notes TSs_and_TRs LTE 32.8 LTE Self-Organizing Networks (SON) coordination management UID_530051 Resources: UID 53005 1 S5 Acronym OAM-SONLTE_COORD Finish 12/09/201 2 Comp 50% Hyperlink SP110637 WI_rapporteur Huawei. The SON coordination solutions may include management of SON policies (e. Objective: to specify SON coordination solutions for the following aspects: 1) Coordination between Configuration Management (bulk/basic CM) via Itf-N and configuration parameters changes made by SON functions below Itf-N.. China Unicom. SA5 will do any necessary changes on the Itf-N interface. 32. The coordination between Cell Outage Compensation and Energy Saving Management. SON (Self-Organizing Networks) concept and many features have been discussed and standardised. which is described in TS 32. PIWorks. Ericsson.1 (2012-06) 8.522. the coordination includes other cases that there are some relations between SON functions and these relations should be cared to make these SON functions run well and not make negative impacts on each other. The SON coordination has the following aspects: 1) Coordination between Configuration Management via Itf-N and configuration changes made by SON functions below Itf-N. 2) Coordination between different SON functions.425.766 Name LTE SelfOrganizing Networks (SON) coordination management Supporting Companies: Huawei.521. The SON coordination solutions may include management of SON policies (e.1. 32. ZTE. and may send liaison to RAN work groups for any changes required on the X2 interface. NEC Justification For LTE.

526 Add LTE SON Coordination Management 32.762 Add LTE SON Coordination Management 32. 32. Performance measurements Evolved 2012 Universal Terrestrial Radio Access Network (E-UTRAN) 3GPP .1.87 Overview of 3GPP Release 11 V0.522 Add LTE SON Coordination Management 32.1 (2012-06) Spec CR Subject No.521 Add LTE SON Coordination Management 32.766 Add LTE SON Coordination Management 32.500 Add LTE SON Coordination Management 32.425 Add LTE SON Coordination Management Affected existing specifications Approved at Comments plenary# SA#56 Jun SON Concepts and requirements 2012 SA#56 Jun SON Policy NRM IRP Requirements 2012 SA#57 Sep SON Policy NRM IRP Information Service (IS) 2012 SA#57 Sep SON Policy NRM IRP Solution Set (SS) definitions 2012 SA#57 Sep E-UTRAN Network Resource Model (NRM) Integration Reference Point (IRP): 2012 Information Service (IS) SA#57 Sep E-UTRAN Network Resource Model (NRM) Integration Reference Point (IRP): 2012 Solution Set (SS) definitions SA#57 Sep Performance Management (PM).

Provide stage 2 (IS) and stage 3 (SS) definitions for Management of Inter-RAT ESM 3) Where possible: Progress topics which were labelled as “FFS” in TR 32. Decide on the solution variants contained in TR 32.551. This work shall be well coordinated with the RAN WGs.522.762.834 For all the above existing standardized functionalities shall be reused.1 (2012-06) 8. Overlapping of collocated cells of different RATs with similar coverage area c. Huawei Notes Triggered by Rel11 TR 32.834 (Study on OAM aspects of interRAT Energy Saving) UID_510045. Orange. 32.834 b. Overlapping of non-collocated cells of different RATs with significantly different coverage areas b. Intel. 32. 32. 32. Deutsche Telekom. 10 Expected Output and Time scale 3GPP . ETRI Triggered by Rel-11 TR 32. Improvements of Intra-RAT ESM based on TR 32. This work item supports this possibility to reduce the energy footprint of mobile networks. Combination of collocated RAT1-RAT2 cells with non-collocated RAT2 cells 2) Based on these requirements and use cases specify OAM solutions for Inter-RAT energy saving a.834 (Study on OAM aspects of inter-RAT Energy Saving) UID_510045. 32.834 results are also possible under this work item.642. ZTE. Needs coordination with RAN WGs TSs_and_TRs 32. NEC. 32. Ericsson. Objective: to specify support Inter-RAT Energy Saving Management (ESM) considering the results of TR 32.646.526.88 Overview of 3GPP Release 11 V0.834 shows that Inter-RAT Energy Saving Management can be done by adapting existing SA5 IRP specifications.1. if it is beneficial. Huawei.766 Name Inter-RAT Energy Saving Management Supporting Companies: Nokia Siemens Networks.9 Inter-RAT Energy Saving Management UID_540031 Resources: UID 540031 S5 Acronym OAMIRATESM Finish 12/09/201 2 Comp 40% Hyperlink SP110701 WI_rapporteur Nokia Siemens Networks.834: 1) Specify OAM requirements for Inter-RAT energy saving for the following use cases a. China Unicom.405. 32. AlcatelLucent. Justification TR 32.

No impact if this variant is not chosen.834. e.834.g.g.526 32. Inter-RAT ES Coverage 2012 Network Resource Model (NRM) relations] [Note: Inter-RAT ES Coverage relations for one of the solution variants of TR32.1 (2012-06) Spec No.1. policies SA#57 Sep SON Policy NRM IRP Information Service (IS) thresholds[. e.522 32. No change in this regard if this variant is not chosen.] Align with adapted IS SA#57 Sep UTRAN network resources Integration Reference Point (IRP). Performance measurements unavailability 2012 UTRAN Add Inter-RAT ESM requirements (and new SA#56 June Energy Saving Management (ESM) Concept and Requirements Intra-RAT ESM requirements when needed) 2012 Add Inter-RAT ESM extensions.g.834.] Align with adapted IS SA#57 Sep SON Policy NRM IRP Solution Set (SS) definitions 2012 Add Inter-RAT ESM extensions. Subject 3GPP . Inter-RAT ES groups] 2012 [Note: ES group required for one of the solution variants of TR32.646 32.551 32. 32. InterSA#57 Sep E-UTRAN Network Resource Model (NRM) Integration Reference RAT ES Coverage relations] 2012 Point (IRP): Information Service (IS) Note: Impact on this TS only required for one of the solution variants of TR32.405 32.642 32.834. 2012 Solution Set (SS) definitions [Add Inter-RAT ESM extensions.766 Affected existing specifications Approved at Comments plenary# Add indications for RRC failure and cell SA#56 June Performance Management (PM). No impact if this variant is not chosen.89 Overview of 3GPP Release 11 V0.762 32. No change in this regard if this variant is not chosen. Align with adapted IS SA#57 Sep E-UTRAN Network Resource Model (NRM) Integration Reference 2012 Point (IRP): Solution Set (SS) definitions Note: Impact on this TS only required for one of the solution variants of TR32. e. energy SA#57 Sep UTRAN network resources Integration Reference Point (IRP). saving state[.

Triggered by Rel-10 TR 32.115). message flows. including functionality.825 containing the analysis for requirements.825 SA5 Study on Rc Reference Point Functionalities and Message Flows (UID_410044) TSs_and_TRs 32.825 needs to be incorporated into the corresponding TSs as optional solutions for the Rc reference point (reference point between Online Charging Function (OCF) and Account Balance Management Function (ABMF) within OCS).825. Amdocs.1 (2012-06) 8.11 Add solutions for Rc .825 SA5 Study on Rc Reference Point Functionalities and Message Flows (UID_10044). UID 47004 5 Name Add solutions for Rc reference point within the Online Charging System (OCS) Acronym CH-Rc Finish 21/09/201 1 Hyperlink SP110129 WI_rapporteur Huawei Notes SP#53 completed.reference point within the Online Charging System UID_470045 Resources: S5 Triggered by Rel-10 TR 32. functionality. 3GPP . The output of TR 32. Openet.reference point within the Online Charging System (OCS) Charging for Policy Enhancements for Sponsored Connectivity and Coherent Access to Policy related Data Bases Unification of Charging session from SIP AS and SRVCC functions in IMS 8. AT&T. basic operations.90 Overview of 3GPP Release 11 V0.299 Supporting Companies: Networks Huawei. China Mobile. This work item aims to specify the solutions for Rc reference point based on the recommendation in TR 32. ZTE.10 Rel-11 Charging Management small Enhancements UID_510052 Resources: UID 51005 2 47004 5 51006 0 55001 9 S5 Acronym CH11 CH-Rc PEST-CH UCHIMS_ASSRVCC WI_rapporteur Huawei Ericsson Alcatel-Lucent Name Rel-11 Charging Management small Enhancements Add solutions for Rc . Stage 3 (Stage 1 in 22. 32. Deutsche Telekom.296. parameter definitions and protocol implementation. Nokia Siemens This work item is triggered by the SA5 Rel-10 study TR 32. basic operations and message flows of Rc reference point.1.

This deployment scenario does not require SPR and allows the PCRF access to the PCC related subscriber data stored in the UDR. the user downloads a purchased ebook from an online store.299 Name Charging for Policy Enhancements for Sponsored Connectivity and Coherent Access to Policy related Data Bases Supporting Companies: UID 50010 6 Alcatel-Lucent. The PCC framework can be enhanced to enable such use cases.12 Charging for Policy Enhancements for Sponsored Connectivity and Coherent Access to Policy related Data Bases UID_510060 Resources: UID 51006 0 S5 Acronym PESTCH Finish 21/09/201 1 Hyperlink SP110126 WI_rapporteur Ericsson Notes SP#53 completed. TR 23. In many cases.g.298. In particular. Objective: PS/EPS charging to support sponsored connectivity sessions to align with Rel-10 Stage 2 TS 23.Coherent access to Policy related databases within TR 23.002. Application service provider) pays for the user’s data usage in order to allow the user to access the Application Service Provider’s services. For example. For example.. 23.203. The user may have limited data plans allowing only a nominal data volume per month and the Sponsor may dynamically sponsor additional volume for the user to allow access to the services offered by the Application service providers. In addition to Key Issue 1. the user may use the limited data plan to browse an online store for interested books. In addition. the user purchases and downloads a game from an operator store. SA2 also studied the feasibility of Key issue 2 . the IP flow may also be granted certain level of QoS (e. in particular. Ericsson. but once a book is purchased.1 (2012-06) 8. the user views free trailer clip from an online library to determine whether to buy the entire movie or not. 32. 3GPP . For example. AT&T. With the emerging of innovative IP services. 32.203 (SA#49 work completed as SA2 Coherent Access to Policy related Data Bases (Rel-10) CRs approved under TEI10 (SP-10557)) Justification This work item provides the Charging functionality for the Rel-10 Feature-Level work item PEST (Policy Enhancements for Sponsored Connectivity and Coherent Access to Policy related Databases) UID_500006. it allows the operator to provide service control based on such sponsored services.91 Overview of 3GPP Release 11 V0. the data usage for downloading the book can be granted for free. Stage 3 TSs_and_TRs 32. This enables additional revenue opportunities for both the Application service providers and the operators.g. the Sponsor (e. the transactional data usage is becoming more and more prevalent on the mobile. video streaming).813.1.251.813 studied the feasibility of these scenarios of sponsored connectivity in the key issue 1 and converged into a set of extensions to the PCC procedures which will allow the operator to provide sponsored connectivity to sponsor entities. such dynamic data usage provided by the Sponsor allows the operator to increase revenues from the users with limited data plans. It enables UDR (User Data Repository) in the PCC architecture as an optional functional entity where PCC related subscriber data can be stored and retrieved by the PCRF through the Ud interface. it allows a dynamic IP flow to be excluded from the user’s data plan since a Sponsor might sponsor the data usage for the identified IP flows. Nokia Siemens Networks Corresponding stage 2 work item (if any) Title TS Stage 2 for Policy Enhancements for Sponsored Connectivity and 23.

to maintain one single charging session (offline and online) on Session Transfer process. a set of IMS Nodes are part of IMS charging architecture. therefore. the number of charging sessions for one whole IMS session could be high. two charging sessions are created: one for the incoming leg and one for the outgoing leg.299 Name Unification of Charging session from SIP AS and SRVCC functions in IMS Supporting Companies: Justification Alcatel-Lucent. Combining the number of IMS Nodes. as one of the IMS Nodes associated to SRVCC. MMTel in TS 32. a different IMS session needs to be considered from the charging perspective for the outgoing dialog). one Charging session is created per dialog (i.1 (2012-06) 8. are also applied with per-dialog charging session (i.260. 3GPP .) and online (S-CSCF. it is proposed.298. including when B2BUA is used. 32. MGCF.. and when defined.e. This solution is an alternative to the existing per-dialog charging session. MMTel AS providing MMTel service and supplementary services. Ericsson. especially for offline charging. 32. Service Centralization and Continuity AS (SCC AS) and Emergency Access Transfer Function (EATF)).e. Objective: to specify charging for Access Transfer Control Function (ATCF). In case the SIP AS application/service logic generates ICID (s) for outgoing leg(s). and any SIP AS(s) implementing base routeing B2BUA.260 and corresponding IMS based services (e.1. for offline (x-CSCF. ZTE In IMS Charging specification TS 32. SIP AS... Huawei.e.g. With the minimized number of session. and B2BUA behaviour. different from the incoming leg ICID for the purpose of the service (i. As a general principle retained in IMS. although transfer requests may be received with different ICID. Nokia Siemens Networks.) charging. It could be beneficial to minimize the number of charging sessions and messages by optimizing at IMS Node level. when the same IMS Charging Identifier (ICID) from the incoming leg is used by the SIP AS for the outgoing leg. The solution can be applied for the base routeing B2BUA. The set of IMS Nodes associated to SRVCC (Single Radio Voice Call Continuity) are involved in IMS charging.275. 32. ATCF and EATF when providing session anchoring (normal and emergency respectively) for IMS Service Continuity.275). this solution allows moderating the total number of charging messages compared to the existing per-dialog solution. the per-dialog charging session applies. per-leg) at each IMS node involved in the IMS session. ATCF and EATF. when an IMS Node behaves as a Back-to-Back User Agent (B2BUA).. Deutsche Telekom. SIP AS. for the SCC AS. In addition.13 Unification of Charging session from SIP AS and SRVCC functions in IMS UID_550019 Resources: UID 55001 9 S5 Acronym UCHIMS_ASSRVCC Finish 12/12/201 2 Comp 40% Hyperlink SP120042 WI_rapporteur Alcatel-Lucent Notes Stage 2/3 TSs_and_TRs 32. when applicable. To specify a single Charging session (offline and online) for the following SIP AS and SRVCC functions identified as acting as B2BUA: • • SCC AS.92 Overview of 3GPP Release 11 V0.

C1 Finish 15/06/201 2 Hyperlink SP110132 WI_rapporteur Deutsche Telekom Notes Stage 2/3.g.S1.229) and therefore need to be coordinated with CT1 and CT3.1. 3GPP . the Transit IOI shall be added to the P-Charging-Vector as well. one to many transit operators are between the originating and terminating operator. Since IMS Charging already populates several charging parameters (orig-ioi. 32. Enhancements of the P-Charging-Vector affect 3GPP specifications outside SA5 (e.298. 32. In IMS transit scenarios. a Transit IOI shall be added to the IMS Charging data.14 Transit Inter Operator Identifier for IMS Interconnection Charging in multi operator environment UID_510029 Resources: UID 51002 9 S5. Objective: In order to improve the IMS charging capabilities to reflect transit scenarios in multi operator environments.229 (IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP).3. and CT3 TS 29. A new Offline.165 (Inter-IMS Network to Network Interface (NNI). Nokia Siemens Networks Charging requirements defined in SA1 TS 22.229 Supporting Companies: Justification AT&T. CT1 has provided the addition of protocol elements and procedures for transit operator identifiers. interconnection charging in IMS is only possible where maximum two carriers are included in the charging process. Ericsson. since the P-Charging-Vector Header only contains two Inter Operator Identifiers ( “orig-ioi” and “term-ioi”). Thus. Stage 1 in SA1 22.S1.C1 Resource S5. term-ioi.3).115 32.115 SP#53 completed under IPXS SP#54 completed CP#56 completed TSs_and_TRs - 51012 9 51022 9 52000 6 Name Transit Inter Operator Identifier for IMS Interconnection Charging in multi operator environment Stage 1 Stage 2/3 SA5 part Stage 3 S1 S5 C1 21/09/201 1 07/12/201 1 15/06/201 2 SP110132 SP110132 CP110440 Deutsche Telekom Deutsche Telekom Deutsche Telekom 22. Huawei.1 (2012-06) 8. This parameter will help to identify all carriers involved in the transit scenario.260. This work item intends to close this gap.115 contain Interconnection Charging (see Clause 4. Deutsche Telekom. where IMS transit scenarios are explicitly listed.93 Overview of 3GPP Release 11 V0. China Mobile.and/or Online Charging AVP for the Transit IOI needs to be added to IMS charging. CT1 TS 24. The interconnection business of operators may require to identify all carriers involved in the transit scenario for charging purposes. Stage 3). icid) based on the P-ChargingVector defined in the CT1 TS 24. Stage 3) also supports the transfer of the P-Charging-Vector between interconnected networks in case of a trust relationship. Currently. transit carriers can not be identified so far.299 24. 32. CP#56 completed.240.

C4.C4 C1 C4.C3 C3 C1 C4 C4 WI_rapporteur Telecom Italia Gemalto NTT ZTE Huawei Alcatel-Lucent China Mobile Ericsson Nokia Siemens Networks Nokia Siemens Networks Deutsche Telekom Telcordia Telecom Italia Intel Deutsche Telekom Alcatel-Lucent 3GPP .C1 C1.G2 C1.C3.C3.1 (2012-06) 9 CT Features UID 48001 1 51000 4 52000 7 52000 8 52000 9 52001 0 53000 3 53001 8 53001 9 53002 0 54001 5 54001 7 55000 7 56000 5 56000 6 56000 7 Name User Data Convergence .phase 5 Service Identification for RRC Improvements in GERAN (Stage 2/3) IMS Emergency PSAP Callback (Stage 3) SAE Protocol Development GCSMSC and GCR Redundancy for VGCS/VBS (Stage 2/3) Support of RFC 6140 in IMS Enhancements for Multimedia Priority Service (MPS) – Gateway Control Priority Inter-IMS Network to Network Interface (II-NNI) enhancements: SIP timers applicability (Stage 3) AT commands for Universal Resource Identifier (URI) support PS Additional Number (Stage 3) Generic IMS User Group Over Sh Acronym UDC_DM HPM_UICC NNI_OI eNR_EPC RLI IMSProtoc5 SIRIG EMC_PC SAES2 RT_VGCS_Red GINI eMPS_Gateway NNI_timers ATURI PSAN GenUG_Sh Resource C4.C1 C4.94 Overview of 3GPP Release 11 V0.Data Model Definition of the UICC Application for Hosting Party Module Usability improvement of Inter-IMS Network to Network Interface (II-NNI) specification for inter-connection by means of Option Item list enhanced Nodes Restoration for EPC Reference Location Information IMS Stage 3 IETF Protocol Alignment .IETF C1 C1.S1 C6 C3 C4.C3 S2.1.

the success of UDC systems. b) Object classes & Directory Information Tree: object classes names. Also the integration of IMS AS user data into the UDR has to be studied. Details related to the data model used with LDAP (e.1. Orange.S1 S1 Finish 07/09/201 2 21/09/201 1 07/09/201 2 06/09/201 2 Comp 55% 100% Hyperlink CP110384 not applicable CP110384 CP110384 WI_rapporteur Telecom Italia Telecom Italia Notes SP#48 Stage 1 completed as Rel-10 SP#53 completed under Rel-10 UDC CP#56 new TR 29. directory tree) are still outside the scope of the present version of this specification and full interoperability between UDR and FEs from different vendors is not guaranteed. IMS AS). 4 Objective In order to guarantee interoperability between FEs and UDR from different vendors and. 3GPP TS 29.364. it is needed to define the reference data model for specific applications (i. as these data are currently stored as transparent data by the HSS but conveyed over the Sh interface based on partial specification in 3GPP TS 29. HSS. As soon as data model for a specific application is considered stable it will moved to normative specification. 3) Define the UDC reference data model for the user data identified in 1) and 2). Alcatel-Lucent.S1 Resource C4.935 29. consequently. 3GPP TS 23.335 has specified the stage 3 of the Ud interface between the FEs and the UDR. attributes grouping. 3GPP .101 Name User Data Convergence Data Model Stage 1 for UDC Data Model TR on User Data Convergence (UDC) Data Model User Data Convergence (UDC) Data Model C4 80% Telecom Italia new TR 29.335 C4 0% Telecom Italia Supporting Companies: Justification Telecom Italia.1 (2012-06) 9.935 v100 for Information TSs_and_TRs 22. semantics.g.95 Overview of 3GPP Release 11 V0. HLR.e.335 has specified UDC architecture defining a new Ud interface between Front-Ends (FEs) and the User Data Repository (UDR) as well as procedures and signalling flows over the interface. syntax. 2) Define the IMS AS user data related to MMTel services especially those having CS equivalents. that means: 1) Define the subset of HLR/HSS interfaces and related user data to include in the reference model.1 User Data Convergence . Deutsche Telekom. The work will start with a new TR and will comprise the following topics to be performed in the following order: a) Attributes definition: names. Distinguished Names and Relative Distinguished Names.Data Model (UDC_DM) UID_480011 Resources: UID 48001 1 48003 6 48011 1 48021 1 C4. LDAP entries. AuC. China Mobile. ZTE.

and need to be reworked for a H(e)NB.2 Definition of the UICC Application for Hosting Party Module (HPM_UICC) UID_510004 Resources: UID 51000 4 C6 4 HPM_UICC Finish 15/06/201 2 Hyperlink CP110289 WI_rapporteur Gemalto Notes CP#56 completed.1.102.1 "Hosting Party Module" The Hosting Party authentication shall be based on a Hosting Party Module. if a dedicated application. new TS 31. the O&M system contact). Language indication. authentication based on EAP-AKA method. Defines Stage 3 for UICC application residing in Hosting Party Module TSs_and_TRs 31.10 "USIM and H(e)NB" Optionally.1. • To define necessary procedure for the UICC application that will reside in Hosting Party Module. Gemalto. According to current USIM initialization procedure.g.3 "Hosting Party Mutual Authentication" An EAP-AKA based method shall be used for hosting party authentication Although Hosting Party Module is defined in 3GPP. sec 5.102. According to TS 33.220 Justification According to TS 22. there is no procedure defined in TS 31.g. sec 5.320.1 (2012-06) 9.220 sec 5. like emergency calling codes.220) Else. a Hosting Party Identity Module (HPIM) shall be defined for this purpose. According to TS 33.320. e. including:      identification of the Hosting Party security mechanism support of information for the initial provisioning (e. or. TS 31.220) Enhanced Home NodeB / eNodeB (EHNB) Rel-9 Feature (Stage 1 requirements in 22. France Telecom.220 TS 22. The USIM application may also contain information for the initial provisioning (e. The HPM is provided by means of a UICC. FDN BDN services. 3GPP . the application residing in HPM shall support unnecessary services.g. Microelectronica Española. • to assess if this can be achieved by extension of USIM application defined in TS 31.104 v200 for Approval. etc. Oberthur Technologies. corresponding stage 1 work item Unique ID Title 450153 Rel-10 Service Requirement for HNB / HeNB 400047 Rel-9 Service Requirement for HNB / HeNB TS TS 22. O&M system contact) initialisation procedure on H(e)NB-UICC interface support of O&M procedure Security mechanism implemented in Hosting Party Module.104 Name Definition of the UICC Application for Hosting Party Module Supporting Companies: China Mobile. Telecom Italia. Objective: • to define the UICC application that will reside in the Hosting Party Module. Sagem Orga. the H(e)NB may support identification and authentication of the H(e)NB Hosting Party by means of a USIM application. The USIM initialisation procedure specified in TS 31.102.96 Overview of 3GPP Release 11 V0. TeliaSonera UID 450053 400035 Related Study Item or Feature (if any) Title Nature of relationship Extended H(e)NB features (EHNBF) Rel-10 Feature (Stage 1 requirements in 22.102 applies to an ME. support of PLMN files. Giesecke & Devrient.

3GPP . since the aim is to specify the list of selectable items related to control plane signalling directly for the same architecture. specify the list of selectable items related to control plane signalling directly for the same architecture) TSs_and_TRs 29. Fujitsu.165 and it is therefore complicated for operators to identify items that require particular attention in inter-operator agreements. the operators can negotiate the option items in their agreements more easily. France Telecom/Orange. Telecom Italia. Nokia Siemens Networks. the list of "option items" that are recommended to be selected by inter-operator agreements will be documented in a new annex to 3GPP TS 29. the SIP profile over II-NNI is specified. Especially. OKI No architectural change is present in this WID. However.165 Name Usability improvement of Inter-IMS Network to Network Interface (II-NNI) specification for interconnection by means of Option Item list Supporting Companies: NTT.97 Overview of 3GPP Release 11 V0. Ericsson. according to 3GPP TS 29. Deutsche Telekom.1. and these items are further called "option items" here. In this way.165. Justification The 3GPP TS 29.165. This work item does not modify the definition of the capabilities supported over the II-NNI and the procedures specified in 3GPP TS 24.165 some items related to control plane signalling need to be selected by inter-operator agreements in advance. For the inter-connection between two operators using the II-NNI. the items which have a great influence on the normal service provisioning and on service interconnection fall into this category.229. and hence the inter-connection by using the II-NNI can be performed more smoothly. Stage 3 (No architectural change. 4 Objective This work item aims to provide a conventional instrument by defining the list of "option items" that are suggested to be selected by inter-operator agreements as complementary information in Release-11 TS 29. For the Ici reference point.3 Usability improvement of II-NNI specification for interconnection by means of Option Item list (NNI_OI) UID_520007 Resources: UID 52000 7 C3 Finish 15/06/201 2 Hyperlink CP110533 WI_rapporteur NTT Notes CP#56 completed.165.1 (2012-06) 9. NTT DoCoMo. NEC. information about the items to be considered is spread throughout the 3GPP TS 29.165 is addressing the Inter-IMS Network to Network Interface (II-NNI) consisting of Ici and Izi reference points between IMS networks. AT&T. In order to solve this problem. This complementary information will be specified within a new informative annex in TS 29.

007.857 certain serious misoperations if the MME. Restoration of PGW failure with and without restart. Alcatel-Lucent. but occasional restart or failure due to various reasons can not be avoided.008.007 Stage 2 requirements for EPC Nodes Restoration 29. This work will cover the following: Restoration of SGW failure with and without restart.1 (2012-06) 9.007. 10 Expected Output and Time scale Affected existing specifications Spec No. 23. However due to the time frame of Rel-10.C1 Resource C4. 29. a subscriber may not be able to receive any IMS terminating call during a long period following an EPC node failure.857 Study on EPC Nodes Restoration UID_490014 CP#56 completion 06/12=>09/12 CP#55 completed TSs_and_TRs - Name enhanced Nodes Restoration for EPC 52010 8 54001 3 CT4 part CT1 part C4 C1 07/09/201 2 02/03/201 2 80% 100% CP110928 CP110928 ZTE ZTE 23.008 Possible Additional data to be stored in MME/S4-SGSN.018 MTRF support 29. China Mobile. SGW or PGW fails with the recovery mechanisms currently specified in 3GPP. SGW. NOTE: Definition of partial failure is specified in 3GPP TS 23.1.274.C1 Finish 07/09/201 2 Comp 83% Hyperlink CP110928 WI_rapporteur ZTE Notes Stage 2/3 Triggered by DRAFT TR 23.857.275 29. CT4 identified in TR 23. 29. justify: SA1 does not define specific service requirements for failure and restoration scenarios. 23. Objective: to carry out the normative work which was not finished in Rel-10 according to the conclusions of the feasibility study documented in TR 23.118 SGs protocol impacts Approved at plenary# CT#56 (June 2012) CT#56 (June 2012) CT#56 (June 2012) CT#56 (June 2012) CT#56 (June 2012) CT#56 (June 2012) Comments CT4 CT4 CT4 CT4 CT4 CT1 3GPP . e.CRSubject 23. PGW 23.4 enhanced Nodes Restoration for EPC (eNR_EPC) UID_520008 Resources: UID 52000 8 C4.98 Overview of 3GPP Release 11 V0. and concluded that certain enhancements would allow to provide service resiliency after an EPC node failure. restoration procedures were only specified for MME/S4-SGSN failure in Rel-10.018. Restoration of node partial failure (see NOTE).g. Restoration of CS service after MME failure. Justification EPC nodes are expected to be highly reliable. Cisco If no identified source of stage 1 information.275 PMIPv6 protocol impacts 23.118 Supporting Companies: ZTE.274 GTPv2 protocol impacts 29.

and no location information can be provided to the PSAP. 29.C1 Resource C4.1 (2012-06) 9.5 Reference Location Information (RLI) UID_520009 Resources: UID 52000 9 C4. 29. As specified in the TS 23.1 of SA2 TS 23. emergency calls cannot be routed to the correct PSAP. Orange. when neither the UE nor the P-CSCF provides location information. Ericsson In the scenarios that LRF is not deployed and the P-CSCF is unable to query the IP-CAN for location information.228. The Reference Location Information may also be useful to the application servers in some cases. if the UE does not provide any location information. Stage 3. Enhance functionalities of the S-CSCF to use the Reference Location Information of the user received from the HSS for service handling. 29. Enhance Sh interface for retrieval of Reference Location Information of the user. and insert it in the INVITE request. 3GPP . Objective: to define stage 3 related to Reference Location Information as follows. Stage 2 clause C.008.C1 Finish 16/09/201 1 Hyperlink CP110386 WI_rapporteur Huawei Notes CP#53 completed.1.1. Alcatel-Lucent. when handling service logic which needs to take the location of the user into account.328.167. Enhance Cx interface for transfer of Reference Location Information of the user from the HSS to the S-CSCF.99 Overview of 3GPP Release 11 V0. • • • • Add Reference Location Information of the user as part of Subscriber Data. the S-CSCF may receive from the HSS a reference location of the user at registration. It is possible to provision in the HSS with reference location information for the user and then provide it to the S-CSCF.329 24. ZTE. e.167 CR#0182 (WI code: TEI11) CP#52 completed TSs_and_TRs - Name Reference Location Information CT4 part of Reference Location Information CT1 part of Reference Location Information 52010 9 52020 9 C4 03/06/201 1 16/09/201 1 CP110386 CP110386 Huawei 23.g.229 C1[98%] Huawei CP#53 completed Supporting Companies: Justification Huawei.

1. The feature set in Release 5 provides a basis for IP Multimedia support. The changes are limited to SIP and SDP related issues. 29. and provide documentation as whether these capabilities are supported in the IM CN subsystem or not. At Release 6.163.1 (2012-06) 9. Huawei. 24.6 IMS Stage-3 IETF Protocol Alignment (IMSProtoc5) UID_520010 Resources: UID 52001 0 52011 0 52021 0 C1. In addition to the above listed items. and there is still significant ongoing work in IETF that should be documented in relation to its impact on IMS.phase 5 CT1 part of IMS Stage-3 IETF Protocol Alignment CT3 part of IMS Stage-3 IETF Protocol Alignment Supporting Companies: Alcatel-Lucent.C3 Resource C1. At Release 11 the need for other new capabilities is being identified. Such changes are principally the end-to-end or end-to-application support of information without necessarily the need for other core network developments (such as interworking). The scope of this WID is protocol alignment. Nokia Siemens Networks. 8. 7.100 Overview of 3GPP Release 11 V0. Ericsson.C3 C1 C3 Finish 07/09/201 2 07/09/201 2 07/09/201 2 Comp 75% 70% 80% Hyperlink CP110437 CP110437 CP110437 WI_rapporteur Alcatel-Lucent Alcatel-Lucent Alcatel-Lucent TSs_and_TRs 23. not of sufficient significance to be normally covered by a work item.165 Name IMS Stage 3 IETF Protocol Alignment . Review of existing and future capabilities provided in SIP by IETF.229. and those capabilities that may lead to new or enhanced IMS applications are not dealt with as part of this WID. and go beneath the level of detail of what is required from the stage 1 and stage 2 descriptions. that can be dealt with by this work item. OMA or ETSI TISPAN that could be further developed at stage 3 under this work item. There may be minor stage 1 and stage 2 enhancements produced under TEI11. Justification In Release 5. 3GPP . 9 and 10 further work was identified. 24.218. or minor stage 1/stage 2 requirements coming from 3GPP2.930 29. the IMS was defined to support IP Multimedia services. justify: In general this work item is about maintaining alignment of the development of the SIP used in IMS with that currently defined by IETF. there may be minor technical improvements and enhancements to IMS. Research in Motion If no identified source of stage 1 information. Objective: • areas to be considered: Ensure protocol alignment between 3GPP Stage 3 IMS work and IETF.

167): "12. Huawei Since Rel-7 and the introduction of IMS emergency calls.229 C1-IETF 07/09/201 2 0% CP110725 Christer Holmberg IETF ECRIT work on PSAP call back no internetdraft available yet 29. Deutsche Telekom.C3. there has been a requirement to support PSAP call back and to be able to handle supplementary services accordingly. 29. ST-Ericsson.173 [40] for Multimedia Telephony (e. NOTE: There is no specific call-back requirement for CS supplementary services.165 C3 07/09/201 2 0% CP110725 Ericsson CP#56 Work can only begin when CT1 has decided the technical solution Supporting Companies: Justification Ericsson. Extract from SA1 requirements (TS 22." Extract from SA2 requirements (TS 23." and "The MGCF may: 3GPP .e. Communication Barring).101 Overview of 3GPP Release 11 V0. Fulfil SA1/2 Rel-7 EMC1 reqs UID_32045 PS domain and IMS impacts for supporting IMS Emergency calls (related to BB UID_1653 Emergency Call Enhancements for IP& PS Based Calls TSs_and_TRs Stage 3 Name IMS Emergency PSAP Callback (Stage 3) 53011 8 53100 4 53021 8 CT1 part of IMS Emergency PSAP Callback (IETF) IMS Emergency PSAP Callback (Stage 3) CT3 part of IMS Emergency PSAP Callback C1 07/09/201 2 0% CP110725 Ericsson 24.7 IMS Emergency PSAP Callback (Stage 3) (EMC_PC) UID_530018 Resources: UID 53001 8 C1. AT&T. PSAP call back is subject to local regulation. coming from a PSAP) then supplementary services at the terminating party shall be handled as described in TS 22.g.IETF Resource C1. call-back is not required. Communication Hold.163. The architecture shall enable emergency centres and PSAPs to request a PSAP call back session to a UE with which the Emergency centres or PSAPs had an emergency session. containing valid credentials). Communication Diversion. In case of a UE in limited service state.IETF Finish 07/09/201 2 Comp 0% Hyperlink CP110725 WI_rapporteur Ericsson Notes Stage 3 (Dependency IETF ECRIT on PSAP call back).e.101): "If the incoming call can be identified by the core network as a call-back to an emergency call (i.1 (2012-06) 9. A call-back may be attempted for a period of time defined by local regulations after the emergency call release. if the UE is registered (i.C3.1.

3GPP ." CT1 have since Rel-7 tried to solve the PSAP call back requirement over the years (with the help of IETF). There is a need to either solve the SA1 and SA2 requirements once and for all. .1. NOTE: Completion of this WID will be directly tied to the completion of the IETF dependencies. and a resolution is trying to be found within the current release. Progress of this WID depends on progress of the related work in IETF ECRIT on PSAP call back. or report back to SA1 and SA2 that this is a task that CT1 is incapable to solve. The operator policy decision may be based on that the call is from an emergency centre or from a PSAP and/or any other information made available to the MGCF.Include a "PSAP call-back indication" in the SIP session establishment request if an incoming call is determined to be for the purpose of PSAP call-back.1 (2012-06) .102 Overview of 3GPP Release 11 V0. but no resolution have so far been made. Objective: to implement IMS emergency callback from PSAP. This WID proposes that a new effort is put in into the work. and rather low interest have been shown in IETF.Determine based on the operator policy if an incoming call form the PSTN is for the purpose of PSAP call-back. Service aspects are covered by the existing stage-1 documents. with explicit indicator according SA1 and SA2.

Having said that. not of sufficient significance to be normally covered by a work item. 24. Renesas This work item is about collecting the minor SAE developments required in release 11. 29.303.301.312.305. Impact on GPRS relating to interworking with LTE. Note that this work item also includes stage 2 documentation for the UE in idle mode.018.1 (2012-06) 9. Such changes relating to SAE involved in CS fallback (including SGs enhancements) or CS fallback to 1x (A separate acronym is requested for this set of work "SAES2-CSFB").229. 24.103 Overview of 3GPP Release 11 V0. It is expected that much of the work in this WID will not however require separate stage 1 and stage 2 development. 24. 24. there may be minor stage 1 and stage 2 enhancements produced under TEI11. At Release 11 the need for other new capabilities is being identified. 29. At Release 9 and 10 further work was identified. 24.122.302. 24. that can be dealt with by this work item. 24.304.008. NOTE: End date will be coincident with freezing of Rel-11.303. 2. LTE was added as an access technology. 24. The scope of the work also includes: 1.8 SAE Protocol Development (Stage 3) (SAES2) UID_530019 Resources: UID 53001 9 C1 Acronym SAES2 Finish 07/09/201 2 Comp 75% Hyperlink CP110639 WI_rapporteur Nokia Siemens Networks Notes Stage 3 continuation of Rel-8 Feature SAES (3GPP System Architecture Evolution Specification Evolved Packet System) UID_320005 TSs_and_TRs - Name SAE Protocol Development 53011 9 SAE Protocol Development (Stage 3) SAES2 07/09/201 2 75% CP110639 Nokia Siemens Networks 53021 9 CS Fallback in EPS Phase 2 SAES2CSFB 07/09/201 2 75% CP110639 Nokia Siemens Networks - 23. 24. 24. The work does not cover PS domain enhancements where parallel changes are identified to both EPS and GPRS.229. and packaging them under a single work item. 24.302. The work item is not a substitute for issues where a feature has already been created by other WG (a separate building block should be created for that WID). 24. 24. The feature set in Release 8 provides a basis for EPS support.008. or for work involving significant changes over multiple CRs in CT1 (where a separate feature WID should be created). 24.1. Objective There may be technical improvements and enhancements to EPS. 24.118 23. NEC. The work also does not cover changes to home Node B and home eNode B. 24. or minor stage 1/stage 2 requirements coming from 3GPP2 that could be further developed at stage 3 under this work item.305. 29.304. 24.167. 29.167.122.018.301. Justification In Release 8. 24. 3GPP .312. Nokia Siemens Networks.118 Supporting Companies: Alcatel-Lucent.

there is no impact on Stage 1 fTS 42. Updated WID CP-110640=>CP-120279 TSs_and_TRs Stage 2/3 43. fire.002 Supporting Companies: Nokia Siemens Networks.104 Overview of 3GPP Release 11 V0. 42. some redundancy in the Core Network is required in order to cope with MSC single outages. Hence.236) and guarantee e.CT4 part Finish 07/09/201 2 Comp 97% Hyperlink CP120279 53012 0 53022 0 07/09/201 2 15/06/201 2 95% 100% CP120279 CP120279 Notes Stage 2/3 adding a CN internal functionality. no Stage 1 impact for VGCS/VBS (42. 43. These enhancements have been added to Rel-7 (TS 43.069 29. earthquakes. For the coexistence of VGCS/VBS and the "Intra-domain connection of RAN nodes to multiple CN nodes" within the same network special enhancements for voice group calls and voice broadcast calls are required. therefore.068. 29.g. This work item introduced the concept of A/Gb flexibility (see 3GPP TS 23. In railway operation the point-to-multipoint communication services Voice Group Call Service and Voice Broadcast Service (TS 43. Justification Railway traffic management is a safety and "Quality of Service" critical operation. Related Study Item or Feature (if any) UID Title 704 Rel-8 Feature: Enhancements for Voice Group Call Service 2 (VGCS) Applications (EVA) 704 Rel-7 Feature: Interoperability between VGCS/VBS and A/Gb 3 flexibility (VGCSFlex) 224 Rel-5 Feature: Intra Domain Connection of RAN Nodes to 3 Multiple CN Nodes (IUFLEX) If no identified source of stage 1 information. Sagemcom Nature of relationship The present WI further enhances the Voice Group Call Service.069. TS 42.C4 Resource C1. The present WI further enhances the use of A/Gb flexibility for Voice Group Call Service. This feature has been added to the 3GPP standard in Rel-5 (see 3GPP TS 23. Therefore. This redundancy functionality is required for the case of unplanned external events (as e.g.g. terrorist attacks) as well as for the case of planned events (as e. Kapsch CarrierCom. the Group Call Serving MSC (GCSMSC) and its associated GCR.069) CP#56 updated WID CP-110640=>CP120279. and 23.069) are frequently used. This WID covers the technical solution for Group Call Serving MSC redundancy.C4 C1 C4 WI_rapporteur Nokia Siemens Networks Nokia Siemens Networks Nokia Siemens Networks Name GCSMSC and GCR Redundancy for VGCS/VBS (Stage 2/3) CT1 part Deleted . However this approach does not support redundancy of the network entities required for VGCS/VBS. justify: This WI adds a CN internal functionality. that also in a network using "Intra-domain connection of RAN nodes to multiple CN nodes" a setup request for a voice group call or voice broadcast call is routed to the appropriate serving Anchor MSC.069. 3GPP .068 and 43.002. but does not affect the VGCS/VBS as perceived by the service subscriber. Completion 06/12=>09/12 CP#56 stopped (no CT4 impact).CT4 part UID 53002 0 Name GCSMSC and GCR Redundancy for VGCS/VBS (Stage 2/3) CT1 part Deleted . Objective In an ASCI capable network the subscribers must be able to establish VGCS/VBS calls even if one MSC of the group call is out of service. Huawei.068. not affecting Voice Group Call Service (VGCS)/VBS as perceived by service subscriber.1.068. This concept has been elaborated by the ETSI Technical Committee TC-RT (Railway Telecommunications).236) and allows providing a redundant MSC configuration ("MSC pool") for the support of point-to-point communication services.9 GCSMSC and GCR Redundancy for VGCS/VBS (Stage 2/3) (RT_VGCS_Red) UID_530020 Resources: UID 530020 530120 530220 C1.1 (2012-06) 9. maintenance activities) which may cause downtimes of an MSC or the transport network between MSCs. 43. This WID covers the work for specifying a redundancy solution which is based on the feature "Intra-domain connection of RAN nodes to multiple CN nodes".068.236).

1. as a whole.069.x Enhancement of the Protocols for SMS over SGs (PROTOC_SMS_SGs) UID_540016 (CP#56 stopped) Resources: UID 54001 6 C4.818) CP#56 stopped (abandonned new TS 29.068 and TS 43. The backup GCSMSC must have the same information about the given voice group call / voice broadcast call as the failed one.105 Overview of 3GPP Release 11 V0.1 (2012-06) The basic requirement for the MSC redundancy is that more than one MSC can be reached from the same geographical location. or b) be available on both MSCs.CT4 part 54011 6 54021 6 54031 6 C4 C4 CP120034 CP120034 CP120034 Alcatel-Lucent Alcatel-Lucent new TR 29. The Group Call Register. This is ensured by the RANFlex pool concept. is the possibility of routing the signalling to a backup GCSMSC when the original target is out of service.218 Diameter based protocols for SMS service over SGs) CP#56 stopped TSs_and_TRs Stage 3 Name Deleted Enhancement of the Protocols for SMS over SGs (Stage 3) Deleted . 43.068 Deleted . Vodafone. Verizon Wireless. new TS 29. Service Aspects: This work will not impact specific services but enables to use VGCS/VBS in a redundant core network configuration.818 29. 24.CT1 part C1 Alcatel-Lucent Supporting Companies: Alcatel-Lucent.040.TR Study Deleted . Cisco 3GPP .C1 Hyperlink CP120034 WI_rapporteur Alcatel-Lucent Notes CP#56 stopped.011.218 23. and therefore it is proposed not to update MAP message description in stage 3. therefore the information about the given voice group call / voice broadcast call shall: a) be reachable from the primary and backup MSCs. 9. The second step. and some interfaces related to it are not fully described in TS 43. Reason: Protocols for SMS over SGs is replaced by the SIMTC SMS in MME solution (as solution not only for MTC user but for general subscribers) CP#56 stopped (abandonned new TR 29.C1 Resource C4.305. covered by the present WID.

106 Overview of 3GPP Release 11 V0. Deutsche Telekom. Genband. Co-existence of this new registration mechanism with the NGCN IP-PBX registration procedures already defined in IMS must be ensured. TSs_and_TRs 24. Ensure co-existence of this new registration mechanism with NGCN IP-PBX registration procedures already defined in IMS. NGCN specific Trunking stage 2 impacts (e. RFC 6140 also defines extensions which allow the NGCN to provide its UAs with public or temporary Globally Routable UA URIs (GRUUs). The NGCN registers reachability information with the NGN. SIP Forum in SIP-Connect 1. RFC 6140 allows a NGCN to enter into a trunking arrangement with a NGN operator whereby the two parties have agreed on a set or range of E.228 ‘IMS stage 2’ architecture and reference points are applicable Justification With RFC 6140 the IETF has developed a solution which satisfies the requirement to route requests based on ITU-T recommendation E. as a large number of SIPPBX manufacturers have indicated their support for RFC 6140. Backward compatibility is considered by the definition of the new option-tag ‘gin’. Huawei. Nokia Siemens Networks.g. these SIPPBXs will send REGISTER requests which contain both "Require:gin" and "Proxy-Require:gin" SIP header fields. Support procedures and protocol extensions in RFC6140 "Registration for Multiple Phone Numbers in SIP" to IMS for complex UEs. no further stage 2 impact. Belgacom. If IMS does not include RFC 6140 support.164 numbers assigned to the NGCN. 3GPP TS 23.1 (2012-06) 9. other SDOs have chosen RFC 6140 as standard mechanism for registration of NGCN SIP-PBXs.1. and if IMS registrars do not support the "gin" extension these registrations will fail.164 number ranges.g. Market reviews have confirmed there will be a need for the NGN to implement RFC 6140.229 Name Support of RFC 6140 in IMS Supporting Companies: CableLabs. e. Furthermore. Telecom Italia Related Study Item or Feature (if any) Title Nature of relationship Business Business Communication Requirements in ETSI TS 181 019 as a part of Common IMS requirements.1. Security Aspects: mechanisms. which enables the NGN to route to the NGCN inbound requests targeted at the assigned telephone numbers. Objective: Add support for the procedures and protocol extensions as defined in RFC 6140 “Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)” to IMS for complex UEs. Being the designated IETF solution for business trunking scenarios. Research in Motion. Access Network Interconnection) considered by ETSI TSs 182 023 ‘Core and NGCG interaction’ and 182 025 ‘Business Trunking Architecture’. Security requirements described in RFC 6140 have to be evaluated against the existing security 3GPP .10 Support of RFC 6140 in IMS (GINI) UID_540015 Resources: UID 54001 5 C1 Finish 07/09/201 2 Comp 80% Hyperlink CP110760 WI_rapporteur Deutsche Telekom Notes Stage 3.

Specific actions may need to be taken by the MGW Control nodes (MGCF. Iq. 29.334 29.232. 29. specify the stage 3 extensions/procedures for the Ix. 29. should be considered.C3 Finish 07/09/201 2 Comp 35% Hyperlink CP110806 WI_rapporteur Telcordia Notes Stage 3. Depending on stage 2 requirements. This WID is focused on the H. 29.162. Stage 2 and possibly stage 3 work is required to support priority treatment (including prioritization of H.248 signalling) for MPS calls/sessions for H. Stage 1 for MPS in 22. IBCF.248-related interfaces.292 Supporting Companies: Justification Telcordia Technologies.153.1 (2012-06) 9.11 Enhancements for Multimedia Priority Service (MPS) – Gateway Control Priority (eMPS_Gateway) UID_540017 Resources: UID 54001 7 C4. Mp. but no such MGCF procedures are defined in TS 29. Iq. National Communications System (NCS).334. Details of any MGW actions for priority needs to be further studied within the scope of this WI.107 Overview of 3GPP Release 11 V0. 23. The details of any MGW actions for priority needs to be further studied within the scope of this WI.248-related IMS Core Network impacts and MGCF signalling interworking procedures only and does not include the radio access and the packet core network impacts.163. 29. as those have already been addressed in 3GPP REl-8 standardisation work under the Enhancements to Multimedia Priority Service (ePRIOR) WI.153.163. Objectives: • • • Specify the stage 2 requirements for the Ix. Mp.332. Specify MPS related signalling interworking procedures between IMS and CS networks at the MGCF. and Mn interfaces to provide priority treatment for MPS calls/sessions. 29.1. The requirements for a MPS call/session is that the call/session shall be given priority over normal calls/sessions and may be given priority over national emergency calls/sessions while nodes or/and network routes are in overload or congestion situations.C3 Resource C4. Mc.238. CP#56 completion 06/12=>09/12 CP#56 completion 06/12=>09/12 TSs_and_TRs Stage 3 Name Enhancements for Multimedia Priority Service (MPS) – Gateway Control Priority 54011 7 54021 7 CT4 part C4 07/09/201 2 07/09/201 2 50% CP110806 CP110806 Telcordia CT3 part C3 20% Telcordia 23. Mc. if needed. MGW nodes and/or network routes may experience overload situations and therefore. Alcatel-Lucent Stage 1 requirements for the Multimedia Priority Service (MPS) are contained in 3GPP TS 22. and Mn profiles to provide priority treatment for MPS calls/sessions. 29.333. 3GPP . AT&T.153. IMS-ALG. MRFC) when handling requests towards the serving MGW.333. MPS signalling interworking procedures between IMS and CS networks are also required according to TS 22.

Cisco. the unpredictable nature of application usage has introduced big challenges to the GERAN network to guarantee the user experience. etc. Alcatel-Lucent. Justification In recent years diverse data applications have been gradually introduced into the GERAN network such as IM chatting. Once GERAN/CT/SA2 a solution agreed.C3. In this example.C3 G2 Hyperlink CP-120033 CP-120033 GP-111876 WI_rapporteur China Mobile China Mobile China Mobile.C4. 23. Huawei Name Service Identification for RRC Improvements in GERAN (Stage 2/3) Stage 2 CN aspects GERAN2 part UID 53000 3 Name Service Identification for RRC Improvements in GERAN (Stage 2/3) Resource S2. Huawei. 23. In some GERAN networks.C3 C4 C3 86% 80% 100% CP120033 CP120033 CP120033 Notes CT define a generic solution (not only for GERAN). This would require the standardization of procedures for the PS domain to identify and transfer this related service information to the BSS.212 Supporting Companies: Networks China Mobile. push services.G2 S2 C4.CT3 part C4. ZTE. The rapid take up of mobile data usage has led to a significant increase in radio resource utilisation in the network. Nokia Siemens If no identified source of stage 2 information. Vodafone.12 Service Identification for RRC Improvements in GERAN (SIRIG) UID_530003 Resources: UID 53000 3 56000 8 54001 8 53010 3 S2.251 29. Minor Stage 2 impacts expected. social networks. justify: Impacts on stage 2 specifications are expected to be minor.060CR1680 (Introduction of SIRIG).C3. GERAN would benefit from identifying the new service information associated with a mobile data application to improve radio resource control and management as well as user experience.G2 Resource S2. SA2 Stage 2 can be updated SP-120252 [23. This has significantly increased data usage in the GERAN network. SA2 can update their stage 2 specifications accordingly.G2 Finish 23/11/201 2 Comp 47% Hyperlink CP120033 56000 8 54001 8 54011 8 55000 9 Stage 2 S2 07/09/201 2 07/09/201 2 07/09/201 2 15/06/201 2 90% - CN aspects CT4 part Deleted . Once a solution is agreed by GERAN/CT/SA2.281 29.060.C3. while preserving the end-toend QoS architecture controlled by the core network. Ericsson. HTTP/WAP browsing.251CR0063 (SIRIG support in shared networks)] Stage 3 CP#56 completion 06/12=>09/12 CP#56 stopped (SA2 decided NO CT3 impact) TSs_and_TRs GERAN 23. some services such as IM chatting may unnecessarily and frequently occupy radio resources for a long time to the detriment of other applications which may suffer from network congestion.C4.1 (2012-06) 9. S2114557 recommends GERAN/CT document solution(s) and get SA2 feedback before GERAN/CT finalization. 3GPP .1.C4. SA2 recommended (S2-114557) that GERAN in cooperation with CT investigate and document solution(s) and then communicate with SA2 to get feedback before GERAN and CT finalize their solution. As a result.108 Overview of 3GPP Release 11 V0.

etc. LG Electronics Justification China Mobile. while preserving the end-to-end QoS architecture controlled by the core network. GP#51 approved WID TSs_and_TRs 48. For GTP-U based interfaces. and to achieve an improved GERAN utilisation of radio resources while avoiding any impact to the radio interface and radio protocols and minimising the impacts upon the end-to-end QoS architecture.018 Supporting Companies: Lucent. This applies only to downlink traffic. In some GERAN networks. Nokia Siemens Networks. social networks. Vodafone. push services. Objective In order to improve the GERAN network radio resource control and management as well as user experience for mobile data services. Objective: to specify the necessary changes in the GPRS Core and EPC to provide the RAN with the service information associated to an application. the unpredictable nature of application usage has introduced big challenges to the GERAN network to guarantee the user experience. this work item aims to: • • standardise procedures. GERAN2 part of Service Identification for RRC Improvements in GERAN (SIRIG) UID_530103 UID 53010 3 Name GERAN2 part Resource G2 Finish 23/11/201 2 Comp 5% Hyperlink GP111876 Notes GP#54 completion 05/12=>11/12. ZTE. some services such as IM chatting may unnecessarily and frequently occupy radio resources for a long time to the detriment of other applications which may suffer from network congestion. In this example.109 Overview of 3GPP Release 11 V0. This work item applies to GERAN only. Alcatel- In recent years diverse data applications have been gradually introduced into the GERAN network such as IM chatting. As a result.1 (2012-06) This is a CT-wide WID. HTTP/WAP browsing. This has significantly increased data usage in the GERAN network. but it does not preclude the solution from being generic. GERAN would benefit from identifying the mobile data application/service type to improve radio resource control and management as well as user experience. HUAWEI. it is proposed to convey this new service information within an extension defined in the GTP-U header. 3GPP . messages and information elements as necessary in the PS domain (on the Gb interface) to allow for the Core Network to deliver service specific attributes requested by a GERAN BSC.1. This would require the standardization of procedures in the BSS to retrieve service/application type indication from the PS domain Core Network. The rapid take up of mobile data usage has led to a significant increase in radio resource utilisation in the network. Ericsson.

g. IMS based services (e.007 (AT comds to control MT functions and GSM/UMTS/LTE network services from TE.005 (AT commands for SMS). VoLTE).005. Currently address types for AT comds based on dialling # TSs_and_TRs 27.005 Use of Data Terminal Equipment .007 Name AT commands for Universal Resource Identifier (URI) support Supporting Companies: Justification Intel. R C Subject Approved at plenary# Comments 27. 27.g. AT commands for Short Message Service are defined in 3GPP TS 27. Ericsson. but currently it is not possible to support IMS based services e. Motorola Mobility TS 27.005.007 specifies AT commands for controlling Mobile Termination (MT) functions and GSM/UMTS/LTE network services from Terminal Equipment (TE).007 AT command set for User Equipment (UE) CT#58 27. 27.DCE) interface for Short Message Service (SMS) and Cell Broadcast Service (CBS) 3GPP . VoLTE) can require addressing by Universal Resource Identifiers (URIs).Data Circuit CT#58 May be affected terminating Equipment (DTE .1 (2012-06) 9.g.13 AT commands for Universal Resource Identifier (URI) support (ATURI) UID_560005 Resources: UID 56000 5 C1 Acronym ATURI Finish 07/12/201 2 Comp 10% Hyperlink CP120275 WI_rapporteur Intel Notes Define new AT comds for URI addresses for IMS services (e. ST-Ericsson.110 Overview of 3GPP Release 11 V0.1. 10 Expected Output and Time scale Affected existing specifications [None in the case of Study Items] Spec No. Currently the allowed address types for the specified AT commands are based on dialling numbers. Objective: to define new AT commands to be used with URI addresses for IMS services. New or modified AT commands in the following scenarios shall be considered: • Voice call initiation • Phonebook support • MMTel supplementary services • Messaging URI schemes and URI parameters required for relevant IMS services shall be supported. 27. to initiate dialling of URIs via AT commands or to include URIs in AT commands for supplementary services.

In this case the original MSISDN may be used for charging and OA&M purposes and forwarded to the PS gateway to other packet data networks. There is an urgent need of this feature by several operators. S6a. 11. This means in addition to the calling party address another number is sent during the setup and the terminating side uses this additional calling party address for CLIP.002. During setup of an outgoing call the gsmSCF can send a generic number in the CAP connect message (for CS calls) to the gsmSSF. 22. No Stage 2 needed since no architecture impact. The MME / SGSN uses the content of this field for further session routing. 29. 23. For this reason SA1 asks for a completion within Rel. This is to ensure backward compatibility and should be taken into account in the updates . This reverse logic is illustrated with the use case in the annex B of 3GPP TS 22.101 clause 17.272. 29. 11. Vodafone. Objective: to meet the Stage 1 requirement it is proposed to introduce in Stage 3 the possibility to assign an additional MSISDN. 10 Expected Output and Time scale 3GPP . If such a field is not defined. in addition to the original MSISDN. If this additional MSISDN is available it shall be used for correlation of CS and IMS in voice call and service continuity as well as IMS Centralized Service.101 and explained in the LSs S1-120248 and S1-121432.101 Deutsche Telekom. Nokia Siemens Networks Remarks Urgent need of this feature by several operators therefore SA1 asks for a completion within Rel.3 Justification A lot of CAMEL / IN services are deployed in today's networks. in the HSS and MME / SGSN are affected. e.14 PS Additional Number (Stage 3) (PSAN) UID_560006 Resources: UID 56000 6 C4 Acronym PSAN Finish 07/09/201 2 Comp 20% Hyperlink CP120253 WI_rapporteur Deutsche Telekom Notes Stage 1 in Rel-11 SA1 TS 22. Orange.1.7.003. as C-MSISDN for SRVCC.1 (2012-06) 9.008. If such a field is defined the content needs to be unique.7.g. Reference points to the MME / SGSN (Gr.111 Overview of 3GPP Release 11 V0. there is no change to existing procedures. Huawei. The content of the original (already existing) MSISDN field is used for charging and forwarded to the GGSN / P-GW. The requirement says that it shall be possible to conditionally include an additional MSISDN field (A-MSISDN) in the location update procedure from the HSS to the MME / SGSN. to a user with PS subscription. Clause 17. This means the value of the A-MSISDN field should be the C-MSISDN and the content of the MSISDN field could be a new MSISDN number.230 Name PS Additional Number (Stage 3) Supporting Companies: Other justification TS or CR(s) Or external document LS S1-113097 S1-121395. The content of this parameter is mapped on the “additional calling party” field on the ISUP setup message. The other reference points and the charging are not affected. 29. Some of them make use of the so called “generic number”.3 (No Stage 2 needed since no architecture impact) TSs_and_TRs 23. For IMS calls a similar behaviour could be achieved by using multiple IMPUs. S6d) and some update of the location procedures. CR 0411 LS S1-121432 TS. For PS domain such possibility for a simple and flexible implementation of certain IN services is missing The agreed Stage 1 requirement to provide such flexibility for PS domain needs to be put in place in Stage 3.

329 Allow transmission of an additional MSISDN from HSS/HLR to SGSN (or MME via IWF) Allow transmission of an additional MSISDN over S6a/S6d Allocate AVP code for A-MSISDN Considering the impact on Sh due to support of A-MSISDN (Align with 29.112 Overview of 3GPP Release 11 V0.003 Definition of an additional MSISDN and update the definition section of C-MSISDN accordingly 23.328 29.008 Update the subscriber data for the PS domains with the additional MSISDN 29.1 (2012-06) Affected existing specifications Spec CR Subject No.328 if needed) Approved at plenary# Comments CT#57 (September 2012) CT#57 (September 2012) CT#57 (September 2012) CT#57 (September 2012) CT#57 (September 2012) CT#57 (September 2012) CT#57 (September 2012) Possible impact 3GPP . 23.1.230 29.002 29.272 29.

1.113 Overview of 3GPP Release 11 V0. user membership as transparent data over the Sh interface and stored in he HSS. ATT . the list of users. 29. user membership) which is transferred over Sh in the transparent data associated to standardized Sh Service Indication(s). Objective The WI will specify the generic basic set of data for a group of IMS users (group identifier. Verizon Wireless. Orange. There is an operator requirement to introduce standardisation of a basic generic set of user group data (group identifier.1 (2012-06) 9. user membership) so that to avoid proprietary definition of such data as it generally differ between ASs supporting different groups services and between different AS suppliers. list of members. Deutsche Telekom.364 Specification of IMS user group information elements identifying the group. The WI is at stage 3 level as having no stage 2 consequences on IMS core. The service content of an IMS user group is out of the scope of the WI. Nokia Siemens User groups in IMS are managed by Application Servers which may transfer associated data describing the group.15 Generic IMS User Group Over Sh (GenUG_Sh) UID_560007 Resources: UID 56000 7 C4 Acronym GenUG_Sh Finish 07/09/201 2 Comp 0% Hyperlink CP120254 WI_rapporteur Alcatel-Lucent Notes TSs_and_TRs 29. the user membership within transparent data identified by standardized service indications over the Sh interface Approved at plenary# CT#57 (September 2012) Comments CT4 responsibility 3GPP .364 Name Generic IMS User Group Over Sh Supporting Companies: Networks Justification Alcatel-Lucent. 10 Expected Output and Time scale Affected existing specifications Spec CR Subject No.

1 37.R2 R2.4 36.R3.R1.R5 Acronym e850_UB Resource R4.Part 2 Acronym e850_UB SONenh2_LTE_UTRA eMDT_UMTSLTE medBS_class_LTE_MSR HSPA_LTE_measRP_MIMO EHNB_enh1 EHNB_enh2 Resource R4.1 36.1 25.1 36.1 36.1 25.1 37.1 36.R5 Finish 07/09/201 2 Comp 86% Hyperlink RP111396 Status_Report WI_rapporteur Sprint Notes Stage 3 Triggered by R4 Rel-10 LTE TR 37.4 25.R2.1 36.1 25.3 37. part e850_UBPerf R4.R2.1 36.R3.R2.R3.3 37.1 25.1 36.114 Overview of 3GPP Release 11 V0.1 25.1 25.R2.1 25.1 25.806 Study on Extending 850 MHz (UID_440016 ) RP#55 completed Name Extending 850 MHz Upper Band (814 – 849 MHz) TSs UTR 50012 0 Core part e850_UBCore R4.1 Extending 850 MHz Upper Band (814 – 849 MHz) UID_500020 Resources: UID 50002 0 R4.1 (2012-06) 10 UID 50002 0 53003 0 53003 3 53003 7 55001 6 56001 3 56001 4 UTRA.Part 1 Further enhancements to H(e)NB mobility .4 36. LTE Features Name Extending 850 MHz Upper Band (814 – 849 MHz) Further Self Optimizing Networks (SON) enhancements Enhancement of Minimization of Drive Tests for E-UTRAN and UTRAN E-UTRA medium range and MSR medium range/local area BS class requirements Verification of radiated multi-antenna reception performance of UEs in LTE/UMTS Further enhancements to H(e)NB mobility .1 36.4 25.R2 WI_rapporteur Sprint Nokia Siemens Networks MediaTek Ericsson Vodafone Alcatel-Lucent Alcatel-Lucent 10.G1 R4 R3.1 36.R4 R4.1.3 36.3 36.1 3GPP .R3 02/03/201 2 100% RP111396 RP-120076 Sprint RP#55 completed 25.R3 02/03/201 2 100% RP111396 RP-120075 Sprint 50022 0 Perf.1 25.1 25.1 36.1 36.R5 R3.R2.R2 R3.1 25.R3.

5 36.5 36. and low-power SMR's will share the 854-862 MHz spectrum.pdf 3GPP .1. SMR and ESMR's both operate in the 851-861 MHz range. and 861-862 MHz is designated as a "Guard Band". although overlapping each other. The specific section on out of band emissions can be found in 47 CFR 90. business/industrial users.1 34. 860-861 MHz is designated as an "Expansion Band".1 (2012-06) RP110377 RP-120459 Sprint RP#56 completion 06/12=>09/12 34. and public safety. approved by the FCC in August 2004 [1]. ESMR has exclusive use of the 861-866 MHz range. There are many operators around the world using 800 MHz spectrum for non-3GPP technologies that would like to have the option of adopting 3GPP technologies Having many different bands that are different in different locations in the world.1 34. ESMR systems will have exclusive use of 862-869 MHz range. being capacity limited and LTE/HSPA migration is facilitated.fcc.18. Public Safety.5 36.5 36. This work item proposes to consolidate and augment bands 5. A discussion of the need for expanded 800 MHz support in the United States follows: In order to reduce the potential for interference between Public Safety operations and commercial operations the Federal Communications Commission developed a plan.g.gpo.5 36. Public Safety and Critical Infrastructure will have exclusive use of 851-854 MHz. it is easier to expand networks by adding frequencies when e.5 Triggered by R4 Rel-10 LTE TR 37.gov/fdsys/pkg/CFR-2009-title47-vol5/pdf/CFR-2009-title47-vol5-part90.1 34. to relocate commercial operations elsewhere in the 800 MHz band Before rebanding. The same applies to the base station implementations in principle. Public Safety has exclusive access to all vacated Nextel channels for 3 years.5 36. Business/Industrial. The addition of a new E850 band provides both the incumbent and new operators the choice of using existing specifications for bands 5.1 36.1 34. create a problem for UE implementations since the number of bands available in one UE is limited and this will reduce the economy-of-scale.gov/services/index. after which they are open to all eligible users. large bandwidth allocations create better opportunities and flexibility in service offerings: different channel bandwidths can be used. During rebanding the following will occur: • • • • All licensees with channels between 866-869 MHz (NPSPAC) must relocate to equivalent channels between 851-854 All licensees other than ESMRs with channels between 851-854 MHz must relocate to equivalent channels between 854-862 Nextel and other ESMR operators must relinquish all channels below 862 MHz. Roaming is simplified because a single band can support operations in several different countries. After rebanding. Hence it is beneficial to create a more harmonized frequency variant approach within the frequency range of 814-849/859-894 MHz.5 nationwide as soon as possible to provide additional spectrum for Public Safety needs.691.806 Study on Extending 850 MHz (UID_440016) Justification There are a number of 3GPP bands specified in the frequency range of 800 MHz to 900 MHz.htm?job=service_releases&id=smrs&page=reconfiguration_documents [2] FCC Web page with links to out of band emission requirements for 862-869 MHz http://www. The FCC rules and regulations for this band are codified in Title 47 of the Code of Federal Regulations (CFR) Part 90 subpart S[4]. 18 or 19 or to take advantage of the economies of scale that come with a consolidated 800 MHz band. Furthermore. References: [1] FCC Web Page with links to 800 MHz Rebanding http://wireless. and Public Safety has exclusive use of the 866-869 MHz range. and 19 into a new single global band that supports UTRA and E-UTRA deployments in the 814-849 and 859-894 MHz band. The FCC has required Nextel to vacate all its channels in the band from 854-854.1 34. No licensees other than ESMR are required to relocate to channels above 860 MHz.115 51001 6 Test part e850_UBUEConTes t R5 07/09/201 2 63% Overview of 3GPP Release 11 V0.

3 36. NEC. US Cellular. The solution defined for LTE in Rel-10 enables the network to detect MRO related problems if the UE re-connects to an LTE cell. enhancing the existing Rel. Telefónica. Even though the Automatic Neighbour Relation (ANR) function and the Minimization of Drive Tests (MDT)..2. CMCC.3 53013 0 Name Further Self Optimizing Networks (SON) enhancements Core part TSs UTR SONenh2_LTE_UTRA -Core 07/09/201 2 40% RP120314 RP-120491 Nokia Siemens Networks RP#55 updated WID RP111629=>RP120314 25. cause unnecessary CN signalling. but since there was no time to complete it during Rel-10 due to some work prioritisation. It has been argued that inter-RAT ping-pongs.8 mechanism. threshold for the measurement) for inter-RAT mobility and for HetNet deployments.4 25.11.902. but never solved. Orange. China Unicom. MediaTek. AT&T. was completed with appropriate support for LTE. Nokia Siemens Networks. 3GPP . Hitachi.3 25.4 36. ZTE. this MRO enhancement topic may include coordinated configuration of the mobility parameters (e. based on UE History Information was found relevant to be addressed in Rel.3 36. Upon acceptance in RAN the second phase will then complete the specification of the agreed items.2 Further Self Optimizing Networks (SON) enhancements UID_530030 Resources: UID 53003 0 R3. Currently there is no mechanism to detect such event and to enable its correction.g. namely the Mobility Robustness Optimisation Enhancements (MRO).116 Overview of 3GPP Release 11 V0. Therefore. Objective: to be completed in two phases: In the first evaluation phase the proposed objectives and use cases will be investigated as to applicability and value. SON aims at maintaining network quality and performance with minimum manual intervention from the operator.1. Deutsche Telekom. were introduced during Rel-10 in UTRAN as well. it is possible after a connection failure the UE selects a cell at different RAT. The need for an adequate inter-RAT solution was identified.4 Supporting Companies: Alcatel-Lucent. As stated in the TR 36. KDDI. Nokia Corp.4 25. most problems that have SON solutions in LTE are not addressed in UTRAN. Hisilicon. LightSquared. In addition. TeliaSonera. T-Mobile USA 3 Justification Mobility Robustness Optimisation (MRO) enhancements For LTE.1 (2012-06) 10. For any of the objectives and use cases. the inter-RAT MRO enhancement topic was postponed. the SON (Self-Optimizing Networks) concept and many features have been standardised from Rel-8 to Rel10. specified in the LTE context. the responsible WG(s) shall propose to TSG RAN a selection of those items which provide sufficient benefits and support in order to justify the start of respective specification work until RAN#55.4 25. Introducing SON functions for UTRAN is also important for operators to minimize operating expenses. even though not resulting in a failure.R2 Acronym SONenh2_LTE_UTRA Finish 07/09/201 2 Comp 40% Hyperlink RP120314 Status_Report WI_rapporteur Nokia Siemens Networks Notes Stage 1. However. Inter-RAT ping-pong scenarios Already during the stage-1 work on SON in Rel-9 some problems related to mobility have been identified. Telecom Italia. CHTTL. One of the use cases addressed in Rel-10. Huawei. there are mobility issues that do not lead to connection failures.4 25.

depending on the UE capabilities. The detection is always in the cell of the same RAT as the cell where the correction should be made: at 3G. In RAN2 if needed. define the required support over the existing HNB network interfaces for establishing and maintaining neighbouring relation information if needed. when the UE returns from LTE. b) 3) Inter-RAT ping-pong resolution: A UE is handed over from a source cell in a source RAT (A) to a target cell in a target RAT (B) different from the source RAT.1. Reconfig. but passes through more than one cell before returning to the source RAT. but within the “definable limited time” the UE is expected to return to an eNB connected to the source eNB via X2. the source cell (i. provide stage 3 specification.g. the UE may return to other cell that the one that started the ping-pong. at LTE. or at another cell. in particular a HOF during an HO (during RACH attempt in LTE) or a RLF in LTE shortly after a HO (after successful RACH) 2) Connection failure resolution support for HetNet deployments in case of following problems: a) After HO preparation from a macro cell to a pico and due to high speed mobility UE fails connection to the pico (e. contact any other TSG/WG if impact in their domain is encountered. but will not be able to identify which HO criteria are wrong. and where the UE is being handed over back to a cell in the source RAT (A) within a “definable limited time”.g. Also. If a UE is handed over to the pico and a failure happens soon after the HO is successfully completed. review applicability of the existing and new SON features for HeNB and HetNet deployments. and the UE reconnects at the source cell. provide stage 2 specification. or succeed in connecting to the pico but shortly after be subject to RLF and re-establish connection to the source cell or to another macro. HO criteria at a macro for a HO to a pico may differ. the too early or wrong cell HO resolution is triggered. Complete) and successfully re-establish connection to the source cell or to another macro cell. reconnection at 2G/3G (too late HO) Failure during or after a HO from 2G/3G to LTE and reconnection back at 2G/3G (source RAT). the cell that started the HO to the pico) will receive the HO REPORT.117 Overview of 3GPP Release 11 V0. if needed. e.e. In the presence of CRE. define O&M requirements for radio-related functions to be performed in the O&M domain. However.1 (2012-06) After the first evaluation phase the following use cases and scenarios have been agreed to be taken forward to the second specification phase: 1) Inter-RAT failure issues related to deployment of LTE over broader 2G/3G coverage: a) b) Failure while in LTE or during a HO to 2G/3G. fail RACH access or fail RRC Conn. if the UE stays at the target RAT still within the “definable limited time”. should also be considered as an interRAT ping-pong. enable necessary UE support for the selected solutions provide stage 2 specification for the required UE & radio procedures provide stage 3 specification for TSs under RAN2 responsibility 3GPP . the problem can be detected at the RNC. Specification work agreed to be started after the investigation phase shall include: In RAN3 define the use-case level requirements. may be at different cell than the source one (too early HO).

parts GERAN part R4 G1 0% 0% RP-120493 - Ericsson Ericsson GP#52 3GPP . 25. 36.118 Overview of 3GPP Release 11 V0.123.413.225.331. 37.320 10.413. 25.133. 25.1 (2012-06) 10.3 TSs_and_TRs UTRA.R3. 36. 25.R4 Acronym eMDT_UMTSLTE Finish 07/09/201 2 Comp 60% Hyperlink RP120277 Status_Report WI_rapporteur MediaTek Notes Stage 2.423. 36. 25.214.331. 36.306.3 Enhancement of Minimization of Drive Tests for EUTRAN and UTRAN UID_530033 Resources: UID 53003 3 R2.G1 Finish 07/09/201 2 Comp 25% Hyperlink RP111383 Status_Report WI_rapporteur Ericsson Name E-UTRA medium range and MSR medium range/local area BS class requirements Core par 53013 7 53023 7 54000 2 medBS_class_LTE_MSRCore medBS_class_LTE_MSRPerf medBS_class_LTE_MSRGERAN R4 07/09/201 2 07/09/201 2 31/08/201 2 70% RP111383 RP111383 GP111779 RP-120492 Ericsson Notes Stage require aligned ongoin UID_5 medium medium BS cla (medB ) RP#56 06/12= v100 fo - Perf.4 E-UTRA medium range and MSR medium range/local area BS class requirements UID_530037 Resources: UID 53003 7 R4.304.423. 36. 25. LTE 53013 3 Name Enhancement of Minimization of Drive Tests for EUTRAN and UTRAN Core part eMDT_UMTSLTECore 07/09/201 2 60% RP120277 RP-120489 MediaTek - 25.1. 36.R1.306.133.304.G1 Acronym medBS_class_LTE_MSR Resource R4.215. 25. 36. 25.

LTE TR 37. LTE Name Further enhancements to H(e)NB mobility . Core fu since Rel-6 & Re very generic test with 2 or more Rx HSPA_LTE_measRP_MIMOPerf 07/12/201 2 20% RP120368 RP-120496 Vodafone Rx diversity (def RAN4 enhanced (defined as Rel-7 HSPA). 25. 25.7 Further enhancements to H(e)NB mobility .803 under AI 12.Part 1 56011 3 Core part EHNB_enh1Core 07/12/201 2 0% RP120900 Alcatel-Lucent 25. 25. 36.469. LTE Name Further enhancements to H(e)NB mobility . 25.R2 Acronym EHNB_enh2 Finish 07/12/201 2 Comp 0% Hyperlink RP120901 WI_rapporteur Alcatel-Lucent Notes Stage 2/3.6 Further enhancements to H(e)NB mobility . LTE TR 37. Compare also Rel-10 WI HNB_HENB_mob_enh RP-110183 TSs_and_TRs UTRA. Triggered by FS_EHNB_enh (UTRA.5 Verification of radiated multi-antenna reception performance of UEs in LTE/UMTS UID_550016 Resources: UID 55001 6 R4 Acronym HSPA_LTE_measRP_MIM Finish 07/12/201 2 Comp 20% Hyperlink RP120368 Status_Report WI_rapporteur Vodafone 55011 6 Name Verification of radiated multiantenna reception performance of UEs in LTE/UMTS Perf. 25.Part 1 UID_560013 Resources: UID 56001 3 R3.2). Triggered by FS_EHNB_enh (UTRA.467.413.Part 2 Core part 56011 4 EHNB_enh2Core 07/12/201 2 0% RP120901 Alcatel-Lucent 25.803 under AI 12. 36. 25.413.413. Rx divers as part of Rel-8 b 10. 36.300. 36.469. part Notes Triggered by FS_HSPA_LTE_ -antenna.1 (2012-06) 10. 36.3.1.423 3GPP . 36.423 10.467.3.Part 1 UID_560014 Resources: UID 56001 4 R3.423.2) TSs_and_TRs UTRA.R2 Acronym EHNB_enh1 Finish 07/12/201 2 Comp 0% Hyperlink RP120900 WI_rapporteur Alcatel-Lucent Notes Stage 2/3.413.300.471.119 Overview of 3GPP Release 11 V0.

R2.R2 R4.R3.R2 R4 R4 R4 R4 R1.R2.R4 R4.R4 R4 R2 R1. Band 27 Carrier based HetNet ICIC for LTE LTE Advanced Carrier Aggregation in Band 38 LTE Advanced Carrier Aggregation in Band 41 LTE for 700 MHz Digital Dividend Relays for LTE (part 2) LTE Advanced Carrier Aggregation of Band 3 and Band 20 LTE Advanced Carrier Aggregation of Band 8 and Band 20 LTE Advanced Carrier Aggregation of Band 1 and Band 7 LTE Advanced Carrier Aggregation of Band 3 and Band 5 LTE Advanced Carrier Aggregation of Band 4 and Band 7 LTE Advanced Carrier Aggregation in Band 7 Signalling and Procedure for Interference Avoidance for in-device coexistence Coordinated Multi-Point Operation for LTE Network Energy Saving for E-UTRAN LTE Advanced Carrier Aggregation of Band 11 and Band 18 LTE Advanced Carrier Aggregation of Band 1 and Band 18 LTE Advanced Carrier Aggregation of Band 1 and Band 19 LTE Advanced Carrier Aggregation of Band 1 and Band 21 Acronym LCS_LTE-NBPS MBMS_LTE_SC LTE_CA_B3_B7 LTE_CA_B4_B17 LTE_CA_B4_B13 LTE_CA_enh LTE_CA_B4_B12 LTE_CA_B5_B12 LTE_CA_B7_B20 LTE_CA_B2_B17 LTE_CA_B4_B5 LTE_CA_B5_B17 eICIC_enh_LTE LTE_DL_FDD700 LTE_eDDA LTE_e850_LB LTE_CA_HetNet_ICIC LTE_CA_B38 LTE_CA_B41 LTE_APAC700 LTE_Relay2 LTE_CA_B3_B20 LTE_CA_B8_B20 LTE_CA_B1_B7 LTE_CA_B3_B5 LTE_CA_B4_B7 LTE_CA_B7 SPIA_IDC_LTE COMP_LTE Netw_Energy_LTE LTE_CA_B11_B18 LTE_CA_B1_B18 LTE_CA_B1_B19 LTE_CA_B1_B21 Resource R2.R2.R2.R4 R2.R3.R2 R4.1 (2012-06) 11 UID 43001 1 48002 6 48002 3 50001 7 50001 8 51003 0 51002 2 51002 3 51002 4 51002 5 51002 6 51002 7 51002 1 51002 8 51003 1 51003 2 51003 3 52001 5 52001 6 52001 7 52001 9 53002 3 53002 4 53002 5 53002 6 53002 7 53002 8 53003 1 53003 2 53003 6 54002 0 54002 1 54002 2 54002 3 LTE Features Name Network-Based Positioning Support in LTE Service continuity improvements for MBMS for LTE LTE Advanced Carrier Aggregation of Band 3 and Band 7 LTE Advanced Carrier Aggregation of Band 4 and Band 17 LTE Advanced Carrier Aggregation of Band 4 and Band 13 LTE Carrier Aggregation Enhancements LTE Advanced Carrier Aggregation of Band 4 and Band 12 LTE Advanced Carrier Aggregation of Band 5 and Band 12 LTE Advanced Carrier Aggregation of Band 7 and Band 20 LTE Advanced Carrier Aggregation of Band 2 and Band 17 LTE Advanced Carrier Aggregation of Band 4 and Band 5 LTE Advanced Carrier Aggregation of Band 5 and Band 17 Further Enhanced Non CA-based ICIC for LTE New Band LTE Downlink FDD 716-728 MHz LTE RAN Enhancements for Diverse Data Applications LTE E850 .R3.Lower Band for Region 2 (non-US).1.R1.R5 R3. Huawei China Mobile KDDI KDDI NTT DoCoMo NTT DoCoMo 3GPP .R4 R3 R4.120 Overview of 3GPP Release 11 V0.R4.R2 WI_rapporteur TruePosition Huawei TeliaSonera AT&T Ericsson Nokia Leap Wireless US Cellular Huawei AT&T AT&T AT&T China Mobile AT&T Research In Motion NII Holdings Nokia Siemens Networks Huawei Clearwire Ericsson Ericsson Vodafone Vodafone China Telecom SK Telecom Rogers Wireless China Unicom China Mobile Samsung.R2.R5 R4 R4 R4 R4 R4 R4 R4 R2.R1.R4 R1.R2 R4 R4 R4.R2 R4.R3.R3 R4 R4 R4 R1.R3.R2 R4.

R2.R3 R4.R3 Alcatel-Lucent Motorola Solutions Renesas Mobile China Mobile LightSquared LTE_enh_dl_ctrl LTE_B14_PSBB_HPUE LTE_Interf_Rej LTE_TDD_add_subfram e LTE_FDD_1670_US 3GPP .1 (2012-06) R1.R2.1.121 54002 5 55001 2 55001 3 55001 4 55001 7 Enhanced downlink control channel(s) for LTE Advanced Public Safety Broadband High Power UE for Band 14 for Region 2 Improved Minimum Performance Requirements for E-UTRA: Interference Rejection Additional special subframe configuration for LTE TDD LTE in the 1670-1675 MHz Band for US Overview of 3GPP Release 11 V0.R4 R4 R4 R4.R2.

Network-based location solutions are transparent to the user.R3.4 TS ( 36. such as surveillance. SRS measurement requirements (measurement period and accuracy 3GPP .3 36. including: • • Stage 2 specification of the UE positioning architecture. Polaris This work is linked to Rel-9: UID_400038 UID_380064 UID_420006 LCS Control Plane Solution for EPS Support for IMS Emergency Calls over GPRS and EPS Positioning Support in LTE (depends on this WI) (is extended by this WI) (is extended by this WI) U-TDOA is a field-proven positioning method widely deployed in the US at this time.2 36.4 36.1 Network-Based Positioning Support for LTE UID_430011 Resources: UID 43001 1 R2. Evaluation results have indicated that UTDOA can satisfy the FCC E911 terrestrial positioning technology performance requirements if suitable signal detection and processing algorithms are used.R1. as well as for scenarios where DL OTDOA is not supported. UTDOA also provides benefits in being usable in areas with insufficient satellite coverage to support A-GNSS/A-GPS.1 36. Alcatel-Lucent.R1. SA2 LCS Control Plane Solution for EPS. TruePosition AT&T.R4 07/12/201 2 80% RP120859 RP-120801 TruePosition 43021 1 Perf. so it has no impact on RAN capacity. Mobile-based solutions may be detected.4 36. and it is transparent to the UE.R3. This work also focuses on secure location solutions transparent to the user for various applications. protocol.1.1 (2012-06) 11. It does not require additional Uu interface signals required. TeleCommunication Systems. supports emergency services calls in US requiring high degree of accuracy.R4 Finish 07/12/201 2 Comp 34% Hyperlink RP120859 Status_Report WI_rapporteur TruePosition Notes RP#56 updated WID RP101446=>RP120859 RP#56 completion 06/12=>12/12 43011 1 Name NetworkBased Positioning Support in LTE Core part TSs LTE LCS_LTE -NBPSCore R2.1 36.R3.e. including legacy Rel-8 UEs. transparent to the UE). interface.122 Overview of 3GPP Release 11 V0.3 36. The solution should be backward compatible with Rel-8 networks and UEs that support LTE and EPS.R1. Andrew Corporation. The work includes support for network-based only positioning methods in LTE (i. and procedures for UTDOA (RAN2/RAN3) Specification of SRS measurement definition. Core part Objective: to specify support for UTDOA in LTE based only on Sounding Reference Signals (SRSs) being used for the uplink measurements.R4 Acronym LCS_LTE -NBPS Resource R2.4 36. Unique ID 400038 380064 420006 Related Study Item or Feature (if any) Title Nature of relationship LCS Control Plane Solution for EPS Support for IMS Emergency Calls over GPRS and EPS Positioning Support in LTE Dependency: 400038 depends on this WI Extension: 380064 capability is extended by this WI Extension: 420006 capability is extended by this WI Justification RAN1 has extensively evaluated Uplink Time Difference Of Arrival (UTDOA) as a network-based positioning technique for LTE.4 36.1 Supporting Companies: Wireless. part LCS_LTE -NBPSPerf R4 07/12/201 2 0% RP120859 RP-120498 TruePosition RP#56 completion 09/12=>12/12 36.1 36.

measurement configuration.1. RAN4) Specification of the interface and signalling support between UTDOA measurement units and between UTDOA measurement units and the E-SMLC (RAN3) o Signalling to include UTDOA measurements. Specification of procedures for UTDOA measurement triggering.1 (2012-06) • • requirements) and RF requirements based on SRS only (RAN1. control information. and measurement report transfer (RAN3) to specify measurement definitions. reports and accuracy requirements based on SRS only Perf. and assistance data transfer.123 Overview of 3GPP Release 11 V0. part Objective: 3GPP . assistance data transfer.

1. Alcatel-Lucent Shanghai Bell. handover to a target cell or reconfiguration of Scell(s).304.R3 Acronym MBMS_LTE_SC Finish 07/09/201 2 Comp 80% Hyperlink RP111374 Status_Report WI_rapporteur Huawei Notes - 48012 6 Name Service continuity improvements for MBMS for LTE Core part TSs_and_ LTE MBMS_LTE_SC -Core 07/09/201 2 80% RP111374 RP-120499 Huawei RP#56 completion 06/12=>09/1 2 25.322. Hitachi. LGE. Objective for Core • o o • • Specify mechanisms to enable the network to provide continuity of the service(s) provided by MBSFN in deployment scenarios involving one or more frequencies. 36.440. whether or not to receive and decode a service. 36.446.1 (2012-06) 11. However certain services may only be relevant to certain localised areas (smaller than the MBSFN area). Research In Motion.323. based on its current location. Making the network aware of the services that the UE is receiving or is interested to receive via MBMS could facilitate proper action by the network e.2 Service continuity improvements for MBMS for LTE UID_480026 Resources: UID 48002 6 R2. 36. Mobility procedures do not account for MBMS reception in Rel-9 and Rel-10.g. It should therefore be possible to provide location information relevant to a service so that a UE can select. Rel-10 makes provision for deployments involving more than one carrier and for the network could take into account a UE’s capability to operate in a specific frequency band or bands and/or to operate on one or several carriers. A UE might minimise its battery consumption if it is able to determine which services are relevant to its current location.321.443. 36. IPWireless. Orange. A UE in Idle Mode should be able to select/reselect cells in order to receive the desired service. 3GPP . Specify cell selection/reselection mechanisms to order to enable the UE to receive the desired MBMS service(s) in RRC Idle mode Specify the signalling mechanisms to enable the network to provide continuity of the desired MBMS service(s) reception in RRC Connected mode Provide the related MCE functionality for the above mechanisms. Unique ID 400039 330018 330019 330020 430007 Related Study Item or Feature (if any) Title Nature of relationship MBMS support in EPS EPS supports MBMS since Rel-9 LTE – Physical Layer The LTE physical layer is MBMS-ready LTE – Radio Interface Layer 2 and 3 Protocol MBMS was initially part of Rel-8 Aspect LTE – eUTRAN Interfaces MBMS was initially part of Rel-8 MBMS support in LTE MBMS LTE Rel-9 Justification In Rel-9 and Rel-10 a core set of MBMS features was specified. 36. In Rel-9 MBMS services are broadcast over a whole MBSFN area. MediaTek. based on its current location. 36. 36. HiSilicon. There is a need to further evolve this feature set in order to make the MBMS of LTE competitive. 36.441.300. 36. to facilitate service continuity of unicast services and desired MBMS services. 36 Supporting Companies: Huawei. 36. KDDI.444. Intel.331. Study and specify some approaches for introducing location information relevant to a service so that a UE may select. 36. NEC.124 Overview of 3GPP Release 11 V0. Alcatel-Lucent.442. whether or not to receive and decode a service.

1 (2012-06) • The impact of such mechanisms on legacy devices should be minimized (e.125 Overview of 3GPP Release 11 V0.1.g. 3GPP . it is tolerable if reception status of legacy devices stays unknown to the network).

TeliaSonera.1 Supporting Companies: TS or CR(s) Or external document TR36. 36. In Europe Band 3.2 Remarks Deployment scenarios Operating bands CA deployment scenarios Comment: Decision from last RAN plenary on this to have new WI for additional CA scenarios Work Item Description. Different CA combinations for these bands are of high priority for Region 1 - TSs_and_TR LTE 48012 3 Core part LTE_CA_B3_B7Core 07/09/201 2 45% RP120830 RP-120520 TeliaSonera 48022 3 Perf. Carrier Aggregation for LTE In Europe Band 3. Band 7 and Band 20 are interesting for LTE and LTE-Advanced deployment. part LTE_CA_B3_B7Perf 07/12/201 2 0% RP120830 RP-120521 TeliaSonera - 36. where band combination independent tasks are treated 3GPP . new generic TR 36. Band 7 and Band 20 are in general very interesting bands for LTE and LTE-Advanced deployment. Add the performance requirements for this band combination in the relevant specifications. • • • • • • A real band-plan combination in order to study RF and performance parameters and IM products is needed.1.2. 36.cde UE Rel-10". Other justification Clause 11. In region 1 we already have commercial LTE deployment Harmonised spectrum is available in Europe This band combination can serve many operators and is one of the 3 band combinations identified in: "TP.126 Overview of 3GPP Release 11 V0.1 (2012-06) 11.cde UE Rel-10 RP 100390 RP 091440 Orange. 36. Telefonica. In Europe LTE-Advanced usage can be foreseen in the near future in order to follow the data explosion.20 are interesting for LTE and LTEAdvanced deployment. TRab.2 A. The generic LTE-A inter-band scenario is a high – low band combination. Telecom Italia. Objectives • • • Specify for the inter-band CA with band 3 and band 7 all the RF and performance values as these are band combination dependent and can not be obtained from the generic scenario. This work covers the Band 3 and Band 7 combination UID 48002 3 Name LTE Advanced Carrier Aggregation of Band 3 and Band 7 Acronym LTE_CA_B3_B7 Finish 07/12/201 2 Comp 21% Hyperlink RP120830 Status_Report WI_rapporteur TeliaSonera Notes RP#56 updated WID RP100668=>RP120830.101.133.104. Finalize inter-band CA for Band 3 + Band 7 with 2 DLs and 1 UL.7. These inter-band combinations can fulfil ITU-R requirements with 2 x 40 MHz spectrum.912 TRab.3 LTE-Advanced Carrier Aggregation of Band 3 and Band 7 UID_480023 Resources: R4 In Europe Band 3. as high priority for region 1. Annex A.850 36.307. The different CA combinations for these bands are agreed in RAN4 to be of high priority for Region 1.1 11. Define the supported transmission bandwidths for this band combination. The suggested scenario covers additional the high – high band combination which is missing for the inter-band CA study. • WI complementary to the generic Carrier Aggregation for LTE. Different CA combinations for these bands are of high priority for Region 1.

AT&T proposes this work item to start RAN4 work on inter-band carrier aggregation of band 4 and band 17 as an initial set of bands for LTE-Advanced deployment.133. Ericsson.808 E-UTRA Carrier Aggregation BS radio transmission and reception RP-100390 RP-091440 revised to RP-100661 Justification In current RAN4 carrier aggregation work. a generic inter-band case has been used to carry out the study of the RF requirements for inter-band carrier aggregation. • Finalize the DL and UL with 2 x 10 MHz transmission bandwidth in the same WI.1. 36. new generic TR 36.4 LTE Advanced Carrier Aggregation of Band 4 and Band 17 UID_500017 Resources: UID 50001 7 R4 Acronym LTE_CA_B4_B17 Finish 07/12/201 2 Comp 23% Hyperlink RP111750 Status_Report WI_rapporteur AT&T Notes Stage 3 TSs_and_TRs LTE 50011 7 Name LTE Advanced Carrier Aggregation of Band 4 and Band 17 Core part LTE_CA_B4_B17Core 07/09/201 2 50% RP111750 RP-120522 AT&T - 50021 7 Perf. Many aspects of RF performance and inter-mod analysis are bandspecific and require to be evaluated for a real carrier aggregation band combination. 3GPP . 36.307 Supporting Companies: AT&T. 36.912 Feasibility study for Further Advancements for EUTRA (LTE-Advanced) TR 36.2 - TS or CR(s) Or external document Remarks Deployment scenarios Operating bands CA deployment scenarios Decision from RAN#47 on Rel-10 work guidance for Carrier Aggregation Feature UID_460007 Carrier Aggregation for LTE (LTE_CA) TR 36.307. • Add the performance requirements for this band combination in the relevant specifications. 36. ST-Ericsson. Work complementary to the generic "Carrier Aggregation for LTE". 36.101.2 A.141.127 Overview of 3GPP Release 11 V0. but with different timescales in order to follow the RAN#47 decisions on the way forward for carrier aggregation. treating band combination independent tasks RAN5 testing aspects will be considered.850 36. 36. Media Tek Other justification Clause 11.2.133. 36. Motorola Mobility.1 (2012-06) 11.101.1 11.104. Alcatel-Lucent. Qualcomm. part LTE_CA_B4_B17Perf 07/12/201 2 0% RP111750 RP-120523 AT&T - 36.104. Objective • Specify the band-combination specific RF requirements for band 4 and band 17 inter-band CA.

5 LTE Advanced Carrier Aggregation of Band 4 and Band 13 UID_500018 Resources: UID 50001 8 R4 Acronym LTE_CA_B4_B13 Finish 07/12/201 2 Comp 19% Hyperlink RP120905 Status_Report WI_rapporteur Ericsson Notes Stage 3. ST-Ericsson.133. RP#56 updated WID RP111678=>RP120905 - 50011 8 Name LTE Advanced Carrier Aggregation of Band 4 and Band 13 Core part TSs_and_T LTE LTE_CA_B4_B13Core 07/09/201 2 40% RP120905 RP-120524 Ericsson 50021 8 Perf. Nokia. Supporting Companies: Verizon.1. Motorola Mobility.133. 36.101. Alcatel-Lucent.850 36. 36. Qualcomm 3GPP .1 (2012-06) 11.101. part LTE_CA_B4_B13Perf 07/12/201 2 0% RP120905 RP-120525 Ericsson - 36.104. Nokia Siemens Networks.128 Overview of 3GPP Release 11 V0. 36.307. 36. 36. Samsung. new generic TR 36. Ericsson. LGE.

R2. Orange. subframe offset / no-subframe offset). Qualcomm. AT&T. and different network configurations (e. CMCC. ST-Ericsson. Objective Core: The detailed objectives build on top of the time domain ICIC in Rel-10 and include the following:  Finalizing the leftover work from Rel-10 on inter-freq/RAT TDM restricted RRM  Based on system performance gains. part eICIC_enh_LTEPerf R4 07/12/201 2 20% RP120860 RP-120501 China Mobile RP#56 completion 06/12=>12/12 Supporting Companies: Alcatel-Lucent.  UE performance requirements and possible air-interface changes / eNB signalling to enable significantly improved detection of PCI and system information (MIB/SIB-1/Paging) in the presence of dominant interferers for FDD and TDD systems.6 Further Enhanced Non CA-based ICIC for LTE UID_510021 Resources: UID 51002 1 R1. This work involved heavy evaluation work in RAN1 followed by discussions and specification work at other RAN WGs (RAN2. Motorola Solutions.(RAN1.g. depending on UE receiver implementations . Telecom Italia. RAN1 to first identify the scenarios for which UE performance requirements in the following two bullets will be specified in terms of.R4 07/09/201 2 65% RP120860 RP-120500 China Mobile 51022 1 Perf. CATT.1 (2012-06) 11.. Panasonic. KDDI. Telefonica. Renesas Electronics. Huawei. e. RAN2)  UE performance requirements and necessary signalling to the UE for significantly improved DL control and data detection and UE measurement/reporting in the presence of dominant interferers (including colliding and non- 3GPP . NEC.1.g. LGE.129 Overview of 3GPP Release 11 V0. China Unicom. Deutsche Telekom.R4 Finish 07/12/201 2 Comp 41% Hyperlink RP120860 Status_Report WI_rapporteur China Mobile Notes Stage 2/3. Fujitsu Justification The Rel-10 WI on “Enhanced ICIC for non-CA based deployments of heterogeneous networks for LTE” provides signalling and performance requirements in relation to the support of co-channel deployments of heterogeneous networks. Samsung.. a late RAN1 agreement that TDM resource partitioning can offer performance benefits and that the impact of legacy transmissions in almost blank subframes on control/data channels demodulation needs to be addressed in Rel 11 (R1-106529) motivates to complete the associated specification work as part of Rel-11.R3. Verizon Wireless.R2. RAN3 and RAN4). Mitsubishi Electric. Also. NTT DoCoMo. MediaTek.R3.R4 Acronym eICIC_enh_LTE Resource R1. Research In Motion.R2. number of interferers and their relative levels with respect to the serving cell. RAN4. Motorola Mobility.R3. This WI proposes to continue the specification work initiated in Rel-10 to further enhance ICIC for an efficient support of heterogeneous networks. Due to time limitations. RP#56 updated WID RP111369=>RP120860 RP#56 completion 06/12=>09/12 51012 1 Name Further Enhanced Non CAbased ICIC for LTE Core part eICIC_enh_LTECore R1. Ericsson. some identified techniques to enhance ICIC were de-prioritized for Rel-10. ZTE.

MBSFN used as ABS. Improved detection based on air interface enhancements to be considered .1 (2012-06) colliding RS. study the following aspects (to start after RAN #55):  Data channel ICIC enhancements. RAN4) Uplink enhancements e.g.1. ABS subframe configurations) for FDD and TDD systems depending on UE receiver implementations. for idle mode operation. as well as. RAN2)  Dominant interference applicable to both macro-pico and CSG scenarios and with or without handover biasing  As a second priority. uplink interference mitigation for Macro-Pico and Macro-Femto Identify interference scenarios stemming from different UL/DL configurations or muted UL subframe configuration in TDD and corresponding air interface change and CSI reporting requirements Dominant interference impacting on legacy UEs (Release 8/9/10)     Objective Perf. RAN2.. RAN2 and RAN3 specifications and the core part of RAN4 specifications. e.(RAN1.g. power saving and mobility enhancements (RAN1. as well as. 3GPP . FDM/TDM coordination and enhanced signalling for resource allocation. e.: Specify UE performance requirements related to further enhancements to non CA-based ICIC. RAN4..g. for the scenarios addressed in RAN1. or supporting the application of single-carrier time domain ICIC mechanism on the frequency of SCell in Carrier Aggregation setting Higher layer enhancements.130 Overview of 3GPP Release 11 V0. RAN3.

131 Overview of 3GPP Release 11 V0.R2 07/09/201 2 35% RP120877 RP-120526 Leap Wireless 51022 2 Perf.R2 Finish 07/12/201 2 Comp 16% Hyperlink RP120877 Status_Report WI_rapporteur Leap Wireless Notes Stage 3. Huawei.1. US Cellular. Nokia Siemens Networks.1 (2012-06) 11. RP#56 updated WID RP11316=>RP120877 - 51012 2 Name LTE Advanced Carrier Aggregation of Band 4 and Band 12 Core part LTE_CA_B4_B12Core R4. Samsung 3GPP . Ericsson. part LTE_CA_B4_B12Perf R4 07/12/201 2 0% RP120877 RP-120527 Leap Wireless - Supporting Companies: Cox Communications. Cellular South.7 LTE Advanced Carrier Aggregation of Band 4 and Band 12 UID_510022 Resources: UID 51002 2 R4.R2 Acronym LTE_CA_B4_B12 Resource R4. Alcatel-Lucent.

part LTE_CA_B5_B12Perf R4 07/12/201 2 0% RP120221 RP-120529 US Cellular Supporting Companies: US Cellular. Qualcomm.R2 Acronym LTE_CA_B5_B12 Resource R4.1 (2012-06) 11. Nokia. Huawei.132 Overview of 3GPP Release 11 V0. Cox Communication. Cellular South.8 LTE Advanced Carrier Aggregation of Band 5 and Band 12 UID_510023 Resources: UID 51002 3 R4. Alcatel-Lucent.R2 07/09/201 2 75% RP120221 RP-120528 US Cellular 51022 3 Perf.1. Samsung 3GPP .R2 Finish 07/12/201 2 Comp 35% Hyperlink RP120221 Status_Report WI_rapporteur US Cellular Notes Stage 3 (DL/UL 20/10MHz & (DL/UL 20/20MHz) RP#55 updated WID RP110372=>RP120221 - 51012 3 Name LTE Advanced Carrier Aggregation of Band 5 and Band 12 Core part LTE_CA_B5_B12Core R4. Nokia Siemens Networks. Ericsson.

133. 36.133 Overview of 3GPP Release 11 V0.850 36. Nokia Siemens Networks. Telia Sonera. ZTE 3GPP .1.307. Alcatel-Lucent. Nokia.104. Huawei. new generic TR 36. Qualcomm. 36.1 (2012-06) 11. MediaTech. Supporting Companies: Orange. Telefonica.9 LTE Advanced Carrier Aggregation of Band 7 and Band 20 UID_510024 Resources: UID 51002 4 R4 Acronym LTE_CA_B7_B20 Finish 07/12/201 2 Comp 21% Hyperlink RP120889 Status_Report WI_rapporteur Huawei Notes Stage 3. RP#56 updated WID RP110403=>RP120889 - 51012 4 Name LTE Advanced Carrier Aggregation of Band 7 and Band 20 Core part TSs_and_T LTE LTE_CA_B7_B20Core 07/09/201 2 45% RP120889 RP-120530 Huawei 51022 4 Perf.101. Renesas. 36. part LTE_CA_B7_B20Perf 07/12/201 2 0% RP120889 RP-120531 Huawei - 36.

307 Supporting Companies: AT&T. Qualcomm. 36. MediaTek. 36. Samsung 3GPP . 36.134 Overview of 3GPP Release 11 V0.101.104. 36.141. Nokia.1 (2012-06) 11.307. 36. 36.133. Ericsson.104.101. new generic TR 36.10 LTE Advanced Carrier Aggregation Band 2 and Band 17 UID_510025 Resources: UID 51002 5 R4 Acronym LTE_CA_B2_B17 Finish 07/12/201 2 Comp 14% Hyperlink RP110432 Status_Report WI_rapporteur AT&T Notes Stage 3 TSs_and_TRs LTE 51012 5 Name LTE Advanced Carrier Aggregation of Band 2 and Band 17 Core part LTE_CA_B2_B17Core 07/09/201 2 30% RP110432 RP-120532 AT&T - 51022 5 Perf.1. 36. part LTE_CA_B2_B17Perf 07/12/201 2 0% RP110432 RP-120533 AT&T - 36.850 36.133.

MediaTek. part LTE_CA_B4_B5Perf 07/12/201 2 0% RP110433 RP-120535 AT&T - 36.133. 36.11 LTE Advanced Carrier Aggregation Band 4 and Band 5 UID_510026 Resources: UID 51002 6 R4 Acronym LTE_CA_B4_B5 Finish 07/12/201 2 Comp 14% Hyperlink RP110433 Status_Report WI_rapporteur AT&T Notes Stage 3 TSs_and_TRs LTE 51012 6 Name LTE Advanced Carrier Aggregation of Band 4 and Band 5 Core part LTE_CA_B4_B5Core 07/09/201 2 30% RP110433 RP-120534 AT&T - 51022 6 Perf.307.101. 36.1.133.104.307 Supporting Companies: AT&T. Qualcomm. new generic TR 36. 36. Nokia. Ericsson. 36.101.850 36. 36.1 (2012-06) 11.104. 36.135 Overview of 3GPP Release 11 V0.141. 36. Samsung 3GPP .

101. MediaTek. new generic TR 36. • Add the performance requirements for this band combination in the relevant specifications.104.136 Overview of 3GPP Release 11 V0. 15. 36. Qualcomm. and 20 MHz bandwidths in the same WI. Ericsson. 36.133. part LTE_CA_B5_B17Perf 07/12/201 2 0% RP110434 RP-120537 AT&T - 36. Nokia. AT&T proposes this work item to start RAN4 work on inter-band carrier aggregation of bands 5+17. 36. 36.141.104. bands 5+17. 36.307 Supporting Companies: AT&T. This WI is complementary to the generic one (Carrier Aggregation for LTE) where band combination independent tasks are treated. Objective Core: • Specify the band-combination specific RF requirements for the following inter-band CA scenarios: o 5+17 • Finalise the DL and UL with 10. 3GPP .912 TRab.133. 36. Samsung Other justification Clause 11.2 A. 36.1 11. and bands 5+17 as an additional set of bands for LTE-Advanced deployment. • RAN5 Test scenarios should be considered.141.2. 36.1.101. Many aspects of RF performance and inter-mod analysis are bandspecific and require to be evaluated for a real carrier aggregation band combination.12 LTE Advanced Carrier Aggregation Band 5 and Band 17 UID_510027 Resources: UID 51002 7 R4 Acronym LTE_CA_B5_B17 Finish 07/12/201 2 Comp 14% Hyperlink RP110434 Status_Report WI_rapporteur AT&T Notes Stage 3 TSs_and_TRs LTE 51012 7 Name LTE Advanced Carrier Aggregation of Band 5 and Band 17 Core part LTE_CA_B5_B17Core 07/09/201 2 30% RP110434 RP-120536 AT&T - 51022 7 Perf.850 36. a generic inter-band case has been used to carry out the study of the RF requirements for inter-band carrier aggregation.307.cde UE Rel 10 RP-100390 RP-091440 Justification In current RAN4 carrier aggregation work.1 (2012-06) 11. Carrier Aggregation for LTE TS or CR(s) Or external document TR 36.2 Remarks Deployment scenarios Operating bands CA deployment scenarios Decision from RAN#47 on Rel-10 work guidance for carrier aggregation Work Item Description.

Alcatel-Lucent. the UL/DL combinations may have 2 or more DL carriers paired with one UL. Not all these scenarios will be symmetric. MediaTek.101.133.137 Overview of 3GPP Release 11 V0. This band is intended to be used with an existing band combination for a corresponding uplink (as well the corresponding downlink).101.104. • • Add the performance requirements for this new band in the relevant specifications.307 36.307 Supporting Companies: Justification AT&T. Ericsson The Carrier Aggregation work in RAN4 introduces various scenarios to RAN specifications. 36. and given the user requirements for downlink. RAN5 testing aspects will be considered.141. 36. The introduction of this new band as an additional downlink LTE FDD band compliments this scenario.141. Some possible combinations for this band include: a) Band 2 + additional new 716-728 downlink b) Band 4 + additional new 716-728 downlink c) Band 5 + additional new 716-728 downlink Objective Core: • Define the band numbering for this new band. 36. part LTE_DL_FDD700 -Core LTE_DL_FDD700 -Perf 07/09/201 2 07/12/201 2 30% 0% RP110710 RP110435 RP-120719 RP-120569 AT&T AT&T 36. • Define the specific RF requirements for the LTE FDD Downlink of 716-728 MHz with 2x5 and 1x10 MHz scenarios • Specify the band-combination specific RF requirements for the inter-band CA of scenario o Band 2 + additional new 716-728 downlink (Note: Additional band combinations (Band 2. Objective Perf. the emphasis will be on how the spectrum will be deployed. As operators seek to acquire spectrum. this part of the operator scenario will need to be enhanced. Samsung.1.13 New Band LTE Downlink FDD 716-728 MHz UID_510028 Resources: UID 51002 8 R4 Acronym LTE_DL_FDD700 Finish 07/12/201 2 Comp 14% Hyperlink RP110435 Status_Report WI_rapporteur AT&T Notes Stage 3. 36. • Define the specific RF requirements for the LTE FDD Downlink of 716-728 MHz with 2x5 and 1x10 MHz scenarios • Specify the band-combination specific RF requirements for the inter-band CA of scenario 3GPP . Nokia. that is. Band 5) may be considered following this initial requirement scenario). RP#56 Core completed TSs_and_TRs LTE 51012 8 51022 8 Name New Band LTE Downlink FDD 716728 MHz Core part Perf.104. One way to do this is for an operator to acquire spectrum to be used for additional downlink capability when combined with existing spectrum in other defined bands.1 (2012-06) 11. 36. Qualcomm.: • Define the band numbering for this new band. 36. 36.

Band 5) may be considered following this initial requirement scenario). RAN5 testing aspects will be considered.138 Overview of 3GPP Release 11 V0.1. • • Add the performance requirements for this new band in the relevant specifications.1 (2012-06) o Band 2 + additional new 716-728 downlink (Note: Additional band combinations (Band 4. 3GPP .

on different layers should be avoided. Redundant solutions and enhancement methods for the same purposes e. RP# updated WID 111749=>RP 120861. part LTE_CA_enh -Perf R4 15/03/201 3 0% RP120861 RP-120503 Nokia - Supporting Companies: Nokia. NTT DoCoMo.R2.R2. Ericsson.R3. China Mobile. and RAN3 specifications. LGE.139 Overview of 3GPP Release 11 V0. RAN2. Samsung. including i. China Unicom. UL physical layer signaling.R2. AT&T. CATT. Alcatel-Lucent Shanghai Bell. Huawei. ZTE. Research In Motion. Possible improvements in the related signalling for the use of LTE carrier aggregation. Another possible area is to see whether Release 10 CA related L1 or higher layer signaling would benefit from further optimizations.14 LTE Carrier Aggregation Enhancements UID_510030 Resources: UID 51003 0 R1. Objective Core: • Specify the support of the use of multiple timing advances in case of LTE uplink carrier aggregation • Define generic framework for UE and BS core requirements for non-contiguous intra-band carrier aggregation in RAN4 based on the existing RAN1. • Identify details for the LTE Carrier Aggregation enhancements methods to be specified through tradeoff analyses where aspects from all the relevant RAN WGs are considered. Intel. China Telecom Justification The use of carrier aggregation (CA) offers means to increase the peak data rates and throughput by aggregating. Enhancements on the following areas are investigated: a. Mediatek.R4. Lightsquared.1. Alcatel-Lucent. HiSilicon.R3 07/09/201 2 55% RP120861 RP-120502 Nokia Notes Stage 3. as has been discovered during Release 10 LTE CA work. Deutsche Telekom. Motorola Mobility.1 (2012-06) 11. Nokia Siemens Networks. NEC.g.R4 Acronym LTE_CA_enh Resource R1. KDDI. Renesas. ii. Panasonic.R4 Finish 15/03/201 3 Comp 23% Hyperlink RP120861 Status_Report WI_rapporteur Nokia Name LTE Carrier Aggregation Enhancements 51013 0 Core part LTE_CA_enh -Core R1. Release 10 carrier aggregation framework does not support the use of multiple timing advances to cover for such an uplink use case that different uplink bands would require different timing advanced (for example due to the use of repeaters in one of the band or differences in the internal delays of the band specific repeaters). enhanced transmit diversity schemes for PUCCH format 1b with channel selection 3GPP . Texas Instruments. Trigg Rel-11 UID_5 Study on HSD Multipoint Transmission (FS_HSDPA_ - 51023 0 Perf.R3. ST-Ericsson.

L2/L3 protocols d.: Specify UE and eNodeB performance requirements for LTE Carrier Aggregation Enhancements for the scenarios addressed in RAN1. RAN2 and RAN3 specifications and the core part of RAN4 specifications. b.140 Overview of 3GPP Release 11 V0. UE capabilities f. Support of inter-band carrier aggregation for TDD DL and UL including different uplink-downlink configurations on different bands • Identify the impact to specifications that are relevant to the following: a. c. drawbacks Objective Perf. 3GPP .1 (2012-06) b. UE and eNB core requirements Propose a way forward for the additional carrier types study based on careful analyses of benefits.1. UE and eNB core requirements • Introduce the identified functionalities of the selected enhancement methods to the relevant specifications: a. EUTRAN network interfaces g. Physical Layer procedures c. Uplink and downlink control channel structures Downlink physical layer transmission and reception procedures L2/L3 Uu interface protocols d. Mobility procedures e. UL and DL control channel structure b.

RRC state control mechanisms and DRX configurations may be optimised with particular applications in mind but these may not remain optimal as different applications are installed/started/stopped on the device and as the consequent traffic profile of the device changes over time. RP#55 updated WID RP111372=>RP120256 RP#56 new TR 36. DBSD. trade-offs are often encountered between UE power consumption. Samsung. Deutsche Telekom. encompassing smartphones. NEC. Ericsson. HiSilicon. Such diversity in device and application type creates a corresponding diversity in the traffic profiles that must be efficiently supported by the radio access networks on which they run.300.822 Supporting Companies: Research In Motion. Furthermore. Sony Europe. 36. 3GPP .141 Overview of 3GPP Release 11 V0. A study item in TSG SA “non-MTC Mobile Data Applications Impacts” is ongoing and is investigating service scenarios and service enhancements for data applications. Intel.331. Nokia Siemens Networks. LightSquared. MediaTek. Nokia. Current trends indicate that the above issues will only increase in significance over the coming years. user experience. the objective of this work item is to identify and specify mechanisms at the RAN level that enhance the ability of LTE to handle diverse traffic profiles. Under some circumstances this can lead to overly-frequent RRC state transitions and to excessive signalling loads (in the core network as well as the RAN). ZTE Justification The range of device types utilising current mobile networks continues to expand. Some specific issues were identified and discussed in RAN2 as part of TEI-10. Telefonica. laptops. The work item “LTE RAN Enhancements for Diverse Data Applications” addresses RAN-level improvements within the existing RAN architecture and is not dependent upon the outcome of the SA study. data transfer latency. the optimum trade-off point may vary according to application characteristics. ST-Ericsson. network efficiency and control plane signalling overhead. UE battery life. 36. particularly for very large connected mode user populations. Numerous applications require that an always-on mobile-broadband experience is seamlessly delivered and presented to the end user. Furthermore. China Unicom. An alternative is to maintain UEs in the RRC connected mode for long periods of time. China Mobile. and consequently may exhibit traffic profiles not well suited to those connections. TeliaSonera. Renesas. signalling overheads. netbooks. Orange. CHTTL. China Telecom. although this approach may result in higher UE power consumption than that of idle mode and may also place additional demands on system resources and their management. Many are capable of running a wide variety of data applications. IPWireless. Motorola. Telecom Italia. When attempting to provide such always-on connectivity at the RAN level. many applications may be designed without specific consideration of the characteristics of cellular networks. Under such traffic loads. the identified improvements will allow for better trade-offs to be achieved when balancing the needs of network efficiency. tablets and embedded modems. The diversity and unpredictable nature of application traffic profiles leads to challenges in optimising the network and in guaranteeing efficient operation under all use cases. KDDI. creation of a work item would enable a more complete treatment of this topic. AT&T.321. and user experience / system performance.1 (2012-06) 11.822 v100 for Information Name LTE RAN Enhancements for Diverse Data Applications Core part TSs_and_TRs LTE 51013 1 LTE_eDDACore 07/09/201 2 60% RP120256 RP-120504 Research In Motion 36. often in parallel. or their activity or status. Vodafone. Cellular South. Objective Core: In the context of providing improved always-on connectivity. Huawei. new TR 36. NII Holdings.1.15 LTE RAN Enhancements for Diverse Data Applications UID_510031 Resources: UID 51003 1 R2 Acronym LTE_eDDA Finish 07/09/201 2 Comp 60% Hyperlink RP120256 Status_Report WI_rapporteur Research In Motion Notes Stage 2/3. It is imperative therefore that the ability of LTE to efficiently handle and manage such traffic is continually improved. Qualcomm.

142

Overview of 3GPP Release 11 V0.1.1 (2012-06)

Enhancements may be applicable to E-UTRAN, the UE or both, and should encompass both FDD and TDD modes. Proposals shall be evaluated during the initial phase of the work and those demonstrating sufficient benefits shall be captured in E-UTRAN stage 2 and subsequently detailed in the stage 3 specifications. This initial phase includes determination of connected mode configurations that enable UE power consumption comparable to idle mode. Enhancements in the following areas shall be considered: • Enhancements within existing RRC states, to RRC state-control mechanisms and RRM mechanisms that offer system efficiency improvements and/or reduced UE power consumption for devices exhibiting a continued but intermittent data activity Enhancements to DRX configuration/control mechanisms to be more responsive to the needs and activity of either single or multiple applications running in parallel, with improved adaptability to time-varying traffic profiles and to application requirements, thereby allowing for an improved optimisation of the trade-off between performance and UE-battery-consumption. More efficient management of system resources (e.g. UL control channel resources) for connected mode UEs that are temporarily inactive, facilitating potentially larger user populations in connected mode For the above enhancements, knowledge from both the UE and the network should be taken into account where possible

• •

Unnecessary duplication of solutions addressing the same problem area shall be avoided.

3GPP

143

Overview of 3GPP Release 11 V0.1.1 (2012-06)

11.16 LTE E850 - Lower Band for Region 2 (non-US) UID_510032
Resources:
UID 51003 2

R1,R2,R4
Acronym LTE_e850_LB Resource R1,R2,R4,R5 Finish 07/12/201 2 Comp 84% Hyperlink RP120602 Status_Report WI_rapporteur NII Holdings Notes Stage 3. RP#56 Core & Perf completed. Updated WID RP110439=>RP120602 (changed lower edge of band, impacted specs) RP#56 completed

Name LTE E850 Lower Band for Region 2 (nonUS), Band 27

TSs LTE

51013 2

Core part

LTE_e850_LBCore

R1,R2,R4

15/06/201 2

100%

RP120602

RP-120570

NII Holdings

51023 2

Perf. part

LTE_e850_LBPerf

R4

15/06/201 2

100%

RP120602

RP-120571

NII Holdings

RP#56 completed

56001 0

Test part

LTE_e850_LBUEConTest

R5

07/12/201 2

0%

RP120603

-

NII Holdings

-

25.1 25.1 25.4 25.4 36.1 36.1 36.1 36.1 36.3 37.1 25.1 25.1 25.1 36.1 36.1 36.5 36.5 36.5 36.5 36.5 36.5 37.5

Supporting Companies: NII Holdings, TELUS, Sprint, SouthernLINC, Nokia Siemens Networks, Huawei, HiSilicon, Motorola Mobility, Alcatel-Lucent, Ericsson, ST-Ericsson Justification
Other justification TS or CR(s) Or external document TS 36.101 TS 36.104 RP-010278 RP-090666 TR 37.806 Clause 5.1 5.1 Remarks Other frequency bands and channel bandwidths may be considered in future releases. Other frequency bands and channel bandwidths may be considered in future releases. LS from RAN to SA on Operating Frequency Band as a Release independent work item E850 Study Item

There are many operators around the world, primarily in the Americas, using spectrum in the range of 806-824/851-869 MHz (or SMR band) for iDEN technology that would like to have the option of deploying 3GPP technologies. There are a number of 3GPP bands specified in the frequency range of 800 MHz to 900 MHz, but none of them cover the full SMR band. The International iDEN Operators Forum (IiOF) sent a liaison statement to 3GPP in 2009 supporting a new 3GPP band to cover the SMR spectrum. [1] NII Holdings has deployed or is in the process of deploying 3GPP networks in Mexico, Brazil, Chile and Peru. TELUS has deployed a 3GPP network in Canada. The addition of the E850_LB will allow them to provide additional capacity with LTE. In order to facilitate coexistence with neighboring bands, the frequency range for the E850_LB will be 807-824/852869 MHz. References:

3GPP

144

Overview of 3GPP Release 11 V0.1.1 (2012-06)

[3] R4-093902, “Liaison Statement in support of a UMTS/LTE band for 806-824/851-869Mhz (Source: International iDEN Operator's Forum, To: RAN 4, Cc: )”, International iDEN Operator’s Forum Objective • Develop related aspects of adding an FDD band into E-UTRA that covers the frequency range of 807-824/852-869 for Region 2, not including the U.S., incorporating any results into technical report TR 37.806. • Add the necessary changes to the relevant performance requirements to support E850_LB band as identified above. Note that it is not expected to have new demodulation performance requirements. • RAN5 Work Item will follow

Objective Core: • Develop a new FDD band to cover the frequency range of 806-824/851-869 MHz for E-UTRA for Region 2, not including the U.S. The investigations will include RF performance requirements and backward compatibility issues needed to add a new FDD band into the E-UTRA specifications. Add the necessary changes to the relevant core requirements to support the Lower E850 band as identified above for E-UTRA. Add the necessary changes to the relevant performance requirements to support E-UTRA in the Lower 850 MHz band. Note that it is not expected to have new demodulation performance requirements.

Objective Perf.: • Develop performance related aspects of adding a new FDD band into E-UTRA that covers the frequency range of 806-824/851-869 MHz for Region 2, not including the U.S., incorporating any results into technical report TR 37.806. Add the necessary changes to the relevant performance requirements to support E850 lower band as identified above. Note that it is not expected to have new demodulation performance requirements.

3GPP

145

Overview of 3GPP Release 11 V0.1.1 (2012-06)

11.17 Carrier based HetNet ICIC for LTE UID_510033
Resources:
UID 51003 3

R3,R1,R2
Acronym LTE_CA_HetNet_ICIC Finish 07/09/201 2 Comp 40% Hyperlink RP111111 Status_Report WI_rapporteur Nokia Siemens Networks Notes Stage 2/3

51013 3

Name Carrie r based HetNet ICIC for LTE Core part

TSs_and_TR LTE

LTE_CA_HetNet_ICIC -Core

07/09/201 2

40%

RP111111

RP-120505

Nokia Siemens Networks

RP#56 completion 06/12=>09/1 2

36.300, 36.413, 36.420, 36.4

Supporting Companies: Nokia Siemens Networks, Nokia, Motorola, Ericsson, ST-Ericsson, Texas Instruments, KDDI, Alcatel-Lucent, LG Electronics, Intel Justification LTE Rel-8 and Rel-10 inter-cell interference coordination (ICIC) solutions are developed for intra-carrier (co-channel) cases. The Rel-8 ICIC solutions were mainly developed for macro-only scenarios, while the Rel-10 ICIC mechanisms were developed to address interference between macro and HeNB, as well as between macro and pico. Further development of autonomous interference management mechanisms for optimally exploiting available frequency assets (carriers in same or different bands) in HetNet environments with mixture of different BTS types and without tight synchronization requirements therefore seems like the next natural step. Interference management on carrier resolution can be used for protection of both control and data channels, and also for interference management between small BTS types such as Picos or HeNBs. Combining such techniques with the carrier aggregation mechanisms available in Rel-10 could offer further optimizations. Objective Core: • • • Evaluate the performance benefits of having interference management on carrier resolution between different BTS nodes in the defined HetNet environments (3GPP TR 36.814). (RAN1 based on RAN3 requests) Study inter-node signalling needed for robust autonomous solutions, where each BTS node selects to use the carrrier(s) that maximize the overall network performance (RAN3). Focus on solutions with no physical layer impact that would work for both legacy Rel-8/9 UEs, as well as benefit from optimizations available for Rel-10/11 UEs supporting carrier aggregation. Thus the solutions shall rely on existing UE features in different Releases. Realistic assumptions for availability of UE measurements and power consumption to be used. Focus on solutions which do not requiring tight synchronization between eNodeBs

3GPP

146

Overview of 3GPP Release 11 V0.1.1 (2012-06)

11.18 LTE Advanced Carrier Aggregation in Band 38 UID_520015
Resources:
UID 52001 5

R4
Acronym LTE_CA_B38 Finish 07/12/201 2 Comp 85% Hyperlink RP110862 Status_Report WI_rapporteur Huawei Notes Stage 3 TSs_and_TRs LTE

52011 5

Name LTE Advanced Carrier Aggregation in Band 38 Core part

LTE_CA_B38Core

07/09/201 2

90%

RP110862

RP-120560

Huawei

-

52021 5

Perf. part

LTE_CA_B38Perf

07/12/201 2

80%

RP110862

RP-120561

Huawei

-

36.101, 36.104, 36.133, 36.141, 36.307, 37.104, 37.141, new TR 36.830 36.101, 36.104, 36.133, 36.141, 36.307, 37.104, 37.141

Supporting Companies: Justification

CMCC, Huawei, HiSilicon, CATT, ZTE, TD Tech, Qualcomm, Clearwire, MediaTek

Band 38 is a major global TDD band which had been allocated for TDD in European countries, China and other countries. Operators have big interest to support carrier aggregation in this band. China had allotted 50MHz spectrum from 2570-2620MHz for TDD with guard band in 2010. The frequency arrangement of other parts of 2.6GHz is yet to be decided. The maximum bandwidth operators can utilize depends on co-existence requirements in the future. In Europe, operator can not use the whole 50MHz spectrum according to the regulation rules. 40MHz carrier aggregation would be a good choice.

-

The study should follow the final emissions requirements for Band 38 defined in TS36.101. The generic work done for intra-band CA for Band 40 can be largely leverage for Band 38. Objective Core The objectives of the WI include:  Specify core requirements for contiguous carrier aggregation in Band 38.   BS: 40MHz CA Determine the appropriate deployment scenario and specify the corresponding RF requirements for up to 40MHz. UE: 40MHz CA Considering the cost and complexity, it is proposed to maintain the same capability requirements for UE as that in other intra-band CA work items, e.g. up to two contiguous 20MHz component carriers for CA. Appropriate A-MPR value may be defined to support CA bandwidth larger than 20MHz for protection of adjacent Band 7 operations.

 Specify band specific RRM requirements in RAN4.  Add signalling support in RAN2 specifications.

3GPP

37. 36.1 (2012-06) 11. Stage 3 linked to Rel10 Carrier Aggregation for LTE UID_460007 RP#55 completed. Many network equipment vendors are supporting. Huawei.147 Overview of 3GPP Release 11 V0.101. 3GPP . 40MHz at the UE with a maximum of 2 CCs on the DL and 1 or 2 CCs on the UL Specify band specific RRM requirements Study specific signalling support requirements in RAN2 b. with often large contiguous (40MHz+) blocks of channels available.19 LTE Advanced Carrier Aggregation in Band 41 UID_520016 Resources: UID 52001 6 R4 Acronym LTE_CA_B41 Finish 02/03/201 2 Hyperlink RP120249 Status_Report WI_rapporteur Clearwire Notes RP#55 completed. up to 194MHz is available for deployment of Band 41 based LTE TDD. 36.104.101. ii. 36. Band 41 is a prime candidate for deployment of Release 10 based LTE-advanced carrier aggregation capable UEs. 36.104.307 Supporting Companies: Justification Clearwire.827 52021 6 Perf. CMCC.104. This work item proposes that RAN4 start work on contiguous.812 v10. CATR. intra-band carrier aggregation for Band 41 to support deployment of LTE-advanced. dual carrier.133. 60MHz at the eNB. 36.0. specifically considering aggregation of appropriate channel bandwidths up to: i.133. Due to the spectrum and network equipment availability.141. specify the core RF requirements for contiguous intra-band CA in Band 41. ZTE In the US.827 v100 for Information + Approval RP#55 completed TSs_and_TRs LTE Name LTE Advanced Carrier Aggregation in Band 41 52011 6 Core part LTE_CA_B41Core 02/03/201 2 RP120249 RP-120126 Clearwire 36. 2x 20MHz TDD radios in the near future for the 2600MHz band. “Evolved Universal Terrestrial Radio Access (E-UTRA). 36.141. 36. or planning to support. Updated WID RP110673=>RP120249.1. CATT. Building on the LTE intra-band CA work completed for Band 40. 36. part LTE_CA_B41Perf 02/03/201 2 RP120249 RP-120127 Clearwire 36. new TR 36.307. TR 36. NII Holdings. [1] TR36. c. LTE TDD 2600MHz in US work item Technical Report” Objective Core a. building on the initial generic LTE TDD CA work that is developing the framework for TDD intra-band carrier aggregation based on Band 40.1.

Downlink 758-803 MHz. HiSilicon.148 Overview of 3GPP Release 11 V0. i. KT Corporation. Vodafone.1 (2012-06) 11.20 LTE for 700 MHz Digital Dividend UID_520017 Resources: UID 52001 7 R4 Acronym LTE_APAC700 Resource R4. At the ninth meeting of the APT Wireless Forum (AWF-9). .1. Ltd. [APT/AWF/REP-14] The agreed FDD arrangement is: Uplink: 703-748 MHz. ZTE Justification The switch off of analogue television (Digital Dividend) will make available for IMT services a portion of the UHF spectrum in Region 3.. part Test part LTE_APAC700Perf LTE_APAC700UEConTest R4 R5 15/06/201 2 01/03/201 3 100% 0% RP110875 RP120600 RP-120573 - Ericsson Ericsson RP#56 completed - Supporting Companies: Alcatel-Lucent. Stage 3 . The AWF-9 meeting also invited further studies to determine UE out-of-band emission limits and implementation issues relating to the usage of the band 698-806 MHz by the Mobile Service. Asian Pacific American Caucus (APAC) AsiaPacific Telecommunit y (APT) Wireless Forum RP#56 completed. ST-Ericsson. Nokia Siemens Networks. Korea from September 13th to 16th 2010. Nokia. LG-Ericsson Co. KDDI. ETRI. 2x45 MHz.e.R3. network operators and manufacturers of equipment. Qualcomm. i. 3GPP . CATT. agreement was reached on two harmonized frequency arrangements for IMT in the 698-806 MHz frequency band in Region 3.R2. user devices and electronic components. However APT notes that “a minimum internal guardband of 5 MHz at the lower edge (698 MHz) and 3 MHz at the upper edge (806 MHz) needs to be considered”.R2.R3 15/06/201 2 100% RP110875 RP-120572 Ericsson 52021 7 56001 1 Perf.e.820 v100 for Information and Approval Name LTE for 700 MHz Digital Dividend 52011 7 Core part LTE_APAC700Core R4. Ericsson.. which will consequently allow more deployments using the APT-agreed arrangements in various countries. Huawei. Note that studies on implementation issues for countries which cannot make the whole band 698-806MHz available and therefore cannot apply the APT-agreed arrangements but will use some part of the frequency arrangement should be conducted in order to suit their national considerations. The agreed TDD arrangement is: 698-806 MHz. In other regions the switch to digital television will also create a digital dividend that may be used for IMT services. Samsung. 1x108 MHz. The APT Wireless Group (AWG) is continuing these studies and plans to finalize them in the 11th meeting of AWG in October 2011. This agreement is the result of extensive studies undertaken by Region 3 administrations. Motorola Mobility. NII Holdings. Telefónica. following the decisions taken WRC-07.R5 Finish 01/03/201 3 Comp 74% Hyperlink RP110875 Status_Report WI_rapporteur Ericsson Notes RP#56 Core & Perf completed. EMOBILE. NTT DOCOMO. LG Electronics Inc. China Mobile. TR 36. held in Seoul.

1. Generate CRs to update the appropriate documents • • 3GPP . Both TDD and FDD should be considered. Develop technical requirements for deployment of LTE in the band 698-806 MHz. considering the on-going work in the AWG. Develop channel arrangements for LTE in the band 698-806 MHz in line with the APT decision for region 3 and the study above. considering implementation issues for countries which cannot make the whole band 698-806MHz available and therefore cannot apply the APT-agreed arrangements but will use some part of the channel arrangement. coexistence requirements with service in adjacent frequency bands. Both TDD and FDD should be considered. Both TDD and FDD should be considered. Consider possible deployment in region 2 outside of US.149 Overview of 3GPP Release 11 V0.1 (2012-06) Objective • • • Study the technical requirements for deploying LTE in the band 698-806 MHz in region 3.g. e.

Verizon Wireless.826) 52021 9 Perf. Ericsson. AT&T. CMCC. LG Electronics . including the following remaining open issues: • o o o o • o o o outcome) o o Transmitter requirements for access and backhaul: Output power and output power dynamics Quality requirements (except frequency accuracy) Unwanted emission requirements (depends on co-ex study outcome) Intermodulation requirements Receiver requirements for access and backhaul Reference sensitivity (backhaul only) Dynamic range In-channel selectivity. 36. RAN4 core and performance requirements need to be specified. ST-Ericsson. Nokia Siemens Networks.150 Overview of 3GPP Release 11 V0. eMobile. Qualcomm. RP#52 Core part not completed in Rel-10 RP#56 completion 06/12=>09/12 .133. SFR. RP#52 transferred completely from Rel-10 UID_460213 TSs_and_TRs LTE 52011 9 Name Relay s for LTE (part 2) Core part LTE_Relay2Core 07/09/201 2 85% RP110914 RP-120506 Ericsson 36.133. In order to have a full specification support for relays. Objective Core The objective of the work is to specify RF core requirements for Relays.21 Relays for LTE (part 2) UID_520019 Resources: UID 52001 9 R4 Acronym LTE_Relay2 Finish 07/09/201 2 Comp 82% Hyperlink RP110914 Status_Report WI_rapporteur Ericsson Notes Continuation of Rel-10 (open RAN4 Core & Perf parts) RP#56 completion 06/12=>09/12 . Telefónica. Orange. ZTE Justification Support for relays has been specified in RAN1. part LTE_Relay2Perf 07/09/201 2 80% RP110914 RP-120507 Ericsson 36.1. Nokia. new RAN4 (36. Samsung.117 (EUTRA Relay conformance testing) Supporting Companies: Vodafone.1 (2012-06) 11. RAN2 and RAN3 in Rel-10.116. adjacent channel selectivity and blocking requirements (depends on co-ex study Receiver spurious emissions Receiver intermodulation requirements 3GPP . new TS 36.

104. 36. 36. 36.101.141.850 36. part LTE_CA_B8_B20Perf 07/12/201 2 0% RP120888 RP-120547 Vodafone - 36.850 36. 36. 11. 3GPP . 36. 36. part LTE_CA_B3_B20Perf 07/12/201 2 10% RP120887 RP-120545 Vodafone - 36.104. 36.101. new generic TR 36. 36.133.1.101.307. 36. 36. 36. new generic TR 36.307. RP#56 updated WID RP111213=>RP120888 - 53012 4 Name LTE Advanced Carrier Aggregation of Band 8 and Band 20 Core part TSs_and_T LTE LTE_CA_B8_B20Core 07/09/201 2 10% RP120888 RP-120546 Vodafone 53022 4 Perf.104.23 LTE Advanced Carrier Aggregation of Band 8 and Band 20 UID_530024 Resources: UID 53002 4 R4 Acronym LTE_CA_B8_B20 Finish 07/12/201 2 Comp 4% Hyperlink RP120888 Status_Report WI_rapporteur Vodafone Notes Stage 3.133.101.151 Overview of 3GPP Release 11 V0. 36.22 LTE Advanced Carrier Aggregation of Band 3 and Band 20 UID_530023 Resources: UID 53002 3 R4 Acronym LTE_CA_B3_B20 Finish 07/12/201 2 Comp 28% Hyperlink RP120887 Status_Report WI_rapporteur Vodafone Notes Stage 3. RP#56 updated WID RP120269=>RP120887 - 53012 3 Name LTE Advanced Carrier Aggregation of Band 3 and Band 20 Core part TSs_and_T LTE LTE_CA_B3_B20Core 07/09/201 2 50% RP120887 RP-120544 Vodafone 53022 3 Perf.133.104.1 (2012-06) 11.

37.1 3GPP . new generic TR 36.101. 36.307. 36.850 36.307. 36.133. new generic TR 36.24 LTE Advanced Carrier Aggregation of Band 1 and Band 7 UID_530025 Resources: UID 53002 5 R4 Acronym LTE_CA_B1_B7 Finish 07/12/201 2 Comp 20% Hyperlink RP120904 Status_Report WI_rapporteur China Telecom Notes Stage 3. 36. part LTE_CA_B1_B7Perf 07/12/201 2 0% RP120904 RP-120539 China Telecom - 36. 36.113.152 Overview of 3GPP Release 11 V0.124.1 11.850 36.1 (2012-06) 11.141. 36.307.101. 36. RP#56 updated WID RP111357=>RP120904 - 53012 5 Name LTE Advanced Carrier Aggregation of Band 1 and Band 7 Core part TSs_and_TR LTE LTE_CA_B1_B7Core 07/09/201 2 45% RP120904 RP-120538 China Telecom 53022 5 Perf. RP#56 updated WID RP111603=>RP120899 - 53012 6 Name LTE Advanced Carrier Aggregation of Band 3 and Band 5 Core part TSs_and_TR LTE LTE_CA_B3_B5Core 07/09/201 2 80% RP120899 RP-120540 SK Telecom 53022 6 Perf.133. 37.1.133. part LTE_CA_B3_B5Perf 07/12/201 2 0% RP120899 RP-120541 SK Telecom - 36. 36.104. 36. 36. 36.104. 36.104.104.101.25 LTE Advanced Carrier Aggregation of Band 3 and Band 5 UID_530026 Resources: UID 53002 6 R4 Acronym LTE_CA_B3_B5 Finish 07/12/201 2 Comp 35% Hyperlink RP120899 Status_Report WI_rapporteur SK Telecom Notes Stage 3.

101.133.104. 36. 37. part LTE_CA_B4_B7Perf 07/12/201 2 0% RP120896 RP-120543 Rogers Wireless - 36. 36.1 (2012-06) 11.153 Overview of 3GPP Release 11 V0.141.104. 36.307.133.133.850 36.104.141 3GPP . 37.101. 36. 37.133. 36.141.26 LTE Advanced Carrier Aggregation of Band 4 and Band 7 UID_530027 Resources: UID 53002 7 R4 Acronym LTE_CA_B4_B7 Finish 07/12/201 2 Comp 11% Hyperlink RP120896 Status_Report WI_rapporteur Rogers Wireless Notes Stage 3.141.101.1.104.101. 36. 37. 36. part LTE_CA_B7Perf 07/12/201 2 70% RP111356 RP-120563 China Unicom - 36.831 36.307. 36.104.141.27 LTE Advanced Carrier Aggregation in Band 7 UID_530028 Resources: UID 53002 8 R4 Acronym LTE_CA_B7 Finish 07/12/201 2 Comp 70% Hyperlink RP111356 Status_Report WI_rapporteur China Unicom Notes Stage 3 TSs_and_TRs LTE 53012 8 Name LTE Advanced Carrier Aggregation in Band 7 Core part LTE_CA_B7Core 07/09/201 2 70% RP111356 RP-120562 China Unicom - 53022 8 Perf. RP#56 updated WID RP111358=>RP120896 - 53012 7 Name LTE Advanced Carrier Aggregation of Band 4 and Band 7 Core part TSs_and_TR LTE LTE_CA_B4_B7Core 07/09/201 2 25% RP120896 RP-120542 Rogers Wireless 53022 7 Perf. new TR 36.104. 36. 36. 36. 36.307.3 11. 37. new generic TR 36. 36. 36.141.104. 36. 36.

101. 36. NonContiguous in Band 25 Core part TSs_and_ 53012 9 LTE_CA_NC_B25Core 14/06/201 3 5% RP120366 RP-120142 Sprint 53022 9 Perf. 36.104. NonContiguous in Band 25 UID_530029 (moved to Rel-12) Resources: UID 53002 9 R4 Acronym LTE_CA_NC_B25 Finish 14/06/201 3 Comp 5% Hyperlink RP120366 Status_Report WI_rapporteur Sprint Notes Stage 3.154 Overview of 3GPP Release 11 V0. part LTE_CA_NC_B25Perf 14/06/201 3 5% RP120366 RP-120143 Sprint 36.104.28 Signalling and Procedure for Interference Avoidance for in-device coexistence UID_530031 Resources: UID 53003 1 R2. 36 11. 36.R4 07/09/201 2 07/09/201 2 60% RP111355 RP111356 RP-120508 China Mobile Perf. part R4 60% RP-120800 China Mobile RP#56 completion 06/12=>09/1 2 RP#56 completion 06/12=>09/1 2 3 3 3 3 3 3GPP .y LTE Advanced Carrier Aggregation Intra-Band.141. 36.R4 Acronym SPIA_IDC_LTE Resource R2.841 36.141.101.3 53013 1 53023 1 Name Signalling and Procedure for Interferenc e Avoidance for indevice coexistenc e Core part T L SPIA_IDC_LTECore SPIA_IDC_LTEPerf R2. RP#55 updated WID RP111371=>RP120366 RP#55 updated WID RP111371=>RP120366 RP#55 updated WID RP111371=>RP120366 LTE Name LTE Advanced Carrier Aggregation Intra-Band.307.1 (2012-06) 11. 36.133. 36.R4 Finish 07/09/201 2 Comp 60% Hyperlink RP111355 Status_Report WI_rapporteur China Mobile Notes Stage 2. ne TR 36.133.1. 36.

819 Study Coordinated Multi-Point Operation for LTE (FS_CoMP_L - 53023 2 53033 2 Perf.155 Overview of 3GPP Release 11 V0.R2.R3. part – Uplink Core part – Downlink COMP_LTE_ULPerf COMP_LTE_DLCore R4 R1.R4 07/12/201 2 07/09/201 2 0% 70% RP111365 RP111365 RP-120511 RP-120512 Huawei Samsung - 53043 2 Perf. Triggered by Rel-11 TR 36.R2.29 Coordinated Multi-Point Operation for LTE UID_530032 Resources: UID 53003 2 R1. part – Downlink COMP_LTE_DLPerf R4 07/12/201 2 0% RP111365 RP-120513 Samsung - 3GPP .R2.R3.R4 Finish 07/12/201 2 Comp 31% Hyperlink RP111365 Status_Report WI_rapporteur Samsung.R4 07/09/201 2 70% RP111365 RP-120510 Huawei Notes Stage 3.1 (2012-06) 11.R2.R4 Acronym COMP_LTE Resource R1.1.R3.R3. Huawei Name Coordinated Multi-Point Operation for LTE 53013 2 Core part – Uplink COMP_LTE_ULCore R1.

with signalling modification are evaluated as feasible. For inter-eNB energy saving use case 1. Telefónica. possible enhancements. and further specification work is needed for implementing the solutions. Unnecessary duplication of solutions addressing the same problem area shall be avoided. applicable and backwards compatible for improving energy efficiency.156 Overview of 3GPP Release 11 V0. The improvements have been evaluated feasible. Inter-RAT aspect can affect UTRA and GERAN as well Name Network Energy Saving for EUTRAN Core part TSs_and_TRs LTE 53013 6 Netw_Energy_LTE -Core 07/09/201 2 95% RP120620 RP-120514 China Mobile 25. 36. 3GPP . Alcatel-Lucent. define O&M requirements for radio-related functions to be performed in the O&M domain. applicable and backward compatible. Telecom Italia. Rel-9 inter-eNB energy saving solutions can be reused for improving energy efficiency.g. Objectives for use cases: • Inter-RAT: specify the signalling based solution and possible enhancements • Inter-eNB overlapping : specify possible enhancements on top of the Rel-9 solution • If needed. how to exit dormant mode efficiently. CATT. besides this. applicable and backwards compatible for improving energy efficiency when there are no LTE-only capable devices. may be needed. which mainly focus on a single cell operating in energy saving mode when the resource utilization is sufficiently low.927. There is a strong need to investigate possible network energy saving mechanisms to reduce CO2 emission and OPEX of operators.3. NEC. and initial evaluations have been addressed.413. Fujitsu Justification The power efficiency in the infrastructure and terminal is an essential part of the cost-related requirements in LTE-A. RP#56 updated WID RP111376=>RP120620 RP#56 completion 06/12=>09/12 . some solutions with signalling modifications and some hybrid based solutions with both O&M and signalling modifications have been evaluated as feasible. Following use cases have been considered in the study item and the study results have been captured in TR 36. 36.30 Network Energy Saving for E-UTRAN UID_530036 Resources: UID 53003 6 R3 Acronym Netw_Energy_LTE Finish 07/09/201 2 Comp 95% Hyperlink RP120620 Status_Report WI_rapporteur China Mobile Notes Stage 2.e. how to exit dormant mode efficiently.423 Supporting Companies: Chine Mobile. solutions and possible enhancements. e. GERAN and UTRAN) providing radio coverage together with E-UTRAN providing capacity enhancements. KPN.413. are implementation based and could be supported by current specification. Deutsche Telekom. where cells are overlapping with each other. Nokia Siemens Networks. which mainly focuses on legacy networks (i. where no cell are overlapping with each other. Huawei. For inter-RAT energy saving. Solutions and enhancements to various energy saving use cases have been studied already in Rel-10. CHTTL.g. Further specification work is needed for implementing these solutions and enhancements. Mitsubishi Electric.1. • • • Intra-eNB energy saving Inter-eNB energy saving Inter-RAT energy saving Those solutions to intra-eNB energy saving use case. For inter-eNB energy saving use case 2.300. Orange. 36. ZTE. e.1 (2012-06) 11.

R2 Finish 07/12/201 2 Comp 19% Hyperlink RP120898 Status_Report WI_rapporteur KDDI 54012 0 Name LTE Advanced Carrier Aggregation of Band 11 and Band 18 Core part Notes Stage 3. part LTE_CA_B1_B18Perf R4 07/12/201 2 0% RP120892 RP-120551 KDDI - 3GPP . RP#56 updated WID RP111634=>RP120898 - LTE_CA_B11_B18Core R4.31 LTE Advanced Carrier Aggregation of Band 11 and Band 18 UID_540020 Resources: UID 54002 0 R4. part LTE_CA_B11_B18Perf R4 07/12/201 2 0% RP120898 RP-120549 KDDI - 11.1 (2012-06) 11.R2 Finish 07/12/201 2 Comp 19% Hyperlink RP120892 Status_Report WI_rapporteur KDDI Notes Stage 3.R2 07/09/201 2 45% RP120898 RP-120548 KDDI 54022 0 Perf.R2 Acronym LTE_CA_B1_B18 Resource R4. RP#56 updated WID RP111635=>RP120892 - 54012 1 Name LTE Advanced Carrier Aggregation of Band 1 and Band 18 Core part LTE_CA_B1_B18Core R4.R2 07/09/201 2 45% RP120892 RP-120550 KDDI 54022 1 Perf.R2 Acronym LTE_CA_B11_B18 Resource R4.32 LTE Advanced Carrier Aggregation of Band 1 and Band 18 UID_540021 Resources: UID 54002 1 R4.1.157 Overview of 3GPP Release 11 V0.

R2 Finish 07/12/201 2 Comp 34% Hyperlink RP111764 Status_Report WI_rapporteur NTT DoCoMo Notes Stage 3 54012 3 Name LTE Advanced Carrier Aggregation of Band 1 and Band 21 Core part TSs_a LTE LTE_CA_B1_B21Core R4. part LTE_CA_B1_B21Perf R4 07/12/201 2 0% RP111764 RP-120555 NTT DoCoMo - 36.1.33 LTE Advanced Carrier Aggregation of Band 1 and Band 19 UID_540022 Resources: UID 54002 2 R4.R2 Acronym LTE_CA_B1_B19 Resource R4. 36. 36.158 Overview of 3GPP Release 11 V0.10 36.133. 11.850 36.104.13 3GPP .R2 Acronym LTE_CA_B1_B21 Resource R4. generic 36.13 36.101.R2 07/09/201 2 80% RP111764 RP-120554 NTT DoCoMo - 54022 3 Perf. RP#56 completed.30 gener 36.34 LTE Advanced Carrier Aggregation of Band 1 and Band 21 UID_540023 Resources: UID 54002 3 R4.133. part LTE_CA_B1_B19Perf R4 15/06/201 2 RP120866 RP-120553 NTT DoCoMo RP#56 completed 36.R2 15/06/201 2 RP120866 RP-120552 NTT DoCoMo 54022 2 Perf.307.1 (2012-06) 11.85 36.10 36. 36. Updated WID RP111765=>RP120866 RP#56 completed 54012 2 Name LTE Advanced Carrier Aggregation of Band 1 and Band 19 Core part TSs_an LTE LTE_CA_B1_B19Core R4.R2 Finish 15/06/201 2 Hyperlink RP120866 Status_Report WI_rapporteur NTT DoCoMo Notes Stage 3.

new TR 36.R2. 36. part LTE_CA_B3_B5_2ULPerf 14/06/201 3 0% RP120364 SK Telecom - 36.35 Enhanced downlink control channel(s) for LTE Advanced UID_540025 Resources: UID 54002 5 R1.R4 07/09/201 2 15/03/201 3 48% RP120871 RP120871 RP-120515 Alcatel-Lucent Notes Stage 3. part R4 0% RP-120516 Alcatel-Lucent - 11.R2.307 3GPP .101.1 (2012-06) 11. Triggered UID_510037 Rel-1 36.159 Overview of 3GPP Release 11 V0. 36.133. 36. 36.1.8ab 36. RP#56 up WID RP-111776=> 120871.141.101. Exists already for 1UL a WI LTE_CA_B3_B5 TSs_and_TRs LTE Name LTE Advanced Carrier Aggregation of Band 3 and Band 5 with 2UL Core part 55011 0 LTE_CA_B3_B5_2ULCore 15/03/201 3 0% RP120364 SK Telecom - 55021 0 Perf. 36.R2.133. 36.R4 Acronym LTE_enh_dl_ctrl Resource R1. 36.104.a LTE Advanced Carrier Aggregation of Band 3 and Band 5 with 2UL UID_550010 (moved to Rel-12) Resources: UID 55001 0 R4 Acronym LTE_CA_B3_B5_2UL Finish 14/06/201 3 Comp 0% Hyperlink RP120364 WI_rapporteur SK Telecom Notes Stage 3.104.R4 Finish 15/03/201 3 Comp 18% Hyperlink RP120871 Status_Report WI_rapporteur Alcatel-Lucent Name Enhanced downlink control channel(s) for LTE Advanced 54012 5 54022 5 Core part LTE_enh_dl_ctrlCore LTE_enh_dl_ctrlPerf R1.307.871 Study on fu Downlink MIMO enhancements for Advanced (FS_LTE_eDL_MIM - Perf.

b Intra-band.141.160 Overview of 3GPP Release 11 V0. 36.307. part 550111 550211 LTE_CA_NC_B3Core LTE_CA_NC_B3Perf 15/03/2013 14/06/2013 0% 0% RP120383 RP120383 SK Telecom SK Telecom - 36. part LTE_Interf_RejPerf 07/12/201 2 30% RP120382 RP-120519 Renesas Mobile 36. 36. Noncontiguous CA for Band 3 for LTE Advanced Core part Perf. 36.101. Adds Perf.8ab 36. 3GPP .307 11. 36.36 Public Safety Broadband High Power UE for Band 14 for Region 2 UID_550012 Resources: UID 55001 2 R4 Acronym LTE_B14_PSBB_HPUE Finish 07/12/201 2 Comp 25% Hyperlink RP120362 Status_Report WI_rapporteur Motorola Solutions Notes Stage 3 55011 2 Name Public Safety Broadband High Power UE for Band 14 for Region 2 Core part TSs_and_TRs LTE LTE_B14_PSBB_HPUECore 07/12/201 2 25% RP120362 RP-120518 Motorola Solutions - 36.104. new TR 36.133. Non-contiguous CA for Band 3 for LTE Advanced UID_550011 (moved to Rel-12) Resources: UID 550011 R4 Acronym LTE_CA_NC_B3 Finish 14/06/2013 Comp 0% Hyperlink RP120383 WI_rapporteur SK Telecom Notes Stage 3 TSs_and_TRs LTE Name Intra-band.101. 36.104.101.1.133.1 (2012-06) 11. 36.837 11. requirements for demodulation of the already specified PDSCH with the transmission modes defined in Rel-8 to Rel10 - Name Improved Minimum Performance Requirement s for E-UTRA: Interference Rejection TS LT 55011 3 Perf. 36.37 Improved Minimum Performance Requirements for EUTRA: Interference Rejection UID_550013 Resources: UID 55001 3 R4 Acronym LTE_Interf_Rej Finish 07/12/201 2 Comp 30% Hyperlink RP120382 Status_Report WI_rapporteur Renesas Mobile Notes Triggered by FS_enh_perf_UE_LTE. new TR 36.

R3 Finish 15/03/201 3 Comp 5% Hyperlink RP120360 Status_Report WI_rapporteur LightSquared TSs_and_TRs LTE 55011 7 Name LTE in the 16701675 MHz Band for US Core part LTE_FDD_1670_USCore R4.1.466.113. 36.101.1 (2012-06) 11.8xy (LTE in 16701675 MHz Band for US) 25.R3 Acronym LTE_TDD_add_subframe Finish 07/09/201 2 Comp 95% Hyperlink RP120384 Status_Report WI_rapporteur China Mobile Notes Stage 3. new TR 36.141. part LTE_FDD_1670_USPerf R4 15/03/201 3 5% RP120360 RP-120575 LightSquared 25.113. 36. 25.101. 36.306.161 Overview of 3GPP Release 11 V0. 36. 25.306. 25.113.133. 25. 36. Exists already for 1UL a WI LTE_CA_B3_B5 RP#56 completion 06/12=>09/12 55011 4 Name Additional special subframe configuration for LTE TDD Core part LTE_TDD_add_subframe -Core 07/09/201 2 95% RP120384 RP-120517 China Mobile 11. 25. 34. 25.124.38 Additional special subframe configuration for LTE TDD UID_550014 Resources: UID 55001 4 R4. 25.R2.307. 36.133.133. 34.104.R3 Acronym LTE_FDD_1670_US Resource R4. 36.307. 25. 25.R2. 25.124.104.R3 07/12/201 2 5% RP120360 RP-120574 LightSquared 55021 7 Perf. 36.466.461.124.331.124.133. 25. 25.307.R2. 25.39 LTE in the 1670-1675 MHz Band for US UID_550017 Resources: UID 55001 7 R4.R2.331. 36.461. 36. 36.307 3GPP .

133.133. new TR 36.101. 36.1 (2012-06) 11.307. 36.141 3GPP . 36.1.x LTE Advanced Carrier Aggregation of Band 3 and Band 8 UID_550018 (moved to Rel-12) Resources: UID 550018 R4 Acronym LTE_CA_B3_B8 Finish 14/06/201 3 Comp 0% Hyperlink RP120388 WI_rapporteur KT Notes Stage 3 TSs_and_TRs LTE Name LTE Advanced Carrier Aggregation of Band 3 and Band 8 Core part Perf. 36.104.162 Overview of 3GPP Release 11 V0.8xy 36. part 550118 550218 LTE_CA_B3_B8Core LTE_CA_B3_B8Perf 15/03/201 3 14/06/201 3 0% 0% RP120388 RP120388 KT KT - 36.

R4.163 Overview of 3GPP Release 11 V0.R2 WI_rapporteur CATR Ericsson China Mobile Huawei Telus Communications Ericsson Qualcomm Nokia Siemens Networks Ericsson Nokia Siemens Networks Ericsson 3GPP .R3.R2.Laptop mounted equipment Free Space test Eight carrier HSDPA UE demodulation performance requirements under multiple-cell scenario for 1.R3.R2.R3.R3.R2 R4.R2.R4 R2.R5 R1.R3 R4.R4 R1.R5 R1.R2.R2.R4 R1.1 (2012-06) 12 UID 45001 6 50001 9 50002 1 50002 2 51001 8 51001 9 51002 0 53003 4 53003 5 54000 9 54002 4 UTRA Features Name UE Over The Air (Antenna) conformance testing methodology .R3 R1.R3.R4 R4.R2.R1.R4 R4.28Mcps TDD Uplink Transmit Diversity for HSPA Introduction of New Configuration for 4C-HSDPA Non-contiguous 4C-HSDPA operation Further Enhancements to CELL_FACH HSDPA Multiflow Data Transmission Four Branch MIMO transmission for HSDPA MIMO with 64QAM for HSUPA HSDPA Dual-Band Multi-Carrier combinations Acronym UEAnt_FSTest 8C_HSDPA LCR_TDD_UE_demod_mc HSPA_UL_TxDiv 4C_HSDPA_Config NC_4C_HSDPA Cell_FACH_enh HSDPA_MFTX 4Tx_HSDPA MIMO_64QAM_HSUPA HSDPA_DB_MC Resource R4.1.

R5 Acronym UEAnt_FSTest Resource R4.144.914 and 34.914 to cover the test requirement and test method of the laptop mounted UEs.914 and 34. Samsung. But as the laptop mounted UEs are never used against the head.114 has also been completed for MS and FDD UE. Orange RAN4 has completed TR 25.Laptop mounted equipment free space test UID_450016 Resources: UID 45001 6 R4. Huawei.144 as a feature extension and applicable for both FDD and TDD laptop mounted UEs. CATT.164 Overview of 3GPP Release 11 V0. China Mobile. It is necessary to develop the test method to control the antenna performance of these products.1 UE over the air conf. Objective: to extend the scope of TS34. so the test configurations for such equipments are different with those defined in 25. testing methodology .Laptop mounted equipment Free Space test Core part Test part UEAnt_FSTest UEAnt_FSTestUEConTest R4 R5 09/12/201 1 07/12/201 2 100% 90% RP111381 RP110629 RP-111456 RP-120460 CATR ZTE RP#54 completed RP#56 completion 06/12=>12/1 2 Supporting Companies: CATR.114/25. Motorola.R5 Finish 07/12/201 2 Comp 96% Hyperlink RP111381 Status_Report WI_rapporteur CATR Notes RP#54 Core completed 45011 6 52001 1 Name UE Over The Air (Antenna) conformance testing methodology . RAN4 also completed the Over the Air (Antenna) minimum performance requirements for the speech mode (terminal close to head) in TS 25. Nokia. ZTE.1.114/TS25. 3GPP .144 and TR 25.144.114/25. Nowadays the laptop mounted UEs become more and more popular.1 (2012-06) 12. the related test specification TS 34. The details of this test method will be updated into 25.914 on UE and MS antenna performance evaluation method. so it needs a new WI to define the related matters.

165

Overview of 3GPP Release 11 V0.1.1 (2012-06)

12.2 Eight carrier HSDPA UID_500019
Resources:
UID 50001 9 50011 9

R1,R2,R3,R4
Acronym 8C_HSDPA 8C_HSDPACore Resource R1,R2,R3,R4 R1,R2,R3,R4 Finish 07/12/201 2 07/09/201 2 Comp 78% 99% Hyperlink RP101419 RP101419 Status_Report RP-120841 WI_rapporteur Ericsson Ericsson Notes Stage 3. RP#56 Core completed RP#56 completetion 06/12=>09/1 2

Name Eight carrier HSDPA Core part

TSs_a UTRA

50021 9

Perf. part

8C_HSDPAPerf

R4

07/12/201 2

60%

RP101419

RP-120470

Ericsson

-

25.101 25.104 25.133 25.211 25.212 25.213 25.214 25.215 25.308 25.331 25.423 25.433 25.101 25.104 25.133

Supporting Companies: Ericsson, Deutsche Telekom, T-Mobile USA, Nokia Siemens Networks, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Huawei, Renesas Technology Europe, Samsung, ZTE Justification Large mobile broadband usage and possibilities for competitive offerings to customers is continuing to increase the demands on the HSPA radio network. Dual-cell HSDPA operation was introduced in Rel-8, effectively doubling the achievable downlink user throughput throughout the cell. The evolution of multi-carrier HSPA has continued in subsequent releases. Rel-10 supports up to four HSDPA MIMO carriers spread over 1-2 frequency bands and up to two adjacent HSUPA carriers. It is expected that more spectrum will be made available for HSPA in the future. Further extensions of the multi-carrier HSPA operation is an attractive option for exploiting the available spectrum to achieve substantial gains in terms of both cell and user throughput. Core part Objective • Specify 5-8 cell HSDPA operation in combination with MIMO for the following scenarios: h. The 5-8 carrier transmission only applies to HSDPA physical channels. i. The carriers belong to the same Node-B. j. The carriers are configured to be spread across 1 or 2 bands. k. The carriers within one band are configured to be adjacent. l. Identification of which limited number of combinations (including which combinations of numbers of downlink carriers per band in the dual-band case and which carriers use MIMO) that should be targeted as part of the work item. The combinations developed under this WI will be added to the WID in RAN#52. m. Functionality currently defined for DC-HSDPA in combination with MIMO, DC-HSUPA, DBHSDPA and 4C-HSDPA should be re-used unless non-re-use can be justified by clear benefits. n. Since an independent design of 5-8 carriers HSDPA and DC-HSUPA is preferred, the work should assess the benefits of compatibility with single UL carrier operation while minimizing the required changes to existing features and channel structures. • Introduce the functionality in the relevant specifications of a. UL and DL control channel structure i. The work should focus on reusing existing structures as much as possible. b. L2/L3 protocols

3GPP

166

Overview of 3GPP Release 11 V0.1.1 (2012-06)

b.1 The Layer 1/2/3 protocols shall be designed in such a way that they would not require changes to support non-adjacent channels in same band c. UTRAN network interfaces d. UE RF core requirements with the work task breakdown In order to reduce UE RF combinations for the multi-band options, TSG RAN WG4 should as initial task identify a limited set of band combinations and number of carriers in each band to be covered in this WI so that the supported band combinations and number of supported carriers per band can be added to the WID in RAN#52. The way of working and combinations identified for DB-HSDPA in Rel-9 and 4C-HSDPA in Rel-10 should serve as a baseline for discussion for this WI. The work for 8C-HSDPA band combinations needs to be prioritized together with remaining band combinations for 4C-HSDPA. Work should address the following main areas: • 5-8 carrier solutions configured adjacent in one band where MIMO operation is configured for zero, some or all carriers • 5-8 carrier solutions across 2 bands where carriers on each band are configured adjacent and where MIMO operation is configured for zero, some or all carriers. • Operation of non-adjacent carriers within single band arising from the deactivation of one or more configured carriers should be supported if considered feasible by RAN4

Perf. part Objective: Specify UE performance requirements for Multi-carrier HSDPA operation with up to 8 carriers in combination with MIMO for the scenarios addressed in RAN1, RAN2 and RAN3 specifications and the core part of RAN4 specifications.

3GPP

167

Overview of 3GPP Release 11 V0.1.1 (2012-06)

12.3 UE demodulation performance requirements under multiple-cell scenario for 1.28Mcps TDD UID_500021
Resources:
UID 50002 1

R4,R5
Acronym LCR_TDD_UE_demod_mc Resource R4,R5 Finish 02/03/201 2 Hyperlink RP111244 Status_Report WI_rapporteur China Mobile Notes RP#53 Perf completed. Stage 3

50012 1

Name UE demodulation performance requirements under multiple-cell scenario for 1.28Mcps TDD Perf. part

LCR_TDD_UE_demod_mc -Perf

R4

16/09/201 1

RP111244

RP-110996

China Mobile

53003 8

Test part

LCR_TDD_UE_demod_mc -UEConTest

R5

02/03/201 2

RP111181

RP-120052

China Mobile

RP#53 completed. TR 25.873v100 for Approval RP#55 completed

Supporting Companies: Justification

China Mobile, CATR, CATT, ZTE, TD Tech, Ericsson, ST Ericsson, Marvell

The DCH demodulation performance requirements under single-cell scenario for TDD were introduced in Rel-4. However, there is a lack of performance requirements for 1.28Mcps TDD under multi-cell scenario, which may be different from single-cell scenario due to the interference from intra-frequency cells. According to the real network deployment, multi-cell scenarios are considered more realistic since UE in cell border is easy to be influenced by the interference from intra-frequency cells. Thus it is necessary to define the demodulation performance requirements for UE under multi-cell scenario, which will also indicate the capability of overcoming intra-frequency interference. Based on the above analyses, this work item, targeted for the Rel-10 timeframe, proposes to add demodulation performance requirements under multi-cell scenario for 1.28Mcps TDD UE. Objective: d. o e. to specify performance requirements for multi-cell scenarios including the following:

Performance in static propagation (AWGN) conditions Define the demodulation performance requirements with intra-frequency interference in static propagation (AWGN) conditions Performance in multi-path fading propagation conditions o Define the demodulation performance requirements with intra-frequency interference in multi-path fading propagation conditions

3GPP

168

Overview of 3GPP Release 11 V0.1.1 (2012-06)

12.4 Uplink Transmit Diversity for HSPA UID_500022
Resources:
UID 50002 2

R1,R2,R3,R4
Acronym HSPA_UL_TxDiv Resource R1,R4,R2,R3 Finish 07/09/201 2 Comp 78% Hyperlink RP120367 Status_Report WI_rapporteur Huawei Notes Stage 2/3

50012 2

Name Uplink Transmi t Diversit y for HSPA Core part Closed Loop

HSPA_UL_TxDivCL-Core

R1,R4,R2,R3

07/09/201 2

93%

RP120367

RP-120797

Huawei

RP#55 completion 06/12=>09/12 . Updated WID RP110374=>RP120367

50022 2 50032 2

Perf. part Closed Loop Core part Open Loop

HSPA_UL_TxDivCL-Perf HSPA_UL_TxDivOL-Core

R4

07/09/201 2 07/09/201 2

70%

RP120367 RP120367

RP-120798

Huawei

-

R4,R1,R2,R3

90%

RP-120473

Huawei

RP#56 completion 06/12=>09/12

50042 2

Perf. part Open Loop

HSPA_UL_TxDivOL-Perf

R4

07/09/201 2

60%

RP120367

RP-120799

Huawei

-

Supporting Companies: Huawei, HiSilicon, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, CATR, China Unicom, Deutsche Telekom AG, Ericsson, Interdigital, Magnolia Broadband, Nokia Siemens Networks, Orange, Qualcomm, Renesas Technology Europe, Samsung, ST-Ericsson, Telecom Italia, Telefonica, Teliasonera, T-Mobile US, Vodafone Group, ZTE Justification With the increased use of HSUPA and increased data rates, optimising uplink throughput and coverage while at the same time minimising UE battery consumption becomes more and more important Uplink transmit diversity is a means to achieve these goals by exploiting the spatial dimension when the terminal disposes of multiple transmit antennas. Open-loop transmit-diversity techniques not requiring any new feedback channels were studied by RAN1 and RAN4. During these studies promising performance enhancements were observed by the use of uplink transmit diversity. Closed loop transmit diversity using explicit uplink channel estimation from multiple antennas and feedback to the terminal is an interesting complement to open loop techniques since it provides additional performance enhancements especially in scenarios with higher mobile speeds and bursty traffic. Furthermore closed loop transmit diversity allows awareness and control of the UE behaviour by the network leading to a further optimised system configuration. In this work item proposal, we propose work on uplink open and closed loop transmit diversity for HSUPA. Objective: 1. 2. to specify uplink transmit diversity operation as follows:

RAN1, RAN2, RAN3 specifications and core requirements in RAN4 specifications for closed loop transmit diversity Performance requirements in RAN4 specifications for closed loop transmit diversity

3GPP

169

Overview of 3GPP Release 11 V0.1.1 (2012-06)

3.

RAN2, RAN3 specifications and core requirements in RAN4 specifications for open loop transmit diversity 4. Performance requirements in RAN4 specifications for open loop transmit diversity Conformance testing in RAN5 specifications will follow.

3GPP

and controlled by HS-SCCH orders).1. control channel design and power control procedures. codebook and the related enhancements in downlink control channels • Power control mechanisms • Required modifications to other L1 procedures • Minimise the influence on HS-DPCCH performance and downlink throughput in soft hand over • Investigate the interaction with existing UTRA features and CPC in particular • Specify the required changes in L2 protocols and related specifications • Specify the required changes in L3 protocols and related specifications allowing activation and deactivation of closed loop transmit diversity. • UL Pilot channel structure for uplink channel sounding based on two pilot channels sent from two transmit antennas at the UE • Investigate tradeoffs between implicit and explicit PCI indication in uplink and the design the related enhancements in uplink control channels • Control signalling mechanisms. Objective Perf. e. legacy devices not supporting transmit diversity • Minimize the impact and the complexity on the terminal and the network • Facilitate the possible extension to UL dual stream MIMO operation in particular for channel sounding and pilot design.170 Overview of 3GPP Release 11 V0.Closed Loop: to specify functionality to enable closed loop uplink transmit diversity as follows: Support for Closed Loop Beamforming and antenna switching Transmit Diversity (where antenna switching is realized as beamforming sub-modes with single antenna transmissions only.1 (2012-06) Objective Core part . existing TR or summary document. Listed here are Work plan steps in addition to those listed in parent work item: Until RAN#55 • Agree on framework for all BS and UE performance requirements Until RAN#57 • Finalization of all BS and UE performance requirements • 3GPP . and minimize the impact on. Take the following into account in the specification design: • As much as possible re-use the existing design for relevant control channels • Ensure coexistence with. The results shall be captured in an appropriate document.g. • Confirm performance gains of closed loop transmit diversity and key factors of the feature design.Closed Loop: to specify BS and UE performance requirements for uplink closed loop transmit diversity operation for the scenarios addressed in RAN1. part . For RAN4 (core requirements): RAN4 will start the work after RAN #51 Until RAN#52 • Agree on the assumption to derive NodeB/UE Tx & Rx core requirements based on input from RAN WG1 including CLTD design guideline • Analyze the impact on existing NodeB/UE Tx & Rx core requirements Until RAN#53 • Ideal results for NodeB/UE Tx & Rx core requirements • Alignment of results and update of assumptions (if necessary) for practical results to derive UE Tx & Rx core requirements Until RAN#54 • Practical results for NodeB/UE Tx & Rx core requirements • Agree on the modification of existing NodeB/UE Tx & Rx core requirements Until RAN#55 • Agree on additional NodeB/UE Tx & Rx core requirements • Finalize NodeB and UE Tx & Rx core requirements Need of additional NodeB requirements is subject to RAN#4 agreements. RAN2 and RAN3 specifications and the core part of RAN4 specifications.

RAN#52 o Agree on the assumption to derive UE Tx & Rx core requirements .Open Loop: to specify UE performance requirements for uplink open loop transmit diversity operation for the scenarios addressed in RAN2 and RAN3 specifications and the core part of RAN4 specifications.RAN#54 o Practical results for UE Tx & Rx core requirements o Agree on the modification of existing UE Tx & Rx core requirements .1. legacy devices not supporting transmit diversity • Minimize the impact and the complexity on the terminal and the network For RAN WG4 (core requirements): RAN4 will start the work after RAN #51 .1 (2012-06) Objective Core part. Take the following into account in the specification design: • Ensure coexistence with. 3GPP .RAN#53 o Ideal results for NodeB/UE Tx & Rx core requirements o Devise additional Tx & Rx core requirements . part .Open Loop: to specify functionality to enable open loop uplink transmit diversity as follows: • Support open loop beam-forming transmit diversity not requiring any new standardised dynamic feedback signalling between network and UE • The required changes in L3 protocols and related specifications allowing activation and deactivation of open loop transmit diversity.171 Overview of 3GPP Release 11 V0.RAN#55 o Agree on the additional Tx & Rx core requirements o Finalize UE Tx & Rx core requirements Objective Perf. and minimize the impact on.

104 25.104 25. 8 and 9 5 3 Remarks User Equipment (UE) radio transmission and reception (FDD) Base Station (BS) radio transmission and reception (FDD) Base Station (BS) conformance testing (FDD) Requirements on User Equipments (UEs) supporting a release-independent frequency band combination Justification 4C-HSDPA was defined in Rel-10 with limited scope of configurations. part TSs_a UTRA 4C_HSDPA_ConfigCore 4C_HSDPA_ConfigPerf R4.Four carriers for Band II (Region 2) – single band configuration Objective Core part: • • • • Objective Perf.317 Clause 5. Huawei.104 25. Add the following configuration to 4C-HSDPA specifications: o Four carriers for Band II (Region 2) – single band configuration Study the impacts of the configuration to the current 4C-HSDPA specifications and define appropriately when necessary.R2 Finish 15/06/201 2 Hyperlink RP110308 Status_Report WI_rapporteur Telus Communication s Telus Communication s Telus Communication s Notes RP#56 Perf completed RP#54 completed RP#56 completed 51011 8 51021 8 Name Introduction of New Configuration for 4CHSDPA Core part Perf. 6. Alcatel-Lucent Stage 3 Other justification TS or CR(s) 25.5 Introduction of New Configuration for 4C-HSDPA UID_510018 Resources: UID 51001 8 R4.1 (2012-06) 12. Some operators have determined that additional configuration will be required (see details in R4-110648).141 Supporting Companies: Telus Communications. This WI adds the combination below: . 7. Study RF performance requirements and backward compatibility issues.R2 R4 09/12/201 1 15/06/201 2 RP110308 RP110308 RP-111463 RP-120475 25.141 25. Bell Mobility. Nokia Siemens Networks.R2 Acronym 4C_HSDPA_Config Resource R4. Add the necessary changes to the relevant core UTRA requirements 3GPP . ZTE. part: • • Add the following configuration to 4C-HSDPA specifications: o Four carriers for Band II (Region 2) – single band configuration Study the impacts of the configuration to the current 4C-HSDPA specifications and define appropriately when necessary.1.172 Overview of 3GPP Release 11 V0. Qualcomm.101 25.141 25.101 25.101 25. Sierra Wireless.

Nokia Siemens Networks.1 25.R3 Acronym NC_4C_HSDPA Resource R4. RAN4 should initially study the feasibility of supporting operation of non-adjacent carriers with the assumptions above. Telecom Italia.1 (2012-06) 12.R3 Finish 07/12/201 2 15/06/201 2 Comp 71% Hyperlink RP110416 RP110416 Status_Report WI_rapporteur Ericsson Notes UTRA. specify UE core requirements for non-contiguous 4-carrier HSDPA operation BS core requirements reusing MSR non-contiguous core requirements for non-contiguous 4-carrier HSDPA operation Note that it is expected that the existing signalling introduced in the context of 4C-HSDPA can be used to support the selected band combinations RAN4 work should be initiated after RAN#52.4 25. Part of this feasibility analysis is to identify a limited set of band combinations and number of carriers in each band to be covered in this WI.3 25.R2. Deutsche Telekom. Huawei.1 Supporting Companies: Ericsson.1 25. Objective Core part: • • Study the feasibility of supporting 4-carrier HSDPA operation for two non-adjacent blocks of carriers within a single band with the following assumptions At most two UE receivers are assumed The total bandwidth per block does not exceed 15 MHz The carriers within the blocks are contiguous The total number of aggregated carriers does not exceed 4 Based on the outcome of the feasibility analysis. Icera. Renesas Justification Current 3GPP specifications allow for multi-carrier HSDPA operation for up to 4 carriers.R2.1 25. Orange.R2. all carriers have to be contiguous (adjacent).1 25. For operators with non-contiguous frequency allocation this restriction limits the possibilities to evolve their HSPA networks. it is necessary to introduce multi-carrier HSDPA operation with non-contiguous carriers in one frequency band.1.R3 100% RP-120842 Ericsson 51021 9 Perf. RP#56 Core completed RP#56 completed Name Noncontiguous 4C-HSDPA operation Core part TSs UTR NC_4C_HSDPACore R4. T-Mobile US. MediaTek. However. In order to enable deployment of HSPA technology in such situations. part NC_4C_HSDPAPerf R4 07/12/201 2 50% RP110416 RP-120477 Ericsson - 25.1 25.173 Overview of 3GPP Release 11 V0. ZTE. Expected Output and Time scale Core part 3GPP .6 Non-contiguous 4C-HSDPA operation UID_510019 Resources: UID 51001 9 51011 9 R4. and provide a recommendation on the continuation to RAN#53.

104 Base Station (BS) radio transmission and reception 25.1.433 UTRAN Iub interface Node B Application Part (NBAP) signalling 25.133 Requirements for support of radio resource management 25.331 Radio Resource Control (RRC).423 UTRAN Iur interface Radio Network Subsystem Application Part (RNSAP) signalling 25. R C Subject 25. R C Subject 25.101 User Equipment (UE) radio transmission and reception 25. part Affected existing specifications Spec No.101 User Equipment (UE) radio transmission and reception 25. part: • Specify UE performance requirements for the non-contiguous 4-carrier HSDPA operation for the scenarios addressed in the core part of RAN4 specifications.133 Requirements for support of radio resource management Approved at plenary# Comments RAN#56 RAN#56 RAN#56 RAN#56 RAN#56 RAN#56 Core requirements Core requirements Core requirements Objective Perf.174 Overview of 3GPP Release 11 V0.141 Base station (BS) conformance testing Approved at plenary# Comments RAN#58 Performance requirements RAN#58 Performance requirements RAN#58 Performance requirements RAN#58 Performance requirements 3GPP . Protocol specification 25.104 Base Station (BS) radio transmission and reception 25.1 (2012-06) Affected existing specifications Spec No. Expected Output and Time scale Perf.

Research in Motion Justification During the last recent years. These enhancements provide substantial improvements compared to R99 FACH/RACH.175 Overview of 3GPP Release 11 V0. T-Mobile USA.R1. This has been mainly due to the rapid penetration of smart phones. The CELL_FACH state was enhanced with the introduction of downlink HS-DSCH transmission in Rel-7 and uplink EDCH transmission in Rel-8. Nokia Siemens Networks. HiSilicon. throughput. As a result.R2.R4 Finish 07/12/201 2 07/09/201 2 Comp 45% Hyperlink RP111321 RP111321 Status_Report WI_rapporteur Qualcomm Notes Stage 2/3 Name Further Enhancements to CELL_FACH Core part Cell_FACH_enhCore R2. Telefonica. Vodafone. Renesas Electronics Europe. Alcatel-Lucent. part Cell_FACH_enhPerf R4 07/12/201 2 20% RP111321 RP-120479 Qualcomm - Supporting Companies: Ericsson. ZTE. China Unicom. the availability of mobile broadband dongles for computers and affordable rates for consumers. mobile networks have experienced a considerable increase of mobile data.R4 75% RP-120478 Qualcomm RP#56 completion 06/12=>09 2 51022 0 Perf. The Rel-7/8 features will serve as a natural basis for any further improvements of the CELL_FACH state. In order to facilitate this type of operation.R4 Acronym Cell_FACH_enh Resource R1. and minimum delays. coverage and battery consumption as in the other states. mobile networks need to implement new mechanisms to cope with this new traffic and make efficient usage of the available resources while providing high capacity and throughputs. Qualcomm. Huawei. a number of further enhancements of the CELL_FACH state should be considered. Objective Core part: Identify whether the gains justify the complexity for each of the following sub-features over existing mechanisms.R2. ST-Ericsson. it becomes increasingly attractive to try to keep these UEs efficiently in CELL_FACH state since other states are either associated with higher latency or higher resource demand. latency and coverage Support concurrent deployment of 2ms and 10ms TTI in a cell Per-HARQ-process grants for 2ms TTI TTI alignment between CELL_FACH UEs and CELL_DCH UEs Fallback to R99 PRACH 3GPP . Deutsche Telekom. However.1.R3.R3. The focus for this work should be to ensure that UEs with low to medium packet data activity can operate in CELL_FACH with a similar performance. as the packet data traffic related to mobile broadband. Introduction of machine type communications in the networks can be expected to follow this trend. smart phones and machine type communications continues to increase. and specify those for which this is shown to be the case. Orange. throughput.1 (2012-06) 12. Interdigital. The mobile data traffic is characterized by a lot of background signalling and bursty traffic with relatively small packets. • • Downlink related improvements of resource utilization. The increase of mobile data has introduced new challenges to mobile networks and the traffic characteristic of smart phones and computers is considerably different than that of traditional mobile phones. Telecom Italia.7 Further Enhancements to CELL_FACH UID_510020 Resources: UID 51002 0 51012 0 R1. latency and coverage Stand-alone HS-DPCCH without ongoing E-DCH transmission DC-HSDPA operation Uplink related improvements of resource utilization.R3.

176 Overview of 3GPP Release 11 V0. second UE DRX cycle in CELL_FACH) Mobility improvements: o Absolute Priority reselection from CELL_FACH o Enhanced network controlled mobility from CELL_FACH Note: Mobility improvements should apply from CELL_FACH to LTE and inter-frequency UTRA.1. while mobility improvement from CELL_FACH to GSM can be considered if sufficient operator interest is shown 3GPP .1 (2012-06) • • Reduction in timing of the initial access in the physical random access procedure Signalling based interference control UE battery life improvements and signalling reduction (e.g.

R4 Finish 01/03/201 3 07/09/201 2 Comp 37% Hyperlink RP111375 RP111375 Status_Report WI_rapporteur Nokia Siemens Networks Nokia Siemens Networks Notes Stage 2.R1.104 25.R4 Acronym HSDPA_MFTX Resource R2.101 25.R1.211 25.R2.R3.101 25.3 25.2 25.R3.2 25.1 (2012-06) 12.1 25.3 25.R4 70% RP-120482 53023 4 Perf.423 25.133 3GPP .R3.214 25.R1.R4 Finish 01/03/201 3 07/09/201 2 Comp 20% Hyperlink RP111393 RP111393 Status_Report WI_rapporteur Ericsson Notes Stage 3 TSs_a UTRA Name Four Branch MIMO transmissio n for HSDPA Core part 4Tx_HSDPACore R1.R2.1.1 12.3 25.3 25.R4 Acronym 4Tx_HSDPA Resource R1.433 25.4 25.2 25.133 25.R2.3 - Name HSDPA Multiflow Data Transmission Core part TSs UTR HSDPA_MFTXCore R2. part HSDPA_MFTXPerf R4 01/03/201 3 15% RP111375 RP-120483 Nokia Siemens Networks - 25.R3.1 25.R4 50% RP-120480 Ericsson 53023 5 Perf.8 HSDPA Multiflow Data Transmission UID_530034 Resources: UID 53003 4 53013 4 R2.1 25.213 25.331 25.215 25.R3.177 Overview of 3GPP Release 11 V0.1 25.9 Four Branch MIMO transmission for HSDPA UID_530035 Resources: UID 53003 5 53013 5 R1.212 25.R3.104 25.308 25.1 25. part 4Tx_HSDPAPerf R4 01/03/201 3 0% RP111393 RP-120481 Ericsson - 25.

R2 R4 60% 20% RP-120487 RP-120488 Ericsson Ericsson 25.178 Overview of 3GPP Release 11 V0.10 3GPP . part MIMO_64QAM_HSUPAPerf R4 14/06/201 3 0% RP111642 RP-120486 Nokia Siemens Networks - 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 12.1 (2012-06) 12.R4 Acronym MIMO_64QAM_HSUPA Resource R1.10 MIMO with 64QAM for HSUPA UID_540009 Resources: UID 54000 9 R1.R2.R4 07/12/201 2 60% RP111642 RP-120485 Nokia Siemens Networks - 54020 9 Perf.14 25.1.R2 Finish 07/12/201 2 07/09/201 2 07/12/201 2 Comp 37% Hyperlink RP111746 RP111746 RP111746 Status_Report WI_rapporteur Ericsson Notes Stage 3 - Name HSDPA DualBand MultiCarrier combinations Core part Perf.R2 Acronym HSDPA_DB_MC Resource R4.10 25.10 25.R2.R3.R3.R3.10 25. part TSs_ UTRA HSDPA_DB_MCCore HSDPA_DB_MCPerf R4.R2.11 HSDPA Dual-Band Multi-Carrier combinations UID_540024 Resources: UID 54002 4 54012 4 54022 4 R4.R4 Finish 14/06/201 3 Comp 24% Hyperlink RP111642 Status_Report WI_rapporteur Nokia Siemens Networks Notes Stage 3 54010 9 Name MIMO with 64QAM for HSUPA Core part TS U MIMO_64QAM_HSUPACore R1.

008. addressing and identification) TSs_and_TRs GERAN 44. select one PLMN ID and inform the network about the selected PLMN ID.e.C1 G1. therefore providing operators with the most suitable (GE)RAN sharing method becomes a need. ST-Ericsson. which means that there is a requirement on the network to supply the terminals with information about the PLMN IDs of the different operators sharing the GERAN network. For this purpose GERAN has already introduced the MOCN-GERAN WI for which only non-supporting MSs/UEs were managed (i.002. It is the understanding of supporting companies that such a requirement mandates the management of MOCN supporting MSs/UEs.S2.003 Numbering.179 Overview of 3GPP Release 11 V0. However in the meantime TSG SA WG1 has asked GERAN to “ensure support for manual PLMN selection in GERAN network sharing scenarios” (see LS GP-101446). 45. 48. It also puts a requirement on terminals to be able to read this information. it is the belief of supporting companies that MOCN is most suitable RAN Sharing method in this respect.060.S2.1. As re-farming means to significantly reduce the set of frequencies allocated to GSM the RAN sharing method has to be as efficient as possible regarding the use of remaining set of frequencies. 48.272 24.C1 Finish 23/11/201 2 Comp 70% Hyperlink GP120737 G2 23/11/201 2 65% GP120737 51020 1 51030 1 51040 1 56000 4 Stage 2 CN Stage 3 CT1 part of CN Stage 3 CT4 part of CN Stage 3 S2 C1. Standardization of management of MOCN supporting MSs/UEs in GERAN.S2.018 23.S2. Vodafone. Ericsson. 45. 3GPP .C1 G1 G2 WI_rapporteur Alcatel-Lucent Kapsch Carriercom Ericsson Vodafone 13. Continuation of Rel10 MOCN-GERAN UID_490001 GP#54 completion 05/12=>11/12. MediaTek 900 MHz spectrum re-farming to other RATs will lead operators to reduce GSM capacity and therefore to share their GSM networks.C4 C1 C4 07/03/201 2 07/09/201 2 07/09/201 2 07/09/201 2 100% 59% 60% 0% SP110390 CP110758 CP110758 GP120737 Notes GP#49 approved WID.C1 G2 S2 C1.1 (2012-06) 13 UID 510001 530002 540003 550023 GERAN Features Name Full Support of Multi-Operator Core Network by GERAN Introduction of ER-GSM band for GSM-R Medium range/local area requirements for multicarrier BTS Domain Specific Access Control in GERAN Acronym Full_MOCN-GERAN RT_ERGSM MRLA GDSAC Resource G2. Alcatel-Lucent Shanghai Bell.008 23.008. Updated WID GP-111459=>GP-120737 to include Gateway Core Network Sharing (GWCN).C4 C1 C4 S2 Hyperlink GP-120737 GP-120737 SP-110390 CP-110758 CP-110758 GP-120737 SP-120268 WI_rapporteur Alcatel-Lucent Alcatel-Lucent Alcatel-Lucent Alcatel-Lucent Alcatel-Lucent Alcatel-Lucent Vodafone Name Full Support of Multi-Operator Core Network by GERAN GERAN part Stage 2 CN Stage 3 CT1 part of CN Stage 3 CT4 part of CN Stage 3 Stage 2 for Gateway Core Network Sharing for GERAN UID 51000 1 51010 1 Name Full Support of MultiOperator Core Network by GERAN GERAN part Resource G2. only a Common PLMN was broadcast on the Radio Interface – a PLMN list was not broadcast).003 Supporting Companies: Justification Alcatel-Lucent. 44. SP#55 completed GP#54 updated WID GP111459=>GP-120737 (added CT4 part 23.018.251.C1 Resource G2.1 Full Support of Multi-Operator Core Network by GERAN (Full_MOCN-GERAN) UID_510001 Resources: UID 510001 510101 510201 510301 510401 560004 560042 G2. 23.

008 23. On the other hand please note that the handling of Extended ACs is out of the scope of this WID. The MS/UE has to indicate the selected PLMN identity to the network. UID 510201 Name Stage 2 Resource S2 Finish 07/03/2012 Hyperlink SP-110390 Notes SP#55 completed TSs_and_TRs 23. To provide specific access control on a per PLMN-basis. To achieve this. 3GPP . it is also proposed to optionally broadcast for each PLMN the set of legacy ACs to be used by any MS/UE selecting this PLMN. a PLMN list shall be broadcast by the network. It is proposed to use for this purpose the BCCH Extended feature and to be able to manage 4 PLMNs at the most in the PLMN list. which means that there is a requirement on the network to supply the terminals with information about the PLMN IDs of the different operators sharing the GERAN network. A PLMN list with at most 5 PLMNs will be broadcasted by the network. Objective: to change Core Network Stage 3 specification in order to support management of supporting MSs/UEs for GERAN network sharing. Since then SA1 has asked GERAN to “ensure support for manual PLMN selection in GERAN network sharing scenarios” (see LS GP-101446). On the other hand as supporting MSs/UEs may be allowed to select the legacy PLMN a supporting MS/UE may select a PLMN from up to 5 PLMNs.003 Justification To support the needs from the operators to share their GERAN networks so as to reduce the set of frequencies allocated to the GSM. Configurations for which the Core Network is shared (GWCN – GateWay Core Network configuration) are also in the scope of this WI. To support network sharing for up to 5 PLMNs. To provide specific access on a per PLMN-basis as for UTRAN sharing. justify: Refer to FULL-MOCN-GERAN feature WID. Stage 2 specifications need to be updated. and to optionally provide PLMN-specific EAB information for MTC services. Corresponding work in CT1 and SA2 work is also needed. UID 510301 510401 560004 Name CN Stage 3 CT1 part of CN Stage 3 CT4 part of CN Stage 3 Resource C1.1. GERAN has already introduced the MOCN-GERAN WI for which only non-supporting MSs/UEs were managed and only a Common PLMN was broadcast on the Radio Interface. GERAN work item 510001 has been agreed to provide full support of MultiOperator Core Network by GERAN. Based on this requirement. 23.C4 C1 C4 Finish 07/09/2012 07/09/2012 07/09/2012 Comp 59% 60% 0% Hyperlink CP-110758 CP-110758 GP-120737 TSs_and_TRs 24. The same LS also puts a requirement on terminals to be able to read this information. Supporting companies see also benefits to have a full convergence between GERAN and (E-)UTRAN Network sharing solutions. and the UE will indicate the selected PLMN identity to the network..251.272 If no identified source of stage 1 information.1 (2012-06) Additionally supporting companies believe that although the penetration rate for GERAN only MOCN supporting MSs is expected to be low. It is the understanding of supporting companies that such a requirement mandates the management of MOCN supporting MSs/UEs.180 Overview of 3GPP Release 11 V0. Objective: to enhance 3GPP Specifications in order to allow GERAN sharing to multiple CN nodes. select one PLMN ID and inform the network about the selected PLMN ID. the situation will be different for multi-RAT MOCN supporting UEs (integration of new features is much faster for multi-RAT UEs). Objective: for the SA2 part is to enhance 3GPP stage 2 Specifications only in order to allow GERAN to manage supporting MSs/UEs according to the above justification.

251CR0062R 2 as TEI11).251 specifies both MOCN and GWCN for EUTRAN and UTRAN.1. Orange. it may be that the sharing operators wish to use “GSM usage” as one input in the division of costs. 3GPP .1 (2012-06) UID 56004 2 Name Stage 2 for Gateway Core Network Sharing for GERAN Acronym Full_MOCNGERANGWCN Resource S2 Finish 12/09/201 2 Comp 80% Hyperlink SP120268 WI_rapporteur Vodafone Notes Stage 2. TeliaSonera. but GWCN is not yet supported on GERAN. Objective: to extend the FULL MOCN GERAN work to also cover GWCN GERAN. When refarming spectrum away from GSM. MOCN GERAN and FULL MOCN GERAN were introduced in Rel-10 and Rel-11 as a RAN sharing method to assist spectrum refarming. TS 23.181 Overview of 3GPP Release 11 V0. The reuse of the charging mechanisms supported on legacy MSCs and SGSNs may be beneficial for this purpose and is hence why GWCN GERAN is of interest to some operators In TS 23. SP#56 completion 06=>09/12 (23. Alcatel-Lucent GSM Network Sharing may become a useful feature. both MOCN and GWCN are specified for E-UTRAN and UTRAN. Extend Full_MOCNGERAN to also cover GWCN GERAN TSs_and_TRs 23. the additions needed to add GWCN GERAN to FULL MOCN GERAN are believed to be small.251 Supporting Companies: Justification Vodafone.251. In particular it offers the potential opportunity to refarm GSM spectrum to other cellular technologies. but GWCN is not yet supported on GERAN. Given that Rel-6 UTRAN network sharing specifications support both GWCN and MOCN variants.

and need for. • Spurious emissions requirements. which is planned for applications within the land mobile service based on national possibilities and national market demands. it is the understanding of the supporting companies that the ER-GSM band shall be included in the 3GPP GERAN specifications for harmonization purpose. the Electronic Communications Committee (ECC) Decision of 19 March 2004 on the availability of frequency bands for the introduction of Wide Band Digital Land Mobile PMR/PAMR in the 400 MHz and 800/900 MHz bands (amended 26 June 2009) Justification The ECC Decision of 19 March 2004 on the availability of frequency bands for the introduction of Wide Band Digital Land Mobile PMR/PAMR in the 400 MHz and 800/900 MHz bands (ECC/DEC/(04)06) amended 26 June 2009. addresses. To ensure that those requirements will minimize the potential impacts to existing GERAN systems in the E-GSM band. Performance requirements and Deployment scenarios ERGSM capability indication TSs_and_TRs GERAN Name Introduction of ER-GSM band for GSM-R 53010 2 53020 2 GERAN1 part 23/11/201 2 07/09/201 2 20% GP111468 GP111468 45. Sagemcom Nature of relationship among others: the use of the band 870876/915-921 MHz. Huawei.050 24. • Intermodulation attenuation requirements. to include an analysis of the extent of. Related Study Item or Feature (if any) Unique ID Title ECC/DEC/(04)06 European Conference of Postal and Telecommunications Administrations (CEPT).001.182 Overview of 3GPP Release 11 V0.005. For ER-GSM MS and BTS. Introduction of ERGSM band. Nokia Siemens Networks. definition of E-GSM-R specific: • Output power requirements. GP#51 approved WID. GSM-R within the bands 873-876 MHz / 918-921 MHz is considered as a subset of PMR/PAMR.2 Introduction of ER-GSM band for GSM-R (RT_ERGSM) UID_530002 Resources: UID 53000 2 G1. the use of the band 870-876/915-921 MHz. To secure that the current 3GPP GERAN requirements of the existing GSM 900 bands and therefore dedicated equipment and services are not affected.C1 Finish 23/11/201 2 Comp 11% Hyperlink GP111468 Notes Use of band 870-876/915-921 MHz for land mobile service on national possibilities/market demand . • Requirements to minimize the potential impacts to 3GPP systems outside of TSG GERAN’s responsibility. Kapsch CarrierCom.1 (2012-06) 13. To follow this Decision and help national administrations to reference the potential usage of the band ER-GSM band 873-876/918-921 MHz for GSM-R systems. • Blocking characteristics requirements. 3GPP . Objective: • • • • To introduce RF requirements for the ER-GSM band and therefore dedicated equipment along with necessary signalling into the 3GPP GERAN technical specifications.1.008 CT1 part 0% Supporting Companies: BMWi. among others. 45. In ECC/DEC/(04)06 it is decided that that the frequency requirements for Wide Band Digital Land Mobile PMR/PAMR systems referred to in the Annex to this Decision shall be met within the bands 870-876 MHz paired with 915-921 MHz with 45 MHz duplex spacing between the transmit frequencies of mobile stations (870-876 MHz) and the transmit frequencies of bases stations (915-921 MHz). To ensure robust operation of the ER-GSM equipment and services in the ER-GSM band. which is planned for applications within the land mobile service based on national possibilities and national market demands.as per ECC/DEC/(04)06 "CEPT ECC Decision on the availability of frequency bands for the introduction of Wide Band Digital Land Mobile PMR/PAMR in the 400 MHz GP#54 completion 08/12=>11/12. 45.

to specify the RF requirements for MCBTS medium range and local area classes. cost and minimizing impact to GSM network performance. 3. Objective: 1. Telecom Italia.1 (2012-06) 13. LS exchange with RAN4 is required. 2. Nokia Siemens Networks. Development of test requirements corresponding to new core requirements for the added MCBTS classes. Creation of new core requirements for two new MCBTS classes. Test requirements in TS 51. ZTE Nature of relationship GERAN specifications need aligned BS RF requirements Related Study Item or Feature (if any) UID Title 53003 E-UTRA medium range and MSR medium range/local area BS class 7 requirements Justification Multicarrier transceiver architectures applied to GSM BTSs allow GSM carriers to be processed by a single transmitter and power amplifier in the downlink and by a single wideband receiver in the uplink. since the new MCBTS classes are assumed to be deployed accordingly.183 Overview of 3GPP Release 11 V0.005 51. This work had limited impact on GERAN specifications since GSM RF characteristics requirements were already seen as sufficient to cover these deployment scenarios. intermodulation attenuation and blocking along with associated testing. The MR and LA requirements need to be aligned to those of the corresponding MSR MR and LA classes to the greatest attainable degree. 3GPP TSG RAN WG4 has recently initiated work on low-power MSR base stations (RP-111383) based on Medium Range and Local Area requirements.3 Medium range/local area requirements for multicarrier BTS (MRLA) UID_540003 Resources: UID 54000 3 54010 3 54020 3 G1 Finish 31/08/201 2 31/08/201 2 31/08/201 2 Comp 63% 95% 30% Hyperlink GP111780 GP111899 GP111782 WI_rapporteur Ericsson Ericsson Ericsson Notes Stage 3. informing about progress. In Rel-10.g. This work is expected to have much larger impact to GERAN specifications. Important RF characteristics were aligned towards UTRA. to make it possible for RAN WG4 and GERAN WG1 to create the 37series Rel-9 MSR specification.021 Name Medium range/local area requirements for multicarrier BTS Core part Perf. derived from the core requirements. while considering the energy efficiency. Steps: RF scenario analysis for the new MCBTS classes. This sharing of hardware resources by several carriers is expected to lead to significant cost reductions for the BTS equipments. Core requirements in TS 45.005 specification based on MSR principles.1. the MSR specifications were further developed to take non-contiguous spectrum deployment scenarios into account. However. The multicarrier BTS was introduced in Rel-8 based on the normal BTS and macro RF scenario. part Supporting Companies: Ericsson. b. Vodafone. The following specification work is required: a. 3GPP .021. with modifications of requirements for e. GP#54 completion 05/12=>08/12 Test spec TSs_and_TRs GERAN 45. taking medium range and local area scenarios described in RAN specifications as a starting point. since no multicarrier BTS exists for the underlying RF scenarios.

The signalling extensions for per-PLMN ACB are fairly significant. Nokia Siemens Networks. Hence it is proposed that Domain Specific Access Control is added at the same time as per PLMN ACB/EAB is being specified for FULL-MOCN-GERAN in release 11. Huawei.4 Domain Specific Access Control in GERAN (GDSAC) UID_550023 Resources: UID 55002 3 G2 Finish 31/08/201 2 Comp 35% Hyperlink GP120452 WI_rapporteur Vodafone Notes Work is dependent upon Full_MOCN-GERAN (UID_510001) TSs_and_TRs GERAN 44. the per PLMN ACB relates to issues within Core Network. per domain ACB/EAB”. Alcatel-Lucent. When a PLMN has a core network problem it is quite likely to be specific to one domain (PS or CS) and only more rarely applies to both PS and CS domains.184 Overview of 3GPP Release 11 V0. 3GPP . per PLMN Access Class Barring is being specified. It is anticipated any future extension of such coding to support “per PLMN per domain” ACB in a later release would be relatively inefficient to add. Objective: to extend the FULL-MOCN-GERAN “per PLMN ACB/EAB” specification to “per PLMN.1. Ericsson. Related Study Item or Feature (if any) UID Title 510001 Rel-11 WI on Full Support of Multi-Operator Core Network by GERAN (Full_MOCN-GERAN) Nature of relationship This WI is dependent Justification As part of the FULL-MOCN-GERAN work item.018 Name Domain Specific Access Control in GERAN Supporting Companies: Renesas. Note that TS 22. MediaTek.1 (2012-06) 13. Given that the legacy Access Class Barring functionality provides support for access network overload. ZTE Vodafone.011 already includes a generic requirement for independent access control for CS and PS domains.

S2 S1 WI_rapporteur China Mobile Qualcomm Tatara Systems Vodafone TR 22.894 3GPP .871 22.809 22.1.1 (2012-06) 14 UID 45004 7 46002 4 48003 3 49003 3 SA1 Studies Name Study on IMS based Peer-to-Peer Content Distribution Services Study on Non Voice Emergency Services Study on Support for 3GPP Voice Interworking with Enterprise IP-PBX Study on IMS Network-Independent Public User Identities Acronym FS_IMS_P2P FS_NOVES FS_VINE FS_INIPUI Resource S1.S2 S1 S1.185 Overview of 3GPP Release 11 V0.906 22.

TR 22. e. • Identifying potential copyright issues.. Hence. proposed by 3GPP. charging and security related requirements in the case of CDS on IMS. 3GPP access networks and non-3GPP access networks had been considered.906 has identified the use cases: Content on Demand.g.g. the number of media servers to provide streaming services is required to be increased almost linearly with the number of users. which helps reduce the storage and bandwidth demands of centralized servers.S2 Acronym FS_IMS_P2P Resource S1.186 Overview of 3GPP Release 11 V0. LTE allows the possibility of the speed up to 100Mbps downlink and 50 Mbps uplink) and more and more powerful mobile handsets have boosted popular usage of Content Distribution Services (e. Objective: to study IMS-based Content Distribution Services (CDS) with the following aspects: • Identify use cases describing how users. is viewed as a Fixed-Mobile Convergence Core Network to provide multimedia services.g.g. In case content is protected by copyright. and most of the traffic can be spread across the edge of the network. paying royalties. Fixed And Mobile Convergence scenarios. ZTE.g. Related service/charging/security requirements had been identified as well. LAN). but also they can handle the requests transferred from the neighbouring edge servers.1.1 (2012-06) 14. such as with the improvement of Peer-to-Peer technology. To consider: Mobile access only (e. the UE can offer spare uplink bandwidth and storage space while obtaining data. Fixed access only (e. So it is required to deploy more and more edge servers close to UEs to guarantee service quality with the increasing number of users. Potential Charging & Security Requirements and Copyright Issues. In addition. UE types.1 Study on IMS based Peer-to-Peer Content Distribution Services UID_450047 Resources: UID 450047 S1. • Identify QoS. Live streaming and Content on Demand) on mobile handsets. G/E-PON allows about 100Mbps downlink and 100Mbps uplink. and users can download the content segments from each other. The development of fixed and mobile broadband technologies (e. With the explosive growth of media content consumption. IMS. the proposal to study IMS-based Content Distribution Services in a Peer-to-Peer manner from an SA1 perspective (use cases and then investigate what service capabilities are required). multimedia session control. So the system capability is improved along with the increasing number of edge servers and UEs. Live Streaming and File Downloading. In case content is protected by copyright.906 Name Study on IMS based Peer-to-Peer Content Distribution Services Supporting Companies: China Mobile. Similarly. MMI and Charging requirements had been considered because users might offer service capabilities to other counterparts. mobility. content may only be released for use when certain conditions are satisfied. if the UE capabilities permit. registration. 3GPP . Not only the edge servers handle the requests from its locally served UEs. Huawei.. IMS defines an infrastructure for user authentication. IMS needs enhancements in cooperation with SDOs dealing with content distribution. Peer-to-peer technology can be used between edge servers and UEs to relieve the above problem. TR 22. and uploads data to other requested destinations. xDSL. To support Peer-to-Peer CDS. operators and service providers benefit from deploying IMS based CDS. I-WLAN). E-UTRAN. • Evaluate possible impacts and improvements on network when IMS-based CDS are deployed.S2 Finish 10/06/201 0 Hyperlink SP090491 WI_rapporteur China Mobile Notes SP#48 completed TR 22. Motorola.906 has indentified Potential Service Requirements to the IMS CN subsystem & to the IMS P2P application service. service discovery. Content is transmitted in a segmented manner. which might bring new security issues. Security impacts had been studied as the content may be transmitted between users. etc. centralized streaming media servers requires considerable demands towards the bandwidth of the backbone IP network. • Identify service aspects where IMS network improvements are needed to cater for CDS for above accesses. UTRAN. appropriate means for content charging needs to addressed.

Charging Aspects for NOVES will be determined by regional regulatory requirements. Real-time video session with emergency services In addition to support the general public. Text messages from citizen to emergency services Session based and session-less instant messaging type sessions with emergency services Multi-media (e.2 Study on Non Voice Emergency Services (FS_NOVES) UID_460024 Resources: UID 46002 4 S1 Acronym FS_NOVES Resource S1 Finish 21/09/201 1 Hyperlink SP090897 WI_rapporteur Qualcomm Notes SP#53 completed. this capability would facilitate emergency communications to emergency services by individuals with special needs (e. Therefore. Nokia. voice. Spin-off Feature UID_500030 Non Voice Emergency Services (NOVES) 3GPP .101 service requirements for emergency calls (with or without the IP Multimedia Core Network) are limited to voice media. hearing impaired citizens)..187 Overview of 3GPP Release 11 V0. Huawei.g. Objective: to include the following questions for NOVES with media other than or in addition to voice: • • • • • • • • • What are the requirements for NOVES? What are the security.1 (2012-06) 14. Nokia Siemens Networks. video clips) transfer to emergency services either during or after other communications with emergency services. 2. Many of the consumers assume that they can utilize these types of non-verbal communications as mechanisms to communicate with emergency services whenever emergency assistance is required. UTRAN.g. The Non Voice Emergency Services (NOVES) is intended to be an end-to-end citizen to authority communications. reliability.. subsequent text messages should go to the same PSAP)? Do multiple communication streams (e. video emergency services) need to be associated together? What types of “call-back” capabilities are required? Investigate the load impact of NOVES in the case of a large scale emergency event or malicious use. E-UTRAN and non-3GPP). Currently. and priority handling requirements for NOVES? How is the appropriate recipient emergency services system (e.871 Name Study on Non Voice Emergency Services Supporting Companies: AT&T. UTRAN) and to EPS (GERAN. MMI-Aspects related to the use of NOVES may need to be studied.1. 3. NOVES will be applicable to GPRS (GERAN. Spin-off Feature UID_500030 Non Voice Emergency Services (NOVES) TR 22. NOVES could support the following examples of non-verbal communications to an emergency services network: 1. TelecommunicationSystems.g. PSAP) determined? Are there any implications due to roaming? Are there any implications to hand-over between access networks Are there any implications due to the subscriber crossing a PSAP boundary during NOVES communications (e.g. text. Justification Non-verbal communications such as text messages and instant messaging via wireless devices has been very successful and continues to expand. the security impacts need to be studied. RIM. 4. TS 22.. Security Aspects: The content may be transmitted between the subscribers and the emergency services which might bring new security issues. pictures. The Emergency Services community has a desire to have multimedia emergency services supported with the same general characteristics as emergency voice calls. Ericsson. Alcatel-Lucent. Such mechanisms currently do not exist. Qualcomm.g.

Support Interworking between 3GPP networks and Enterprise environments to provide enterprise voice services via 3GPP mobile devices TR 22. Cisco. Verizon Wireless.g. China Mobile. Objective: to provide use cases and requirements for the following aspects of interworking between 3GPP networks and enterprise voice services: 1. Nokia Siemens Networks.1. it is not intended to pose additional requirements on H(e)NB subsystems as part of this Study Item. 3.809 approved.S2 Finish 23/03/201 1 Hyperlink SP100411 WI_rapporteur Tatara Systems Notes SP#51 TR 22. E.809 Name Study on Support for 3GPP Voice Interworking with Enterprise IP-PBX Supporting Companies: Vodafone.: when users move between cellular and enterprise environments using the same 3GPP mobile device / when users choose to switch the service between 3GPP mobile device and fixed IP Phone or soft PC Phone that is part of the enterprise environment. However.S2 Acronym FS_VINE Resource S1. etc. Service Aspects: to be covered in this Study: CS and IMS services Enterprise specific value-added services (e. It is expected that the interworking functionality can be deployed alongside any type of enterprise environment which may or may not include H(e)NB subsystems.1 (2012-06) 14. 2. Deutsche Telekom. As the enterprise environment is outside the scope of 3GPP.3 Study on Support for 3GPP Voice Interworking with Enterprise IP-PBX (FS_VINE) UID_480033 Resources: UID 48003 3 S1. The scope of the work will cover only 3GPP-related aspects which includes an interface towards the enterprise environment.188 Overview of 3GPP Release 11 V0.g. Ericsson. Support for CS and IMS voice services interworking with IP-PBX services while at the same time maintaining full operator visibility and operator control of the related voice service signalling in the mobile operator’s core network Mobile operator control of security. Justification There is interest among operators to support Interworking between 3GPP networks and Enterprise environments to provide enterprise voice services via 3GPP mobile devices. "short code dialling". any functionality within the enterprise environment will not be studied. The enterprise environment includes any IP network in the enterprise such as a fixed networks and wireless networks. Service control is expected to be based on IMS. manageability and operation of IP-PBX interworking function Mobile operator control of availability of IP-PBX services to 3GPP mobile devices Mobility between cellular and enterprise environments Continuity when an IMS session is moved between cellular and enterprise environments and when the IMS session is moved between mobile and fixed devices in the enterprise environment Use cases/requirements from other SDOs will be considered in this Study item. AT&T. transfer of sessions to a soft-phone on a PC) • Interaction between services provided by the mobile operator and services provided by the enterprise • • Charging Aspects: Consider charging requirements for enterprise services provided to 3GPP mobile devices. 5. Tatara Systems. 3GPP . 4. conferencing. The work is expected to cover various use cases for enterprise voice services. Use of prior work in other SDOs will be considered based on the use cases and requirements developed in Stage 1.

Orange. Although domains typically refer to an operator. AT&T. 3GPP . Telefónica.com. e. e.g.894 Name Study on IMS NetworkIndependent Public User Identities Supporting Companies: Vodafone. users may desire to employ identities based on their own domains especially in the case of corporations. one operator provides telephony services via the SIP URIs for telephony and another service provider provides email services via MAILTO URIs. ZTE. allowing the operator’s national/regional subsidiaries in different countries/regions to administer URIs with the same domain name portion will allow increased flexibility in the administering process.g. if the operator has subsidiaries in multiple countries. Ericsson. and operators sharing the domain name.1 (2012-06) 14. @operator. NOTE 2: This requirement is useful to allow user related addresses of a corporate domain of a multinational company. In the second scenario. e.189 Overview of 3GPP Release 11 V0. Any regulatory requirements will also be considered.1.g. those subsidiaries are not allowed to administer the URIs. the assignee of user@domain where it is not the same as the domain owner. It follows that allowing different operators within one country and also from different countries to administer URIs with the same domain name portion will provide increased flexibility. and arrangements for secure inter-operator resolution of non-operator domains are not defined. Alcatel-Lucent. @example.com is provided by different national subsidiaries of a single operator. Objective: to examine the use cases and requirements for the following functionalities: • Allow operators to assign to subscribers Public User Identities of the form user@domain where the domain element is any Internet registered domain that: o may not necessarily be owned by the IMS operator. This study item also aims to clarify the relationships between the domain owner. For example. NeuStar. Huawei. alphanumeric SIP URIs with the same domain name portion. and o can be the same domain name in another URI scheme without requiring provisioning by the same operator (see NOTE 2).com. @example. In the first scenario. a multinational corporation has IMS services provided on an operator-per-country basis. China Mobile. For the enterprise case. Due to the non-geographic nature of URI addressing.4 Study on IMS Network-Independent Public User Identities (FS_INIPUI) UID_490033 Resources: UID 49003 3 S1 Acronym FS_INIPUI Resource S1 Finish 08/06/201 1 Hyperlink SP100652 WI_rapporteur Vodafone Notes SP#52 completed TR 22. e. @operator. in general there are two scenarios that need to be considered. can only be administered by a single operator.com. o may be shared amongst different subscribers (identified in the "user" portion) that can belong to different IMS operators (see NOTE 1).g. Telecom Italia Justification Currently. NOTE 1: This requirement is useful when the IMS services for the domain name portion @operator. to be provided by different operators/service providers for different types of services. Therefore. a corporation has IMS services provided by different operators within one country.com.

Studying an overload control mechanism is necessary at least in the following cases: 3GPP . S-CSCF. At the same time a number of operators will progressively install new services such as multimedia conferencing or IPTV on the same IMS platforms. reducing options of solutions for the same issues. the method to distribute load between network elements in different regions especially when some disaster happens. in order to avoid congestion. new nodes can join the network and auto-configure themselves without manual intervention. It is deemed beneficial to review the current IMS architecture including aspects such as the possible of interfaces/reference points (by looking at different groupings of combining existing entities). IMS network service availability largely relies on the reliability of network entity. e. And if any node fails. IMS networks will have to cope with high volume of traffic with significant traffic peaks. Fixed and Mobile telecommunication providers will progressively move voice traffic from their legacy networks to IMS. Identifies some problems that telecom operators might encounter during IMS network deployment and operations. for example. Such mechanisms are essential to any carrier-grade telecommunication network.813 23.g. service availability will be severely impacted. while others are under loaded to some extent.1 Study on IMS Evolution (FS_eIMS) UID_410041 Resources: UID 41004 1 S2 Acronym FS_eIMS Resource S2 Finish 14/12/201 1 Hyperlink SP100360 WI_rapporteur China Mobile Notes SP#54 completed TR 23. Linked work items: IMS restoration procedures UID_400012. Introducing self-organization features will improve the network intelligence and reduce the efforts of manual configuration. by blocking traffic bound to this node when its load exceeds a certain threshold.812 23. Moreover network elements are not fully utilized because network load is not usually well distributed. Hence the need to study the evolution of IMS. HSS) go out of service. however we found out there is still some room for improvement in IMS architecture. the system level solution should be studied.190 Overview of 3GPP Release 11 V0. some nodes are often overloaded due to sudden traffic explosion. CATT. Orange. how to make IMS network simpler.850 15. Telecom Italia. Telefonica.885 23. ZTE.g. other nodes will take over the traffic through the failed node timely and automatically.1. and the network maintenance and upgrade are usually time-consuming and also costly for operators. relevancy of certain functions etc. This may have impact on IMS architecture and/or procedures. This calls for robust Overload Control mechanisms enabling reacting to the near-congestion state of a network node.812 Name Study on IMS Evolution Supporting Companies: China Mobile.1 (2012-06) 15 UID 41004 1 44004 7 44004 8 46003 0 51004 4 SA2 Studies Name Study on IMS Evolution Study on Policy solutions and enhancements Study on IPv6 Migration Study on Single Radio Voice Call Continuity from UTRAN/GERAN to E-UTRAN/HSPA Study on Roaming Architecture for Voice over IMS with Local Breakout Acronym FS_eIMS FS_PP FS_IP6M FS_rSRVCC FS_RAVEL Resource S2 S2. The network expansion requires a great deal of manual configurations. Local Breakout/Optimized Media Routing UID_370050 IMS architecture has laid a solid foundation for rolling out all kinds of multimedia services. SK Telecom. such as the ongoing work in CT4.975 23. Huawei.S1 S2 S2 S2 WI_rapporteur China Mobile AT&T China Mobile Orange Deutsche Telekom TR 23. such as earthquake. For example. If some critical network elements (e. more robust. Though there’re some element level approaches to solve these problems. Deutsche Telekom. more intelligent and therefore easier to operate and maintain. Verizon Wireless. for example. upon discovering the entry point of the network.

• 3GPP . Objective 2 to study IMS Overload Control: • • Determine the parts of IMS architecture for which overload control mechanisms are needed. ETSI and IETF are working on the specification of a SIP-based mechanism for supporting overload control procedures.191 Overview of 3GPP Release 11 V0.1 (2012-06) • • • protecting a network from overload caused by traffic sent by different networks (at the NNI). if proposed within this study item.1.  other mechanisms.  mechanisms specified or studied by e. Objective 1 to study the feasibility of enhancing IMS network architecture by investigating: • • • architectural improvements to reduce the complexity of signalling procedures by reducing the signalling hops. means to improve system-level load balancing and reliability. including:  mechanisms having already been specified or studied within 3GPP and their possible enhancements. NOTE: overlap with SA5 and CT4 work need to be monitored. Provide recommendations based on analysis. ETSI TISPAN. possibilities for reducing configuration workload to save OPEX.g. Backward compatibility with current IMS specifications shall be ensured. IETF and their possible enhancements. protecting an Application Server from overload caused by traffic sent by S-CSCFs (e. protecting a network from overload caused by traffic coming at the user-to-network interface. or the number of options and combinations (by looking at different groupings of combining existing entities). AS in charge of a TV game receiving a peak of traffic).g. Evaluate the applicability of candidate solutions for Overload Control to the SIP entities of the IP multimedia core network architecture.

One of the aims of the study is to ensure a policy architecture that provides an extensible framework for easy reuse with new IP based services by identifying areas where improvement of specifications are feasible. China Mobile.g.S1 Finish 08/06/201 1 Hyperlink SP090895 WI_rapporteur AT&T Notes SP#52 completed TR 23. location related info for use with the service etc. Huawei. other mechanisms.S1 Acronym FS_PP Resource S2. PCEF and BBERF • SPR. Telecom Italia.working with 3GPP) • Session transfer and terminating policies • Security policy control. • user subscriptions.1 (2012-06) 15. NEC. In addition. Nortel Networks. However the approach so far has been fragmented and a more comprehensive approach would ensure better policy decisions.g. Nokia Siemens Networks. Existing components for consideration in the Policy Study are functions and interfaces to/from • PCRF. Alcatel Lucent. Qualcomm. Starent Networks. TS 22. For example. to use different PDNs for different services.278 and in BBF WT 203. by intelligently identifying service in use and providing service enhancement via e.2 Study on Policy solutions and enhancements (FS_PP) UID_440047 Resources: UID 44004 7 S2. • Standardized and extensible ways to implement service policies that go beyond existing PCC IP flow policies.192 Overview of 3GPP Release 11 V0. ZTE. • terminal capabilities (including converged terminals) • network capabilities (3GPP and those non 3GPP accesses inter. e. The study item will look into solutions for the examples in the section above. Some examples of what is missing are • Deep Packet Inspection coupled with user privacy policies to improve user experience.220. Juniper Networks. Toshiba. operators are looking into ways to inter-work the 3GPP PCC architecture towards fixed access networks in support of requirements and use cases defined in 3GPP SA1 TS 22. Panasonic.g.813 Name Study on Policy solutions and enhancements Supporting Companies: AT&T. Rogers Wireless. Ericsson. 3 Justification The importance of policy based service delivery has been recognized within 3GPP and has resulted in following work in the last few releases: QoS and Charging related policies • PCRF – Non 3GPP access inter-working • ANDSF • Mobility protocol selection In addition there has been work done in IMS that defines policies related to selection of IMS for service delivery vs. Telcordia. China Unicom. firewalling and gating – 3GPP . Cisco.1. • Service based traffic steering e. • service requirements. appropriate QoS for the service. For example transactional service policies such as a policy to enforce max limit on SMSIP/month based on user profile etc. Verizon Wireless. LG Electronics. BT. For example issues such as source address selection when the UE is connected to multiple PDNs. Other example could be service policy such as redirect and firewall control. HSS • ANDSF • IMS policy decision making entities The study aims to provide a more comprehensive way (e. 3GPP work in this area reflects efforts to improve service delivery based on operator policy. user preferences etc. going beyond existing 3GPP PCC framework) to handle operator policies for all IP / service flows (IMS and non-IMS) in a coordinated manner and under varying network conditions while keeping in view aspects such as • user preferences.g. 4 Objective The objective is to study an evolved policy solution through enhancement of 3GPP policy framework. Allot Communications.

dynamic.1 (2012-06) Roaming scenarios shall be considered as part of this study.1. network based. 8 Security Aspects Provisioning of policies and associated privacy issues will impact security aspects. 5 Service Aspects The propose work will not impact specific services but is likely to have some impact on aspects of service delivery.e. Compatibility with existing system architecture elements shall not be disrupted and backward compatibility will be a requirement. 7 Charging Aspects The proposed work is not likely to impact the charging data collection. In some other policy aspects it is envisioned coordination with SA1 may be needed. 3GPP . All types of policies i. Note: For some work such as deep packet inspection SA1 has indicated in the past that no new requirements are needed.193 Overview of 3GPP Release 11 V0. static/pre-provisioned. But access network selection related policies are likely to take into consideration charging policies. Another objective is to study how to enable inter-working between 3GPP PCC architecture and fixed access networks to meet SA1 use cases and requirements per reference in the section above. UE based would be considered in the study.

AT&T. Motorola. Panasonic. Samsung.1. CATT. Rogers Wireless. and identify the compatibility between applicable transition mechanisms Identify any impact on 3GPP network elements Provide recommendations on IPv6 migration and identify if any normative work is needed 3GPP . Furthermore. including: Identify the migration/deployment scenarios of interest for operators and the respective assumptions and requirements Analyze existing IP address allocation mechanism for terminals and provide guidelines Investigate IPv6 transition mechanisms for the scenarios identified during the study and investigate their applicability for 3GPP network. NEC. Qualcomm Europe.981. Ericsson. and how to handle scenarios where not all services are provided via IPv6. Nokia-Siemens Networks. taking into account the recommendations outlined in TR23. 3GPP have not investigated how to migrate from IPv4 to IPv6-only with the help of transition mechanisms defined in IETF. 3GPP SA2 has mainly specified IPv6 address allocation and relevant signalling process in TS 23. Cisco. Alcatel-Lucent. demands for deploying IPv6 are higher than before. ZTE. Juniper Networks.975 Name Study on IPv6 Migration Supporting Companies: China Mobile.194 Overview of 3GPP Release 11 V0. With depletion of IPv4 address and development of data service. Verizon Wireless.3 Study on IPv6 Migration (FS_IP6M) UID_440048 Resources: UID 440048 S2 Acronym FS_IP6M Resource S2 Finish 08/06/201 1 Hyperlink SP090362 WI_rapporteur China Mobile Notes SP#52 completed TR 23. That is fundamental capability to support IPv6 deployment. Some of these solutions may have impacts on 3GPP network elements. Orange. Telecom Italia.1 (2012-06) 15.060. Starent Networks. compatibility and interconnection between different transition mechanisms needs to be considered.401 and TS 23. Huawei. T-Mobile. 4 Objective: to analyze different IPv6 migration scenarios and applicable mechanisms as well as to identify impacts on 3GPP network elements. However. Therefore it is necessary to identify and evaluate possible impacts on 3GPP network elements and terminals and to provide recommendations on IPv6 migration based on the appropriate deployment/migration scenarios applicable for 3GPP networks. Nokia.

Nokia Siemens Networks. Alcatel-Lucent. 4 Objective The objective of the feasibility study is to investigate a solution for supporting seamless service continuity when UE handovers from UTRAN/GERAN CS access to E-UTRAN/HSPA for voice call initiated in LTE and handed over to 2G/3G CS access as well as for the voice call directly initiated in 2G/3G CS access. LG Electronics. NEC. NTT DoCoMo. 3 Justification Release 8 SRVCC has defined the requirements for supporting SRVCC between UTRAN/GERAN and EUTRAN/HSPA in both directions.1. Telenor. Samsung. ZTE.885 Name Study on Single Radio Voice Call Continuity from UTRAN/GERAN to EUTRAN/HSPA Supporting Companies: Orange . ST-Ericsson. while there are some clear use case(s) for UTRAN/GERAN to E-UTRAN/HSPA service continuity. China Mobile. Deutsche Telekom. 3GPP . ATT. China Unicom. TeliaSonera. Huawei. Study on "reverse direction" from UTRAN/GERAN to EUTRAN/HSPA (Rel-8 SRVCC was in the other direction EUTRAN/HSPA to GERAN/UTRAN) TR 23. Starent Networks.4 Study on SR Voice Call Continuity from UTRAN/GERAN to E-UTRAN/HSPA (FS_rSRVCC) UID_460030 Resources: UID 46003 0 S2 Acronym FS_rSRVCC Resource S2 Finish 14/12/201 1 Hyperlink SP090806 WI_rapporteur Orange Notes SP#54 completed.195 Overview of 3GPP Release 11 V0. However the UTRAN/GERAN CS access to E-UTRAN/HSPA service continuity was not specified in Rel-8 and Rel-9.1 (2012-06) 15. Ericsson.

i. However there are several topics that need clarification. Furthermore the setup of the necessary SDP information and also the specification where this information is produced and where it is processed and executed needs to be clarified. Interdigital. The service control is retained by the HPLMN also in the case where the destination network is the same as the VPLMN where the roaming user is. It is expected that the GSMA will provide guidance as to which of the alternatives (if more than one is identified) should be selected. The roaming architecture for voice over IMS using local breakout needs to fulfil the following objectives: allow the service control to be performed by the HPLMN (e. The IMS control plane is routed to the destination via the HPLMN. Telecom Italia. KDDI. e. can be routed to any IP target node according to IMS SDP description received via IMS control plane from the HPLMN IMS domain.196 Overview of 3GPP Release 11 V0. to cater for the case where the destination address is modified). Additionally the GSM Association has been discussing the roaming architecture for voice over IMS and has decided that local breakout in the visited network will be needed (see GSMA PRD IR. Ericsson. ST-Ericsson. Objective: to consider a solution for the provision of voice over IMS in roaming scenarios that facilitates the realization of a charging model that replicates the principles of CS model. CS (GSM/ISDN/POTS) or PS (TISPAN/3GPP IMS) network using any kind of interconnection it might require. i. Telia Sonera UID 49003 2 AT&T. Related to LBO/home routing decision TR 23. The replication of charging models will require also the replications of routing principles especially when it comes to legacy CS-interworking.65). The solution will be such as to allow the VPLMN to support outgoing voice over IMS calls from inbound roamers: • • • towards any kind of Destination Network. In such study SA2 should identify if and which changes to the core 3GPP specifications are needed. the split/bundling of user and control plane needs to comply with the above mentioned principles. instead of being routed to the HPLMN. Linked to Rel-11 OSCAR (Optimized Service Charging and Allocation of Resources in IMS whilst Roaming) UID_490032. In the proposed model the UE obtains an IP address from the VPLMN.e.g.1 (2012-06) 15. • Allow to reach a user whose number has been ported to a different PLMN using the same resolution mechanism adopted by the VPLMN for their own users.e.g.850 Name Study on Roaming Architecture for Voice over IMS with Local Breakout Supporting Companies: Telenor.1. Deutsche Telekom.5 Study on Roaming Architecture for Voice over IMS with Local Breakout (FS_RAVEL) UID_510044 Resources: UID 51004 4 S2 Acronym FS_RAVEL Resource S2 Finish 14/12/201 1 Hyperlink SP110087 WI_rapporteur Deutsche Telekom Notes SP#54 completed. Local breakout can be regarded as one cornerstone to replicate the above mentioned charging and routing principles. The user plane. legacy CS or PS (IPX) interconnection 3GPP . Related Work Item(s) (if any] Title Rel-11 Feature: Optimized Service Charging and Allocation of Resources in IMS whilst Roaming (OSCAR) Nature of relationship LBO/home routing decision Justification The GSM Association requested 3GPP to check if the replication of the charging principles that apply to circuit switched voice can also be applied to voice over IMS (see the LS from GSMA CPWP to SA5 in S5-102806).

1. The voice over IMS roaming architecture should not impact the interconnection networks. in particular. origination network (MTC). i. legacy CS or PS (IPX) interconnection In the course of the study. the solution should. media plane routing aspects need also to be taken into account.e.197 Overview of 3GPP Release 11 V0. i. consider the case where the HPLMN requests the user plane to be anchored in the HPLMN. Charging Aspects: The roaming architecture for voice over IMS with local breakout will be such as to enable the relevant network nodes to generate charging information that allows a replication of the CS charging model between VPLMN and HPLMN as well as between originating/terminating PLMN and interconnection providers. CS (GSM/ISDN/POTS) or PS (TISPAN/3GPP IMS) network using any kind of interconnection it might require.e. Security Aspects: to be determined by SA3 3GPP .1 (2012-06) The solution will be such as to allow supporting incoming voice over IMS calls to outbound roamers: • • from any kind of Destination Network. Further objectives are expected to be defined according to requirements provided by GSMA. destination network (MOC) and remote party when a SRVCC procedure is invoked within the VPLMN.

E-UTRAN has introduced a key hierarchy. ZTE. 16. Nokia. including user plane and signalling protection. Orange. Telenor. Rogers Wireless. The study should cover the technical feasibility and consequences. Orange. 4 Objective The objective of this work item would be to study potential solutions for introducing a key hierarchy in UTRAN to improve the security level in the presence of the new deployment scenarios and to ensure that a security breach in UTRAN will not propagate into E-UTRAN. moved to HSPA NodeBs present the same threat environment as encountered by E-UTRAN eNBs.804 16.859 33. Nokia Siemens Networks.1 (2012-06) 16 UID 38008 4 48004 8 SA3 Studies Name Study on UTRAN key management enhancements Study on Single Sign On (SSO) Application Security for IMS . SP#54 TR 33. Ericsson. The impacts of such potential solution on UTRAN rel-9 should be identified. This.328.828 and TS 33. Qualcomm.based on SIP Digest Acronym FS_UKM FS_SSO_APS Resource S3 S3 WI_rapporteur Ericsson Nokia TR 33. Alcatel-Lucent Shanghai Bell. because the mapped EPS security context used in E-UTRAN will not be based on UTRAN keys that have been exposed on the air interface. BT. With the current key management in UTRAN it is impossible to achieve the same level of protection as in E-UTRAN.1. AT&T. ST-Ericsson. Introduction of a key hierarchy in UTRAN resembling the one in E-UTRAN would enable having similar level of protection in both systems when it comes to compromised base stations.829 Name Study on Extended IMS Media Plane Security features Supporting Companies: Alcatel-Lucent. 3GPP .859 Name Study on UTRAN key management enhancements Supporting Companies: 3 Justification Alcatel-Lucent.859v200 for Approval TR 33. Present deployments of UTRAN with part of the RNC functionality. Huawei.914 converted to 33. making security breaches of the keys used on the air-interface much less severe. Vodafone. Continuation of Rel-9 Feature UID_430036 IMS Media Plane Security (MEDIASEC) Study solutions and extensions to features and functionality described in TR 33.1 Study on UTRAN key management enhancements UID_380084 Resources: UID 38008 4 S3 Acronym FS_UKM Resource S3 Finish 07/03/201 2 Hyperlink SP090283 WI_rapporteur Ericsson Notes SP#55 completed.x Study on Extended IMS Media Plane Security features UID_480043 (moved to Rel-12) Resources: UID 48004 3 S3 Acronym FS_eMEDIASEC Hyperlink SP100256 WI_rapporteur Vodafone Notes TR 33. Ericsson.198 Overview of 3GPP Release 11 V0. The introduction of a key hierarchy in UTRAN would achieve additional benefits by yielding interworking between UTRAN and E-UTRAN more secure.

based on SIP Digest UID_480048 Resources: UID 48004 8 S3 Acronym FS_SSO_APS Resource S3 Finish 20/06/201 2 Hyperlink SP100639 WI_rapporteur Nokia Notes SP#56 completed. or BBF. 2. or passwords. Bootstrapping enables Single SignOn (SSO) to applications using the security infrastructure already present for e. as defined in 3GPP TS 33. TS 33. SIP Digest as an authentication mechanism for access to the Common IMS core over a non-3GPP access network. This means that other types of credentials.924 Identity management and 3GPP security interworking. credentials used for access to the Common IMS.804 Name Study on Single Sign On (SSO) Application Security for IMS . The study may identify features that allow the re-usage of the described SSO approaches.914 converted to 33. SP#55 TR 33. The study may identify the optional transport of SIP digest related data form HSS to BSF for support of SIP digest based user authentication and introduction of related data fields. or cable access. or held by the user.109 Zh and Zn interfaces based on Diameter TS 24. Identity management and Generic Authentication Architecture (GAA) interworking TS 29. 3GPP network access. provides a bootstrapping mechanism.g. The Generic Bootstrapping Architecture (GBA). such as e. stored in the HSS and in the terminal. e. The process of providing security in a certain context (application) based on security already defined in some other context (e. Provide reference material for IMS based non-UICC based SSO to applications. 3GPP TS 33.1. 3GPP network access or IMS. Rogers Wireless.804).g.203 defines. Nokia Siemens Networks.220.199 Overview of 3GPP Release 11 V0. TISPAN NASS. or 3GPP2 access.2 Study on Single Sign On (SSO) Application Security for IMS .228 Cx support for SIP Digest Authentication 3 Justification This Study Item targets to reuse non-UICC credentials.g. The study may identify features that extend the existing approaches on interfaces for applications The study may identify features that allow re-usage of the credential infrastructure of the SIP Digest authentication mechanism defined for Common IMS in TS 33. Study reuse of nonUICC credentials (in particular SIP Digest) to provide security for access to applications. The study may identify optional impact on Cx for SSO support.203 Access security for IP-based services TR 33. to provide security for the access to applications. AT&T.914v200 approved (converted 33.based on SIP Digest Supporting Companies: Nokia. cannot benefit from GBA to provide security for the access to applications based on the security for network access or IMS.220 Generic Bootstrapping Architecture (GBA) TS 29. The credentials used with SIP Digest are shared secrets.203. but it is limited to UICC-based credentials.1 (2012-06) 16.g. GBA enables single sign-on to applications 3GPP . TS 33. TeliaSonera Study the reuse of non-UICC credentials (in particular SIP Digest) to provide security for the access to applications. in particular SIP Digest credentials. By means of bootstrapping. or WiMAX access. in particular. IMS) is often called bootstrapping of security.109 Bootstrapping interface (Ub) and network application function interface (Ua). Provide reference material for IMS based non-UICC based SSO to applications TR 33.1 Study Item Title Related Work Item(s) (if any] Nature of relationship The study may identify features that extend the existing GBA functionality The study may identify features that build upon the GBA core network functionalities.

Furthermore. Users would benefit from SSO as it reduces complexity for users when accessing applications.141. A similar need for the re-use of SIP Digest credentials for applications has been recognized by ETSI TISPAN. The re-use of SIP Digest credentials for SSO to applications would bring the benefit. This study item takes into consideration the benefits of SSO to applications and the provision of cryptographic keys to terminals and application servers.200 Overview of 3GPP Release 11 V0. The study item should describe needed extension to enable a re-use of SIP Digest credentials in Common IMS for providing security between a terminal and an application server. Charging users for the use applications could be tied to the IMS subscription. 3GPP . used for self-administration of IMS subscribers. and work was started there in December 2009. in particular SIP Digest. that there is no need for rolling out a separate security infrastructure for these applications. SSO_APS would ease the introduction of new applications and services for the operator whose subscribers use SIP Digest credentials in Common IMS. 7 Charging Aspects Through SSO_APS. the operator could provide a chargeable service to application providers. cf. Charging users for the use applications could be tied to the IMS subscription. an automated way for providing the security for the Ut interface. 4 Objective The objective of this study item is to provide reference material for IMS based non-UICC based Single Sign On (SSO) to applications. 5 Service Aspects A study on SSO_APS would show the way which would allow single sign-on to applications without the need for rolling out a separate security infrastructure for these applications. In this context optional extensions of interfaces to the HSS for supporting SIP Digest based SSO should also be studied. The use of SSO_APS is intended to be restricted to environments where the storage of credentials on a UICC is not mandated. would be for the benefit of subscribers using SIP Digest credentials. GBA may be used for providing the security for the Ut interface used for self-administration of IMS subscribers. In this way. The Study Item targets to bring forth approaches with a security level for access to applications using SSO_APS that is at least as good as that provided by SIP Digest for Common IMS. a SSO mechanism re-using SIP Digest credentials would ease the introduction of new applications and services for the operator whose subscribers use SIP Digest credentials in Common IMS. although this is a matter for further discussion. SIP Digest is arguably the most commonly used authentication mechanism in current IMS deployments.1 (2012-06) using the security infrastructure already present for 3GPP network access or IMS. In this way. TS 33. This is FFS. As an example. operators could provide a chargeable service to application providers. The study item aims to maximise the commonalities of the SSO_APS with the currently defined application security approaches in 3GPP while efficiently satisfying the needs of Common IMS deployments using SIP Digest. are used. 6 MMI-Aspects User would benefit from single sign-on as it reduces complexity for users when accessing applications. This study item targets to re-use the SIP Digest Credentials for SSO to applications by re-using Common IMS and existing security elements. bootstrapped from IMS credentials that are available in those scenarios where nonUICC based authentication mechanisms.1. As an example.

. • Identify potential needs for the 3D subtitles and graphics support and analyze corresponding solutions. • Study the constraints and the adaptations required when considering a 3D video content.. recommend for the potential adoption. which would need to be addressed in a work item. produced for TV set viewing and displayed on a mobile terminal. ETRI. convergence environment. they can be considered to be delivered on 3D capable UEs for seamless 3D consumption. and hence deployment of selected video coding technologies. The use cases and the solutions proposed in the TR26. Huawei.905 Name Study on Mobile 3D Video Coding Supporting Companies: Orange. more and more stereoscopic 3D video contents are available.905 17. The 3D part of the release 10 study item Improved Video Coding Support only addressed the encoding formats and the frame-packing arrangements. France Telecom. DVB. 3D capable UEs are introduced in the market in order to highlight the significant progress achieved in terms of rendering and capturing capabilities. the study item will use similar work achieved in other standardization groups (MPEG. • Study potential network capacity/bandwidth and quality of service (QoS) requirements for 3D video services over 3GPP networks. Samsung. Ericsson.) as input to the study. ST-Ericsson. Objective: to further analyze the candidate solutions which enable the delivery of stereoscopic 3D services.1 Study on Mobile 3D Video Coding (FS_M3DVC) UID_520036 Resources: UID 52003 6 S4 Acronym FS_M3DVC Finish 20/06/201 2 Hyperlink SP110310 WI_rapporteur Orange Notes SP#56 completed.1. Based on results provided in TR 26. Nokia. Therefore. content portability).201 Overview of 3GPP Release 11 V0. Intel. • Evaluate the subjective quality achieved with the candidate solutions on the 3D capable UEs especially on mobile autostereoscopic displays. Fraunhofer Gesellschaft. 3GPP .1 (2012-06) 17 UID 520036 SA4 Studies Name Study on Mobile 3D Video Coding Acronym FS_M3DVC Resource S4 WI_rapporteur Orange TR 26. Deutsche Telekom.904 require further analysis of performance. MBMS user services and MTSI services. ZTE Extends Rel-10 work on 3D video formats UID_480044 Improved Video Coding Support for PSS and MBMS Justification The evolved radio access networks allow for considering enhanced video services which require higher bitrates in order to provide a significant improvement in terms of quality of experience.904 “Improved Video Coding Support for PSS and MBMS services” the objectives are: • Identify new and refine existing use cases that may require specific 3D requirements. Qualcomm. Extends Rel-10 work on 3D video formats UID_480044 Improved Video Coding Support for PSS and MBMS TR 26. • Continue the evaluation of the video coding technologies regarding the potential service requirements (such as the 2D backward compatibility. • Based on the outcome of the evaluations. When applicable. • Propose guidelines for the usage and deployment of the technologies for the identified use cases and if necessary identify needed adjustment of existing service components and functionality for improved integration of the selected video coding technologies. Due to the commercial launch of 3DTV broadcast services in 2010 over satellite or IPTV. The scope of the study includes but is not limited to PSS (including HTTP-based Streaming and Download).

1 (2012-06) Service Aspects: This study may result in recommendations for the support of stereoscopic 3D video coding solutions and the adjustment of existing service components and functionality for improved integration of the selected video coding technologies.202 Overview of 3GPP Release 11 V0.1. 3GPP .

Samsung.938 Name Study on Improved Support for Dynamic Adaptive Streaming over HTTP in 3GPP Supporting Companies: Qualcomm.203 Overview of 3GPP Release 11 V0. Intel.1 (2012-06) 17.x Study on Improved Support for Dynamic Adaptive Streaming over HTTP in 3GPP UID_540033 (moved to Rel-12) Resources: UID 54003 3 S4 Acronym FS_IS_DASH Finish 12/09/201 2 Comp 5% Hyperlink SP110887 WI_rapporteur Qualcomm Notes Linked to Feaqture UID_470034 HTTP-based Streaming and Download Services TR 26. InterDigital. Fraunhofer Gesellschaft.1. ST-Ericsson Related Work Item(s) (if any] Unique ID Title 470034 HTTP-based Streaming and Download Services Nature of relationship Feature 3GPP . RealNetworks. Nokia. Cisco. Ericsson. HuaWei.

1. To identify alternative solutions with their pros and cons to support the identified requirements. It might be beneficial for IRPManager to use identical/similar/same operation (to achieve some level of consistency) to obtain the two different kind of information.901 32.1 Study on version handling UID_470050 Resources: UID 470050 S5 Finish 12/09/2012 Comp 85% Hyperlink SP-100082 WI_rapporteur Ericsson Notes TR 32. registration & discovery).833 32. there is no standardised way to know which IRPVersion that a particular Managed Object (MO) instance belongs to. Huawei.1 (2012-06) 18 UID 47005 0 48004 7 49003 9 51004 5 SA5 Studies Name Study on version handling Study on Management of Converged Networks Study on User Data Convergence (UDC) information model handling and provisioning: Example Use Cases Study on OAM aspects of inter-RAT Energy Saving Acronym FS_OAM_VH FS_ManCon FS_UDC_AppUseCase FS_OAM_ES_iRAT WI_rapporteur Ericsson Nokia Siemens Networks Alcatel-Lucent Nokia Siemens Networks TR 32.830 32. There are a number of issues and inconsistencies with version handling in the current set of SA5 specifications (e. 3GPP . measurements and trace data. China Mobile.g. and how SOA may provide capabilities for a coherent version handling (e.g.834 18.830 Name Study on version handling Supporting Companies: Ericsson. Trace specifications). Issue 1: Network Resource Model (NRM) object version handling In today’s set of standard IRP specifications. 4 Objective To document current version handling in SA5 specifications To identify and agree on the use cases and requirements for a coherent version handling approach. Issue 4: SOA support As we have recently (Rel-9) introduced SOA (Service Oriented Architecture) for IRPs. Issue 2: Version handling of Interface IRPs versus NRM IRPs For IRPManager to obtain the IRPVersion(s) of an IRPAgent's supported Interface IRPs and supported NRM IRPs.204 Overview of 3GPP Release 11 V0. we should also study if and how the version handling can satisfy the needs of SOA. To agree on one of the proposed alternative solutions and document recommendations in the TR’s conclusions. Issue 3: Version handling of management information such as alarms. measurements and trace data Currently there is no version handling defined in SA5 for management information such as alarms. IRPManager needs different operations. one or more. Nokia Siemens Networks. The solutions may comprise rules in the IRP methodology documentation as well as enhancements of existing or new IRP specifications. IRP specifications. But if the IRPAgent supports more than one IRPVersion. there is support for an IRPManager to retrieve a list from the IRPAgent about which IRPVersion(s) (of the NRM IRP SSs) that the IRPAgent supports. while utilizing SOA capabilities. there is an information gap on Itf-N which needs to be filled. PM specifications. Thus. Alcatel-Lucent.

Motorola. Deutsche Telekom . All this leads to high CAPEX and OPEX. Ever increasing cost pressure requires reducing OPEX and CAPEX.1. wireless) (b) Management of converged networks Identify the main operational problems to be addressed and for which solutions should be provided Provide a high level solution proposal for each of the main problems identified above Identify SDOs and industry fora which should be involved in the work on convergence Set up the required relationships to the above identified bodies • It is not within the scope of this study to address harmonisation of management interfaces. A main challenge lies in the identification of the potential that can be leveraged by the new harmonized and converged management approach. Also the operations departments of the service providers operate today in a quite independent manner. Removal of these silos will provide solutions for management problems that cannot be addressed today. Nokia Siemens Networks. 3GPP . One possibility to do so is by common management of existing as well as converged networks. A new study on the PM Interface is under consideration as well. Instead a close cooperation with other relevant SDOs and industry fora is required. Additionally joint working groups have been formed to drive the work forward. Ericsson. Huawei. Identification of operational problems and their solutions: In today’s networks there is little or no interaction between the management silos for wireless and wireline management. this is addressed in dedicated study and work items. Orange. wireline. also this network as such needs to be managed. Common management of existing as well as converged networks is here defined by the following: • Harmonisation and alignment of management approaches: For harmonisation of generic model parts and FM Interface between TMF and 3GPP there are already two Study Items in place in 3GPP. Objective • o o • • • Develop use case for (a) Common management of existing multi-technology networks (e. ZTE. China Unicom. • • The challenges of convergence cannot be solved by 3GPP alone.833 Name Study on Management of Converged Networks Supporting Companies: Alcatel-Lucent.1 (2012-06) 18.g. Management of the converged network: As the network converges and allows for more services. Justification The management of fixed and mobile networks is currently structured along silos with different management approaches and little interaction between them.205 Overview of 3GPP Release 11 V0. Vodafone. PIWorks.2 Study on Management of Converged Networks UID_480047 Resources: UID 48004 7 S5 Finish 12/09/201 2 Comp 70% Hyperlink SP100377 WI_rapporteur Nokia Siemens Networks Notes SP#56 TR 32.833v100 for Information TR 32. As mentioned above.

Objective: Develop understanding. The Provisioning Gateway is shown supporting an interaction with the operator’s BSS.176. Orange. including TS 32. This study is proposed to analyze the progression of information models displayed on the left hand side of the above figure using some specific application examples. guidelines. The Provisioning Gateway (part of the UDR) provides a single logical point for access to provisioning of user data for all services in the UDR. which is essential for the operation of the UDR.141. and investigate how these Application data elements could be used to populate . standardized within 3GPP in such specifications as TS 23. Application Data Models (ADMs). there must be a relationship between the BSS interaction with the Provisioning Gateway and the SA5 specifications dealing with Subscription Management. 32. in particular the applications of HSS-IMS and MMTel.3 Study on UDC information model handling and provisioning: Example Use Cases UID_490039 Resources: UID 49003 9 S5 Finish 14/12/201 1 Hyperlink SP110127 WI_rapporteur Alcatel-Lucent Notes SP#54 completed TR 32. 3GPP . Although not stated in Release 9 of this specification. the Specialized Information Model (SpIM). These include the Common Baseline Information Model (CBIM).140. and the Consolidated Data Model (CDM) of the User Data Repository (UDR).206 Overview of 3GPP Release 11 V0.008.172. Application Information Models (AIMs). The investigation would proceed to examine the integration and consolidation of the AIM with example scenario SpIMs to produce new SpIMs.1 (2012-06) 18.1.172 especially for reuse by applications specified outside 3GPP. and preliminary requirements for the BSS provisioning capabilities and information model handling when new applications and related services are implemented in the operator’s UDR by doing the following: • • • • • • Develop several example initial SpIMs for discussion purposes Examine what BSS interactions with the Provisioning Gateway would be required to support provisioning of user service and subscription data in the UDR for these SpIMs Study the relationship to the information model of TS 32.172 Develop understanding of CBIM-derived entities of Application Information Models (AIM) for HSS-IMS and MMTel from application data elements available in TS 23.1-1 of TS 32. It is proposed to start with a list of Application Data Elements.181 Framework for Model Handling and Management discusses various types of information and data models associated with the architecture of User Data Convergence (UDC). this figure introduces the aspect of the Provisioning Gateway.CBIM-derived entities of an Application Information Model. In addition to the models previously mentioned.175 and 32.008 and TS 29. AT&T. by implication this interaction is associated with the provisioning of user subscription and service data in the UDR via the Provisioning Gateway. Consider Figure 8. 32. 32. This study also to provide preliminary findings concerning the requirements for the BSS interactions to the Provisioning Gateway as new applications become operational in the UDR and to explore the relationship between this interaction and the Subscription Management (SuM) Network Resource Model (NRM) Integration Reference Point (IRP) Information Service found in TS 32. China Mobile. TS 29. Focus on the progression of information models and resulting BSS provisioning implications as new applications and services are implemented in the UDR and do not seek to derive findings concerning the Ud reference point.172. Deutsche Telekom TS 32.181 showing the operational environment of the UDC.364.364 and other relevant standards Discuss the integration and consolidation of these AIM entities with the example initial SpIMs above Evaluate the potential changes to the BSS provisioning interactions for the implementation of HSS-IMS and MMTel applications in the UDR and implications concerning the information model of TS 32.901 Name Study on User Data Convergence (UDC) information model handling and provisioning: Example Use Cases Supporting Companies: Justification Alcatel Lucent.

1. TeliaSonera.551 Triggered by Rel-10 UID_430044 TR 32. Huawei.425. • Select information that should be used to decide if an energy saving cell shall enter or leave energy saving mode. o o 3GPP . The time frame for this study item is intentionally set very short. By initiating this Study and the intended follow-up implementation WI about OAM aspects of Inter-RAT Energy Savings. adapted or extended to fulfil these requirements or if a new IRP is needed. 32. based on the results of the study. e.762. But also for these a standardized Energy Saving Management functionality is required. Motorola.826 Study on Telecommunication Management. can be switched on again if traffic indicators shows higher traffic than typical in backing cell (potentially also other information can be used to decide if switching cell/s on can really bring benefits to the customer).767. 32. by several means such as limiting their networks' energy consumption. Ericsson. Vodafone.763.4 Study on OAM aspects of inter-RAT Energy Saving UID_510045 Resources: UID 51004 5 S5 Finish 14/12/201 1 Hyperlink SP110138 WI_rapporteur Nokia Siemens Networks Notes SP#54 completed. NEC. adaptations or extensions to IRPs may be considered but not limited to them:  LTE ES management functionality for Inter-RAT scenarios  Suitable traffic load measurements (potentially with short granularity periods)  Energy consumption measurements  “low consumption mode” of network resources  Adjust Network Resources Models SA5 is willing to cooperate with RAN WGs where needed. General scenario: There are two RAT layers. It is intended to create. our fight against global warming should be without respite. New elements in IRPs. SA5 up to now has defined Energy Saving Management functionality for LTE (OAM aspects of Energy Saving in Radio Networks (OAM-ES) UID_470037. ZTE UID 43004 4 47003 7 Related Work Item(s) (if any] Title Rel-10 Study on Telecommunication Management.765. when network redundancy is leveraged. energy costs are rising and form a growing share of the operational expenses of mobile network operators. Furthermore. This study will also involve InterRAT Energy Saving Management.g. As part of sustainable development. Alcatel-Lucent. 32. TR 32. Objective: • Identify the most important Inter-RAT energy saving scenarios and use cases • Identify OAM based concept and requirements for these use cases • Analyse how existing IRPs can be re-used. Orange. China Mobile.826 32. Nokia Siemens Networks.207 Overview of 3GPP Release 11 V0. SA5 hopes to contribute to the protection of our environment and the environment of future generations. China Unicom. Most mobile network operators aim at reducing their greenhouse emissions. Such definitions are not yet present for 3G and 2G mobile networks. o Use case 1: cells of the different RATs are collocated and have a similar coverage area o Use case 2: cells of one RATs are not collocated and have a significantly smaller coverage area than the other RAT Typically cells of the RAT working on higher frequency can be switched off / brought into lower energy consumption mode in low traffic periods. Energy Savings Management (FS_OAM_ESM) and UID_470037 OAM aspects of Energy Saving in Radio Networks (OAM-ES) Justification Sustainable development is a long-term commitment in which all of us should take part. Energy Savings Management Rel-10 OAM aspects of Energy Saving in Radio Networks Nature of relationship TR 32. new 32. within the Rel-11 time frame a dedicated work item for OAM aspects of Inter-RAT Energy Saving.834 Name Study on OAM aspects of inter-RAT Energy Saving Supporting Companies: Deutsche Telekom. 32.1 (2012-06) 18.

SA2 TS 23. Deutsche Telekom. Vodafone. Huawei Notes Linked to SP-110433 (LS on Equivalent PLMN identities and MDT) and Network Sharing UID_31018. ZTE 3GPP . Architecture and functional description) TR 32. Alcatel-Lucent.951 (Service aspects and requirements for network sharing). Huawei.x Study on management of Heterogeneous Networks UID_510046 (moved to Rel-12) Resources: UID 510046 S5 Acronym FS_OAM_HetNet Hyperlink SP-110140 WI_rapporteur Ericsson TR 32. ZTE. NEC.8xy Name Study on management of Heterogeneous Networks Supporting Companies: Ericsson. Teliasonera. Ericsson. NEC. Huawei.208 Overview of 3GPP Release 11 V0. Nokia Siemens Networks. SA1 TR 22. Orange.y Study on OAM aspects of Network Sharing UID_540032 (moved to Rel-12) Resources: UID 54003 2 S5 Acronym FS_OAM_SHARE Hyperlink SP110888 WI_rapporteur Alcatel-Lucent.1 (2012-06) 18.251 (Network Sharing.851 Name Study on OAM aspects of Network Sharing Supporting Companies: Alcatel-Lucent. Qualcomm 18.1. ETRI.

to document limitations. and consequently. with emphasis on mass effects in the UE-CN signalling.826 23. to analyze similar impacts from activation status of non-3GPP access networks. ES conditions. Defines Energy Savings Management OAM requirements and solutions Related Work Items Title SA5 Study on Telecommunication Management. Strong requirements from operators (for reasons of cost and environmental image) and indirectly from authorities (to meet international and national targets) have been formulated. to perform a corresponding analysis for connected mode UEs. thus a systematic study is needed. Vodafone. including home cell deployment and I-WLAN. to evaluate and give recommendations on potential enhancements to 3GPP specifications.1 Study on impacts on UE-Core Network signalling from Energy Saving UID_480015 Resources: UID 48001 5 C1 Finish 03/06/201 1 Hyperlink CP100330 WI_rapporteur NEC Notes CP#52 completed.826 Name Study on impacts on UE-Core Network signalling from Energy Saving Supporting Companies: UID 430044 (FS_OAM-ESM) 460016 (FS_Energy_UMTS) 470015 (FS_Energy_LTE) 470037 (OAM-ES) NEC. Infineon. Nature of relationship Studied energy saving requirements and solutions for several use cases (Completed 03/2010). Orange. address how to avoid service degradation. RAN1 UID_460016 (FS_Energy_UMTS) TR 24. 3GPP . in the form of HNB/eNBs. Linked to SA5 UID_430044 (FS_OAM-ESM) & UID_470037 (OAM-ES). It is unclear whether and how currently defined procedures are able to cope with. this aspect becomes even more crucial. Objective • • • • • • Service Aspects: to analyze UE idle mode procedures and UE-CN signalling resulting from frequent switch on/off of radio equipment in all 3GPP accesses.857 19. to study potential s and enhancements to these procedures. Deutsche Telekom. mass effects in signalling potentially endanger the network stability and need to be handled properly. in particular: • • the activation status of radio stations (on/off) introduces a new scale of dynamicity for the UE and network. RAN3 UID_470015 (FS_Energy_LTE).209 Overview of 3GPP Release 11 V0. Identifies potential solutions to enable energy saving within UMTS Node-Bs. of mobile networks.1. and eventually can be optimized for. and does a light initial evaluation of the proposed solutions. Energy Savings Management (ESM) RAN1 Study on Solutions for energy saving within UTRA Node B RAN3 Study on Network Energy Saving for EUTRAN SA5 OAM aspects of Energy Saving in Radio Networks Energy Saving mechanisms are becoming an integral part of radio networks. It is necessary to ensure that ES does not lead to service degradation or inefficiencies in the network. potentially resulting from ES mechanisms. Studies Inter-RAT and inter-eNB energy saving mechanisms from RAN perspective (in addition to what was already specified in Rel-9). weaknesses and inefficiencies in these procedures. With the expected masses of mobile network radio equipment as commodities.1 (2012-06) 19 UID 48001 5 49001 4 CT Studies Name Study on impacts on UE-Core Network signalling from Energy Saving Study on EPC Nodes Restoration Acronym FS_UECN_ES FS_EPC_NR Resource C1 C4 WI_rapporteur NEC ZTE TR 24.

but occasional restart or failure due to various reasons may be unavoidable.1 (2012-06) 19.210 Overview of 3GPP Release 11 V0. This study item proposes to study the behaviour of nodes in EPS upon restart/failure of network elements or failure of the communication links between them. NEC. and analyze solutions that ensure no degradation of the service to the UE. Cisco. In order to resolve such problem. Continue work in Rel-11 especially to cover handling of Idle mode Signalling Reduction (ISR). China Mobile. Ericsson. CATT. complexity) 3GPP . Although in Rel-8 and Rel-9 there are basic mechanisms for the node recoveries and restorations.857 Name Study on EPC Nodes Restoration Supporting Companies: DoCoMo.1. SGW and PGW identify precisely the problems resulting from the current definition of the standards analyze possible solutions conclude on potential enhancements to the standards (depending on gains vs. NTT The node in the EPS should have the high reliability. China Unicom. problems were found with these mechanisms especially the case where the IMS is introduced and an EPC node such as MME has restarted (in such case. it is needed to perform a further feasibility study of the possible enhancements for existing mechanisms and/or new mechanism to make sure the EPS network can provide reliable service. the connectivity between the nodes can also cause additional problems.2 Study on EPC Nodes Restoration UID_490014 Resources: UID 490014 C4 Acronym FS_EPC_NR Resource C4 Finish 07/09/201 2 Comp 90% Hyperlink CP100700 WI_rapporteur ZTE Notes CP#56 completion 06/12=>09/12. Linked to SA2 UID_490036 Study on Core Network Overload solutions TR 23. SGSN. the call cannot be received for UE for which the restarted EPC node served). When looking at the network. ZTE Justification Alcatel-Lucent. Objective: to consider any necessary operational protocol recovery mechanisms in the EPS in order to achieve end to end system recovery by addressing the following points: • • • • list the different network failure scenarios to be analyzed for EPC nodes: MME.

4 Objective • Study GERAN enhancements for GERAN to improve the support for MTC considering their specific requirements and optimization categories identified by SA1 3GPP . Whenever any MTC device is visible from the network. To fully support the SA1 service requirements and optimization categories. Vodafone.802 20.1.1 (2012-06) 20 UID 46000 1 48000 3 49000 6 52000 1 52000 2 GERAN Studies Name Study on GERAN improvements for Machine-Type Communications Study on Signal Precoding enhancements for EGPRS2 DL Study on Solutions for GSM/EDGE BTS Energy Saving Study on Voice services over Adaptive Multi-user channels on One Slot (VAMOS) enhancements Study on GERAN enhancements for Mobile Data Applications Acronym FS_NIMTC_GERAN FS_SPEED FS_Energy_BTS FS_eVAMOS FS_GERAN_eMDA Resource G1. The "Group based system optimization category" identified in TS 22. it is anticipated that group paging issues and new group broadcast mechanisms as well as optimised access procedures are studied. This opens up opportunities to define a "Thin Modem" specification or a collection of modem types (e.G2 Acronym FS_NIMTC_GERAN Finish 31/08/201 2 Comp 60% Hyperlink GP092418 WI_rapporteur Ericsson Notes GP#54 TR 43. low data usage (CS or PS) and extra link budget for weather/theft/vandalism proofing (e. flexible ultra-low duty cycle.868 v100 for Information. heavily shielded antenna). it is necessary to study GERAN technical enhancements needed for supporting MTC.368 indicates area of improvement in the ability of the system to efficiently serve MTC applications that relate to a group of MTC devices.368 to list Service requirements and optimization categories for Machine-Type Communications (MTC) in Rel-10. Deutsche Telekom. Another important issue is how the large number of MTC will influence the GERAN performance.G2 G1. MTC device addressing formats. and in order to improve efficiency in GERAN to handle MTC.1 Study on GERAN improvements for Machine-Type Communications UID_460001 Resources: UID 46000 1 G1.g. Vodafone China Mobile. ST-Ericsson. ZTE. Completion 05/12=>08/12 .G2. The TS is considered stable as of Aug 2009.868 GERAN 45. LG Electronics.G1 WI_rapporteur Ericsson Ericsson Nokia Siemens Networks. Most MTC devices are expected to require low data bandwidth and to be either of the Mobile Originated or Mobile Terminated type. power saving mechanisms for several M2M application scenarios.g.211 Overview of 3GPP Release 11 V0.G2 GP.860 GERAN 45.G2 G1. MTC applications may involve the deployment of a group of MTC devices that are owned and operated by a single MTC customer and as such the MTC customer and the MNO may treat the group as a single entity (individual MTC devices are not visible from the network and no group optimization is foreseen in such a case).868 Name Study on GERAN improvements for MachineType Communications Supporting Companies: China Mobile. Telecom Italia. Motorola.8xy GERAN 43. Ericsson. Samsung. GP#44 approved WID TR GERAN 43. Some examples for optimising GERAN for MTC devices are radio resource allocation methods for a large number of Machines in the same cell with low/no mobility. Justification SA1 has created TS 22. broadcast only devices are MT only). Huawei.926 GERAN 45.G1 G2. Huawei Huawei TR GERAN 43. Research in Motion.

occasional active use. Impacts of radio interference due to the large number of MTC devices in a cell shall be investigated. Identify potential opportunities in specifying "Thin Modem" device types for MTC. device addressing formats.1.1 (2012-06) • • • • • • • Study the bounds on the number of possible MTC devices that can be supported in a GERAN cell and possible impact on the RACH capacity. etc. Study ways to reduce signalling latency and minimise user plane data overhead Study ways to provide prioritisation/deprioritisation of MTC device communication in the RAN Study ways to distribute the loading (signalling and data) created by MTC device communication to avoid signalling/traffic spikes in the RAN 3GPP . etc. optimised for minimal data only applications with no mobility support. low latency impacts and possible MO only or MT only devices. Investigate ultra low power MTC devices: prolonged period between transmission/reception.212 Overview of 3GPP Release 11 V0. Study GERAN enhancements which enable or improve efficient use of RAN resources and/or which lower complexity when a large number of MTC devices are served. channel capacity. Evaluate possible network architectural changes to support Broadcast/Group Paging enhancements.

860 Name Study on Signal Precoding enhancements for EGPRS2 DL Supporting Companies: Unique ID 50121 Ericsson. 3GPP . Performing precoding of EGPRS2 modulated data is expected to increase robustness of the system significantly while keeping all spectral properties of the signal intact. allowing significant increase to both data capacity and spectral efficiency for EGPRS2. Furthermore. China Mobile.1 (2012-06) 20.1. Justification The concept of Precoded EGPRS2 DL has recently shown to provide significant performance gains for EGPRS2. Telecom Italia. GP#46 approved WID. Huawei. ST-Ericsson. to evaluate the possible gains with Precoded EGPRS2 compared to realistic EGPRS2 performance. DAS-5 to 12 and DBS-5 to 12 respectively. Vodafone. Gains are expected both in interference and sensitivity limited scenarios. • to investigate possible enhancements in burst formatting by e.213 Overview of 3GPP Release 11 V0. • to keep all channel coding definitions of EGPRS2 intact. i.G2 Finish 02/03/201 2 Hyperlink GP111281 WI_rapporteur Ericsson Notes GP#53 completed (03/12). modifying the placements of the training sequence symbols in the burst and changing the mapping of bits onto modulation symbols within a burst.g. DAS-12 and DBS-12 for EGPRS2-A and EGPRS2-B respectively.e. i. TR GERAN 45. Objective • to investigate the feasibility of using the Discrete Fourier Transform (DFT) precoder for EGPRS2-A and EGPRS2-B DL specific modulation and coding schemes. • to minimize hardware impact on base station and mobile station. except for the highest MCS of each set. In addition all channel coding definitions will be kept intact except for DAS-12 and DBS-12 where additional enhancements are to be investigated. • • to investigate possible techniques to reduce Peak-to-Average Ratio (PAR) for Precoded EGPRS2 DL. this technique allows reducing receiver complexity for EGPRS2 considerably. ZTE.G2 Acronym FS_SPEED Resource G1. Related Work Item(s) (if any] Title Nature of relationship REduced symbol Duration.2 Study on Signal Precoding enhancements for EGPRS2 DL UID_480003 Resources: UID 48000 3 G1. Higher Order modulation Modulation and coding schemes from the RED HOT study and Turbo coding (REDHOT) are used as basis in this study item work.e.

China Mobile. Due to the need to reduce energy consumption within operators’ networks. cell (re-)selection performance. Nokia Siemens Networks. Ericsson Justification Vodafone. such that a subset of these proposals can be used as the basis for further investigation of their feasibility.1. and considering the large amount of GSM/EDGE network equipment deployed in the field around the world. notably MCBTS. solutions that are non-backwards compatible towards legacy mobile stations shall be out of the scope of this study). Vodafone Notes GP#54 completion 05/12=>08/12. Impacts on UL/DL coverage balance. the standardisation of methods to save energy in BTS is seen as an important area of study for 3GPP. due to reduction in DL power. handover performance. DTM and packet transfer mode Deactivation of cells (e.e. Alcatel-Lucent.214 Overview of 3GPP Release 11 V0.g. There has not been a large amount of focus on energy-saving in GSM/EDGE networks so far in 3GPP. Cell Power Down and Cell DTX like concepts as discussed in RAN) Deactivation of other RATs in areas with multi-RAT deployments.926 Name Study on Solutions for GSM/EDGE BTS Energy Saving Supporting Companies: Huawei. especially to CS voice Solutions shall be considered for both BTS energy saving non-supporting and supporting mobile stations (i. Objective: to study potential solutions enabling energy saving within the BTS (including MCBTS and MSR) by: • • • • • • Reduction of Power on the BCCH carrier (potentially enabling dynamic adjustment of BCCH power) Reduction of power on DL common control channels Reduction of power on DL channels in dedicated mode. Telecom Italia. GP#47 approved WID TR GERAN 45. where the mobile station could assist the network to suspend/minimise specific in-use RATs at specific times of day And any other radio interface impacted power reduction solutions. e.3 Study on Solutions for GSM/EDGE BTS Energy Saving UID_490006 Resources: UID 49000 6 G1. 3GPP .G2 Acronym FS_Energy_BTS Finish 31/08/201 2 Comp 80% Hyperlink GP101638 WI_rapporteur Nokia Siemens Networks.g. for example. although some solutions have been agreed in previous Releases. ZTE. Therefore it is proposed to start an initial study phase to identify solutions and perform any initial evaluation. etc.1 (2012-06) 20. The solutions identified in this study item shall also consider the following aspects: • • • • Impacts on the time for legacy and new mobile stations to gain access to service from the BTS Impacts on legacy and new mobile stations to keep the ongoing service (without increasing drop rate) Impacts on legacy and new mobile stations implementation and power consumption.

Objective: study to improve the call quality of paired mobiles and non-paired mobiles by optimizing radio resource management mechanisms for VAMOS to investigate network improvements utilizing network synchronization.215 Overview of 3GPP Release 11 V0. GP#50 approved WID. ZTE.4 Study on VAMOS enhancements UID_520001 Resources: UID 52000 1 GP.G1 Acronym FS_eVAMOS Finish 23/11/201 2 Comp 30% Hyperlink GP110991 WI_rapporteur China Mobile. Huawei Notes GP#54 completion 05/12=>11/12.8xy Name Study on Voice services over Adaptive Multiuser channels on One Slot (VAMOS) enhancements Supporting Companies: China Mobile. Ericsson Nature of relationship Rel-8 Study item Rel-9 Work item Related Work Item(s) (if any] UID Title 50590 Multi-User-Reusing One Timeslot (MUROS) 420002 Voice services over Adaptive Multi-user channels on One Slot (VAMOS) Justification VAMOS has been specified as a Rel-9 feature and was expected to theoretically double the voice capacity of GERAN per BTS transceiver.1 (2012-06) 20. such as radio resource management and interference coordination/mitigation mechanisms. Triggered by Rel-8 TR 45. Capacity gains of VAMOS have however been seen from system level simulations to vary significantly depending on the frequency load of the network.1.914 Study Multi-UserReusing One Timeslot (MUROS) UID_50590 and Rel-9 VAMOS UID_420002 TR GERAN 45. Call quality in the network may rely upon factors which were not modelled/covered in the MUROS study. 3GPP . to avoid any impact on Core Network to avoid any impact on base station hardware to avoid any impact on mobile station . Hence it is desirable to explore standardization ways in these and/or other possible areas to optimize the call qualities of VAMOS networks.G2. In networks with relatively high frequency load the possible system capacity increase brought by VAMOS could thus result in degraded call quality. Vodafone. Nokia Siemens Networks. Huawei. including the use of inter-cell interference coordination/mitigation and inter-cell channel state sharing in and between BSS.

push services etc. this study aims to consider the following objectives: o o o Study and identify the relevant traffic profiles from GERAN perspective for the mobile data application of human communication.802 Name Study on GERAN enhancements for Mobile Data Applications Supporting Companies: Huawei. GERAN needs to study and identify the impacts from these applications on existing mechanisms and potentially consider new mechanisms (if required) to ensure that networks can cope with this traffic and make efficient usage of the available resources while meeting the above-mentioned performance requirements. HTTP/WAP browsing. etc .1. The increase of mobile data has introduced new challenges to mobile networks. it is essential to ensure that the user experience for these applications should be either improved or maintained. challenges to the mobile network increase as the total amount of related traffic is increasing significantly. Telecom Italia. IM chatting. characteristics of the traffic also pose problems to networks: for example. GP#50 approved WID. and minimizing battery consumption. increases (and are more frequently used in parallel).g. Objective: In order to make the GERAN network better suited for mobile data applications used on multi-tasking capable mobile stations. and social network. Triggered by RAN#51 (Mar 2011) WID in RP-110454 (LTE RAN Enhancements for Diverse Data Applications) UID_510031 TR GERAN 43. social network services. mobile networks have experienced a significant increase of mobile data. As well as the performance requirements. China Mobile.216 Overview of 3GPP Release 11 V0.) in quick succession at the application layer currently may result in rapid transitions in the access network from idle to active and vice versa. Ericsson.5 Study on GERAN enhancements for Mobile Data Applications UID_520002 Resources: UID 52000 2 G2. Study the impact on GERAN network based on the identified traffic profiles.G1 Acronym FS_GERAN_eMDA Finish 31/08/201 2 Comp 35% Hyperlink GP110999 WI_rapporteur Huawei Notes GP#51 completion 03/12=>08/12 (mobile coucou). Nokia Siemens Networks. resource utilization etc. However. sequences of frequent short transmissions from the same mobile (such as from IM. Alcatel-Lucent Related Work Item(s) (if any] UID Title 51003 LTE RAN Enhancements for Diverse Data 1 Applications Nature of relationship RAN WI started RP#51 Mar 2011 (RP-110454) Justification In recent years. As a result. HTTP/WAP browsing services (including streaming). while ensuring efficient use of network resources (considering signalling efficiency.g. Renesas. etc. e. Research in Motion. Vodafone. compared with the user experience today. ZTE. HTTP/WAP browsing (including streaming). IM chatting. Study enhancements to alleviate the impacts from these traffic patterns on the current GERAN networks (if any) with regards to: 3GPP . Diverse mobile applications are introduced by machine type communication and human type communication.).1 (2012-06) 20. As the usage and range of applications used today for human communication. status updates etc. e. such as IM chatting. social network service. ST-Ericsson.

1. 3GPP .217 Overview of 3GPP Release 11 V0.1 (2012-06) o o o o Radio resource utilization Signalling procedures RR states and transition between them Battery lifetime The identified enhancements to better handle the mobile data application should not impact the CS services.

KDDI.839 LTE 36.902 21. MediaTek.888 LTE TR 36.signalling assumptions and related delay for the information exchange between the participating cells. CHTTL.R3. new TR 37. and also to increase system throughput.218 Overview of 3GPP Release 11 V0. Huawei. CATR. Deutsche Telekom. Orange.R2.R1.816 LTE 36.914.R2.824 LTE TR 36. Research In Motion. China Mobile. CATT.R4 R1. ZTE Justification Coordinated Multi-Point (CoMP) transmission and reception has been considered for LTE-Advanced as a tool to improve the coverage of high data rates.R4 R4.836 LTE TR 36.1 Study on Coordinated Multi-Point operation for LTE UID_470014 Resources: UID 47001 4 R1. the cell-edge throughput. NTT DOCOMO. Qualcomm.R2. Alcatel-Lucent Shanghai Bell. Samsung. Fujitsu.R1. Motorola Mobility. SK Telecom. The LTEAdvanced study showed different performance results depending on whether the serving cell is the only transmission point (coordinated scheduling/beamforming) or multiple cells including the serving cell serve simultaneously as transmission points (joint transmission) whether the cells participating in the CoMP operations belong to the same eNodeB or different eNodeBs assumptions on CSI-RS measurement as well as the accuracy and nature of the CSI feedback for multiple cells participating in the CoMP operation assumptions on uplink sounding and channel reciprocity . Hitachi. Motorola.819 Name Study on Coordinated Multi-Point operation for LTE Supporting Companies: Alcatel-Lucent. ITRI.828 LTE TR 36.829 LTE new TR LTE 25. Nokia Siemens Networks. Pantech.R3 R2. Ericsson.R2 R3. LG Electronics.R4 R4 R2. Mitsubishi Electric. HTC.R3 Acronym FS_CoMP_LTE Finish 16/09/201 1 Hyperlink RP101425 Status_Report RP-111343 WI_rapporteur Samsung Notes RP#53 completed TR LTE 36.819 LTE 36.1 (2012-06) 21 UID 47001 4 48002 8 50001 6 51003 4 51003 7 51003 9 53005 2 53005 3 53005 4 53005 5 55002 0 55002 2 LTE Studies Name Study on Coordinated Multi-Point operation for LTE Study on Signalling and procedure for interference avoidance for in-device coexistence Study on Inclusion of RF Pattern Matching Technologies as a positioning method in the E-UTRAN Study on HetNet mobility enhancements for LTE Study on further Downlink MIMO enhancements for LTE-Advanced Study on Further Enhancements to LTE TDD for DL-UL Interference Management and Traffic Adaptation Study on Provision of low-cost MTC UEs based on LTE Study on LTE Coverage Enhancements Study on Mobile Relay for E-UTRA Study on Enhanced performance requirement for LTE UE Study on LTE-HRPD (High Rate Packet Data in 3GPP2) inter-RAT SON Study on Measurements of radio performances for LTE terminals .R4 R1 R1. Panasonic.R2.1.871 LTE 36.809 LTE 36.R1 R3 R4 WI_rapporteur Samsung China Mobile Polaris Wireless Alcatel-Lucent Alcatel-Lucent CATT Vodafone China Telecom CATT NTT DoCoMo China Telecom CATR TR LTE 36. 3GPP . ST-Ericsson. Nokia.Total Radiated Power (TRP) and Total Radiated Sensitivity (TRS) test methodology Acronym FS_CoMP_LTE FS_SPIA_IDC FS_LCS_LTE_RFPMT FS_HetNet_eMOB_LTE FS_LTE_eDL_MIMO_enh FS_LTE_TDD_eIMTA FS_LC_MTC_LTE FS_Cov_Enh_LTE FS_LTE_mobRelay FS_enh_perf_UE_LTE FS_LTE_HRPD_SON FS_LTE_OTA Resource R1. NEC.R4 R1.

considering possible antenna configurations.219 Overview of 3GPP Release 11 V0.1 (2012-06) The performance evaluation in LTE-Advanced spent considerable effort on CoMP for homogeneous macro networks while newer deployment types such as cells with distributed Remote Radio Heads (RRHs) and heterogeneous networks received less attention. network synchronization accuracy. The detailed objectives are as follows: Consider whether further refinements to the simulation assumptions from the agreements reached during the LTE-Advanced study item are needed to align with potential deployment scenarios. spatial domain inter-cell scheduling and/or interference coordination.. if possible. and other cooperation methods. Recommend way forward on actual design principle with its related scenario(s) for the high capacity/low latency inter-point communication and. 3GPP .1. Develop simulation assumptions for the case of having high capacity and low latency communication between transmission points 2. and achievable performance benefit should be evaluated and taken into account.and intra-site CoMP in homogeneous macro networks o Coordination between a cell(s) and the distributed RRHs connected to the cell(s): negligible latency is assumed over the interface between a cell(s) and the RRHs connected to the cell(s). Evaluate applicability of X2 for different CoMP modes/schemes (e. Identify potential enhancements for DL-CoMP operation (relating to JP and/or CB/CS) in the following areas: o Control signalling and procedures on Uu and network internal interfaces o UE feedback of downlink channel state information for multiple cells configured in the CoMP operation. The RRHs may or may not form separate cells from the cell to which they are connected. Evaluate constraints from lower capacity/higher latency communication between transmission points (including applicability and impact of these constraints) on performance gain of schemes/modes. - - - Detailed work plan is as follows: 1. and coordination capability including centralized or distributed scheduler assumption and their message exchange data rate and latency Evaluate the performance benefits of CoMP operation and the required specification support for the following scenarios: o Inter. While the potential of CoMP was recognised during the LTE-Advanced study and it was agreed that CSI RS design in Rel-10 should allow for accurate inter-cell measurements. data traffic model. develop corresponding simulation assumptions 3.g. provide clear view on what will happen with extension to the lower capacity/higher latency inter-point communication Trade-off between the limit to the feedback overhead. joint processing) 4. e. which may be related to certain feedback schemes. The coordination between amongst different o Coordination between different cell layers and within a cell layer in heterogeneous networks: coordination is performed between a macro cell(s) and small cells in the coverage of the macro cell(s). Objective: CoMP study shall cover both intra-eNodeB as well as inter-eNodeB CoMP. and include investigation of spatial domain cooperation. o Uplink sounding Identify potential standardization impact for UL-CoMP operation and evaluate its performance benefit. The small cells may be non-uniformly distributed in the coverage of a macro cell(s).g. consideration of further studies of the performance benefits and the standardization impact of enhanced CoMP operation was recommended in R1-101599.

Deutsche Telekom.816 Name Study on Signalling and procedure for interference avoidance for in-device coexistence Supporting Companies: China Mobile. Verizon. a terminal filter is difficult to provide sufficient rejection on the adjacent frequencies. LG Electronics. Furthermore. CATT. It should be noted that the guard band required is double the GPS carrier bandwidth which impact large GPS bandwidth systems such A-GNSS and Compass and also GPS Currently.1. Hence. it is necessary to study alternative solutions other than single generic RF design to solve the interference problem for the in-device case. Compass the spectrum allocation to these services continues to increase. Whether or not existing RRM procedures could well handle such kind of interference and guarantee required QoS needs to be evaluated. Samsung. some mechanisms specified in LTE could be utilized to detect and avoid interference. ZTE.harmonic frequency. b) LTE and Global position systems With the rapid increase in number and type of GPS systems. The detailed objectives are as follows: 3GPP . Scientific and Medical (ISM) Radio within the same device working in adjacent frequencies TR LTE 36. enhanced signalling procedures or resource sharing/re-allocation mechanisms are promising to better mitigate or avoid the interference.R4 Acronym FS_SPIA_IDC Finish 16/09/201 1 Hyperlink RP100671 Status_Report RP-111057 WI_rapporteur China Mobile Notes RP#53 completed. a) LTE and ISM (Bluetooth and WLAN) technologies When LTE and ISM radio within the same device works on adjacent frequencies (e. Motorola. it is necessary to study alternative solutions other than single generic RF design to solve the interference problem for the in-device case. due to activation of ISM/GPS device. inter-frequency/inter-RAT handover. Hence. AGNSS. especially the interference to the LTE receiver caused by ISM transmission. Sprint. if needed. Therefore. It is identified by RAN4 that with current state-of-the-art filter technology. i. Nokia. RLF monitoring and connection reestablishment. GPS.1 (2012-06) 21. NII Holdings. Nokia Siemens Networks. CATR. Objective: focus on the coexistence scenario that LTE and GPS/ ISM radio within the same device working in adjacent frequencies or sub-harmonic frequencies. Investigate suitable mechanisms for interference avoidance from signalling and procedure point of view. MediaTek. for in-device case the LTE radio is aware of the cause of interference. Studied coexistence scenario of LTE and Industrial. When LTE and GPS radio within the same device will cause interference due to adjacent operation or harmonics which cannot be avoid by allocating a guard band at the sub.2 Study on Signalling and procedure for interference avoidance for in-device coexistence UID_480028 Resources: UID 48002 8 R2. cell (re)selection. 3 Justification The growing market of smart connected devices demands that the same device supports multiple radio technologies. CHTTL. Clearwire. Scientific and Medical (ISM) Radio within the same device working in adjacent frequencies.e. Study coexistence scenario of LTE and Industrial. such as RSRQ measurement.220 Overview of 3GPP Release 11 V0. LTE working on upper part of Band 40 (2300-2400MHz)) such kind of coexistence will cause the interference. Some examples are. To investigate suitable mechanisms for interference avoidance from signalling and procedure point of view to facilitate the abovementioned coexistence scenario. Huawei. ST-Ericsson. Qualcomm. Alcatel-Lucent. differing from other coexistence scenarios. RAN4 has studied the coexistence issues between ISM technologies and LTE deployed in the adjacent bands.g. Ericsson.

1. • 3GPP . • If legacy signalling and procedure are not sufficient to ensure required performance in the interested coexistence scenario. RAN4 should analyse the solutions RAN2 has identified to verify the effectiveness of these solutions.1 (2012-06) Evaluate whether existing RRM mechanisms could be utilized to effectively solve the coexistence problems that arise in supporting the scenarios abovementioned and guarantee the required QoS in LTE with proper GPS/ISM operation. • Impact on legacy LTE UEs should be minimized. study enhanced mechanisms to better avoid interference and mitigate the impact caused by ISM radio.221 Overview of 3GPP Release 11 V0.

Stoke Incorporated. Agilent. Objective: to evaluate the use of measurements for positioning.1. The technology should be supported in LTE to allow current service providers to maintain their LCS capabilities as they migrate their networks to LTE.1 (2012-06) 21. Andrew Corporation. which are currently specified for UE and eNodeB for other purposes but are not currently included in LPP and LPPa. Thales-Alenia.3 Study on Inclusion of RF Pattern Matching as a positioning method in the E-UTRAN UID_500016 Resources: UID 50001 6 R4 Finish 07/12/201 2 Comp 55% Hyperlink RP120885 Status_Report RP-120583 WI_rapporteur Polaris Wireless Notes RP#56 completion 06/12=>12/12. TruePosition. Emergency location services and for Government Lawful Intercept applications. Alcatel-Lucent.222 Overview of 3GPP Release 11 V0.809 Name Study on Inclusion of RF Pattern Matching Technologies as a positioning method in the E-UTRAN Supporting Companies: Polaris Wireless. The implementation could be an E-SMLC based eNodeB-assisted location service using existing E-UTRAN measurements which are provided to the E-SMLC via the LPPa positioning protocol and UE-assisted location service using existing UE measurements (RSRP. for an RF Pattern Matching positioning technology in LTE. Linked to Rel-10 WI on Inclusion of RF Pattern Matching Technologies as a positioning method in the UTRAN (LCS_UMTS_RFPMT) UID_460005 TR LTE 36. RF Pattern Matching is an excellent complement to A-GPS because it is not a purely time-based geometrical location method. This study item is intended to complement already standardized location methods and existing location work items. RSRQ and UE Rx-Tx time difference only) which are provided to the E-SMLC via LPP positioning protocol. Updated WID RP110385=>RP-120885. BMWi Related Work Item(s) (if any] UID Title 46000 Inclusion of RF Pattern Matching Technologies as a positioning method in the UTRAN 5 (LCS_UMTS_RFPMT) Nature of relationship Rel-10 UMTS WI Justification RF Pattern Matching technologies have been utilized for location in GSM and UMTS networks worldwide for commercial location services. AT&T. The RFPM performance with these measurements will be compared to the RFPM performance based on the measurements currently specified for the ECID location method. This provides enhanced accuracy performance in high multipath environments like the dense urban core and building interiors. 3GPP .

Motorola Solutions. Finally.g. and therefore additional re-establishment procedures could help improve the overall system robustness.4 Study on HetNet mobility improvements for LTE UID_510034 Resources: UID 51003 4 R2. mobility for HeNBs with carrier aggregation has not been addressed in Rel-10.R1. Nokia. to ensure good solutions for avoiding high-mobility users on small BTS layer. and vice versa.R3. Evaluate performance benefits of enhanced UE mobility state estimation and related functionalities. LGE.839 Name Study on HetNet mobility enhancements for LTE Supporting Companies: Nokia Siemens Networks. This may cause some unfortunate effects in HetNet scenarios. shall be supported to enable offload benefits. Identify and evaluate strategies for improved small cell discovery/identification..1 (2012-06) 21. Research In Motion. RAN4) • Further study and define mobility enhancements for Home eNodeBs with multiple carriers (or CA) with CSGs (potentially different CSG on different carriers) (RAN2. KDDI. Today autonomous UE mobility state estimation is based purely on number of experienced cell changes.223 Overview of 3GPP Release 11 V0. RAN3) • Robust mobility functionality under various supported assumptions for the availability of UE measurements (including DRX functionality) shall be ensured/taken into account as well as UE power consumption and complexity (RAN2. so it is suggested to study related improvements. and is thus considered as a topic for Rel-11. Scenarios with more BTS-layers and multiple carriers also means that there are more potential error cases. CATT Justification Seamless and robust mobility of users from LTE macro to small BTS-layer.1. (RAN2. e. (RAN2) • Identify and evaluate HetNet mobility performance under established Rel-10 eICIC features e.g.R4 Finish 07/09/201 2 Comp 85% Hyperlink RP110709 Status_Report RP-120584 WI_rapporteur Alcatel-Lucent TR LTE 36. and other possible mobility solutions to take different cell-sizes into account. RAN3) 3GPP . and is therefore recommended to be studied in more details – especially for case where cells are on different carriers. but without explicitly taken the cell-size into account. Efficient small cell discovery is important to ensure efficient offload from macro to small cells. RAN1 if requested by RAN2) • Further study and define automatic re-establishment procedures that can help improve the mobility robustness of HetNet LTE networks. Almost Blank Subframe (RAN2. Objective: • to consider both network centric solutions and possible UE assisted enhancements. Intel. Alcatel-Lucent.

China Unicom. Panasonic.1. Texas Instruments. Ericsson. KDDI.1 (2012-06) 21. Verizon Wireless. US Cellular. Qualcomm. Telefónica. Nokia Siemens Networks. NTT DOCOMO.x Study on Enhanced Uplink Transmission for LTE UID_510035 (RP#56 stopped) Resources: UID 51003 5 R1 Hyperlink RP120259 Status_Report RP-120585 WI_rapporteur Huawei Notes RP#56 stopped. Research In Motion. CATT.Study on Enhanced Uplink Transmission for LTE Supporting Companies: Huawei. CHTTL. ZTE.8xy Name Deleted . China Telecom. HiSilicon. Orange 3GPP . Nokia. Alcatel-Lucent Shanghai Bell. LGE. CATR. Clearwire. Intel. CHT. RP-120856 discussion: most content moved to Rel-11 Coordinated Multi-Point Operation for LTE – Uplink (COMP_LTE_UL) and RAN1 has no time to look at it TR LTE 36. Alcatel-Lucent. ST Ericsson. Samsung. Motorola Mobility. CMCC. Mitsubishi Electric.224 Overview of 3GPP Release 11 V0.

LG Uplus.e. Nokia. the need to enhance performance also for non-uniform network deployments (e. HiSilicon. open-loop MIMO enhancements were briefly mentioned but not thoroughly investigated in Rel-10. In many deployment scenarios. especially for MU-MIMO.871 Name Study on further Downlink MIMO enhancements for LTEAdvanced Supporting Companies: Alcatel-Lucent. Objective: − o o With first priority: Evaluate issues from real-life network deployments of MIMO. and evaluate such enhancements. LG Electronics. ST-Ericsson. low-power nodes (including indoor). In addition. heterogeneous deployment) has grown.5 Study on further Downlink MIMO enhancements for LTE-Advanced UID_510037 Resources: UID 51003 7 R1 Finish 09/12/201 1 Hyperlink RP111366 Status_Report RP-111550 WI_rapporteur Alcatel-Lucent Notes RP#54 completed TR LTE 36. It would therefore be beneficial to study and optimize the MIMO performance for non-uniform deployments where the channel conditions especially for low-power node deployments might typically differ from what is normally encountered in scenarios considered so far. and including geographically-separated antennas i. For the 8-tx antenna case.1. For example. In addition the impact of calibration error on the performance could be discussed. HTC.g. Intel. the CSI feedback to support downlink MIMO has been enhanced with a new dual-codebook structure aimed at improving CSI accuracy at the eNB without increasing the feedback overhead excessively. It is therefore worth studying further potential enhancement for MU-MIMO. Motorola Mobility. Samsung. SK Telecom. Huawei. MU-MIMO operation is considered by many network operators as important to further enhance system capacity. The enhancement of MIMO performance through improved CSI feedback for high priority scenarios not directly targeted by the feedback enhancements in Release 10.225 Overview of 3GPP Release 11 V0. LG-Ericsson. macro-node with low-power RRHs). Furthermore. which includes UE CSI feedback enhancement and control signalling enhancement. it can be discussed if robust rank adaptation works properly in practice with current UE procedures that allow a single subframe of data to determine the rank. Alcatel-Lucent Shanghai Bell.  • • 3GPP . It would be beneficial to discuss the experience from commercial MIMO deployments. including: Identify and evaluate techniques for CSI feedback accuracy enhancement. the experience from real-life deployments in the field has increased significantly since Rel-8. Research In Motion. ETRI. Nokia Siemens Networks. and practical antenna configurations (especially 4 tx. CATT. less than 8 tx antennas will be employed.1 (2012-06) 21. Clearwire. modification or update may be included. Recently. including: Evaluate UE CSI feedback enhancements. relay backhaul scenarios. NEC. Ericsson. It is important to focus on the eNB antenna configurations of highest priority for network operators. in both homogeneous and heterogeneous scenarios should be studied. AT&T. Downlink MIMO in LTE-Advanced has been enhanced in Release 10 to support 8-layer SU-MIMO transmission and dynamic SU-MU MIMO switching. Verizon Wireless Justification The Rel-8 MIMO and subsequent MIMO enhancements in Rel-10 were designed mostly with homogenous macro deployment in mind. applicable to nonuniform network deployments. Pantech. China Mobile. This work will allow 3GPP to keep MIMO up to date with latest deployments and experience. especially the case of 4 tx antennas in a cross-polarised configuration. allowing arbitrary precoders to be used by the eNB for transmission. Panasonic. CHTTL. considering different environments and deployment scenarios. Identify the need for DL MIMO enhancements. and identify if there are any potential shortcomings and possible ways to address those. Precoded reference symbols are provided for data demodulation. New codebooks or techniques for codebook selection. US Cellular.

evaluate possible enhancements for demodulation RS for MIMO. including open loop MU-MIMO operation o Within the constraint of not introducing new antenna ports. Reuse of existing feedback frameworks should be considered if possible. Priority should not be given to re-visiting aspects already sufficiently addressed in Rel-10. while also taking into account estimation errors.1 (2012-06) •  • • − o Assess the standardization impact of the studied techniques. 3GPP . feedback overhead. complexity. calibration errors. backward compatibility and practical UE implementations. With second priority: Evaluate open-loop MIMO. based on UE-specific reference signals. Evaluate enhancements for downlink control signalling: to support MU-MIMO.226 Overview of 3GPP Release 11 V0. especially for MUMIMO. including impact on CSI payload sizes. Sub-band versus wideband feedback should be taken into account. If relevant feedback proposals are not directly implicit in nature. including considering improved orthogonality for MU-MIMO and possibilities for DMRS overhead reduction.1. All studies should evaluate the throughput gains potentially achievable from the studied techniques. the study of testing aspects should be included.

RAN1 should identify potential air interface solutions. For the multi-cell scenario. where possible interference may include adjacent channel interference as well as co-channel interference such as remote basestation-to-basestation interference. CATT. Huawei. including traffic models. o Deployments comprising the same or different uplink-downlink configurations should be investigated. For both isolated cell scenario and multi-cell scenario: − If significant benefits are identified by RAN1 evaluations. to mitigate DL-UL interference. For TDD deployments in general. Nokia Siemens Networks. Vodafone. Alcatel-Lucent Shanghai Bell. HiSilicon. with co-channel interference: − RAN1 should evaluate the benefits of uplink-downlink re-configuration dependent upon traffic conditions. Currently. LTE TDD allows for asymmetric UL-DL allocations by providing seven different semi-statically configured uplink-downlink configurations. 3GPP .828 for Information and Approval TR LTE 36. where adjacent channel interference may be from other operator(s). Research In Motion. IPWireless. deployment scenarios should include regular homogeneous macro deployments and layered heterogeneous deployments. o Assess the appropriate time scale for uplink-downlink re-configuration. i. These allocations can provide between 40% and 90% DL subframes. − RAN4 should perform co-existence analysis for the above identified scenarios.1 (2012-06) 21. − RAN4 should perform coexistence analysis with multiple operator deployments in adjacent channels. The semi-static allocation may or may not match the instantaneous traffic situation. dynamic allocation of subframes to UL or DL. − Backward compatibility of Rel-8/9/10 terminals should be maintained. NEC. − For all the studies above.6 Study on Further Enhancements to LTE TDD for DLUL Interference Management and Traffic Adaptation UID_510039 Resources: UID 51003 9 R1. The current mechanism for adapting UL-DL allocation is based on the system information change procedure.e. o Identify the proper simulation assumptions. Intel. Mediatek. Ericsson. i. Additional mechanisms could include e.227 Overview of 3GPP Release 11 V0. o Assess the appropriate time scale for uplink-downlink re-configuration.g. interference between UL and DL including both basestation-to-basestation and UE-to-UE interference needs to be considered. where it may be of interest to consider different uplink-downlink configurations in different cells. CHTTL. taking into account the RAN4 co-existence analysis. Samsung. − Specification impact should be identified and assessed. − RAN1 and RAN4 should identify the multi-cell scenarios for which TDD DL-UL interference may arise and additional TDD DL-UL interference mitigation would be beneficial. TR 36. ITRI. including traffic models. CATR. Also of interest are deployments involving different carriers deployed by different operators in the same band and employing either the same or different uplink-downlink configurations. HTC. Panasonic. This study item shall consider the work of other related study/work item(s) in Rel-11. Renesas. including co-channel and adjacent channel interference. including necessary EUTRAN/UE measurements. One example includes layered heterogeneous network deployments. Potevio. ZTE Justification TDD offers flexible deployments without requiring a pair of spectrum resources. o Assess the benefits at least in terms of performance and energy saving.828 Name Study on Further Enhancements to LTE TDD for DL-UL Interference Management and Traffic Adaptation Supporting Companies: Alcatel-Lucent. ST-Ericsson. without co-channel interference: − RAN1 should evaluate the benefits of uplink-downlink re-configuration dependent upon traffic conditions.e. o Identify the proper simulation assumptions.R4 Finish 15/06/201 2 Hyperlink RP110450 Status_Report RP-120587 WI_rapporteur CATT Notes RP#56 completed. Objective: For the isolated cell scenario. LG Electronics. China Mobile. o Assess the benefits at least in terms of performance and energy saving. Texas Instruments.1.

Nokia. Ericsson. Enable significantly improved spectrum efficiency for low data rate MTC traffic compared to that achieved for R99 GSM/EGPRS terminals in GSM/EGPRS networks today. Optimisations for low-cost MTC UEs should minimise impact on the spectrum efficiency achievable for other terminals in LTE Release 8-10 networks. and inefficiently assigned.888 v200 noted after RP-120715 discussion (address till 09/12 further Coverage aspects and update the WID accordingly) TR LTE TR 36. or evolved from. Renesas Mobile. IP Wireless. AT&T. ZTE. this naturally increases the reliance on GSM/GPRS networks.4 Kbps). TeliaSonera. operators would like to reduce the cost of overall network maintenance by minimising the number of RATs.1. Owing to the low cost of these devices and good coverage of GSM/GPRS. Therefore.2 Kbps). Sony Europe. This does not preclude the support of higher data rates provided the cost targets are not compromised. Machine-Type Communications (MTC) is a market that is likely to continue expanding in the future. Target operation of low-cost MTC UEs and legacy LTE UE on the same carrier. LTE RAN specifications up to and including Rel-10 shall be investigated and evaluated to clearly understand the feasibility of creating a type of terminal that would permit the cost of terminals tailored for the low-end of the MTC market to be competitive with that of GSM/GPRS terminals targeting the same low-end MTC market. TR 36. the overall resource they will need for service provision may be correspondingly significant. As more and more MTC devices are deployed in the field. The same defined LTE cell coverage footprint as engineered for “normal LTE UEs” should apply for low-cost MTC UEs.R4 Finish 07/12/201 2 Comp 90% Hyperlink RP111112 Status_Report RP-120588 WI_rapporteur Vodafone Notes RP#56 completion 06/12=>12/12. Qualcomm. eMobile.888 Name Study on Provision of low-cost MTC UEs based on LTE Supporting Companies: Vodafone. it is necessary to find a solution to ensure that there is a clear business benefit to MTC device vendors and operators for migrating low-end MTC devices from GSM/GPRS to LTE networks.R2. Ensure good radio frequency coexistence with legacy (Release 8-10) LTE radio interface and networks. ST-Ericsson. Given the likely high number of MTC devices.1 (2012-06) 21. Mediatek. Motorola Mobility. there is very little motivation for MTC device suppliers to use modules supporting the LTE radio interface. Huawei. Samsung. Orange Justification As LTE deployments evolve. NEC. • • • • • • The starting point of the analysis shall be the Rel-10 LTE air-interface. 4 Objective Solutions using. Many MTC devices are targeting low-end (low cost.228 Overview of 3GPP Release 11 V0. Nokia Siemens Networks. China Mobile. and ideally comparable with that of LTE. but also prevent operators to reap the maximum benefit out of their spectrum (given the non-optimal spectrum efficiency of GSM/GPRS).7 Study on Provision of low-cost MTC UEs based on LTE UID_530052 Resources: UID 53005 2 R1. Alcatel-Lucent. and a maximum of 3 active timeslots]. Ensure that overall power consumption is no worse than existing GSM/GPRS based MTC devices. at least comparable and preferably improved beyond what is possible for providing MTC services over GPRS/GSM today (assuming deployment in the same spectrum bands). 1 uplink timeslots (59. Ensure that service coverage is not worse than GSM/GPRS. Such solutions should: • Support data rates equivalent to that supported by [R’99 E-GPRS] with a EGPRS multi-slot class [2] device [2 downlink timeslots (118. Re-use the existing LTE/SAE network architecture. Sony. 3GPP . Telefónica. Intel. low data rate) applications that can be handled adequately by GSM/GPRS. This will cost operators not only in terms of maintaining multiple RATs.

3GPP . • • As part of the analysis of the different solutions. A method to guarantee that any features recommended as part of this study to allow cost reduction. any impacts on backwards compatibility with existing LTE network shall be evaluated and justified. Given that factors outside 3GPP responsibility influence the cost of a modem/device. transmission power. significantly lower peak data rate support. and reduced radio protocol processing. Note1: It is assumed that low-cost MTC UEs will have to support mobility and roaming. as well as impact on the operation of legacy LTE Release 8-10 UEs and Release 8-10 LTE system performance. additionally considering baseband-RF conversion aspects. or be used as a guarantee. Benefit of developing methods for reducing the processing in the device. The study shall evaluate at least the following aspects: • Benefit of developing methods for reducing RF component cost in the devices. from a 3GPP standpoint. after further careful study.1 (2012-06) The study item shall consider optimizations for both FDD and TDD mode. including (for example) simplifications and reductions in support of bands/RATs/RF chains/antenna ports. no support of spatial processing mode in uplink/downlink. and support of half-duplex FDD mode. but which also bring a reduction in LTE system performance. The initial phase of the study shall focus on solutions that do not necessarily require changes to the LTE base station hardware.1. maximum channel bandwidth less than the maximum specified for respective frequency band. Note2: This study item is to assess. the technical feasibility of low-cost LTE devices for MTC. shall be restricted to devices which only operate as MTC devices not requiring high data rates and/or low latency. that such modem/device will be low-cost in the market.229 Overview of 3GPP Release 11 V0. this study item (and the text above) cannot guarantee.

Backward compatibility should be taken into account. 4 Objective Until RAN#54: • Develop necessary simulation assumptions for coverage study • Based on the agreed scenarios. Many of the LTE-A enhancements have been mainly focusing on ensuring high peak rate and high spectral efficiency. on different layers should be avoided. NII Holdings. Panasonic. Huawei. c. TR 36. Identify the specification impacts of each potential solution. CHTTL. In addition. 3GPP should study if there are any such imbalances in relevant scenarios (including scenarios applicable for VoIP and low data-rate services). taking the control overhead into account. ongoing studies do not address the overall balance between coverage of control and data channels. and also leads to more UEs experiencing low geometry. China Unicom. China Mobile. • Coverage issues relating to voice should also be studied.R2 Finish 15/06/201 2 Hyperlink RP120225 Status_Report RP-120589 WI_rapporteur China Telecom Notes RP#56 completed. Until RAN#55: • For any identified coverage imbalances: a. is addressed by ongoing studies such as CoMP. ST-Ericsson.824 v200 for Approval TR LTE TR 36. this implies higher propagation losses for LTE and potentially a need to add more sites to ensure sufficiently good LTE coverage. uplink and downlink. HiSilicon. 3GPP . which can be seen both in terms of extending cell range for low data rates and in terms of improving data rates at the cell edge. Nokia Siemens Networks. KDDI. or initial access and data transmission. for example between control and data channels. This means that the number of application scenarios. ZTE Justification Over the last 5 years LTE has emerged as the technology of choice for beyond 3G evolution for the majority of global operators. Identify potential solutions. when rolling out LTE in existing networks.g. However. Quantify the gain of each potential solution.824 Name Study on LTE Coverage Enhancements Supporting Companies: China Telecom. However. operators are facing challenges in ensuring proper coverage when rolling out LTE in existing networks. Adding sites is costly and requires lengthy negotiations with building owners etc so it is not an optimal solution for quick and easy roll out of LTE. SK Telecom. Orange.8 Study on LTE Coverage Enhancements UID_530053 Resources: UID 53005 3 R1. Alcatel-Lucent. Motorola Solution.230 Overview of 3GPP Release 11 V0. LTE will be deployed at higher carrier frequencies than existing 2G and 3G systems. at least initially. Ericsson. link directions and communication phases. Alcatel-Lucent Shanghai Bell. d.1 (2012-06) 21. In order to ensure that LTE provides the best possible solutions to maximize coverage and minimize the need for site additions during roll out phase. Aspects concerning all the relevant RAN WGs should be considered. identify any potential issues due to coverage bottlenecks by taking coverage imbalances into account. coverage enhancement for data & voice transmissions is also very important for LTE system deployment. In many cases. b.1. deployment scenarios and spectrum configurations for LTE has significantly increased since the early days of LTE standardization. Redundant solutions and enhancement methods for the same purposes e. at the current stage.

231 Overview of 3GPP Release 11 V0.  Although dedicated network planning may be used to alleviate the above issues. the quality of service for UEs on high speed vehicles remains to be improved. Telefonica. New Postcom. Huawei. Mobile relay can also improve spectrum efficiency by exploiting more advanced antenna arrays and signal processing algorithms than normal UEs. Effectively mitigating the impairments mentioned above may lead to more efficient utilization of radio resources. Potevio. handover occurs much more frequently. Intel. the handover success rate is reduced. RIM. NEC. thereby impacting the operator’s CAPEX and OPEX. Mobile relay (a relay mounted on a vehicle wirelessly connected to the macro cells) is a potential technique to solve the above problems.1. Repeaters with an indoor and an outdoor antenna will have good channel conditions towards the UEs for improved UL and towards the network for improved DL transmissions.836 v100 for Information. CHTTL. The achievable throughput with these impairments can be significantly reduced compared to low speed environment. only one radio access system is required on the backhaul link. China Mobile. Being connected through a L1 repeater. In addition. III. HTC. With a mass of UEs performing handover at the same time. Specific eNB/UE implementations to combat these impairments are possible. LGE. UE measurements in high speed environments are typically less accurate than low speed environments. ITRI. due to excessive signalling overhead and the fact that tracking area update (TAU) is provided in a short time period. with mobile relays. Nokia Siemens Networks Justification High speed public transportation is being deployed worldwide at an increased pace. the required transmit power of the UEs is much less.1 (2012-06) 21.R1. CATR. where excessive handover signalling is avoided by performing a group mobility procedure instead of individual mobility procedures for every UE. See RP-120695 Clarification on the scope of RAN1/2/4 in mobile relay for EUTRA TR LTE TR 36. at the expense of additional cost.836 Name Study on Mobile Relay for E-UTRA Supporting Companies: CATT. providing multiple services of good quality to users on high speed vehicles is important yet more challenging than typical mobile wireless environments also due to the following reasons:  Reduced handover success rate: for high speed UEs. A mobile relay is a base station/access point mounted in a moving vehicle likely to provide at least the following key functions: 1) Wireless connectivity service to end users inside the vehicle 2) Wireless backhauling connection to on-land network 3) Capability to perform group mobility 4) Capability to allow different air interface technologies on the backhaul and access link Handover success rate can be improved via mobile relays. they are useful when deployed at positions with advantageous SINR. China Telecom. Degraded throughput due to high Doppler effects: impairments caused by high Doppler include frequency estimation errors and channel estimation errors. Hence. UEs can 3GPP . leading to significant UE power saving and increased UE battery life. Furthermore. Furthermore. With UEs connected to a close by relay node on board. Since repeaters do not re-generate the received signal. L1 repeater (mounted on a vehicle) is an alternative technique in fast-moving environments.R4 Finish 07/09/201 2 Comp 60% Hyperlink RP111377 Status_Report RP-120590 WI_rapporteur CATT Notes RP#56 completion 06/12=>09/12.R2. which can possibly reduce the number of radio access systems required at macro NBs along the vehicle path. TR 36. In addition such repeaters overcome the wall or window penetration loss. separate antennas for communication on backhaul and access link can be used to effectively eliminate the penetration loss through the vehicle.9 Study on Mobile Relay for E-UTRA UID_530054 Resources: UID 53005 4 R3. L1 repeaters amplify and forward signals of a certain frequency band. China Unicom. HiSilicon.

L1 repeaters) in fast-moving environments Evaluate suitable mobile relay system architecture and procedures. including the following aspects: Identify the target deployment scenarios first (RAN3) Identify the key properties of mobile relays and assess the benefits of mobile relays over existing solutions (e. which increases UE battery life.g. including procedures for group mobility (RAN3) Comparison based on higher layer considerations. e. Observing the potential benefits of mobile relay for high speed application and the fact that only stationary relay nodes are specified in Rel-10. etc. Group mobility.1. L1 repeaters are transparent and do not have an impact on radio interface standards.1 (2012-06) reduce their transmit power. it is proposed to start a new study item on mobile relay in Rel-11. etc. (RAN2) Comparison based on PHY layer considerations.232 Overview of 3GPP Release 11 V0. (RAN1) o Identify possible impact on deployment and performance aspects (RAN4) This study item shall consider the related L1 work in other Rel-11 work/study items. etc. Objective: focus on the backhaul design of mobile relays. (RAN3) Radio protocol impact. Doppler effect.g. • • o o • • o 3GPP .g. e.

and effect of CRS and control channels to which different precoder is applied compared with data channels.829 Name Study on Enhanced performance requirement for LTE UE Supporting Companies: NTT DoCoMo. Huawei. Deutsche Telekom. In principle. Nokia. different precoders. Initial work plans are following: 3GPPRAN4#60-BIS:  Agree on evaluation scenarios. HiSilicon. Thus the inter-cell interference suppression capability for other types of interference is not ensured by UE receiver for LTE. Further system performance gain could be envisioned by UE receiver enhancements. Softbank Mobile. . Orange. Renesas Mobile.  Study and evaluate feasibility and potential gain by advanced receiver at link and system levels: . Some complexity considerations should be taken into account during the SI phase to avoid over simplified model later on that doesn’t reflect the performance benefits found. China Unicom.Identify the scenarios and conditions where inter-cell interference mitigation is effective . Nokia Siemens Networks. For HSDPA.Evaluation should be based on realistic modelling of inter-cell interference.1 (2012-06) 21. finalize TR. Qualcomm. For LTE.829 v100 for Information + Approval TR LTE TR 36.  Receiver structures targeted to TDM-eICIC are only to be studied under the eICIC enhancements WI. TR 36. 4 Objective  Identify realistic deployment scenarios. the LMMSE receiver suppresses both inter and intra-cell interference. ST-Ericsson. MediaTek. Intel.10 Study on Enhanced performance requirement for LTE UE UID_530055 Resources: UID 53005 5 R4.1.  Receiver structures targeting spatial domain interference mitigation such as IRC are to be considered as a starting point. ranks and powers applied over consecutive subframes. The demodulation performances of LTE receivers to date have been specified assuming that inter-cell interference is modelled as AWGN. AT&T. demodulation performance of inter-cell interference suppression receiver which is referred to as Type 3i has been specified. KDDI Justification To cope with growing data traffic to support smart phones with various applications. and performance metrics to evaluate the performance of advanced receiver to mitigate inter-cell interference. Particularly. Telecom Italia. Samsung. China Mobile. mitigating inter-cell interference at the UE receiver would be desired to improve cell edge user throughput. decision on work item 3GPP . Alcatel-Lucent.R1 Finish 02/03/201 2 Hyperlink RP111378 Status_Report RP-120167 WI_rapporteur NTT DoCoMo Notes RP#55 completed.Identify the receiver structures that could be a baseline to specify performance requirement.233 Overview of 3GPP Release 11 V0. traffic models. CATT. including both synchronous and asynchronous operations among macro eNBs. further improvement of system capacity is required for the LTE systems. NEC. Verizon Wireless. NII. and performance metrics 3GPPRAN4#61  Review initial simulation results and agree further simulation cases to conclude the SI  Review initial complexity analysis 3GPPRAN4#62  Review further results. interference models. Ericsson. demodulation performance requirements have been specified for UE receiver based on Linear Minimum Mean Squared Error (LMMSE) criteria assuming two receive antennas. interference models.  Details of interference modelling for performance requirements and conformance testing shall be specified in the WI phase.

including the following: • • • Mobility load balancing between LTE and HRPD. 3GPP . ZTE. Huawei.11 Study on LTE-HRPD (High Rate Packet Data in 3GPP2) inter-RAT SON UID_550020 Resources: UID 55002 0 R3 Finish 07/12/201 2 Comp 15% Hyperlink RP120380 Status_Report RP-120591 WI_rapporteur China Telecom Notes TR LTE new TR Name Study on LTE-HRPD (High Rate Packet Data in 3GPP2) inter-RAT SON Supporting Companies: Justification China Telecom. It’s necessary to coordinate between 3GPP and 3GPP2 on this topic. however inter-RAT SON for LTE-CDMA is not specified. 3GPP2 has approved a work item on CDMA SON. Alcatel-Lucent.234 Overview of 3GPP Release 11 V0. Nokia Siemens Networks Inter-RAT SON features of LTE and UTRAN/GSM have been standardized in 3GPP. the potential solutions and the impacts to current specifications should be studied. To identify the impacts to current specifications.1 (2012-06) 21. Automatic neighbor relationship between LTE and HRPD. the ability of load balance will help to offload LTE traffic from/to the HRPD network.1. Mobility robustness optimization between LTE and HRPD. Automatic neighbor relationship will fasten the LTE network deployment. inter LTE-HRPD SON will bring many benefits. which includes LTE-HRPD inter-RAT scenario. For the CDMA operators who plan to deploy LTE networks. Objectives: To study the SON use cases applied to inter LTE-HRPD RAT. and improve the handover performance between LTE and HRPD. In order to support inter LTE-HRPD SON. Qualcomm. To develop the potential solutions to support the use cases above. for example.

Justification 3GPP RAN WG4 has already finalized TR25. Nowadays LTE (FDD and TDD) terminals with multiple receive antennas are becoming more and more important to the mobile phone market. ZTE. it is clear that there is commercial pressure from operators to have a test method available for LTE already today. The results of the UE Over The Air (OTA) test method with Head and Hand Phantoms study item can be considered later on once finalized. NTT DOCOMO. it is anticipated this will take some more time to converge on the methodology because the aspects to do fading and verifying the impact of antenna correlation are complex issues.TRP and TRS test methodology UID_550022 Resources: UID 55002 2 R4 Acronym FS_LTE_OTA Finish 07/09/201 2 Comp 70% Hyperlink RP120412 Status_Report RP-120592 WI_rapporteur CATR Notes RP#56 completion 06/12=>09/12 . TR 37. NOKIA.902 Name Study on Measurements of radio performances for LTE terminals Total Radiated Power (TRP) and Total Radiated Sensitivity (TRS) test methodology Supporting Companies: CATR.235 Overview of 3GPP Release 11 V0. Huawei. it is easy to extend to this study item contribution to UMTS terminals with. 3GPP .Laptop mounted equipment Free Space test (UEAnt_FSTest) Nature of relationship RAN4 TR 25. It is very necessary to ensure that the test method exists to control the antenna performance of these products.1.TRP and TRS test methodology. The work should utilise the existing environments in TR25. Objective: to make a simple extension to the UE OTA TRP and TRS test methods TS34. and is therefore considered an interim step until the fully radiated test method for multi-antenna UE reception is available As UMTS devices with multiple receive antennas are still needing test methodology. new TR 37.914 Rel-11 “Measurements of radio performances for UMTS terminals in speech mode” RAN4 TS 25. SAMSUNG.114 for LTE UE with multiple receive antennas. and it is proposed to define a simple extension to the existing TRP and TRS test method for LTE as well. China Unicom.144 Rel-11 “User Equipment (UE) and Mobile Station (MS) over the air performance requirements” on UMTS and GSM OTA aspects.914. ETS-Lindgren. China Telecom. CMCC.144 Rel-11 “User Equipment (UE) and Mobile Station (MS) over the air performance requirements” on UMTS and GSM OTA aspects. However. This study item will have a new TR number on Measurements of radio performances for LTE terminals .902 v100 for Information (See RP120592 discussion: applies not only to LTE but also to UMTS FDD/TDD=> need to change WID & TR Title before Approval) TR LTE 25. It is important to clarify that this simple TRS approach does not give the same accurate information of radiated UE receiver performance especially in realistic radio environments as the test method being developed under the “Measurement of Radiated Performance for MIMO and multi-antenna reception for HSPA & LTE terminals” study item.914 Rel-11 “Measurements of radio performances for UMTS terminals in speech mode ” and TS25.976 has already discussed and is progressing in RAN4.1 (2012-06) 21. a hot topic MIMO-OTA TR37. However.12 Study on Measurements of radio performances for LTE terminals . For now. due to similar situation and technical issue. without considering all of the aspects associated with spatial channels.914. Deutsche Telekom Related Work Item(s) (if any] UID Title 53005 Study on UE Over The Air (OTA) test method with Head and 7 Hand Phantoms (FS_OTA_phantoms_UTRA) 45011 Core part: UE Over The Air (Antenna) conformance testing 6 methodology .

UMTS TRP and TRS test methods should also be updated in the same way.1 (2012-06) In this study item. the needed modifications to measurement parameters for LTE devices will be studied and applicability of the existing measurement procedures. TRP and TRS will be evaluated for LTE devices with multiple receive antennas TDD-LTE and FDD-LTE terminals (as it is expected that the same issues are applicable independent of RAT). UE antenna OTA TRP and TRS minimum requirements for LTE devices will not be defined in this study item. e. 3GPP .1.g.236 Overview of 3GPP Release 11 V0.

G1 WI_rapporteur Vodafone Ericsson Huawei Spirent Alcatel-Lucent LG Uplus NTT DoCoMo Huawei Ericsson TR UTRA. an LS was sent to COST 2100 SWG2. Orange. 4 Objective The high level objective of this study item is to define a 3GPP methodology for measuring the radiated performance of multiple antenna reception and MIMO receivers in the UE. Vodafone. but it is clear that the ability to duplicate these gains in the field is highly dependent on the performance of the receive-antenna system.976 UTRA. T-Mobile International.R2 R4 R4 R4. However given that 3GPP is the customer for this work as well as being a potential contributor. At TSG RAN#41. Ericsson. SFR. LTE Studies Name Study on Measurement of Radiated Performance for MIMO and multi-antenna reception for HSPA and LTE terminals Study on Extending 850 MHz Study on RAN improvements for Machine-Type Communications Study on UE Application Layer Data Throughput Performance Study on further enhancements for HNB and HeNB Study on Interference analysis between 800~900 MHz bands Study on UMTS/LTE in 900 MHz band (Japan.804 UTRA. with particular focus on handheld devices and devices embedded in laptop computers. The test methodology should be relevant for HSPA and LTE technologies. and also the timescales for which such work could be completed to define such a methodology. LTE 37.868 UTRA.R4 R3. LTE. LTE 37. NTT DoCoMo. 3GPP already defined conducted tests for MIMO and multiple antenna receivers (type 1 and type 3 in TS25. LTE 37.R3. GERAN 37. LTE 37.1 Study on Measurement of Radiated Performance for MIMO and multi-antenna reception for HSPA and LTE terminals UID_430020 Resources: UID 43002 0 R4 Resource R4 Finish 02/03/201 2 Hyperlink RP111754 Status_Report RP-120154 WI_rapporteur Vodafone Notes RP#55 completed.2 and CTIA ERP to ask them for feedback on their plans/ongoing work in this area. Since then.840 UTRA. feedback from COST 2100 and CTIA has suggested they are happy to work on this topic. Motorola. LTE impacts TR 37. Korea) Study on RF and EMC requirements for active Antenna Array System (AAS) Base Station Study on Passive InterModulation (PIM) handling for UTRA and LTE Base Stations Resource R4 R4 R2.1.R4 R5. Nokia. LTE 37.976 v200 for Approval TR UTRA.976 Name Study on Measurement of Radiated Performance for MIMO and multiantenna reception for HSPA and LTE terminals Supporting Companies: AT&T. As an outcome of the discussion. LTE 37. LTE 37.808 22.1 (2012-06) 22 UID 43002 0 44001 6 45001 5 50000 2 51003 6 51003 8 52001 8 53005 6 55002 1 UTRA. The use of MIMO and receiver diversity in the UE is expected to give large gains in downlink throughput performance for HSPA and LTE devices.806 UTRA.901 UTRA. TR 37. LTE 37. Samsung.237 Overview of 3GPP Release 11 V0. with particular focus on handheld devices and devices embedded in laptop computers. Research in Motion. it is important to aim for commonlyaccepted measurement and test methodology to be used across the industry. The steps intended to achieve this involve the following: 3GPP .803 UTRA.804 UTRA.R1 R4. it was indicated that there is a need for a test methodology to be created with the aim of measuring and verifying the radiated performance of multi-antenna and MIMO receiver in UEs for both HSPA and LTE devices.R1.101 for HSPA demodulation).

TSG RAN should contact TSG GERAN to get feedback on the applicability of such a test methodology for GERAN. Maintain ongoing communication with COST 2100 and CTIA ERP to ensure industry coordination on this topic.1. Agree the final solution.238 Overview of 3GPP Release 11 V0. Review of potential solutions also considering input from CTIA ERP and COST 2100. 3GPP . and detail the agreed 3GPP solution in a technical report to be reported to RAN plenary.1 (2012-06) • • • • Identify the performance metrics and clarify the requirements of operators for defining such a methodology.

The same applies to the base station implementations in principle. Once the RAN4 work has progressed.239 Overview of 3GPP Release 11 V0. The finding will be contained in a technical report. ST- There are a number of 3GPP bands specified in the frequency range of 800 MHz to 900 MHz. LTE 37. 3GPP . There are many operators around the world using this allocation for non-3GPP technologies that would like to have the option of adopting 3GPP technologies Having many different bands that are different in different locations in the world. NII Holdings. Additional spectrum 806814/851-859 MHz is already allocated by ITU for IMT around the world for possible 3GPP technologies. Motorola. Hence it would be beneficial to study a more harmonised frequency variant approach within the frequency range of 806-849/851-894 MHz taking into account implementation aspects. create a problem for UE implementations since the number of bands available in one UE is limited and this will reduce the economy-of-scale.g. Study means such as A-MPR (LTE) and power back-off (CM for WCDMA) to facilitate coexistence with services in adjacent bands. for example the width of the duplexer gap.2 Study on Extending 850 MHz UID_440016 Resources: UID 44001 6 R4 Finish 07/09/201 2 Comp 90% Hyperlink RP090666 Status_Report RP-120578 WI_rapporteur Ericsson Notes RP#56 completion 06/12=>09/12 TR UTRA.1 (2012-06) 22. Nokia. Nokia Siemens Networks. One example is the Public Safety band below the SMR band in the US.806 Name Study on Extending 850 MHz Supporting Companies: Ericsson. The investigations will include RF performance requirements and backward compatibility issues. Ericsson. being capacity limited and LTE/HSPA migration is facilitated. it is easier to expand networks by adding frequencies when e.1. RAN2 may need to study signalling issues related to this. although overlapping each other. large bandwidth allocations create better opportunities and flexibility in service offerings: different channel bandwidths can be used. Alcatel-Lucent. Furthermore. Objective: to study a more harmonised frequency variant approach within the frequency range of 806-849/851-894 MHz.

868 and Rel-10 UID_410030 Network Improvements for Machine-Type Communications (NIMTC) SA1 TS 22. the traffic of MTC in different M2M applications needs to be characterized.3 Study on RAN improvements for Machine-Type Communications UID_450015 Resources: UID 45001 5 R2. CATR . to study the feasibility of above enhancements with particular focus on maximizing re-use of existing features while minimizing changes in order to keep complexity related to M2M s at a minimum level.1. LG Electronics. and to improve RAN efficiency to handle MTC. identify problems. Telecom Italia. To support these service requirements and categories.1 (2012-06) 22. Triggered by SA1's UID_7027 Study on Facilitating Machine to Machine Communication in GSM and UMTS (M2M) TR 22. LTE 37.R4 Finish 16/09/201 1 Hyperlink RP100330 Status_Report RP-111052 WI_rapporteur Huawei Notes RP#53 completed. radio resource allocation methods for a large number of Machines in the same cell. power saving mechanisms for several M2M application scenarios and flexible ultralow duty cycle. Qualcomm. to study RAN enhancements for UTRA and EUTRA to improve the support for MTC considering their specific requirements identified by SA1. In order to study these issues. to study RAN enhancements which enable or improve efficient use of RAN resources and/or which lower complexity when a possibly large number of MTC devices need to be served. China Unicom. TR 37. Fujitsu.868v100 for Approval (No WID change: RAN overload only). Philips.R1. to report areas where enhancements are found worthwhile to RAN.868 Study on Facilitating Machine to Machine Communication in GSM and UMTS (M2M) UID_7027 and Rel-10 NIMTC UID_410030 TR UTRA. CATT. propose solutions and reduce the complexity of MTC. Verizon. the system performance impact introduced by serving a possibly very large number of MTC devices. For example.368 lists service requirements for MTC (UID_410031 Stage 1 for Network Improvements for MachineType Communications). Panasonic. ST-Ericsson.R3. China Mobile. low mobility consideration for many devices which never move at all. Study how to enable efficient use of RAN resources for MTC. it is necessary to study RAN technical enhancements for MTC for UTRA and EUTRA. Alcatel-Lucent.868 Name Study on RAN improvements for Machine-Type Communications Supporting Companies: Huawei. Another important issue is how the large number of MTC will influence the RAN performance. 3GPP .240 Overview of 3GPP Release 11 V0. ZTE. Triggered by TR 22. Ericsson. Objectives: • • • • to study traffic characteristics typical for different M2M applications that are using MTC based on the SA1 requirements and define new traffic models based on these findings.

4 Study on UE Application Layer Data Throughput Performance UID_500002 Resources: UID 50000 2 R5. It is also noted that the PTCRB might additionally be able to take advantage of the results of such work in 3GPP. Although utilising existing test procedures without any 3GPP . of the UE standalone or/and in combination with a Laptop. The GCF has indicated that they wish to add UE Application-Layer Data Throughput Measurements under various simulated network conditions to their Performance Items area of activity and has requested RAN5 to recommend and produce the necessary test procedures. will be defined to simulate typical network conditions.241 Overview of 3GPP Release 11 V0. Samsung.g. LTE 37. AT&T. Motorola Mobility. As part of this work RAN5 has determined that if TSG RAN agrees that RAN5 should carry out this work then the way forward would be to create a Study Item which would produce a suitable TR. ZTE.LS on Request to RAN5 to analyse proposals for performance testing Justification The currently-used HSPA. an initial set of suitable scheduling/radio conditions to be used by the test systems.1 (2012-06) 22. The exact simulated network scheduling and down link radio conditions to be used will be determined during the study. The test procedures developed will measure the achieved average application-layer data rates (e. The test procedures will be developed in a flexible manner to accommodate various test conditions. using labbased simulators and other necessary equipment). "bad" will be supplied).RAN5 ToR Scope Review. or inside the UE in case of a terminal that does not support tethered mode. "medium". NOTE: The point of measurement on the UE side will be either in a connected PC for terminals that support tethered mode only. and even more the upcoming LTE radio access technology. lab-based environment (i. During RAN5#49 RAN5 has carried out this work and responded to TSG RAN in [5].e. radio conditions) and test procedures used in current conformance testing by RAN5. Agilent. This is being matched and even exceeded by a corresponding increase in the demand for data from users of the latest data-hungry devices and applications.RAN5 LS to GCF SG (R5-104673) [3] R5-104166 . References [1] RP-100802 .1. TSG RAN in [4] requested RAN5 to review the GCF proposal and provide further requested information back to TSG RAN.g.GCF SG LS S-10-103. RAN5 Chair [2] RP-100713 .LS on Request to RAN5 to analyse proposals for performance testing [5] R5-106665 . or in both places for UEs that support both modes. GCF inquired whether RAN5 could develop test procedures for “end-to-end data throughput measurements”. Vodafone. Rohde & Schwarz. It is therefore essential that data devices achieve high efficiency when using data services and do not unduly load the network. are providing a very large increase in data transmission capacity in mobile networks. Objective: to define test procedures to measure UE data throughput performance at the application-layer. no matter what maximum data rate they are capable of using. Telecom Italia. Sprint Introduction During RP#49. with no qualification of the results (i. China Unicom. as sent to and reviewed at RAN5 [4] RP-101025 . "good". It is envisaged that in addition to some measurements under "ideal conditions".e.R4 Finish 09/12/201 1 Hyperlink RP101422 Status_Report RP-111543 WI_rapporteur Spirent Notes RP#54 completed TR UTRA. Additional optional conditions may be developed later as and when required. TSG RAN discussed [1] against the backdrop of the liaison from RAN5 [2] regarding the GCF request [3] handled in RAN5#48. Qualcomm. no verdicts such as "pass/fail". Verizon Wireless.901 Name Study on UE Application Layer Data Throughput Performance Supporting Companies: Spirent Communications. The study will aim to reuse wherever possible conditions already specified by RAN4 (e. Orange. using FTP or UDP) under simulated realistic network scheduling and radio conditions in a repeatable. CATR.

etc.1. NOTE: Test cases for example in clause 8 of TS 36. - 3GPP .g. The impact from the lower layers data throughput on the application-layer data throughput. Other issues that the Study Item may investigate include: The definition of a reliable and repeatable test environment to ensure the best possible repeatability of the results. especially when variable radio conditions are applied. etc) to be used. The study should determine the best candidates. quality of service.521-1 could possibly be adapted for the study and test procedures could be based on the existing single antenna port. The study will determine the Applications and the related Application requirements (e. uplink data transfers and bidirectional data transfers. FTP. transmit diversity. UDP. The study will determine suitable test procedures for downlink data transfers. adaptation of existing test cases may well be possible.242 Overview of 3GPP Release 11 V0. and open and closed loop spatial multiplexing test cases.1 (2012-06) modification is unlikely. GCF has stated that the Radio connection should be limited to LTE and W-CDMA Rel-5 (HSDPA) and later and the study will only consider these. applications in the UE or/and the Laptop that would measure the throughput. TCP settings. This could include the definition of a reference laptop configuration.

The extension of SHO capability to operation with macro network can allow better integration of HNB cells with the macro network. Hitachi Justification The Rel-10 WI UID_470005 on "HNB and HeNB Mobility enhancements" introduced support for mobility signalling via horizontal RAN interfaces (Iurh. The issues involved in supporting inter-CSG HO need to be studied. If supported for SHO. Evaluate the benefit of support for enhanced mobility including SHO between HNBs on different HNB-GWs. Nokia Siemens Networks. Evaluate the benefit of support deployment scenarios with 2 HeNB-Gateways directly interconnected to each other (RAN3 only) 3GPP . (RAN3 only) Evaluate the benefit of support for Inter-CSG enhanced mobility. HiSilicon. This will be studied in the context of any further requirements from SA.5 Study on further enhancements for HNB and HeNB UID_510036 Resources: UID 51003 6 R3.803 v200 for Approval TR UTRA. (RAN3 only) Evaluate the benefit of support for enhanced SRNS relocation between HNB and Macro RNC (RAN3 only) Evaluate the benefit of support of Inter-CSG HNB-HNB enhanced mobility . KDDI. supported on the macro network has not been considered in relation to H(e)NBs. Mitsubishi Electric. Support of X2 via GW proxy for HeNB to HeNB mobility will be studied. LTE 37.1 (2012-06) 22. Also deferred from Rel-10 was support for inter-CSG HeNB-HeNB HO.R2 Finish 15/06/201 2 Hyperlink RP120279 Status_Report RP-120579 WI_rapporteur Alcatel-Lucent Notes RP#56 completed.1. This SI considers support of CELL_FACH state and the benefits that support of CELL_PCH and URA_PCH states can provide. but provides significant benefits for open mode HeNBs used in mall environments and to extent coverage areas of macro network. To support SHO an extension of Iur from the HNB-GW to a macro RNC can be used.803 Name Study on further enhancements for HNB and HeNB Supporting Companies: Alcatel-Lucent. Objective: • • • • • • for UMTS: Evaluate the benefit to enhance support of enhanced mobility in CELL_FACH. Interdigital. RAN Sharing (UMTS and LTE): RAN sharing. Orange. Huawei. Support for inter-CSG HO was discontinued in Rel-10. AT&T. in line with SA decisions. X2) for the support of H(e)NB to H(e)NB mobility. (RAN3 only) Evaluate the benefit of X2 connection via the GW proxy for (H)eNB to HeNB mobility enhancements (RAN3 only) Evaluate the benefit of support of RAN sharing for HeNBs in line with SA decisions. and this can also be used to link HNB-GWs as the Iur is a symmetrical interface. TeliaSonera. the presence of an Iur between HNB-GW and macro RNC would allow use of enhanced SRNS relocation to further improve Hand-in/Hand-out performance compared to CN involved methods already specified. (RAN3 led) Evaluate the benefit of support of enhanced mobility including soft handover between HNB and macro network (RAN3 led).243 Overview of 3GPP Release 11 V0. LTE only: Support for eNB to HeNB was de-scoped in Rel-10. NEC. TR 37. Alcatel-Lucent Shanghai Bell. Objective: • • • • • for LTE: Evaluate the benefit of support for Enhanced eNB to HeNB mobility and vice versa. CELL_PCH and URA_PCH states. UMTS only: Work on support for enhanced mobility in CELL_FACH for 3G home access was discontinued in Rel-10. (RAN3 only) Evaluate the benefit support of RAN sharing for HNBs.

the KCC (Korea Communications Commission) has allocated some portion of Band 5 and some portion of Band 8 for IMT service. As such. To investigate impact of interference both in UE and BS operating between 800~900 MHz bands. The Band 5 is a defined band for region 2. ETRI. and in this case a study on coexistence and collocation is necessary. B. KT. Korea) UID_520018 TR UTRA. bands defined per region could be used simultaneously. LG Electronics. for each country. Pantech Currently it is becoming more and more difficult to acquire frequency resource for mobile communications service. Currently in Korea.1 (2012-06) 22. KTL.804 Study on UMTS/LTE in 900 MHz band (Japan. The detailed objectives are as follows: In case both band 5 and band 8 are used in the same region for LTE simultaneously. and it is expected that multiple bands defined per region would be used simultaneously. the Band 5 and 10MHz portion of Band 8 are allocated for mobile communication.244 Overview of 3GPP Release 11 V0. investigation on whether it would be necessary to define a new band or how we can utilize and approach existing 3GPP Technical Specifications 3GPP . LG-Ericsson. Objective: focus on the interference analysis between 800~900 MHz bands. In 2010. Samsung. Impacts TR 37. LTE impacts TR 37. it is necessary to study: 1) investigation on whether interference would exist 2) interference study on co-existence and co-location including system and UE A. if interference does exist.1.804 Name Study on Interference analysis between 800~900 MHz bands Supporting Companies: Justification LG Uplus.6 Study on Interference analysis between 800~900 MHz bands UID_510038 Resources: UID 51003 8 R4 Finish 15/06/201 2 Hyperlink RP111752 Status_Report RP-120586 WI_rapporteur LG Uplus Notes RP#56 completed. and the Band 8 is a defined band for region 1. Such study would be very helpful when similar problems occur in the near future. SKT.

Softbank Mobile.e. KT. assignment to the areas will be completed by March 2018). Panasonic. 2011. Sharp. the SI “Interference analysis between 800~900 MHz bands” is ongoing in RAN4.1 (2012-06) 22.950 MHz for DL will be allocated in 2011. Korea) Supporting Companies: NTT DoCoMo. in Korea. 839 849 MHz for UL and 884 . LG Uplus. Band 8/VIII or a new band. and the final report was issued in May. it would be useful to study the possibility of harmonized WI proposal for these different band plans among these two countries.894 MHz for DL) and the 900 MHz band (i. Therefore. Taking this plan into account. feasibility study would be needed in advance on how to define the new spectrum in 3GPP.905 MHz for UL and 945 . i. Fujitsu Justification In Japan. eAccess.e.7 Study on UMTS/LTE in 900 MHz band (Japan. LTE 37. Korea) UID_520018 Resources: UID 52001 8 R4 Finish 15/06/201 2 Hyperlink RP120617 Status_Report RP-120580 WI_rapporteur NTT DoCoMo Notes RP#56 completed.. Since the possible new WI for the 900MHz band in Japan and the existing SI for interference analysis between 800~900 MHz bands in Korea are targeting for similar frequency ranges. Objective:  Study the feasibility to add the Japanese technical conditions in the 900 MHz band to UMTS Band VIII  Study the feasibility to add the Japanese technical conditions in the 900 MHz band to LTE Band 8 considering the required A-MPR value and associated NS signalling  Study the creation of a new UMTS/LTE Band to match the Japanese technical conditions in the 900 MHz band  Study the possibility of a harmonized WI proposal for the different frequency allocations in the 900 MHz ranges Japan and Korea 3GPP . TR 37. Mitsubishi.804 v100 for Information and Approval. however. new WI in 3GPP TSG-RAN for specification of the Japanese technical conditions in the 900 MHz band is needed.245 Overview of 3GPP Release 11 V0.960 MHz for DL will be allocated by 2015 (note: the reorganization may not be completed in some geographical areas until 2015. Meanwhile. KDDI. Updated WID RP-111751=>RP120617.. “Action plan for frequency reorganization toward realizing Wireless Broadband” was discussed in the Working Group (WG) under the ICT Policy Task Force for a Global Era of the Ministry of Internal Affairs and Communications (MIC).804 Name Study on UMTS/LTE in 900 MHz band (Japan. SKT.1. Linked to Study on Interference analysis between 800~900 MHz bands UID_510038 TR UTRA. such as Bands 18 and 19/XIX. the Telecommunications Council under the MIC studied technical conditions in the 900 MHz band. NEC. In order to investigate the impact of interference both in UE and BS operating between these 800~900 MHz bands. It should be noted that these technical conditions are developed considering the co-existence with the UMTS/LTE operation in the 800 MHz band.960 MHz for DL) for IMT service. the KCC (Korea Communications Commission) has re-allocated the 800 MHz band (i.e. before the possible new WI for the 900 MHz band in Japan is established in the RAN#53. and 10 MHz bandwidths will be added to the UL and DL from 2012 if all progress smoothly. Eventually 900 915 MHz for UL and 945 . 905 – 915 MHz for UL and 950 . Since the spectrum to be allocated is a part of Band 8/VIII. The WG concluded that 900 .

36. TD Tech. Based on the outcome of the above studies. It may significantly reduce the operation expenses by saving the required space for the BS site infrastructure. The RF and/or EMC requirements for AAS BS transmitters and receivers.141. China Telecom. TeliaSonera. China Unicom. The methodologies for specification implementation of all the necessary changes. It remains the currently applicable tests for BS using antenna arrays. 3GPP . AT&T. • Feasibility of OTA tests. the following specification-related work will be identified pending approval of the related Work Item: 1. The study will cover single-RAT UTRA and E-UTRA.8 Study on RF and EMC requirements for active Antenna Array System (AAS) Base Station UID_530056 Resources: UID 53005 6 R4.1. • The core RF and/or EMC requirements for the transmitter and receiver. CMCC. This Study Item proposes to evaluate the feasibility of specifying the necessary requirements for BS using AAS Objective: to investigate the RF and EMC requirements for an AAS BS based on macro-cell deployment scenarios for both TDD and FDD. However. Ericsson. It can enable system optimization to be adaptive to traffic demands and address network evolution issues through flexible software re-configuration of the BS and antenna system. and by elimination of the cable loss. specification implementation and test methodologies • Study the following aspects • Transmitter and receiver characteristics and their impact on system performance and co-existence. LTE 37. Nokia Siemens Networks.141 and 37. US Cellular Justification Compared with BS installed with traditional antenna. Telecom Italia.141. 2. • Determine the appropriate approaches for standardization. as well as multi-RAT base stations. HiSilicon.246 Overview of 3GPP Release 11 V0. it was noticed that these tests might not be sufficient to accurately reflect the AAS antennas environment in practical field deployments.840 Name Study on RF and EMC requirements for active Antenna Array System (AAS) Base Station Supporting Companies: Alcatel-Lucent. the Active Antenna Array Systems (AAS) BS can offer a host of benefits: • • • • It can lead to system capacity/performance gains by flexible cell split or beam-forming. Orange.R1 Finish 07/09/201 2 Comp 55% Hyperlink RP111349 Status_Report RP-120581 WI_rapporteur Huawei Notes TR UTRA. CATR. Huawei.1 (2012-06) 22. The study item particularly covers the following two main aspects: • Feasibility of defining AAS BS requirements based on the commonality of different architecture and implementations: • Develop/define relevant terminology associated with AAS BS to ensure common understanding. Deutsche Telekom. The requirements for AAS BS have been discussed in RAN4 and RAN for several meetings. Current test specifications for BS using antenna arrays are found in TS 25. It may significantly simplify the site engineering complexities and reduce the installation costs. • Regulatory aspects related to multiple antenna transmission and the impact on AAS BS.

Existing BS RF requirements and tests remain unchanged. which should serve as a deployment guide line.808 Name Study on Passive InterModulation (PIM) handling for UTRA and LTE Base Stations Supporting Companies: Ericsson. including the antennas. LightSquared Related Work Item(s) (if any] UID Title 480025 Rel-10 WI Multi-standard radio Base Station RF requirements for non-contiguous spectrum deployments (MSR_NC) Justification The impact of passive intermodulation (PIM) on Base Station receiver performance has been extensively discussed in RAN4 in relation to the MSR-NC work. Understand the overall PIM mechanism. including the BS. Consider and develop test methods so the PIM performance can be captured and tested properly 3. Objective: to investigate the passive intermodulation issue from an overall perspective.1. possible counter measures and way forward.247 Overview of 3GPP Release 11 V0. based upon the outcome of study item.9 Study on Passive InterModulation (PIM) handling for for UTRA and LTE Base Stations UID_550021 Resources: UID 550021 R4. Applicability conditions of new PIMrelated requirements will be also investigated and defined.1 (2012-06) 22. since passive intermodulation can be generated in the complete site infra-structure. For this reason.G1 Finish 07/09/201 2 Comp 35% Hyperlink RP120268 Status_Report RP-120582 WI_rapporteur Ericsson Notes Linked to Rel-10 WI on Multistandard radio Base Station RF requirements for non-contiguous spectrum deployments (MSR_NC) UID_480025 TR UTRA. Identify the corresponding requirements needed and their applicability for the BS core and test specifications. NTT DoCoMo. impact and level of degradation considering the PIM performance of the complete site infrastructure. 2. The following specification-related work will be required: • • In the BS-PIM Study Item report. Nokia Siemens Networks. LTE. GERAN 37. It is proposed to primarily focus on the following steps: 1. with the objective to conclude on a way forward for the PIM problem and propose corresponding requirements for the BS specifications. AT&T. the PIM issue needs to be addressed from a broader BS site and infrastructure point view in a separate study item. 3GPP . set in relation to the site infra-structure PIM performance. Telecom Italia. It has been shown that the degradation depends on several factors and can in some cases be quite severe (over 10 dB). identify possible site deployment aspects. It was also concluded that putting requirements only on the BS will not solve the issue. Conclude on reasonable new PIM-related requirements for the BS.

dual stream transmission has to be considered.872 UTRA 25. The motivation of considering a closed loop transmit diversity scheme is that via the Node B knowledge of the channel and feedback of a weight vector.1. the following should be investigated: • Impact on infrastructure implementation • Impact on UE implementation • Impact on performance of UEs not supporting UL MIMO (including legacy UEs) 3GPP . China Unicom. cell edge user throughput. Furthermore. Another advantage of considering UL CLTD is that it offers a framework that can be used to be extended simply towards UL MIMO (dual stream transmission). the UE transmitter can apply the weight vector to achieve the transmit power gains. These potential benefits are highly attractive to operators of HSPA systems. A theoretical gain analysis of CLTD was presented in TR 25. etc) taking the closed loop transmit diversity into account for the following configuration • Up to 2 streams can be transmitted by the UE • UL MIMO transmission only applies to E-DCH physical channels • UL MIMO cannot be configured with DC-HSUPA • UL MIMO is applicable in CELL_DCH only • Both 2x2 and 2x4 configurations should be considered with 2x2 as the baseline scenario Furthermore. due to transmit power limitation. Nokia Siemens Networks. there is a need to ensure that the uplink remains on par to avoid becoming a bottleneck. Deutsche Telekom.871 UTRA 25.1 (2012-06) 23 UID 50001 4 50001 5 53005 7 54002 6 UTRA Studies Name Study on Uplink MIMO Study on HSDPA Multipoint Transmission Study on UE Over The Air (OTA) test method with Head and Hand Phantoms Study on HSPA feedback and signalling efficiency enhancements for LCR TDD Resource R1 R1. ST-Ericsson.1 Study on Uplink MIMO UID_500014 Resources: UID 50001 4 R1 Resource R1 Finish 16/09/201 1 Hyperlink RP101432 Status_Report RP-111048 WI_rapporteur Qualcomm Notes RP#53 completed (1-step Approval) TR UTRA 25. As a result greater spectral efficiency and throughput on the uplink is necessary. In case of a cell edge user.R3 R4.8xy 23.871 Name Study on Uplink MIMO Supporting Companies: Qualcomm.248 Overview of 3GPP Release 11 V0. Interdigital. the user experience is often limited by the UE’s transmitting power. while taking into account the impact on the other aspects such as fairness.g. in their goal of optimizing uplink throughput.914 UTRA 25.R2. video or picture upload). Objective: to study the feasibility and merits of UL MIMO (including improvements in terms of average throughput in a cell. Samsung Justification As HSPA networks continue to evolve and deploy new features improving the spectral efficiency and peak data rates on the downlink. TMobile USA. UL CLTD is a technology of choice to ensure greater spectral efficiency in the UL however in order to further increase the peak and average throughput. The technique of transmit diversity is useful to improve these situations. the need for increased uplink bandwidth becomes more pressing (e. Ericsson. it has to transmit at a low date rate. as phones become hubs of social networking activity. Renesas.R5 R1 WI_rapporteur Qualcomm Nokia Siemens Networks Nokia TD Tech TR UTRA 25. Huawei. For a mobile user in the HSPA cellular system. Telecom Italia.863 and showed significant improvements.

the single cell downlink MIMO (MIMO-Physical layer) feature was introduced in Rel-7. Alcatel-Lucent.1 (2012-06) 23. i. Both these features allow the NodeB to serve one or more users by simultaneous operation of HSDPA on two different carrier frequencies in two geographically overlapping cells. the dual cell HSDPA (DC-HSDPA) and dual band DC-HSDPA features were introduced. • Identify potential standardization impact for HSDPA multipoint transmission operation • Identify impact to implementation that are relevant to the following for both Intra-NodeB and Inter NodeB same frequency cell aggregation and cell switching: a. Single HSDPA transmission from any one of the two cells operating on the same carrier frequency in any given TTI to a particular user.2 Study on HSDPA Multipoint Transmission UID_500015 Resources: UID 50001 5 R1.872 Name Study on HSDPA Multipoint Transmission Supporting Companies: Nokia Siemens Networks. Orange.R3 Finish 16/09/201 1 Hyperlink RP101439 Status_Report RP-111049 WI_rapporteur Nokia Siemens Networks Notes RP#53 completed TR UTRA 25. Huawei. HSPA has begun to be deployed on more than one transmit antenna or more than one carrier. ST-Ericsson. Qualcomm. channel coding of CQI reports and CQI reporting measurement procedures should be reused where possible e. consideration shall also be given to the operation of the HSDPA multipoint transmission method in combination with Rel-10 functionality. the non-serving cell has available resources. When a UE falls into the softer or soft handover coverage region of two cells on the same carrier frequency. Ericsson. ZTE Justification HSPA based mobile internet offerings are becoming very popular and data usage is increasing rapidly. As an example.R2. Telefonica. ME b. when the link from the serving HS-DSCH cell is capacity or interference constrained and the non-serving cell in it’s active set is partially loaded. Subsequently. e. TMobile USA. In addition to a single carrier operation. b. thus improving the user experience across the entire cell coverage area. c. in Rel-8 and Rel-9. Functionality currently defined in DC-HSDPA and/or 4C-HSDPA for e. Deutsche Telekom.e.1. Vodafone. Consequently. Samsung. Telecom Italia. Any impact to legacy terminals from any of the proposed methods should be clarified as part of the study.g. d. RAN 3GPP . This feature allowed a NodeB to transmit two transport blocks to a single UE from the same cell on a pair of transmit antennas thus improving data rates at high geometries and providing a beamforming advantage to the UE in low geometry conditions. Objective • Identify the potential HSDPA multipoint transmission methods and evaluate their system performance and user experience benefits for the following scenarios: a. MCHSDPA+MIMO x 2 sectors.249 Overview of 3GPP Release 11 V0. Simultaneous HSDPA transmission from a pair of cells operating on the same carrier frequency in any given TTI to a particular user. it would be beneficial for the non-serving cell to be able to schedule packets to this UE and thereby improving this particular user’s experience.g.

NodeB has no accurate knowledge about the instant wireless channel of UE and thus can not make the accurate scheduling decision. Research In Motion. such as how to solve the problem the discontinuous CQI feedback will create. Samsung.3 Study on UE Over The Air (OTA) test method with Head and Hand Phantoms UID_530057 Resources: UID 53005 7 R4.114 only includes Head Phantom for the speech mode. China Unicom. Potevio.R5 Finish 07/09/201 2 Comp 95% Hyperlink RP120208 Status_Report RP-120576 WI_rapporteur Nokia Notes RP#56 completion 06/12=>09/12 TR UTRA 25.1. NTT Docomo. Vodafone. In order to improve the downlink peak data rate and throughput of UE. In FDD. some questions occurred and needed to be solved. ZTE. Sony Ericsson. China Mobile. the HS-DSCH TTI is 2-ms while in LCR TDD the HS-DSCH TTI is 5ms. The current OTA test method in TS 34.1 (2012-06) 23. the CQI may be fed back discontinuously. HSPA control channel efficiency optimization For HSPA and multi-carrier HSPA.4 Study on HSPA feedback and signalling efficiency enhancements for LCR TDD UID_540026 Resources: UID 54002 6 R1 Finish 07/09/201 2 Comp 30% Hyperlink RP111766 Status_Report RP-120577 WI_rapporteur TD Tech Notes TR UTRA 25.250 Overview of 3GPP Release 11 V0. the same questions also exist in multi-carrier HSPA. AT&T. The mapping relationship between the traffic channel and the associated control 3GPP . Objective: to further develop User Equipment (UE) / Mobile Station (MS) Over The Air (OTA) antenna test methods in TS 34. 23. In the field test of HSDPA in LCR TDD. the corresponding study shall be done in RAN1 to evaluate the impact the discontinuous CQI feedback will create and if needed find out how to solve the problem the discontinuous CQI feedback will create and evaluate how much gain will be obtained. Due to the fact that multi-carrier HSPA is backward compatible with HSPA. the mapping relationship between the traffic channel and the associated control channel limits the control channel efficiency. New Postcom During the application of HSPA. and Hand Phantom for the data mode. During the CQI feedback interval. Motorola Mobility.8xy Name Study on HSPA feedback and signalling efficiency enhancements for LCR TDD Supporting Companies: Justification China Mobile. T-Mobile US Justification In the Global Certification Forum (GCF) it has been requested to identify a UE OTA antenna test method. CQI is measured by UE and fed back to NodeB on HS-SICH. which includes both Head and Hand Phantoms for additional verification of the UE OTA antenna performance.914 Name Study on UE Over The Air (OTA) test method with Head and Hand Phantoms Supporting Companies: Nokia. the discontinuous CQI feedback will make the peak data rate drop obviously. how to increase the control channel efficiency and how to increase the HSPA resource efficiency. Due to the fact that UE may be scheduled discontinuously. CATR. Some typical questions are illustrated below: CQI feedback enhancement In order to make NodeB HSDPA scheduler adapt to the instant wireless channel of UE.114 with Hand Phantoms in addition to the current Head Phantom for the speech mode. In some scenarios. The traffic channel and the associated control channel are on the same carrier for multi-carrier HSUPA. It’s more urgent in LCR TDD to improve the CQI feedback. the throughput of UE will drop by 10% or more. CATT. Elektrobit.

Furthermore. (3) HSPA signalling enhancements for more efficient resource usage  find out the new methods for more efficient HSPA resource usage  Evaluate how much gain will be obtained with the new methods. the corresponding study shall be done in RAN1 to find out how to improve the HSPA control channel efficiency. 3GPP . For example. It’s more urgent in LCR TDD to improve the HSPA control channel efficiency.  Evaluate how much gain will be obtained with the new methods. Node B can only schedule the rectangular resource to UE. HSPA signalling enhancements for more efficient resource usage For HSPA and multi-carrier HSPA. the impact of the above HSPA enhancements on the existing specifications.1 (2012-06) channel is configured by RNC for multi-carrier HSDPA. It’s more urgent in LCR TDD to improve the HSPA resource efficient.1. (2) HSPA control channel efficiency optimisation  find out the new methods for increasing the HSPA control channel efficiency. the left HSPA resource can not be used fully. the study on HSPA and Multi-carrier HSPA enhancement for the above questions is recommended in this study item. the control channel associated with the traffic channel on this carrier is spare. which may result in the low HSPA resource efficiency in some scenarios. HS-SCCH or E-AGCH.251 Overview of 3GPP Release 11 V0. occupies 1 SF=8 OVSF code while in FDD one control channel occupies 1 SF=128 (HS-SCCH ) or SF=256 (E-AGCH) OVSF code. When no UE is scheduled on one carrier. when UE is scheduled and the HSPA resource left is not rectangular. Based on the above analysis. But it can not be used for the traffic channel on another carrier. Objective: to study the feasibility and merits of the following HSPA enhancements: (1) CQI feedback enhancement  Evaluate the impact the discontinuous CQI feedback will create  If needed. the implementation complexity and backward compatibility should be taken into account. the corresponding study shall be done in RAN1 to find out how to improve the HSPA resource efficiency. in order to improve the peak data rate and throughput of UE. one HSPA control channel. Therefore. Therefore. find out how to solve the problem the discontinuous CQI feedback will create  Evaluate how much gain will be obtained with the new methods. The minimum code unit for HS-PDSCH is 1 SF=16 OVSF code while in TDD the minimum code unit for HS-PDSCH is 1 SF=8 code because of the default K=8 midamble shifts in DL in LCR TDD. In LCR TDD.

C 3.S5.C1.C1.C4 S2.C1 C4.Data Model Definition of the UICC Application for Hosting Party Module Usability improvement of Inter-IMS Network to Network Interface (II-NNI) specification for inter-connection by means of Option Item list enhanced Nodes Restoration for EPC Acronym IPXS SIMTC USSI SIPTO_SC QoS_SSL OSCAR MRB NOVES VINE ACR_CS BBAI eMPS_SRVCC vSRVCC NWK-PL2IMS SAPP VCSG DIDA LOBSTER rSRVCC SaMOG_WLAN RAVEL SEC11 Ext_ATS EMM CVO M3DV OAM11 CH11 IOI_IMS_CH UDC_DM HPM_UICC NNI_OI eNR_EPC Resource S1.132 Enhancements to Multimedia: PSS. Maintenance and Provisioning (OAM&P) Rel-11 Charging Management small Enhancements Transit Inter Operator Identifier for IMS Interconnection Charging in multi operator environment User Data Convergence .IETF S1.C1. MMS.C1.S5.C3.1.S1.S1 C6 C3 C4.C 3.C1.S5.R3 S2.C1. and MBMS Enhancements and Performance Improvements Coordination of Video Orientation Mobile 3D Video Coding Rel-11 Operations.IETF S2 S2.C 4.C 6.C4.131 and TS 26.S1.C3.R2.S1.S5 .C1 S1.C1 WI_rapporteur Telefónica KPN Deutsche Telekom Vodafone Vodafone Vodafone AT&T Qualcomm Tatara Systems Alcatel-Lucent Ericsson NTT DoCoMo Samsung T-Mobile Allot Communications Qualcomm Qualcomm ZTE Orange ZTE Deutsche Telekom Orange.C 4 S2.C4.1 (2012-06) 24 UID 0 47005 1 48003 0 48003 1 49003 0 49003 1 49003 2 53002 1 50003 0 51004 7 52002 8 46002 6 48003 5 50002 6 48003 8 50003 2 50003 3 51004 8 51005 0 53000 1 53004 6 54002 9 52003 0 52003 3 53004 8 56004 0 56004 1 51005 1 51005 2 51002 9 48001 1 51000 4 52000 7 52000 8 Rel-11 Completed Features and Studies Name Release 11 Features Advanced IP Interconnection of Services System Improvements to Machine-Type Communications Unstructured Supplementary Service Data (USSD) simulation service in IMS SIPTO Service Continuity of IP Data Session QoS Control Based on Subscriber Spending Limits Optimized Service Charging and Allocation of Resources in IMS whilst Roaming Inclusion of Media Resource Broker (Stage 2/3) Non Voice Emergency Services Support for 3GPP Voice Interworking with Enterprise IP-PBX Anonymous Call Rejection in the CS domain Support for BroadBand Forum Accesses Interworking Single Radio Voice Call Continuity (SRVCC) aspect of enhancements for Multimedia Priority Service Single Radio Video Call Continuity for 3G-CS Network Provided Location Information for IMS (NETLOC) Service Awareness and Privacy Policies VPLMN Autonomous CSG Roaming Data Identification in Access Network Discovery and Selection Function (ANDSF) LOcation-Based Selection of gaTEways foR WLAN Single Radio Voice Call Continuity from UTRAN/GERAN to EUTRAN/HSPA S2a Mobility based On GTP and WLAN access to EPC Roaming Architecture for Voice over IMS with Local Breakout Rel-11 Security small Enhancements Extensions of Acoustic Test Specifications in TS 26.S1.C1 S2.C3 S2.C4.C4 S2.R 5 S4 S4 S4 S4 S5 S5 S5.C4.IETF S2.C4.C3 S1 S1. Qualcomm Qualcomm Ericsson Orange Deutsche Telekom Telecom Italia Gemalto NTT ZTE 3GPP .C1.S2.R2.C 3.C 3 S1.C1 S2.252 Overview of 3GPP Release 11 V0.C 3 S1.C3.C3 S2.S2 S1.S3.G2.C1. Administration.R3 S1.C3.C 3 S3.S2.S2 C1.S2.C1.C4.

1.IETF C1 C1.C4.C3 S2.C3.1 (2012-06) RLI IMSProtoc5 SIRIG EMC_PC SAES2 RT_VGCS_Red GINI eMPS_Gateway NNI_timers ATURI PSAN GenUG_Sh C4.C3 C3 C1 C4 C4 Huawei Alcatel-Lucent China Mobile Ericsson Nokia Siemens Networks Nokia Siemens Networks Deutsche Telekom Telcordia Telecom Italia Intel Deutsche Telekom Alcatel-Lucent 3GPP .G 2 C1.C4 C1 C4.C1 C1.253 52000 9 52001 0 53000 3 53001 8 53001 9 53002 0 54001 5 54001 7 55000 7 56000 5 56000 6 56000 7 Reference Location Information IMS Stage 3 IETF Protocol Alignment .C3.phase 5 Service Identification for RRC Improvements in GERAN (Stage 2/3) IMS Emergency PSAP Callback (Stage 3) SAE Protocol Development GCSMSC and GCR Redundancy for VGCS/VBS (Stage 2/3) Support of RFC 6140 in IMS Enhancements for Multimedia Priority Service (MPS) – Gateway Control Priority Inter-IMS Network to Network Interface (II-NNI) enhancements: SIP timers applicability (Stage 3) AT commands for Universal Resource Identifier (URI) support PS Additional Number (Stage 3) Generic IMS User Group Over Sh Overview of 3GPP Release 11 V0.

R2 R4 R4 R4.Lower Band for Region 2 (non-US).R3.R3.R5 R3.R4 R4 R2 R1.R2 R4 R4 R4 R4 R1.R1.R3.R3. Band 27 Carrier based HetNet ICIC for LTE LTE Advanced Carrier Aggregation in Band 38 LTE Advanced Carrier Aggregation in Band 41 LTE for 700 MHz Digital Dividend Relays for LTE (part 2) LTE Advanced Carrier Aggregation of Band 3 and Band 20 LTE Advanced Carrier Aggregation of Band 8 and Band 20 LTE Advanced Carrier Aggregation of Band 1 and Band 7 LTE Advanced Carrier Aggregation of Band 3 and Band 5 Acronym Resource WI_rapporteu r Alcatel-Lucent Vodafone Kapsch Carriercom Sprint Nokia Siemens Networks MediaTek Vodafone Ericsson Ericsson TruePosition Huawei TeliaSonera AT&T Ericsson Nokia Leap Wireless US Cellular Huawei AT&T AT&T AT&T China Mobile AT&T Research In Motion NII Holdings Nokia Siemens Networks Huawei Clearwire Ericsson Ericsson Vodafone Vodafone China Telecom SK Telecom Full_MOCNGERAN GDSAC RT_ERGSM e850_UB SONenh2_LTE_U TRA eMDT_UMTSLTE HSPA_LTE_meas RP_MIMO medBS_class_LT E_MSR MRLA LCS_LTE-NBPS MBMS_LTE_SC LTE_CA_B3_B7 LTE_CA_B4_B17 LTE_CA_B4_B13 LTE_CA_enh LTE_CA_B4_B12 LTE_CA_B5_B12 LTE_CA_B7_B20 LTE_CA_B2_B17 LTE_CA_B4_B5 LTE_CA_B5_B17 eICIC_enh_LTE LTE_DL_FDD700 LTE_eDDA LTE_e850_LB LTE_CA_HetNet_I CIC LTE_CA_B38 LTE_CA_B41 LTE_APAC700 LTE_Relay2 LTE_CA_B3_B20 LTE_CA_B8_B20 LTE_CA_B1_B7 LTE_CA_B3_B5 G2.C1 R4.R2.R4 R4 R4.R3.R5 R4 R4 R4 R4 R4 3GPP .254 Overview of 3GPP Release 11 V0.R4 R2.R2 R4.R4.R2.C1 G2 G1.R3.R2.R5 R3.G1 G1 R2.1.R1.S2.R2 R2.R2.R2.1 (2012-06) UID 0 51000 1 55002 3 53000 2 50002 0 53003 0 53003 3 55001 6 53003 7 54000 3 43001 1 48002 6 48002 3 50001 7 50001 8 51003 0 51002 2 51002 3 51002 4 51002 5 51002 6 51002 7 51002 1 51002 8 51003 1 51003 2 51003 3 52001 5 52001 6 52001 7 52001 9 53002 3 53002 4 53002 5 53002 6 Name Release 11 GERAN/RAN Features Full Support of Multi-Operator Core Network by GERAN Domain Specific Access Control in GERAN Introduction of ER-GSM band for GSM-R Extending 850 MHz Upper Band (814 – 849 MHz) Further Self Optimizing Networks (SON) enhancements Enhancement of Minimization of Drive Tests for E-UTRAN and UTRAN Verification of radiated multi-antenna reception performance of UEs in LTE/UMTS E-UTRA medium range and MSR medium range/local area BS class requirements Medium range/local area requirements for multicarrier BTS Network-Based Positioning Support in LTE Service continuity improvements for MBMS for LTE LTE Advanced Carrier Aggregation of Band 3 and Band 7 LTE Advanced Carrier Aggregation of Band 4 and Band 17 LTE Advanced Carrier Aggregation of Band 4 and Band 13 LTE Carrier Aggregation Enhancements LTE Advanced Carrier Aggregation of Band 4 and Band 12 LTE Advanced Carrier Aggregation of Band 5 and Band 12 LTE Advanced Carrier Aggregation of Band 7 and Band 20 LTE Advanced Carrier Aggregation of Band 2 and Band 17 LTE Advanced Carrier Aggregation of Band 4 and Band 5 LTE Advanced Carrier Aggregation of Band 5 and Band 17 Further Enhanced Non CA-based ICIC for LTE New Band LTE Downlink FDD 716-728 MHz LTE RAN Enhancements for Diverse Data Applications LTE E850 .R4 R4.R1.R3 R4 R4 R4 R1.

R2.R2 R3.R4 R1.R3.R2.R1.R2 R4.R4 R4.28Mcps TDD Uplink Transmit Diversity for HSPA Introduction of New Configuration for 4C-HSDPA Non-contiguous 4C-HSDPA operation Further Enhancements to CELL_FACH HSDPA Multiflow Data Transmission Four Branch MIMO transmission for HSDPA MIMO with 64QAM for HSUPA HSDPA Dual-Band Multi-Carrier combinations Further enhancements to H(e)NB mobility .R2.R4 R1.R3.Part 1 Further enhancements to H(e)NB mobility .R2. Huawei China Mobile KDDI KDDI NTT DoCoMo NTT DoCoMo Alcatel-Lucent Motorola Solutions Renesas Mobile China Mobile LightSquared CATR Ericsson China Mobile Huawei Telus Communicatio ns Ericsson Qualcomm Nokia Siemens Networks Ericsson Nokia Siemens Networks Ericsson Alcatel-Lucent Alcatel-Lucent - Signalling and Procedure for Interference Avoidance for in-device coexistence Coordinated Multi-Point Operation for LTE Network Energy Saving for E-UTRAN LTE Advanced Carrier Aggregation of Band 11 and Band 18 LTE Advanced Carrier Aggregation of Band 1 and Band 18 LTE Advanced Carrier Aggregation of Band 1 and Band 19 LTE Advanced Carrier Aggregation of Band 1 and Band 21 Enhanced downlink control channel(s) for LTE Advanced Public Safety Broadband High Power UE for Band 14 for Region 2 Improved Minimum Performance Requirements for E-UTRA: Interference Rejection Additional special subframe configuration for LTE TDD LTE in the 1670-1675 MHz Band for US UE Over The Air (Antenna) conformance testing methodology Laptop mounted equipment Free Space test Eight carrier HSDPA UE demodulation performance requirements under multiple-cell scenario for 1.R2 R4.R3 R1.R4 R3 R4.R2 R1.R4 R4.R3.R2.1.255 53002 7 53002 8 53003 1 53003 2 53003 6 54002 0 54002 1 54002 2 54002 3 54002 5 55001 2 55001 3 55001 4 55001 7 45001 6 50001 9 50002 1 50002 2 51001 8 51001 9 51002 0 53003 4 53003 5 54000 9 54002 4 56001 3 56001 4 48000 4 56000 1 LTE Advanced Carrier Aggregation of Band 4 and Band 7 LTE Advanced Carrier Aggregation in Band 7 Overview of 3GPP Release 11 V0.1 (2012-06) LTE_CA_B4_B7 LTE_CA_B7 SPIA_IDC_LTE COMP_LTE Netw_Energy_LT E LTE_CA_B11_B1 8 LTE_CA_B1_B18 LTE_CA_B1_B19 LTE_CA_B1_B21 LTE_enh_dl_ctrl LTE_B14_PSBB_ HPUE LTE_Interf_Rej LTE_TDD_add_su bframe LTE_FDD_1670_ US UEAnt_FSTest 8C_HSDPA LCR_TDD_UE_de mod_mc HSPA_UL_TxDiv 4C_HSDPA_Confi g NC_4C_HSDPA Cell_FACH_enh HSDPA_MFTX 4Tx_HSDPA MIMO_64QAM_H SUPA HSDPA_DB_MC EHNB_enh1 EHNB_enh2 TEI11 TEI11_Test R4 R4 R2.R3 R4.R2 R4.R2.R3.(Small) Technical Enhancements and Improvements for Rel-11 3GPP .R2.R4.R4 R4 R4 R4.R2 All R5.R2 R4.R3.R3 R4.R3 R4.R2 R3.Part 2 (Small) Technical Enhancements and Improvements for Rel-11 Test .G3new Rogers Wireless China Unicom China Mobile Samsung.R4 R1.R4 R2.R2.R5 R1.R2.R2.R3.R5 R1.

S2 S1 S2 S2.based on SIP Digest Study on Mobile 3D Video Coding Study on version handling Study on Management of Converged Networks Study on User Data Convergence (UDC) information model handling and provisioning: Example Use Cases Study on OAM aspects of inter-RAT Energy Saving Study on impacts on UE-Core Network signalling from Energy Saving Study on EPC Nodes Restoration Acronym FS_IMS_P2P FS_NOVES FS_VINE FS_INIPUI FS_eIMS FS_PP FS_IP6M FS_rSRVCC FS_RAVEL FS_UKM FS_SSO_APS FS_M3DVC FS_OAM_VH FS_ManCon FS_UDC_AppUseCase FS_OAM_ES_iRAT FS_UE-CN_ES FS_EPC_NR Resource S1.1.S1 S2 S2 S2 S3 S3 S4 S5 S5 S5 S5 C1 C4 WI_rapporteur China Mobile Qualcomm Tatara Systems Vodafone China Mobile AT&T China Mobile Orange Deutsche Telekom Ericsson Nokia Orange Ericsson Nokia Siemens Networks Alcatel-Lucent Nokia Siemens Networks NEC ZTE 3GPP .S2 S1 S1.1 (2012-06) UID 0 450047 460024 480033 490033 410041 440047 440048 460030 510044 380084 480048 520036 470050 480047 490039 510045 480015 490014 Name Release 11 Studies Study on IMS based Peer-to-Peer Content Distribution Services Study on Non Voice Emergency Services Study on Support for 3GPP Voice Interworking with Enterprise IP-PBX Study on IMS Network-Independent Public User Identities Study on IMS Evolution Study on Policy solutions and enhancements Study on IPv6 Migration Study on Single Radio Voice Call Continuity from UTRAN/GERAN to E-UTRAN/HSPA Study on Roaming Architecture for Voice over IMS with Local Breakout Study on UTRAN key management enhancements Study on Single Sign On (SSO) Application Security for IMS .256 Overview of 3GPP Release 11 V0.

R5 R1 NTT DoCoMo Vodafone Ericsson Huawei Spirent Alcatel-Lucent NTT DoCoMo Huawei Ericsson Qualcomm Nokia Siemens Networks Nokia TD Tech 3GPP .G2.R2 R3.G2 G1.1. Korea) Study on RF and EMC requirements for active Antenna Array System (AAS) Base Station Study on Passive InterModulation (PIM) handling for UTRA and LTE Base Stations Study on Uplink MIMO Study on HSDPA Multipoint Transmission Study on UE Over The Air (OTA) test method with Head and Hand Phantoms Study on HSPA feedback and signalling efficiency enhancements for LCR TDD Acronym FS_NIMTC_GERAN FS_SPEED FS_Energy_BTS FS_eVAMOS FS_GERAN_eMDA FS_CoMP_LTE FS_SPIA_IDC FS_LCS_LTE_RFPMT FS_HetNet_eMOB_LTE FS_LTE_eDL_MIMO_enh FS_B800_B900_Interf_LTE FS_LTE_TDD_eIMTA FS_LC_MTC_LTE FS_Cov_Enh_LTE FS_LTE_mobRelay FS_LTE_HRPD_SON FS_LTE_OTA Resource G1.R1.R3 R2.R2.R2.R4 R4 R2.R1.R1 R4 R4 R2.R3.R4 R3.1 (2012-06) UID 0 46000 1 48000 3 49000 6 52000 1 52000 2 47001 4 48002 8 50001 6 51003 4 51003 7 51003 8 51003 9 53005 2 53005 3 53005 4 55002 0 55002 2 53005 5 43002 0 44001 6 45001 5 50000 2 51003 6 52001 8 53005 6 55002 1 50001 4 50001 5 53005 7 54002 6 Name Release 11 GERAN/RAN Studies Study on GERAN improvements for MachineType Communications Study on Signal Precoding enhancements for EGPRS2 DL Study on Solutions for GSM/EDGE BTS Energy Saving Study on Voice services over Adaptive Multiuser channels on One Slot (VAMOS) enhancements Study on GERAN enhancements for Mobile Data Applications Study on Coordinated Multi-Point operation for LTE Study on Signalling and procedure for interference avoidance for in-device coexistence Study on Inclusion of RF Pattern Matching Technologies as a positioning method in the EUTRAN Study on HetNet mobility enhancements for LTE Study on further Downlink MIMO enhancements for LTE-Advanced Study on Interference analysis between 800~900 MHz bands Study on Further Enhancements to LTE TDD for DL-UL Interference Management and Traffic Adaptation Study on Provision of low-cost MTC UEs based on LTE Study on LTE Coverage Enhancements Study on Mobile Relay for E-UTRA Study on LTE-HRPD (High Rate Packet Data in 3GPP2) inter-RAT SON Study on Measurements of radio performances for LTE terminals .R4 R1.R2 R4 R4.R4 R3 R4 WI_rapporteur Ericsson Ericsson Nokia Siemens Networks.G1 G2.G2 GP. Vodafone China Mobile. Huawei Huawei Samsung China Mobile Polaris Wireless Alcatel-Lucent Alcatel-Lucent LG Uplus CATT Vodafone China Telecom CATT China Telecom CATR FS_enh_perf_UE_LTE FS_HSPA_LTE_measRP_MI MO_multi-antenna FS_e850 FS_NIMTC_RAN FS_UE_App_Data_Perf FS_EHNB_enh FS_UTRA_LTE_900MHz FS_AAS_BS_LTE_UTRA FS_BS_PIM FS_UTRA_UL_MIMO FS_HSDPA_MP_TX FS_OTA_phantoms_UTRA FS_LCRTDD_HSPAenh R4.G2 G1.R4 R1.G1 R1.R4 R1 R4 R1.R4 R5.R1.Total Radiated Power (TRP) and Total Radiated Sensitivity (TRS) test methodology Study on Enhanced performance requirement for LTE UE Study on Measurement of Radiated Performance for MIMO and multi-antenna reception for HSPA and LTE terminals Study on Extending 850 MHz Study on RAN improvements for Machine-Type Communications Study on UE Application Layer Data Throughput Performance Study on further enhancements for HNB and HeNB Study on UMTS/LTE in 900 MHz band (Japan.R1 R4.257 Overview of 3GPP Release 11 V0.R3.R2.R2.R3 R4.G1 R1 R1.

1.1 (2012-06) 25 UID 0 540016 0 510035 Rel-11 Deleted Features and Studies Name Release 11 Features Deleted .RP C4.C1 SP.RP R1 WI_rapporteur Alcatel-Lucent Huawei 3GPP .GP.CP.258 Overview of 3GPP Release 11 V0.CP.GP.Study on Enhanced Uplink Transmission for LTE Acronym PROTOC_SMS_SGs FS_eUL_TX_LTE Resource SP.Enhancement of the Protocols for SMS over SGs (Stage 3) Release 11 Studies Deleted .

2 0. Provide reference material for IMS based non-UICC based SSO to applications SP#56 completed.0. Stage 1 was frozen Sep 2011 2012-01 Post-TSG#54 updates 2012-03 Post-TSG#55 updates. Korea) UID_520018 RP#56 completed. TR 36.1 (2012-06) Annex A: Change history Change history Date 2009-12 2010-04 2010-06 2010-09 2011-02 2011-04 2011-06 2011-09 Subject/Comment 1st draft despatched to TSG#47 for input / comment Post-TSG#47 updates Post-TSG#48 updates Post-TSG#49 updates Post-TSG#50 updates Post-TSG#51 updates Post-TSG#52 updates Post-TSG#53 updates.914v200 approved (converted 33.803 v200 for Approval Alcatel-Lucent 3GPP .1 0.7 0.0 0.804). Impacts TR 37. Stage 2 was frozen Mar 2012 2012-06 Post-TSG#56 updates Ver. SP#55 TR 33.0.0.5 0.3 0.6 0. TR 37.259 Overview of 3GPP Release 11 V0. Study reuse of non-UICC credentials (in particular SIP Digest) to provide security for access to applications.824 v200 for Approval RP#56 completed.R2 China Telecom RP#56 completed. Extends Rel-10 work on 3D video formats UID_480044 Improved Video Coding Support for PSS and MBMS S3 52003 6 Study on Mobile 3D Video Coding S4 Orange Release 11 RAN Studies UID 51003 8 Name Study on Interference analysis between 800~900 MHz bands Study on Further Enhancements to LTE TDD for DL-UL Interference Management and Traffic Adaptation Study on LTE Coverage Enhancements Study on further enhancements for HNB and HeNB Resource WI_rapporteur LG Uplus Notes RP#56 completed.0.1.1.0.0.0.8 0.0.1 TSG#56 completed Rel-11 Studies Release 11 Studies (non-RAN) UID 48004 8 Name Study on Single Sign On (SSO) Application Security for IMS based on SIP Digest Resource WI_rapporteur Nokia Notes SP#56 completed.4 0. TR 36.9 0.R2 R3.1.828 for Information and Approval R4 51003 9 R1. 0.0.804 Study on UMTS/LTE in 900 MHz band (Japan.R4 CATT 53005 3 51003 6 R1.

1. TR 24.302 (on access authentication & authorization and tunnel management.839 v100 for Information and Approval 55000 5 TR on Stage 3 BB I for BBAI.820 v100 for Information and Approval. Huawei SP#56 completed 52000 4 QoS_SSL-CT3 C3 Huawei CP#56 completed 47002 3 BBAI S2 Ericsson SP#56 completed 53011 2 BBAI_BBI-CT C1 Ericsson CP#56 completed. TR 3GPP .804 v100 for Information and Approval. Linked to Study on Interference analysis between 800~900 MHz bands UID_510038 Study on UMTS/LTE in 900 MHz band (Japan. UE to network protocols Acronym SIMTC-RAN_OC Resource WI_rapporteur Ericsson Notes CP#56 completed C1 49003 1 QoS_SSL S1. Updated WID RP111751=>RP-120617. security aspects) CP#56 completed.C3 Vodafone TSG#56 completed 50002 9 QoS_SSL S5 Nokia Siemens Networks.S2. IP mobility mode selection. TR 37.S5. TR 29. Home (e)Node B – Security Gateway Interface Stage 2 BB II: BBF interworking with offload in access network for WLAN and for H(e)NB TR on Stage 3 BB II BBAI_BBI-CT C4 Ericsson 47002 4 BBAI S2 Ericsson SP#56 completed 53011 BBAI_BBII-CT C1 Ericsson CP#56 completed. Identify additional FMC specific procedures in addition to those in 24. Korea) R4 NTT DoCoMo TSG#56 completed/stopped Rel-11 Features Release 11 Features (non-RAN) UID 53030 9 Name CT1 part of Stage 3 Extended Access Barring for UTRAN and E-UTRAN QoS Control Based on Subscriber Spending Limits Charging for QoS Control Based on Subscriber Spending Limits (Stage 2) CT3 aspects of QoS Control Based on Subscriber Spending Limits (Stage 3) Stage 2 BB I: BBF interworking with home routed traffic for WLAN and H(e)NB TR on Stage 3 BB I for BBAI.1 (2012-06) RP#56 completed.260 52001 8 Overview of 3GPP Release 11 V0.

Updated WID CP-110803=>CP-120252 (no CT1 impact) CP#56 completed 54001 0 CT aspects of LOcation-Based Selection of gaTEways foR WLAN CT4 part of CT aspects of LOcationBased Selection of gaTEways foR WLAN Deleted .C4 ZTE CP#56 completed.C1. Provide Single Radio VIDEO Call Continuity from E-UTRAN to UTRAN-CS based on the agreed architecture alternative in TR 23.CT1 part of CT aspects of LOcation-Based Selection of gaTEways foR WLAN CT1 part of CN aspects of Mobility based On GTP & PMIPv6 for WLAN access to EPC CT3 part of CN aspects of Mobility based On GTP & PMIPv6 for WLAN access to EPC LOBSTER-CT C4 ZTE 54011 0 LOBSTER-CT C4 ZTE 54021 0 LOBSTER-CT C1 ZTE CP#56 stopped. Related to UID_350027 SAE for support for non3GPP accesses (SAESSA-FP_n3GPP).1.261 3 Overview of 3GPP Release 11 V0. Updated WID CP-110803=>CP120252 (no CT1 impact) 54021 1 SaMOG_WLAN-CN C1 Alcatel-Lucent CP#56 stopped (no CT1 impact) 54031 1 SaMOG_WLAN-CN C3 Alcatel-Lucent CP#56 completed 3GPP .C4 NEC 52010 5 vSRVCC-CT C1 NEC 55020 8 NWK-PL2IMS-CT C4 Huawei CP#56 completed 51005 0 LOBSTER S2. Updated WID CP-110757=>CP-120278 CP#56 completed 52000 5 CN aspects of Single Radio Video Call Continuity for 3G-CS CT1 aspects of Single Radio Video Call Continuity for 3G-CS CT4 part of CT aspects of Network Provided Location Information for IMS LOcation-Based Selection of gaTEways foR WLAN vSRVCC-CT C1. CP#56 completed.C4 Samsung CP#56 completed. UE to network protocols Single Radio Video Call Continuity for 3G-CS vSRVCC 50002 6 S2.1 (2012-06) 24. CP#56 completed. Enhancements to ePDG and PDN GW selection functions for S2b and S2c based on UE location Stage 3.C3.C3.886 Stage 3. for 3GPP System to Fixed Broadband Access Network Interworking.820 v100 for Information and Approval.

1 (2012-06) PIDS. Stage 1 in SA1 22. Updated WID CP-110640=>CP-120279 54001 6 PROTOC_SMS_SGs C4.TR Study on enhancement of protocols for SMS service over SGs Deleted .CT4 part of Enhancement of the Protocols for SMS over SGs LI11 S3 S5. TS 31.C1 Stage 1/2/3.S1. CP#56 completed. Stage 3 (No architectural change.262 52003 2 51002 9 Overview of 3GPP Release 11 V0. specify the list of selectable items related to control plane signalling directly for the same architecture) 52000 7 NNI_OI C3 NTT 55000 9 SIRIG C3 China Mobile CP#56 stopped (SA2 decided NO CT3 impact) 53022 0 RT_VGCS_Red C4 Nokia Siemens Networks CP#56 stopped (no CT4 impact). Defines Stage 3 for UICC application residing in Hosting Party Module CP#56 completed.CT4 part of GCSMSC and GCR Redundancy for VGCS/VBS Deleted Enhancement of the Protocols for SMS over SGs (Stage 3) Deleted .115 IOI_IMS_CH 52000 6 IOI_IMS_CH C1 Deutsche Telekom CP#56 completed 51000 4 HPM_UICC C6 Gemalto CP#56 completed.C1 Alcatel-Lucent CP#56 work stopped due to enhancements to SIMTC WID 54011 6 PROTOC_SMS_SGs C4 Alcatel-Lucent CP#56 work stopped due to enhancements to SIMTC WID 54021 6 PROTOC_SMS_SGs C4 Alcatel-Lucent CP#56 work stopped due to enhancements to SIMTC WID 3GPP .CT3 part of CN aspects of Service Identification for RRC Improvements in GERAN Deleted . SP#56 completed Stage 2/3.104 v200 for Approval.1. AlcatelLucent Deutsche Telekom Lawful Interception in the 3GPP Rel-11 Transit Inter Operator Identifier for IMS Interconnection Charging in multi operator environment Stage 3 for Transit Inter Operator Identifier for IMS Interconnection Charging in multi operator environment Definition of the UICC Application for Hosting Party Module Usability improvement of Inter-IMS Network to Network Interface (IINNI) specification for inter-connection by means of Option Item list Deleted .

263 54031 6 Overview of 3GPP Release 11 V0.CT1 part of Enhancement of the Protocols for SMS over SGs PROTOC_SMS_SGs C1 CP#56 work stopped due to enhancements to SIMTC WID Release 11 RAN Features UID 51013 2 51023 2 52011 7 Name Core part: LTE E850 .R2. part: LTE Advanced Carrier Aggregation of Band 1 and Band 19 Introduction of New Configuration for 4C-HSDPA Perf.820 v100 for Information and Approval RP#56 completed Stage 3.R2 R4 Telus Communications Telus Communications RP#56 Perf completed RP#56 completed TSG#56 New Rel-11 Features) Release 11 Features (non-RAN) UID 5600 02 Name Stage 2/3 for SMS in MME architecture option and related PS-only service subscription Acronym SIMTC-PS_Only Resou rce C1. RP#56 completed R1. Band 27 Perf.C4 Hyperl ink CP120418 WI_rappo rteur Ericsson Notes New Stage 2 i/f btw MME & SMS central functions requires a Diameter based protocol as it applies to MME. part: LTE for 700 MHz Digital Dividend LTE Advanced Carrier Aggregation of Band 1 and Band 19 Core part: LTE Advanced Carrier Aggregation of Band 1 and Band 19 Perf.1.R2.Lower Band for Region 2 (non-US).R 4 R4 R4. part: Introduction of New Configuration for 4C-HSDPA Resource WI_rapporteur NII Holdings Notes RP#56 completed RP#56 completed RP#56 completed.R 3 R4 R4.1 (2012-06) Alcatel-Lucent Deleted .R2 R4. RP#56 completed.Lower Band for Region 2 (non-US). Band 27 Core part: LTE for 700 MHz Digital Dividend Perf.R2 NII Holdings Ericsson 52021 7 54002 2 54012 2 Ericsson NTT DoCoMo NTT DoCoMo 54022 2 R4 NTT DoCoMo RP#56 completed 51001 8 51021 8 R4. part: LTE E850 . CP#56 updated WID CP110756=>CP-120276 5601 02 CT1 part of Stage 2/3 for SMS in MME architecture option and related PS-only service SIMTC-PS_Only C1 CP120418 Ericsson 3GPP . need not deploy Diameter based solution & MAP if only SMS via PS req. LTE operators with SMS in MME architecture but w/o 3GPP 2G/3G services (CDMA). TR 36.

1. 35. VoLTE).251CR0063 (SIRIG support in shared networks)] GP#54 updated WID GP111459=>GP-120737 (added CT4 part 23. 27.g. but GWCN is not yet supported on GERAN. SP-120252 [23. Extend Full_MOCN-GERAN to also cover GWCN GERAN Define new AT comds for URI addresses for IMS services (e.251CR0062R2 as TEI11).221. addressing and identification) 5600 41 5600 08 Mobile 3D Video Coding Stage 2 for Service Identification for RRC Improvements in GERAN CT4 part of CN Stage 3 for Full Support of MultiOperator Core Network by GERAN Stage 2 for Gateway Core Network Sharing for GERAN M3DV S4 SP120229 not applica ble Orange SIRIG S2 - 5600 04 Full_MOCNGERAN C4 GP120737 AlcatelLucent 5600 42 Full_MOCNGERAN-GWCN S2 SP120268 Vodafone Stage 2.401. 35.003 Numbering. new (35.905.1 (2012-06) subscription 5602 02 CT4 part of Stage 2/3 for SMS in MME architecture option and related PS-only service subscription CT3 part of Stage 3 for Inclusion of Media Resource Broker (IETF) CT4 part of CN aspects of Mobility based On GTP & PMIPv6 for WLAN access to EPC Conformance Test Aspects – ZUC (EEA3 and EIA3 Encryption & Integrity EPS security Algorithms Coordination of Video Orientation SIMTC-PS_Only C4 CP120418 Ericsson CP#56 updated WID CP110756=>CP-120276 5600 03 MRB C3 CP120277 AT&T CP#56 updated WID CP110642=>C1-121669 (added CT3 part) 5610 10 SaMOG_WLAN-CN C4IETF CP110802 Lionel Morand CP#56 added IETF dependency.222. Work in progress (Introduced with C4-120828) 5600 09 EEA3_EIA3_UECo nTest R5 RP120631 CATR Testing for SA3 TSs 33.005 (AT commands 5600 05 AT commands for Universal Resource Identifier (URI) support ATURI C1 CP120275 Intel 3GPP .264 Overview of 3GPP Release 11 V0.060CR1680 (Introduction of SIRIG). 27. SP#56 completion 06=>09/12 (23.251 specifies both MOCN and GWCN for E-UTRAN and UTRAN.007 (AT comds to control MT functions and GSM/UMTS/LTE network services from TE. TS 23. 23.223) 5600 40 CVO S4 SP120228 Ericsson resolve backward compatible video orientation mis-alignment issues in MTSI real-time video communication via interaction between MTSI video clients at call setup & during mid-call of the video orientation for correct local rendering Triggered by UID_520036 Rel-11 Study on Mobile 3D Video Coding (FS_M3DVC) TR 26.

2).7.222.Part 2 Acronym EHNB_en h1 Resou rce R3.R2 Hyperl ink RP12090 0 WI_rappo rteur AlcatelLucent Notes Stage 2/3. 35.401. Currently address types for AT comds based on dialling # 5600 06 5600 07 PS Additional Number (Stage 3) Generic IMS User Group Over Sh PSAN C4 CP120253 CP120254 Deutsche Telekom AlcatelLucent Stage 1 in Rel-11 SA1 TS 22.223) - 560010 560011 560001 LTE_e850_LB-UEConTest LTE_APAC700-UEConTest TEI11_Test R5 R5 R5.R2 RP12090 1 AlcatelLucent Stage 2/3.3.1.Lower Band for Region 2 (non-US).803 under AI 12.1 (2012-06) for SMS). new (35. LTE TR 37.(Small) Technical Enhancements and Improvements for Rel-11 Acronym EEA3_EIA3_UEConTest Resource R5 WI_rapporteur CATR Notes Testing for SA3 TSs 33.265 Overview of 3GPP Release 11 V0.803 under AI 12.3. Compare also Rel-10 WI HNB_HENB_mob_enh RP-110183 - 5601 13 EHNB_en h1-Core R3. 35.G3new NII Holdings Ericsson - TSG#56 New Rel-11 IETF dependency UID 561010 Name (IETF) CT4 part of CN aspects of Mobility based On GTP & PMIPv6 for WLAN access to EPC (SaMOG_WLAN-CN) Resource C4-IETF TSs_and_TRs IETF Draft draft-ietf-radextieee802ext-01 (RADIUS Attributes for 802 Networks) 3GPP .221. Triggered by FS_EHNB_enh (UTRA.R2 RP12090 0 AlcatelLucent 5600 14 EHNB_en h2 R3.2) 5601 14 EHNB_en h2-Core R3.R2 RP12090 1 AlcatelLucent - TSG#56 New Rel-11 Testing UID 560009 Name Conformance Test Aspects – ZUC (EEA3 and EIA3 Encryption & Integrity EPS security Algorithms Test part: LTE E850 . LTE TR 37.3 (No Stage 2 needed since no architecture impact) - GenUG_Sh C4 Release 11 RAN Features UID 5600 13 Name Further enhancements to H(e)NB mobility Part 1 Core part: Further enhancements to H(e)NB mobility . Triggered by FS_EHNB_enh (UTRA.Part 1 Further enhancements to H(e)NB mobility Part 2 Core part: Further enhancements to H(e)NB mobility . Band 27 Test part: LTE for 700 MHz Digital Dividend Test .101 clause 17.