1

Overview of 3GPP Release 7 V0.9.10 (2010-06)

Contents

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

3 Abbreviations.........................................................................................................................................7 4 IMS8
4.1 Identification of Communication Services in IMS (ServID) UID_732097..........................................................8 4.2 Supporting Globally Routable User Agent URIs in IMS (GRUU) UID_32116..................................................9 4.3 Multimedia Telephony Service for IMS (MTSI) UID_7038..............................................................................10 4.3.1 Multimedia Telephony Service for IMS (MTSI) - UE Conformance Testing UID_350147..........................11 4.4 TISPAN requirements for Multimedia Telephony with PSTN/ISDN simulation services (TMMTEL7) UID_377001..............................................................................................................................................11 4.5 Maintenance of TISPAN release 1 common IMS (MCIMSTR1) UID_387001.................................................12 4.6 Maintenance of TISPAN documentation (MAINTISP) UID_380069...............................................................13 4.6.1 Maintenance of TISPAN R1 (MAINT_R1) UID_380004................................................................................13 4.6.2 Maintenance of TISPAN release 1 common IMS (IMS_Comm_Mtce7) UID_380072...................................14 4.7 PS domain and IMS impacts for supporting IMS Emergency calls (EMC1) UID_32045..................................15 4.8 IMS Support of Conferencing (IMSconf) UID_11065.......................................................................................16 4.9 Performance Characterization of VoIMS over HSDPA\EUL channels (VoIMS-PCVoIMS) UID_34033........17

5 IWLAN................................................................................................................................................18
5.1 WLAN-UMTS Interworking Phase 2 (WLAN2) UID_31062...........................................................................18 5.2 WLAN Interworking – Private Network access from WLAN 3GPP IP Access (WLANPNA) UID_32110.....18 5.3 Enhancements to support QoS provisioning over 3GPP/WLAN Interworking (WLANQOS) UID_32092......19

6 Location Services.................................................................................................................................21
6.1 Location Services enhancements (LCS3) UID_32079.......................................................................................21 6.1.1 LCS Enhancements Related to Location-Based Services (LCS3-LBS) UID_50558, 14025, 20042..............21 6.1.2 Inclusion of Uplink TDOA UE positioning method in the UTRAN specifications UID_20012....................22 6.1.3 LCS for 3GPP Interworking WLAN (LCS3-IWLAN) UID_31052................................................................22 6.2 Advanced Global Navigation Satellite System (A-GNSS) concept (LCS3-AGNSS) UID_31051....................23 6.2.1 Towards A-GNSS Concept UID_50548..........................................................................................................23 6.2.2 Global Navigation Satellite System (GNSS) in UTRAN UID_20050............................................................24 6.3 A-GPS Minimum Performance (GAGR) UID_50581........................................................................................25

7 MBMS.................................................................................................................................................26
7.1 MBMS Enhancements (MBMSE) UID_31084..................................................................................................26 7.1.1 MBMS FDD Physical layer Enhancements UID_340042...............................................................................26 7.1.2 MBMS TDD Physical layer Enhancements UID_340043...............................................................................27 7.1.3 MBMS LCR TDD Physical layer Enhancements UID_350022......................................................................28 7.1.4 MBMS Mz interface UID_340046..................................................................................................................29 7.2 MBMS - UE Conformance Testing UID_400058..............................................................................................30 7.3 MBMS User Service Extensions (MBMSUSE) UID_34038.............................................................................30

3GPP

2

Overview of 3GPP Release 7 V0.9.10 (2010-06)

8 SA1 Features........................................................................................................................................32
8.1 USSD message delivery and transfer to USIM (USSD-USIM) UID_31048.....................................................32 8.2 Combinational Services (CSICS) UID_31063....................................................................................................33 8.3 CAMEL Trunk Triggers (TTCAMEL) UID_31065...........................................................................................35 8.4 Enhancements of VGCS for public authority officials (EVGCS) UID_11045..................................................36 8.5 Improvements of VGCS for parallel use of services (IVGCS) UID_11055.......................................................37 8.6 Open Service Access (OSA7) UID_31071..........................................................................................................38 8.7 Selective Disabling of UE Capabilities (SDoUE) UID_31053...........................................................................39 8.8 Network selection enhancements (NSP-CR) UID_7041....................................................................................41 8.8.1 Network selection enhancements (NSP) - UE Conformance Testing UID_25048.........................................42

9 SA2 Features........................................................................................................................................43
9.1 Access Class Barring and Overload Protection (ACBOP) UID_32064.............................................................43 9.2 System enhancements for fixed broadband access to IMS (FBI) UID_32074...................................................44 9.3 Support of SMS over generic 3GPP IP access (SMSIP) UID_32081.................................................................46 9.4 Evolution of Policy Control and Charging (PCC) UID_32082..........................................................................47 9.5 Voice call continuity between CS and IMS (incl. I-WLAN) (VCC) UID_32091..............................................49 9.6 One Tunnel solution for Optimisation of Packet Data Traffic (OPTUNEL) UID_7046....................................51 9.7 CSI Terminating Session handling (CSItermS) UID_320029............................................................................51

10 SA3 Features......................................................................................................................................53
10.1 Liberty Alliance and 3GPP Security Interworking (LibSec) UID_33022........................................................53 10.2 Trust Requirements for Open Platforms in 3GPP (TrustOP) UID_33023.......................................................54 10.3 Development of UEA2 and UIA2 (AlgUEA2) UID_33024.............................................................................54 10.4 Lawful Interception in the 3GPP Rel-7 architecture (LI-7A) UID_33026.......................................................55 10.5 Key establishment between a UICC and a terminal (KeyEstUTerm) UID_33028..........................................56 10.6 Security enhancements (SEC7) UID_732030...................................................................................................56 10.7 NDS Authentication Framework Extension for Transport Layer Security (NDSAFTLS) UID_330008.........59

11 SA4 Features......................................................................................................................................60
11.1 Video Codec Performance Requirements (VICPer) UID_34030.....................................................................60 11.2 Dynamic and Interactive Multimedia Scenes (DIMS) UID_34032..................................................................61 11.3 3G-324M Video Telephony Call Setup Times Improvements (VTCSTI) UID_34034...................................63 11.4 Optimizations for Multimedia Telephony over IMS (OMTIMS) UID_34035.................................................63 11.5 End-to-End Multimedia Services Performance Metrics (E2EMSPM) UID_34036.........................................65 11.6 Packet Switched Streaming Enhancements (PSSe) UID_34039......................................................................67

12 SA5 Features......................................................................................................................................68
12.1 Operations, Administration, Maintenance & Provisioning (OAM7) UID_35041............................................68 12.2 Charging Management small Enhancements (CH7) UID_320007...................................................................76

13 CT Features........................................................................................................................................77
13.1 IMS Stage 3 IETF Protocol alignment (IMSProtoc) UID_711052..................................................................77 13.2 Interoperability between VGCS/VBS and A/Gb flexibility (VGCSFlex) UID_7043......................................77 13.3 DIAMETER on the GGSN Gi interface (DIAMGi) UID_13023.....................................................................78 13.4 DIAMETER on the PDG Wi interface (DIAMWi) UID_13022......................................................................78 13.5 Interworking between the 3GPP CS domain with BICC or ISUP as signalling protocol and external SIP-I networks (ExtSIPI) UID_13033...............................................................................................................78 13.6 PDU multiplexing at Nb Interface with IP transport (NbIPMux) UID_340047...............................................79 13.7 Mp (MRFC - MRFP) interface (Mp) UID_14012............................................................................................80 13.8 Routeing of MT-SMs via the HPLMN (SMSviaH) UID_340016....................................................................81 13.9 Mobile Termination whilst the MS is moving to another MSC (MTmovMS) UID_350003...........................82

14 CT6 Features......................................................................................................................................83
14.1 ISIM API for Java Card (APIJAVA) UID_743009..........................................................................................83 14.2 High speed interface between the UICC and the ME (HSI) UID_330001.......................................................83 14.3 Rel-7 (U)SIM API Testing (TS 31.213) UID_440042......................................................................................84

15 RAN Features.....................................................................................................................................85
15.1 Multiple Input Multiple Output antennas (MIMO) UID_2468.........................................................................85 15.2 Rel-7 Improvements of the Radio Interface (RInImp) UID_20028..................................................................85 15.2.1 Extended UMTS 1.7/2.1 GHz UID_20060....................................................................................................85 15.2.2 UMTS 2.6 GHz 7.68 Mcps TDD UID_20067...............................................................................................86 15.2.3 UMTS 2.6 GHz UID_20021..........................................................................................................................86

3GPP

3

Overview of 3GPP Release 7 V0.9.10 (2010-06)

15.2.4 UMTS 2.6 GHz TDD UID_20025.................................................................................................................87 15.2.5 UMTS 900 MHz UID_20027........................................................................................................................87 15.2.6 UMTS 1700 MHz UID_20043......................................................................................................................87 15.2.7 UE Antenna Performance Evaluation Method and Requirements UID_20024.............................................88 15.2.8 Improved Performance Requirements for HSDPA UE based on Rx Diversity (Type 1) & LMMSE equalizer (Type 2) UID_20045..........................................................................................................................88 15.2.9 Additional minimum UE performance requirement for non-HSDPA channels based on Type 1 enhanced receiver (Rx Diversity) UID_20062...................................................................................................88 15.2.10 Improvements of the Radio Interface - UE Conformance Testing UID_25025..........................................89 15.3 RAN improvements (RANimp) UID_20029....................................................................................................90 15.3.1 Optimization of channelization code utilization for 1.28 Mcps TDD UID_20026.......................................90 15.3.2 Delay optimisation for procedures applicable to CS and PS Connections UID_20031................................91 15.3.3 Improved support of IMS Realtime Services using HSDPA/HSUPA UID_20032.......................................92 15.3.4 UE Performance Requirements for MBMS (TDD) UID_20033...................................................................92 15.3.5 Continuous connectivity for packet data users UID_20046..........................................................................92 15.3.6 Extended WCDMA Cell Range UID_7030...................................................................................................93 15.3.7 7.68 Mcps TDD Enhanced Uplink UID_7031...............................................................................................94 15.3.8 Enhanced CELL_FACH State in FDD UID_330009....................................................................................95 15.3.9 64QAM for HSDPA (FDD) UID_340038.....................................................................................................96 15.3.10 Improved L2 support for high data rates UID_340039................................................................................97 15.3.11 Introduction of 16QAM in HSUPA (FDD) UID_340040...........................................................................98 15.3.12 Interface to control Tower Mounted Amplifiers (TMAs) UID_20066........................................................98 15.4 RAN improvements - UE Conformance Testing UID_25026..........................................................................99 15.4.1 Conformance Test Aspects - 3.84 Mcps and 7.68 Mcps TDD Enhanced Uplink UID_25021.....................99 15.4.2 Conformance Test Aspects – 64QAM for HSDPA (FDD UID_25031.........................................................99 15.4.3 Conformance Test Aspects – 16QAM for HSUPA (FDD) UID_25032........................................................99 15.4.4 Conformance Test Aspects – Improved L2 support for high data rates UID_25033....................................99 15.4.5 Conformance Test Aspects – Continuous connectivity for packet data users UID_25034.........................100 15.4.6 Conformance Test Aspects – Enhanced CELL_FACH state in FDD UID_25035.....................................100 15.5 7.68 Mcps TDD option UID_20014...............................................................................................................100 15.6 3.84 Mcps TDD Enhanced Uplink UID_20035..............................................................................................101 15.7 1.28 Mcps TDD Enhanced Uplink UID_20055..............................................................................................103 15.7.1 1.28 Mcps TDD Enhanced Uplink - UE Conformance Testing UID_350146............................................104

16 GERAN Features.............................................................................................................................105
16.1 MS Antenna Performance Evaluation Method and Requirements (APEMR) UID_50118............................105 16.2 Lower 700 MHz Inclusion in the GERAN specifications (GSM710) UID_50119........................................105 16.3 Support of Conversational Services in A/Gb mode via the PS domain (SCSAGB) UID_50564...................106 16.4 Addition of new frequency band to GSM (TGSM810) UID_50565..............................................................107 16.5 Handover of dedicated and shared resources while in dual transfer mode (HODSRDTM) UID_50567.......107 16.6 Mobile Station Receive Diversity (DARP Phase II) (MSRD2) UID_50569..................................................108 16.7 Downlink Dual Carrier (GDCDL) UID_50579..............................................................................................108 16.7.1 Downlink Dual Carrier Conformance Testing (GDCDL-Stage3) UID_59579...........................................109 16.8 Support of SIGTRAN in GERAN (GSIGT) UID_50580...............................................................................109 16.9 Latency Reductions (LATRED) UID_50582.................................................................................................111 16.10 PS Handover between GERAN/UTRAN mode and GAN Mode (GUGAN) UID_52147...........................111 16.11 Higher Uplink performance for GERAN Evolution (HUGE) UID_50584).................................................113 16.11.1 HUGE Conformance Testing (HUGE) UID_59584 (target Mar 2011).....................................................114 16.12 REduced symbol Duration, Higher Order modulation and Turbo coding for downlink (REDHOT) UID_50121..............................................................................................................................................116 16.12.1 REDHOT Conformance Testing (REDHOT) UID_59121 (target Nov 2010)..........................................117

17 Feasibility Studies............................................................................................................................118
17.1 Study on Multimedia Telephony Capabilities for IMS (MITE) UID_31082.................................................118 17.2 Study on Behaviour of Multi system UEs (BMSU) UID_31050...................................................................119 17.3 Study on Combining CS calls and IMS sessions UID_31055........................................................................119 17.4 Study on All-IP Network (FS_AIPN) UID_31059.........................................................................................120 17.5 Study on Videotelephony teleservice (VidTel) UID_31075...........................................................................122 17.6 Study on Network Selection Principles (NetSel) UID_31073........................................................................123 17.7 Study on Multimedia Priority Service (PRIOR-MM) UID_31041.................................................................124 17.8 Study on Transferring of emergency Call data (eCALL) UID_31083...........................................................125 17.9 Study on Enhancement of E2E QoS UID_32073...........................................................................................126

3GPP

......21 Study on Continuous connectivity for packet data users UID_20044...(G)MSC-S Nc Interface based on the SIP-I protocol UID_320018.....19 Study on Performance Evaluation of the UE behaviour in high speed trains UID_20034.............................134 17...........................................................................139 17........................17 Study on IRP Information Mode UID_35068................................................140 18 Rel-7 Completed Items.................10 Study on Bandwidth Saving at Nb Interface with IP transport UID_7034...............................4 Overview of 3GPP Release 7 V0................................................................25 Study on Scope of future FDD HSPA Evolution UID_20065..........................................................127 17.........131 17.......136 17..................12 Study on the TCAPsec Gateway concept UID_7025.......................136 17............162 Annex A: Change history.........................131 17..........132 17................................................................................................11 Study on Routeing of MT-SMs via the HPLMN UID_14019...................................20 Study on UTRA Tower Mounted Amplifier (FDD) UID_20041................133 17.................26 Study on Dynamically reconfiguring a FDD UE ................................................28 Study on Future GERAN Evolution (FGE) UID_50568..................23 Study on Performance Improvements in Small Cells using HSDPA/EDCH UID_20052....................................................144 19 Rel-7 Stopped Items...................................129 17...........................9..................13 Study on using M2PA in 3GPP network UID_7050......................................22 Study on Improvement of Multimedia Broadcast Multicast Service (MBMS) in UTRAN UID_20051..........................128 17...................................................................................135 17............................137 17.................15 Study on SOAP/HTTP IRP Solution Sets UID_35066............................................24 Study on Further Improved Performance Requirements for UMTS/HSDPA UE (FDD) UID_20053..................................16 Study on Itf-N Implementation Conformance Statement (ICS) template UID_35067.............10 (2010-06) 17.... UID_330013.................167 3GPP ....139 17.130 17..................................................................14 Study on Support of (G)MSC-S ...........27 Study on GAN Enhancements (EGAN) UID_50120...................................18 Study on Evolved UTRA and UTRAN UID_20023.............................................................................................................................138 17..........................................167 Ongoing Release 7 Testing................................................................................129 17......................................127 17.............................

Stopped Features and Studies are listed at the end of the present document.g. who wishes to thank all the contributors for the high quality of their inputs. completed.9. The overall document was coordinated by Alain Sultan (MCC Technical Coordinator). ongoing. 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.10 (2010-06) Foreword The coloured highlight of the Unique IDentifier (UID) reflects the status of the work items e. 3GPP .5 Overview of 3GPP Release 7 V0. etc.

org/ftp/Specs/latest/ For specific purposes.org/ftp/Information/WORK_PLAN/Description_Releases/ 3GPP Release Timeline • • 3GPP synchronizes specification development into releases Releases cover the areas of: • • • Accesses (GSM.3gpp. or alternatively in the CR database. The impact of a given feature on a particular specification is described in the Change Request (CR) list.org/specs/specs. HSPA.3gpp. containing the most recent corrections and additions. older versions might be needed.1 Specifications Global information on the Specifications (also called "specs") can be found at: http://www.htm The latest versions of all 3GPP specifications.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 Work Item Descriptions (WIDs) and the CR database. UMTS. and provides links towards the 3GPP Specifications.10 (2010-06) 1 Scope The present document contains a high-level description of the 3GPP Release 7 (Rel-7) Features. etc. for all Releases. the meeting contributions. EPC) Services (IMS. LTE.9.905: "Vocabulary for 3GPP Specifications". which can be found at the end of the respective specification. 2. Its latest version is available at: http://www. Chapter 2 of the present document contains global references. which contains the full list of CRs for all 3GPP specifications. 3GPP Common IMS MMTel IMS EPC .3gpp. LTE-Advanced. the Work Plan.3gpp. are available at: http://www. EDGE. These versions are available at: http://www.6 Overview of 3GPP Release 7 V0. MMTel) R99 2000 UMTS R4 2001 R5 2002 HSPA DL R6 2003 2004 2005 HSPA UL R7 2006 2007 R8 2008 LTE R9 2009 2010 R10 2011 LTE Adv HSPA + For each Feature (or independent item). 2 [1] References 3GPP TR 21. references are given to guide the reader on how to deepen the subject: the Work Item Description (WID) as well as the list of impacted specifications is provided at the beginning of each clause describing the feature.) Core Network (GSM Core.

org/ftp/Information/WORK_PLAN/ 2.3gpp.10 (2010-06) 2.3gpp. etc. When it is considered to be 80% complete. They are stored in: http://www.3gpp.4 Change Request database A specification is originally drafted and maintained by a rapporteur.9.3gpp. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation.3gpp.'. the abbreviations given in TR 21. CS IMS ISDN PLMN RAB RLC RTP SIP Circuit Switched IP Multimedia Subsystem Integrated Services Digital Network Public Land Mobile Network Radio Access Bearer Radio Link Control Real Time Protocol Session Initiated Protocol (IETF) 3GPP . in TR 21. as: the WG in charge of it.. After this. the status of each Change Request and references to relevant temporary document numbers and meetings. its starting date and (foreseen or actual) completion date. which contains the full list of Work Items and Study Items.org/ftp/Information/Databases/Change_Request/ Further information on CR is available at: http://www. The Work Plan is available at: http://www. who compiles the contents from discussions in the WGs and TSGs. Potential subsequent versions narrow the target and foreseen completion date according the actual progress. and are the inputs for elaborating the specs. updated roughly each month. 2.7 Overview of 3GPP Release 7 V0. including a Work Item code. changes to the specification can only be made using Change Requests that are usually agreed by consensus in the Working Group responsible for the specification. a Change Request number that is unique within the specification (different versions are possible.. Work Items and Study Items Work Item Description ("WID") (also called WI Description) and Study Item (also called "Feasibility Studies") are forms which initial version provides the target to be reached before starting the technical work. but only one can ever be approved). if any. This database is available in: http://www.3 Work Plan.org/ftp/Information/WI_sheets/ The 3GPP Work Plan is a living document. They are available (sorted by 3GPP technical groups (Technical Specification Groups (TSGs) and Working Groups (WGs)) at: http://www.htm 3 Abbreviations For the purposes of the present document. it is brought under a so-called "change control" process.org/ftp/ starting with 'tsg.2 Tdocs The Temporary Documents (tdocs) are mainly the original papers written by the 3GPP Members. as well as summary information for each WI. the actual progress. and then formally approved by the relevant Technical Specification Group.905 [1].org/specs/CR.905 [x] and the following apply. The Change Request database contains all available information on Change Requests..

.8 Overview of 3GPP Release 7 V0. Stage 3 Impacted Specifications IP Multimedia Subsystem (IMS).g.228 TS 23. it is useful to be able to route the SIP request to the UE(s) supporting a requested communication service. Charging may use a communication service identifier as input.298 TS 32. but indicates the particular communication service used.229 Title/Contents WID(s) S2 WID on Identification of Communication Services in IMS C1 WID on Identification of Communication Services in IMS.S5 References Document SP-060293 CP-060259 TS 22. OMA has employed the feature tag as ServID. Diameter charging applications IP Multimedia (IM) session handling. TR 23. In a multi-UE scenario where a recipient has several UEs with different UE capabilities. while allowing for many services to be offered using the same enablers and media types. if required. It is desirable for the network to be able to authorize the use of a communication service.1 Identification of Communication Services in IMS (ServID) UID_732097 Resources: S2. Stage 2 Policy and charging control architecture Telecommunication management.228 TS 23. Stage 2 Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP). A means is required in order to identify the communication service requested for the following reasons: • • • • • • • • • • • The network is required to identify the correct application server(s) to link into the SIP call path. Charging Data Record (CDR) parameter description Telecommunication management. The architectural requirements and technical procedures and the administrative procedures for a ServID required study. In addition to the above reasons. Communication service prioritization in the case of network overload. Provide a scope for the IOP specifications related to a particular communication service. a communication Service IDentifier (ServID) also has the advantage or reducing the required co-ordination between standardization bodies if format and encoding across these bodies was the same.816 covers the following aspects: 3GPP . Charging management. To be an input into inter-operator interconnect service level agreements. as such interworking between an IMS based service and a non-IMS based service may benefit from the identification of the requested communication service. The introduction of a ServID does not replace the Public Service Identity (PSI).C1.816 Identification of communication services in IMS 3GPP has adopted the approach of creating a number of IMS enablers that can be used by a number of services.203 TS 32.218 TS 24.10 (2010-06) 4 IMS 4. IP Multimedia Subsystem (IMS) charging Telecommunication management.. Allowing the network to authorize the use of the service for a particular user. The media authorization policy may use a communication service identifier as input. In order to enable the User Equipment to identify the correct application logic. nor the requested media being used is sufficient to identify the particular communication service requested.). Charging management. Often interworking requires knowledge of the services being interworked. The success of this has been demonstrated through the adoption of the IMS by other standardization bodies (e. Stage 3 New Dedicated Specifications/Reports TR 23. TISPAN. A consequence of this approach is that neither the enabler being used.S1.9. IM call model.299 TS 23. OMA . Charging management. some of which have finalized a service definition utilising the IMS.260 TS 32. Stage 1 IP Multimedia Subsystem (IMS).

which utilise IMS communication services. 4. Conferencing and PoC need to be able to identify the origin of and route SIP signalling to a specific UE instance even when multiple UEs use the same Public User Identity.9. TS 32. Mechanism for IMS Core Network to update GRUUs during re-registrations. 3GPP .298. including the requirements upon when a ServID value is required to be allocated. The support of GRUU in IMS requires the enhancement of the IMS architecture and associated protocols. but a few possibilities exist and are described - Stage 1 and 2 were implemented in existing SA1/2 TS 22.2 Supporting Globally Routable User Agent URIs in IMS (GRUU) UID_32116 Resources: S2 References Document SP-050633 SP-050633 TS 22. Stage 3 New Dedicated Specifications/Reports - The IMS architecture supports the possibility for multiple UEs to register with the same Public User Identity. TS 24. IM call model.229 and is aligned with IETF.10 (2010-06) • • • • Framework description for the usage and applicability of ServID and its relationship with PSI and other existing IMS mechanisms. In the case that an IMS ServID is not present the network should identify a particular IMS communication service by other means. CSI. TS 23. A GRUU URI enables routing to a specific user agent instance. CT1 Stage 2/3 for the new identifiers (IMS service identifier.228.229 Title/Contents WID(s) S2 WID on Supporting Globally Routable User Agent URIs (GRUUs) in IMS C1 WID on Supporting Globally Routable User Agent URIs (GRUUs) in IMS – stage 3 Impacted Specifications IP Multimedia Subsystem (IMS). Stage 1 IP Multimedia Subsystem (IMS).218 TS 24. in order to have a general solution adoptable outside 3GPP. Stage 2 IP Multimedia (IM) session handling.816 concludes the following: IMS communication services may be identified by an IMS ServID. The exact means to administer IMS ServIDs is a stage 3 issue. Presence. TR 23. Many IMS based enablers such as Voice Call Continuity. Stage 2 Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP). Identify requirements on compatibility and evolution of a communication service in relation to the ServID. are identified by an application reference.299. IMS enhancements needed: • • • Ability for the UE to generate unique device instance identifiers and obtain GRUUs.218.260. The absence of the application reference may imply that a default application for the specified IMS communication service is invoked. No alternative means to identify IMS communication services were identified.9 Overview of 3GPP Release 7 V0. This issue has been worked on in the IETF and the solution found is GRUUs (Globally Routable User Agent URIs). TS 32. IMS applications. Describe the expected behaviour when the ServID in the requesting SIP method doesn’t match with any of the service identifiers included in the registration process from the called UEs Identify the methods for administrative procedures for a ServID.228 TS 23. Charging of ServID is implemented in existing SA5 TS 32.228.203. Application reference) is implemented in existing TS 23. TS 23. Mechanism for IMS Core Network to generate and store GRUUs during IMS registration. Identify architectural requirements for ServID that enable the usage scenarios identified.228 TS 23.

114 allows additions of media components and functionality in later Releases. It is desirable to specify media behaviour in a predictable manner. echo and noise cancelling. Interworking with 3GPP-specified telephony services are covered (CS speech. support of the new SIP option tag in IMS SIP messages). packet loss handling and concealment. that the services from day one must be well specified and interoperable. Transport protocols Multimedia telephony over IP Multimedia Subsystem (IMS).229 TS 29. for example implicit registration.914 Title/Contents WID(s) S1 WID on Multimedia Telephony Service for IMS C1 WID on IMS Multimedia Telephony Service. Exchange of GRUUs between UEs. Default codecs Packet switched conversational multimedia applications. SA1 has. It was necessary to specify the media handling and behaviour (delay jitter handling.173 TS 26. rate adaptation.173 TS 24. in order to be able to define services to the end-users. with the goal of making these basic services consistent. Stage 3 S4 WID on IMS Multimedia Telephony. SA1 decided to reuse where applicable Supplementary Service (SS) definitions as specified by ETSI TISPAN. This means.236 TS 26. delay and jitter) than for a comparable CS conversational service. SA4 has specified a basic PS service supporting conversational speech.10 (2010-06) • • • • • • • Mechanism to signal to the IMS core the UE’s support of GRUU (for example. Define guidelines for appropriate usage of GRUU vs. One interesting aspect of IMS Multimedia Telephony is that it is possible to have a user experience that has a larger gamut (e. media handling and interaction Impacted Specifications Generic enhancements and extensions due to Multimedia Telephony Generic enhancements and extensions due to Multimedia Telephony New Dedicated Specifications/Reports IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service and supplementary services. The work focussed on person-to-person calls using RTP-transported media. The system may need to correlate SIP requests addressed to GRUUs to the Public User Identities associated with the GRUU for charging purposes. also defined any potential additional 3GPP-only SSs and capture those in the same 3GPP specification. media related end-2-end signalling etc). Add/drop of media during a call were specified. Interaction between an IMS core that supports GRUU and one that does not. 3GPP . Interaction between an UE that supports GRUU and one that does not.10 Overview of 3GPP Release 7 V0. Interaction of GRUU with existing IMS features. interoperable and of predictable performance. Support by IMS of routing of SIP requests addressed to GRUUs. among other things.235 TS 26. Security impacts and privacy issues related to the generation and use of GRUUs based on existing 3GPP device identifiers such as IMEI and IMSI needed to be studied. apart from endorsing the relevant TISPAN SSs. video and text. interoperability with CS/UTRAN/GERAN. Media handling and interaction Packet switched conversational multimedia applications.3 Multimedia Telephony Service for IMS (MTSI) UID_7038 Resources: S1.114 TS 26. usage of Public User Identity.C1.9. a standardized consistent terminal behaviour is important for the operator to enable tuning of the network with full control over the end users’ experience. and emerging TISPAN network (se also TR 22. Optimization opportunities 3GPP and TISPAN defined an IMS based Multimedia Telephony service.163 TS 22. 3G-324M and video telephony) as well as with traditional POTS. In addition. This also means a well specified transmitter and receiver behaviour. so that operators are able to differentiate their service offerings. inter-media synchronization. The service defined by 3GPP is needed for wireless access to IMS. Written in a forward-compatible way TS 26.973). for voice. which is an evolution of the CS based Telephony service provided by traditional ISDNs and PSTNs.S4 References Document SP-060224 CP-060257 SP-060225 TS 24. 4. Stage 1 IMS Multimedia telephony communication service and supplementary services IMS Multimedia Telephony.g. and to support interoperability in multi-vendor and multi-operator environment and to provide the user with the same experience across the different IP based accesses and domains.

TS 26.114 apply to MTSI. registration to the network and/or to IMS at power-on or at other occurrences were not included.236 do not include the specification of an MTSI client.UE Conformance Testing UID_350147 Resources: R5 References Document RP-080605 34. Issues on SIP signalling.9. The optimizations regarded mainly media transport and signalling.236 that are specifically referenced by TS 26.273 TISPAN. Status Report in RP-090056.4 TISPAN requirements for Multimedia Telephony with PSTN/ISDN simulation services (TMMTEL7) UID_377001 Resources: S1 References Document SP-070568 TS 22.3. This enables the conformance testing of core Rel-7 enhancements of MTSI. Conformance test specifications must be developed for IMS Call Control protocol to verify correct functionality of the UE when operating in an IMS network.235 and TS 26.235 and TS 26.114 addresses the areas of optimization opportunities identified in TR 26. although they include conversational multimedia applications.2291/2/3 None Title/Contents WID(s) R5 WID on Conformance Test Aspects – Multimedia Telephony Services for IMS (MTSI) Impacted Specifications Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP) New Dedicated Specifications/Reports - RAN5 provides conformance testing for MTSI (linked to MTSI Feature UID_7038.11 Overview of 3GPP Release 7 V0.914.10 (2010-06) TS 26.173 Title/Contents WID(s) SA1 SID on Review of Network Selection Principles Impacted Specifications IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service and supplementary services. 4.to 3GPP (TS 22. TS 26. Stage 1 (CR#0009 Alignment of References) New Dedicated Specifications/Reports TS 22. 4. Multimedia Telephony with PSTN/ISDN simulation services This work transfers TISPAN Release 1 MMTEL Stage 1 (ETSI TS 181 002) .114 specifies a client for MTSI supporting conversational speech (including DTMF).273) for maintenance purposes.needed to implement the core IMS specification in light of the Common IMS concept . IMS Call Control based on SIP forms the basis of IMS applications. video and text transported over RTP with the scope to deliver a user experience equivalent to or better than that of CS conversational services using the same amount of network resources.1 Multimedia Telephony Service for IMS (MTSI) . 3GPP . Only those parts of TS 26.

a further number. and only essential maintenance is envisaged on the 3GPP 2x.2.141 and OMAAD-Presence_SIMPLE-V1_0] TISPAN. 2x.3gpp.5 Maintenance of TISPAN release 1 common IMS (MCIMSTR1) UID_387001 Resources: S2.htm.508 TS 23. there is a need to ensure that maintenance occurs of the TISPAN R1 deliverables.12 Overview of 3GPP Release 7 V0. published as ETSI standards. Release 7] TISPAN.4xx and 2x. List of TISPAN R1 specifications under 3GPP SA responsibility See http://www.406 TS 23.9.org/specs/TISPAN-IMS-transfer. This work item does not provide for any new feature or for any enhancement of a feature. Because of different working methods between TISPAN and 3GPP.S1 References Document SP-070915 TS 22. Stage 1 (Alignment of references) New Dedicated Specifications/Reports TS 22.5xx TSs. with the constraint that such a change shall not result in any technical change to TISPAN R1 or to frozen 3GPP releases. IP Multimedia Subsystem (IMS). NGN Architecture to support emergency communication from citizen to authority [Endorsed document 3GPP TS 23. In general.509 TS 23. NGN Release 1 (R1) and Release 2 (R2) publications are transferred under separate 3GPP TS numbers. The work item allocates a work item code that can be used on such essential corrections to TISPAN R1. Functional architecture TISPAN.228 v7. Stage 2 description [3GPP TS 23. Where further development is envisaged within the Rel-8 timeframe. Architecture and functional description [OMA-AD-XDM-V1_0-20051006C modified] As part of the agreement of moving common IMS work from ETSI TISPAN to 3GPP. where as essential corrections are identified they should be made to older releases to which they are appropriate. Presence Service.167.0. TISPAN has a Change Request process similar to 3GPP. modified] TISPAN.273 TS 23. 3GPP . XML Document Management. IP Multimedia Subsystem (IMS). Multimedia Telephony with PSTN/ISDN simulation services TISPAN. where the table shows the ETSI publications relating to core functions of the IP Multimedia Subsystem (IMS) used by the Next Generation Network standardized within ETSI Technical Committee Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN). This work item also provides a work item code for appropriate re-documentation to assist the above.6xx. TISPAN documents are transferred in an already-frozen state.10 (2010-06) 4.417 TS 23.511 TISPAN.173 Title/Contents WID(s) S2 WID on Maintenance of TISPAN release 1 common IMS Impacted Specifications IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service and supplementary services. Architecture and functional description [Endorsement of 3GPP TS 23. has been allocated.

This work item also provides a work item code for appropriate re-documentation to assist the above.g. with mirrors in TISPAN R2. where as essential corrections are identified they should be made to older releases to which they are appropriate.6 Maintenance of TISPAN documentation (MAINTISP) UID_380069 4.xxx Title/Contents WID(s) C1 WID on Maintenance of TISPAN release 1 common IMS Impacted Specifications Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP). as defined by 3GPP and ETSI TISPAN Change Control process. ETSI TISPAN will need to delete the contents of their specifications and replace them with references to these new 3GPP specifications.229 TS 29. Additionally. Signalling flows and message contents Cx and Dx interfaces based on the Diameter protocol. Such redocumentation must not result in any technical change. Due to some issues with 3GPP maintaining directly the TISPAN specifications.229 TS 24.13 Overview of 3GPP Release 7 V0.10 (2010-06) 4. e. with the constraint that such a change shall not result in any technical change to TISPAN R1 or to frozen 3GPP releases. Stage 3 Interworking between the IM CN subsystem and IP networks Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks IP Multimedia (IM) Subsystem Cx and Dx Interfaces. This work item does not provide for any new feature or for any enhancement of a feature. such changes shall be essential corrections. to being one where the dependency is on a specific release but not a specific version.9. and 3GPP Rel-8 onwards. The corollary of this is that in association with this work item. the mechanism for doing this will be to create new 3GPP release 7 specifications with identical contents to those of the TISPAN R1 specifications.C4 References Document CP-080211 TS 24.228 TS 29.1 Maintenance of TISPAN R1 (MAINT_R1) UID_380004 Resources: C1. then such changes are also allowed under this work item. by changing the TISPAN deliverable from being dependent on a specific version of a 3GPP specification. This work item provides a work item code that can be used for maintenance of TISPAN R1. published as ETSI standards.6.162 TS 29. The table below identifies the list of TISPAN R1 specifications that 3GPP CT currently assumes responsibility for: 3GPP . if the maintenance process can be made simpler by some re-documentation. there is a need to ensure that maintenance occurs of the TISPAN R1 deliverables. TISPAN has a Change Request process similar to 3GPP. The work item allocates a work item code that can be used on such essential corrections to TISPAN R1.163 TS 29.C3. Protocol details New Dedicated Specifications/Reports See table below As part of the agreement of moving common IMS work from ETSI TISPAN to 3GPP.

as defined by 3GPP and ETSI TISPAN Change Control process. Stage 2 description [3GPP TS 23.9.429 29. Videotelephony over NGN Service Description TISPAN.g. Functional architecture TISPAN.14 ETSI TISPAN document TS 183 004 TS 183 005 TS 183 006 TS 183 007 TS 183 008 TS 183 010 TS 183 011 TS 183 016 TS 183 021 TS 183 023 TS 183 028 TS 183 029 TS 183 033 TS 183 041 ES 283 003 ES 283 027 ES 283 030 ES 283 012 Overview of 3GPP Release 7 V0.228 / 29.405 24. by changing the TISPAN deliverable from being dependent on a specific version of a 3GPP specification.406 24. This work item also provides a work item code for appropriate re-documentation to assist the above. This work item does not provide for any new feature or for any enhancement of a feature.509 TS 23. then such changes are also allowed under this work item.401 TS 23. This work item provides a work item code that can be used for maintenance of TISPAN R1.430 29.403 29.229 Endorse 29. Stage 1 (Alignment of references) New Dedicated Specifications/Reports TS 22.173 Title/Contents WID(s) S2 WID on Maintenance of TISPAN release 1 common IMS Impacted Specifications IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service and supplementary services. NGN ECT Endorse 29.163 Endorse 24.2 Maintenance of TISPAN release 1 common IMS (IMS_Comm_Mtce7) UID_380072 Resources: S2. e.2. to being one where the dependency is on a specific release but not a specific version. if the maintenance process can be made simpler by some re-documentation.416 29. 3GPP .441 24.412 WG CT1 CT1 CT1 CT1 CT1 CT1 CT1 CT1 CT3 CT1 CT1 CT1 CT4 CT1 CT1 CT3 CT1 CT3 Subject NGN CDIV NGN CONF NGN MWI NGN OIP OIR NGN TIP/TIR NGN HOLD NGN ACR/CB NGN MCID Endorse 29.247 Endorse 24. Additionally.427 24. there is a need to ensure that maintenance occurs of the TISPAN R1 deliverables.511 TISPAN. where as essential corrections are identified they should be made to older releases to which they are appropriate.428 24.6. published as ETSI standards.229 Endorse 24. IP Multimedia Subsystem (IMS).S1 References Document SP-080501 TS 22. Architecture and functional description [Endorsement of 3GPP TS 23. Multimedia Telephony with PSTN/ISDN simulation services TISPAN.10 (2010-06) New 3GPP document 24.228 v7.421 24.407 24.508 TS 23.408 24.0.167.162 NGN XCAP NGN Basic comm.410 24. XML Document Management.404 24. such changes shall be essential corrections. TISPAN has a Change Request process similar to 3GPP. with the constraint that such a change shall not result in any technical change to TISPAN R1 or to frozen 3GPP releases.406 TS 23. modified] TISPAN.417 TS 23. NGN Architecture to support emergency communication from citizen to authority [Endorsed document 3GPP TS 23.141 stage 2 trunking gateway control procedures 4.423 24. Release 7] TISPAN.433 24. The function of this work is to allocate a work item code that can be used on such essential corrections to TISPAN R1.411 24. Presence Service.141 and OMAAD-Presence_SIMPLE-V1_0] TISPAN. Such redocumentation must not result in any technical change. Architecture and functional description [OMA-AD-XDM-V1_0-20051006C modified] As part of the agreement of moving common IMS work from ETSI TISPAN to 3GPP. IP Multimedia Subsystem (IMS).273 TS 22.

Relations with Location Services. addressing and identification Organization of subscriber data Policy and charging control architecture Architectural requirements IP Multimedia Subsystem (IMS). This work studied and specified the functionalities required to meet the requirements as defined in TS 22. European and other regulatory requirements.228 TS 29. depending on the type of emergency.271 TS 24. Stage 2 General Packet Radio Service (GPRS).060 TS 23. Emergency sessions shall be routed to an emergency centre in accordance with national regulations. Stage 3 3GPP system to Wireless Local Area Network (WLAN) interworking.229 (Release 7).234 TS 24. This can be for example done by the dialled number. or a linkage to a car air bag control.203 TS 23.163 TS 29.101. The impact to 3GPP LCS architecture to support this aspect should be studied as part of the (xxxx) Stage 2 LCS for 3GPP Interworking WLAN. 3GPP specific codes and identifiers 3GPP system to Wireless Local Area Network (WLAN) interworking. It shall be possible to implement different MMIs to invoke emergency services.167 Title/Contents WID(s) S2 WID on PS domain and IM CN subsystem impacts for supporting IMS Emergency calls C1 WID on Emergency Call Enhancements for IP& PS Based Calls – stage 3 Impacted Specifications Service aspects.7 PS domain and IMS impacts for supporting IMS Emergency calls (EMC1) UID_32045 Resources: S2. With respect to fixed broadband access to IMS the objective is to keep work on the IM CN subsystem specific aspects of IMS emergency calls independent from the PS domain aspects as much as possible so that work on each part can progress individually. Service description. Stage 3 New Dedicated Specifications/Reports Internet Protocol (IP) based IP Multimedia Subsystem (IMS) emergency sessions IP Multimedia Subsystem (IMS) emergency sessions It shall be possible to establish an emergency session via the PS domain and the IM CN subsystem to meet the requirements defined in TS 22.403 TS 29. Core network protocols.101 and other relevant specifications for emergency session handling in the PS domain and the IM CN subsystem.S1. The function shall be supported when roaming.9.C4. IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3 [3GPP TS 24.15 Overview of 3GPP Release 7 V0.867 TS 23. The main focus was on support for SIP emergency sessions and related packet bearers. This WID studies Emergency location information for I-WLAN and fixed broadband access.C3 References Document SP-050604 CP-050529 TS 22. It shall be allowed to establish a PS emergency session without the need to dial a dedicated number to avoid the mis-connection in roaming case. WLAN User Equipment (WLAN UE) to network protocols.008 TS 23. Signalling flows and message contents Diameter applications. Compliant with FCC mandates. etc.10 (2010-06) 4. Stage 2 Network architecture Functional stage 2 description of Location Services (LCS) Mobile radio interface Layer 3 specification.234 TR 23. modified] Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks IP Multimedia (IM) Subsystem Cx and Dx Interfaces.101 TS 23. a dedicated Menu.002 TS 23. This may be based upon one or more default addresses stored in the ME and/or USIM and information about the origin of the session. such as connect by menu. 3GPP .221 TS 23.230 TS 29. Service principles Numbering. The objective is to specify the functionalities for both the UICC-less case. one or more dedicated buttons. Stage 3 TISPAN.003 TS 23.C1.228 TS 23. Points also considered: • • • • • • Using the existing emergency numbering schemes. Possibility to initiate emergency sessions to different emergency service centers.008 TS 24. and the case when the UE has a valid UICC. The work takes into account requirements coming from fixed broadband access to IMS and seeks for maximum commonality of architectural solutions between 3GPP and fixed broadband access to IMS.

167) and existing specifications.008) and IM CN Subsystem domain (TS 24.e: • • Floor control for IM CN subsystem conferencing. 3GPP . Stage 3 New Dedicated Specifications/Reports - In Rel-5.g. CT provided the stage 3 specification as follows: • • • CT1 added via CR emergency calls for the PS domain (TS 24. such applications could not be completed in Rel-6. additional applications were developed.229).16 Overview of 3GPP Release 7 V0.147 TS 24.8 IMS Support of Conferencing (IMSconf) UID_11065 Resources: C1 References Document CP-070120 TS 24. During Rel-6. Stage 3 Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP).867 was a temporary container for the architectural impacts on IM CN subsystem and on IP-Connectivity Access Network for establishing an emergency session via IM CN subsystem. IETF has finished a floor control specification (BFCP).867 was moved into 3GPP new (TS 23. CT3 added via CR emergency calls for the PS and the IM CN Subsystem domain to TS 29. The contents of TR 23. CT1 added via CR emergency calls for the PS domain to TS 29. Extensions to conferencing related SIP procedures Security aspects are already covered by existing Rel-6 security specifications e.061 (interworking between PLMN and PDNs) and to TS 29.9. The feature set in Rel-5 provides a basis for IP Multimedia support.163 (additions to the IW). but due to IETF dependencies.060 (changes to GTP) 4.229 WID on IMS Support of Conferencing Title/Contents WID(s) Impacted Specifications Conferencing using the IP Multimedia (IM) Core Network (CN) subsystem. adopted for Rel-7 IMS conferencing. This work progress Stage 3 on postponed Rel-6 features for IP multimedia applications in accordance with existing Rel6 Stage 1 requirements and for which the related IETF dependencies have been completed within the Rel-7 i. GAA. IMS was defined to support IP Multimedia services.10 (2010-06) TR 23. and SDP and conference policy control to support provision of a floor control server.

2. AMR 12. street and cafeteria.935 Title/Contents WID(s) WID on Performance Characterization of VoIMS over HSDPA\EUL channels Impacted Specifications Packet Switched (PS) conversational multimedia applications. 8 channel conditions consisting of 2 traffic and 2 mobility conditions: 2 traffic conditions (low: 40. This Work Item is about performing a similar set of tests as currently described in TR 26. TR 26.935 provides information on the performance of default speech codecs in packet switched conversational multimedia applications. This is not an optimal RAB to do PS conversational test but it was the only one available at the time the test bed and the air interface simulator were designed. The tests performed were based on an approved test plan (same experimental conditions used for the conversational tests). 3 background noise types: car. but also delay analysis was included.935. The transmission of IP/UDP/RTP/AMR packets over the UMTS air interface (over DCH channels) was simulated using the Conversational Packet Switched Radio Bearers coming from TS 34.935 in collaboration with relevant RAN WGs 1 and 2 by using HS-DSCH and E-DPDCH channels instead of DCH for carrying voice on downlink and uplink. Performance characterization of default codecs New Dedicated Specifications/Reports None The idea of carrying voice over shared resources such as HSDPA is becoming quite attractive due to the performance benefits and enhanced code utilization. The tests performed by France Telecom.805 defined scenarios and testing procedures). Listening-only tests to bring complementing information of the performance. while France Telecom kindly offered to perform the conversational subjective tests at their own expenses.65 kbps (each tested in separate experiment consisting of 16 test conditions). 3 minutes (conforming to ITU-T SG12 Recommendation P.9 Performance Characterization of VoIMS over HSDPA\EUL channels (VoIMS-PCVoIMS) UID_34033 Resources: S4 Reference Document SP-050089 TR 26. and AMR-WB 12.2 kbps. – The test results were put in the informative Annex 8 of 3GPP TR 26. Radio access bearer simulations conform to error-delay profiles and the definition of relevant RABs from RAN1 and RAN2. who kindly offered to perform the subjective tests at their own expenses. RAN2 has recently defined RABs for the support of Voice over IMS on High Speed Downlink Packet Access HSDPA) bearers. Dynastat and Beijing Institute of Technology were based on a generic scheduler and an approved test plan. (These focussed on the effect of jitter and channel errors instead of end-to-end delay. The impact of jitter delay on the speech quality was evaluated by using proprietary Jitter Buffer Management algorithms.17 Overview of 3GPP Release 7 V0. that carry RTP.10 (2010-06) 4. 3GPP . Conversation testing with conversations lasting ca. 1. Therefore.9. high: 30 or 120 km/h vehicle).9 kbps.) Outline of conversation and listening-only testing conditions (48 test conditions): – – – 3 codecs/modes: AMR 5. RTCP and SIP protocols. The performance of proprietary Jitter Buffer Management algorithm(s) was tested by means of Listening only tests by Ericsson and Nokia.108. Funding to compensate the work done by Dynastat and Beijing Institute of Technology was provided by Lucent Technologies (before the merge with Alcatel). high: 80 or 100 mobile users per cell) and 2 terminal mobility scenarios (low: 3 km/h pedestrian. In order to allow testing for support of Voice over IP over HSDPA\EUL (EUL = Enhanced UpLink) optimized RABs were simulated. respectively. the characterization consisted of: Conversation tests to evaluate the performance under real-time conversations. 45 or 60 mobile users per cell.

234 CR#0087/0088 were approved against this work item acronym (WLAN2).C1.234-0011. CR 22. and outlines some of the different WLAN technologies that may be interworked with 3GPP systems. as follows: 3GPP . Thus the WLAN effectively becomes a complementary radio access technology to the 3GPP system. Stage 3 Interworking between the Public Land Mobile Network (PLMN) supporting packet based services with Wireless Local Area Network (WLAN) access and Packet data Networks (PDNs) New Dedicated Specifications/Reports - WLAN 3GPP IP Access has the concept that existing 3GPP PS based services shall be supported via WLAN access.234-0010 SP-040737) (CR 22. This requirement existed already in Rel-6 TS 23.2 WLAN Interworking – Private Network access from WLAN 3GPP IP Access (WLANPNA) UID_32110 Resources: S2. which defined the interworking between 3GPP systems and WLANs.234 clause 5.234 TS 29. In 3GPP/WLAN interworking.161 Title/Contents WID(s) S2 WID on WLAN Interworking – Private Network access from WLAN 3GPP IP Access C1 WID on WLAN Interworking – Private network access from WLAN 3GPP IP Access Impacted Specifications 3GPP system to Wireless Local Area Network (WLAN) interworking. Rel-6 TR 22.234-0012 SP-050066) (CR 22.934 and defines the highly level requirements for I-WLAN.934 includes a number of different scenarios of 3GPP-WLAN interworking ranging from common billing to the provision of services seamlessly between the WLAN and the 3GPP system.10 (2010-06) 5 IWLAN 5. referred as Scenarios 1 to 6.234 TS 33.1 WLAN-UMTS Interworking Phase 2 (WLAN2) UID_31062 Resources: S1 References Document SP-030712 TS 22.WLAN. For this purpose.234 took the conclusions of Rel-6 TR 22.234-0021 SP-060305) 3G security. it includes the analysis of a number of environments where both the 3GPP system and WLAN may be deployed. WLAN User Equipment (WLAN UE) to network protocols. 3GPP system functionalities can reside behind the WLAN or in parallel to the WLAN. "3GPP/WLAN interworking" refers to the utilization of resources and access to services within the 3GPP system by respectively the WLAN UE and user. The Stage 1 in 22. The WLAN provides access to services located in WLANs and/or networks behind the WLAN.18 Overview of 3GPP Release 7 V0.234 WID on 3GPP system . System description 3GPP system to Wireless Local Area Network (WLAN) interworking. Wireless Local Area Network (WLAN) interworking security New Dedicated Specifications/Reports - This work item is an extension of the WLAN-UMTS Interworking Rel-6. 5.C3 References Document SP-050489 CP-060256 TS 23.9. SA3 TS 33.1. In addition.4. The intent of 3GPP/WLAN Interworking is to extend 3GPP services and functionality to the WLAN access environment.Interworking Title/Contents WID(s) Impacted Specifications Requirements on 3GPP system to WLAN interworking (CR 22.234 TS 24.

19

Overview of 3GPP Release 7 V0.9.10 (2010-06)

-

Access to 3GPP PS based services shall be provided via WLAN. The interworking architecture shall provide IP connectivity to be able to support all 3GPP PS based services.

However, the standardization of Intranet/ISP access with some authentication scheme (e.g. PAP/CHAP) has been missed in Rel-6 I-WLAN. This work provides Private Network access from WLAN 3GPP IP Access. WLAN 3GPP IP Access allows 3GPP WLAN UEs to establish connectivity with External IP networks, such as 3G operator networks, corporate Intranets or the Internet via the 3GPP system. A mechanism to perform authentication between the WLAN UE and an AAA server located in an external Packet Data Network (PDN) was implemented via CR in SA2 TS 23.234. CT provided the protocol based on the security requirement defined by SA3: • • CT1 24.234 (CR#0035) provided UE to network protocols (Tunnel management procedures: UE-PDG); CT3 29.161 (CR#0003) provided network protocols (RADIUS on Wi reference point.

5.3 Enhancements to support QoS provisioning over 3GPP/WLAN Interworking (WLANQOS) UID_32092
Resources: S2,C4,C1 References
Document
SP-050682 CP-060418

Title/Contents WID(s)
S2 WID on WLAN Interworking – Enhancements to support QoS provisioning over 3GPP/WLAN Interworking C4 WID on WLAN Interworking – Enhancements to support QoS provisioning over 3GPP/WLAN Interworking, Stage 3

Impacted Specifications
TS 23.234 TS 23.008 TS 29.234 TS 24.234 3GPP system to Wireless Local Area Network (WLAN) interworking; System description Organization of subscriber data 3GPP system to Wireless Local Area Network (WLAN) interworking; Stage 3 3GPP system to Wireless Local Area Network (WLAN) interworking; WLAN User Equipment (WLAN UE) to network protocols; Stage 3

New Dedicated Specifications/Reports
-

Some 3GPP PS based services (e.g. VoIP over IMS, PS streaming, etc.) require strict QoS provisioning. In order to support such services over I-WLAN it is required to have QoS Provisioning in 3GPP/WLAN Interworking. IEEE 802.11 WLAN standards are currently not supporting QoS mechanisms, therefore QoS provisioning was not considered in Rel-6 work for 3GPP/WLAN Interworking. As IEEE has approved QoS amendments to 802.11 WLAN standards, QoS-related aspects of the 3GPP/WLAN architecture should be studied. In the context of end-to-end QoS provisioning being studied in TR 23.802 (Study on Enhancement of E2E QoS UID_32073), provisioning of QoS within I-WLAN as an IP-CAN is important. It shall be defined if and how QoS provisioning in I-WLAN can interact with the end-to-end QoS framework. Flow Based Charging (FBC) and service/subscription based Policy Control (PC) are generic features supporting access to PS based services from different Internet Protocol Connectivity Access Network (IP-CANs); see Evolution of Policy Control and Charging (PCC) UID_32082. In order to leverage the generic charging and service/subscription based Policy Control within I-WLAN as another IP-CAN, the Gateway element in case of 3GPP/LAN Interworking has to provide the needed functionalities, e.g. for Policy Enforcement. This work: • • Investigates the necessity and reliability of the applicable QoS mechanism between the WLAN UE and PDG, and the possible impacts to the 3GPP-WLAN interworking entities. Ensures that the architecture for 3GPP/WLAN Interworking defined by TS 23.234 is supported by the following QoS-related mechanisms being developed in 3GPP: a) TR 23.802 on E2E QoS architecture (Study on Enhancement of E2E QoS UID_32073); b) Policy and charging evolution capabilities (Evolution of Policy Control and Charging (PCC) UID_32082)

3GPP

20

Overview of 3GPP Release 7 V0.9.10 (2010-06)

Enhancements to support QoS provisioning over 3GPP/WLAN interworking were implemented via CR in TS 23.234. CT4, CT1 provided the Stage 3 enhancement to support QOS provisioning over 3GPP/WLAN Interworking: • • • Add subscribed 3GPP/WLAN QoS profile information to the WLAN user profile in the HS; Extend existing AAA reference points to transport 3GPP/WLAN QoS subscription, authorization and usage/charging information (Wx, Wm, Wd, Wa); Use Differentiated Services (DiffServ) - colouring the DS field in the external IP header - as QoS mechanism between WLAN UE and PDG.

CT4 TS 23.008 updates via CR the subscriber data with WLAN QoS profile. CT4 TS 29.234 updates via CR the WLAN Access Authentication and Authorization procedures and Tunnel Establishment with QoS. CT1 TS 24.234 adds via CR the enhancements needed to support QoS provisioning over 3GPP/WLAN Interworking.

3GPP

21

Overview of 3GPP Release 7 V0.9.10 (2010-06)

6

Location Services

6.1 Location Services enhancements (LCS3) UID_32079
Resources: S1,S2,GP,C4,R2 Reference
Document SP-040682 SP-050119 TS 23.271 Title/Contents WID(s) S1 WID on Location Services enhancements Rel-7 S2 WID on LCS Enhancements (LCS3) Impacted Specifications Functional stage 2 description of Location Services (LCS) New Dedicated Specifications/Reports None

Global Stage 2 for LCS3 (including IMS emergency location aspects) covers in SA2 TS 23.271 several independent enhancements in the field of LCS in Rel-7 such as: • • • Location-Based Services enabling modifications such as velocity or periodic reporting; Location for IMS Emergency calls to enable routing to the correct PSAP; E112 Support Enhancements delayed from Rel-6.

6.1.1 LCS Enhancements Related to Location-Based Services (LCS3-LBS) UID_50558, 14025, 20042
Resources: GP,C4,R2 References
Document GP-050265 CP-050240 RP-050300 TS 43.059 TS 44.031 TS 49.031 TS 48.008 TS 24.030 TS 24.080 TS 29.002 TS 25.305 TS 25.331 TS 25.410 TS 25.413 TS 25.453 Title/Contents GP WID on LCS Enhancements Related to Location-Based Services (LCS3-LBS) UID_50558 C4 WID on LCS Enhancements Related to Location-Based Services (LCS3-UEPos-LBS) UID_14025 R2 WID on LCS Enhancements Related to Location-Based Services (LCS3-UEPos-Velocity) UID_20042 Impacted Specifications Functional stage 2 description of Location Services (LCS) in GERAN Location Services (LCS); Mobile Station (MS) - Serving Mobile Location Centre (SMLC) Radio Resource LCS Protocol (RRLP) Location Services (LCS); Base Station System Application Part LCS Extension (BSSAP-LE) MSC - BSS Interface; Layer 3 Specification Supplementary service operations - Stage 3 Mobile radio interface layer 3 supplementary services specification; Formats and coding Mobile Application Part (MAP) specification User Equipment (UE) positioning in Universal Terrestrial Radio Access Network (UTRAN); Stage 2 Radio Resource Control (RRC); Protocol specification UTRAN Iu interface: General aspects and principles UTRAN Iu interface Radio Access Network Application Part (RANAP) signalling UTRAN Iupc interface Positioning Calculation Application Part (PCAP) signalling New Dedicated Specifications/Reports -

Proposed LCS offerings are migrating beyond the initially targeted Emergency Services toward offerings that provide Location-Based Services (LBS). These LBS require information to be communicated that is not accounted for in current specifications. Additionally, Emergency Services are characterized by a single request for position resulting in a single position report. In contrast, many LBS require multiple reports of an UE’s position with varying update rates. Some of these requests may be call-independent location requests i.e. requests for a mobile’s position when the mobile is not on an active call. Changes to the current specifications could alleviate the consequences of increased messaging traffic and provide the capabilities required for a feature rich LBS offering.

3GPP

3 LCS for 3GPP Interworking WLAN (LCS3-IWLAN) UID_31052 Resources: S1. It provides a stand-alone SMLC (SAS) based overlay network interfacing UTRAN on the Iupc interface. and performed a gap analysis to determine whether existing 3GPP specifications can support LCS requirements for 3GPP WLAN interworking. It provides LBS by: • • Providing information required by LBS through enabling the reporting of velocity. Stage 2 UTRAN Iupc interface Positioning Calculation Application Part (PCAP) signalling New Dedicated Specifications/Reports - The Uplink TDOA (U-TDOA) location method has been standardized in the GSM Circuit Switched environment and standardization in the GSM Packet Switched environment (GPRS) is proceeding.S2 References Document SP-060291 SP-060818 TS 23.271 TS 23. Status Report in RP-060459 6. Mitigating the network impacts encountered by the increased usage of LBS through the enabling of periodic position reporting. LCS with 3GPP WLAN Interworking system is considered to enlarge the area of location service. 3GPP . System description Functional stage 2 description of Location Services (LCS) IP Multimedia Subsystem (IMS) emergency sessions New Dedicated Specifications/Reports (S1) Feasibility study on Location Services (LCS) for Wireless Local Area Network (WLAN) interworking To further the advancement of LCS within the 3GPP.935 Title/Contents WID(s) S1 WID on (Study of) LCS for 3GPP Interworking WLAN S2 WID on LCS for 3GPP Interworking WLAN Impacted Specifications 3GPP system to Wireless Local Area Network (WLAN) interworking. modifications such as implementation of periodic position reporting could be considered. turn-by-turn directions and point-of-interest finding require knowledge of the speed and direction of travel of the UE. This is complementary to already standardized location methods.167 TR 22.22 Overview of 3GPP Release 7 V0.1. LBS such as mobile tracking. this requirement could be achieved by providing the ability to report the velocity (speed and bearing) of a UE.1. LCS requirements and standards are extended for 3GPP WLAN interworking to support the same Location-Based Services that have been deployed today for GSM and UMTS. Status Report in RP-070797 6. RAN2 Completed Sept 2006.10 (2010-06) Specifically. scope of work required. As potential solutions to mitigate the increased messaging and the resultant increased bandwidth required for frequent location updates.234 TS 23. There is an interest in using the U-TDOA location technology for UMTS.2 Inclusion of Uplink TDOA UE positioning method in the UTRAN specifications UID_20012 Resources: R2 References Document RP-040387 TS 25.305 TS 25. As an example. SA1 studied technical requirements and architecture.9. Completed Nov 2007.453 Title/Contents WID(s) WID on Inclusion of Uplink TDOA UE positioning method in the UTRAN specifications Impacted Specifications User Equipment (UE) positioning in Universal Terrestrial Radio Access Network (UTRAN).

e. and particularly to the GALILEO system.101. In order to support LCS in I-WLAN.1 Towards A-GNSS Concept UID_50548 Resources: GP 3GPP .234. This has been done in the stage 1 of 22.071 None Title/Contents WID(s) WID on Advanced Global Navigation Satellite System (A-GNSS) concept Impacted Specifications Location Services (LCS).071. Service description. Study different possible LCS architectures to fulfil the LCS requirements for 3GPP WLAN Interworking scenarios. LCS for I-WLAN can leverage on today's location services and may offer additional services. There are advantages of enlarging the Assisted-GPS concept to Assisted-GNSS. IEEE 802. Investigate whether there are WLAN Interworking architecture enhancements necessary to support LCS. i. Also. This work also enables emergency services support in accordance with requirements in TS 22. It studied a generic interworking functionality for LCS between 3GPP system and WLAN systems (e. IEEE 802. New Dedicated Specifications/Reports - The existing mechanisms of Cell-ID or E-OTD provide high service availability but limited service accuracy.10 (2010-06) It determined that providing this service is feasible. SP-050584). CT1. TS 23.9. …) • • • • Specify LCS functional requirements for 3GPP WLAN Interworking scenarios. Additional considerations are required. in SA2. HIPERLAN/2…) covering: • • • • Study LCS requirements for 3GPP WLAN Interworking scenarios.11 family.271. Stage 1 (22.935 conclusion The intent of 3GPP-WLAN interworking is to extend 3GPP services and functionality to the WLAN access environment. the emergency location information handling for I-WLAN.g. the A-GPS method provides high service accuracy but service availability could be improved..11 family. TS 23.167 and in line with regulatory requirements for delivering the position of VoIP subscribers. 6.e. multiple positioning methods need to include WLAN access point locations.. This feasibility study has found no reason why existing 3GPP LCS specifications cannot support LCS requirements for I-WLAN. e. especially when considering the obstacles masking the signals of part of the GPS satellites in urban environments. since it allows improving the above lacks.071-0071r1. LCS functionalities developed by 3GPP for GSM and UMTS will have a similar appeal in IWLAN coverage areas. Specify LCS aspects for I-WLAN as IP-CAN in the IMS Emergency call.g.2 Advanced Global Navigation Satellite System (A-GNSS) concept (LCS3-AGNSS) UID_31051 Resources: S1 References Document SP-040681 TS 22. With the onset of other satellite positioning systems these conflicting requirements may be harmonized.g. i. The LCS capability in I-WLAN allows any properly authorized location based service to position an I-WLAN UE in any I-WLAN including roaming. TS 23. HIPERLAN/2. Specify LCS architecture to fulfil the LCS requirements for 3GPP WLAN Interworking scenarios. TR 22.23 Overview of 3GPP Release 7 V0. TS 23. the emergency location information handling for I-WLAN.2. It is feasible to offer LCS in I-WLAN. Investigate the LCS aspects for I-WLAN as IP-CAN in the IMS Emergency call.167 specify the interworking functionality for LCS between 3GPP system and WLAN systems (e. Specify WLAN Interworking architecture enhancements necessary to support LCS. LCS functionality in I-WLAN enhances the overall value of I-WLAN services. 6.

008 TS 48. The following items were developed in Rel-7: Items Carrier phase measurements reported by the MS to the Network Carrier measurements assistance Non native orbit models Orbit extension Non broadcast ephemeris flag Validity period information for orbit models Cell timing measurements for neighbouring cells Cell timing assistance for neighbouring cells Earth orientation parameters Stationary indication in MS-Assisted mode Code phase measurement description In particular.2 Global Navigation Satellite System (GNSS) in UTRAN UID_20050 Resources: R2 3GPP .BSS Interface. Additional delta packets to the original full shipment can be provided at a greatly reduced data overhead while preserving the ability to accurately compute the satellite location using the satellite location techniques already provided for in today’s implementations. Accurate satellite location information is among the important information content required by an MS in order to navigate well.059 TS 44.BSS GPRS Protocol (BSSGP) LCS . this approach would minimise additional impacts to the 3GPP specifications in case an interest arises in the future to add further GNSSs to 3GPP. This technique extends the life of an ephemeris by providing compact updates to the existing ephemeris information.031 were felt of relevant importance.035 TS 44. Base Station System Application Part LCS Extension (BSSAP-LE) Mobile Station (MS) conformance specification New Dedicated Specifications/Reports Title/Contents WID(s) The use of GALILEO either alone or especially in association with GPS improves the availability and the accuracy of the LCS Services provided by the PLMN in difficult situations such as urban or indoor environments where a limited number of satellites are visible and where satellite signals can be highly attenuated. Changes to TS 44. There is therefore an interest to introduce support of Assisted-GALILEO in the 3GPP specifications.9.Serving Mobile Location Centre (SMLC) Radio Resource LCS Protocol (RRLP) LCS .031 TS 51.Location Services (LCS) Specification MSC .SMLC/SMLC . The introduction of GALILEO would not result in duplication of A-GPS.018 TS 48.SMLCPP Specification Location Services (LCS).031 TS 49.031 TS 44.030 TS 43.24 Overview of 3GPP Release 7 V0.010 None WID on Towards A-GNSS Concept Impacted Specifications Radio network planning aspects Functional stage 2 description of Location Services (LCS) in GERAN Location Services (LCS). Mobile Station (MS) . 6. This information can be computed from Ephemeris data that can be provided in current assistance messages.10 (2010-06) References Document GP-042677 TS 43.Mobile radio interface layer 3 . The work item was therefore meant to introduce support of Assisted-GALILEO in the 3GPP TSG GERAN specifications as a particular case of an Assisted-GNSS. it has been highlighted that it was preferable to introduce Assisted-GALILEO in the 3GPP standards in a generic manner: GALILEO is considered as a particular case of a Global Navigation Satellite System (GNSS) (GPS is the first available GNSS. it was recommended that the full implementation of GALILEO and GNSS in general should include the option to extend the satellite orbits beyond that provided by the native format.071 TS 48.2. and other GNSSs can come to existence in the future). Since other satellite positioning systems are currently being developed or are likely to be developed in the near future.Broadcast Network Assistance for E-OTD and GPS Positioning Methods LCS . Layer 3 Specification GPRS / BSS / SGSN .

G3 References Title/Contents WID(s) GP-060834 WID on A-GPS Minimum Performance Impacted Specifications TS 45. This work added an A-GPS Minimum Performance core specification and associated Conformance test cases for Mobile Stations supporting A-GPS in the GERAN. Completed Sept 2006. since it allows improving the above lacks.433 TS 25. Protocol specification UE Radio Access capabilities UTRAN Iu interface Radio Access Network Application Part (RANAP) signalling UTRAN Iu interface Radio Access Network Application Part (RANAP) signalling UTRAN Iub interface Node B Application Part (NBAP) signalling UTRAN Iupc interface Positioning Calculation Application Part (PCAP) signalling Services provided by the physical layer Physical layer.453 TS 25.452 Title/Contents WID(s) WID on Global Navigation Satellite System (GNSS) in UTRAN Impacted Specifications User Equipment (UE) positioning in Universal Terrestrial Radio Access Network (UTRAN).171 respectively.10 (2010-06) References Document RP-060211 TS 25. and particularly to include the GALILEO system.005 Radio transmission and reception TS 51.9.010 Mobile Station (MS) conformance specification New Dedicated Specifications/Reports None Document A minimum performance specification is desirable to give the operators implementing services based on A-GPS a baseline performance that can be relied on in all equipped MSs. Stage 2 Radio Resource Control (RRC). With the onset of other satellite positioning systems these conflicting requirements may be harmonized.450 TS 25.302 TS 25. It introduces support of Assisted-GALILEO in the 3GPP TSG RAN specifications as a particular case of an AssistedGNSS (where Assisted-GPS was the first available Assisted-GNSS.171 and 34.215 TS 25.25 Overview of 3GPP Release 7 V0.401 TS 25. 3GPP . This approach minimises additional impacts to the 3GPP specifications in case of adding further Assisted-GNSS. and other Assisted-GNSS might exist in the future). Measurements (FDD) UTRAN overall description Synchronization in UTRAN Stage 2 UTRAN Iupc interface general aspects and principles UTRAN Iupc interface: signalling transport The Cell-ID or E-OTD methods provide high service availability but limited service accuracy. Status Report in RP-070482 6. by aligning as closely as possible with the two UTRAN specifications for Minimum Performance and associated conformance test cases which are available in 25. It covers both UE side (UE-assisted and UE-based) and network-assisted techniques.306 TS 25.413 TS 25. especially when considering the obstacles masking the signals of part of the GPS satellites in urban difficult environments. There are advantages of enlarging the Assisted-GPS concept to Assisted-GNSS.402 TS 25.3 A-GPS Minimum Performance (GAGR) UID_50581 Resources: G1.305 TS 25.331 TS 25. The A-GPS method provides high service accuracy but service availability could be improved.423 TS 25.

1. although the basic functionality already exists in Rel-6 MBMS.g. These new requirements were added via CR to TS 22. I-WLAN. e. via IP accesses such as WLAN.228 Title/Contents WID(s) WID on MBMS Enhancements Impacted Specifications Multimedia Broadcast/Multicast Service (MBMS).9.R1. 7. additional requirements are necessary to enhance the current MBMS in Rel-7 and enable IMS to use MBMS transport.10 (2010-06) 7 MBMS 7.246-0009 SP-060308) Service requirements for the Internet Protocol (IP) multimedia core network subsystem (IMS). From operators’ point of view it would also be desirable to profit from the radio-resource efficient broadcast / multicast mechanisms provided by MBMS transport services for IMS based services. MBMS reception over IP accesses. e. Support for adaptation of MBMS to the QoS resources provided by the access network(s). Stage 1 (CR 22. For these purposes. Higher MBMS bit-rate services (The impact on the throughputs in the RAN should be investigated). Stage 1 (CR 22.211 TS 25.146-0046 SP-050742) Multimedia Broadcast/Multicast Service (MBMS) user services.228-0034 SP-050510) New Dedicated Specifications/Reports - With the increasing deployment of MBMS services in networks.g.228.26 Overview of 3GPP Release 7 V0. Examples could be value-added services like e-learning or PoC-enhancements.1 MBMS Enhancements (MBMSE) UID_31084 Resources: S1.104 TS 25. The additional requirements identified are: • • • • Enabling IMS to use the MBMS bearer service. MBMS should provide higher bit-rates for applications like digital TV etc.146.246 and TS 22.212 TS 25. Stage 1 (CR 22. Additionally. users expect more stable services and more access alternatives for accessing them.C3 References Document SP-050389 TS 22.1 MBMS FDD Physical layer Enhancements UID_340042 Resources: R1 References Document RP-070226 TR 25.101 TS 25.246-0006.214 TS 25.213 TS 25.246 TS 22. TS 22.905 TS 25.331 Title/Contents WID(s) WID on MBMS FDD Physical layer Enhancements Impacted Specifications Feasibility study on improvement of the Multimedia Broadcast / Multicast Service (MBMS) in UTRAN User Equipment (UE) radio transmission and reception (FDD) Base Station (BS) radio transmission and reception (FDD) Physical Channels and mapping of Transport channels (FDD) Multiplexing and Channel coding (FDD) Spreading and modulation (FDD) Physical Layer procedures (FDD) UE Radio Access capabilities definition Radio Resource Control (RRC) protocol specification 3GPP .306 TS 25. These new requirements have been carefully considered regarding their effects on Rel-6 terminals and MBMS Rel-6 bearer service to ensure backwards compatibility.246-0007 SP050530) (CR 22.146 TS 22. CR 22.

The SFN area will be limited to the RNC area.e. and thus minimum impact on UE receivers. In order to take full advantage of the attainable data rates however higher order modulation and receiver performance supporting SFN operation is necessary.306 TS 25. MBMS data loss may occur during periods where a single receiver UE is receiving on the unicast carrier.222 TS 25.346 TS 25. Completed May 2007.221 TS 25.102 TS 25.10 (2010-06) Introduction of the Multimedia Broadcast Multicast Service (MBMS) in the Radio Access network (RAN). Stage 2 Synchronisation in UTRAN Stage 2 3GPP .905 studied the possibility of transmitting the MBMS service on a DL only carrier using a SFN network with an FDD channel structure.2 MBMS TDD Physical layer Enhancements UID_340043 Resources: R1 References Document RP-070241 TR 25. Necessary radio protocol enhancements to support FDD SFN operation on a DL only MBMS carrier SFN area selection and reselection for the dedicated SFN MBMS carrier Minimum UE capabilities related to the support of SFN MBMS reception and the support of simultaneous services on the unicast carrier Iub user and control plane protocols to support FDD SFN operation UE reception performance requirements for applicable bands for the SFN transmission BTS requirements for 16QAM transmission on S-CCPCH for applicable bands for the SFN transmission Conditions applied: • • • • The UE mobility requirements and procedures related to the unicast carrier must be met. The unicast serving RNC does not need to be aware of a UE receiving transmissions from a SFN MBMS carrier. Status Report in RP-070290 7.433 None Overview of 3GPP Release 7 V0.402 Title/Contents WID(s) WID on MBMS TDD Physical layer Enhancements Impacted Specifications Feasibility study on improvement of the Multimedia Broadcast / Multicast Service (MBMS) in UTRAN User Equipment (UE) radio transmission and reception (TDD) BS radio transmission and reception (TDD) requirements Requirements for support of radio resource management (TDD) Physical channels and mapping of transport channels onto physical channels (TDD) Multiplexing and channel coding (TDD) Spreading and modulation (TDD) Physical layer procedures (TDD) UE Radio Access capabilities definition Radio Resource Control (RRC) protocol specification Introduction of the Multimedia Broadcast Multicast Service (MBMS) in the Radio Access network (RAN).1. i. Stage 2 Synchronisation in UTRAN Stage 2 UTRAN Iub interface NBAP signalling New Dedicated Specifications/Reports - TR 25.223 TS 25. Handling of delay spread in the UE receiver to support reception of SFN MBMS that supports the assumed deployment scenario (to be discussed by RAN4) Ensuring backwards compatibility with the existing UTRA physical layer architectures in existing spectral assignments (legacy UEs should not camp on a dedicated SFN MBMS carrier).331 TS 25.123 TS 25. No optimisations are done within this work item for single receiver (one local oscillator) UEs. The study shows that the attainable data rates using a SFN operation for MBMS can be greatly increased with a minimum impact on the physical channel structure.224 TS 25.105 TS 25. It adds support for DL only SFN operation for FDD including: • • • • • • • • • • • Configuration of a common primary scrambling code.402 TS 25.9.346 TS 25. Receiver support for suitable equaliser technology.e.905 TS 25.27 TS 25. similar to Type-2 and Type-3. Support for 16QAM on S-CCPCH. i.

905 studied the possibility of transmitting the MBMS service on DL using an SFN network with a TDD channel structure. The unicast serving RNC does not need to be aware of a UE receiving transmissions from a SFN MBMS carrier.28 TS 25. In order to take full advantage of the attainable data rates however higher order modulation and receiver performance supporting more delay spread is necessary.331 TS 25.905 TS 25. Receiver support for suitable equaliser technology.402 Title/Contents WID(s) WID on MBMS LCR TDD Physical layer Enhancements Impacted Specifications Feasibility study on improvement of the Multimedia Broadcast / Multicast Service (MBMS) in UTRAN User Equipment (UE) radio transmission and reception (TDD) BS radio transmission and reception (TDD) requirements Requirements for support of radio resource management (TDD) Physical channels and mapping of transport channels onto physical channels (TDD) Multiplexing and channel coding (TDD) Spreading and modulation (TDD) Physical layer procedures (TDD) UE Radio Access capabilities definition Radio Resource Control (RRC) protocol specification Introduction of the Multimedia Broadcast Multicast Service (MBMS) in the Radio Access network (RAN).105 TS 25.e.221 TS 25.1. The study shows that the attainable data rates using a SFN operation for MBMS can be greatly increased with a minimum impact on the physical channel structure. Necessary radio protocol enhancements to support TDD SFN operation SFN area selection and reselection for the dedicated SFN MBMS carrier Minimum UE capabilities related to the support of SFN MBMS reception and the support of simultaneous services on the unicast carrier Iub user and control plane protocols to support TDD SFN operation UE reception performance requirements for applicable bands/slots for the SFN transmission BTS requirements for 16QAM transmission on S-CCPCH for applicable bands/slots for the SFN transmission RF Coexistence Conditions applied: • • • • The UE mobility requirements and procedures related to the unicast carrier must be met. Status Report in RP-070291 7.224 TS 25.433 None UTRAN Iub interface NBAP signalling Overview of 3GPP Release 7 V0.10 (2010-06) New Dedicated Specifications/Reports - TR 25. Completed May 2007.222 TS 25.9. and thus minimum impact on UE receivers. No optimisations are done within this work item for single receiver (one local oscillator) UEs. MBMS data loss may occur during periods where a single receiver UE is receiving on the unicast carrier. including diversity reception Handling of delay spread in the UE receiver to support reception of SFN MBMS that supports the assumed deployment scenario (to be discussed by RAN4) Ensuring backwards compatibility with the existing UTRA physical layer architectures in existing spectral assignments (legacy UEs should not camp on a dedicated SFN MBMS carrier).68Mcps including: • • • • • • • • • • • • Configuration of a common scrambling code for a subset or a all timeslots.3 MBMS LCR TDD Physical layer Enhancements UID_350022 Resources: R1 References Document RP-070253 TR 25.84Mcps / 7. Support for 16QAM on S-CCPCH.346 TS 25.123 TS 25. i. It adds support for SFN operation for TDD 3.306 TS 25.223 TS 25. Stage 2 Synchronisation in UTRAN Stage 2 3GPP . The SFN area will be limited to the RNC area.102 TS 25.

). and thus minimum impact on UE receivers.4 MBMS Mz interface UID_340046 Resources: C3 References Document CP-070109 TS 29.28Mcps including: • • • • • • • • • • • • • • • • Demonstrate gains with respect to Rel-6 MBMS Configuration of a common scrambling code for a subset or a all timeslots Receiver support for suitable equaliser technology including joint detection. The study shows that the attainable data rates using a SFN operation for MBMS can be greatly increased (with a minimum impact on the physical channel structure. MBMS data loss may occur during periods where a single receiver UE is receiving on the unicast carrier.1. It is assumed that similar performance gains can be achieved with respect to 1. In order to take full advantage of the attainable data rates however higher order modulation and receiver performance supporting more delay spread is necessary. i.9. Completed May 2007. Status Report in RP-070292 7.29 TS 25. No optimisations are done within this work item for single receiver (one local oscillator) UEs.84 Mcps TDD channel structure. Handling of delay spread in the UE receiver to support reception of SFN MBMS that supports the assumed deployment scenario Phase shifting for SFN transmission Ensuring maximum backwards compatibility with the existing UTRA physical layer architectures in existing spectral assignments(legacy UEs should not camp on a dedicated SFN MBMS carrier) No precluding Rel6 MBMS transmission modes in the same deployment Support for 16QAM on S-CCPCH Support for TDD SFN operation coexisting with R6 MBMS on a unicast carrier Necessary protocol enhancements to support TDD SFN operation SFN area selection and reselection for the dedicated SFN MBMS carrier Minimum UE capabilities related to the support of SFN MBMS reception and the support of simultaneous services on a unicast carrier Iub user and control plane protocols to support TDD SFN operation UE reception performance requirements for applicable slots for the SFN transmission BTS requirements for 16QAM transmission on S-CCPCH for applicable slots for the SFN transmission RF Coexistence Conditions applied: • • • • The UE mobility requirements and procedures related to the unicast carrier must be met.905 studied the possibility of transmitting the MBMS service on DL using an SFN network with a 3. The SFN area will be limited to the RNC area.061 Title/Contents WID(s) C3 Exception Sheet for WI on Multimedia Broadcast Multicast Service (MBMS) Mz interface protocol / MBMSMz Impacted Specifications Interworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN) New Dedicated Specifications/Reports - 3GPP .10 (2010-06) New Dedicated Specifications/Reports - TR 25.28 Mcps TDD.e. The unicast serving RNC does not need to be aware of a UE receiving transmissions from a SFN MBMS carrier.433 UTRAN Iub interface NBAP signalling Overview of 3GPP Release 7 V0. It adds support for SFN operation for TDD 1.

34.121-1. 34.122.108.2 MBMS . A number of useful service functions become possible and need to be specified.123-2.123-1. commands use description and AVPs were added via CR to TS 29. 1 Apr 2009 Flagged as Rel-7 i/o Rel-8 to match the Core specs release SR in RP-080541.3 MBMS User Service Extensions (MBMSUSE) UID_34038 Resources: S4 References Document SP-050838 TS 26.123-1 34. 34.UE Conformance Testing Acronym MBMSE_UEConTest WID SR Notes Linked to Feature UID_31084 (MBMSE).346 TS 26.109.10 (2010-06) CT3 has developed the Stage 3 protocol of the MBMS Mz interface. 34.123-3 MBMSERANPhysLCRTDD_UEConTest MBMSEUEConTest_RANPhysFDD RP080318 RP080336 RP090715 RP091214 RP#45 completed RP#46 completed 7. 34. For instance.061. Call flows.121-2. Protocols and codecs Multimedia Broadcast/Multicast Service (MBMS) user service guidelines New Dedicated Specifications/Reports - It is expected.946 - Title/Contents WID(s) WID on MBMS User Service Extensions Impacted Specifications Multimedia Broadcast/Multicast Service (MBMS).30 Overview of 3GPP Release 7 V0. RP#41 completed - TS-TR 25049 40005 9 40006 0 Conformance Test Aspects – MBMS TDD Physical layer Enhancements – MBSFN for HCR and VHCR TDD Conformance Test Aspects – MBMS LCR TDD Physical Layer Enhancement Conformance Test Aspects – MBSFN for FDD MBMSERANPhysTDD_UEConTest RP080155 RP080541 34. 34. which contains also Gmb interface. that the user equipment capabilities will evolve and that the minimal UE capability requirements increases and allow more flexible services for the Rel-7 timeframe.123-1/2/3 34.9.108. 7. one limiting UE capability for MBMS Rel-6 was that the UE should avoid using interactive bearer resources or any other uplink bearer resources while receiving an MBMS transmission. 34. 34. if 3GPP .108. 34.UE Conformance Testing UID_400058 Resources: R5 References Document WID(s) Impacted Specifications New Dedicated Specifications/Reports Title/Contents Linked to Feature MBMS Enhancements (MBMSE) UID_31084 UID 40005 8 Title MBMS .

g. Usage of interactive and streaming bearers for MBMS user service delivery. to smooth out jitter caused by peak media bit-rate temporally exceeding the channel bit-rate. Another aim was to extend the MBMS User Service to allow the provision (of MBMS User Service) on existing UMTS bearers with interactive and/or streaming traffic classes (i. 3GPP . Scalability extensions for unicast delivery of MBMS services: More than one entry point (server) is enabled for unicast delivery of MBMS to avoid problems with scalability (temporal high number of users). Additions of HTTP Response Error Codes: Additional error response codes were added for file repair to avoid ambiguities.and frame-rates) Also OMA BAC-BCAST was currently preparing a Mobile Broadcast Service specification. (Especially useful for variable rate media. whenever the gain justifies the changes.e. unicast bearers) without affecting MBMS Rel-6 UEs.2 for H.31 Overview of 3GPP Release 7 V0. Since MBMS is intended to serve large audience.) MBMS download service delivery to UEs in roaming condition: Procedures to provide MBMS download over unicast bearers using OMA Push protocol are completed. Improved video support for MBMS: Optional video support is raised from level 1. such as video. Signalling of initial buffering period: The same mechanism used in PSS for signalling of initial buffering period is included in MBMS. The MBMS User Services were aligned with the OMA BAC-BCAST service enabler. Enhanced services such as interactive services while consuming an MBMS stream and protecting the network against possible overload situations due to these enhanced services. considered as one of their broadcast distribution systems.b to level 1.9. Protocols and codecs) through CRs about e.346 (MBMS. The work outcome was brought into TS 26. Main objectives: • • • MBMS User Service optimizations.264 (enables better quality through the use of higher bit.: • • • • • • Optimization to allow smooth transition between MBMS and PSS: Synchronisation time between MBMS bearers and unicast bearers is reduced (when the same synchronisation source in the RTP packets is detected for both PSS and MBMS flows). the usage of the uplink resources must be controlled to avoid overload situations in the uplink and in infrastructure nodes.10 (2010-06) MBMS UEs may start using an uplink communication channel in parallel with an MBMS reception channel. including bearer independent procedure.

111-144 CP-050141) Secured packet structure for (Universal) Subscriber Identity Module (U)SIM Toolkit applications (CR 31.090-0003r3 SP-060445) Universal Subscriber Identity Module (USIM) Application Toolkit (USAT) (CR 31. However. This feature is considered to be very desirable by many operators. add the Java API routines for the above commands. Originally this feature was first devised in T3 (now CT6) which identified the need to: • • • • • • add addressing in the USSD message.130-014 CP050141) New Dedicated Specifications/Reports - Since R99 there has been a mechanism to deliver Unstructured Supplementary Service Data (USSD) strings from the USIM to the network and receive the reply.048 to clarify the use of this specification over USSD. provide backwards compatibility. there was no specified delivery and transfer mechanism for the USIM to receive Network initiated USSD. add a USSD clause to TS 23. Stage 1 (CR 22. add USSD as part of Bearer Independent protocol in USAT.111 TS 31.9. (U)SIM API for Java Card (CR 33.32 Overview of 3GPP Release 7 V0.10 (2010-06) 8 SA1 Features 8. 3GPP .090 TS 31.1 USSD message delivery and transfer to USIM (USSD-USIM) UID_31048 Resources: S1.130 - Title/Contents WID(s) S1 WID on USSD message transfer to USIM C6 WID on Alignment with requirements regarding USSD usage Impacted Specifications Unstructured Supplementary Service Data (USSD).115 TS 31.C6 References Document SP-040104 TP-040069 TS 22. add a USSD data download command to USAT.115-005 CP050141) (U)SIM Application Programming Interface (API).

The existing address context is reused when the combined service is established. Core network protocols.C1.008-1062r1 CP-060121) Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP).S4 References Document SP-050228 CP-060105 SP-050091 TS 22. In addition either user can add an IMS session to a CS speech call or a CS Multimedia call.279 TR 24.008 TS 24. enable the unidirectional or bi-directional (simultaneous send / receive) exchange of PS data within the context of an IMS session. interoperability between UEs that implement different approaches is possible. the IMS registration can be performed at switch-on or on demand. camped on identical or different RATs. Default codecs (CR 26. Stage 3 This work was triggered by the Study on Combining CS calls and IMS sessions UID_31055 in TR 22. Supplementary services as they relate to CSICS. Stage 1 Combining Circuit Switched (CS) and IP Multimedia Subsystem (IMS) services.228 TS 24.235 TS 22. The user (A or B party) only needs to know one address in order to establish the combinational service.9.164 number exchange.235-0014r3 SP-050790) New Dedicated Specifications/Reports Combined Circuit Switched (CS) and IP Multimedia Subsystem (IMS) sessions.229 TS 26. Requirements for the following capabilities are included: • • • • • • Radio capability exchange. Stage 2 Combining Circuit-Switched (CS) calls and IP Multimedia Subsystem (IMS) sessions Combining Circuit Switched (CS) and IP Multimedia Subsystem (IMS) services. 3GPP . Depending on the differing UE implementations. Terminal capability exchange. both users A and B must have valid subscriptions for voice calls as well as for accessing the IMS.S2.33 Overview of 3GPP Release 7 V0. Media formats and codecs (CR 26. Adding IMS session to an ongoing CS call. and roaming. A specific subscription for combinational services is not necessary. Stage 3 (CR 24.279 Title/Contents WID(s) S1 WID on Specification of Combining CS and IMS services & Capability Detection and Exchange mechanism C1 WID on Stage 3 Specification of Combining CS and IMS services & Capability Detection and Exchange mechanism S4 WID on Stage 3 Specification of Combining CS and IMS services (Release 7) Impacted Specifications Service aspects. A user may be invited even though he is not IMS registered. However. Stage 1 Architectural requirements IP Multimedia Subsystem (IMS). which are applicable to both UTRAN and GERAN.979. The combinational service can be established between two users: • • • within the same PLMN or within different PLMNs. If not.228 TS 23. Charging and billing Service requirements for the Internet Protocol (IP) multimedia core network subsystem (IMS). when roaming (assuming the visited operator supports GPRS roaming). which makes the combined service simple to invoke for the user.115 TS 22. The capabilities defined for CSICS support interoperability between different operator networks.221 TS 23.279 TS 23. E. then the invited user is able to accept or reject the IMS registration request.141 TS 26.2 Combinational Services (CSICS) UID_31063 Resources: S1. Also. thereby creating a combinational call or vice versa. Adding a CS call to an ongoing IMS session. Stage 2 Mobile radio interface Layer 3 specification.229-1183 CP-060121) IP Multimedia System (IMS) Messaging and Presence.10 (2010-06) 8. The IMS session may consist of one or more IMS services. Combinational services.879 TS 24.141-0002r5 SP-050790) Packet switched conversational multimedia applications. Stage 3 (CR 24.

stage 2 in TS 23. This work defines stage 1 in TS 22.34 Overview of 3GPP Release 7 V0. 3GPP .279.9.279 and stage 3 TS in 24.279.10 (2010-06) A combinational service is possible for both unidirectional and bi-directional exchange of PS data within the context of the IMS session.

018 TS 23.35 Overview of 3GPP Release 7 V0.078-0770r1 CP-050103) (CR 23.078-0396r1 CP-050626) New Dedicated Specifications/Reports - Customised Application for Mobile network Enhanced Logic (CAMEL) was defined for mobile originated & mobile forwarded calls in the Visited Mobile Switching Centre (VMSC).e. In addition to mobile originated calls.078-0182r1 SP-050064) (CR 22.078 Customized Applications for Mobile network Enhanced Logic (CAMEL). Stage 1 (CR 22. It includes the feature CAMEL Trunk Originated TDPs to CAMEL Phase 4. CAMEL already provided Network CAMEL Service Information (N-CSI).078-0192 SP-050744) Basic Call Handling.078 TS 29. this required Camel Service Environment (CSE) interaction for calls from fixed terminals (received over a trunk interface at the MSC) and calls from foreign GSM-R networks (received over a trunk interface at the MSC). In addition.078-0793r1 CP-050626) Mobile Application Part (MAP) specification (CR 29. to identify services offered by the serving PLMN operator equally for all subscribers. CAMEL Application Part (CAP) specification (CR 29.3 CAMEL Trunk Triggers (TTCAMEL) UID_31065 Resources: S1 References Document SP-040743 NP-040550 Title/Contents WID(s) S1 WID on CAMEL Trunk Originated Trigger Detection Points (to enable CSE interaction for trunk-originated calls at the MSC/ SSP) C4 WID on CAMEL Trunk Originated Trigger Detection Points (To enable CSE interaction for trunk-originated calls at the MSC/ SSP) Impacted Specifications TS 22.078-0392r1 CP-050103) (CR 29. Service description. PRI) trunk interface. Stage 2 (CR 23. This work requires CAMEL Service Information to identify services offered by the serving PLMN operator for all calls received over a specific trunk at the MSC.078 TS 23. This requires CSE interaction for calls from fixed terminals received at the MSC from a public (e. 3GPP .002 TS 29. Technical realization (CR 23. There are however some existing and new service scenarios that would benefit from CAMEL being defined for trunk originated calls at the MSC.10 (2010-06) 8. ISDN/ PSTN) trunk interface. CR 23. operators could use CAMEL trunk originated TDPs to allow access to existing CSE-based services for calls from fixed terminals received at the MSC from a private (i.018-0145r1 CP-050103) Customized Applications for Mobile network Enhanced Logic (CAMEL) Phase X. Some GSM-R operators wanted to use CAMEL to provide number translation functions in multi-vendor GSM-R networks.002-0765r1 CP-050103) Customized Applications for Mobile network Enhanced Logic (CAMEL) Phase X.078-0792r2: CR 23.g.078-0764r1. Operators who incorporated wireline access to existing CSE-based services may also want to use CAMEL to provide this capability for multi-vendor networks.9. mobile terminated calls in the GMSC and VMSC and gsmSCF initiated new call or new party in an existing call.

firebrigade.g.068 TS 29.10 (2010-06) 8.9. transport mechanisms of keys. emergency handling. Key Management of group keys for Voice Group Call Services Although ciphering of the air-interface is mentioned in 42. or SMS support. HLR. emergency handling.068 (a number of group keys is used for each group) no mechanism has been specified concerning the key management of the group keys. specification of: Where group keys are stored in the network (e. as end-to-end (E2E) encryption.068 TS 29. etc.g. emergency case talker request. BSS) Where group keys are stored in the mobile equipment (e.4 Enhancements of VGCS for public authority officials (EVGCS) UID_11045 Resources: S1.068 and 43. Rel-7 introduces enhancements allowing VGCS to be used by public authority officials (police. including e. some additional functionality are added to VGCS services.).068 (Stage 2) and 44.g.011 TS 44.g. It is required that E2E speech encryption in voice group calls is supported.040 TS 24. USIM or handset) How groups are transported between different network entities (e. etc). To meet the associated particular requirements. where to store the keys. i.068 TS 44. Group Call Register.002 - Title/Contents WID(s) Enhancements of VGCS in public networks for communication of public authority officials Impacted Specifications Stage 2 modifications for talker priorisation and display of additional information about the current talker Stage 3 modifications for talker priorisation Stage 3 enhancements of MAP messages for talker priorisation and display of additional information about the current talker Stage 2 modifications for E2E encryption and SMS delivery Stage 2 modifications of SMS delivery Stage 3 modifications of SMS protocol Stage 3 modifications for E2E encryption Stage 3 enhancements of MAP messages for E2E encryption and SMS delivery New Dedicated Specifications/Reports - Voice Group Call Services (VGCS) can be used in public networks for communication of public authority officials (police. These enhancements are mostly: Support of talker prioritisation (eg priority subscriber talker request. This WI is a catch-all for all hiccoughs that occur in Security.068 (Stage 1). VGCS is specified in 42. who is the current talker. encryption. 43. will be heard by all other members.e. firebrigade. See the Rel-4 description document to get more information on VGCS.g.36 Overview of 3GPP Release 7 V0. SMS support).068 (Stage 3). from the Group Call Register to the BTS) How the group key identification and selection is done 3GPP . e. The voice group call services (VGCS) is a Feature introduced in Rel-4 which offers the possibility to a group a people to communicate in such a way that any member of the group. avoiding them to use a dedicated (expensive) network such as TETRA and TETRApol.002 TS 43. directly from public networks.g. VLR. To meet the particular requirements for this purpose additional functionality needs to be supported by VGCS (e.C1 References Document CP-050528 TS 43.068 TS 23. emergency talker reset) alert in voice group calls Sending short messages to a voice group to all group members Display of additional information (text) about the current talker to all group members Support of E2E ciphering in voice group calls: see below VGCS services used for communication of public authority officials have to fulfill additional security requirements.

068 TS 44.068-0069r1 CP-060123) Group Call Control (GCC) Protocol Mobile radio interface Layer 3 specification. These enhancements affect the group call itself.068 TS 43. 3GPP .9. CR 42. use of GPRS in parallel to a VGCS). Layer 3 specification Mobile radio interface layer 3 specification. Stage 3 Mobile Application Part (MAP) specification Mobile Switching Centre .068-0013.008 TS 29.10 (2010-06) 8.068 TS 24. Stage 1 (CR 42. were needed (e. Core network protocols. However. SMS to single users during an active group call.C1. Stage 2 (CR 43.G2 References Document SP-050075 SP-040304 NP-050141 GP-071855 TS 42.008 TS 44.018 - Title/Contents WID(s) WID on Improvements of VGCS in public networks for parallel use of services WID on Enhancements of VGCS in public networks for communication of public authority officials WID on Improvements of VGCS in public networks for parallel use of services WID on Enhancements for VGCS Applications Impacted Specifications Voice Group Call Service (VGCS).Base Station system (MSC-BSS) interface. Radio Resource Control (RRC) protocol New Dedicated Specifications/Reports - Requirements for use of VGCS in public networks for communication of public authority officials have been defined (SP-040304).g.068-0014 SP-050224) Voice Group Call Service (VGCS). further improvements.002 TS 48. not directly concerning the group call but the use of other services in parallel.37 Overview of 3GPP Release 7 V0.5 Improvements of VGCS for parallel use of services (IVGCS) UID_11055 Resources: S1.

198-11 29.198-07 29.C5 The Open Service Access (OSA) enables service application developers to make use of network functionality through open. Part 3: Call notification 3GPP . and of vendor specific solutions and programming languages. Part 4: Call control. where an annex defines the extension of the capabilities to enable operation in cdma2000 systems environment. like distributed object oriented technique and Web Services technologies. secure. Stage 2 (CT5) 29. OSA Web Services (29.198-06 29. The OSA API is independent of where or which network capabilities are implemented in the network.199-family) • Access to Service Capability Features is realised by using modern state of the art access technologies.199-01 29. Parlay X web services. Part 4: Call control.198-15 29. The 3GPP2 is using the 3GPP Stage 3 specifications. Part 14: Presence and Availability Management (PAM) SCF OSA API.198-08 29. Part 1: Common OSA. OSA needs to evolve in form of small technical enhancements based on market/ implementations feedback and also addition of new functionality.198-14 29.198-13 29. Subpart 4: Multimedia call control SCF OSA API.198-04-1 29.198-03 29. Part 15: Multi-media Messaging (MM) SCF OSA. Part 4: Call control. Part 7: Terminal capabilities SCF OSA API. A secure OSA API is a key enabler for the Virtual Home Environment (VHE) system concept.198-04-3 29. Part 5: User interaction SCF OSA API. Parlay X web services. Subpart 2: Generic call control SCF OSA API. OSA APIs (29. all formats of the API.38 Overview of 3GPP Release 7 V0. Part 12: Charging SCF OSA API.198-family) • • The OSA specifications define a set of APIs that enables operator and 3rd party applications to make use of network functionality through a set of open. which requires users to be consistently presented with the same personalised services in whatever network and terminal.199-03 Stage 3 Specifications OSA API. Part 8: Data session control SCF OSA API. Part 13: Policy management SCF OSA API. extensible and scalable interfaces. Stage 1 (SA1) OSA. Part 4: Call control. Part 1: Overview OSA API.199-02 29. the IDL code. Part 2: Common data definitions OSA API.198-02 29. References Document SP-050183 CP-070200 22. standardized interfaces.198-05 29. Subpart 1: Call control common definitions OSA API. Using the latest document and code generation techniques.198 Title/Contents WID(s) S1 WID on OSA Stage 1 C5 WID on OSA Stage 2/3 enhancements Impacted Specifications OSA. Part 2: Third party call OSA. This ensures alignment between all versions. Parlay X web services. The OSA specifications were developed by the Joint-Working-Group (JWG) of Parlay.9. subject to the capabilities of both.198-12 29.127 23.6 Open Service Access (OSA7) UID_31071 Resources: S1. the ETSI TISPAN Project OSA and 3GPP CT5. Part 3: Framework OSA API. Part 6: Mobility SCF OSA API. standardised. WSDL code and Java API are all produced from a single source UML model.198-04-2 29. the detailed technical description documents. Part 11: Account management SCF OSA API. WSDL description of the interfaces are attached to the technical specifications.198-04-4 29. Subpart 3: Multi-party call control SCF OSA API.198-01 29. These SCFs provide access to the network capabilities on which the application developers can rely when designing their applications. The specifications are derived from a UML model of the OSA API.10 (2010-06) 8. Applications see the network functionality offered to them as a set of Service Capability Features (SCFs) in the OSA API.

Multimedia Multicast Control Web Service (new TS 29.10 (2010-06) OSA. Update OSA Stage 2/3 to take account of Web Service industry developments 10.user status service mapping. Service Provisioning. Parlay X web services.305 Title/Contents WID(s) S1 WID on Selective Disabling of UE Capabilities C1 WID on Support of Selective Disabling of UE Capabilities (SDoUE) – Stage 3 Impacted Specifications Service accessibility New Dedicated Specifications/Reports Selective Disabling of UE Capabilities (SDoUE) Management Object (MO) With increasing data usage and the drive towards increasing the ARPU per subscriber from increased data usage. This can also be a substantial threat. The misbehaving application may be downloaded by the user through various means: e-mail. Part 13: Address list management OSA.199-19 29. Parlay X web services.199-04 29. Similar problems may also arise with downloaded applications that are not functioning correctly and which could repeatedly make a connection request requiring both allocation of radio resources and network signalling processing.199-10 29.199-14 Overview of 3GPP Release 7 V0.199-12 29.998-06-1 29.199-17 29. SMS and Push services. Parlay X web services. Parlay X web services.199-05 29.S2.199-20 29.199-16 29. Application Driven QoS Web Service (new TS 29. Part 7: Account management OSA.39 29. Message Broadcast Web Service (new TS 29. Update Web Services to align with completion of IETF work (impact also on previous Releases) 8. OSA Service Brokering (new TS 29.198-16 29.199-16) 4. Multimedia Streaming Control Web Service (new TS 29. Part 17: Application-driven Quality of Service (QoS) OSA.199-15) 3. Feature Interaction and Service Chaining. Parlay X web services.199-19) 7. Geocoding Web Service (new TS 29.199-20) 8. While operators may be able to maintain some degree of control this poses a significant threat to the industry at large.user status service mapping. Parlay X web services. Part 14: Presence 29. Parlay X web services. Part 16: Service broker SCF OSA. Parlay X web services. Parlay X web services. Part 6: User location . providing an API that supports functionality including Service Selection. Part 18: Device capabilities and configuration OSA.011 TS 24.199-13 29.199-18) 6. Part 16: Geocoding OSA. Subpart 1: Mapping to MAP OSA API Mapping. Device Capabilities and Configuration Web Service (new TS 29. Part 4: Short messaging OSA. Parlay X web services. Parlay X web services. Parlay X web services. and (exceptionally) fail to be detected and disabled by application layer preventative measures. Part 8: Terminal status OSA. 3GPP . Parlay X web services. Subpart 2: Mapping to SIP New and enhanced functionality was added in Rel-7 as follows: 1.998-06-2 New Dedicated Specifications/Reports Stage 3 Specifications OSA API. Part 20: Multimedia multicast session management OSA API Mapping. Part 11: Audio call OSA.199-08 29. Part 12: Multimedia conference OSA.9.198-04-5) 9.199-18 29. Part 9: Terminal location OSA. Part 6: Payment OSA.198-04-5 29.199-11 29.199-17) 5. Part 6: User location . Parlay X web services. Parlay X web services. Parlay X web services.199-06 29.C1 References Document SP-050182 CP-060181 TS 22. Part 15: Message broadcast OSA.199-15 29. the need for effective methods of dealing with the consequences of downloading and activating a virus in a mobile telephone needed to be addressed. 2. Subpart 5: Conference call control SCF OSA API. Part 10: Call handling OSA. OSA API Conference Call Control SCF (new TS 29. Parlay X web services.7 Selective Disabling of UE Capabilities (SDoUE) UID_31053 Resources: S1.199-07 29. Part 5: Call control. Part 19: Multimedia streaming control OSA.198-16) The Service Broker function enables the delivery of multiple services in the network of an operator in a managed and controlled fashion. Similar problems may also arise with viruses. Part 5: Multimedia messaging OSA.199-09 29.

805 (Selective disabling of User Equipment (UE) capabilities. Means were provided to inform the user about the full or partial disabling of the mobile and the reason for this.9. Report on technical options and conclusions) was abandoned.011 and Stage 3 in the new CT1 TS 24. effectively quarantining the device. Draft SA2 TR 23. The relation to existing “black list” features had been analyzed. The outcome of the work was implemented via CRs in SA1 TS 22. if the misbehaving application impacts only the PS domain.g.e.10 (2010-06) This work provides a means of disabling an infected device from registering again on the network. then it should be possible to allow CS domain connections such as Emergency calls or vice-versa.305. even if the mobile has been successively switched off and on. The criteria for determining when an application is misbehaving were outside the scope of this work item. It also provides a means of maintaining the disabled status of the device. i. both in the current network and any other network. Threats a reactive network protection mechanism mitigates were analyzed. 3GPP . Selective disabling of the mobile device were provided to allow the establishment of connection types which are not impacted by a virus or application error. New threats potentially introduced by a network protection mechanism had been studied.40 Overview of 3GPP Release 7 V0. e.

2.011-0076 SP-060311). three definitions and one abbreviation added. style changed (HPLMN) in one definition to match the others (CR 21. then the UE should register on the HPLMN/EHPLMN immediately.2.122 TS 24.011-0073 SP-060033). A new requirement added as an optional feature of the ME.0110069r2 SP-060221).011-0078r1 SP060426).011 clause 4.102 TS 45.011-0077 SP-060311). An option was added to display either all the available EHPLMNS or just the highest available based on a USIM flag when in Manual Network Selection mode (CR 22. The restriction that a successful registration on a forbidden PLMN only happens in manual mode was removed (CR 22.011-0075 SP-060033). Steering of Roaming requirements were introduced that allow the HPLMN to direct the UE to select a specific VPLMN and to direct the UE to steer away from a specific VPLMN (CR 22. but the HPLMN is. for the user to be able to set a preference in the ME for the mode that shall be used at switch on. or if RPLMN and EPLMN are not available.41 Overview of 3GPP Release 7 V0.9.2.011-0079r3 SP-060451). Core network protocols.101 TS 23.905 TS 22.10 (2010-06) 8.811 (Study on Network Selection Principles (NetSel) UID_31073) and the network selection workshop. if RPLMN is not available in the SIM/USIM. An implementation option is added to indicate that at power-on only. This is an exception and the UE remains in manual mode (CR 22.011-0070 SP-060033).122-0098r2 CP-060359). • • 3GPP . this work translates the findings into specifications.3 that the ME shall read all the information of data files stored in the SIM related to network selection (CR 23.905-0068 SP-060033).8 Network selection enhancements (NSP-CR) UID_7041 Resources: S1 References Document SP-050227 SP-060220 CP-060357 TS 21. The list of PLMN types listed to include Forbidden PLMNs was extended as this is considered useful information to a user (CR 22. This behaviour is under the control of the operator (CR 22. Changes included: • • • • • • • • • • • The definitions in 21.2 indicating that additional information on the available PLMN may be presented when the user is in manual mode (CR 22.905 are corrected to align the definitions with those already used in the existing stage 2 and stage 3 specifications of the protocol.2. A new requirement was added in clause B of 3. An optional requirement is added to allow alternate UE behaviour which would allow the UE to go to the HPLMN if available and not return to the last RPLMN.2.1 to clarify that the ME shall utilise all the information stored in the USIM related to network selection (CR 22. A statement was added to indicate that the safe roaming functionality is only applicable if the UE is in automatic mode of operation (CR 22. A clarification is added to clause 3.011-0074 SP-060033). A change was made to 23. Service principles Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode Mobile radio interface Layer 3 specification. One definition corrected (VPLMN).008 TS 25.011 TS 22.8 on Steering of Roaming to clarify the effect on the User Controlled PLMN List and the Forbidden List.4. A small addition was made to clause 3.011-0071 SP-060033).304 TS 31.008 - Title/Contents WID(s) SA1 SID on Review of Network Selection Principles SA1 WID on Network selection enhancements CT1 WID on Network Selection Enhancements – Procedural aspects Impacted Specifications Vocabulary for 3GPP Specifications Service accessibility Service aspects. A new feature is introduced that prompts the end user to confirm that roaming is required when near a border (CR 22. If set then the ME would select this preference rather than the default mode (CR 22.2. Stage 3 User Equipment (UE) procedures in idle mode and procedures for cell reselection in connected mode Characteristics of the Universal Subscriber Identity Module (USIM) application Radio subsystem link control New Dedicated Specifications/Reports - Following TR 22.011-0072 SP-060033).

42 Overview of 3GPP Release 7 V0.108 TS 34. 3GPP .10 (2010-06) 8.9.123-1/2/3 None Title/Contents WID(s) WID on Network Selection Enhancements – Procedural aspects Impacted Specifications Common test environments for User Equipment (UE) conformance testing User Equipment (UE) conformance specification New Dedicated Specifications/Reports - Status Report in RP-080819.1 Network selection enhancements (NSP) .8. Linked to UID_7041 (NSP-CR).UE Conformance Testing UID_25048 Resources: R5 References Document RP-080135 TS 34.

how to prevent all mobiles re-establishing PDP contexts when one GGSN fails. TR 23. how to avoid automatic re-establishment attempts by PS domain applications (cf the auto-redialling restrictions in TS 02. cell level congestion (e. traffic jam in a large town served by many cells) RNC/BSC overload MSC overload/failure Voice transit network (and/or MGW?) overload/failure SS7 signalling network overload/failure (e.g. Based on the available information at this stage.) Based on requirements given in S2-040529. SA2 studied 3GPP system enhancements needed to cope with R97 (GPRS). 9. R99 (UMTS) and Rel-5 (Iu-flex) architectural changes as follows: 1. In addition. S2-040842 indicates that the Access Class Control and Overload Protection functions of the 3GPP system have not been enhanced to cope with architectural changes made in R97. 4. the solution of domain specific access control in case of CS domain overload in Rel-6 was given the highest priority in this study.g.C1 References Document SP-040338 TS 24. Stage 3 New Dedicated Specifications/Reports Access Class Barring and Overload Protection (ACBOP) SA2 has received requirement from SA1 (S2-040529 = S1-040129) to investigate any mechanisms necessary for Domain Specific Access Control within the UTRAN.10 (2010-06) 9 SA2 Features 9. impact on MM. Correction of the load re-distribution capability of RAN nodes and the handling of CN node failure in the Iu-Flex configuration. a subset of the functionality can be concluded while other complementary functionality needs further study. 7. and was asked for investigation related to an issue where overload in the CS transit network caused a restriction in the packet switched traffic while radio capacity was available. Core network protocols.07 Annex A).898 Title/Contents WID(s) WID on 3GPP Access Class Barring and Overload Protection Impacted Specifications Mobile radio interface Layer 3 specification. 5. 6. It was considered valuable to investigate impacts and study issues going beyond CS congestion issues on UTRAN. 3.g.9. GMM and SMS) SGSN overload/failure "packet backbone" (GTP-U or Gi) overload/failure GGSN overload/failure (e. 8. 2. R99 and Rel-5. traffic jam on country road served by one cell) wide area radio interface congestion (e.43 Overview of 3GPP Release 7 V0.1 Access Class Barring and Overload Protection (ACBOP) UID_32064 Resources: S2. At this stage it has not been possible to reach a conclusion on the following subset of the functionality: • Permission of SMS while Access Class Barring prohibits any other traffic.898 has analysed a variety of potential solutions on how to cope with different network overload and failure situations.g. 3GPP . Other considerations include: • • the impact of the URA-PCH and Cell-PCH states. Conclusion: The recommended enhancements to the current specifications are to adopt: • • Domain Specific Access Class Barring (DSAC).008 TR 23.

25.0). Stage-3 The standardization of fixed broadband access to IMS is addressed by a number of SDOs.209 TS 33. as seen appropriate from a 3GPP system perspective. mobility management is not included). 3GPP . This work provides enhancements to IMS within 3GPP for fixed broadband access.10 (2010-06) • • Permitting the mobile to respond to paging while Access Class Barring prohibits mobile originating traffic. The work provides possible IMS architectural enhancements necessary in the 3GPP system to support fixed broadband access to IMS.298 and TS 32. This work was limited to the current scope of the IMS.413) and GERAN (44. Access security for IP-based services Packet switched conversational multimedia applications. Stage 2 Telecommunication management.S3.299. e.g.203 TS 26. session control (e.299 TS 24.229 TS 29. Stage 3 Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks Policy control over Gq interface 3G security.163 TS 29. Service interaction aspects had been taken into account. as stated in ETSI TISPAN release 1 and PacketCable 2.g. Transport protocols New Dedicated Specifications/Reports Protocol impact from providing IMS services via fixed broadband. This will embed IMS as the framework for advanced multimedia services for many types of operators. are covered by SA5 TS 32. Diameter charging applications Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP).240.C1.260 TS 32. IP Multimedia Subsystem (IMS) charging Telecommunication management.C4 References Document SP-060145 NP-040618 SP-050395 TS 22. Charging management.819 Title/Contents WID(s) S2 WID on System enhancements for fixed broadband access to IMS C1 WID on Protocol impact from providing IMS services via fixed broadband S3 WID on IMS security extensions Impacted Specifications Service requirements for the Internet Protocol (IP) multimedia core network subsystem (IMS). 9.e. The 3GPP/TISPAN workshop agreed that ETSI/TISPAN will define NGN session control using IMS as a platform.2 System enhancements for fixed broadband access to IMS (FBI) UID_32074 Resources: S2. Prevent/delay automatic re-establishment attempts for PS session and SMS.298 TS 32. TS 32. Charging management. Stage 3 Core Network aspects of ACBOP were implemented as CR by CT1 (24.S5.018) as per WID in SP-040338. Some enhancements of the 3GPP specifications were needed for IMS to enable external organizations to reuse IMS as a platform for session control for systems with fixed broadband access.228 TS 23. (e.9.228 TS 32. The TSG CT-wide work provides possible enhancements of protocols used in IMS in order to support NGN such as: • Simulation of existing PSTN/ISDN services Any SIP and SDP (or other protocol) specification necessary to provide PSTN/ISDN services in the IMS. i. Stage 3 Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP). During the SA#30 it was then agreed to incorporate changes on fixed broadband access to IMS stemming from PacketCable2. ETSI and ITU-T in the framework of Next Generation Networking (NGN). Charging management. including cable access.0 requirements.331. Charging management. NOTE: No work has been done in RAN (25.g. Charging Data Record (CDR) parameter description Telecommunication management.236 TR 24.44 Overview of 3GPP Release 7 V0.240 TS 32. TS 32. Offline charging aspects related to fixed broadband access. Charging architecture and principles Telecommunication management.C3.229 TS 29.008).260. Stage 1 IP Multimedia Subsystem (IMS).

one cannot rely on having a physical UICC to implement the security mechanisms.e. SA3 studied if IMS access security solution needs to be extended." However. IMS service and HSS. IMS Commonality. Furthermore. Rel-5 and 6 IMS access security solution was mainly designed for UMTS access networks. Issues not targeted for R1 of TISPAN. and deploys terminal. The IMS signalling protection solution that traverse NA(P)T is a fundamental need for TISPAN NGN R1. Lawful interception and MMI aspects like visibility of offered security level and user interaction had been studied. It shall also be possible to use different access technology to connect the "IP multimedia CN Subsystem" e. Where appropriate changes were integrated in existing works items e. TISPAN stated that "TISPAN NGN R1 priority is for securing IMS for a fixed network.45 Overview of 3GPP Release 7 V0.102. and is independent of any discussion of what mobile operators may or may not mandate for interconnection to their IMS services i. SA3 studied security requirements and solutions related fixed broadband access to IMS with special focus on an IMS signalling protection solution that traverse NA(P)T and firewall devices. NGN QoS requirements Provides enhancements to the Go/Gq interfaces to enable control of bearer resources in the NGN. Non-3GPP access networks Any SIP and SDP (or other SIP message body) specification necessary to access IMS through NGN access technologies. SA3 Security aspects are covered in TS 33. The unity of the security extensions to the IMS security specifications must be preserved and handled in SA3. Another objective was to study requirements and solutions for IMS security in conjunction with solutions for secure access to the Core Network which are independent of access networks and applications. network. Even though the access security solution is access network independent. NGN charging requirements Any SIP and SDP (or other SIP message body) specification necessary to provide for transport of NGN specific charging information in the IMS. IMS security architecture relies partly on underlying network security. the authentication of the IMS subscriber must be based on access to physical UICC. 3GPP . In this case.g.10 (2010-06) • • • • • NGN security requirements Any SIP and SDP (or other SIP message body) specification necessary to provide secure access to the IMS from NGN terminals. wireline and Wireless LAN etc. It studied also other requirements and solutions needed for TISPAN NGN R1. the fixed operator has a commercial relationship with the customer. as well as possible solutions. xDSL. such as fixed broadband access as currently specified in ETSI and ITU-T in the framework of Next Generation Networks (TISPAN-NGN). but within the scope of 3GPP Rel-7 are requirements and need for media protection in IMS. The deployment of a NAT traversal between the UE and the P-CSCF causes problems to apply the adequate security by using the current IPSec solution. WLAN Interworking. for example access networks that include NATs. The end-user shall be able to access the services located at the home IM-domain wherever the end-user may roam to. NGN architectural requirements Any SIP and SDP (or other SIP message body) specification necessary to cope with NGN specific architecture aspects.g. there are still important use scenarios in which the current solution is difficult or even impossible to use. and how potential extensions are done. for 3GPP operators running IMS.9.

common (re)registration mechanisms).3 Support of SMS over generic 3GPP IP access (SMSIP) UID_32081 Resources: S2. 2. 7.234).204 TS 24. when WLAN coverage is lost). 5.229 Title/Contents WID(s) WID on Support of SMS over IP networks WID on Support of SMS over IP networks – stage 3 Impacted Specifications Organization of subscriber data Technical realization of Short Message Service (SMS) Mobile Application Part (MAP) specification Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP). Mechanisms to handle SMS when there is more than one 3GPP IP connection active with the mobile (e.040 TS 29.g.9.46 Overview of 3GPP Release 7 V0. Updates to stage 3 specifications were also expected. more generally across any form of IP access that is part of the 3GPP system. the impact on SMS message waiting flags and on voice mail services). 3. First TR 23.10 (2010-06) 9. Addressing mechanisms when multiple IP-SMS Gateways are in use. specification of security mechanisms).804 TS 23. and. 4. On delivery of MMS over 3GPP IP Access it was concluded that the OMA specifications cover the requirements for delivery of MMS over IP access and no enhancements to 3GPP Stage 2 or 3 were needed.002 TS 24. Impact on existing SMS services and the HSS (e. When using generic 3GPP IP access.804 studied the architectural aspects and the results were used to generate Stage 2 specifications: • • Utilize IMS-registration.g. Stage 3 There is interest in providing 3GPP Messaging Services across WLAN.C1 References Document SP-060658 CP-060697 TS 23. The work provides support for delivery of SMS and MMS over WLAN and any other 3GPP IP access in a manner which guarantees existing SMS and MMS services are not degraded.C4. Stage 2 Support of SMS over IP networks. If this is not studied.804 conclusion: 3GPP . TR 23. 6. Although some initial work has been documented within annex D of the WLAN interworking stage 2 (TS 23. security needs to be provided between the UE and any IP-SMS gateway. a WLAN/GPRS/UMTS card may be GPRS attached and/or CS attached while also having the WLAN connection active).g. there are many topics that cannot be tackled in isolation including (but not limited) to: 1.g. On Charging it studied whether the SMSC need to know that the message was delivered/sent via WLAN or via GSM/UMTS access. Provision of SMS services over any 3GPP IP access needs authentication (e. Potential synergies between solutions for SMS and IMS messaging (e.341 Support of SMS and MMS over generic 3GPP IP access Support of Short Message Service (SMS) over generic 3GPP Internet Protocol (IP) access. and IMS Immediate Message capabilities for transparently delivering originating and terminating SMS over IP access. Investigation of using SS7 and/or IP protocols to communicate with the SMSC (actually its GMSC/IWMSC) and/or the HSS. Stage 3 New Dedicated Specifications/Reports TR 23. then there is a risk that existing operator services will be degraded by the introduction of "SMS over WLAN".g. Reliable deregistration mechanisms to cope with cases when the 3GPP IP access link is lost suddenly (e.008 TS 23.

Proposes that Interworking aspects between SMS/MMS and IMS based messaging should be further studied.g. when WLAN coverage is lost). Potential synergies between solutions for SMS and IMS messaging.008. Addressing mechanisms when multiple IP-SMS Gateways are in use. also known as Flow Based Charging (FBC). it recommends utilizing IMS-registration and IMS Immediate Message capabilities for transparently delivering originating and terminating SMS over IP access.341.C3. Absent Subscriber.212 TS 29. Assumes that the OMA SIP-based Push work will utilize IMS enablers. the impact on SMS message waiting flags and on voice mail services). To fully exploit and re-use mechanisms that are already standardized.C1 References Document SP-060217 CP-060434 CP-060435 TS 23. In particular. Diameter charging applications Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP).229) include: a) b) c) d) e) f) g) h) i) Impact on existing SMS services and the HSS/HLR (e. it recommends pursuing the SIP/IMS based mechanism for SMS/MMS over IP access.207 TS 23. 3GPP .207 and TS 23.002 TS 23. creating duplicity in service information distribution and in bearer inspection in those architectures willing to implement both features. Relevant 3GPP protocol specifications CT 4 (23. Wireless Local Area Network (WLAN) charging Telecommunication management. Charging Data Record (CDR) parameter description Telecommunication management. Reliable deregistration mechanisms to cope with cases when the 3GPP IP access link is lost suddenly (e.9. a 'WLAN/GERAN/UTRAN' equipment may be GPRS attached and/or CS attached while also having the WLAN connection active). Recommends for MMS to pursue utilizing SIP-based Push for notification (i. Both. More Messages to send) will be supported over any 3GPP IP access. Authentication aspects for providing SMS services over any 3GPP IP access.214 TS 29.228 TS 32.e. Proposes to develop an IMS enabler providing IMS based deferred messaging. Ensure that all SMS service characteristics (e. Charging management. Mechanisms to handle SMS when there is more than one 3GPP IP connection active with the public ID (e.229 Title/Contents WID(s) S2 WID on Evolution of policy control and flow based bearer level charging C3 WID on Gx interface for Policy Control and Charging (PCC) C3 WID on Rx reference point for Policy and Charging Control (PCC) Impacted Specifications End-to-end Quality of Service (QoS) concept and architecture Network architecture IP Multimedia Subsystem (IMS).252 TS 32. Charging management.040. Define how all elements in the SMS TP PDU (e. 24.g.S5. whilst continue using HTTP and SMTP for transfer of the MMS itself. Service Based Local Policy (SBLP) and FBC have interest in what bearer carries what services. SIP would be used whenever SMS is used as transport).Stage 2 Telecommunication management.298 TS 32. Both functionalities have generated a number of new reference points and specifications (in SA2 e.g.125. Stage 3 New Dedicated Specifications/Reports TS 23.47 Overview of 3GPP Release 7 V0.251 TS 32. TS 23.g. and the service-based local Policy Control (PC).002) and CT1 (24. Charging management.10 (2010-06) • • • • • Describes the architecture and high-level stage-2 procedure alternatives for SMS and MMS over generic IP access. Impact to communications with the SC (actually its GMSC/IWMSC) and/or the HSS/HLR (linked to UID_14019 Study on Routeing of MT-SMs via the HPLMN).203 TS 29.g. Alert SC. 9. Reply Path etc) are supported over any 3GPP IP access.213 Policy and charging control architecture Policy and charging control over Gx reference point Policy and charging control over Rx reference point Policy and charging control signalling flows and Quality of Service (QoS) parameter mapping 3GPP has developed the architecture for an enhanced bearer charging functionality. Delivery Confirmation. Packet Switched (PS) domain charging Telecommunication management. Charging management. 23.g.299 TS 24.4 Evolution of Policy Control and Charging (PCC) UID_32082 Resources: S2. 29.

208 (End to end Quality of Service (QoS) signalling flows) was not progressed to Rel-7. It incorporates the necessary call flows for the different procedures involved in a PCC architecture. TS 32.250. Support for end-user subscription differentiation and general PC aspects to the policy.10 (2010-06) SA2 have studied the technical aspects of merging these architectures. however a full harmonization must be achieved. matching the SA2 decision. CT3's TS 29. This work created the Stage 2 for an evolved and streamlined architecture allowing to harmonize and merge PC and FBC architectures and functionalities by. TS 29.207 (Policy control over Go interface) was not progressed to Rel-7. TS 29. CT3's new TS 29.203 for PCC architecture is to have a single reference point between PCRF and AF: the Rx reference point. The existing Rel-6 Gx protocol needs to be enhanced to fulfil SBLP and any other new Rel-7 requirements.48 Overview of 3GPP Release 7 V0.299. SA5 Charging aspects of PCC were implemented as CRs in TS 32. The information was transferred to the new TS 29.203 for PCC architecture is to have a single reference point between the PCRF and the PCEF: the Gx reference point.and charging control. Another conclusion is the need to specify the methodology to map QoS and policies between the application and the transport domains used in SBLP. Binding bearers to services. algorithms) to map QoS and policies between the application and transport domains. CT3 produced a new TS 29. which shall be realized by combining Rel-6 Rx and Gq within a single protocol.213 (Policy and charging control signalling flows and Quality of Service (QoS) parameter mapping) with the necessary changes for the PCC architecture. TS 32. CT3's new TS 29.213 contains call flows and methodology associated to the PCC architecture (including Rx and Gx interfaces). Fulfilling the policy and charging control requirements for all different IP access networks.229 (IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP).212 defining the protocol for the Gx reference point on a Stage 3 level. • • • • Complete harmonization and merger of the PC and FBC architecture and procedures. CT1's TS 24. CT3 work on Gx interface for PCC One of the conclusions of the new SA2 TS 23.210 (Charging rule provisioning over Gx interface) was not progressed to Rel-7. that shall be realized combining Go and Rel-6 Gx within a single protocol. matching the SA2 decision. CT3's TS 29. 3GPP . matching the SA2 decision.214 defines the protocol for the evolved Rx reference point on a Stage 3 level. Affected existing specifications were: TS 29.9.298 and TS 32. matching the SA2 decision. Stage 3) was updated via CRs to align with the PCC specifications. matching the SA2 decision.g. NOTE: Rx enables for charging correlation and provides necessary input for PCC rules. Rel-6 Rx and Gq are already very similar.209 (Policy control over Gq interface) was not progressed to Rel-7.251. as well as the necessary methodology (e. as well as a detailed description of the call flows involved in the PCC architecture. CT3 work on Rx reference point for PCC One of the conclusions of the new SA2 TS 23.211 (Rx Interface and Rx/Gx signalling flows) was not progressed to Rel-7.

49

Overview of 3GPP Release 7 V0.9.10 (2010-06)

9.5 Voice call continuity between CS and IMS (incl. I-WLAN) (VCC) UID_32091
Resources: S2,S1,S5,C1,C4 References
Document
SP-060292 CP-070186

Title/Contents WID(s)
S2 WID on Voice call continuity between CS and IMS (incl. I-WLAN) C1 WID on Voice call continuity between CS and IMS (incl. I-WLAN)

Impacted Specifications
TS 22.101 TS 23.228 TS 32.250 TS 32.260 Service aspects; Service principles IP Multimedia Subsystem (IMS); Stage 2 Telecommunication management; Charging management; Circuit Switched (CS) domain charging Telecommunication management; Charging management; IP Multimedia Subsystem (IMS) charging Numbering, addressing and identification (CR#0118)

TS 23.003
TR 23.806 TS 23.206 TS 24.206 TS 24.216

New Dedicated Specifications/Reports
Voice call continuity between Circuit Switched (CS) and IP Multimedia Subsystem (IMS) Study Voice Call Continuity (VCC) between Circuit Switched (CS) and IP Multimedia Subsystem (IMS); Stage 2 Voice call continuity between Circuit Switched (CS) and IP Multimedia Subsystem (IMS); Stage 3 Communication Continuity Management Object (MO)

TS 23.234 (3GPP system to Wireless Local Area Network (WLAN) interworking: System description) provides the possibility to offer VoIP over WLAN interworking with home IMS. The converged IMS architecture offers the possibility to support the most prevalent GSM service, voice calls, over WLAN when there is coverage. A seamless voice call between CS Domain and the WLAN could provide relief to the GSM/UMTS radio resources and increase service revenue. In addition, wireline operators with VoIP offerings should be able to use the 3GPP IMS architecture to offer converged services. Seamless session continuity between WLAN and 3GPP access assumes the continuation of a WLAN IP service as a 3GPP IP service (i.e. via the PS domain). This current assumption is not realistic for real-time voice services; in particular those with GSM radio coverage. This work studied the necessary enhancements to 3GPP systems so that real-time voice call can be offered seamlessly between the CS Domain and the WLAN interworking with IMS architecture. This work defined real-time Voice Call Continuity (VCC) when moving between the GSM/UMTS CS Domain and WLAN interworking with home IMS functionality. It studied the framework in which the continuity takes place, e.g. the following aspects: • • • • Ability for the UE to detect and automatically select the appropriate Access Network (such as GSM/UMTS radio or IP Connectivity Access Network) based on operator policy for real-time voice service. Mechanism for selecting how to route the terminating voice calls to the UE: either through the GSM/UMTS CS Domain or through the WLAN interworking networks with IMS based on the user registration. Criteria for the routing decision as well as the routing mechanism itself should be covered. VCC when the user is moving between GSM/UMTS CS Domain and WLAN interworking with home IMS. Support of calls to/from roaming subscribers accessing service from I-WLANs connected over the public internet.

Whilst the objectives above assume WLAN as the underlying access for IMS, the solution developed for CS-IMS Voice Call Continuity shall be independent of the use of the underlying IP Connectivity Access Network. E.g. the solution shall be applicable to IMS over GPRS or fixed broadband access. TR 23.806 conclusion A number of alternative architectural solutions that enable VCC between CS and IMS domains have been proposed. Based on analysis, some options have been removed or placed in annexes (thereby ensuring that work is not lost). Because of the fact that the almost all of the current deployed CS networks do not support CAMEL 4, the CAMEL 4 based-solution has not been further investigated. Two alternatives remained: Original Domain Controlled (clause 6.4) and IMS Controlled Static Anchoring (clause 6.3).

3GPP

50

Overview of 3GPP Release 7 V0.9.10 (2010-06)

Work has been undertaken to identify any common aspects of the two alternatives. It was determined that the VCC solution impacts Registration, Origination, Termination, Network Domain Selection as well as mid-call supplementary services. When these areas were deemed common or only had minor differences, they were placed in common sections (clauses 6.2 and 6.2a) retaining some solution-specific details where necessary. Finally, the study has shown that both the Original Domain Controlled and IMS Controlled Static Anchoring solutions have their advantages and disadvantages. However, to facilitate interoperability it is believed that the interests of the industry would be best served by pursuing a single solution. It is further believed that on balance the comparative advantages of the IMS Controlled Static Anchoring model make it the preferred way forward. TR 23.806 therefore concludes that further effort on VCC should focus on a solution based on the IMS Controlled Static Anchoring approach, as the basis for standardization. The requirements for VCC were introduced as CRs in SA1 TS 22.101. The new SA2 TS 23.206 specifies the functional architecture and information flows of the Voice Call Continuity feature which provides the capability to transfer the path of an existing voice call between a 3GPP CS system (GSM/UMTS) and IMS, and vice versa. The security in each domain is covered by existing security specifications in those domains. In other words, CS security aspects are covered by existing CS security specifications, I-WLAN security aspects by existing I-WLAN security specifications and IMS security aspects by existing IMS security specifications. The VCC across these domains shall not compromise the security mechanisms of the individual domains. The billing/charging impacts were assessed by SA5, e.g. the ability to generate the appropriate accounting parameters as subscribers move between WLAN networks and GSM/UMTS networks. The capability to separately charge for sessions in each access network needs to be provided. SA5 Charging aspects of VCC (VCC-CH covered by SA2 WID SP-060292) were introduced by CRs in: • • TS 32.250 TS 32.260 update the CS Charging functionality to integrate the charging requirements; update the IMS Charging functionality to integrate the charging requirements;

CT has covered the Stage 3 for VCC. CT4 added Voice Call Continuity Identification and Addressing via CR#0118 to TS 23.003. CT1 has produced two new specifications: • • TS 24.206 TS 24.216 Voice call continuity between Circuit Switched (CS) and IP Multimedia Subsystem (IMS); Stage 3 Communication Continuity Management Object (MO)

3GPP

51

Overview of 3GPP Release 7 V0.9.10 (2010-06)

9.6 One Tunnel solution for Optimisation of Packet Data Traffic (OPTUNEL) UID_7046
Resources: S2 References
Document WID(s)
SP-060819 TS 23.060 TR 23.919 WID on One Tunnel solution for Optimisation of Packet Data Traffic

Title/Contents Impacted Specifications
General Packet Radio Service (GPRS); Service description; Stage 2

New Dedicated Specifications/Reports
Direct tunnel deployment guideline

The amount of user plane data is assumed to increase significantly during the next few years because of the introduction of HSPA and IMS. Discussions in 3GPP have shown that more scalable UMTS system architecture can be achieved by using direct tunnelling of user plane data between the RNC and the GGSN, which is known as "One Tunnel approach". The One Tunnel approach offers a solution that optimizes Rel-6 PS core architecture without impacts to UE and can be deployed independently of the LTE/SAE architecture. TR 23.919 further develops the One Tunnel approach described in Rel-4 TR 23.873 and identifies what changes are needed to PS core and potentially to UTRAN functionalities and protocols to support the One Tunnel functionality. TR 23.919 includes investigation of functions added after Rel-4 up to Rel-6 (e.g. Iu-flex, Network sharing, MBMS, etc.) and either certifies that they are not affected or addresses any conflicts between these functions and the One Tunnel function. TR 23.919 also investigates if the RAN/RNC is impacted or not by the One Tunnel functionality. This includes e.g. Iurelease due to Iu inactivity, 2G/3G mobility, Inter-RAT PS Handover, and other Inter-SGSN and Inter-RAT procedures. The consequences of mixing the Iu and Gn/Gp interfaces in one interface were investigated, with respect to IP privacy and security, L2 technologies, etc. Rel-4 TR 23.873 proposed a solution minimizing the impact on the network resulting in a number of traffic cases that are not supported. This work balanced the impact on the network and supported traffic cases, and alternative solutions for e.g. the roaming case. TR 23.919 finds that the overall gains in system scalability are not diminished by the increased signalling load and system complexity (for instance the impact of SRNS relocation on GGSN). Lawful Interception done in SGSN may not be possible with the One Tunnel function. In case Lawful Interception in SGSN is required, alternatives have to be investigated. TR 23.919 outlines that the resulting system architecture is fully interoperable with pre-Rel-7 nodes and retains existing network capabilities, or documents those that cannot be delivered. Other alternatives of how to separate the control and user plane are outside the scope of this work. Volume-based charging information generated in SGSN may not be possible with the One Tunnel function. In case volume based charging on SGSN is required, alternatives have to be investigated. Necessary specification changes identified during this work were introduced by means of CRs into TS 23.060.

9.7 CSI Terminating Session handling (CSItermS) UID_320029
Resources: S2,C1

3GPP

IMS) and different UE capabilities (CSI. Scenario 3: adding IMS session to existing voice call of IMS origination and CSI termination.. a pure IMS voice/video session and a combination of a CS call and an IMS session.g.g.279 specifies how to handle terminating real-time sessions and calls taking into account different domains (CS.279 provided the relevant stage 3: introducing the CSI AS and the B2B UA as well as making procedural changes to realize functionalities of session combining and session split. Stage 3 New Dedicated Specifications/Reports Combining Circuit Switched (CS) and IP Multimedia Subsystem (IMS) services.52 Overview of 3GPP Release 7 V0. SA2. the case the CSI capable UE is not IMS registered had been also specified.10 (2010-06) References Document SP-060437 CP-070239 TS 24. With Stage 2 in place. Scenario 4: adding voice call to existing IMS session.. TS 23. architecturally. 3GPP . What has not been addressed.279 TS 23. Scenario 2: Multimedia session of IMS origination and CSI termination. is the interworking between e. Call delivery scenarios for e.279 additionally changes cover session modification requests. the session split and session combining for IMS originated sessions leading to CSI session termination.g. CT1 TS 24.279 is covering the CSI AS. etc. however. a pure IMS voice/video session and a combination of a CS call and an IMS session.9. SA2 TS 23. introduced a CSI Application Server in the IMS core of the CSI termination and the following interworking scenarios had been specified: • • • • • Scenario 1: voice call of IMS origination and CSI termination. IMS VoIP.279 Title/Contents WID(s) S2 WID on CSI Terminating Session handling C1 WID on Stage 3 CSI Terminating Session handling Impacted Specifications Combining Circuit Switched (CS) and IP Multimedia Subsystem (IMS) services. TS 23. Stage 2 3GPP has specified how to combine CS call and IMS Sessions but has not yet addressed the interworking between e. 3GPP stage 3 properly covers the combining of a CS call and IMS sessions from the perspective of both parties being CSI capable UEs.).

3GPP services might utilize the authentication model defined by LAP. There may also be other 3GPP security methods that could be used to authentication towards the Liberty IdP. that trusts this authentication confirmation of the IdP. Investigated possible architectural scenarios for 3GPP security – Liberty interworking. it is therefore required to study the 3GPP security . TR 33. 3GPP . The Liberty Alliance Project (LAP) defines in the ID-FF and ID-WSF specifications a family of protocols. Identified suitable format. but the interworking between them should be made possible and optimized. The 3GPP security specifications (e. standards and forums to incorporate the interworking optimization suggestions. Another area of interworking is the use of an authentication done at a Liberty IdP to a 3GPP service or applications. Those protocols enable reuse of an authentication done at an Identity Provider (IdP) for user authentication towards a Service Provider. The enabling of optimal interworking of technologies might require work that lies outside the current GAA area and therefore interworking should be studied in a separate work item outlined by this WID. and hence leverage the access of 3G subscribers to Liberty-enabled services. hence their deployment should be kept independent of each other. to enable easy integration with the existing infrastructure and legacy authentication mechanism (e. Investigated the need and define. New developments in related organisations that affect the interworking need to be studied in further detail. TR 33. GAA.Liberty interworking.9. In order to enable the use of 3GPP authentication methods within the Liberty framework. IMS) and the Liberty Alliance specifications (i.980 studied how an interworking between 3G security methods and the Liberty Alliance framework could be realized. Studied possible optimization of the 3GPP security and LAP interworking and proposed enhancements to the relevant specifications. Identity Web Services Framework (ID-WSF) and Generic Authentication Architecture (GAA) The Generic Authentication Architecture (GAA) system provides mobile subscriber and an application with a shared secret or provides a certificate to the subscriber.g. the result of this study: • • • • • • Investigated relevant standards and technologies. which is specific to mobile subscribers. Identified clearly areas of interworking. is one of the methods that can be used to provide the authentication towards the Liberty IdP. The Liberty Alliance specifications use the provided authentication to the IdP means without restricting the type of authentication mechanism. LAP does not specify the actual means of authentication. The interworking of 3GPP authentication technologies and Liberty has been discussed in SA3 and some areas for optimization and enhancement for interworking were outlined.1 Liberty Alliance and 3GPP Security Interworking (LibSec) UID_33022 Resources: S3 References Document SP-050145 TR 33.g. GAA. guidelines on the usage of 3GPP security and Liberty Alliance protocols for 3GPP services and applications. but leaves that for agreement between the business partners. if applicable.10 (2010-06) 10 SA3 Features 10.980.53 Overview of 3GPP Release 7 V0. username / password). and suggests optimizing the interworking between LAP and GAA.980 Title/Contents WID(s) WID on Liberty Alliance and 3GPP Security Interworking Impacted Specifications - New Dedicated Specifications/Reports Liberty Alliance and 3GPP security interworking. Interworking of Liberty Alliance Identity Federation Framework (ID-FF). but details of this interworking are not fully studied and specified. ID-FF and ID-WSF) have been drafted with different goals.e. both existing as well as the ones that are work-in-progress.

Document 3: Implementors’ test data 3GPP . This study evaluates the trust requirements and develops additional trust requirements for the usage models described in 3GPP. 2) Reliable – the Open Platform is readily available for transactions and communications.216 TS 35. Consequently.905 WID on Trust Requirements for Open Platforms in 3GPP Title/Contents Impacted Specifications - New Dedicated Specifications/Reports Recommendations for Trusted Open Platforms An Open Platform is a computing platform with an architecture allowing users to upgrade their hardware and/or update the software running on that platform. Therefore.9. the result of this study: • • • Investigates relevant trust standards and technologies. Protecting the interface between the Open Platform and the UICC is also of critical importance.215 TS 35. it is very much desirable that the Open Platform must have secure authentication and authorization mechanisms to protect against eavesdropping. both existing as well as the ones that are work-in-progress. processing and input/output of sensitive data on an Open Platform is of critical importance. Security architecture New Dedicated Specifications/Reports Specification of the 3GPP Confidentiality and Integrity Algorithms UEA2 & UIA2. Achieves the following characteristics for the Open Platform in 3GPP environment: 1) Trusted – the Open Platform acts in a recognized manner and in able to communicate what that manner is supposed to be. Develops the Open Platform trust requirements for delivery of new applications and services to open platforms. as well as prepared to act against viruses and other intrusions (intrusion prevention and detection). Such new applications and services include the 3GPP-WLAN Interworking usage models described in TS 33.54 Overview of 3GPP Release 7 V0. TR 33. isolation of some applications (e. appropriate trust requirements need to be specified to counteract the threats. Also. for the diverse 3GPP usage models of the Open Platform.2 Trust Requirements for Open Platforms in 3GPP (TrustOP) UID_33023 Resources: S3 References Document WID(s) SP-040863 TR 33. Document 2: SNOW 3G specification Specification of the 3GPP Confidentiality and Integrity Algorithms UEA2 & UIA2. Document 1: UEA2 and UIA2 specifications Specification of the 3GPP Confidentiality and Integrity Algorithms UEA2 & UIA2. such as the ones described in TS 33. This open architecture makes the platform vulnerable to an increasinglysophisticated number of hardware and software attacks on the platform. Securing the storage.905. 3) Protected – the Open Platform is shares information with only those that need to know within commonly accepted parameters for computer privacy.10 (2010-06) 10. and protocols from Trojans that can attack such applications and spoof sensitive identities is imperative. 10.102 TS 35.234.3 Development of UEA2 and UIA2 (AlgUEA2) UID_33024 Resources: S3 References Document SP-040864 TS 33. and malicious modification of user data and operator applications residing on the Open Platform. applications that are managing (U)SIM and (U)SIM reader).g.217 WID on Development of UEA2 and UIA2 Title/Contents WID(s) Impacted Specifications 3G security.234.

In TS 33. There are no current indications that the existing UMTS cipher and integrity protection algorithms (based on KASUMI) are in danger of being broken but cryptanalysis advances all the time.10 (2010-06) Specification of the 3GPP Confidentiality and Integrity Algorithms UEA2 & UIA2. This work provides lawful interception for the latest Rel-7 architecture.9. so that an attack on one algorithm is very unlikely to translate into an attack on the other. Handover interface for Lawful Interception (LI) New Dedicated Specifications/Reports - The 3GPP Rel-7 architecture continues to develop IP-based Services. TS 33. Subscriber Certificates and I-WLAN for possible LI systems. Handover Interface HI1 (Administration) is not covered as being considered a matter of national regulation.108 addressed HI2 (Intercepted Related Information) and HI3 (Content) interfaces for Packet Data and advanced IMS delivery to the Law Enforcement Monitoring Facilities for 3G networks for Rel-7. The overall objectives were: • • To develop new algorithms for confidentiality and integrity protection for UTRAN to be in place in mobile terminals should the existing KASUMI-based algorithms be broken in the future. Lawful interception architecture and functions 3G security. Liaise with GSMA for the commission from ETSI SAGE to develop the new algorithms.107 TS 33. The 3G Packet Domain and phase 2 Multimedia Domain have been addressed in these specifications for Rel-6.107 and TS 33.218 TR 35. Document 5: Design and evaluation report The need for backup algorithms for UTRAN access confidentiality and integrity protection (UEA2. To enable operators to quickly and easily re-establish a high level of security by switching their networks to use the new algorithms. so that if KASUMI is ever broken.106. 3GPP . SA3-LI studied advanced IMS services. The enhancements to specifications TS 33. the alternative is ready to use. The algorithms were provided by ETSI SAGE. Of course. Agree requirement specification with ETSI SAGE for development of new algorithms. The following issues were addressed: • • • • Confirm GSMA policy and budget allocation to develop new algorithm.55 TS 35.106 TS 33. Document 4: Design conformance test data Specification of the 3GPP Confidentiality and Integrity Algorithms UEA2 & UIA2.919 Overview of 3GPP Release 7 V0. It seems sensible to have a second pair of algorithms developed and deployed in handsets.4 Lawful Interception in the 3GPP Rel-7 architecture (LI-7A) UID_33026 Resources: S3 References Document WID(s) SP-050237 TS 33. UIA2) was identified. the new algorithms needed to be fundamentally different from KASUMI. Multimedia Broadcast and Multicast Services (MBMS). 10. which need to be addressed by LI. Delivery of algorithm specification..107 I-WLAN first step has been addressed for Rel-6.108 WID on Lawful Interception in the 3GPP Rel-7 architecture Title/Contents Impacted Specifications Lawful interception requirements 3G security. test data and design and evaluation reports.

Authorisation (e. the definition of a key establishment mechanism is out of ETSI SCP's scope. 7 (SS7) security gateway. Zh and Zn Interfaces based on the Diameter protocol. tamper resistant device. Generic bootstrapping architecture Generic Authentication Architecture (GAA).220 TS 29.110 defines how to provision a shared key between a UICC and a terminal that may host the UICC or be connected to the device hosting the UICC via a local interface. The smart card is rarely a stand-alone device. 10. Protocol details Generic Authentication Architecture (GAA).C4 References Document SP-050573 SP-050576 SP 060429 SP-050579 CP-060170 TS 33. Stage 3 Mobile Application Part (MAP) specification New Dedicated Specifications/Reports Generic Authentication Architecture (GAA).109 TS 33.918 TR 33. SS7 security Gateway (NDS/TCAPsec) C4 WID on TCAPsec Gateway Function Impacted Specifications Generic Authentication Architecture (GAA). ETSI SCP specifies a secure channel protocol under WI "Secure channel between a UICC and an end-point terminal".002 TR 33. However. Architecture.204 Title/Contents WID(s) S3 WID on HTTPS connection between a UICC and a NAF S3 WID on 2G GBA: 2G SIM usage in 3GPP GAA framework S3 WID on Generic Authentication Architecture usage extensions and optimisations S3 WID on Network Domain Security. Access to network application functions using Hypertext Transfer Protocol over Transport Layer Security (HTTPS) Bootstrapping interface (Ub) and network application function interface (Ua). Network Domain Security (NDS). Therefore. functional description and protocol details 3GPP . Establishment of a shared key between a UICC and a terminal allows operators to provide a wide range of sensitive applications requiring a secure local interface to protect the data exchanged between the UICC and the terminal.5 Key establishment between a UICC and a terminal (KeyEstUTerm) UID_33028 Resources: S3 References Document SP-050780 TS 33.110 Title/Contents WID(s) WID on Key establishment between a UICC and a terminal Impacted Specifications - New Dedicated Specifications/Reports Key establishment between a UICC and a terminal The smart card. determining which terminal can securely connect to which UICC) and user involvement (MMI) are also covered.920 TS 33.56 Overview of 3GPP Release 7 V0.C1. Early implementation feature 3G Security. the need to establish a secure channel between a UICC and a terminal that may host the UICC or be connected to the device hosting the UICC via a local interface has been identified by different standardization groups in order to protect the communication between the UICC and the terminal. Sensitive applications are often split between a smart card and a terminal with sensitive data exchanged between the two.204 TS 29.222 TS 24.g. SA3's new TS 33. Transaction Capabilities Application Part (TCAP) user security Signalling System No.109 TS 29.9.6 Security enhancements (SEC7) UID_732030 Resources: S3. it also provides portability of the user credentials. SA3 needs to specify key establishment between a UICC and a terminal so that a complete solution could be used by 3GPP and others.10 (2010-06) 10. has a primary role of storing credentials and performing sensitive cryptographic computations. it usually interacts with a terminal. Early implementation of Hypertext Transfer Protocol over Transport Layer Security (HTTPS) connection between a Universal Integrated Circuit Card (UICC) and a Network Application Function (NAF) SIM card based Generic Bootstrapping Architecture (GBA).

Services that utilize Liberty Alliance protocols. Due to time constraint. secure content management. Subsequently. while still provide easy migration. The support for 2G GBA is completely under MNO control. i. with few adaptations can provide this secure bridge between the UICC and the network. Also. This work defines how the GBA_U internal key (i. The security level of 3G Authentication and Key Agreement is higher than the 2G SIM authentication.e. which may require secure connection with the network. An application residing on a UICC may advantageously use such a mechanism to secure its communication with a Network Application Function (NAF). as long as the protocol in which a SIM card is used is not specified. the UICC offers a tamper resistant platform that may host a wide range of applications.918 studied as a first step the early implementation of Hypertext Transfer Protocol over Transport Layer Security (HTTPS) connection between a Universal Integrated Circuit Card (UICC) and a Network Application Function (NAF). This option leverages the mobile network operators investments into their SIM cards. Please also note that "SIM card level security" is a very vague concept.57 Overview of 3GPP Release 7 V0. since the Liberty Alliance Identity Provider can use GBA credentials for user authentication in Single Sign On or for web services. This work does not require any change to the existing SIM specifications.109. In this way. banking application. HTTPS connection between a UICC-based application and a NAF was added by CRs to SA3 TS 33. Generic Bootstrapping Architecture (GBA) is currently based on 3G USIMs and ISIMs (TS 33.g. TS 33. the availability of 2G GBA will allow building services where authentication is performed and managed in an analogous way as using USIM. this scenario was not fully covered in Rel-6. the support for 2G GBA should be completely under MNO control. because it is more secure. Mobile network operators could try first out the success of services without handing out new cards and after successful service usage migrate seamlessly to UICCs. The network operators issuing GBA_U aware UICCs should have the possibility to maximize the benefit from the GBA_U security features for the different services. there are billions of people with SIMs in their phones and it will take long time to provision UICCs capable of 3G authentication to such a large population. Meanwhile there should be a way to offer services whose authentication is based on GAA also to 2G subscribers. the introduction of 2G GBA-based authentication provides a security and operational enhancement for users that rely on SIM. Ks_int_NAF) should be used by an UICC-based application and a GBA_U capable NAF to establish an HTTPS connection. then it should be ensured that the 3G authentication procedure is chosen. The work on 2G GBA: 2G SIM usage in 3GPP GAA framework is linked to the Rel-6 WI on GAA and Support for subscriber certificates (SEC1-SC).220). it might even speed up the process of handing out UICCs to the subscribers. In addition. This feature allows the operator to provide a wide range of UICC-based applications using HTTPS to secure its communication with the network e. On the other hand. Moreover. if it is possible to choose between 2G and 3G authentication procedures between a particular UE and the BSF. GAA/HTTPS.10 (2010-06) The work on HTTPS connection between a UICC and a NAF is linked to the WI on Generic Authentication Architecture (GAA) and Support for subscriber certificates. This work specifies how 2G SIMs can be used in 3GPP GBA framework securely. Location services that use OMA SUPL.222 and CT1 TS 24. decides the strength of the security of the whole system.222. This option enables network operators to leverage on their GAA investments to broaden the range of GBA-based services. 2G GBA can be of benefit to: • • • Services that are HTTP based and that are secured using HTTPS. the BSF would be configurable either to allow or to disallow 2G GBA.e. It is therefore proposed to investigate different 2G GBA approaches and choose a 2G GBA of highest security quality. However. Therefore.222 describes how the access over HTTP can be secured using TLS in the Generic Authentication Architecture. The initial roll-out phases of services and service success testing would not need to rely on passwords. In fact. TR 33.9. in particular GBA_U as 3G will not be included in 2G GBA. This could lower the threshold for operators to deploy more sophisticated services that usually would require a UICC from the start. any solution adopted for 2G GBA significantly should enhance GSM security to address the known GSM vulnerabilities. The protocol wherein the SIM card is used. 3GPP . However. SA has agreed upon the working assumption that the HTTPS connection between a UICC-based application and a NAF should be an option for TS 33..

The objective of the work was to ease usage and integration of GAA for a broad range of services and applications. This work specifies a TCAP user security solution in a so called SS7 security gateway architecture. Introduction of automatic key management as planned for Rel-5 MAPsec was also studied. 3GPP . The new SA3 TS 33. The solution provides a clear migration path for the introduction of UICC that makes roll-out and transition easy and smooth. Also. TR 33. The new SA3 TS 33. This functionality was added by CRs to SA3 TS 33. CT1 TS 24. 3GPP2). and integrate GAA into their work and applications (e. the 2G GBA feature should be considered as a separate feature then 3G GBA and operators can choose to use this feature or to connect to operators who deploy 2G GBA or not.9. MAP payload protection (encryption and integrity) is an important element to combat this type of fraud which has a much wider applicability than the TCAP handshake solution of 3GPP Rel-6 (which only applies to SMS-MO and SMS-MT traffic). These additional features would optimise and ease the usage of GAA for various kinds of services and extend the possible usage scenarios for GAA. This work item does not cover the extension of the GBA specification to enable usage of SIM cards for GBA. Since 2G GBA is based on SIM security.109 and CT4 TS 29. Also other threats on SS7 networks could appear and a mechanism preventing them needs to be developed. The MAPsec gateway concept and the MAPsec Rel-4 NE-based solution need not coexist.223 Generic Authentication Architecture (GAA).200) can be reused as basis for a TCAP user security solution to allow protection of e. 2G GBA was added by CRs to SA3 TS 33. MAP and CAP messages in an SS7 security gateway architecture. They have specific needs and requirements on GAA. Transaction TCAP user security) contains this functionality. Subsequently. • • • • The security mechanism will be applied by the gateway above the TCAP layer.109. to provide new features and to optimize existing GAA specifications.10 (2010-06) • Services that use OMA common security enablers.220.920 studied as a first step the early implementation feature of SIM card based Generic Bootstrapping Architecture (GBA).SA3 Part Fraudulent SMS traffic creating customer dissatisfaction and leading to financial losses for operators has been encountered by several network operators. The introduction of usage of 2G SIM cards for GBA allows testing of service acceptance by the user without large investments. take up. ways around the handshake or different fraud methods will be developed sooner or later. Explicit verification of SCCP and MAP-payload addresses against MAPsec SPI were studied. OMA. Any new extension under this WID shall not negatively impact the security level of Rel-6 GAA specifications. other standardization organizations start to discuss. The gateway concept will only include two ‘protection profiles’: ‘Integrity only' and ’integrity and confidentiality’.220. During the final phase of the work on the details of the GAA for Rel-6 it became clear that many useful and desired features would timely not be able to be included. but without real MAP payload protection.204 (Network Domain Security. The work on Generic Authentication Architecture usage extensions and optimisations is linked to the Rel-6 WI on GAA and Support for subscriber certificates (SEC1-SC). TISPAN.58 Overview of 3GPP Release 7 V0. The current specification of MAP application layer security (Rel-6 TS 33.g. Generic Bootstrapping Architecture (GBA) Push function was not realized in the Rel-7 time frame and was consequently moved to Rel-8. The target is to apply protection in a way which is agnostic to the application protocol. so that it can protect other protocols in addition to MAP.g. These specific requirements extend the Rel-6 GAA architecture and would add additional features to it. TCAP handshake will prevent most of the currently known SMS fraud scenarios. SS7 TCAP security Gateway .

SGSN. functional description and protocol details). In particular. However. In addition. Rather than protecting only MAP messages at the MAP-Network Entity (HLR. would allow network operators to secure SS7 connections for all MAP messages passing between them.59 Overview of 3GPP Release 7 V0. Furthermore. Extending NDS/AF to support TLS means that a single cross-certification operation between the peering operators would allow any TLS entity in one operator to communicate securely with any TLS entity in the other operator.800. which resulted from the Study on TCAPsec Gateway Concept. The Transport Layer Security (TLS) profile was moved to Rel-8. VLR.10 (2010-06) SS7 TCAP security Gateway . routeing considerations.7 NDS Authentication Framework Extension for Transport Layer Security (NDSAFTLS) UID_330008 Resources: S3 References Document WID(s) SP-060507 TS 33. especially as the number of peering TLS entities increases. The new CT4 TS 29. Architecture.203 recommends using TLS for secure SIP interconnect between IMS networks and non-IMS networks. gsmSCF. GGSN. or some similar PKI.. TS 29. This work specifies in existing TS 33.310 WID on NDS Authentication Framework Extension for TLS Title/Contents Impacted Specifications Network Domain Security (NDS).310 an extension of the NDS Authentication Framework to support TLS. The work on MAPsec Rel-4 within 3GPP. 3GPP . TLS might also be used to secure inter-operator IP-based communications in some situations. automatic key management was not finalized. and protocol details with regard to the SS7 Security Gateway. the process of establishing the communication links between each pair of peering TLS entity could be quite costly. TLS might be used to secure other types of inter-operator communication in the future.204 replaces TR 29. TS 33.CT4 Part An identified security weakness in 2G and 3G systems is the absence of security in SS7 networks. and without this feature. MAPsec is difficult to set up and operate in a large scale. with changes needed in every MAP NE. Material on MAPsec (NE-based solution for Rel-7) was removed from CT4 TS 29. MSC. CAP and possibly others) at an SS7 Security Gateway which is located at the PLMN's border.9... Authentication Framework (AF) New Dedicated Specifications/Reports - The NDS/AF standard defines an inter-operator Public Key Infrastructure (PKI) that can be used to support the establishment of IPsec connections between operators. 10. the Rel-4 MAPsec suffered from low acceptance from vendors and operators.002 (SS7 security gateway.204 covers network architecture. Furthermore.220 specifies that TLS is used on the Zn' interface between a Zn-proxy in a visited network and a Bootstrapping Server Function (BSF) in a home network.) it is envisaged to protect all TCAP user messages (including MAP. EIR. Without the NDS/AF standard. While IPsec might be deployed quite widely for securing interoperator IP-based communications. TS 33. It also means that TLS entities can be easily added and removed without the need for any inter-operator procedures.

234 TS 26. low latency requirements. Covers the most challenging service scenario of PS conversational / Multimedia Telephony Service for IMS (which involves UE based encoding. 3GPP speech/audio specifications include encoder and decoder pair. quality requirements. The vendors are encouraged to surpass the specified minimum performance requirements. The specifications include minimum performance requirements and reference implementations. They also address the codec operation over typical channel conditions. Test cases. and to provide a specification that meets those requirements. description of error concealment techniques. Defines a set of performance metrics and related target figures and explains methods for performance assessment. and application layer transport quality feedback). The reference implementations meet the minimum performance requirements specified. Protocols and codecs New Dedicated Specifications/Reports Video Codec Performance Traditionally.902 on Video Codec Performance (for PS video-capable multimedia services standardized by 3GPP): • • • Gives guidance for preparing high quality implementations of H.902 Title/Contents WID(s) WID on Video Codec Performance Requirements Impacted Specifications Multimedia Messaging Service (MMS). their encodings. Protocols and codecs Packet switched conversational multimedia applications. Default codecs Multimedia Broadcast/Multicast Service (MBMS). Objectives: • Specify decoder operation under typical GERAN/UTRAN channel conditions including: o A reference decoder implementation. This work specifies Video encoder quality metrics. The error concealment techniques at the decoder are also informative.9. o Capability to detect packet losses.264 video codecs for PS multimedia services.g.140 TS 26. o Generate valid bitstreams that under the constraint of average and peak bitrates achieve specified video quality when decoded by above specified decoder. packet losses are not considered. besides. copy from co-located regions in previous frame(s).235 TS 26. and software to enable the running of tests on codecs. error masks. o Ability to perform minimal concealment for video regions in error. i. e.e. (TR 26. In contrast. erasure prone transport. The encoder specifications are informative. • TR 26. The decoders specified are only for error-free bitstreams. MPEG and ITU have specified only encoded bitstream syntax and decoders normatively for audio and video codecs.60 Overview of 3GPP Release 7 V0. Media formats and codes Transparent end-to-end Packet-switched Streaming Service (PSS).902 contains unencoded test sequences.) 3GPP . Specify encoder operation including: o A reference encoder implementation.10 (2010-06) 11 SA4 Features 11.263 and H.346 TR 26. Performance assessment of both encoder and decoder is covered.1 Video Codec Performance Requirements (VICPer) UID_34030 Resources: S4 References Document SP-040836 TS 26. test materials and software tools for the assessment are defined and included. to specify decoder quality requirements under channel errors for 3GPP packet switched services.

61

Overview of 3GPP Release 7 V0.9.10 (2010-06)

Uses pre-processed video sequences (anchor bitstreams). Hence, no reference video codec software are needed to be included in TR 26.902. Textual descriptions of reference codecs and their parameter settings are given as used in the generation of anchors and performance target figures.

TR 26.902 is organized as follows: • • • Service scenarios, including their relationship with 3GPP services are discussed together with the performance measurement metrics used in the document. Test case definition and performance figures define representative test cases and contain a listing, in the form of tables, performance of video codecs for each of the test cases. Supplementary information on figure generation contains pointers to accompanying files containing video sequences, anchor bit streams, and error prone test bit streams. It also describes the mechanisms used to generate the anchor compressed video data, compressed video data exposed to typical error masks, and descriptions on the creation of error masks. Annex A sketches one possible environment that could be used by interested parties as a starting point for defining a process to assess the performances of a particular video codec against the performance figures. Annex B introduces details on the H.263 encoder and decoder configurations. Annex C introduces details of the H.264 encoder and decoder configurations Annex D introduces details on the usage of 3G file format in the present document. Annex E introduces details on the usage of RTPdump format in the present document. Annex F introduces details on the simulator, bearers, and dump files. Annex G introduces the details on the Quality Metric Evaluation. Annex H introduces the details on the Video Test Sequences. Annex I provides information on verification of appropriate use of the tools provided in this document.

• • • • • • • • •

11.2 Dynamic and Interactive Multimedia Scenes (DIMS) UID_34032
Resources: S4 References
Document SP-050195 TS 26.140 TS 26.142 TS 26.234 TS 26.244 TS 26.346 Title/Contents WID(s) WID on Dynamic and interactive multimedia scenes Impacted Specifications Multimedia Messaging Service (MMS); Media formats and codes Dynamic and Interactive Multimedia Scenes Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP) Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs New Dedicated Specifications/Reports -

This work specifies the dynamic and interactive multimedia scenes of PSS, MMS, MBMS services relative to SA4 specifications. There are non-standardized solutions in this area enjoying some adoption into 3G terminals, but the 3G market community would greatly benefit from a standard, open, stable, multi-vendor and interoperable solution. "Scene" is understood as a presentation of multimedia content including a service logic (animation, menu, links, etc.). Existing capability in 3GPP specifications is limited to download and progressive download; full incremental update is not possible, and interactivity is limited. In addition, existing support for compression and binarization is limited. An update of a piece of content within a multimedia presentation is not possible without reloading a complete page, e.g. changing frequently a quote within a stock-exchange service or adding a voting button in an iTV service. DIMS enables content owners to build enhanced user experiences, and existing capabilities in user input and display can be leveraged (but there might be impact on MMI). In fact, the user experience of multimedia on 3G terminals can be enhanced if the selection, control and display of the multimedia scenes are integrated into a single user interface;

3GPP

62

Overview of 3GPP Release 7 V0.9.10 (2010-06)

also, it would be possible to update animated applications and displays incrementally in order to use bandwidth appropriately. DIMS is providing a dynamic rich-media media system, including a media type, its transport, packaging, delivery, and interaction with the local terminal, user, and other local and remote sub-systems. Enhanced end-user experiences are provided by the coordinated management and synchronization of media and events, combined with end-user interaction. DIMS media type can be used as a generic media type, allowing creating dynamic interactive rich-media services and can also benefit, or be used in association with other media type (e.g. audio codec, video codec, xhtml browser, etc.). DIMS media type allows spatial and temporal layout of the multimedia scene. This scene can consist of any combination of still pictures, videos, audio channels and animated graphics. It includes an update mechanism that allows for partial updates of the existing scene, as well as updating the presentation with a completely new scene and stream tune-in functionality. TS 26.142 for multimedia scene management includes: • • • • • • • scene format and scene definition; container and delivery formats including both file and stream forms; compatibility with, integration of, and building upon existing media types and formats in 3GPP specifications, including but not limited to video, audio (including both sampled audio and synthetic audio), images and graphics (SVG Tiny), storage format such as 3GPP file format and stream formats such as RTP; management of user interactivity; incrementally updated scenes and animations; integration with capabilities for secure/encrypted delivery; efficient use of bandwidth of the radio network.

The new functionalities are: • • • • • • • • A method of linking primary and secondary streams ("updates") An additional method of synchronization of media streams ("syncRef") Screen Orientation ("ScreenOrientationPortrait", etc.) Activation and deactivation parts of the tree ("activate"/"deactivate"/"active") Distributed Random Access Points (DRAP) The ability to directly run scripts sent from a server without inserting them into the DOM "doScript" Seeking in a DIMS stream "seek" The timing and processing models have been substantially updated. NOTE: A parallel (not conflicting) action was carried out in OMA, which was finalized at the end of 2006.

There are areas of TS 26.142 still needing input from other groups, both inside and outside 3GPP, and some areas that SA4 needed to tidy up after completing the basic technology specification. They include: a) c) e) f) align softkey locations with OMA RME; to establish a group ID for two-transport RTP, in consultation with IETF; timing model consulting with W3C; possible use of one or more DIMS units in XML files and/or items in a meta directory;

b) security section as a result of SA3 review; d) definition of the initial profiles and levels;

g) security considerations for save/restore.

3GPP

63

Overview of 3GPP Release 7 V0.9.10 (2010-06)

11.3 3G-324M Video Telephony Call Setup Times Improvements (VTCSTI) UID_34034
Resources: S4 References
Document
SP-050404 TR 26.911

Title/Contents WID(s)
WID on 3G-324M Video Telephony Call Setup Times Improvements

Impacted Specifications
Codec(s) for Circuit-Switched (CS) multimedia telephony service; Terminal implementor’s guide

New Dedicated Specifications/Reports
-

Video telephony is very important for the successful adoption of UMTS. 3G-324M, the basis for 3GPP CS multimedia calls, was based on H.324 and has been evolving ever since its first introduction in R99 3GPP specifications. As part of this evolution, new codecs have been proposed and adopted in 3GPP to improve the quality of service. These evolutions have been focusing so far on the media quality and not on other aspects such as call set-up time, which also greatly affects user experience. Using R99, the time taken to set up a 3G-324M call is currently significantly longer than that taken to set up a voice call. This quality of experience is broadly acceptable to early UMTS customers. However, as adoption becomes broader, this tolerance will decrease. In the interest of facilitating broader adoption of UMTS and mobile video telephony, further solutions should be identified to accelerate 3G-324M. This may be accomplished by several methods including optimizing the in-band call control (H.245). This work reduces 3G-324M call set-up time to the equivalent of a voice call. Since methods to achieve this goal have already been proposed and adopted in other standards bodies, SA4 decided to reuse as much as is relevant of the existing solutions. Therefore SA4 suggested a phased approach to this work. First SA4 liaised to SA1 to get requirements for this work and liaised also with GERAN (depending on the output on the Feasibility Study on Enhanced Support of Video Telephony). Then SA4 decided to consider the work of ITU-T SG16 WP2 Q.1 that developed a H.324M call setup acceleration solution at the April 2006 meetings in Geneva. The solution is a combination of three different proposals, previously known as FastMedia, Fast Session Setup, and Accelerated Call negotiation. SA4 accepted the Annex K/H.324 approved at a special WP2/16 Plenary meeting held on 13 June 2006. TR 26.911 (Codec(s) for Circuit-Switched (CS) multimedia telephony service; Terminal implementor’s guide) was then revised by means of two Change Requests, introducing respectively: • • WNSRP (Windowed Numbered Simple Retransmission Protocol), which was recommended to be used during establishment of 3G-324M multimedia calls if it is present in the calling party terminal. If the dialling party does not support WNSRP, NSRP or SRP shall be used. MONA (Media Oriented Negotiation Acceleration), which was recommended to be used during establishment of 3G-324M multimedia calls if it is present in the calling party terminal.

11.4 Optimizations for Multimedia Telephony over IMS (OMTIMS) UID_34035
Resources: S4 References
Document
SP-060226 TS 26.235

Title/Contents WID(s)
WID on Optimizations for Multimedia Telephony over IMS

Impacted Specifications
Packet switched conversational multimedia applications; Default codecs

3GPP

where voice is required to meet or exceed the performance of CS in terms of voice distortion. therefore. However. For multimedia telephony over IMS however there is a much larger degree of freedom in how to implement the service. like • • • Multimedia Telephony capabilities for IMS (MITE). The work in SA1. packet loss targets are taken from subjective tests of the reference PLC algorithm. Currently it is assumed. It should be noted that PLC algorithms can directly reduce packet loss effects by using packets that arrive beyond their jitter protection. If network capacity were planned with the assumption that there can be no packet loss.9. as is currently done for PLC. this work aimed in a phased approach to: • • • identify explore evaluate the optimisation opportunities under consideration of the above-mentioned work in the other groups in parallel with their development. it was felt appropriate for SA4 to quantify the amount of jitter the decoder can accommodate while maintaining voice quality at target levels. jitter. However. Again by analogy. packets that have already been replaced by concealment algorithms can be 3GPP . can only increase. Transport protocols New Dedicated Specifications/Reports - A number of existing specifications related to Multimedia telephony over IMS were originally created in SA4 for CS conversational services for which they are concise. this is similar to the ability of decoders to perform Packet Loss Concealment (PLC). the current assumption that jitter is converted to an equivalent amount of delay is also unnecessarily limiting capacity. Some work has been done on the Building Block “Characterisation of Adaptive Jitter Management Performance for VoIP Services. The same is planned for adaptive jitter management. packet loss concealment. Similarly. As users are added to the system. that jitter will be converted directly to delay. as well as an example adaptive jitter management algorithm (one "static and one "dynamic" example).10 (2010-06) Packet switched conversational multimedia applications. in order to allow a co-ordinated effort and even possibly to include further promising opportunities. Therefore. examples of a class of Jitter Management algorithms that use well-known signal processing techniques may mitigate jitter without increasing the end-to-end delay. media handling in video-conferencing or echo-cancellation have already been pointed out. While PLC produces speech that has less quality than a perfect channel would produce. Such algorithms will be limited by their effect on voice quality. but can remove the subjective effect of the delay. A major factor limiting HSDPA/EUL performance is the amount of packet jitter passed to the decoder or transcoder. jitter increases until the delay or packet loss exceeds the acceptable target levels. It will be possible for different manufacturers to create their own version of the jitter buffer algorithm. Current work aimed to define and optimize end-to-end VoIMS for HSDPA/EUL. This led to improved service quality and efficiency. (OMTIMS-CAJMP)”. implying that the direct adoption of the existing specifications is neither necessarily optimal nor unambiguous. Improved Support of IMS Realtime Services using HSDPA/HSUPA. in other words. then capacity would be quite low. and facilitated the optimisation of existing work items. if adaptive jitter management is not used. Study Item on IMS enhancements and optimisations for real time communication. By analogy. and capacity. the effects on the user are such that a modest level of loss will have minimal impact on quality. These algorithms provide also a tool for adaptive jitter management when evaluating endto-end VoIMS performance. the referenced IETF transport protocols are defined service agnostic. The example algorithms provide information on acceptable jitter range in the network. A couple of optimisation opportunities such as transport protocol optimisations.236 - Overview of 3GPP Release 7 V0. which was then stopped and the output transferred to the WIs "MTSI-MHI" and "End-to-end performance characterisation of VoIMS for HSDPA/EUL". SA2 and RAN2 had further implications on SA4 specifications related to Multimedia telephony over IMS and it was felt appropriate to make the required specification updates in a co-ordinated effort. However. which consequently also leaves room for optimisations considering the architectural constraints of IMS. PLC tests are well-known and a reference implementation is given for every codec. Moreover. The aim was to quantify the effects of jitter on voice quality at the terminal and core network. and allows for relatively large increases in capacity. (IMS-RT).64 TS 26. providing an example methodology for assessing the subjective quality of any given algorithm. delay and capacity.

10 (2010-06) resynchronized into the decoder if they arrive late. customers could enjoy the satisfying multimedia services as they required. and this can greatly mitigate the effects of packet loss. service providers and device providers with a universal method and some systematic metrics to characterize the end-to-end performance of multimedia services like PSS. Without standardized metrics. and quality beyond CS performance. further increasing capacity. This work focused on the end-to-end performance characterization and metrics for multimedia services. they lack the necessary metrics to determine whether the multimedia services running on these equipments can meet the requirements of consumers. they don’t know how to evaluate the equipments of the various providers without standardized metrics and methods. This has the following consequences for: a) Operators: When deploying a 3G network to provide multimedia services. All these promote the multimedia services deployment. IMS. It covers "Multimedia service performance evaluation methods" by using Subjective and Objective methods.65 Overview of 3GPP Release 7 V0. it is difficult to convince the operators. Multimedia services are very important services in 3G networks. MMS. 11.114. See performance requirements in TS 26. With a standard about end-to-end multimedia services performance evaluation metrics. c) Consumers: They can’t be provided with clear quality requirements when subscribing multimedia services from operators. MBMS.944 Title/Contents WID(s) WID on End-to-End Multimedia Services Performance Metrics Impacted Specifications - New Dedicated Specifications/Reports End-2-End Multimedia Services Performance Metrics This work provides operators. there is no standard on how to characterize the performance of such services. b) Device providers: They have to provide a set of performance data to operators in order to prove that their products can support multimedia services very well. both operators and providers know how to do when deploying a multimedia service.5 End-to-End Multimedia Services Performance Metrics (E2EMSPM) UID_34036 Resources: S4 References Document SP-050433 TR 26. However. It avoids deploying multimedia services without satisfying effects or waste of network resources. At the same time. Besides. An example of systematic service performance metrics framework is given in the following table: 3GPP . PSC.9.

pDVD. and operational methods are provided for the operators/service providers to guarantee service performance.g. Colourfulness…… Terminal Capabilities CPU. average frame rate. Mean time between corruption. and then provides the End-to-end Service QoS (ESQoS) and System QoS (SQoS) parameters and mapping between these performance metrics for different layers. transaction node) and are identified for the different layers (e. which starts with the quality of experience (QoE) parameters. analog TV-like quality. Corruption duration. Re-buffering duration.10 (2010-06) End-to-End Multimedia Service Metrics Methods User Service Performance Indicators Setup delay. including PackedSwitched Streaming (PSS) service. The ESQoS parameters describe the QoS of the end-to-end service. TR 26. They are obtained directly from the QoE parameters by mapping them into parameters more relevant to operators and service providers. The inherent relationship between the ESQoS and SQoS parameters of PSS is described.944 contains an annex (Annex A) on PSS performance analysis with theoretical models. ESQoS and SQoS parameters for each of the relevant services. Blocky level. Decoder…… Access Access ratio…… Transport Layer Underlying networks aspects Transfer Delay. digital TV-like quality. Lip sync. quality variation over time…… Intra-frame (Spatial) PSNR. A comparison with TS 102 250 of ETSI STQ is contained in Annex C of TR 26.944. Memory. Blurriness. DSL-like video conferencing quality. TR 26. Audio quality. BLER…… …… …… TR 26. wireline transport network.944 describes and defines performance metrics for use in multimedia services in 3G networks. ISDN-like video conferencing quality. Dropped Frames. Multimedia Broadcast Multicast Service (MBMS). Initial buffering duration. that was developed taking into account also ITU-T work in the area of QoE and QoS.944 defines the QoE. transport). wireless transport network. Audio/video sync …… QoS Subjective & Objective Codec.). They are defined separately for each system part (client. End-to-end delay.944 has a top-down approach. Edge noise. The SQoS parameters are the inherent attributes of the networks and are important in guaranteeing that the QoE requirements of the users are met. Content quality (e. The QoE parameters reflect the end-to-end quality as experienced by the end user.g.9. Theoretical models are introduced to study the ESQoS and SQoS parameters. TR 26. Video quality. system an transport aspects Codec Inter-frame (Temporal) Freeze Frames. Video Telephony (VT). 3GPP . and IP Multimedia Subsystem (IMS) service. These metrics can be reported by the end users. Jitter. etc. application.66 Overview of 3GPP Release 7 V0. Service availability (Initial availability and Dropped stream ratio) …… QoE Initial connection duration. radio access network. The SQoS parameters reflect the point-to-point QoS in system parts within networks.

server file extensions (FLUTE). 3GPP . 3GPP file format (3GP) New Dedicated Specifications/Reports - 3GPP RAN has developed high capacity HSPA bearers which allow for higher video frame rates and sizes.g. Content switch time QoE metric: A new QoE (Quality of Experience) metric for reporting content switching time was added. It is well known that user experience is strongly influenced by the switching time between channels (“channel surfing”) and the ability to provide feedback (interactivity such as voting. Fast content switching was introduced in Rel-7 and a metric for measuring the content switching time was hence needed. Improvements in this area will make PSS even more valuable. In order for 3GP files to support new features of these services as well as other improvements. e.67 Overview of 3GPP Release 7 V0. e.g.10 (2010-06) 11. e. some improvements were felt necessary. Content switching time has significant impact on the quality of experience for the user. IMS and MBMS.).9. The 3GPP file format (3GP) is defined in PSS. Informative annex was added to give examples. The rest of the CRs (category C) concerned: Fast content switching and start-up: Procedures were defined to allow faster start-up and switching of content by reducing the client/server interactions to a minimum. on updates in levels of recommended video codecs.234 TS 26. Clients will reuse the existing RTSP control session and RTP resources while switching to new content. carriage of the new DIMS (Dynamic and Interactive Multimedia Scenes) media type. The QoE metric negotiation protocols were updated accordingly.234 (PSS. (This results into significantly faster start-up and channel switching than in Rel-6. although it is used by many services.6 Packet Switched Streaming Enhancements (PSSe) UID_34039 Resources: S4 References Document SP-060361 TS 26. Align media codec configurations to available bearer rates.244 - Title/Contents WID(s) WID on Packet Switched Streaming Enhancements (PSSe) Impacted Specifications Transparent end-to-end Packet-switched Streaming Service (PSS). Protocols and codecs Transparent end-to-end packet switched streaming service (PSS). • • • • • Adjustments to allow MBMS transmission using PSS. Further.g. Protocols and codecs) through CRs. (The QoE framework is a tool in PSS used for gathering statistics about the quality of experience of a PSS session. File format enhancements (carriage of DIMS etc).). the Packet-switched Streaming Service (PSS) feature must be enhanced to allow provision of MBMS User Service using PSS where MBMS Bearer Service is not available or desirable. including MMS.) PSSe QoE negotiation modifications: Fast content switching and start-up introduce changes into the negotiation of RTSP session. The CR defined the necessary extensions to RTSP and their use for fast start-up and fast switching. Improve switching time between channels. etc. and media quality than currently defined (the H. channel switching will take less than 3 seconds at best.264 Baseline Profile Level 1b for instance allows only for bitrates up to 128 kbps). This work enhances the existing PSS specifications with new functionality and state of the art configurations of media codec configurations. Improve the interactivity between the client and the server. The work outcome was brought into TS 26.

Core network resources IRP: Bulk CM XML file format definition Configuration Management (CM). Concept and requirements Subscriber and equipment trace. Principles and high level requirements Telecommunication management. Signalling Transport Network (STN) interface NRM IRP: CORBA Solution Set Configuration Management (CM). Basic CM IRP. Administration.741 TS 32. Trace concepts and requirements Subscriber and equipment trace.335 TS 32. Signalling Transport Network (STN) interface NRM IRP: Requirements Configuration Management (CM).635 TS 32. Release 7 Impacted Specifications Telecommunication management.150 TS 32. Requirements Configuration Management (CM). Kernel CM IRP SOAP Solution Set Test management IRP XML definitions 3GPP . Core network resources IRP: Requirements Configuration Management (CM). RAN3 (only for End-to-end tracing for IMS UID_35039) TR 30.102 TS 32. Bulk CM IRP: Information Service Configuration Management (CM).371 TS 32.423 TS 32.642 TS 32.743 TS 32. UTRAN network resources IRP: CORBA Solution Set Configuration Management (CM).111-3 TS 32.615 TS 32.111-2 TS 32. Project scheduling and open issues for SA5.432 TS 32. Core network resources IRP: CORBA Solution Set Configuration Management (CM). Trace control and configuration management Subscriber and equipment trace. Bulk CM IRP: XML file format definition Configuration Management (CM).101 TS 32. C1/3/4.675 TS 32.421 TS 32.422 TS 32. Concept and definitions Configuration Management (CM). SOAP Solution Set Configuration Management (CM).667 TS 32.643 TS 32. UTRAN network resources IRP: NRM Configuration Management (CM). Part 2: Alarm IRP: Information Service Fault Management. Part 3: Alarm IRP: CORBA Solution Set IRP Concept and definitions IRP Information Service (IS) template IRP Information Service UML repertoire Test management IRP: Requirements Notification Log (NL) IRP: XML solution definitions Security Management concept and requirements Performance Management (PM).401 TS 32.742 TS 32.435 TS 32.633 TS 32. Architecture Fault Management.152 TS 32.9.632 TS 32.745 Title/Contents WID(s) Telecommunication management.817 TS 32.325 Backward and Forward Compatibility (BFC).601 TS 32.607 TS 32.436 TS 32.154 TS 32.1 Operations.321 TS 32. Basic CM IRP SOAP Solution Set Configuration Management (CM). Notification IRP SOAP Solution Set Generic IRP management. Project scheduling and open issues for SA5. Signalling Transport Network (STN) interface NRM IRP: Information Service Configuration Management (CM). Core Network Resources IRP: NRM Configuration Management (CM). Signalling Transport Network (STN) interface NRM IRP: Bulk CM XML file format definition New Dedicated Specifications/Reports TS 32.645 TS 32.817 "Telecommunication management.612 TS 32. Trace data definition and management Performance measurement: File format definition Performance measurement: XML file format definition Performance measurement: ASN. Release 7"contains the updated Work Item Descriptions (WIDs) for OAM and Charging management.317 TS 32.631 TS 32. The Feature OAM7 contains three (3) Building Blocks as follows: Network Infrastructure Management Performance Management Trace Management OAM7-NIM OAM7-PM OAM7-Trace References Document TR 30.68 Overview of 3GPP Release 7 V0. State Management IRP: Bulk CM XML file format definition Configuration Management (CM).307 TS 32.151 TS 32. UTRAN network resources IRP: Bulk CM XML file format definition Configuration Management (CM). Maintenance & Provisioning (OAM7) UID_35041 Acronym: Resources: OAM7 S5.1 file format definition Configuration Management (CM).10 (2010-06) 12 SA5 Features 12.

408 TS 32. responsibility and management knowledge between EMSs over a horizontal Peer-to-Peer (P2P) interface.665 TS 32.73x "IMS NRM IRP". Performance measurements IMS Trace Management IRP Requirements Trace Management IRP Information Service (IS) Trace Management IRP CORBA Solution Set Trace Management (Trace) IRP XML file format definition Configuration Management (CM).365 TS 32.UID_35044 The IMS has been adopted as the basis of the NGN. whereas Operations Support Systems (OSSs) are single vendor.10 (2010-06) File Transfer IRP XML definitions Entry Point IRP XML definitions Performance Management (PM) IRP XML definitions Configuration Management. Performance measurements UTRAN Performance Management (PM).725 TS 32. Multiservice Switching Forum (MSF) resulting in a new TS family TS 32.404 TS 32. 2.63x Configuration Management (CM). ITU-T SG4.393 TS 32. It is possible to share information. Performance measurements Core Network CS domain Performance Management (PM).722 TS 32.383 TS 32. Kernel CM IRP XML definitions Security services for IRP Information Service Security services for IRP CORBA Solution Security services for IRP File integrity solution Partial Suspension of Itf-N IRP Requirements Partial Suspension of Itf-N IRP Information Service (IS) Partial Suspension of Itf-N IRP CORBA Solution Set Partial Suspension of Itf-N IRP XML file format definition Delta synchronization IRP Requirements Delta synchronization IRP Information Service (IS) Delta synchronization IRP CORBA Solution Set Delta synchronization IRP XML file format definition Performance Management (PM).372 TS 32.442 TS 32. Traditional architectures allow multi-vendor capabilities to be provided through integration to a vendorindependent Network Management System (NMS).806 TR 32.UID_35046 Networks are often multi-vendor.382 TS 32.441 TS 32.731 TS 32.409 TS 32.392 TS 32. Enhance NRM to accommodate NGN (IMS as basis of the Next Generation Network) .375 TS 32.406 TS 32.391 TS 32.443 TS 32.395 TS 32. the existing 3GPP IRPs).373 TS 32. Core Network Resources Integration Reference Point (IRP) was enhanced to accommodate additional requirements of NGN Release 1 and VoIP coming from other groups (e.733 TS 32.69 TS 32.9. Co-operative Element Management interface (CO-OP) .415 TS 32.385 TS 32. The 3GPP Core Network Resource Model (NRM) in TS 32. Repeater network resources IRP Requirements Configuration Management (CM). responsibility and management knowledge between EMSs over a horizontal P2P interface (by reusing and/or enhancing existing 3GPP IRPs). TMF. Performance measurements Teleservice Performance Management (PM).735 TR 32. Shared responsibility and management knowledge between EMSs addressed are as follows: • • • • Read domain topology data Subscribe to state changes Receive events/alarms Requests functions 3GPP .345 TS 32. Repeater network resources IRP Bulk CM XML file format definition IP Multimedia Subsystem (IMS) Network Resource Model (NRM) IRP Requirements IP Multimedia Subsystem (IMS) Network Resource Model (NRM) IRP Information Service IP Multimedia Subsystem (IMS) Network Resource Model (NRM) IRP CORBA Solution Set IP Multimedia Subsystem (IMS) Network Resource Model (NRM) IRP XML file format definition Application guide for use of Integration Reference Points (IRPs) on peer-to-peer (p2p) interface Itf-N performance criteria: Requirements UTRAN and GERAN Key Performance Indicators (KPI) Network Infrastructure Management (OAM7-NIM) . This is achieved through sharing of information. This enables the NMS (and the human operator) to monitor and configure border aspects between Element Management Systems (EMSs)/IRP Agents (within a vendor’s domain and across vendors' domains). Repeater network resources IRP information Service Configuration Management (CM).445 TS 32.UID_35042 1.721 TS 32. Performance measurements Core Network PS domain Performance Management (PM).405 TS 32.381 TS 32.814 Overview of 3GPP Release 7 V0.Definitions and template Performance Management (PM).723 TS 32. ETSI TISPAN. by means of northbound interfaces (i.811 TR 32. Performance measurements .e.407 TS 32. Repeater network resources IRP CORBA Solution Set Configuration Management (CM).732 TS 32.g.

This puts an unnecessary load on both IRPManager and IRPAgent and can take a long time – even if there was only a short interruption of the connection.UID_35048 If the connection between IRPManager and IRPAgent is lost. especially when designing the internal architecture of the IRP Agent which may influence the performance of Itf-N. reasonable performance criteria are needed. SOAP has been agreed to be the suitable technology for SuM.UID_35049 Standardization of SuM operations significantly enhances the ability of 3GPP based networks to provision and administer complex services in the area of multimedia. the only way for the IRPManager to synchronize again after re-establishment of the connection was to synchronize the complete data.4xy. 3GPP . The performance criteria are considered by vendors when developing their products.811 provides for all IRP specifications produced by 3GPP the overall performance criteria (interface IRP data consistency. 4. Delta synchronization between IRP Manager and IRP Agent . then a higher level KPI definition approach may be used. Subscription Management (SuM) IRP Solution Sets . TR 32. This is also valid for the UMTS network management Itf-N.e. to ensure the all-around quality of the Itf-N. This study has not used a uniform template between the two different KPI methods. Other cases where synchronization is needed are e.814 details two methods of defining KPIs. new/modified/deleted data) from a synchronization point onwards.UID_35047 Performance is a key point to ensure the quality of a product. This can be a huge amount of data. e. however when standardised measurements are not available or not appropriate to use. 5. value added services.: • • • • IRPAgent does not send notifications IRPManager does not evaluate notifications loss of notifications on IRPManager side because of system problems inability to generate notifications on IRPAgent side because of system problems TS 32. Performance criteria reveal the potential risk for UMTS network management Itf-N. These performance criteria are also useful for operators as a guide to evaluate Itf-N products. TR 32. To enable service providers to administer the subscription data defined in the Network Resource Model (NRM) an adequate Interface IRP fulfilling the SuM operations requirements has been specified. 3. even if only very little data actually has changed in the meantime.g. The TR concludes that where standardised measurements are available. It gives examples of Test Environment and Measurement Point. The current SA5 specifications define the function requirements and solution for the UMTS network management Itf-N. both and individually for Configuration Management (CM) and Fault Management (FM) data. The value definition of itf-N performance criteria was out of the scope of this WID. It is necessary to accurately reflect the performance bottle-necks of the Itf-N. However.806 shows how P2P horizontal interfaces can be added to the existing Telecommunication Management (TM) architecture and how existing IRPs can be applied to this architecture. this is something that should be addressed in any future KPI standardisation work. the first definition approach should be used. data services.70 Overview of 3GPP Release 7 V0. Network Management (NM) Itf-N performance criteria .10 (2010-06) • Common Key Performance Indicators (KPIs) TR 32.g. The second method takes a higher level approach that does not require the use of standardised performance measurements. The first method is characterized by using performance measurements defined in TS 32.9. end-to-end applications.39x Delta Synchronization IRP define an interface through which an IRPManager can request only the data which has changed (i. when differing implementation alternatives have led to non uniform counter updates or even different counter definitions between vendors. capacity and reliability).

Integration Reference Point (IRP) Security Management .UID_35050 The 3G Mobile Network is sensitive to fraud and contains very sensitive data which is essential for the correct operation.607 Basic CM IRP SOAP SS 32. Backward and Forward Compatibility of IRP systems .g. the implementations supporting the resultant new release can interoperate with implementations supporting the "older" release.317 Generic IRP Management SOAP SS 32. A 3G Mobile Network exchanges sensitive data between the management system and the mobile network.665 Kernel CM IRP XML definitions 32.101 Telecom management.307 Notification IRP SOAP SS 32. and • Vendors are making products that support Vendor Specific Extension (VSE) that are based on 3GPP IRP specifications.e. In these scenarios it can also be important that no commands via the Itf-N interfere with actions from the local craft interface (e. TS 32.10 (2010-06) As a result: • • • Added new SOAP SS in TS 32. TS 32.UID_35052 In certain scenarios floods of unwanted notifications including alarms is sent to the IRP Manager by network object instances. Given that 3GPP is publishing the Interface. Thereby the interface and the management systems bear unnecessary load. NRM and Data Definition IRP specifications rapidly. 7.38x specify an interface through which an IRP Manager can suspend the forwarding of notifications via ItfN which were generated in parts of the managed systems. Notifications and Files. and • Operators may want to use a managing system that is compliant to vendor-A VSE (that is based on 3GPP IRP specifications) to manage multi-vendor managed systems that may not be supporting vendor-A VSE but are supporting vendor-B VSE (that is based on 3GPP IRP specifications). Responses.667 Kernel CM IRP SOAP SS 6. there is a need for 3GPP to specify rules such that. i. including Requests.9. • 3GPP . not to send notifications of the involved network elements and/or to disallow Itf-N management operations). all IRPManagers (may be from various vendors) and IRPAgents (may be from various vendors as well) must use the same 3GPP specification release at all time. This work builds upon and enhances the Release 6 work on security management to further ensure secure access and data protection throughout the OAM network. Even worse: the operator’s awareness is drawn away from really urgent events. be done in a gradual basis. in a large multi-vendor network. exchanged across the Itf-N. and will continue to do so in the future. Such rules are called Backward Compatibility (BC) rules. multiple versions per release period. Consequently suspending for a period of time Itf-N is beneficial (i. Partial suspension of Itf-N during maintenance/testing . services and functions to protect the network management data.175 SuM NRM IRP XML definition with the SOAP SS used for Interface IRP For existing IRPs new TSs on SuM Interface IRP SOAP SSs were created as follows: 32.71 Overview of 3GPP Release 7 V0. and • Operators are planning to use 3GPP IRP to manage large multi-vendor networks.UID_35064 This sets the rules that IRP authors can use to evolve existing IRP specifications such that implementations of the new IRP specifications can result in systems that are backward compatible to systems that have implemented the existing specification. if and when used by IRP standard authors to develop a new release.e.372/3/5 specify the necessary security features. Principles & high level requirements Aligned TS 32. 8. and • It is inconceivable that. people working close to antennas would like to have complete control when the radiation is switched on). and • It requires less coordination and less service disruption if managing systems and managed systems upgrades in a large network.

" Based on TS 32. Release 7 sets the rules for BC (primary focus) and the requirements and rules for FC (secondary focus).xyz were lacking repeater related NRM specifications needed by the NMS. the operator only needs to grasp the configured value of channel power.331 it is necessary to define XML Schema for the remaining Itf-N Notifications: i.32x). 10. since in the BC case the ‘old’ system behaviour is known whereas a FC system needs to cope gracefully with unknown future features.72x define the Configuration Management (CM). the implementation supporting the resultant release can have a better chance of interoperating with implementations supporting future release.34x).36x). The power can be assigned on transport channel or physical channel. KernelCMIRP (32. it is necessary to measure the dynamic value of channel power. In UTRAN. be capable of holding fault management alarms. BC rules had been studied in Release 6 TR 32.UMTS and combined UMTS/GSM 11. The result of this work resulted in CRs against: • • 32. The standardization of these FC rules is the secondary focus of this work item. Notification XML Schema . FC is harder to achieve than BC. So effective monitoring of the radio channel power is very helpful for operators’ daily OAM&P work and network estimation.61x). Often vendors implement repeater OMC to manage the repeaters and carry the necessary OAM&P functions defined in TMN. A log is capable of capturing all semantics carried in a notification. This resulted in new TSs 32.41x).9. 3GPP . Such rules are called Forward Compatibility (FC) rules. BulkCMIRP (32. Operators require grasping the configured and dynamic value of those channels’ power. High or low power value of each kind of channel has different impact on the network. configuration management events. at any one point in time. Repeater Network Resource Model (NRM) definition . the repeater OMC is a kind of Element Management System (EMS) which should be managed by the Network Management System (NMS) through itf-N. SA5 considered industry best practices for defining systems that are BC and/or FC. Repeater network resources IRP. This work covers the need and solutions for Repeater NRM definition in UMTS. From the TMN view point. NotificationLogIRP (32. performance management events.UID_35071 Repeater is the equipment which can be used in the UTRAN network to improve the network coverage. TS 32.10 (2010-06) There is also a need for 3GPP to specify rules such that when used by IRP standard authors to specify a standard of a release.72 Overview of 3GPP Release 7 V0.331 (Notification Log IRP requirement) states that: "Any Notification Log must.66x).805 under the SA5 Work Task "Backward Compatibility". and event log management events. transport and physical channels. While for the others. Existing 3GPP TS 32. TS 32.335/ 615/ 665.33x). FTIRP (32. EPIRP (32.325/ 345/ 365/ 415 and CRs against TSs 32.UID_35072 Power is a very important and limited resource in the WCDMA UTRAN network. 9. TS 32.64x UTRAN network resources IRP 32. UTRAN radio channel power monitoring . PMIRP (32.UID_340009 Notification Log IRP is defined to be a general Notification Logging mechanism which can hold notifications related to different functional areas in the network. For those which are not related to power control.154 recommends developing future IRP specifications in a Backward Compatible (BC) way so that the group of IRPManager(s) and IRPAgent(s) are not forced to be upgraded in lock step. there are three different levels of radio channels: logical.405 Performance Measurements . TestIRP (32. Tower Mounted Amplifier/Booster (TMA/B) is not within the scope.e.

405. for those measurement types that can be standardised across all vendors' implementations. TS 32.UID_35059 In Release 6 all the counters were either FDD specific or FDD/TDD specific. however the TNL based on ATM is still an allowed option.g.405 e.73 Overview of 3GPP Release 7 V0. circuit switched inter-RAT handover.403 there are performance measurements families related to the RNC but there are missing performance measurement definitions of the bearer network which help evaluating the transport network layer (TNL) performance and give more detail to analyse RNC performance. the TNL based on IP was introduced in TS 25. Performance measurements definition for CN CS .g. ALCAP. In R6 TS 32. ITU-T or IETF) are only referenced in this specification.UID_35057 Performance measurement data is important for an operator to analyze the network performance. hard handover. radio link addition. Some TDD specific counters are missing in TS 32. signalling connection. relocation.UID_35060 Performance measurements are very important in analyzing. The work was not restricted to UTRAN. RRC connection.401.10 (2010-06) Performance Management (OAM7-PM) . including the protocols of TNL (SCCP. The performance measurement data related to the CN. Iur and Iub interface throughput measurements needed to reflect the interface load RNC resource usage measurements to reflect the equipment load Cell soft handover scale radio link measurements for network planning and optimization Cell paging measurements to reflect the paging channel resource usage RAB establishment measurements per cell to analyze service quality Cell frequency usage measurements to analyze service quality Cell code resource usage for use in network planning and optimization 14. 15. This leads to comparable measurement data produced in a multi-vendor network. SSCOP. RLC connection. and Iu connection release. The work focussed on ATM bearer network performance measurement definitions related to the RNC. For a good monitoring of the UTRAN new performance measurements were added to TS 32.407 contains the Performance measurements for the Core Network (CN) Circuit Switched (CS) domain for both UMTS and combined UMTS/GSM. In R5. IuPS. Enhancement UTRAN performance measurements definition . ATM bearer network Performance measurements . soft handover. Therefore. MTP3B). TS 32. So far the necessary performance measurements related to RNC.UID_35058 Performance measurement data is important for an operator to analyze the network performance. It is therefore necessary to specify a comprehensive set of measurement types for the TDD network elements to deliver TDD network information across the UMTS system.408 contains the Performance measurements Teleservice for both UMTS and combined UMTS/GSM. Add TDD specific counters in Performance measurement . it is necessary to study the ATM bearer network performance measurement definitions to analyse network performance more efficiently.9. Measurements related to 3GPP-"external"technologies (such as ATM or IP) as defined by other standards bodies (e. 13.UID_35043 12. So far the necessary performance measurements related to RNC RAB management. SGSN. especially CN CS (IP-based) is added.: • • • • • • • • • • Inter-frequency and intra-frequency hard handovers for use in network optimization Inter-system HO measurements to show CS and PS domain hard handover stability and reliability RAB drop rate per service type to analyze quality of service IuCS. optimizing and forecasting the UMTS system performance. In R99 and R4 the TNL in UTRAN was based on ATM. GGSN and MMS were defined. From two options the 2nd one was preferred: 3GPP .

openmobilealliance. rather than per node tracing.101. CT1/3/4 . 32. CT3. 16. CT4. SLT is aimed at end-to-end service-level diagnostics. HS-DSCH transmission facilitates several new features. dropped call analysis. and to bulk interfaces for trace data transfer from the network to the Network Manager were produced by: • • • SA5 (having primary responsibility) CT1. CT4 has developed the appropriate specifications for end-to-end service tracing for IMS to fulfil the OMA OSPE service level tracing requirements. By definition. SLT is the ability to capture and log all relevant information at each component within a service chain.409 contain the Performance measurements applicable to IMS.74 Overview of 3GPP Release 7 V0. But to support them with minimum impact on the existing radio interface protocol architecture. Core Network and UTRAN end-to-end 3G procedure validation.9. TS 32. Trace Management (OAM7-Trace) . Interested companies should approach the other standards bodies to include the identified counters.404 / 405 / 406 / 407 support for ATM bearer network Performance Measurement Counters by reference to existing measurements from other standards bodies (ITU-T. and to some extent. HSDPA O&M requirements are need to satisfy the requirement of HSDPA TS 32. 32. Performance measurements definition for IMS . HSDPA performance measurements .UID_35040 The Open Mobile Alliance™ (URL:http://www.UID_35039 Subscriber and Equipment Trace provide very detailed information at call level on one or more specific mobile(s). Trace is activated on user demand for a limited period of time for specific analysis purposes. a new MAC sub-layer. specifications for Subscriber and Equipment Trace pertaining to high-level concepts and requirements of trace. The performance measurement data related to IMS is missing. 3GPP . Contrary to Performance Measurements. ATM Forum). associated with a specific service that is initiated either by an end user or a component (OMA-RDOSPE-V1_0-20050614-C. Trace plays a major role in activities such as determination of the root cause of a malfunctioning mobile. MAC-hs. This data is an additional source of information to Performance Measurements and allows going further in monitoring and optimisation operations.405 contains performance measurements for HSDPA with both FDD and TDD modes. no 3GPP defined performance measurements can be used. advanced troubleshooting. streaming Radio Access Bearer (RAB) services in the downlink. 17.org/) has developed a set of technology agnostic service level tracing requirements (OMA-RD-OSPE-V1_0-20050614-C. 3GPP SA5 (by CRs 32.pdf). CT3. optimisation of resource usage and quality. CT4 (having secondary responsibility) on End-to-end tracing for IMS In particular it was added: 18. a new transport channel was introduced: the High-Speed Downlink Shared Channel (HS-DSCH). Hence.421/2/3). RAN3 (having secondary responsibility) on trace activation/deactivation CT1.UID_35073 In WCDMA 3GPP Release 5.pdf). Service Level Tracing (SLT) improves and simplifies end-to-end service diagnostics and enhances the Mobile Operators' ability to manage complex services. which are a permanent source of information. in coordination with 3GPP CT1. background. End-to-end tracing for IMS: Stage 1 by OMA. which provides enhanced support for interactive.404. RF coverage control and capacity improvement. Stage 2/3 SA5. If an operator deploys IMS. has been introduced for HS-DSCH transmission.10 (2010-06) • • Include in TSs 32.UID_35069 Performance measurement data is important for operator to analyze network performance. to Subscriber and UE activity trace data definition and management. to trace data collection control and configuration management.

zip) were addressed within OMA. CRs 32. 19.10 (2010-06) OMA OSPE service level tracing requirements specific to OMA enablers utilising IMS (OMA-IMSinOMA-V1_020050204-C. IRP for Subscriber and Equipment Trace Management .632/3/5) applies to both Signalling Based Activation and Management Based Activation and allows: • • Activation/Deactivation/Interrogation of a Trace Session from the NM with one unique Trace Reference Trace report to be notified to NM with the known Trace Reference Without the Trace management IRP there is no standardized centralized way for managing the trace.441/2/3/5.9. 3GPP .UID_35063 Trace management IRP (TS 32.75 Overview of 3GPP Release 7 V0.

Align 3GPP Charging with OMA PoC Enabler Release 2. 32. The OMA Push-to-Talk over Cellular Version 2. This alignment has been realized via CRs against 32.0 includes several new chargeable features which impact the 3GPP SA5 TS 32. This was implemented via CRs to offline charging functions in 32.272 32. 32.260.9.817 "Telecommunication management.296 32.260 32. 2.240.240. but has been identified as being responsible for the charges.10 (2010-06) 12. Project scheduling and open issues for SA5.272 defining charging for OMA PoC version 1.272.298. A mechanism to guarantee the delivery of the charged party indication in a trusted manner was needed in a standardized optional way for IMS sessions to be charged to an alternate subscriber. The function is based on the service aspects that define the service as charging a subscriber who is not the originating party.252 32.270 32.0.0 (CH7-PoC) .298.UID_320008 The charging specifications were not supporting any other billing model than "Calling party pays".273 32. Release 7"contains the updated Work Item Descriptions (WIDs) for OAM and Charging management. 3GPP .299 and 32.240 32. Online charging was out of scope of this release.250 32. Alternate Charged Party (ACP) for IMS (CH7-IMS-ACP) .76 Overview of 3GPP Release 7 V0.2 Charging Management small Enhancements (CH7) UID_320007 Acronym: Resources: S5 CH7 TR 30. 32. It was provided an alternate charged party in the Charging Data Function (CDF).298 32. 32. when used with 3GPP IMS core network.299. 32.0 Title/Contents Impacted Specifications Charging architecture and principles Circuit Switched (CS) domain charging Packet Switched (PS) domain charging Wireless Local Area Network (WLAN) charging IP Multimedia Subsystem (IMS) charging Multimedia Messaging Service (MMS) charging Push-to-talk over Cellular (PoC) charging Multimedia Broadcast and Multicast Service (MBMS) charging Online Charging System (OCS): Applications and interfaces Charging Data Record (CDR) file format and transfer Charging Data Record (CDR) parameter description Diameter charging applications New Dedicated Specifications/Reports none 1. References Document WID(s) SP-060442 SP-060546 32.299 none WID on Alternate Charged Party (ACP) for IMS WID on Align 3GPP Charging with OMA PoC Enabler Release 2.297 32.251 32. or service within a serving network.UID_330004 OMA has asked 3GPP SA5 to provide a PoC Charging solution for the enhancements of OMA PoC Release 2.

Areas covered: • • Align protocol between IETF and postponed 3GPP Rel-5 and Rel-6 Stage 3 IMS. Capabilities leading to new or enhanced IMS applications were not dealt with under this work item. not covered by a dedicated WID.002 - Title/Contents WID(s) C1 WID on Interoperability between VGCS/VBS and A/Gb flexibility Impacted Specifications Voice Group Call Service (VGCS). and provide documentation as whether these capabilities are supported in the IM CN subsystem or not Review of additional capabilities provided in SIP by IETF. Review existing and future capabilities provided by IETF in SIP. 13. Rel-7 adds other new capabilities and aligns with ongoing IETF work impacting IMS.930 on signalling flows. CT specified Stage 2 architecture and Stage 3 protocol enhancements as follows: • CT1 added Stage 2 description for VGCS-RANflex interoperability via CR to TS 43.1 IMS Stage 3 IETF Protocol alignment (IMSProtoc) UID_711052 Resources: C1 References Document CP-060101 TS 24. Stage 2 Voice Broadcast service (VBS).77 Overview of 3GPP Release 7 V0. Stage 3 IMS was defined in Rel-5 and Rel-6 to support IP Multimedia services. Stage 2 Mobile Application Part (MAP) specification New Dedicated Specifications/Reports - SA2 identified that A/Gb flexibility (IuFlex) and VGCS/VBS do not interoperate and therefore should not be operated together in the same service area of a network.229 TS 23. and provide documentation as whether these capabilities are supported in IMS or not. Create TR 24.218 TR 24. were covered by this work item. and provide documentation as whether these capabilities are supported in the IM CN subsystem or not New Dedicated Specifications/Reports Signalling flows for the session setup in the IM CN subsystem based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP).068 TS 43. This work covers only protocol alignment. This work overcomes this limitation achieving full interoperability between VGCS/VBS and A/Gb flexibility from Rel-7 onwards.C4 References Document CP-060102 TS 43.930 Title/Contents WID(s) WID on IMS Stage-3 IETF Protocol Alignment Impacted Specifications Review of additional capabilities provided in SIP by IETF. reflecting the different options for session setup in IMS. 3GPP .069 TS 29.068.10 (2010-06) 13 CT Features 13.2 Interoperability between VGCS/VBS and A/Gb flexibility (VGCSFlex) UID_7043 Resources: C1.9. Minor technical enhancements to IMS Rel-7.

DIAMETER is used over several interfaces including: Cx. Rf. Authorization and Accounting (AAA) services. Other platforms that could have used either RADIUS or DIAMETER have been allowed to use DIAMETER in the specifications. 13.061) supports only the RADIUS protocol. Authorization and Accounting (AAA) services.78 Overview of 3GPP Release 7 V0.10 (2010-06) • • CT1 added Stage 2 description for VBS-RANflex interoperability via CR to TS 43.002.061 Title/Contents WID(s) WID on DIAMETER on the GGSN Gi interface Impacted Specifications Interworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Network (PDN) New Dedicated Specifications/Reports - GGSN Gi interface in GPRS Rel-6 (TS 29. 13. Gq. Other platforms that could have used either RADIUS or DIAMETER have been allowed to use DIAMETER in the specifications. The DIAMETER messages and AVPs (Attribute-Value-Pair in DIAMETER messages) were defined through reference to TS 29.5 Interworking between the 3GPP CS domain with BICC or ISUP as signalling protocol and external SIP-I networks (ExtSIPI) UID_13033 Resources: C3 3GPP . Ro.4 DIAMETER on the PDG Wi interface (DIAMWi) UID_13022 Resources: C3 References Document CP-060432 TS 29.061 in order to provide Authentication. Several reference points in Wireless LAN will be using DIAMETER.161 Title/Contents WID(s) WID on DIAMETER on the PDG Wi interface Impacted Specifications Interworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Network (PDN) New Dedicated Specifications/Reports - The protocol for Wi interface is currently RADIUS.061. 13.069. The usage of DIAMETER over the PDG Wi interface was introduced in TS 29. CT4 introduced a new MAP messages between group call channel controlling MSC/VLR and serving MSC/VLR via CR to TS 29.161 in order to provide Authentication.3 DIAMETER on the GGSN Gi interface (DIAMGi) UID_13023 Resources: C3 References Document CP-060431 TS 29. in IMS. Sh.9. policy control and IP flow charging. The usage of DIAMETER over the GGSN Gi interface was introduced and the DIAMETER message flows between GGSN and DIAMETER Server were described in TS 29.

79 Overview of 3GPP Release 7 V0. Differences between SIP and SIP-I do not impact the user plane. e. It is therefore expected that the existing Mn interface may be applied without modifications between the server and gateway part of the CS domain Interworking node to be standardised. The new TS 29.5 describes the Interworking between SIP-I and BICC or ISUP. Service Aspects: The Interworking of ISUP supplementary services should be addressed as an operator option. The 3GPP Mn interface was designed to control an IM-MGW that interconnects CS networks. and an IMS network. which applies either BICC or ISUP as signalling protocol.163 describes the Interworking between the IMS profile of SIP and CS networks using either BICC or ISUP. as they apply the same encoding to describe media streams. Therefore.6 PDU multiplexing at Nb Interface with IP transport (NbIPMux) UID_340047 Resources: C3 References Document CP-070105 TS 29.9. but related H.1912.10 (2010-06) References Document CP-070101 TS 29. rather than the standardization of entirely new Interworking procedures an endorsement and amendment of the existing standardized procedures for the particular requirements of the 3GPP CS domain seems advisable. The procedures of ITU-T Q. The 3GPP CS domain applies either ISUP or BICC as signalling protocol. which are also applied in external SIP-I networks. To minimise impacts for the deployed CS network. RTP. The 3GPP specification allows operators to configure the Interworking node accordingly. Considerable standardisation work in the field of Interworking between BICC/ISUP and SIP is already available. this Interworking is performed at a gateway node at the interconnection between the 3GPP CS domain and external SIP-I networks that may be collocated with a gateway MSC.164 Title/Contents WID(s) WID on Interworking between the 3GPP Cs domain with BICC or ISUP as signalling protocol and external SIP-I networks Impacted Specifications New Dedicated Specifications/Reports Interworking between the 3GPP Cs domain with BICC or ISUP as signalling protocol and external SIP-I networks In external networks.164 reuses as far as possible existing Interworking procedures in TS 29. 13. As part of the work. thus allowing the use of Transcoder Free Operation (TrFO).5 are quite similar to TS 29. such as the 3GPP CS domain.414 Title/Contents WID(s) WID on PDU multiplexing at Nb Interface with IP transport Impacted Specifications Core network Nb data transport and transport signalling New Dedicated Specifications/Reports - 3GPP . and external networks that use SIP-I as signalling protocol.164 specifies interworking procedures between a 3GPP CS domain. Profile C of ITU-T Q. SIP-I is gaining importance as signalling protocol. procedures to interwork the codec negotiation between SIP-I and BICC were standardized.163.g. TS 29. TS 29. Security Aspects: Trust relationships between operators determine the amount of signalling information exchanged between the networks. The Interworking node may be split between into a server and gateway part.1912. This Interworking is performed at a gateway node at the interconnection between the 3GPP CS domain and external SIP-I networks that may be collocated with a gateway MSC. However. The user plane in the IMS applies standard IETF protocols.163 and only describe deltas against it. there is a need to provide interworking between such already deployed 3GPP CS domain networks and external networks that use SIP-I. and also contains procedures to interwork the codec negotiation between SIP and BICC. Thus.248 procedures for a split architecture and codec Interworking procedures are lacking.

248 Protocol with the additional support of Multimedia specific H. including the additional Packages and procedures. 35 byte for AMR 12.g. A new transport format for Nb IP bearers and signalling extensions for multiplexing negotiation is added to TS 29.80 Overview of 3GPP Release 7 V0. The Mp Interface.248 including the additional H. The solution minimizes impacts to existing network characteristics (in particular jitter and packet delay) and suites any type of payload transported within NbFP.333 TS 29.229 TS 23. supports the H.MRFP) interface (Mp) UID_14012 Resources: C4. ad-hoc video and audio conference capabilities. session identifier) and control MRFP accordingly.814 (Study on Bandwidth Saving at Nb Interface with IP transport UID_7034) For typical payload transported over the Nb interface. Procedures description Multimedia Resource Function Controller (MRFC) – Multimedia Resource Function Processor (MRFP) Mp Interface.10 (2010-06) This work is based on the Rel-7 TR 29. One method of doing this is by multiplexing several NbFP/codec payload PDUs of different bearers within one IP packet sent between MGWs over the Nb interface. Stage 3 New Dedicated Specifications/Reports Multimedia Resource Function Controller (MRFC) – Multimedia Resource Function Processor (MRFP) Mp interface.MRFP) interface Impacted Specifications IP Multimedia Call Control Protocol based on SIP and SDP. 60 byte for IPv6) and the layer 2 header/trailer header overhead (e.9. Application Server (AS) and Serving Call Session Control Function (S-CSCF).g. It considered both IP and MPLS core networks (MPLS may reside either in edge routers or directly within MGWs). Sources media streams (for multimedia announcements). and the support of announcements. MRFC: • • • Controls the media stream resources in the MRFP. which is located between these two functions.g. optional multiplexing mechanism for the Nb interface and IP transport that allows transporting several NbFP/codec payload PDUs of different bearers. It is desirable to reduce the /IP/UDP/RTP header and the layer 2 header/trailer overheads to save bandwidth. Processes media streams (e. 7 bytes for POS) are much larger than the transported payload NbFP/codec (e. for multiple parties). 3GPP . 38 bytes for Ethernet v2. Generates CDRs MRFP: • • • • • Controls bearers on the Mb reference point.g.7 Mp (MRFC . for example.248 Multimedia Packages between the MRFC and MRFP and the relationship between the S-CSCF and MRFC interface (Mr-interface) SIP and SDP procedures/instructions and the associated H. and by optionally compressing RTP headers This work defines a solution for a simple. Provides resources to be controlled by the MRF.248.C1 References Document CP-070246 TS 24. the /IP/UDP/RTP header overhead (40 byte for IPv4.248 Packages. provides. Interprets information coming from an AS and S-CSCF (e. through interactions with the User Equipment (UE). Stage 3 Title/Contents WID(s) Within IMS. This work defines using H. the Multimedia Resource Function (MRF).2 kHz and 9 byte for SID frames). MRF contains two functions MRFC and MRFP. Mixes incoming media streams (e. 13. media analysis). tones and media streams processing.g.414.333 WID on Mp (MRFC .

CT4's TR 23. 3GPP .040. in effect setting-up a relay that allows the HPLMN of the receiving MS to control the delivery of all short messages even when the receiving MS is roaming outside of their HPLMN. Addition of new value added capabilities such as "SMS Forwarding". CT4 added optional insertion of flags and updated signal flow diagrams in TS 29. Provision of an interception point for Spoof and Fake SMS. in order to protect a number of existing 3GPP specified services from the negative effects of a multiplicity of non-standard solutions.10 (2010-06) 13.840 (Study on Routeing of MT-SMs via the HPLMN UID_14019) examined the desirability of producing a standardized solution for the termination of short messages in the HPLMN of the receiving MS via an SMS-SC-like logical entity. The opportunity to include a non-standardised SMS-SC-like logical entity in the HPLMN of the receiving MS already exists outside of 3GPP specifications for operators.840.002 Title/Contents WID(s) WID on Routeing of MT-SMs via the HPLMN Impacted Specifications Technical realization of Short Message Service (SMS) Mobile Application Part (MAP) specification New Dedicated Specifications/Reports - This work is linked to SA2 Feature: Support of SMS over generic 3GPP IP access (SMSIP) UID_32081. CT1 added architecture and procedural descriptions via CR to TS 23.81 Overview of 3GPP Release 7 V0. This work adds in existing 3GPP specifications.9.C1 References Document CP-070032 TS 23.8 Routeing of MT-SMs via the HPLMN (SMSviaH) UID_340016 Resources: C4. The potential benefits include: • • • • More control over SMS Spam.002 clause 23.040 TS 29. Added flexibility for MT-SMS charging (particularly pre-pay). the agreed solution as defined in TR 23.

after receipt of a MAP Cancel Location procedure. Technical realization (CR#0157) Customized Applications for Mobile network Enhanced Logic (CAMEL) Phase X. A solution is proposed to allow routing of the terminating call to the called party. mobile terminating calls to a called party which is simultaneously moving to another MSC will either be lost or forwarded to a 3rd party (e.82 Overview of 3GPP Release 7 V0.10 (2010-06) 13.079 TS 29.008 TS 23. This second SRI request allows the GMSC to obtain a roaming number for the new MSC towards which the call can then be delivered.002 Title/Contents WID(s) WID on Mobile Termination whilst the MS is moving to another MSC Impacted Specifications Organization of subscriber data (CR#0206) Location management procedures (CR#0026) Basic call handling.9.g.018 TS 23.078 TS 23. Stage 2 (CR#0815) Support of Optimal Routeing (SOR). This problem has been seen by many operators and accounts for a fair percentage of MT calls failing to get through generally on networks. using the Resume Call Handling procedure.012 TS 23. An optional procedure is added to CT4 specifications allowing delivery of the terminating call to the called party. and thus enable operators to reduce these customer perceived failures to improve their completion rates and customer satisfaction. If this procedure is supported by the GMSC. 3GPP . the old VMSC shall redirect the mobile terminated call to the new MSC by instructing the GMSC to send an additional SRI to the HLR. the HLR and the terminating VMSC.9 Mobile Termination whilst the MS is moving to another MSC (MTmovMS) UID_350003 Resources: C4 References Document CP-070334 TS 23. voicemail). Technical realization (CR#0085) Mobile Application Part (MAP) specification (CR#0848) New Dedicated Specifications/Reports - With the existing 3GPP specifications.

10 (2010-06) 14 CT6 Features 14.101 Title/Contents WID(s) WID on High Speed Interface between the UICC and the ME Impacted Specifications - New Dedicated Specifications/Reports UICC-terminal interface.101 The smart card is undergoing a significant trend towards higher memory capacity and increased computing power.9.133 WID on ISIM API for Java Card™ Title/Contents WID(s) Impacted Specifications - New Dedicated Specifications/Reports IP Multimedia Services Identity Module (ISIM) Application Programming Interface (API).1 ISIM API for Java Card (APIJAVA) UID_743009 Resources: C6 References Document CP-050145 TS 31. CT6 developed a new API specification based on the ETSI SCP TS 102 241 providing means for application developers to access the ISIM file system defined in TS 31.103 (Characteristics of the IP Multimedia Services Identity Module (ISIM) application). Physical and logical characteristics After TSG CT has noted that ETSI SCP has selected a technology to cover SA's service requirement for a high-speed access to data on the UICC. The new High Speed ME-UICC Interface was included via CR in TS 31.103 in an interoperable way. It is expected that this trend will significantly enhance services and service opportunities related to new applications.2 High speed interface between the UICC and the ME (HSI) UID_330001 Resources: C6 References Document CP-070259 TS 31. 14. 3GPP . the inclusion of the new interface in the 3GPP USIM and ISIM specifications was needed. ISIM API for Java Card Application developers need to access in an interoperable way the ISIM application defined in TS 31.83 Overview of 3GPP Release 7 V0.

213 needs updating to: • • • Extend existing test specification to take into account all new features of Rel-7 Modify existing test specification to take into account all corrections and clarifications of Rel-7 API methods Review and.9. the related test TS 31.213) UID_440042 Resources: C6 References Document CP090450 TS 31.84 Overview of 3GPP Release 7 V0. update existing tests 3GPP .3 Rel-7 (U)SIM API Testing (TS 31. if identified necessary.213 Title/Contents WID(s) WID on Rel-7 (U)SIM API Testing (TS 31. Application Programming Interface (API) for Java Card™ With the Rel-7 evolution of the (U)SIM API for Java card (TS 31.130) incorporating new and changed functionalities.10 (2010-06) 14.213) Impacted Specifications New Dedicated Specifications/Reports Test specification for subscriber (U)SIM. new constants & toolkit events and clarifications of existing methods.

RAN1 TR 25.461.1 Multiple Input Multiple Output antennas (MIMO) UID_2468 Resources: RP References Document RP-0300192 TS 25.133.85 Overview of 3GPP Release 7 V0.876 contains the working assumptions and evaluation criteria of the different techniques considered for MIMO in UTRA.7/2.121 3GPP .214 covers the definition of MIMO operation on HS-PDSCH. The PARC scheme was selected for TDD and Dual-codeword MIMO based on D-TxAA was selected for FDD. Node B receive).214 TS 25.141.101.1 GHz Band) defines as a new operating band: • • 1710 – 1770 MHz: Up-link (UE transmit. It specifies the extended 1.423.7/2. TR 25.212 TS 25. 25.306.215 TS 25. Stage 3 focussed on UTRA FDD.1 GHz FDD system for potential deployment in ITU Region 2 only. with the weights being signalled on the HS-SCCH in the downlink. UE receive).806. This is achieved by using multiple antennas at both UE and Node-B sides. affected specifications 25. 2110 – 2170 MHz: Down-link (Node B transmit. 15. TR 25.2 Rel-7 Improvements of the Radio Interface (RInImp) UID_20028 15. 25.10 (2010-06) 15 RAN Features 15.1 GHz band and Band IV radio requirements.7/2. 34. WID in RP-060180.7/2.7/2.876 TR 25.221 TR 25. Measurements (FDD) Physical channels and mapping of transport channels onto physical channels (TDD) New Dedicated Specifications/Reports Multiple Input Multiple Output (MIMO) antennae in UTRA Spatial channel model for Multiple Input Multiple Output (MIMO) simulations MIMO improves system capacity and spectral efficiency by increasing the data throughput in the downlink within the existing 5 MHz carrier. Band IV (UMTS 1. Status Report in RP-070037and RP-070531.806 investigates possible commonality between the new Extended 1. This extended operating band contains the whole Band IV (1710-1755/2110-2155 MHz) as a sub-band.307.1 GHz UID_20060 Resources: R4 WRC 2000 identified additional spectrum for IMT-2000.2. TS 25. 25. 25. TS 25.9.211 TS 25. 25. including the band 1710-1885 MHz.104. Completed Sep 2007.213 TS 25.996 Title/Contents WID(s) WID on Multiple Input Multiple Output Antennas Impacted Specifications Physical channels and mapping of transport channels onto physical channels (FDD) Multiplexing and channel coding (FDD) Spreading and modulation (FDD) Physical layer procedures (FDD) Physical layer.331. 25. 24. The MIMO functionality was integrated in UTRA (FDD and TDD) to improve capacity and spectral efficiency.1 Extended UMTS 1. 25.212 covers coding for HS-SCCH (Downlink) and HS-PDCCH (Uplink).1) and Band IX (UMTS 1700). 3GPP has specified three bands that include parts of this frequency range: Band III (UMTS 1800). 25.806 (radio requirements for UTRA FDD in the Extended 1. 25.463.

25. 25.2690 MHz has progressed to the extent that 3GPP TSG RAN had sufficient information to commence work on specification for UMTS operating within the band 2500 . Assigned blocks shall be in multiple of 5. 25.0 MHz.141. 25. During the UMTS 2. Status Report in RP-060681 15. in particular for RAN4 to consider co-existence with IMT2000 technology within 2500 – 2690 MHz under the same constraints used for the UMTS 2. Node B receive) 2620 – 2690 MHz: Down-link (Node B transmit. 34.6 GHz 7. 25.10 (2010-06) Completed Dec 2006.142.105.2690 MHz as considered by CEPT/PT1: • • • the frequency band 2500 – 2570 MHz is paired with 2620 – 2690 MHz for FDD operation with the mobile transmit within the lower band and base transmit within the upper band. 34. UE receive) The co-existence with IMT2000 technology within 2500 – 2690 MHz shall be considered.6 GHz TDD work item.113.6 GHz TDD work item.121 Completed Jun 2005. This work provides the necessary information for 2. This work covers the 3.2690 MHz as considered by CEPT/PT1 is: • • • The frequency band 2500 – 2570 MHz is paired with 2620 – 2690 MHz for FDD operation with the mobile transmit within the lower band and base transmit within the upper band.68 Mcps TDD UID_20067 Resources: R4 Harmonised spectrum scheme for IMT-2000/UMTS in the band 2500 .307. operation of the 3GPP TDD mode was specified for operation in the band 2570 – 2620 MHz.68 Mcps TDD system operation. Any guard bands required to ensure adjacent band compatibility at 2570 MHz and 2620 MHz boundaries will be decided on a national basis and taken within the band 2570 – 2620 MHz.306. 25. 25.6 GHz Band:   • 2500 – 2570 MHz: Up-link (UE transmit.942. This work provides the necessary information of 2.86 Overview of 3GPP Release 7 V0. Administrations may assign the frequency band 2570 – 2620 MHz either for TDD or for FDD downlink (external).9. affected specifications 25. Status Report in RP-050184 3GPP .6 GHz FDD system: • Generate a report summarizing a study of radio requirements UTRA FDD in the 2. Any guard bands required to ensure adjacent band compatibility at 2570 MHz and 2620 MHz boundaries to be decided on a national basis and taken within the band 2570 – 2620 MHz. 25. Administrations may assign the frequency band 2570 – 2620 MHz either for TDD or for FDD downlink (external).68 Mcps TDD option. Within a previous work item (UMTS 2.133.28Mcps TDD options.6 GHz TDD).2 UMTS 2. This initially did not include operation in the 2.2. work was also ongoing on a further work item to include the 7.6 GHz 7. 25. Assigned blocks shall be in multiple of 5.104.331.124 Completed Sep 2006. Status Report in RP-060451 15.102. affected specifications 25.2690 MHz. 25.3 UMTS 2.0 MHz.6 GHz band due to lack of completion of the UMTS 2.123. WID in RP-060349.101. The harmonised spectrum scheme for IMT-2000/UMTS in the band 2500 . 25. WID in RP-040397.2.6 GHz TDD work item.84Mcps and 1.6 GHz UID_20021 Resources: R4 Work within CEPT/PT1 regarding the ECC Decision on harmonised utilization of spectrum for IMT-2000/UMTS systems operating within the band 2500 .

25.105.101.121 Completed Dec 2005.142.87 Overview of 3GPP Release 7 V0.113.307. Assigned blocks shall be in multiple of 5. WID in RP-040541. i.123.2620 MHz TDD ).133.2690 MHz as considered by CEPT/PT1 is: • • • The frequency band 2500 – 2570 MHz is paired with 2620 – 2690 MHz for FDD operation with the mobile transmit within the lower band and base transmit within the upper band.133. 25. Administrations may assign the frequency band 2570 – 2620 MHz either for TDD or for FDD downlink (external). 25.306. 25. 25. 25. affected specifications 25.9 – 1784. 25. 25.6 GHz Band (2570 . 25.121 Completed Dec 2005.331.9. Node B receive) 925 – 960 MHz: Down-link (Node B transmit. 25.5 UMTS 900 MHz UID_20027 Resources: R4 RAN4 performed the necessary work to allow the introduction of UMTS in the 900 MHz.9 MHz: Down-link (Node B transmit.141. WID in RP-040553. WID in RP-050385.307. Status Report in RP-050662 15. This work provides the necessary information for 2. 25. 34.104. 25. Status Report in RP-050661 15.331.e. a report summarizing a study of radio requirements for UTRA TDD in the 2. The co-existence with IMT2000 technology within 2500 – 2690 MHz shall be considered. UE receive) It studied co-existence with ARIB STD-28 (PHS).104.2690 MHz.942. Any guard bands required to ensure adjacent band compatibility at 2570 MHz and 2620 MHz boundaries to be decided on a national basis and taken within the band 2570 – 2620 MHz. The harmonised spectrum scheme for IMT-2000/UMTS in the band 2500 .10 (2010-06) 15.2690 MHz has progressed to the extent that 3GPP TSG RAN had sufficient information to commence work on specification for UMTS operating within the band 2500 . 25. 25.6 UMTS 1700 MHz UID_20043 Resources: R4 This work evaluates UMTS 1700 for potential deployment in Japan in: • • 1749.2. taking the frequency reframing plan in Japan into account.102.307. affected specifications 25. 34. 25. 25. 34.9 – 1879. 25. Status Report in RP-050824 3GPP .141.331. 25. 25.2.4 UMTS 2. 25.0 MHz.6 GHz TDD. UE receive) RAN 4 evaluated the BS and UE minimum RF performance requirements necessary to ensure the good co-existence of GSM and UMTS in the 900 MHz band in practical deployment scenarios. 25.124 Completed Dec 2005. 25.113.113.6 GHz TDD UID_20025 Resources: R4 Work within CEPT/PT1 regarding the ECC Decision on harmonised utilization of spectrum for IMT-2000/UMTS systems operating within the band 2500 .942. 34. produce the necessary UMTS900 specifications and check the current RF Scenarios against the requirements in the band: • • 880 – 915 MHz: Up-link (UE transmit.9 MHz: Up-link (UE transmit.306.101. affected specifications 25.2. 25.122.306. Node B receive) 1844.

no specific implementation solution is mandated by the performance requirements.7 UE Antenna Performance Evaluation Method and Requirements UID_20024 Resources: R4 UE antenna performance has critical impact on both system performance (throughput) and coverage. for selected key non-HSDPA transport channels using receiver diversity as the baseline receiver. affected specifications 25.101 Completed Mar 2006.10 (2010-06) 15. and it is expected that diversity receivers for HSDPA can also readily operate with diversity for non-HSDPA channels.2. However.101 for HSDPA on the basis of enhanced receivers of Type 1 and 2 (RX diversity and LMMSE). No specific implementation solution is mandated by the performance requirements. affected specifications 25. 15. minimal requirements for UE antenna performance are needed. For the speech mode (UE close to head) it: • • introduces a method for UE antenna performance evaluation. It provides the benefits of Rx diversity for all (Ior/Ioc) geometries while the LMMSE augments the benefits of Rx diversity when effectively operating at the higher (Ior/Ioc) geometries. and it is expected that diversity receivers for HSDPA can also readily operate with 3GPP .101. Status Report in RP-060015 15. Status Report in RP-070281. WID in RP-050362. 25.963 Completed May 2007. further improvements for HSDPA performance requirements for 10 code UEs (i. The performance benefits of RX diversity are potentially large for nonHSDPA transport channels as well.88 Overview of 3GPP Release 7 V0.2.101 for HSDPA on the basis of enhanced receivers of Type 1 and 2 (Rx diversity and LMMSE).9 Additional minimum UE performance requirement for non-HSDPA channels based on Type 1 enhanced receiver (Rx Diversity) UID_20062 Resources: R4 Improved performance requirements have been included in TS 25. No specific UE implementation is mandated by these enhanced HSDPA requirements. defines UE antenna minimal performance requirements. The performance benefits of Rx diversity are potentially large for nonHSDPA transport channels as well. for categories 7 and 8) were introduced above the Rel-6 improvements based on reference receiver LMMSE chip-level equalizer and a reference receiver with receive diversity.2. The proposed performance requirements would enable verification that such receivers do achieve expected improved performance with non-HSDPA channels. WID in RP-050122. A subset of the current non-HSDPA receiver performance requirements would need to be improved to ensure the main expected benefits.8 Improved Performance Requirements for HSDPA UE based on Rx Diversity (Type 1) & LMMSE equalizer (Type 2) UID_20045 Resources: R4 To further increase attractiveness and performance of the higher code capability UE classes. In order to ensure a certain level of coverage and QoS for the user. The combined reference receiver can be based on the receiver structures that were used for defining HSDPA performance improvements in Rel-6 (Type 1 and Type 2 performance improvements).e. It defines optional performance requirements for enhanced receivers Type 1. This would enable potential gains from diversity to be utilized for services such as circuit-switched voice and MBMS.9. Additional minimum UE performance requirement for DL physical channels in support of DCH/HS-DSCH operation based on Type 1 enhanced receiver (RX-Diversity) Improved performance requirements have been included in TS 25.

affected specifications 25.123-2.108. 3GPP . 34. Yet.121 34. This would enable potential gains from diversity to be utilized for services such as circuit-switched voice and MBMS. RAN#41 completed (GERAN aspects might need to be included later) 2501 5 UE conformance testing for FDD Inter-Band Operation RInImp-InterBand_Test 34. The proposed performance requirements would enable verification that such receivers do achieve expected improved performance with non-HSDPA channels. It defines new optional minimum UE performance requirements based on Type 1 receiver for the E-RGCH.121 34. However. WID in RP-060184.108 34. HS-SCCH). Status Report in RP-060679 15. It defines new optional minimum UE performance requirements based on Type 1 receiver for the MICH and S-CCPCH considering MTCH and MCCH operation. minimum UE performance requirements based on Type 1 receiver have not been defined for other physical channels. A subset of the current non-HSDPA receiver performance requirements would need to be improved to ensure the main expected benefits.108. Status Report in RP-060678 Additional minimum UE performance requirement for downlink physical channels in support of E-DCH operation based on Type 1 enhanced receiver (Rx-Diversity) Minimum UE performance requirements based on Type 1 receiver have been defined for downlink physical channels related to Release-5 HS-DSCH operation (HS-PDSCH.121. 34.89 Overview of 3GPP Release 7 V0. HS-SCCH). for selected key non-HSDPA transport channels using receiver diversity as the baseline receiver.10 (2010-06) diversity for non-HSDPA channels.101 Completed Dec 2006.114 Notes Status Report in RP080535.101 Completed Dec 2006. It defines optional performance requirements for enhanced receivers Type 1. No specific implementation solution is mandated by the performance requirements. 34.9. Minimum UE performance requirements based on Type 1 receiver have not been defined for other physical channels. Yet. no specific implementation solution is mandated by the performance requirements. No specific implementation solution is mandated by the performance requirements. E-AGCH and E-HICH.123-1. UE supporting Type 1 receiver for HS-DSCH operation could also use the Type 1 receiver capability to improve the demodulation performance for other downlink physical channels. affected specifications 25.101 Completed Jun 2006.2.108.UE Conformance Testing UID_25025 Resources: R5 Linked to Feature UID_20028 (RInImp) UID 2500 7 2500 8 2501 3 2502 0 Name UE conformance testing for UMTS 2600 MHz UE Conformance Test for UMTS 900 MHz (band VIII) Conformance Test Aspects – Improved Performance of HSDPA Receiver type 3 UE antenna Over The Air (OTA) conformance testing Acronym RInImp-UMTS2600_Test RInImp-UMTS900_Test RInImp-HSPerf-Type3_Test RInImp-UEAnt_Test TSs_TRs 34. affected specifications 25. Status Report in RP-060235 Additional minimum UE performance requirement for downlink physical channels in support of MTCH and MCCH operation based on Type 1 enhanced receiver (Rx-Diversity) Minimum UE performance requirements based on Type 1 receiver have been defined for downlink physical channels related to Release-5 HS-DSCH operation (HS-PDSCH. 34. WID in RP-060185.10 Improvements of the Radio Interface . UE supporting Type 1 receiver for HS-DSCH operation could also use the Type 1 receiver capability to improve the demodulation performance for other downlink physical channel. WID in RP-060183. 34.

222 and 25.1xx No Title/Contents WID(s) WID on Optimization of channelization code utilization 1. It allows a better utilization of codes for dedicated channels. Efficient utilization and careful management of both downlink and uplink code resources is desirable.10 (2010-06) 34.108. Several features require a UE specific code for a dedicated channel.331 TS 25.90 Overview of 3GPP Release 7 V0. For TDD code resources are limited on both uplink and downlink.121-1. IMS with infrequent RTCP packets and full headers which have to be sent with low delay.221 TS 25. and Iub/Iur protocol aspects were intorduced.423 TS 25.222 TS 25.28 Mcps TDD Impacted Specifications Physical channels and mapping of transport channels onto physical channels (TDD) Multiplexing and channel coding (TDD) Physical layer procedures (TDD) Radio Resource Control (RRC).7/2. A new physical channel PLCCH (Physical Layer Common Control Channel) was introduced to efficiently carry SS/TPC signalling to multiple users.221.28 Mcps TDD UID_20026 Resources: R1 References Document RP-040552 TS 25. This enables code resources to be released which may be re-used by other DL channels.430 TS 25.3 RAN improvements (RANimp) UID_20029 15. Protocol specification UTRAN Iur interface Radio Network Subsystem Application Part (RNSAP) signalling UTRAN Iub Interface: general aspects and principles UTRAN Iub interface Node B Application Part (NBAP) signalling New Dedicated Specifications/Reports No Code utilization is an important element for the uplink and downlink efficiency of UTRA-TDD cells. 25. HSDPA transmissions also require channelization codes and so efficient code utilization of dedicated channels also improves HSDPA performance.9. Also.3. This applies to the downlink and uplink for TDD. 34.121-2 2504 0 RInImpUEConTest_RxDivMBMS Status Report RP-080056 15. such as HSDPA which requires an associated DPCH.1 GHz Conformance Test Aspects – Minimum UE performance requirement for downlink physical channels in support of E-DCH operation based on type 1 enhanced receiver (Rx-Diversity) Conformance Test Aspects – Minimum UE performance requirement for downlink physical channels in support of MTCGH and MCCH operation based on type 1 enhanced receiver (Rx-Diversity) RInImpUEConTest_UMTS1721Ext RInImpUEConTest_RxDivEDCH 34. the corresponding changes to layer 2 and 3 apects. The new channel was intoroduced in TS 25.433 TS 25.123-3 2502 8 2503 9 Conformance Test Aspects – Extended UMTS 1. thus removing the need for the associated DL DPCH in the case that no higher layer data is mapped to it.224 TS 25. Status Report in RP-060682 3GPP .1 Optimization of channelization code utilization for 1.224. 34. Completed Dec 2006.

331).321 TS 25.321. due to this delay.g.3.2 Delay optimisation for procedures applicable to CS and PS Connections UID_20031 Resources: R2 References Document RP-050386 TS 25. Analyses and recommendations In a modern telecommunication network such as UMTS.815 proposes enhancements and changes to existing specifications (TS 25. The delay in set up or channel allocation times can be attributed to: • • • • • • • • Processing time in the UTRAN Processing time in the Core network Processing time in UE Call setup and alerting phase in the core network UTRAN and CN Protocols and associated overhead including protocol conversion Signalling delay on the air interface Signalling delay on UTRAN interfaces and towards CN NAS procedures The objectives are: • • • • • • • • To review the CS and PS Call and session Setup and channel allocation procedures in UMTS To highlight the improvements where call and session setup process can be improved and consider impacts the relevant specifications To highlight the improvements to the existing RRC state transitions To identify possible ways to enhance call and session setup performance whilst keeping in mind R99 backwards compatibility To put forward change request relevant to specifications To focus on the reduction of delay caused by RAN related aspects To review performance requirements for e. 3GPP . which determine the degree of satisfaction of a user of a service.10 (2010-06) 15.322.9. may think that the connection has not gone through or the network is not responding which may prompt the user to re-dial. This work investigates mechanisms to improve the connection establishment times.322 TS 25. 25. RRC procedures To review network RRM strategies TR 25.815 Title/Contents WID(s) WID on Delay optimisation for procedures applicable to CS and PS Connections Impacted Specifications Medium Access Control (MAC) protocol specification Radio Link Control (RLC) protocol specification Packet Data Convergence Protocol (PDCP) specification New Dedicated Specifications/Reports Signalling enhancements for Circuit-Switched (CS) and Packet-Switched (PS) connections.91 Overview of 3GPP Release 7 V0. The QoS is the collective effect of service performances. Solutions with limited impact on the UE development were preferred in order to ensure a fast delivery. When establishing a connection the user. Under the general heading of quality of experience (QoE) one of the more noticeable points faced by the user is the apparent delay in set up or channel allocation times for different connections. From the service provider’s perspective improving the quality of service is very important giving their users a good perception of the network performance and efficiency. Priorities were given to decrease the latency caused by the various factors. reconnect or even in some cases to abandon the connection attempt. 25. the aim of the operator is to offer high Quality of Service (QoS) to users.331 TR 25. The set up and channel allocation delay can be defined as the time interval from the instant the user initiate a connection request until the complete message indicating call disposition is received by the calling terminal or the by application server.

3. Results of SA4 on MBMS were considered.123 None Title/Contents WID(s) WID on UE Performance Requirements for MBMS (TDD) Impacted Specifications User Equipment (UE) radio transmission and reception (TDD) Requirements for support of radio resource management (TDD) New Dedicated Specifications/Reports - In order to facilitate the deployment MBMS.92 Overview of 3GPP Release 7 V0. Status Report in RP-060477 15.3 Improved support of IMS Realtime Services using HSDPA/HSUPA UID_20032 Resources: R2 References Document RP-050160 None None Title/Contents WID(s) WID on Improved support of IMS Realtime Services using HSDPA/HSUPA Impacted Specifications - New Dedicated Specifications/Reports - HSDPA and HSUPA are very important features for operators to carry efficient multimedia services in conjunction with IMS. Completed Sep 2006. Conclusion: there is enough functionality in Rel-6 to support VoIP over HSDPA/HSUPA. e. Status Report in RP-060453 15.3. Performance requirements take into account the potential impacts of interruptions (e. minimizing the service interruption time in case of handover and ensuring efficient radio resource utilization. The objective is to improve the support for IMS real time services using HSDPA/HSUPA. It defines performance requirements for the support of MBMS P2M radio links and MICH by the UE.g. the VoIP capacity and RT Gaming issues have not been optimized. however.5 Continuous connectivity for packet data users UID_20046 Resources: R1 3GPP . Status Report in RP-050667 15.4 UE Performance Requirements for MBMS (TDD) UID_20033 Resources: R4 References Document RP-050156 TS 25.9. However. It defines performance requirements for the support of the MBMS feature in the UE. it is essential to ensure that MBMS capable UES are supporting a minimum level of performance in terms of P2M radio link reception. Remaining open items moved to the following WIs: • • Improved support of gaming over HSDPA/EDCH Continuous connectivity for packet data users Closed Dec 2005. measurements) (inter-RAT and/or inter-frequency). there is a need to investigate further the possibilities to enhance the support for IMS real time services.102 TS 25.g.10 (2010-06) Completed Sep 2006.3.

and avoiding frequent connection termination and re-establishment with its inherent overhead and delay. one is HS-SCCH less operation and the other is DTX/DRX at the UE. it is intended to reduce the impact of control channels while maintaining the DCH state and allowing a much faster reactivation for temporarily inactive users. new slot format of HS-SCCH (type 2) were introduced to be used for: • • HS-SCCH less operation: CRC type 2 for HS-PDSCH and HS-SCCH format for retransmissions added.321 TS 25. where the user stays connected over a long time span with only occasional active periods of data transmission.133 TS 25.214 TS 25.331 TS 25.331 TS 25. the limiting factor for supporting a similarly high number of E-DCH users is the noise rise.903 Title/Contents WID(s) WID on Continuous connectivity for packet data users Impacted Specifications Physical layer . VoIP) and non real-time services. In the uplink.201 TS 25.425 TS 25. for reading during web browsing or in between packets for periodic packet transmission such as VoIP).133 TR 25.9. As completely releasing dedicated channels during periods of temporary traffic inactivity would cause considerable delays for re-establishing data transmission and a corresponding bad user perception.6 Extended WCDMA Cell Range UID_7030 Resources: R3 References Document RP-060212 TS 25. Protocol specification UTRAN Iur interface Radio Network Subsystem Application Part (RNSAP) signalling UTRAN Iub interface Node B Application Part (NBAP) signalling User Equipment (UE) radio transmission and reception (FDD) Requirements for support of radio resource management (FDD) New Dedicated Specifications/Reports Continuous connectivity for packet data users Packet-oriented features like HSDPA and E-DCH in WCDMA/UMTS systems will promote the subscribers’ desire for continuous connectivity. Completed at Mar 2007.423 TS 25. The corresponding overhead in the noise rise caused by maintained control channels will significantly limit the number of users that can be efficiently supported.93 Overview of 3GPP Release 7 V0. The objective is to reduce the overhead of physical control channels or related signalling messages of packet data users for both real-time (e. To support a high number of HSDPA users in the code limited downlink the feature F-DPCH was introduced in Rel-6. Stage 2 Medium Access Control (MAC) protocol specification Radio Resource Control (RRC).g. Overall description.433 Title/Contents WID(s) WID on Extended WCDMA Cell Range Impacted Specifications Requirements for support of radio resource management (FDD) Radio Resource Control (RRC) protocol specification UTRAN Iur interface Radio Network Subsystem Application Part (RNSAP) signalling UTRAN Iur interface user plane protocols for Common Transport Channel data streams UTRAN Iub interface Node B Application Part (NBAP) signalling 3GPP . To support these features. for users which have temporarily no data transmission in either uplink or downlink. e.g.212 TS 25.g. HS-SCCH orders: L1 command to activate/deactivate DTX and/or DRX at the UE.423 TS 25. Status Report in RP-070033 15.433 TS 25.308 TS 25.3.211 TS 25.101 TS 25.10 (2010-06) References Document RP-050870 TS 25. For such a high number of users in the cell it can be assumed that many users are not transmitting any user data for some time (e. Focus is on the uplink. but reduction of overhead in downlink is considered as well. two features were introduced. Packet data users as considered here are using only HS-DSCH/E-DCH channels without UL DPDCH and DL DPCH. As for physical layer aspects for Continuous Packet Connectivity (CPC) feature.general description Physical channels and mapping of transport channels onto physical channels (FDD) Multiplexing and channel coding (FDD) Physical layer procedures (FDD) High Speed Downlink Packet Access (HSDPA).

On the Iub interface a new Extended Propagation Delay IE was introduced which optionally complements the previously existing Propagation Delay IE. whenever Extended Propagation Delay IE is present.433 TR 25. Completed Dec 2006. The introduced range 0.427 TS 25. Measurements (TDD) Services provided by the physical layer UE Radio Access capabilities Enhanced uplink. UTRAN performance requirements for PRACH propagation delay and RTT measurements in the extended reporting ranges were specified. i.10 (2010-06) UTRAN Iub interface user plane protocols for Common Transport Channel data streams UTRAN Iupc interface Positioning Calculation Application Part (PCAP) signalling New Dedicated Specifications/Reports - Before Re-7.3.223 TS 25. ± 0. Protocol specification UTRAN overall description UTRAN Iur interface general aspects and principles UTRAN Iur interface Radio Network Subsystem Application Part (RNSAP) signalling UTRAN Iur/Iub interface user plane protocol for DCH data streams UTRAN Iub Interface: general aspects and principles UTRAN Iub interface Node B Application Part (NBAP) signalling Iub/Iur congestion control UTRAN functions.7 7.401 TS 25. Status Report in RP-060685 15. the Propagation Delay IE shall be set to its maximum value to provide best approximate value for legacy systems.453 None Overview of 3GPP Release 7 V0. The range of the new Extended Propagation Delay IE is selected to allow for cell radius of at least 180 km and this requires 10bits in the CCH RACH frame protocol. The new Extended Round Trip Time IE is a new choice when reporting measurements.331 TS 25.931 TS 25.225 TS 25.902 TR 25.68Mcps Time Division Duplex (TDD) option .3069 chips corresponds to 240 km.423 TS 25. The accuracy requirements for extended RTT and PRACH propagation delay were kept the same as before.5 chip and 2 chips respectively. However. no new requirements for the UE were added.430 TS 25.e. Extended WCDMA Cell Range works with legacy terminals. in the RADIO LINK SETUP REQUEST.68 Mcps TDD Enhanced Uplink UID_7031 Resources: R1 References Document RP-060119 TS 25.9.321 TS 25. As scenarios were identified which require larger WCDMA cell sizes. The range that could be reported for PRACH propagation delay was around 60 km and the range for Round Trip Time (RTT) measurements in the Node B was around 68 km.general description 7.105 TS 25. Overall description.94 TS 25.142 None Title/Contents WID(s) WID on 7.102 TS 25.302 TS 25.202 TS 25.420 TS 25.222 TS 25. Overall description: Stage 2 Physical channels and mapping of transport channels onto physical channels (TDD) Multiplexing and channel coding (TDD) Spreading and modulation (TDD) Physical layer procedures (TDD) Physical layer.221 TS 25. RADIO LINK ACTIVATION and UPLINK SIGNALLING TRANSFER messages. These two values are specified for cell ranges up to 180 km while the signalling allows cell sizes up to 240 km. by messages DEDICATED MEASUREMENT INITIATION RESPONSE and DEDICATED MEASUREMENT REPORT.319 TS 25.435 TS 25.224 TS 25. it was decided to remove these restrictions in Rel-7 and to allow extended WCDMA cell ranges as exist today in GSM (120 km for extended range GSM cells).306 TS 25. signalling in the UTRAN protocols did not allow cell ranges higher than around 60 km.201 TS 25.68 Mcps TDD Enhanced Uplink Impacted Specifications Physical layer . For Protocol Compatibility. examples on signalling procedures User Equipment (UE) radio transmission and reception (TDD)" Base Station (BS) radio transmission and reception (TDD) Base Station (BS) conformance testing (TDD) New Dedicated Specifications/Reports - 3GPP . Stage 2 Medium Access Control (MAC) protocol specification Radio Resource Control (RRC).

8 Enhanced CELL_FACH State in FDD UID_330009 Resources: R2 References Document RP-070245 TR 25.308 TS 25.423 TS 25. e. Cell_FACH.9.3.815 TS 25.68 Mcps TDD option are limited to those provided by Rel-6. the Enhanced Uplink feature or HSUPA is also required for the 7.331 TS 25. which determine the degree of satisfaction of a user of a service. URA_PCH States).321 TS 25. this also allows mobiles to remain in the Cell_FACH state longer (i. This is expected to provide the natural uplink complement to 7.95 Overview of 3GPP Release 7 V0. As a consequence.68Mcps. Procedures for 3. Overall description. This is achieved by applying HSDPA (HS-DSCH channels) to Signalling Radio Bearers (SRBs) (without re-use of uplink feedback and specific physical channel DP-CCH.423 TS 25.433 TS 25.84Mcps E-DCH can be almost entirely reused at 7.425 TS 25. CellPCH. In a modern telecommunication network such as UMTS. from all States towards the Cell_DCH State. It improves (i. Completed Dec 2006. Protocol specification UTRAN Iur interface Radio Network Subsystem Application Part (RNSAP) signalling UTRAN Iur interface Radio Network Subsystem Application(RNSAP) signalling UTRAN Iur interface user plane protocols for Common Transport Channel data streams UTRAN Iub interface Node B Application Part (NBAP) signalling UTRAN Iub interface user plane protocols for Common Transport Channel data streams New Dedicated Specifications/Reports - This builds upon the enhancements done by the Work Item UID_340039 (Improved L2 support for high data rates) due to common Layer 2 architecture. the aim of the operator is to offer high Quality of Service (QoS) to users. for CS and PS. reduces) the delay in setup and channel allocation.435 None Title/Contents WID(s) WID on Enhanced CELL_FACH State in FDD Impacted Specifications Signalling enhancements for Circuit-Switched (CS) and Packet-Switched (PS) Connections. and hence allows power consumption saving.10 (2010-06) As features available with the 7. Stage 2 Medium Access Control (MAC) protocol specification Radio Resource Control (RRC).68Mcps HSDPA and also to provide double the peak uplink user data rate with respect to 3. without closed loop power control).e.84 Mcps TDD. Other gains provided: • • Possibility to increase available downlink peak rates in all states other than Cell_DCH (i.304 TS 25.211 TS 25.e.g. 3GPP . idle. Reduce state transitions delays. The only substantive changes identified are that the channelization code hopping sequences would need to be extended to accommodate SF32 and that the SFdependent power gain factors would need to be amended to accommodate SF32. Under the general heading of quality of experience (QoE) one of the more noticeable points faced by the user is the apparent delay in set up or channel allocation times for different connections including response times of different PS data connections.306 TS 25. The QoS is the collective effect of service performances.e. Analyses and recommendations Physical channels and mapping of transport channels onto physical channels (FDD) User Equipment (UE) procedures in idle mode and procedures for cell reselection in connected mode UE Radio Access capabilities High Speed Downlink Packet Access (HSDPA). Status Report in RP-060684 15.68 Mcps TDD option. without transiting to "more dedicated" states).

this work considered the enhancements provided by Continuous Packet Connectivity (CPC).212 TS 25. by utilising HSDPA in CELL_FACH state.96 Overview of 3GPP Release 7 V0.425 TS 25. This could be due to high interest on "always on" type services like PoC. CELL_PCH and URA_PCH state to CELL_DCH state Allowing lower UE power consumption in CELL_FACH state by discontinuous reception In addition. e. Status Report in RP-070287 3GPP .211 TS 25. e.3. Reducing the latency of user and control plane in the CELL_FACH.9 64QAM for HSDPA (FDD) UID_340038 Resources: R1 References Document RP-070223 TS 25. the work considered how the data rates available in CELL_FACH can be increased to reduce signalling latencies as well as address the cases where the usage of CELL_DCH state is not preferred by the network.815 shows that setup delays on PS and also CS domain can significantly be reduced by using HSPA for SRBs. in scenarios where deployment of MIMO is not possible. Completed May 2007. Status Report in RP-070286 15.308 TS 25.104 TS 25. The target is to reduce UTRAN latencies and concentrate on how the HSPA resources can be activated for the UE in the most efficient manner. to achieve best suited solutions in the areas they may overlap.141 None Title/Contents WID(s) WID on 64QAM for HSDPA (FDD) Impacted Specifications UE Radio Access capabilities Physical channels and mapping of transport channels onto physical channels (FDD) Multiplexing and channel coding (FDD) Spreading and modulation (FDD) UE Radio Access capabilities Radio Resource Control (RRC). the use of HSDPA in CELL_FACH state was investigated to obtain smaller signalling delays and higher bit rate in CELL_FACH state.331 TS 25.101 TS 25.10 (2010-06) TR 25.9.g. In light of continuous progress to packet optimised radio together with Node B based scheduling.306 TS 25. Push email and VPN connections.423 TS 25. Protocol specification UTRAN Iub interface Node B Application Part (NBAP) signalling UTRAN Iub interface user plane protocols for Common Transport Channel data streams UTRAN Iur interface Radio Network Subsystem Application Part (RNSAP) signalling UTRAN Iur interface user plane protocols for Common Transport Channel data streams User Equipment (UE) radio transmission and reception (FDD Base Station (BS) radio transmission and reception (FDD) Base Station (BS) conformance testing (FDD) New Dedicated Specifications/Reports - The use of 64QAM in the downlink is an attractive complement to multi-antenna techniques (MIMO) in the downlink. This work provides the necessary modifications to Rel-7 improving the CELL_FACH state by: • • • • Increasing the available peak rate for UEs in CELL_FACH state. Completed May 2007.435 TS 25.213 TS 25. CELL_PCH and URA_PCH state by higher data peak rate Reducing state transition delay from CELL_FACH. In addition. It adds 64QAM support as a downlink modulation scheme for HSDPA in FDD for Type II/III UEs.433 TS 25.g. which introduce frequent but small packets to be transmitted between UE and server. Significant gains were observed by the provision of 64QAM in scenarios (cells with isolation) where users can benefit in terms of increased throughput from favourable radio conditions such as in well tuned outdoor systems or indoor system solutions.

in order to support higher data rates. As changes to the link layer protocols are already needed for the introduction of the MIMO. it would be beneficial to incorporate future-proof solutions already in Rel-7 to support high data rates in the link layer protocols.999 None Title/Contents WID(s) WID on Improved L2 support for high data rates Impacted Specifications Radio interface protocol architecture High Speed Downlink Packet Access (HSDPA). MAC-hs multiplexing and segmentation. the RLC protocol can not sustain the current peak data rate of the physical layer in HS-DSCH. the methods to enhance transition between old and new PDU formats had been evaluated. It optimizes the Radio Link Control (RLC) layer. The introduction of MIMO significantly increases the data rates of the HSDPA and other improvements. For reasonable RLC PDU sizes. Evaluate the necessity to support MAC-d multiplexing and RLC concatenation. such as higher order modulation targeted for HSPA evolution to further increase the DL data rates.999 it is proposed to introduce support for flexible RLC PDU sizes and MAC segmentation in downlink in order to reach high data rates and reduce protocol overhead and padding. 64QAM for HSDPA (FDD) and Enhanced CELL_FACH state in FDD.331 TS 25. Medium Access Control (MAC) segmentation. in TR 25. Frequency Division Duplex (FDD) New Dedicated Specifications/Reports - This Work Item is in fact a baseline feature for other Work Items such as MIMO. For increased data rates achieved by MIMO and other improvements. leading to a situation.435 TS 25.3. Completed May 2007.10 Improved L2 support for high data rates UID_340039 Resources: R2 References Document RP-070242 TS 25. In order to facilitate easy deployment of the enhanced protocols. This is achieved through flexible RLC sizes. and the multiplexing of different priority schemes (direct multiplexing of logical channels in the MAC header) in the downlink. Allow smooth transition between old and new protocol formats.306 TS 25. It provides the necessary modifications in order to: • • • • Allow link layer support for high data rates in downlink by introducing support for flexible RLC PDU sizes. It is known from the work on HSDPA that the RLC peak data rate is limited by the RLC PDU size.423 TS 25. Overall description UE Radio Access capabilities Medium Access Control (MAC) protocol specification Radio Link Control (RLC) protocol specification Radio Resource Control (RRC). Therefore.9.433 TS 25.425 TR 25. the RTT and the RLC window size. Status Report in RP-070289 3GPP .308 TS 25. Protocol specification UTRAN Iub interface Node B Application Part (NBAP) signalling UTRAN Iub interface user plane protocols for Common Transport Channel data streams UTRAN Iur interface Radio Network Subsystem Application Part (RNSAP) signalling UTRAN Iur interface user plane protocols for Common Transport Channel data streams High Speed Packet Access (HSPA) evolution.322 TS 25. as well as backward compatibility. The reason was that the RLC peak data rate was limited by the RLC Packet Data Unit (PDU) size. The link layer support for high data rates in the uplink may be provided in the future. it is likely that the limitations of the RLC are even more pronounced. the round trip time (RTT) and the RLC window size (creating a situation where under some scenarios the RLC protocol was the bottleneck of the system). such as 320 or 640 bit. in which the RLC protocol is the bottleneck of the system.10 (2010-06) 15.321 TS 25. It is itself built upon HSDPA (use of the HS-DSCH channels).301 TS 25. Provide a single L2 protocol evolution for all performance enhancements.97 Overview of 3GPP Release 7 V0.

213 TS 25.466 UTRAN Iuant interface: Application part Before the introduction of this feature the control of TMAs was only possible by means of proprietary interfaces between Node B and Operator's O&M System. Telecommunication management. Significant gains in terms of throughput were observed by the provision of 16QAM in scenarios (cells with isolation) where users can benefit from favourable radio conditions such as in well tuned outdoor systems or indoor system solutions.3.463 TS 32.11 Introduction of 16QAM in HSUPA (FDD) UID_340040 Resources: R2 References Document RP-060844 TS 25. UTRAN network resources Integration Reference Point (IRP): Network Resource Model (NRM) Telecommunication management.319 TS 25.10 (2010-06) 15.9. UTRAN network resources Integration Reference Point (IRP): Bulk CM eXtensible Markup Language (XML) file format definition New Dedicated Specifications/Reports TS 25.401 TS 25.331 TS 25.141 TS 25.462 TS 25. UTRAN network resources Integration Reference Point (IRP): Common Object Request Broker Architecture (CORBA) Solution Set (SS) Telecommunication management.98 Overview of 3GPP Release 7 V0.3.460 TS 25.S5 References Document RP-060418 TS 25. providing the users also with increased uplink data rates.642 TS 32.211 TS 25.461 TS 25.306 TS 25.645 Title/Contents WID(s) WID on Interface to control Tower mounted amplifiers Impacted Specifications UTRAN Overall Description UTRAN Iuant interface: General aspects and principles UTRAN Iuant Interface: Layer 1 UTRAN Iuant interface: Signalling transport UTRAN Iuant Interface: Remote Electrical Tilting (RET) antennas Application Part (RETAP) signalling Configuration Management (CM). Status Report in RP-070288 15.12 Interface to control Tower Mounted Amplifiers (TMAs) UID_20066 Resources: R3. the introduction of 16QAM in the uplink is an attractive addition to the enhanced uplink concept.321 TS 25. Protocol specification UTRAN Iur interface Radio Network Subsystem Application Part (RNSAP) signalling UTRAN Iub interface Node B Application Part (NBAP) signalling New Dedicated Specifications/Reports - With the introduction of MIMO or 64QAM in the downlink.643 TS 32. Configuration Management (CM). It specifies the support of 16QAM as a uplink modulation scheme for HSUPA in FDD Completed May 2007. To match the increased downlink throughput.133 TS 25.104 TS 25.433 None Title/Contents WID(s) WID on Introduction of 16QAM in HSUPA (FDD) Impacted Specifications Enhanced uplink. Stage 2 User Equipment (UE) radio transmission and reception (FDD) Base Station (BS) radio transmission and reception (FDD) Requirements for support of radio resource management (FDD) Base Station (BS) conformance testing (FDD) Physical channels and mapping of transport channels onto physical channels (FDD) Multiplexing and channel coding (FDD) Spreading and modulation (FDD) Physical layer procedures (FDD) UE Radio Access capabilities Medium Access Control (MAC) protocol specification Radio Resource Control (RRC).214 TS 25. Configuration Management (CM).212 TS 25. Overall description.101 TS 25.423 TS 25. higher data rates can be provided for users in favourable conditions. 3GPP .

3 Conformance Test Aspects – 16QAM for HSUPA (FDD) UID_25032 UID 2503 2 Name Conformance Test Aspects – 16QAM for HSUPA (FDD) Acronym RANimp-UEConTest_16QamUplink WID RP070022 SR RP080281 Notes SR in RP080281.68 Mcps TDD Enhanced Uplink Acronym RANimp-UEConTest_EDCHTDH WID RP060484 SR RP080536 Notes SR in RP080536. 34. 34.4.3.108.68 Mcps TDD Enhanced Uplink UID_25021 UID 2502 1 Name Conformance Test Aspects 3.2 Conformance Test Aspects – 64QAM for HSDPA (FDD UID_25031 UID 2503 1 Name Conformance Test Aspects – 64QAM for HSDPA (FDD) Acronym RANimp-UEConTest_64QamDownlink WID RP071319 SR RP080059 Notes SR in RP080059.4. These specifications were updated with the TMA functionality according to the table above. 34.123-1.108. 34.122.460.121-2. 34.1233 3GPP .9. RP#41 completed TSs_TRs 34. 34. Completed Mar 2007. 25. except for the Application Part signalling. 25.84 Mcps and 7. 25.121-2. 25.466 describing both Applications. 34.4. Status Report in RP-070140 15.461.4.1232. As a consequence. 34.4 RAN improvements .4 Conformance Test Aspects – Improved L2 support for high data rates UID_25033 UID 2503 3 Name Conformance Test Aspects – Improved L2 support for high data rates Acronym RANimp-UEConTest_L2DataRates WID RP070020 SR RP080256 Notes SR in RP080256.108. 34.UE Conformance Testing UID_25026 Resources: R5 Linked to Feature UID_20029 (RANimp) 15. a standardized interface was required to save Operator's costs for site visits and to enable Operators to independently choose Vendors of Node B and TMA equipment. RP#40 completed TSs_TRs 34.463 was closed (i. 34. Furthermore. a common set of parameters and commands in a multi-vendor network allows the Operator to perform network optimization from the Network Element Manager over the Ift-N interface. 34. 34.123-3 15.1 Conformance Test Aspects . RET and TMA. TSs_TRs 34. RP#39 completed.108.123-2.123-3 15. 34. 34.123-1.123-1.84 Mcps and 7. RP#40 completed TSs_TRs 34. no further Rel-7 maintenance) and replaced by the new 25.123-2. 34. 34. 34.99 Overview of 3GPP Release 7 V0.123-1.123-3 15.463).121-1.e.462.121-1.123-2.10 (2010-06) As a result Operators could not mix equipment from different Node B and TMA Vendors. To control TMAs the existing Iuant interface introduced in Rel-6 for "Remote Electrical Tilting Antennas" was re-used (25.

223 TS 25.306 TS 25.108.123 TS 25.121-1.302 TS 25. 34.423 TS 25.453 TS 25.425 TS 25. 34.4. 34.321 TS 25.6 Conformance Test Aspects – Enhanced CELL_FACH state in FDD UID_25035 UID 2503 5 Name Conformance Test Aspects – Enhanced CELL_FACH state in FDD Acronym RANimp– UEConTest_EnhancedCellFACHState WID RP080730 SR RP090711 Notes RP#45 completed TSs_TRs 34. 34.433 TR 25. Nevertheless.121-2.68Mcps TDD option is an evolution of the 3.9. Protocol specification UTRAN overall description Synchronization in UTRAN Stage 2 UTRAN Iur interface Radio Network Subsystem Application Part (RNSAP) signalling UTRAN Iur interface user plane protocols for Common Transport Channel data streams UTRAN Iur/Iub interface user plane protocol for DCH data streams UTRAN Iub interface Node B Application Part (NBAP) signalling UTRAN Iub interface user plane protocols for Common Transport Channel data streams UTRAN Iupc interface Positioning Calculation Application Part (PCAP) signalling User Equipment (UE) radio transmission and reception (TDD) Base Station (BS) radio transmission and reception (TDD) Requirements for support of radio resource management (TDD) Base Station (BS) conformance testing (TDD) Electromagnetic compatibility (EMC) requirements for mobile terminals and ancillary equipment New Dedicated Specifications/Reports 7.124 TS 25.68 Mcps TDD Enhanced Uplink Impacted Specifications Physical layer .202 Title/Contents WID(s) WID on 7.4.68 Mcps TDD option UID_20014 Resources: RP References Document RP-060119 TS 25.201 TS 25. There exists a great degree of commonality between the 3.225 TS 25. Measurements (TDD) Radio interface protocol architecture Services provided by the physical layer User Equipment (UE) procedures in idle mode and procedures for cell reselection in connected mode User Equipment (UE) positioning in Universal Terrestrial Radio Access Network (UTRAN).401 TS 25.84Mcps TDD option to a higher chip rate.5 7. there are many aspects of the 7. 34.84Mcps TDD option and the 7.123-2.68Mcps Time Division Duplex (TDD) option .10 (2010-06) 15. 34.68Mcps TDD option.123-1.435 TR 25.224 TS25.100 Overview of 3GPP Release 7 V0.105 TS 25. Overall description: Stage 2 The 7.427 TS 25.402 TS 25.221 TS 25. RP#40 completed TSs_TRs 34.123-3 15.108. 3GPP .331 TS 25.68Mcps TDD option that require separate specification.123-3 15. Stage 2 UE Radio Access capabilities Medium Access Control (MAC) protocol specification Radio Resource Control (RRC).304 TS 25.222 TS 25.305 TS 25. 34.123-1.142 TS 34. 34.301 TS 25.102 TS 25.123-2.5 Conformance Test Aspects – Continuous connectivity for packet data users UID_25034 UID 2503 4 Name Conformance Test Aspects – Continuous connectivity for packet data users Acronym RANimp-UEConTest_CPC WID RP070023 SR RP080282 Notes SR in RP080282.general description Physical channels and mapping of transport channels onto physical channels (TDD) Multiplexing and channel coding (TDD) Spreading and modulation (TDD) Physical layer procedures (TDD) Physical layer.

Completed Dec 2006. Protocol specification UTRAN overall description UTRAN Iur interface general aspects and principles UTRAN Iur interface Radio Network Subsystem Application Part (RNSAP) signalling UTRAN Iur/Iub interface user plane protocol for DCH data streams UTRAN Iub Interface: general aspects and principles UTRAN Iub interface Node B Application Part (NBAP) signalling UTRAN Iub interface user plane protocols for Common Transport Channel data streams User Equipment (UE) radio transmission and reception (TDD) Base Station (BS) radio transmission and reception (TDD) Requirements for support of radio resource management (TDD) Base Station (BS) conformance testing (TDD) New Dedicated Specifications/Reports - 3GPP .84Mcps. L2/BMC.68 * 106 = 130.10 (2010-06) As for physical layer structure.102 TS 25.68Mcps is twice that at 3.84 Mcps TDD Enhanced Uplink Impacted Specifications Physical layer .68Mcps TDD and 3.223 TS 25.123 TS 25. Physical layer procedures such as power control. The frame structure is shown in Figure 5. HSPDA transport block size signalling.420 TS 25. where Tc is the chip duration (Tc = 1 / 7.201 TS 25.84 Mcps TDD).68 Mcps TDD and 3.68 Mcps TDD mode are based on the 3.331 TS 25. UE capabilities for the 7.306 TS 25. as for layer 2/3 protocol aspects.68 Mcps TDD is the same as the protocol architecture for 3.142 None Title/Contents WID(s) WID on 3. The capabilities for 7. Tx and Rx characteristics for both of UE and BS are updated. HSDPA procedures. Status Report in RP-060684 15.401 TS 25.68Mcps TDD account for the higher number of physical channels supported and additionally support higher peak bit rates.84 Mcps TDD concern L2/MAC and L3/RRC only. and so on are aligned with that of 3.101 Overview of 3GPP Release 7 V0.68Mcps TDD option frame is of length 10ms and consists of 15 timeslots of duration 5120 * Tc.435 TS 25.4Mbps). the protocol architecture for 7.68Mcps (20. The minimum MBMS capability at 7.84 Mcps TDD Enhanced Uplink UID_20035 Resources: RP References Document RP-050100 TS 25. Next.84Mcps. Any timeslot in the frame can be either uplink or downlink. there are some impact on signalling. The L2/MAC differences between 7.general description Physical channels and mapping of transport channels onto physical channels (TDD) Multiplexing and channel coding (TDD) Spreading and modulation (TDD) Physical layer procedures (TDD) Physical layer. The L2/MAC differences concern: the maximum number of PDUs transmitted in a single TTI (636 at 7.221 TS 25.2ns).84 Mcps TDD.224 TS 25. synchronisation procedures.4-1. The differences between 7.430 TS 25. Measurements (TDD) Radio interface protocol architecture Services provided by the physical layer UE Radio Access capabilities Medium Access Control (MAC) protocol specification Radio Resource Control (RRC). Spurious response and so on.105 TS 25. At least one timeslot in the frame is assigned to the uplink and at least one timeslot in the frame is assigned to the downlink. RACH procedures. the 7.302 TS 25. Adjacent Channel Leakage power (ACLR).84Mcps TDD.68Mcps compared to 318 for3. The maximum transport block size that can be signalled at 7. such as Spectrum Emission Mask.301 TS 25.6 3. L2/RLC.225 TS 25.84 Mcps TDD. Adjacent Channel Selectivity (ACS). Regarding Radio aspects.68Mcps is twice the minimum capability at 3.84Mcps TDD are due to the support of a higher capability HSDPA UE at 7.222 TS 25.321 TS 25. L2/PDCP and L3 U-plane information are not impacted. timing advance.9.433 TS 25.427 TS 25.423 TS 25.

Incorporation of Node-B controlled rate.102 Overview of 3GPP Release 7 V0.10 (2010-06) The target was uplink enhancement techniques to increase the coverage and throughput and reduce the delay of the uplink for packet-based services. Status Report in RP-060462 3GPP .and physical resource scheduling. hybrid ARQ. − For radio interface physical layer: − Physical and Transport Channels mapping − Multiplexing and Channel Coding − Physical Layer procedures − Physical layer measurements − UE physical layer capabilities For radio interface higher RAN layers: − Architecture aspects − MAC entity (Scheduling and hybrid ARQ protocol) − Interlayer interactions in connected mode − Control plane protocols − User plane protocols − UE capabilities For Iur/Iub interface: − Control plane protocols − User plane protocols For radio transmission and reception: − UE radio transmission and reception − Base Station radio transmission and reception − Base Station conformance testing − Requirements for support of Radio Resource Management − − − Completed Sep 2006. and support for higher-order modulation deliver significant performance improvement with manageable complexity whilst maintaining backwards compatibility.9.

123 TS 25.105 TS 25.102 TS 25.433 TS 25.435 TS 25.420 TS 25.223 TS 25.423 TS 25.224 TS 25.425 TS 25.9. Measurements (TDD) Radio interface protocol architecture Services provided by the physical layer UE Radio Access capabilities Medium Access Control (MAC) protocol specification Radio Resource Control (RRC).401 TS 25. − For radio interface physical layer: − Physical and Transport Channels mapping − Multiplexing and Channel Coding − Spreading and modulation − Physical Layer procedures − Physical layer measurements − UE physical layer capabilities For radio interface higher RAN layers: − Architecture aspects − MAC entity (Scheduling and hybrid ARQ protocol) − Interlayer interactions in connected mode − Control plane protocols − User plane protocols − UE capabilities For Iur/Iub interface: − Control plane protocols − User plane protocols For radio transmission and reception: − UE radio transmission and reception − Base Station radio transmission and reception − − − 3GPP .222 TS 25.321 TS 25.221 TS 25.430 TS 25.28 Mcps TDD Enhanced Uplink Impacted Specifications Physical layer .331 TS 25.10 (2010-06) 15.201 TS 25.225 TS 25.427 TS 25.general description Physical channels and mapping of transport channels onto physical channels (TDD) Multiplexing and channel coding (TDD) Spreading and modulation (TDD) Physical layer procedures (TDD) Physical layer.306 TS 25. hybrid ARQ.28 Mcps TDD Enhanced Uplink UID_20055 Resources: RP References Document RP-060202 TS 25.301 TS 25. Incorporation of Node-B controlled rate.142 None Title/Contents WID(s) WID on 1. and support for higher-order modulation deliver significant performance improvement with manageable complexity whilst maintaining backwards compatibility. Protocol specification UTRAN overall description UTRAN Iur interface general aspects and principles UTRAN Iur interface Radio Network Subsystem Application Part (RNSAP) signalling UTRAN Iur interface user plane protocols for Common Transport Channel data streams UTRAN Iur/Iub interface user plane protocol for DCH data streams UTRAN Iub Interface: general aspects and principles UTRAN Iub interface Node B Application Part (NBAP) signalling UTRAN Iub interface user plane protocols for Common Transport Channel data streams User Equipment (UE) radio transmission and reception (TDD) Base Station (BS) radio transmission and reception (TDD) Requirements for support of radio resource management (TDD) Base Station (BS) conformance testing (TDD) New Dedicated Specifications/Reports - The target was uplink enhancement techniques to increase the coverage and throughput and reduce the delay of the uplink for packet-based services.103 Overview of 3GPP Release 7 V0.7 1.302 TS 25.and physical resource scheduling.

28 Mcps TDD Enhanced Uplink .108 TS 34. RAN#41 completed.122 TS 34.104 Overview of 3GPP Release 7 V0.1 1.28Mcps TDD Enhanced Uplink Impacted Specifications Common test environments for User Equipment (UE) conformance testing Terminal Conformance Specification. Status Report in RP-080539. 3GPP .UE Conformance Testing UID_350146 Resources: R5 References Document RP-060202 TS 34.1. Status Report in RP-070038 and RP-070296 15.7.123-1/2/3 None Title/Contents WID(s) WID on UE conformance test aspects .10 (2010-06) − − Base Station conformance testing Requirements for support of Radio Resource Management Completed May 2007. Radio Transmission and Reception (FDD) User Equipment (UE) conformance specification New Dedicated Specifications/Reports - Linked to Feature UID_20055 (LCRTDD-EDCH).9.

021 - Title/Contents WID(s) WID on Lower 700 MHz Inclusion in the GERAN Specifications Impacted Specifications Mobile radio interface Layer 3 specification.118 TS 45.2 Lower 700 MHz Inclusion in the GERAN specifications (GSM710) UID_50119 Resources: GP References Document GP-050543 TS 24. 16.022 TS 44.R4 References Document GP 050284 TS 45. 2G MS. 3GPP . General description Radio transmission and reception Mobile Station (MS) conformance specification Base Station System (BSS) equipment specification. Stage 3 Functions related to Mobile Station (MS) in idle mode and group receive mode Mobile radio interface layer 3 specification.144 Title/Contents WID(s) WID on MS Antenna Performance Evaluation Method and Requirements Impacted Specifications Radio transmission and reception New Dedicated Specifications/Reports Measurements of radio performances for UMTS terminals in speech mode User Equipment (UE) and Mobile Station (MS) over the air performance requirements COST273 has finalized the specification of a method for measurement of radiated output power and radiated sensitivity.018 TS 44. Radio aspects New Dedicated Specifications/Reports None This work included the 698-746 MHz band in the GERAN test specifications. Iu mode Physical layer on the radio path.914 TS 25.001 TS 45.005 TR 25.1 MS Antenna Performance Evaluation Method and Requirements (APEMR) UID_50118 Resources: G1.010 TS 51. MS/UE antenna performance has a critical impact on coverage and capacity.10 (2010-06) 16 GERAN Features 16.005 TS 51. Radio Resource Control (RRC) protocol. Radio Resource Control (RRC) protocol Mobile radio interface layer 3 specification.105 Overview of 3GPP Release 7 V0. as well as dual-mode 2G/3G MS/UE antennas for the "speech mode" (MS/UE close to the head).008 TS 43.9. Future envisaged steps will cover the "data mode" and diversity antenna MS/UE. To enable for operators to plan their networks in a systematic manner. Core network protocols. a method for MS/UE antenna performance evaluation and MS/UE antenna minimal performance requirements are needed. ensuring a certain coverage and QoS for their customers. This method is applicable both to 3G UE.

10 (2010-06) 16. The current functional split of the protocol architecture between core and radio access network is maintained.005 TS 45.010 TS 51. impact of DTX. Stage 2 General Packet Radio Service (GPRS). optimisation of IP header adaptation. Define radio resource management functionalities in order to efficiently support Conversational Services like VoIP in the PS domain in A/Gb mode.3 Support of Conversational Services in A/Gb mode via the PS domain (SCSAGB) UID_50564 Resources: GP References Document GP-061501 TS 43.106 Overview of 3GPP Release 7 V0. Issues like radio resource sharing. General description Multiplexing and multiple access on the radio path Channel coding Radio transmission and reception Radio subsystem synchronization Mobile Station (MS) conformance specification GSM radio aspects base station system equipment specification New Dedicated Specifications/Reports None Packet-switched Handover for GERAN A/Gb mode is a prerequisite for supporting conversational services. Improve the feedback reporting mechanism. which today are not possible in GERAN A/Gb mode through the PS domain. modifications to LLC/SNDCP protocol headers).g. This work makes possible to: • • • • • • Minimise the transfer delay between the SGSN and the MS.9. Stage 3 extended the Non-Persistent RLC mode to non-MBMS services.001 TS 45.060 TS 45. Stage 3 defines the modification of radio resource management functionalities in order to efficiently support Conversational Services in A/Gb mode via the PS domain. It introduces support for conversational services with minimum impact to existing systems. For instance. the conversational services would need a reduced transfer delay and a fast acknowledgement procedure over the radio interface. Define a suitable RLC mode allowing retransmissions for delay-sensitive applications.Base Station System (BSS) interface. Stage 2 Overall description of the GPRS radio interface.055 TS 43. To support conversational services in the PS domain in A/Gb mode there is a need to optimise various aspects of the GERAN packet service.002 TS 45. support of dedicated channels).010 TS 51.021 - Title/Contents WID(s) WID on Support of Conversational Services in A/Gb mode via the PS domain Impacted Specifications Dual Transfer Mode (DTM). Mobile Station (MS) .003 TS 45. 3GPP .064 TS 44. Optimise radio channel support for conversational QoS (e. Minimise the protocol overhead on the user plane (e. Radio Link Control/ Medium Access Control (RLC/MAC) protocol Physical layer on the radio path. radio performance in case of different AMR modes and impact of RoHC re-initialization are taken into account.g.

g. Radio Link Control/ Medium Access Control (RLC/MAC) protocol Physical layer on the radio path.005 TS 45.010 TS 51.4 Addition of new frequency band to GSM (TGSM810) UID_50565 Resources: GP References Document GP-050945 TS 24. Mobile Station (MS) .008 TS 43.021 - Title/Contents WID(s) WID on Addition of new frequency band to GSM (T-GSM810) Impacted Specifications Mobile radio interface Layer 3 specification. 851 MHz to 866 MHz: base transmit.018 TS 44. Radio Resource Control (RRC) protocol General Packet Radio Service (GPRS).Base Station System (BSS) interface. However.050 TS 51. base receive. It is thus necessary to minimize the PS service interruption at handover in DTM to enable the deployment of any realtime PS service also in DTM and ensure service continuity with UTRAN. Radio Link Control/ Medium Access Control (RLC/MAC) protocol New Dedicated Specifications/Reports None Dual Transfer Mode (DTM) enhancements for reduction of the PS service interruption in DTM were completed in Release 6 and focused on improving both the release of the RR connection while in dual transfer mode and the initiation of the RR connection while in packet transfer mode.107 Overview of 3GPP Release 7 V0.5 Handover of dedicated and shared resources while in dual transfer mode (HODSRDTM) UID_50567 Resources: GP References Document GP-050979 TS 43. Radio Resource Control (RRC) protocol General Packet Radio Service (GPRS).9.10 (2010-06) 16. Stage 2 Mobile radio interface layer 3 specification. Stage 3 Functions related to Mobile Station (MS) in idle mode and group receive mode Radio network planning aspects Mobile radio interface layer 3 specification. service continuity must also be ensured between UTRAN and GERAN. While such scenarios are possible in UTRAN.018 TS 44.060 Title/Contents WID(s) WID on Handover of dedicated and shared resources while in dual transfer mode Impacted Specifications Dual Transfer Mode (DTM).060 TS 45.001 TS 45. voice call while gaming.008 TS 45.Base Station System (BSS) interface. General description Radio transmission and reception Radio subsystem link control Radio subsystem synchronization Background for RF Requirements Mobile Station (MS) conformance specification GSM radio aspects base station system equipment specification New Dedicated Specifications/Reports None This work adds a new frequency band to GSM (T-GSM810): • • 806 MHz to 821 MHz: mobile transmit. Core network protocols. Mobile Station (MS) . 16. 3GPP .022 TS 43. voice call while sharing real-time video). the PS service interruption caused by a (CS) handover in DTM prevents real-time PS services with strict delay requirements from being used in DTM (e. mobile receive.055 TS 44.010 TS 45.030 TS 44.

7 Downlink Dual Carrier (GDCDL) UID_50579 Resources: GP References Document GP-061331 TS 24. The introduction of Single Antenna Interference Cancellation (SAIC) characterised by the Downlink Advanced Receiver Performance (DARP) requirements has shown that receiver enhancements in the MS provide significant gains in terms of spectral efficiency.064 TS 44.005 for the Performance requirements and Test Scenarios for MSRD.005 TS 45.055 TS 43. MSRD enhances channel diversity. Radio Link Control / Medium Access Control (RLC/MAC) protocol Physical layer on the radio path. Stage 3 Dual Transfer Mode (DTM). improves interference cancellation performance for GMSK modulated signals and provides significant gains for 8PSK-modulated signals.001 TS 45. Radio Resource Control (RRC) protocol General Packet Radio Service (GPRS).002 TS 45.912 on evolved GSM/EDGE Radio Access Network (FGE) UID_50568. in order to meet QoS requirements for conversational PS services and potentially standardize a solution. No hardware upgrades are required in the network to support this feature. Core network protocols. TS 45.008 TS 43. General description Multiplexing and multiple access on the radio path Radio transmission and reception Radio subsystem link control 3GPP . Mobile Station (MS) .008 TS 45. Since MSRD is a downlink receiver improvement. Overall description of the GPRS radio interface. 16. 16.6 Mobile Station Receive Diversity (DARP Phase II) (MSRD2) UID_50569 Main Resources: GP References Document GP-061491 TS 24. which improves the receiver performance of the MS by means of an additional antenna. Stage 3 Radio transmission and reception Mobile Station (MS) conformance specification. Therefore gains in both user throughput and system capacity can be achieved. MSRD is a downlink feature.108 Overview of 3GPP Release 7 V0. Stage 2 Mobile radio interface layer 3 specification.018 TS 44. TS 51.010 included the MS conformance Tests.9.10 (2010-06) This work evaluates possible solutions for handover of dedicated and shared resources while in DTM. No Mobile Station (MS) and no GSM base station system equipment conformance testing were developed. it may be specified as a DARP phase II in: • • • TS 24.010-1 - Title/Contents WID(s) WID on Mobile Station Receive Diversity (DARP Phase II) Impacted Specifications Mobile radio interface Layer 3 specification. Part 1: Conformance specification New Dedicated Specifications/Reports None The feasibility of MS Receive Diversity (MSRD) has been determined in TR 45.008 WID on Downlink Dual Carrier Title/Contents WID(s) Impacted Specifications Mobile radio interface Layer 3 specification.008 as far as concerns the DARP Phase II capability indication.005 TS 51. Core network protocols.Base Station System (BSS) interface.060 TS 45. Stage 2 General Packet Radio Service (GPRS).

This limitation puts a restriction on the rate of data transfer to one and the same user. General aspects Signalling Transport Mechanism Specification for the Base Station System .MSC) interface. The M3UA and SCTP are used in UTRAN while adopting these protocols in 3GPP . Dual-carrier GERAN gives increased flexibility in how the system throughput is divided among users.1 Downlink Dual Carrier Conformance Testing (GDCDL-Stage3) UID_59579 Resources: G3new References Document GP-060486 TS 51. Layered Architecture and Location Services) require an intermediate signalling network for best performance.9. Base Station System Application Part LCS Extension (BSSAP-LE) New Dedicated Specifications/Reports None Some functions in GERAN (e.001 TS 48. 16. The Signalling Transport (SIGTRAN) based protocols M3UA and SCTP provide these features to low cost at the same time as it is preparing the interfaces for packet transport rather than dedicated circuits as is the case today.6kbps × 2).010 16.010 51. clause 7). Possibility for a dual antenna terminal to switch between dual carrier reception and MS receive diversity is envisaged. This work specifies the support for simultaneous transmissions over two independent carriers in downlink in GERAN. It overcomes one limitation of the GSM radio interface – the 200 kHz carrier bandwidth.g.059 TS 48. Dual-carrier transmission allows for doubling downlink peak and average user throughputs in a flexible and backwards compatible manner.912.031 WID on Support of SIGTRAN in GERAN Title/Contents WID(s) Impacted Specifications Functional stage 2 description of Location Services (LCS) in GERAN Base Station System . the peak data rate would be close to 1Mb/s (473.Mobile-services Switching Centre (BSS .10 (2010-06) New Dedicated Specifications/Reports None The feasibility of dual-carrier in downlink has been determined during the feasibility study for evolved GSM/EDGE Radio Access Network (see 3GPP TR 45.010 - Title/Contents WID(s) WID on Downlink Dual Carrier Impacted Specifications Mobile Station (MS) conformance specification None New Dedicated Specifications/Reports 59579 53086 Downlink Dual Carrier – MS Conformance Test Downlink Dual Carrier – MS Conformance Test GDCDLStage3 GDCDLStage3 04/09/200 9 04/09/200 9 100% 100% GP060486 GP060486 GP#43 completed GP#43 completed 51.006 TS 49.7. It is expected that no hardware upgrades are required in the network to support this feature.109 Overview of 3GPP Release 7 V0.8 Support of SIGTRAN in GERAN (GSIGT) UID_50580 Resources: GP References Document GP-060450 TS 43.Mobile Services Switching Centre (BSS-MSC) Interface Location Services (LCS). MSC in Pool.

Furthermore. Lb. It introduces support for M3UA and SCTP on A-. The functional split of the protocol architecture between core and radio access network is maintained.9. Lb.and Lp-interfaces with a minimum of impacts to existing systems.110 Overview of 3GPP Release 7 V0.10 (2010-06) GERAN will also give synergy effects in the core network. This work provides a concept for supporting M3UA and SCTP on A-. signalling over IP removes the link bandwidth constraints of the E1/T1 links in existing SS7 networks. 3GPP .and Lp-interfaces and defines the stage 3. making possible SS7 signalling over IP transport between the nodes on each side of the concerned interfaces.

conversational services such as VoIP and gaming applications) by utilising efficient RLC re-transmission schemes.111 Overview of 3GPP Release 7 V0.306 TS 24. Radio aspects New Dedicated Specifications/Reports None The feasibility to reduce latency has been determined in TR 45. By reducing latency in the radio access network decreases Round Trip Times (RTT) in both.912 on evolved GSM/EDGE Radio Access Network (FGE) UID_50568. General description Multiplexing and multiple access on the radio path Channel coding Radio transmission and reception Radio subsystem synchronization Dual Transfer Mode (DTM). Stage 2 UE Radio Access capabilities Mobile radio interface Layer 3 specification. Support of DTM was insured as well. A shorter RTT would also increase the throughput for Transmission Control Protocol (TCP) based services. Mobile GA interface layer 3 specification Packed-switched handover for GERAN A/Gb mode. Latency reduction techniques were specified. it would also make applications having many client/server interactions faster. Mobile Station (MS) .008 TS 44. Core network protocols. Radio Link Control / Medium Access Control (RLC/MAC) protocol Mobile Station (MS) conformance specification.9.005 TS 45.331 TS 51. and an optimized solution allowing fast USF scheduling and decoding (to be used when multiplexing on the same radio resources of low-latency TBFs with legacy ones is not required).318 TS 43. including improved Ack/Nack reporting and reduced Transmission Time Interval (TTI) that characterizes low-latency Temporary Block Flow (TBF).Base Station System (BSS) interface. The reduced latency makes it possible to provide low-delay services otherwise not feasible in GERAN (e.9 Latency Reductions (LATRED) UID_50582 Resources: GP References Document GP-061519 TS 45. ideal and non-ideal radio conditions.10 (2010-06) 16.10 PS Handover between GERAN/UTRAN mode and GAN Mode (GUGAN) UID_52147 Resources: G2 References Document GP-061349 TS 43. In addition.g.010 - Title/Contents WID(s) WID on PS Handover between GERAN/UTRAN mode and GAN Mode Impacted Specifications Generic access to the A/Gb interface.010-1 TS 51. This includes a solution maintaining legacy Uplink State Flag (USF) scheduling and decoding (to allow multiplexing on the same radio resources of low-latency TBFs with legacy ones).021 WID on Latency Reductions Title/Contents WID(s) Impacted Specifications Physical layer on the radio path. Stage 3 General Packet Radio Service (GPRS).003 TS 45.060 TS 25. Radio Link Control / Medium Access Control (RLC/MAC) protocol Radio Resource Control (RRC). 16.060 TS 51. Part 1: Conformance specification Base Station System (BSS) equipment specification. Stage 2 Generic Access (GA) to the A/Gb interface. Mobile Station (MS) . Stage 2 General Packet Radio Service (GPRS).001 TS 45.Base Station System (BSS) interface.318 TS 44.010 TS 43.002 TS 45.129 TS 25. Stage 2 General Packet Radio Service (GPRS). Protocol specification Mobile Station (MS) conformance specification New Dedicated Specifications/Reports None 3GPP .064 TS 44. Overall description of the GPRS radio interface.055 TS 43.

various specifications currently lack procedures applicable for PS handover between GERAN/UTRAN mode and GAN mode as follows: • • • • a mechanism by which an MS can indicate it supports PS Handover between GERAN/UTRAN and GAN mode. 3GPP . The work provides the support for PS handover between GERAN/UTRAN mode and GAN mode. PS handover preparation and execution phase activities performed by a target or source GANC.318 and 44.9. The working assumption for Generic Access (as specified in 3GPP TS 43. a mechanism by which a source GANC can determine the System Information applicable to a target BSS.318) has so far been that requirements on GERAN should also apply for Generic Access.10 (2010-06) The existing GERAN specifications support the Um interface signalling mechanisms required to perform PS handover to/from an MS operating in A/Gb mode. However.112 Overview of 3GPP Release 7 V0. new Up interface control plane messages required to support PS handover between GERAN/UTRAN mode and GAN mode.

higher order modulations and turbo codes. Radio Resource Control (RRC) protocol General Packet Radio Service (GPRS). To facilitate different levels of MS/NW support.113 Overview of 3GPP Release 7 V0.e.Base Station System (BSS) interface. a combination of higher symbol rate and higher order modulations. turbo codes. the following levels are defined: A.018 TS 44. implementation of the full feature may require hardware enhancements on BSS. 32-ary modulation with 325 ksymbols/s symbol rate.001 TS 45. Two compatibility objectives of special concern are the impact to legacy BSS hardware and to legacy frequency planning (which could not be met with a 2 TRX implementation option). (less than) 271 kHz (assuming symbol rate sampling for a legacy transceiver). 16-ary modulation with 271 (legacy) ksymbols/s symbol rate B. Those could be met if a symbol rate of 1. To maximise the fraction of the installed legacy BTS hardware where the feature can be implemented. i. To further enhance the uplink radio performance of the GERAN with minimal impact to higher layers of the existing EGPRS by means of: • • • • 1.064 TS 44. General description Multiplexing and multiple access on the radio path Channel coding Modulation Radio transmission and reception Radio subsystem link control Radio subsystem synchronization Dual Transfer Mode (DTM).004 TS 45.060 Title/Contents WID(s) WID on Higher Uplink performance for GERAN Evolution Impacted Specifications Mobile radio interface Layer 3 specification. 325ksymbols/s). Mobile Station (MS) .010 TS 43. and the interference to adjacent channels is minimized.055 TS 43. 16-ary modulation and 32-ary modulation with 325 ksymbols/s symbol rate C. Nevertheless.2 times the legacy symbol rate is chosen (i. Core network protocols. Stage 2 General Packet Radio Service (GPRS).008 TS 45. 16-ary modulation. Radio Link Control / Medium Access Control (RLC/MAC) protocol New Dedicated Specifications/Reports - The following have been studied in TR 45. the transmitted signal bandwidth is small enough to be received by a single legacy transceiver. peak / average bit rates and bit rates at cell border have been shown.002 TS 45.2 times higher symbol rate (325 ksymbols/s). different levels of MS/NW support are motivated.912 on evolved GSM/EDGE Radio Access Network (FGE) UID_50568. 32-ary modulation.e. Significant improvements in spectral efficiency. Overall description of the GPRS radio interface. Stage 2 Mobile radio interface layer 3 specification. but the compatibility objective of coexistence with existing legacy frequency planning is still met.008 TS 45.003 TS 45.9.005 TS 45.10 (2010-06) 16.11 Higher Uplink performance for GERAN Evolution (HUGE) UID_50584) Resources: GP References Document GP-071083 TS 24. and possibly turbo coding (see Note) 3GPP . The compatibility objectives of GERAN evolution can be met. • • • higher symbol rates in uplink. Stage 3 Physical layer on the radio path.

G3new G3new GP061906 SP#42 split core from testing specification work GP#46 completion 09/10=>03/11 (was 02/10=>03/10=>09/10).MS Conformance Test HUGE HUGEMstest G1.g. less than 271 kHz). C) will imply support for all lower levels (e. Radio aspects . BTS conformance testing has been revised (CR to TS 51.010-1 TS 51. A. – Corrections on channel coding. Part 1: Conformance specification . • Status: the work item HUGE = EGPRS2 UL is formally COMPLETED. MS conformance test specs not started yet. It has to be ensured that the different levels of MS and NW support can interoperate. it will imply MS support of A. if so. Different transmit filters were considered. In this work.G3new New Dedicated Specifications/Reports - 9584 5308 7 HUGE Conformance Testing HUGE . The number of options needs to be kept as low as possible in order to reduce complexity. Performance evaluations and optimisations focused on asynchronous networks with uplink diversity but other scenarios were also considered. • • If it is agreed that different levels of MS support exist. If it is agreed that there is only one level of MS support. – Progress on the definition of APD (back-off) values to be used when EGPRS2 is used on the BCCH carrier.G1 Base Station System (BSS) equipment specification.9. – EVM values agreed on the BTS side. three prerequisites are that the transmitted signal bandwidth will be small enough to be received by a single legacy transceiver (i. it will be studied how the levels above have to be supported by a HUGE MS. There is still activity in GERAN on the following areas: EGPRS2 channel quality reporting: • agreement on timeslot based reporting but still discussions on how to perform reporting on all timeslots due to the high number of modulations to report. – Mixed modulation USF: no agreement yet to include the proposal in the standards.g.010 3GPP . MS support for a higher level (e. B).021 - Title/Contents WID(s) WID on Higher Uplink performance for GERAN Evolution (HUGE) – MS Conformance Tests WID on Higher Uplink performance for GERAN Evolution (HUGE) – BTS Conformance Tests Impacted Specifications Mobile Station (MS) conformance specification. – Implementation of seamless switch between EGPRS and EGPRS2A/B levels w/o TBF release/reestablishment (approved).10 (2010-06) NOTE: Turbo coding is included if the achievable gains (already shown by simulations) justify the cost of its introduction.11.021 approved).114 Overview of 3GPP Release 7 V0.212 will be reused. B and C. No interest in HUGE TCs development among the participating companies 51. the Turbo coding scheme defined in 3GPP TS 25.e. that the coverage is maximised and that the interference to adjacent channels will be minimised. – • • • Where : EVM: Error Vector Magnitude APD: Average Power Decrease USF: Uplink State Flag 16.G1 References Document GP-061906 GP-061907 TS 51.1 HUGE Conformance Testing (HUGE) UID_59584 (target Mar 2011) Resources: G3new. For this reason. Good progress on receiver performance requirements for MSs and BTSs.

BTS Conformance Test HUGEBTStest G1 GP061907 Overview of 3GPP Release 7 V0.021 3GPP .9.115 5114 3 HUGE .10 (2010-06) GP#43 completed 51.

Higher Order modulation and Turbo coding for downlink (REDHOT) UID_50121 Resources: GP References Document GP-071080 TS 24. All MS supporting the REDHOT feature are required to support either level A or level A+B. Increased data throughput in the entire cell.212 is reused. To facilitate different levels of MS support. At higher symbol rate. 32-QAM modulation. 16-QAM and 32-QAM combined with Turbo coding and Higher symbol rate.018 TS 44. Radio Link Control / Medium Access Control (RLC/MAC) protocol New Dedicated Specifications/Reports - In TR 45. This work further enhances data rates. Stage 2 Mobile radio interface layer 3 specification.912 on evolved GSM/EDGE Radio Access Network (FGE) UID_50568. This justifies different levels of MS support.9. 3GPP . Complexity analysis indicates the feasibility of higher order modulations and turbo codes in the downlink. higher symbol rates and Turbo codes have been demonstrated. Implementation of the full feature may require hardware enhancements on BSS. sensitivity and spectral efficiency of the GERAN network in typical network layouts through new modulation and coding schemes using:      QPSK modulation. the benefits of higher order modulation. Higher Order modulation and Turbo coding (REDHOT) for downlink Impacted Specifications Mobile radio interface Layer 3 specification.008 TS 45. General description Multiplexing and multiple access on the radio path Channel coding Modulation Radio transmission and reception Radio subsystem link control Radio subsystem synchronization Dual Transfer Mode (DTM).10 (2010-06) 16. the following approach is taken: • • Level A: 8-PSK. legacy services received by legacy terminals are not worsened: this may imply having more than one solution depending on the interference situation in the network. Dual Carrier Downlink (DCDL).003 TS 45. improved sensitivity and improved spectral efficiency in GERAN networks.060 Title/Contents WID(s) WID on REduced symbol Duration. have been shown.055 TS 43.116 Overview of 3GPP Release 7 V0. 16-QAM and 32-QAM combined with Turbo coding.064 TS 44. Turbo coding based on independent encoding of RLC/MAC blocks.001 TS 45. Stage 3 Physical layer on the radio path.002 TS 45. REDHOT is compatible with Mobile Station Receive Diversity (MSRD). but the compatibility objective of coexistence with existing legacy frequency planning is still met.004 TS 45. Overall description of the GPRS radio interface. 16-QAM modulation.Base Station System (BSS) interface.010 TS 43. Core network protocols.008 TS 45. Mobile Station (MS) . Some features will put higher requirements on the NW/MS. Radio Resource Control (RRC) protocol General Packet Radio Service (GPRS).12 REduced symbol Duration. Higher symbol rate (325 ksymbols/s). latency reductions (LATRED) and Higher Uplink performance for GERAN Evolution (HUGE).005 TS 45. The Turbo coding scheme defined in TS 25. Level B: QPSK. Stage 2 General Packet Radio Service (GPRS).

G1 References Document GP-062491 GP-062492 Title/Contents WID(s) WID on REduced symbol Duration.117 Overview of 3GPP Release 7 V0.021 approved). RED HOT A (EGPRS2-A DL) and HUGE A (EGPRS2-A UL) use legacy symbol rate (270 ksymbol/s) RED HOT B (EGPRS2-B DL) and HUGE B (EGPRS2-B UL) use increased symbol rate (325 ksymbol/s) There is still activity in GERAN on the following areas: EGPRS2 channel quality reporting: • agreement on timeslot based reporting but still discussions on how to perform reporting on all timeslots due to the high number of modulations to report. – Mixed modulation USF: no agreement yet to include the proposal in the standards. Good progress on receiver performance requirements for MSs and BTSs.G1 Base Station System (BSS) equipment specification. Radio aspects .1 REDHOT Conformance Testing (REDHOT) UID_59121 (target Nov 2010) Resources: G3new. – Progress on the definition of APD (back-off) values to be used when EGPRS2 is used on the BCCH carrier.MS Conformance Tests BTS Conformance Tests REDHOT REDHOTMstest REDHOTBTStest G1. Part 1: Conformance specification .9.G3new G3new G1 GP062491 GP062492 SP#42 split core from testing specification work GP#46 completion 09/10=>11/10 (was 02/10=>03/10=>09/10) GP#42 completed 3GPP .021 Mobile Station (MS) conformance specification.g. MS conformance test specs not started yet. – Corrections on channel coding. – Implementation of seamless switch between EGPRS and EGPRS2A/B levels w/o TBF release/reestablishment (approved). mutual aligned signalling. BTS conformance testing has been revised (CR to TS 51. Higher Order modulation and Turbo coding (RED HOT) for downlink: MS conformance tests Impacted Specifications TS 51.010-1 TS 51. – • • • Where : EVM: Error Vector Magnitude APD: Average Power Decrease USF: Uplink State Flag 16.10 (2010-06) REDHOT can be used simultaneously with any of these and compatibility was maintained between these WIs on e. • Status: the work item RED HOT = EGPRS2 DL is formally COMPLETED. Higher Order modulation and Turbo coding (RED HOT) for downlink: MS conformance tests WID on REduced symbol Duration.G3new New Dedicated Specifications/Reports None 5912 1 5308 8 5114 6 REDHOT Conformance Testing REDHOT . – EVM values agreed on the BTS side.12.

Conclusion: Recommendation to standardize a service with the name IMS Multimedia Telephony service endorsing the TISPAN service definition for supplementary services applicable to 3GPP Systems as follows: • • • • • • • • • • Originating Identification Presentation (OIP). Originating Identification Restriction (OIR). Communication Hold (HOLD). Message Waiting Indication (MWI).173 Title/Contents WID(s) WID on Multimedia Telephony Capabilities for IMS Impacted Specifications - New Dedicated Specifications/Reports IMS Multimedia Telephony service. Communication Barring (CB) with the addition that the ICB service extension with a roaming condition (the roaming condition is set to true when the served user is roaming). is needed for wireless access to IMS. The study has found one supplementary service not covered by TISPAN but applicable to a 3GPP specified IMS Multimedia Telephony service and that is: • Communication Diversion: Communication Forwarding on Mobile Subscriber Not Reachable. Result: Spin-off Feature Multimedia Telephony Service for IMS (MTSI) UID_7038 3GPP . A similar service. Terminating Identification Presentation (TIP). and to support interoperability in multi-vendor and multi-operator environment and to provide the user with the same experience across the different IP based accesses and domains.118 Overview of 3GPP Release 7 V0. Communication Diversion (CDIV). Explicit Communication Transfer (ECT). Define in close cooperation with TISPAN a minimum set of capabilities required to secure multi-vendor and multioperator inter-operability for Multimedia Telephony and related Supplementary Services. Conference (CONF). in order to be able to define services to the end-users. TISPAN is defining an IMS based Multimedia Telephony service. TS 22. defined by 3GPP.173 defines the IMS Multimedia Telephony service and the minimum set of capabilities required to secure multivendor and multi-operator inter-operability for Multimedia Telephony and related Supplementary Services. Stage 1 In addition to reusing the IMS system as defined by 3GPP. and supplementary services IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service and supplementary services. which is an evolution of the CS based Telephony service provided by traditional ISDN and PSTN. Terminating Identification Restriction (TIR).973 TS 22.9.10 (2010-06) 17 Feasibility Studies 17.1 Study on Multimedia Telephony Capabilities for IMS (MITE) UID_31082 Resources: S1 References Document SP-050387 TR 22.

3GPP . system of selection must. The intention is to ensure that the multi system operation does not lead to non 3GPP-compliant behaviour by the terminal. available of the UICC can be assumed. supported systems or network operators are needed. TR 22. However. operators are interested in techniques that may provide the ability to smooth the rollout and accelerate the take-up of IMS. The study should identify different methods of system selection and their impact on 3GPP specifications. having switched to a different system.936 keeps clearly visible the distinction between 3GPP internal PLMN selection requirements and multi system selection requirements.979 Title/Contents WID(s) WID on Feasibility Study on IMS with real time services deployments WID on Feasibility Study on Combining CS calls and IMS sessions Impacted Specifications - New Dedicated Specifications/Reports Feasibility study on combined Circuit Switched (CS) calls and IP Multimedia Subsystem (IMS) sessions Operators regard IMS as a key feature. If this is supported the interaction between the user's and the operator's preferences should be studied. Also. Related to this. The study should consider what needs to be tested and by whom. but was not restricted to: • Whether the system selection or PLMN selection should take higher priority in a multi system terminal. The existing PLMN selector lists and HPLMN information could be re-used in system selection. It may also allow user to set system preferences but more consideration is needed in this area. and. Additionally.3 Study on Combining CS calls and IMS sessions UID_31055 Resources: S1 References Document SP-040465 SP-040467 TR 22.119 Overview of 3GPP Release 7 V0.10 (2010-06) 17. This could take the form of a background scan of higher priority systems. 17. When dealing with the 3GPP-compliant part of the terminal. it should be studied if these should reside in the terminal memory or in the smartcard.9. Particular issues handled included. If any priority lists for user's preferences. there remain issues with the efficiency of transferring Voice over IP over the radio interface. the criteria for system change would need to be defined. with the capability of the GSM radio interface to handle VoIP.936 WID on Behaviour of multi system terminals Title/Contents Impacted Specifications - New Dedicated Specifications/Reports Multi-system terminals There is a need to standardize how a multi system terminal should perform system selection.936 clearly identifies which requirements are mandatory and which can be left implementation specific. be capable of switching back to the original system and should allow manual system selection as this is likely to be a regulatory requirement in some regions. TR 22. needs to be supported.2 Study on Behaviour of Multi system UEs (BMSU) UID_31050 Resources: S1 References Document WID(s) SP-050502 TR 22. or both. • • • Conclusion: The method of system selection must provide means for the operator to set system preferences. Whether automatic or manual system selection mode. Testing of multi-mode terminals. in particular the mechanisms for system selection should be considered. taking into account interoperability and network protection.

the user may want to add a voice call to a chat session. A continued evolution and optimisation of the system concept is also necessary in order to maintain a competitive edge in terms of both performance and cost. clause 9 should be reflected in 3GPP Stage 1 specifications.228.979 studies options for combining CS and IMS capabilities. the user may want to send a picture while on a voice call. by covering requirements. It is desired to make such adding of media simple from user point of view and manageable from an operator point of view. Motivations for further evolving the 3GPP system to an AIPN include: • • Rapid increase in IP traffic.g. In order for the 3GPP system to cope with the rapid growth in IP data traffic.120 Overview of 3GPP Release 7 V0. 17. it is important to ensure compliance with Internet protocols within future developments of the 3GPP system. one of the possible fast deployment scenarios for IMS services is to build on existing service such as CS calls and enhance by adding IMS sessions. 3GPP . The two solutions in TR 22.10 (2010-06) In order to use the existing CS infrastructure to transport the voice traffic for multimedia services. It is anticipated that the progression towards an AIPN may enable leverage of Information Technology (IT) hardware and software with general-purpose and mobile network specific software that should provide cost reduction (CAPEX and OPEX) for infrastructure equipment and applications of 3GPP based mobile networks. video clip. solutions and trade-offs. Or alternatively. Potential network and traffic cost reduction.4 Study on All-IP Network (FS_AIPN) UID_31059 Resources: S1 References Document SP-040303 - Title/Contents WID(s) WID on All-IP Network Feasibility Study Impacted Specifications - New Dedicated Specifications/Reports TR 22. the PS technology utilized within 3G mobile networks requires further enhancement. WLAN as an alternative access technology to services in the mobile core network is recognized from Rel-6 onwards. leaving vendors and operators to develop these different techniques in isolation would lead to interoperability problems and fragmented/small markets. to speak to a member of the chat room. There is a need to assure a single. TR 22. However. file) and vice versa. The All-IP Network (AIPN) concept was initially introduced within 3GPP in Rel-4 with the standardization of the MSC Server . interoperable solution for adding media to CS calls and IMS sessions including terminals. It recommends developing a new TS for combinational services. The proposed solution should have no or very minor impact on existing CS and IMS services and infrastructure. TR 22.9. add an IMS session to a CS call for exchanging media (e. picture. Moreover.g. Spin-off feature Combinational Services (CSICS) UID_31063.979 studies solutions for adding IMS sessions to a CS call or a CS call to an IMS session. addressing migration and interoperability issues. As an example.979 are related on architectural level. there are many different techniques for combining the CS and IMS parts together.979. Conclusion: The requirements captured in TR 22. e.MGW split core network architecture for the CS domain and extended from Rel-5 by the standardization of the IMS. infrastructure and services from various vendors. From an end-user point of view.978 All-IP network (AIPN) feasibility study The 3GPP system currently supports GERAN and UTRAN based Access Networks in conjunction with CircuitSwitched (CS) and Packet-Switched (PS) Core Network domains and IP Multimedia CN Subsystem (IMS) from Rel-5. to be referenced via the existing appropriate specifications. Two possible solutions have been identified: • • use CS real time bearers with IMS sessions to better satisfy the existing requirements in TS 22.

 Investigate needs and requirements associated with the evolution of the 3GPP System to an AIPN and to identify a 3GPP view on how IP technology and associated transport technologies should be evolved towards an enhanced multi-service network. specifically: • Investigate the business and technological drivers for progression of the 3GPP system to an AIPN : o o o o • Study motivations Study impact on current models (e. The reuse of existing standards also needs to be investigated. Furthermore. Ability to offer enhanced and flexible IP services (e.  Investigate requirements associated with the reuse of legacy infrastructure and support of legacy terminals  Identify the capability expansion required to introduce the AIPN concept into the 3GPP system (migration and co-existence). 3GPP should focus on the inter-working between 3GPP Mobile Networks and other Networks considering mobility. IP technology being mainstream technology. o TR 22. optimisation for the radio environment. Taking the above into consideration it is necessary to further define the AIPN concept. Convergence of telecommunications and IT industries towards IP technology. and roadmap for work to be undertaken within Rel-7and further. recognizing support of multiple access network scenarios.g.g.g. the following aspects identified within Rel-6 TR 21. study if and how the introduction of a 3GPP AIPN will give a significant cost reduction (CAPEX and OPEX) Identify any short and long term issues To define and develop the end user and operator aspects of a 3GPP AIPN concept: o Investigate the feasibility of evolving the 3GPP system towards an AIPN from existing functionalities:  Produce an ideal 3GPP All-IP vision. taking into account the special requirements for the mobile community e. explore business and technological drivers and evaluate the feasibility of evolving the 3GPP system towards an AIPN. Additionally. Flexible accommodation and deployment of existing and new access technologies with mobility by a common IPbased network.902 "Evolution of 3GPP System" are considered relevant to the long-term evolution of the 3GPP system: • • • A seamless integrated network comprising a variety of networking access systems connected to a common IP based network supported by a centralised mobility manager. This work studies further application of the AIPN concept. high security. PtP.978 conclusions / Roadmap for work within Rel-7 New requirements for introduction to the 3GPP specifications in Rel-7 3GPP . identifies and evaluates needs/drivers and identifies work required to satisfy the short term and long term needs of 3GPP. integrated services) increasing revenues for network operators. Subsequent steps to be identified during the concluding phases of the Feasibility Study.10 (2010-06) • • • • • • Industry trend towards IP services. A similarity of services and applications across the different systems is beneficial to users. business/charging models) Study the leverage of technological convergence and introduction of new technology in a cost effective way i.9.121 Overview of 3GPP Release 7 V0.e. aspects of the 3GPP system requiring enhancement need to be identified and developed in accordance with this common vision. Leverage of existing capabilities to evolve the 3GPP system towards an AIPN. target.  Define the scope. charging and QoS management. carrier grade.

For this reason it is recommended that these functionalities are captured by new service requirements for the 3GPP system with the highest priority. the content of other clauses may be considered within specification work for an AIPN as appropriate. standardising a new videotelephony teleservice improving the existing videotelephony service that is based on BS30 For both alternatives backwards compatibility with existing videotelephony services using the BS30 Multimedia Call Bearer Service is essential. The requirements for enhancing videotelephony should build on the CS Multimedia call Bearer Service. In call modifications (rate adaptation) and modifications at call establishment should be investigated.9.2.g. 17. The content of this clause should be used as a basis for introducing AIPN service requirements into Rel-7 specifications.122 Overview of 3GPP Release 7 V0. The introduction of new functionalities and the enhancement of existing functionalities are necessary to achieve multiple access system accommodation and the mobility across multiple different access systems which are the fundamental key aspects of an AIPN. videotelephony services based on the CS Multimedia call Bearer Service) can be assured.5 Study on Videotelephony teleservice (VidTel) UID_31075 Resources: S1 References Document WID(s) SP-050506 TR 22. TR 22.10 (2010-06) New requirements for introduction in Rel-7 specifications to enable an AIPN have been identified in clause 6. provided that backward compatibility with existing services (e. Some of the possible advantages for defining a videotelephony teleservice are: • • • • • • • ability to negotiate the codecs used in the VT call using already standardised mechanisms available today for teleservices ability to differentiate the charging between videotelephony and data transfers using BS30 simplification of handling of call modification for network operators compared to videotelephony services provided using the BS30 Multimedia Call Bearer Service simplification of downgrading the service to speech in case of changing from 3G to 2G and vice versa compared to videotelephony services provided using the BS30 Multimedia Call Bearer Service the same handling of supplementary services as other teleservices unique subscription for videotelephony services including unique definition within roaming agreements which may improve interoperator charging possible definition of a unique emergency videotelephony teleservice (if required) 3GPP . 2.903 concludes that enhancements were needed including: • • • • • • Call setup time improvements Additional support of supplementary services Charging improvements Improved in call modification More efficient emergency videotelephony call support User notification These enhancements can be provided by either: 1. Additionally.903 WID on Study on Videotelephony teleservice Title/Contents Impacted Specifications - New Dedicated Specifications/Reports Study on Videotelephony teleservice The study should provide a full definition of videotelephony as a teleservice.

terminal capability. 3) Network Operators need to dynamically distribute their roaming customers across multiple VPLMNs in a given country. Methods to improve the time taken for a UE to regain service and hence avoid time consuming searches of all the bands in which a UE can operate were considered.6 Study on Network Selection Principles (NetSel) UID_31073 Resources: S1 References Document WID(s) SP-050227 SP-060220 TS 22.011 and requirements from other work areas. 2) There is a requirement to provide the tools to a network operator to allow them to offer their customers the best possible experience when roaming into other networks.10 (2010-06) These need to be balanced against possible disadvantages of defining two alternative solutions for providing videotelephony services. and so on. The ability to prevent users from selecting specific PLMNs.123 Overview of 3GPP Release 7 V0. access technology. 17.811 SID on Review of Network Selection Principles WID on Network selection enhancements Title/Contents Impacted Specifications - New Dedicated Specifications/Reports Review of network selection principles The study should review the network selection mechanisms in TS 22. It is thought that videotelephony will be a telecommunication service that provides the complete capability. 3GPP .9. Enhancements to Manual Network Selection to provide the user with additional information to assist their choice. especially in the cases where UEs support multiple bands and multiple modes. Such tools include The ability for the HPLMN to dynamically direct a UE to select a different VPLMN. Ideal performance targets were identified as: less than 20 seconds to select a PLMN in the case where the RPLMN is not available and less than 5 seconds in the case where the RPLMN is available. including terminal equipment functions. This includes the ability of the home operator to control their user’s selection of visited network from the perspective of service provisioning. Conclusion: In light of these considerations it might be beneficial to fully specify a videotelephony teleservice. for communication between users according to standardized protocols and transmission capabilities established by agreement between operators. by considering new methods of access and new operator types and ensuring appropriate access is chosen based on: • • • • • • • • • • Network selection algorithm used by mobile devices End user inter-action & interface Network operation Multiple Access System scenarios User & network operator lists National roaming International roaming RAN evolution Radio Planning Backwards compatibility Conclusion: it would be beneficial to consider enhancements to the current specifications in a number of areas: 1) The time the network selection process takes.

There is a need to study concepts. In the case where a UE may oscillate between two PLMNs.953 WID on Study Item on Multimedia Priority Service Title/Contents Impacted Specifications - New Dedicated Specifications/Reports Multimedia priority service feasibility study The response to emergency situations (e. in manual mode. audio. In some cases. and requirements for the support of packet based Multimedia Priority Services. earthquakes.950).7 Study on Multimedia Priority Service (PRIOR-MM) UID_31041 Resources: S1 References Document WID(s) SP-060329 TR 22.10 (2010-06) 4) Practical experience from the implementation of National Roaming has highlighted a number of areas where enhancements to the 3GPP specifications could be considered. Priority Session Establishment. perhaps due to a direct or indirect result of the emergency situation. but not all. Similar prioritized service provision is needed for packet (e. 6) In the course of the development of the TR some additional areas for enhancements to the 3GPP specifications have been identified. Priority Levels. floods. certain government and emergency management officials may have to rely on public network services when the communication capability of the serving network may be impaired. for example due to congestion or partial network infrastructure outages. At power on. TR 22. used by the UE. in the most optimum manner possible. 5) The performance of PLMN selection in border areas needs to be improved.g. The following high-level requirements were identified to support Multimedia Priority Service: • • • • • Priority Session Origination. video. terrorist attacks) depends on the communication capabilities of public networks. In most cases. as it has been noted that network operators are advising their customers to manually select the HPLMN to avoid accidental roaming. Work is underway to provide standardized Priority Service for authorized persons in the context of CS speech communications (e. IP) based multimedia services including data. it is desirable to register to the HPLMN if it has become available.124 Overview of 3GPP Release 7 V0. However. if the RPLMN is not found. hurricanes. It should be possible for the user to set a preference for either manual or automatic network selection on power-up Some of the proposed enhancements are feasible for Release 7 completion.g. These are: It may be beneficial to standardise a minimum size of list to be supported by the ME and any conclusion should support the normal operational requirements of operators The use of the Refresh command should be reviewed to allow the subscriber’s operator to update information.9. while other more complex features should be developed in future releases (see Network selection enhancements (NSP-CR) UID_7041). Priority Radio Resource Queuing.g. emergency responders use private radio systems to aid in the logistics of providing critically needed restoration services. the UE will attempt to select the RPLMN (the national roaming partner). Priority Session Progression. but the HPLMN is available then the UE should automatically register with it. features. 3GPP . In the case where a UE is registered to a national roaming partner and loses coverage. 17. and text transmission capabilities.

As a result. This initiative was called eSafety. Applicability to Telecommunications Services. Handover. the CEC has published Commission Recommendation on the processing of caller location information for the purpose of location-enhanced emergency call services (adopted by the Commission in June 2003). Multimedia Priority Service Code/Identifier.967 Study Item on Transferring of emergency Call data Title/Contents Impacted Specifications - New Dedicated Specifications/Reports Transferring of emergency call data During 2004 a number of discussions were between the Commission for the European Communities (CEC). 3GPP . ERM TG 37 and the eCall Driving Group. matching these with existing capability within 3GPP specifications and. Revision from UTRAN to RAN.125 Overview of 3GPP Release 7 V0. 17.8 Study on Transferring of emergency Call data (eCALL) UID_31083 Resources: S1 References Document WID(s) SP-050388 TR 22. Roaming. At the time of writing this document. The work involved co-operation in the short term with European initiatives and groups such as E-MERGE.9. The work also involved co-operation with similar initiatives in other regions. eCall was defined as a specific item in the scope of the eSafety initiative. It consisted in collection of regional requirements. in order to increase road safety and reduce the number of accidents on Europe's roads. This work studies the feasibility of data transmission associated with an emergency communication to the PSAP. ETSI MSG. a joint initiative of the CEC (DG Enterp and DG InfoSo). Charging Data Record. there was no directive. Conclusion: with the availability of the report from GSME on the Operators' preferred method of implementation. the telecommunication industry and ETSI standards groups regarding the provision of in-vehicle emergency calls. Queuing Requests for Bearer Resources. TRANSPORT PROJECT in ETSI RCC. The following primary capabilities were identified to support Multimedia Priority Service: • • IMS IETF Resource Priority Header Conclusion: Recommendation to add the IETF Resource Priority Header to 3GPP IMS specifications. Part of this work was to collect the minimum data set required by emergency services and identify the most appropriate means to supply this data to the PSAPs. deployment and use of Intelligent Integrated Safety Systems that use information and communication technologies in intelligent solutions. As part of this initiative. EMTEL. It is intended to extend the current E112 capabilities to enable the Transferring of eCall data between the Vehicle and the Public Safety Answering Points (PSAP). This should rely on existing GSM/UMTS infrastructure. if essential gaps are identified. Work Items can be established in the appropriate Working Groups to complete any standardization work required.10 (2010-06) • • • • • • • • Invocation on Demand. industry and other stakeholders was defined with aims to accelerate the development. but this has not been ruled out. to work towards an efficient 3GPP solution. the automotive industry. Based on initial discussions.

such as conversational speech or streaming video.126 Overview of 3GPP Release 7 V0.207 to achieve improved end-to-end QoS also in case of an interworking with IP network domains or backbone networks that are not under the control of PLMN operators.g.10 (2010-06) 17.2. IMS deployment in the near term will rely on this approach. e.e. Mechanisms which are scalable and can take into account the overall end-to-end networks performance should be considered to enhance the current architecture.34 and this model takes a pragmatic approach to QoS..2. Consequently.207. Recommendation: The current interconnection model required by GSMA for 3GPP networks does not require the enhancement of TS 23.3.207 and in TR 23.9 Study on Enhancement of E2E QoS UID_32073 Resources: S2 References Document WID(s) SP-040326 TR 23. are insufficient to achieve fully end-to-end QoS guarantees in case of an interworking with different IP network domains or backbone networks. which may require to be enhanced as a result of other ongoing specification work in 3GPP related to IMS and QoS issues.802 clause 5. Interaction with emerging Next Generation Networks (NGN) standards and work in ITU-T and IETF NSIS were considered. It is generally recognized that in the future new interconnection models may be needed. This work studies different possible solutions to enhance the end-to-end QoS architecture specified in TS 23. to accommodate increased adoption of IP based services and/or support interfacing to other Next Generation Networks and/or when the committed SLAs cannot be met. together with SLAs. relying simply on over-provisioning and marking of User Plane IP packets (using DiffServ) to exchange QoS information (i.1 and A. the requirements may not be fully satisfied with existing models in case of an interworking with IP network domains or backbone networks that are not under the control of PLMN operators.2.9.802 WID on Study on Enhancement of E2E QoS Title/Contents Impacted Specifications - New Dedicated Specifications/Reports Architectural enhancements for end-to-end Quality of Service (QoS) The mechanisms described in the QoS related 3GPP specifications. According to GSMA.207. Current solutions that guarantee QoS end-to-end rely on existing IP QoS models and networks that are controlled by the PLMN operators. Conclusion: The current interconnection model for 3GPP networks is described in GSMA PRD IR. For some important services with strict end-to-end QoS requirements. to deliver QoS on inter-PLMN networks. especially TS 23. Such solution is described in Annex A. as per Release 99). although the timing and the details of such need is not currently well understood. This work should be frozen until timing and details on the need of new interconnection models become clear. it will not be easy to achieve fully end-to-end QoS guarantees in case of interworking with different IP network domains or backbone networks.2 of TS 23. 3GPP . So the ways to interwork QoS policies and control between different IP network domains are needed. especially when the service traffic goes through different IP network domains or backbone networks.

10 Study on Bandwidth Saving at Nb Interface with IP transport UID_7034 Resources: C3 References Document WID(s) CP-060438 TR 29. optional multiplexing mechanism for the Nb interface and IP transport that allows transporting several NbFP/codec payload PDUs of different bearers.11 Study on Routeing of MT-SMs via the HPLMN UID_14019 Resources: C4 References Document WID(s) CP-060701 Study into Routeing of MT-SMs via the HPLMN Title/Contents Impacted Specifications None New Dedicated Specifications/Reports TR 23. standard VoIP bearers or other interfaces such as Iu. in effect setting-up a relay that allows the HPLMN of the receiving MS to control the delivery of all short messages even when the receiving MS is roaming outside of their HPLMN.g. 7 bytes for POS) are much larger than the transported payload NbFP/codec (e.840 Study into Routeing of MT-SMs via the HPLMN The opportunity to include a non-standardised SMS-SC-like logical entity in the HPLMN of the receiving MS already exists outside of 3GPP specifications for operators.g.127 Overview of 3GPP Release 7 V0.1 and 5. the /IP/UDP/RTP header overhead (40 byte for IPv4.9. The solution should be suitable for any type of payload transported within NbFP. 60 byte for IPv6) and the layer 2 header/trailer header overhead (e.814 WID on Study a Multiplexing at Nb Interface with IP transport Title/Contents Impacted Specifications None New Dedicated Specifications/Reports Bandwidth saving at Nb interface with IP transport For typical payload transported over the Nb interface. e. Conclusion: TR 29. 3GPP . A format of compressed RTP headers has been defined for NbFP transport and the transport formats specified in clause 5. the multiplexing design should be generic and future-proof by not precluding support of non-NbFP payload types. The solution should not modify the standard IP header. 35 byte for AMR 12.814 defines a solution allowing achieving significant bandwidth reductions in an IP network by multiplexing packets with the same destination address and DiffServ class. in particular jitter and packet delay.1. Spin-off implementation Feature: PDU multiplexing at Nb Interface with IP transport (NbIPMux) UID_340047.1 are agreed to be added as options for the Nb interface specifications within the scope of Rel-7.2. Extra bandwidth reduction can further be obtained by supporting RTP header compression. 38 bytes for Ethernet v2. This work studies possible solutions for a simple. It is desirable to reduce the /IP/UDP/RTP header and the layer 2 header/trailer overheads to save bandwidth. while taking care to preserve the optional capability to avoid RTPXtalk situations. The potential benefits include: • • More control over SMS spam.2 kHz and 9 byte for SID frames).10 (2010-06) 17. 17. Added flexibility for Mobile Terminated SMs (MT-SMs) charging (particularly pre-paid).1.g. Though primarily intended and possibly optimized for NbFP transport within 3GPP CS core networks. The solution should minimize impacts to existing network characteristics.

in order to protect a number of existing 3GPP specified services from the negative effects of a multiplicity of non-standard solutions.. The target was to apply protection in a way which is agnostic to the application protocol.840 shows the advantages and disadvantages of both Transparent and Non-Transparent Modes. functional description and protocol details (TCAPsec Gateway Function) An identified security weakness in 2G and 3G systems is the absence of security in SS7 networks. and without this feature. Such a solution should avoid negatively affecting existing 3GPP defined functionality. MSC. The work on MAPsec Rel-4 within 3GPP. Rather than protecting only MAP messages at the MAP-Network Entity (HLR.. It was also planned that the message format.) it is envisaged to protect all TCAP user messages (including MAP.002. VLR. 7 (SS7) Security Gateway. 17.204 Title/Contents WID(s) WID on Feasibility Study regarding the TCAPsec Gateway Concept WID on TCAPsec Gateway Function Impacted Specifications MAP stage 3 New Dedicated Specifications/Reports Signalling System No.9. However. Provision of an interception point for Spoof and Fake SMs. the most appropriate way to specify such functionality in 3GPP specifications. 23. 3GPP . functional description and protocol details (SS7 Security Gateway) Signalling System No. GSMA IREG have requested to complete the work on MAPsec and to a support the use of gateways (see N4-041252). gsmSCF. It recommends enhancements to MT SMS functionality be included in existing specifications (23. Conclusion: TR 23. 29. TR 29.12 Study on the TCAPsec Gateway concept UID_7025 Resources: C4 References Document CP-050687 CP-060170 TS 29. the Rel-4 MAPsec suffered from low acceptance from vendors and operators. Architecture. so that it can protect other protocols in addition to MAP. the Non-Transparent Mode as defined in TR 23. Furthermore. with changes needed in every MAP NE. where further steps were suggested.840 is not recommended.003). Due to the drawbacks of no support for true delivery reports and no support for handling of SMS with the Priority bit field set. SGSN. security header. etc. Creating a new specification risks harming inter-working with existing SMS functionality that should be avoided.800 TS 29.800 analyzes the impact of the TCAPsec gateway concept on the stage 3 work and proposes the most efficient solution for the implementation.128 Overview of 3GPP Release 7 V0.040. EIR. This study determined: • • the most efficient solution for the implementation of the T-SMSC in the MT-SMs transfer procedure. SA3 have re-initiated the work for Rel-7. The security mechanism applies by the gateway above the TCAP layer. 3GPP should examine the desirability of producing a standardized solution for the termination of Short Messages (SMs) in the HPLMN of the receiving MS via an SMS-SC-like logical entity. CAP and possibly others) at an SS7 Security Gateway which is located at the PLMN's border. 7 (SS7) security gateway.10 (2010-06) • • Addition of new value added capabilities such as "SMs Forwarding". Architecture. GGSN. automatic key management was not finalised.. MAPsec is difficult to set up and operate in a large scale. It recommends defining the Transparent Mode architecture in 3GPP.002 TR 29. The analysis is based among others on the following necessary changes to the MAPsec concept identified by SA3: • • The gateway concept includes two ‘protection profiles’: ‘Integrity only' and ’integrity and confidentiality’. from the MAPsec Rel-4 specification can be re-used. would allow network operators to secure SS7 connections for all MAP messages passing between them.

801 evaluates the benefits of M2PA (MTP2 User Peer-to-Peer Adaptation Layer) compared to M3UA (MTP3 User Adaptation Layer) and the possibility of introducing M2PA in 3GPP and specify the functionalities required on the protocol level to meet the requirements of BICC. and protocol details regarding the SS7 Security Gateway. 3GPP does not define an interworking scenario for SIP-I interworking into the bearer independent CS network. In order to avoid the use of a heavyweight interworking function and to provide commonality of products between wireless and wireline networks. the majority of the networks (fixed telephony.802 (G)MSC-S – (G)MSC-S Nc Interface based on the SIP-I protocol As the industry moves from Voice over TDM to Voice over IP. enterprise.10 (2010-06) • • Explicit verification of SCCP and MAP-payload addresses against MAPsec SPI was studied. although this is a valid interworking scenario. This implementation provides the additional benefits of: 3GPP .800 evaluates the feasibility of an SS7 Security Gateway concept and temporarily contains its functional description.14 Study on Support of (G)MSC-S .(G)MSC-S Nc Interface based on the SIP-I protocol UID_320018 Resources: C4 References Document CP-070034 Title/Contents WID(s) WID on Study of Support of (G)MSC-S – (G)MSC-S Nc Interface based on the SIP-I protocol Impacted Specifications New Dedicated Specifications/Reports TR 29.129 Overview of 3GPP Release 7 V0. A solution was found. 17. and protocol details. It covers network architecture. in co-operation with the specification manager.g. At the same time specific material related to MAPsec was removed from Rel-7 TS 29.801 Feasibility study of using M2PA in 3GPP networks TR 29. TS 29. Solution 2 (introducing enhanced M3UA) depends on the progress in IETF. routeing considerations. IMS) are moving towards SIP-based signalling.204 covers network architecture. TR 29. Addition in TS 29.9.002. The TR 29. Currently. MAP and CAP. routeing considerations. 17.202 of M2PA in 3GPP IP based signalling networks for interface B may be considered in the future. to ‘delete’ the MAPsec Rel-4 NE-based solution from the 3GPP specs. The MAPsec gateway concept and the MAPsec Rel-4 NE-based solution need not coexist. or to make it clear in the gateway specifications that interworking with the MAPsec Rel-4 NE-based solution is not supported. TR 29.13 Study on using M2PA in 3GPP network UID_7050 Resources: C4 References Document WID(s) CP-060698 Feasibility study of using M2PA in 3GPP network Title/Contents Impacted Specifications None New Dedicated Specifications/Reports TR 29. Conclusion: Solution 1 (introducing M2PA) is a recommended option that can be used in 3GPP IP based signalling networks for interface B. e.204 under the implementation work item UID_310005 TCAPsec Gateway.802 investigates the implementation of SIP-I on the Nc Interface as an alternative protocol to BICC.800 content was moved into a new TS 29.

802 should be used as a basis for future work in Rel-8.9. e.g. SCUDIF. Stage 2 and 3 should be specified in existing and new specifications as defined in Annex A.15 Study on SOAP/HTTP IRP Solution Sets UID_35066 Resources: S5 References Document SP-050610 TR 32. Identifies impacts and provides support for interworking SIP-I on the Nc interface with a BICC-based Nc interface and with 3GPP IMS. Starting with Service Management implementation should allow a smooth transition and to gain experience. a particular focus should be set on Service Management but this shouldn't be restrictive. Conclusion: SIP-I based Nc interface is an alternative feasible option to the existing BICC definition. Provides migration of PLMN to common NGN based SIP signalling. Eases interworking issues for IP-Interconnect and converges SIP-I signalling across the industry. Standardizing end to end service between mobile subscribers that may be located in different networks.809 Title/Contents WID(s) WID on Study of SOAP/HTTP IRP Solution Sets Impacted Specifications - New Dedicated Specifications/Reports Feasibility study of XML-based (SOAP/HTTP) IRP solution sets Integration Reference Points (IRPs) need to be extended with the introduction of SOAP/HTTP Solution Sets in order to respond to the growing market and industry demand for such lightweight solutions over the Itf-N. This study concludes that SA5 should go ahead with the use of XML-Based Solution Sets beyond Release 7. For a start. Identifies and resolves impacts related to effects on existing functional capabilities provided by the existing 3GPP BICC implementation (OoBTC.10 (2010-06) • • • • • Providing a standardized SIP-I based Nc Interface which improves network interconnections by removing potential signalling interworking to external SIP-I networks.g. 3GPP . TR 29.802: • • • • • Defines a scenario for providing SIP-I on the Nc Interface interworking with an external SIP-I based signalling network. CORBA. Defines SIP-I on the Nc Interface in order to provide interworking. as additional choice to e. CSD. support of codec negotiation over IP transit network to enable TrFO. Network Resource Model and Data Definition IRPs based on SOAP/HTTP technology. SCUDIF etc. 17.) by providing SIP-I on the Nc Interface. TR 29.130 Overview of 3GPP Release 7 V0. Identifies and resolves impacts related to effects on the user plane by providing SIP-I on the Nc Interface. wireless and wireline. etc. Reduces Capital Expenditure (CAPEX) for Operators and inter-operator agreements regarding interworking functionality. This TR studies the need to specify a new Solution Set for all Interface.

131 Overview of 3GPP Release 7 V0. RO/RW access support. The study provides a template for Itf-N implementation conformance test.810 Title/Contents WID(s) WID on Study of IRP Information Model Impacted Specifications - New Dedicated Specifications/Reports Information model Integration Reference Point (IRP) Study Currently there is no standard interface specified for how the Network Manager Centre (NMC) may access details of Network Element Manager (NEM) IM. NRM Information Object Classes (IOC). there is currently no 3GPP Implementation Conformance Statement (ICS) specification available for testing a vendor’s Itf-N product. 3GPP .16 Study on Itf-N Implementation Conformance Statement (ICS) template UID_35067 Resources: S5 References Document SP-050609 TR 32.g.812 Title/Contents WID(s) WID on Study of Itf-N Implementation Conformance Statement (ICS) template Impacted Specifications - New Dedicated Specifications/Reports Itf-N Implementation Conformance Statement (ICS) template Interface-N (Itf-N) is the interface between the Network and the Network Manager (NM).17 Study on IRP Information Mode UID_35068 Resources: S5 References Document SP-050611 TR 32. notifications supported etc. The IM should provide the type of information currently specified in IRP and NRMs IS level specifications. it would be advantageous if a standard interface is specified for an NEM to be able to access an NEM’s Information Model (IM) realization. The TR studies the possibility of specifying an IM IRP enabling an IRPManager to read an IRPAgent's vendor-specific IM view over Itf-N. Typically an NMC will be required to interface to several NEMs from different vendors. A few SA5 studies had been moved from Release 7 to Release 8 as follows: • • • Study of Element Operations Systems Function (EOSF) definition UID_35065 Study of SA5 MTOSI XML Harmonization UID_35074 Study of Common Profile Storage (CPS) Framework of User Data for network services and management UID_320006 17. It defines the structure and table format for the ICS on the Information Service (IS) and CORBA solution set level. attribute valid values. containment. e. Details of vendor specific extensions are not included. naming. However. To simplify NM operations.10 (2010-06) 17. each of which may support variants and vendor specific extensions to the standard NRMs for CM and PM. attributes. Vendors have developed products in compliance with different versions of these specifications. 3GPP has produced several IRP specifications for 3G networks' OAM&P. The same applies to Performance Management (PM) NRMs. Currently this type of information is just specified in Configuration Management (CM) IRP Network Resource Models (NRM) specifications for standard NRMs.9.

18 Study on Evolved UTRA and UTRAN UID_20023 Resources: RP References Document RP-040461 TR 25.xyz NRM specifications.132 Overview of 3GPP Release 7 V0. introduction of new transmission schemes and advanced multi-antenna technologies Related to the radio interface layer 2 and 3: e. means to support flexible transmission bandwidth up to 20 MHz. lowlatency and packet-optimized radio-access technology. At the same time.9. The study gives a framework for the evolution of the 3GPP radio-access technology towards a high-data-rate. Studied areas: • • • • Related to the radio-interface physical layer (downlink and uplink): e.813 TR 25. Radio interface protocol aspects Physical layer aspect for evolved Universal Terrestrial Radio Access (UTRA) Requirements for Evolved UTRA (E-UTRA) and Evolved UTRAN (E-UTRAN) With enhancements such as HSDPA and Enhanced Uplink. signalling optimization Related to the UTRAN architecture: identify the most optimum UTRAN network architecture and functional split between RAN network nodes. How IM Discovery might be able to address the challenges of OAM&P for an LTE enabled network could be further studied in Release 8 as part of the SA5 LTE feasibility study. This study concludes that there are diverging views on being able to provide the IM at run-time.814 TR 25. so that the standard models and capabilities can be expressed in formal and machine readable way.g. Important parts of such a long-term evolution include reduced latency. UML Profile).g. It focuses on supporting services provided from the PS-domain.g. More work is needed and other approaches might be better (e. In order to achieve this. Application and implementation of IM is feasible.e.g. The IM IRP service needs to cover all IRP views. to ensure competitiveness in an even longer time frame. i. support for transmission bandwidths of 5MHz and less than 5MHz should be investigated in order to allow for more flexibility in whichever frequency bands the system may be deployed in. Immediate benefit could be to apply the IM IRP to some of the existing 32. 100 Mbps (downlink) and 50 Mbps (uplink) Increase "cell edge bitrate" whilst maintaining same site locations as deployed today 3GPP . higher user data rates. However.912 TR 25. improved system capacity and coverage. and reduced cost for the operator. 17.10 (2010-06) The scope of the IM covers 3GPP generic and vendor-specific objects/data. the 3GPP radio-access technology will be highly competitive for several years. is questioned by some. for the next 10 years and beyond. not precluding considerations on the functional split between UTRAN and CN (SA2 experts should be invited to the latter topic) RF-related issues Targets for the evolution of the radio-interface and radio-access network architecture: • • Significantly increased peak data rate e. It is recommended that IM discovery should be further studied in Release 8 as part of the SA5 LTE feasibility study. Also applying IM and getting the benefits from legacy Network Elements. a long-term evolution of the 3GPP radio-access technology needs to be considered.913 Title/Contents WID(s) WID on Study on Evolved UTRA and UTRAN Impacted Specifications - New Dedicated Specifications/Reports Feasibility study for evolved Universal Terrestrial Radio Access (UTRA) and Universal Terrestrial Radio Access Network (UTRAN) Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN). an evolution of the radio interface as well as the radio network architecture should be considered. Considering a desire for even higher data rates and also taking into account future additional 3G spectrum allocations the long-term 3GPP evolution should include an evolution towards support for wider transmission bandwidth than 5 MHz.

cost. and power consumption.133 Overview of 3GPP Release 7 V0.25. e. Support of further enhanced IMS and core network Backwards compatibility is highly desirable. but the trade off versus performance and/or capability enhancements should be carefully considered. The aim of the study was to: 1. identify realistic propagation conditions and multipath models for high speed train environments decide on the need to perform simulations of the UE behaviour for speeds up to 350 km/h in high speed train environments including HSDPA decide on the need to define minimum performance requirements for the UE and the network assuming high speed train environments with speeds up to 350 km/h Identify impact to other groups Completed items: • • • • Deployment scenarios agreed Simulation results presented for ideal receivers Agreed that same performance can be achieved by ideal HSDPA UEs at 350 km/h vs. Status Report in RP-060472 17.9.g.5 MHz: to allow flexibility in narrow spectral allocations where the system may be deployed Support for inter-working with existing 3G systems and non-3GPP specified systems Further enhanced MBMS Reduced CAPEX and OPEX including backhaul Cost effective migration from Rel-6 UTRA radio interface and architecture Reasonable system and terminal complexity. including the possibility to exchange user-plane data starting from camped-state with a transition time of less than 100 ms (excluding downlink paging delay) Scaleable bandwidth: a) 5. 10. Presence) System should be optimized for low mobile speed but also support high mobile speed Operation in paired and unpaired spectrum should not be precluded Possibility for simplified co-existence between operators in adjacent bands as well as cross-border co-existence Conclusion: Rel-8 implementation WI to be started RAN#33 (Sep 2006) completed. 3. 4. Efficient support of the various types of services.] 2. Voice over IP. especially from the PS domain (e.UE) below 10 ms Significantly reduced C-plane latency. 3GPP . 2-4 x Rel6) Possibility for a Radio-access network latency (user-plane UE – RNC (or corresponding node above Node B) . In order to ensure a certain level of performance in terms of appropriate data rates (throughput) and QoS for the user in mobility environments with higher speeds. 2. 120 km/h Agreed that there is an issue with Doppler shift variation relating to channel estimation that needs to be considered further as part of the TEI work item.19 Study on Performance Evaluation of the UE behaviour in high speed trains UID_20034 Resources: R4 References Document RP-050146 - Title/Contents WID(s) WID on Performance Evaluation of the UE behaviour in high speed trains with speeds up to 350 kmph Impacted Specifications - New Dedicated Specifications/Reports - UE behaviour in high mobility environments is described in the current specifications up 250 km/h and 120 km/h for HSDPA.g. b) [1.10 (2010-06) • • • • • • • • • • • • • • • Significantly improved spectrum efficiency ( e.g. 20 and possibly 15 MHz.

Impact on RRM measurements. Furthermore. Three standardization alternatives were considered and as a summary the following can be stated: 3GPP .818 regarding the following key aspects: 1) Feasibility of splitting the radio requirements between BS and TMA 2) Feasibility of standardization alternatives. this parameter split is non-trivial and would need to be reconsidered for each operating band and for each TMA gain alternative. a single set of UTRA FDD TMA requirements supporting all BS configurations or multiple sets of requirements) Impact on current specifications TS 25. which need to be standardized for external low noise Tower Mounted Amplifier (TMA) in Rx for UTRA FDD. Impact on conformance testing and overall system responsibility. for deriving the TMA IMD requirements a set of interference scenarios would need to be considered and their respective IMD levels would need to be agreed and split between the BS and TMA. Alternatives how UTRA FDD TMA radio requirements could be standardized. Regarding aspect 1) it was observed that a number of radio performance related parameters would need to be split between BS and TMA. Then any minimum performance requirements defined for the BS+TMA chain can only be ensured for the assumed range of feeder losses. This would require detailed investigations for the TMA+BS receive / transmit chain in a possible WI.818 WID on UTRA Tower Mounted Amplifier (FDD) Title/Contents Impacted Specifications - New Dedicated Specifications/Reports UTRA tower mounted amplifier (FDD) study item technical report Objectives of the study: • • • • • • • Identification of the radio requirements. In particular.20 Study on UTRA Tower Mounted Amplifier (FDD) UID_20041 Resources: R4 References Document WID(s) RAN_Study_Items_History TR 25.141. Status Report in RP-060412 17.134 Overview of 3GPP Release 7 V0.g.104.9. The feeder loss between BS and TMA also needs to be taken into account when defining the radio requirements for BS and TMA. and TR 25.10 (2010-06) RAN#32 (Jun 2006) completed.942. There exist different options for the split of the performance between the BS and the TMA. However. That is true not only for the TMA gain but also for linearity in the TMA amplifier as well as the filtering in the TMA. including conformance testing and system responsibilities 3) Impact on Radio Resource Management requirements. TS 25. as otherwise there would be no defined performance for the BS+TMA chain. it was generally noted that the BS-TMA interface needs to be specified for both. In order to cope with all different solutions the TMA would have to fulfil the worst case scenario or the base station requirements would have to be tightened for some vendors to be compatible with all TMAs. IP3) or having a number of IMD test cases. the BS and TMA if the inter-working of BS and TMA of different vendors should be facilitated by 3GPP standards. The feasibility of splitting the radio requirements between base station and UTRA FDD TMA. No meaningful TMA specification can be developed without such a radio parameter split. How to structure UTRA FDD TMA radio requirements (e. Regarding aspect 2). there seems to be no other way in setting TMA IMD requirements than specifying either the details of the TMA receiver implementation (RX filters. The feasibility of standardizing the BS – TMA interface was studied in TR 25. This would either drive the cost for the TMA or the base stations or it would be a solution with a lot of options which would not guarantee interoperability.

This study proposes to reduce the impact of control channels on uplink noise rise while maintaining the connections and allowing a much faster reactivation for temporarily inactive users. So the corresponding overhead in the noise rise caused by maintained control channels significantly limits the number of users that can be efficiently supported. and avoiding frequent connection termination and re-establishment with its inherent overhead and delay. for all considered frequency bands. Alternative 3: A multiple set of radio parameters has to be split between different BS and TMA implementations.10 (2010-06) - Alternative 1: Not a standardized solution at all. To support a high number of HSDPA users in the code limited downlink the feature F-DPCH was introduced in Rel-6. but the conclusions drawn in this study still apply. TMA solutions as to the current date are either vendor specific delivered as a whole site solution or are proprietary from different suppliers and hence a mix of TMA and base stations of different supplier is not possible without loosing flexibility for the operator. meaning that it does not allow nor guarantee interoperability and therefore does not make sense for vendors or operators. That means a non-trivial work which requires a considerable amount of standardization work. This study proposes different alternatives how external low noise RX amplifier radio requirements for UTRA FDD could be standardized. reducing the system noise figure and improving the sensitivity of the Node B. In the uplink. The TMA has currently a vendor specific performance and characteristic. RAN#31 (Mar 2006) completed. TS 25.141).g. For such a high number of users in the cell it can be assumed that many users are not transmitting any user data for some time (e.21 Study on Continuous connectivity for packet data users UID_20044 Resources: R1 References Document WID(s) RP-050391 WID on Continuous connectivity for packet data users Title/Contents Impacted Specifications - New Dedicated Specifications/Reports - Packet-oriented features like HSDPA and E-DCH in WCDMA/UMTS systems promotes the subscribers’ desire for continuous connectivity. This would either be a solution with a number of non-interoperable options or drive the cost for the TMA or the base stations. which seems difficult to handle within a reasonable WI time plan. where the user stays connected over a long time span with only occasional active periods of data transmission. whereas the overall system performance is covered by requirements and tests according to the concept of different test ports (TS 25.135 Overview of 3GPP Release 7 V0. Tower Mounted Amplifiers (TMA) are external low noise RX amplifier and are an important part of the radio network. Status Report in RP-060035 17. a filter or the combination of such devices is used. If any external apparatus such as RX amplifier. Radio characteristics are specified at the BS antenna connector. As completely releasing dedicated channels during periods of traffic inactivity would cause considerable delays for re-establishing data transmission and a corresponding bad user perception. for reading during web browsing). This configuration is even more complex and would require further analysis. requirements apply at the far end antenna connector. GSM in Band VIII) was outside the scope of the SI.9. the limiting factor for supporting a similarly high number of E-DCH users is the noise rise.104. It should be noted that the impact on TMA radio requirements related to antenna feeder sharing with other systems (e. 3GPP .g. Alternative 2: Jeopardizes overall system performance and might even violate regulatory requirements and is therefore not acceptable.

Non DL-only carrier with SFN (TDD only).9.905 Title/Contents WID(s) WID on Improvement of the Multimedia Broadcast Multicast Service (MBMS) in UTRAN Impacted Specifications - New Dedicated Specifications/Reports Feasibility study on improvement of the Multimedia Broadcast / Multicast Service (MBMS) in UTRAN The study recommends considering the following principles in any new WI for improvement of MBMS in UTRAN.10 (2010-06) It proposes RAN1 to start an implementation WI. and throughputs. HSDPA and HSUPA are very important capabilities for operators. including operation on SFN. most notably outdoor micro-cells (with at least some users indoor and in building pico-cells. Status Report in RP-060692 17.136 Overview of 3GPP Release 7 V0. Full mobility/paging etc.23 Study on Performance Improvements in Small Cells using HSDPA/EDCH UID_20052 Resources: R4 References Document RP-050782 - Title/Contents WID(s) WID on Performance Improvements in Small Cells using HSDPA/EDCH Impacted Specifications - New Dedicated Specifications/Reports - There is a need to investigate the possibilities to further enhance the ability of HSDPA/HSUPA in certain deployed environments beyond the macro cellular case.22 Study on Improvement of Multimedia Broadcast Multicast Service (MBMS) in UTRAN UID_20051 Resources: R2 References Document RP-050746 TR 25. The UE in these situations may not be the typical hand held terminal but could be embedded 3GPP . This covers the following cases: • • • • • Additional DL carrier without SFN. Additional DL-only carrier with or without SFN. Status report in RP-050427 17. Additional binded DL-only carriers with or without SFN (LCR TDD only). This is especially important in smaller cells with lower mobility and "contained" environments. This is especially relevant when 3GPP technologies compete against technologies deployed specifically to serve contained environments. Simultaneous reception on different carriers is possible. support should be provided by all UEs without mandating 2 LO. RAN#34 (Dec 2006) completed. Additional DL-only carriers with or without SFN binded with Non DL-only carrier (LCR TDD only). Further RAN4 study is expected to better understand issues relating to simultaneous reception on different carriers. rates. It is critical that performance of these channels especially in environments and deployment scenarios that are not macro cell based be maximized for a wide range of data services. RAN#29 (Sep 2006) completed. but not mandated from the UEs.

based on well-known and widely accepted techniques. Such methods are both better understood and more practical than they have been in the past. The objective was to establish and characterize the small cell and/or contained environments that are of greatest operator interest. Improvements based on cancellation or rejection of other-cell interference have not been included yet.9. 2. The network scenarios and interference models have much in common for 1-branch and 2-branch methods. 2-branch receive diversity. Evaluate the feasibility. and there is now work showing substantial potential gains from other-cell interference cancellation. to evaluate the feasibility and potential gains at link and system level to investigate the metrics and other aspects of specifying UE performance Objectives: • • • Develop realistic network scenarios and interference models and investigate practical metrics that could be used to specify performance based on interference mitigation.10 (2010-06) implementations inside computers. So performance improvement in lowgeometry is still an important priority. but this aspect has not been included to date in the work item based on 2-branch equalization. The selected environment should be sufficiently characterized to enable accurate simulation of advanced W-CDMA technologies in the environment.and high-geometry cases. interference cancellation performance has been specified for single branch receivers. Evaluate feasibility.24 Study on Further Improved Performance Requirements for UMTS/HSDPA UE (FDD) UID_20053 Resources: R4 References Document RP-050880 TR 25. So there is an opportunity for significant gain. Joint detection methods have been developed for UTRA FDD uplink receivers and UTRA TDD receivers. RAN#32 (Jun 2006) closed (no progress). Conclusion: Small gain was noted on Single Branch Receivers 3GPP . link performance. but UE design issues may affect deployment. Equalization is primarily useful in case of high geometry. Status Report in RP-060263 17. The improvements specified so far have been for thermal noise and noise-like inter-cell interference.963 Title/Contents WID(s) WID on Further Improved Performance Requirements for UMTS/HSDPA UE (FDD) Impacted Specifications - New Dedicated Specifications/Reports Feasibility study on interference cancellation for UTRA FDD User Equipment (UE) For UTRA FDD performance specifications have been developed for UE receivers on the basis of equalization and. study of both singlebranch and two-branch interference mitigation for UTRA FDD had been started. It is well-known that 2-antenna receivers using algorithms such as space-temporal equalization can reject other-cell interference.137 Overview of 3GPP Release 7 V0. For GSM radio access. and intra-cell interference caused by multipath. and system capacity potential of 1 branch interference mitigation with realistic network scenarios and interference models. most notably those using multiple antennas at the UE and/or Node B. Since the basic performance improvements from diversity and equalization have been addressed in previous work. and system capacity potential of 2 branch interference mitigation with realistic network scenarios and interference models. or a PCMCIA type data card (or other diverse form factors) which may be more amenable to embodiment of the improvements. link performance. The number of environments and use cases should be limited in order to allow expeditious completion. particularly for single-antenna UE. with two goals: 1. for HSDPA. Diversity is useful in both low. Contributions have been made showing the link-level performance benefit of single-branch interference cancellation for UTRA FDD UE receivers. if the interference rejection aspect can be evaluated and specified.

HSPA operators are just as interested in the potential performance and cost savings which may be achieved through HSPA evolution in a 5MHz bandwidth as they are in the future LTE system. A number of Work Items listed in section 15 are already open to define potential enhancements to the HSPA standard and these need to be taken into consideration. The tradeoffs necessary to achieve performance comparable to LTE in 5 MHz should be analyzed. peak data rate and latency should continue to evolve. Evolved HSPA should be able to operate as a packet-only network based on utilization of Shared Channels only. Define constraints in terms of acceptable network architecture changes. e) f) Identify potential solutions to improve HSPA performance towards the agreed targets within the defined constraints. The interworking between HSPA Evolution and LTE should be as smooth as possible from one technology to the next and should facilitate joint technology operation. Make recommendations for future and possible revisions of ongoing WIs related to HSPA. HSPA networks form an integral part of 3G systems and must provide a smooth path towards LTE. existing infrastructure should only need a simple upgrade to support the features defined as part of the HSPA Evolution. Results: • Defined a broad framework for HSPA evolution 3GPP . Objectives of the study: a) c) Define a broad framework for HSPA Evolution Targets for improvements in latency. throughput and spectrum efficiency utilising the existing 5MHz bandwidth Define constraints in terms of acceptable hardware and software changes to current elements {UE. Node.25 Study on Scope of future FDD HSPA Evolution UID_20065 Resources: RP References Document RP-060217 TR 25. Ideally.999 Title/Contents WID(s) WID on Scope of future FDD HSPA Evolution Impacted Specifications - New Dedicated Specifications/Reports High Speed Packet Access (HSPA) evolution.138 Overview of 3GPP Release 7 V0. Status Report in RP-070499 17. Frequency Division Duplex (FDD) The importance to enhance the capabilities and performance of HSPA-based radio networks is widely recognised. RNC. SGSN and GGSN}. Guiding principles considered: • • • • • HSPA spectrum efficiency. Determine what performance benefit is achieved by the existing WIs b) Define a set of requirements for HSPA Evolution covering: d) HSPA Evolution shall be backward compatible in the sense that legacy terminals (R99-DCH and HSPA mobiles) are able to share the same carrier with terminals implementing the latest features of the HSPA Evolution track without any performance degradation.10 (2010-06) RAN#36 (May 2007) completed.9. HSPA Evolution shall be backward compatible in the sense that legacy terminals (R99-DCH and HSPA mobiles) are able to share the same carrier with terminals implementing the latest features of the HSPA Evolution track without any performance degradation.

c) RAN2 to investigate additional signalling which may be beneficial to support UEs in the decision making process for reducing their performance. for example to reduce receiver power consumption. Status Report in RP-070533 17. UID_330013 Resources: R4 References Document RP-060641 Title/Contents WID(s) WID on Dynamically reconfiguring a FDD UE receiver to reduce power consumption when desired Quality of Service is met Impacted Specifications TR 25.27 Study on GAN Enhancements (EGAN) UID_50120 Resources: GP References Document WID(s) GP-062298 WID on GAN Enhancements Title/Contents Impacted Specifications New Dedicated Specifications/Reports TR 43. RAN4 should also identify scenarios in which UE receiver performance reduction cannot safely be performed. RAN#37 (Sep 2007) completed.9. The purpose of these scenarios is to ensure that UE performance is not degraded when conditions are not suitable.. or minimal impact to the overall UTRAN system level performance or user experience. procedures related to receiver reconfiguration for non-MBMS channels should not be specified in 3GPP. However. RAN#37 (Sep 2007) completed.. The objectives of this study item are: a) RAN4 to identify whether there are situations in which individual UE receiver performance reduction has no.26 Study on Dynamically reconfiguring a FDD UE . b) RAN4 to investigate scenarios for the identified situations where the UE could reduce its performance. Status Report in RP-070534 17. The purpose of this study item is to investigate how and whether it is this kind of performance reductions could be done in a controlled way. Conclusion: Under certain reception conditions benefits could be achieved with negligible impact on system level performance in non-MBMS scenarios. so that the overall UTRAN system benefits of enhanced receiver performance requirements are not lost.902 Enhanced Generic Access Networks Study (EGAN) 3GPP .10 (2010-06) • Identified potential solutions to improve HSPA performance towards the agreed targets within the defined constraints. it may be desirable to allow UEs supporting enhanced performance requirements to reduce their performance to TS25.906 - New Dedicated Specifications/Reports Dynamically reconfiguring a Frequency Division Duplex (FDD) User Equipment (UE) receiver to reduce power consumption when desired Quality of Service (QoS) is met In certain conditions.139 Overview of 3GPP Release 7 V0. for example quality thresholds which assist the UE in determining that conditions are suitable to reduce receiver performance.101 minimum performance requirements.

Conversational services like Voice over IP (VoIP) and enhanced Push-to-talk over Cellular (PoC). • • 3GPP . TR 43. throughput is limited by the TCP window size divided by the round trip time.140 Overview of 3GPP Release 7 V0. on-line gaming services typically have high requirements on latency and fast access. evolving further the GERAN radio interface needs to be studied to ensure not only that the same services are available regardless of the underlying radio technology UTRAN or GERAN. In order to leverage the investments made in GERAN infrastructure. Such an evolution is also needed to maintain GERAN competitiveness as well as UTRAN competitiveness.g. but also gain from reduced latency. a need for enhancements has been identified by LS from SA1 in terms of architectural and performance in order to: • • • • Offer both full services for 2G and 3G subscribers Offer seamless handovers with full service continuity between 2G/3G networks and GAN Reduce protocol overhead and latency for PS services. Enhance service continuity with other RAT. e. e.912 Feasibility study for evolved GSM/EDGE Radio Access Network (GERAN) TR 45.g. file download and image or video clip upload) typically gain from increased mean bit rates. etc. and recommends the specification of GAN Iu mode in Release 8.902 evaluates enhancement topics for GAN architecture and performance. but essentially that service continuity exists across these radio technologies supported by core network evolution e.9.912 studied the means for GERAN to: • • • • • Increase spectral efficiency. video-telephony is a service that needs (better) coverage for higher bit rates for both uplink and downlink.g.10 (2010-06) While 3GPP completed GAN specifications in April 2005 and first commercial deployments have emerged (end 2006).28 Study on Future GERAN Evolution (FGE) UID_50568 Main Resources: GP References Document GP-051052 Title/Contents WID(s) WID on Future GERAN Evolution Impacted Specifications - New Dedicated Specifications/Reports TR 45.g. as well as. While GERAN is being deployed worldwide also in emerging markets. All services may gain from improved coverage. Increase average data rates. • Interactive and Best-effort services (like web browsing. Some examples of services that were considered are given below. Reduce the cost of delivery of packet data services to enable profitable launches of new high volume data services. IMS. 17. Reduce latency between a mobile station and the GERAN. GERAN is a result of over a decade of radio interface evolution that is still ongoing. it was felt a priority to minimize the impacts on it. e. This study resulted in independent GERAN features. Increase capacity and coverage.

Based on the results. reduce latency. Link. as this may yield higher capacity. Also. There are also stand-alone GSM/EDGE networks. • A GSM/EDGE network may interoperate with WCDMA RAT. MS receive diversity offers the possibility of enhanced channel diversity and the potential for further improved interference cancellation performance for GMSK modulated signals. as seen from a radio performance perspective. the performance requirements and design constraints that the proposed features/candidates should take into account are provided by this study. high bit rates are required at the same time as robustness is important to fulfil coverage and latency requirements as well as providing interactivity. large gains are achieved even for high values of correlation and antenna gain imbalance. receive diversity enables significant gains for 8PSK-modulated signals. It has been noted that MSRD has significant impact on the MS hardware. 3GPP . The impact of these parameters using the MSRD channel models has been assessed as well as a small literature survey of publications related to the achievable performance MS receive diversity has been provided.9. This could potentially lead to reduce cost of provisioning and create a wider use of services. GSM/EDGE only networks can give their users an increased range of end-user services/applications and possibly make use of applications/services that do not require adaptations to access specific capabilities. although it is recognized that factors such as antenna performance and terminal design may impact the performance in a live network. GERAN#27 has approved a work item on MSRD characterised by DARP Phase II. That is. which improves the receiver performance of the MS by means of an additional antenna. Particular requirements may be set by services like broadcast TV over MBMS bearers. Typically.e. If non-compliant the reasons and consequences had to be detailed. Simulations and literature surveys have shown that considerable gains are achievable for both 8-PSK and GMSK modulated signals. Taking those into consideration would enable easy network evolution and be able to efficiently use existing network equipment and support legacy Mobile Stations. which includes antenna correlation and gain imbalance between the receiver antennas. TR 45.and system level simulations have been provided for speech services (AMR) and data services (EGPRS).10 (2010-06) • All services may gain from a Mobile Station (MS) always being connected to the most appropriate Base Station. i.912 conclusions and recommendations for Downlink: Mobile Station Receive Diversity (MSRD) is a downlink feature. A combined WCDMA & GSM/EDGE network may benefit from better service continuity between the accesses resulting in an easier resource utilization and service provisioning. As a general guideline. Each new candidate feature was requested to describe the compliance to the following relevant assumptions and prerequisites. due to improved interference conditions. as opposed to SAIC.141 Overview of 3GPP Release 7 V0. To study the performance in more detail a simple channel model was derived. The introduction of Single Antenna Interference Cancellation (SAIC) characterised by the Downlink Advanced Receiver Performance (DARP) requirements has already shown that receiver enhancements in the MS can provide significant gains in terms of spectral efficiency. etc. and may impact both terminal power consumption and size. Both the GSM/WCDMA networks and the GSM only networks may benefit from the increased GSM/EDGE service portfolio. Several contributions have shown the impact in terms of receiver performance for different architectures and in general it seems that the diversity receivers are relatively insensitive to parameter variations. either within an operator's network or with different operators.

it could be possible for a dual antenna terminal to switch between dual carrier reception and MS receive diversity.0 and 1.9 times higher bit rates at interference limited scenarios. The receiver complexity for DSR is about up to 50% more complex per bit than for 8PSK. in particular.g. narrower channel filter may be applied and oscillators are not needed to tune out of 200 kHz channel raster. The BTS receiver needs to cope with wider transmission bandwidth and could beneficially utilise the gain of interference rejection combining (IRC) for reception of dual symbol rate. The main benefit of MDSR is the narrower signal bandwidth of two 200 kHz GSM channels instead of three in the case of DSR. both peak and average user throughput are increased proportionally to the number of carriers.6 kbps for a single user.g. GERAN has approved a work item on REduced symbol Duration.g. the peak data rate would be close to 1 Mbps. with dual carrier. Based on the results of this study. peak and average bit rates can be increased in a very flexible and backwards-compatible manner.8 to 1. This could simplify dual transceiver implementation compared to DSR e. To meet peak throughput objectives. Dual Carrier in the Downlink has been shown to meet some of the performance objectives of GERAN Evolution (in particular it enables an increase in the peak downlink data rate) without impairing any of the other performance metrics.g. Dual Carrier in the Downlink can optionally be combined with MS Receive Diversity. GERAN has approved a work item on Dual Carrier in the Downlink. With a dual-carrier configuration.33 (4/3) times higher than the legacy symbol rate. Optimization of MDSR concept for single legacy TRX implementation may be done by removing the 100 kHz offset and reducing the symbol rate further e. Latency enhancements: four different enhancements were evaluated: • • Improved ACK/NACK reporting. it is considered acceptable in an initial phase to restrict the number of carriers to two. average bit rates in the order of 100 kbps to 200 kbps are feasible on four timeslots. Evolution in uplink bit rates is needed to support uploading of images or video from camera phones and also to maintain a balance in bit rates and in coverage with downlink enhancements e. With this feature. it is expected that it will have no impact on BSS hardware. 3GPP . to produce High Symbol Rate schemes (HSR). it satisfies all the compatibility objectives for candidate features. Both options offer about similar bit rates and performance in uplink e. With multicarrier. Higher Order modulation and Turbo coding (REDHOT) for downlink (see work item UID_50121). The feature is aimed at enabling higher data rates in GERAN with minimal impacts to infrastructure. Higher Order Modulation and Turbo Codes: the impact of introducing higher order modulation based on QAM and Turbo coding in EGPRS has been analyzed.10 (2010-06) Multi-carrier is a performance-enhancing feature whereby data to a single user can be transmitted on multiple carriers. Also. the theoretical peak data rate of EGPRS is 473. Dual symbol rate and modified dual symbol rate: this study proposed two alternative uplink concepts: Dual Symbol Rate (DSR) and Modified Dual Symbol Rate (MDSR) for future GERAN evolution to double bitrates in uplink.g.2 (6/5) or 1. DSR doubles the modulation rate in the transmitter of the MS and MDSR combines higher symbol rate (3/2) with 16QAM and optionally with QPSK. Given the current technical and implementation limitations. Currently. It is also anticipated that implementation in the MS is feasible.142 Overview of 3GPP Release 7 V0. The need for higher bit rates could make it desirable to support more than two carriers in future releases of the GERAN standards. Provided that the MS supports this capability.9 times higher average bit rates at coverage and 1.7 to 1. In a real network.9. 32QAM modulation would then be needed. The dual symbol rate applies to normal GSM frequency planning for all re-uses up to 1/1. e. Based on the results of this study.5 times higher symbol rates clearly exceed the given performance objectives on coverage and spectral efficiency but that two legacy TRX implementation option was not favoured. given that there are no changes to the modulation and to the coding schemes. to 1. 1. Simulations to evaluate link performance have taken reasonable practical impairments in the receiver and transmit implementations into consideration. It was found earlier that DSR and MDSR with 2. Reduced Transmission Time Interval (TTI).

Based on the results of this study. GERAN has approved a work item on LATency REDuction (LATRED) UID_50582. Adaptation between MS receiver diversity and dual-carrier. Modified MBMS Service.e. Based on the results of this study. Other aspects in TR 45. Uplink throughput enhancements with low standard impact. GERAN has approved a work item on Higher Uplink performance for GERAN Evolution (HUGE) UID_50584. The enhancements reduce overall latency and have a second order effect on mean/average and peak bit rates as reduced latency (i. lowering the round trip time) may provide better throughput if the bit rate on the link becomes so high that the maximum buffer window size limits the transmission rate. Enhancements to resource allocation. The reduced TTI and Variable sized radio blocks takes effect in both non-ideal radio conditions and ideal radio conditions. Hybrid ARQ.10 (2010-06) • • Variable sized Radio Blocks. 3GPP .9. as the number of re-transmissions is almost zero in ideal conditions. The improved ACK/NACK reporting and hybrid ARQ mainly provide reduced latency in non-ideal radio conditions.912 are: New burst structures and new slot formats.143 Overview of 3GPP Release 7 V0.

10 (2010-06) 18 Unique_I D 0 732097 Rel-7 Completed Items Name Release 7 Features Identification of Communication Services in IMS ServID S2.S 2 C1 S5 S2.9.C1 S1.C 1. W updated SP#32 - CP#32 approved WID - SP#29 approved WID SP#29 approved WID CP#32 approved WID - 377001 387001 TMMTEL7 MCIMSTR1 S1 S2 06/12/2007 06/12/2007 SP-070568 SP-070915 - Ericsson RP#43 complete Linked UID_703 (MTSI) - 387002 387003 32045 1314 MCIMSTR1S1 MCIMSTR1S2 EMC1 EMC1 S1 S2 S2.2 of GRUU Stage 3 of GRUU Multimedia Telephony Service for IMS Stage 1 of MTSI Stage 3 of MTSI Media handling and interaction in MTSI Multimedia Telephony Service for IMS (MTSI) .IMSlevel Emergency Call Enhancements for IP& PS Based Calls – stage 3 EMC1 EMC1 EMC1 EMC1 S2 S2 S2 C1 16/09/2005 08/12/2005 09/06/2006 15/06/2007 SP-050604 SP-050604 SP-050604 CP-050529 - Siemens Siemens Siemens Ericsson - 3GPP .C1.UE Conformance Testing TISPAN requirements for Multimedia Telephony with PSTN/ISDN simulation services Maintenance of TISPAN release 1 common IMS SA1 aspects of MCIMSTR1 SA2 aspects of MCIMSTR1 PS domain and IMS impacts for supporting IMS Emergency calls Service Requirements for IP-based emergency calls ServID ServID ServID ServID GRUU GRUU GRUU MTSI MTSI-REQ MTSI MTSI-MHI MTSIUEConTest 21/03/2006 31/05/2006 15/03/2007 14/09/2007 15/06/2007 29/09/2006 15/06/2007 15/06/2007 29/09/2006 14/06/2007 15/03/2007 12/03/2009 SP-060293 SP-060293 CP-060259 SP-060293 SP-050633 SP-050633 CP-060358 SP-060224 SP-060224 CP-060257 SP-060225 RP-080605 RP-090056 Ericsson Ericsson Ericsson Orange RIM RIM CableLabs Ericsson Ericsson Ericsson Ericsson Ericsson.S 1.2 of ServID Stage 3 of ServID Charging of ServID Supporting Globally Routable User Agent URIs in IMS Stage 1.S4 S1 C1 S4 R5 14/09/2007 SP-060293 Ericsson Acronym Res ourc e Finish Hyperlink Status_Rep ort rapporteu r Notes 32106 32107 320010 7035 32116 7010 320011 7038 7039 7037 7040 350147 TR on ServID Stage 1.S 1. Motorola WID approved SP#28.144 Overview of 3GPP Release 7 V0. S5 S2 S1.S 1 S1 06/12/2007 06/12/2007 15/06/2007 25/06/2004 SP-070915 SP-070915 SP-050604 SP-050604 - Telecom Italia Ericsson Siemens Siemens - 32046 32080 32100 1653 Study on Stage 2 for IMS-level solution Study on Stage 2 for GPRS-level solution Stage 2 Specification Phase .S 2 C1 S1.

9.Stage 3 CT1 aspets for WLAN-PNA CT3 aspets for WLAN-PNA Enhancements to support QoS provisioning over 3GPP/WLAN Interworking Stage 2 on support of QoS over 3GPP/WLAN interworking Stage 3 CT4 on support of QoS over 3GPP/WLAN Interworking Stage 3 CT1 on support of QoS over 3GPP/WLAN Interworking Location Services enhancements WLAN-SC WLAN-SC WLANPNA WLANPNAst2 WLANPNAst3 WLANPNAst3 WLANPNAst3 WLANQOS S1 S2 S2.Stage 2 WLAN-PNA .10 (2010-06) 15/06/2007 15/06/2007 01/06/2007 15/03/2007 06/12/2007 07/06/2005 CP-050529 CP-050529 CP-050529 CP-070120 SP-050089 SP-030712 Ericsson Ericsson Ericsson AlcatelLucent AlcatelLucent Telenor - CP#35 revised W - 31057 32096 32110 32111 11059 11064 13027 32092 Stage 1 on Session Continuity Stage 2 on Session Continuity: covered by SAE WLAN Interworking – Private Network access from WLAN 3GPP IP Access WLAN-PNA .C4.C 3.145 1315 1646 14026 11065 34033 31062 CT1 IMS aspects to support IMS Emergency sessions CT1 PS domain aspects to support IMS Emergency sessions CT4 PS domain aspects to support IMS Emergency sessions IMS Support of Conferencing Performance Characterization of VoIMS over HSDPA\EUL channels WLAN-UMTS Interworking Phase 2 EMC1 EMC1 EMC1GPRSc4 IMSconf VoIMSPCVoIMS WLAN2 C1 C1 C4 C1 S4 S1 Overview of 3GPP Release 7 V0. - 20012 Inclusion of Uplink TDOA UE positioning method in the UTRAN specifications LCS for 3GPP Interworking WLAN FS on 3GPP system to WLAN Interworking with LCS Stage 2 for LCS architecture for IWLAN MBMS Enhancements R2 17/12/2007 RP-040387 RP-070797 TruePositi on Telcordia Telcordia LG Electronic s China Mobile 31052 32077 340007 31084 S1 S1 S2 S1 02/03/2007 30/06/2006 02/03/2007 30/11/2007 SP-060291 SP-060291 SP-060818 SP-050389 - Complete Sept 200 SR in RP 060459 Complete Nov 2007 SR in RP 070797 WID at SP#55 - 3GPP . R2 S2 GP C4 R2 30/06/2006 09/03/2007 30/11/2006 17/12/2007 SP-050682 CP-060418 CP-060418 SP-040682 - Samsung Huawei Huawei - Approved SP#29 Approved CP#29 Approved CP#29 Approved CP#29 Moved fr FS sectio Feb 06.Velocity LCS3 LCS3-LBS LCS3UEPos-LBS LCS3UEPosVelocity LCS3UEPosUTDOA LCS3IWLAN LCS3IWLANFSs1 LCS3IWLAN MBMSE 15/09/2006 31/08/2007 01/12/2006 15/09/2006 SP-050119 GP-050265 CP-050240 RP-050300 RP-060459 SiRF SiRF SiRF SiRF SP#27 approved WID.C4 C1 C3 S2. S 30 updat WID SP-30 updated WID CP-32 approved WID CP-32 approved WID - 32093 50558 14025 20042 Stage 2 for LCS3 (including IMS emergency location aspects) LCS Enhancements related to Location-Based Services CT4 aspects for LCS UEPos-LBS UE positioning .C 1.GP .S 2.C 4.C3.C1 11/06/2004 07/06/2005 26/09/2006 23/06/2006 26/09/2006 26/09/2006 26/09/2006 09/03/2007 SP-050489 SP-050489 CP-060256 CP-060256 CP-060256 SP-050682 - NEC NEC NEC NEC NEC Samsung Created TSG#27 because WLAN ite belongin Rel-7 - 7016 14028 340005 32079 WLANQOS WLANQOS WLANQOS LCS3 S2 C4 C1 S1. C4 S2 C1.

S 2.10 (2010-06) 08/12/2005 SP-050389 China Mobile 340042 MBMS FDD Physical layer Enhancements MBMSERANPhysFD D MBMSERANPhysTD D R1 04/06/2007 RP-070226 RP-070290 Ericsson Structure created b MCC to include R aspects under SA Feature Complete May 200 SR in RP 070290 340043 MBMS TDD Physical layer Enhancements R1 04/06/2007 RP-070241 RP-070291 IPWireless Complete May 200 SR in RP 070291 350022 MBMS Low Chip Rate TDD Physical Layer Enhancement MBMSERANPhysLC RTDD R1 10/09/2007 RP-070253 RP-070292 RITT Complete May 200 SR in RP 070292 - 340046 400058 MBMS Mz interface MBMS .UE Conformance Testing MBMSMz MBMSE_UE ConTest C3 R5 30/11/2007 04/12/2009 CP-070109 not applicable - Huawei - 25049 400059 Conformance Test Aspects – MBMS TDD Physical layer Enhancements – MBSFN for HCR and VHCR TDD Conformance Test Aspects – MBMS LCR TDD Physical Layer Enhancement Conformance Test Aspects – MBSFN for FDD 400060 MBMSERANPhysTD D_UEConTe st MBMSERANPhysLC RTDD_UEC onTest MBMSEUEConTest_ RANPhysFD D MBMSUSE LCS3AGNSS AGNSS-GP LCS3GNSSUTRAN R5 12/09/2008 RP-080155 RP-080541 IPWireless R5 18/09/2009 RP-080318 RP-090715 CATT Linked to Rel-7 Feature UID_310 (MBMSE SR in RP 080541.9.C3 Overview of 3GPP Release 7 V0.R 1.C 6 S1 C6 S1. RP#41 complete RP#45 complete R5 04/12/2009 RP-080336 RP-091214 Huawei RP#46 complete 34038 31051 50548 20050 MBMS User Service Extensions Advanced Global Navigation Satellite System (A-GNSS) concept Towards A-GNSS Concept Global Navigation Satellite System (GNSS) in UTRAN S4 S1.146 340041 Stage 1 of MBMSE MBMSE S1.R2 GP R2 07/06/2007 31/08/2007 31/08/2007 04/06/2007 SP-050838 SP-040681 GP 042677 RP-060211 RP-070482 Ericsson Alcatel Alcatel France Telecom - GP#36 complete Complete Sept 200 SR in RP 070482 50581 31048 31060 43008 31063 31064 32084 11054 34031 A-GPS Minimum Performance USSD message delivery and transfer to USIM Stage 1 Alignment with requirements regarding USSD usage Combinational Services Stage 1 for CSICS Stage 2 for CSICS Stage 3 for CSICS CN aspects Stage 3 for codec aspects GAGR USSD-USIM USSD-USIM USSD-USIM CSICS CSICS CSICS CSICS CSICSCodec GP S1.G P. S4 S1 S2 C1 S4 31/08/2007 12/08/2005 15/10/2004 12/08/2005 06/03/2006 09/06/2005 15/07/2005 06/03/2006 07/12/2005 GP-060834 SP-040104 SP-040104 TP-040069 SP-050228 SP-050228 SP-050228 CP-060105 SP-050091 - Spirent Axalto Axalto Axalto TeliaSoner a TeliaSoner a TeliaSoner a Vodafone Ericsson - 3GPP .C1.

C 4 S1 C4 S1 Overview of 3GPP Release 7 V0.9.C 4 C1 C4 G2 S1 S1 C1 C1 27/08/2004 15/06/2007 15/06/2007 10/03/2006 16/02/2007 15/03/2007 08/06/2005 14/03/2007 15/03/2007 SP-040304 CP-050528 CP-050528 GP-071855 SP-070167 SP-070167 NP-050141 NP-050141 - Siemens Siemens Siemens Siemens Siemens T-Mobile T-Mobile T-Mobile No CR submitte rel-8 (accordin to CR database No Rel-8 changes Moved fr Rel-6 UID_505 Enhance nts of VG in public networks commun on of pub authority officials Voice Gr Call Serv - Voice Gr Call Serv - 11063 31071 31072 43011 7017 15039 CT1 aspects of IVGCS OSA Rel-7 Service Requirements for OSA Service Broker Stage 2 OSA API Service Brokering Stage 3 OSA API Service Brokering OSA Stage 2/3 enhancements IVGCS OSA7 OSA7-SB OSA7-SB OSA7-SB OSA7 C1 S1.C4.10 (2010-06) 05/12/2005 05/12/2005 05/12/2005 13/03/2006 SP-040743 SP-040743 NP-040550 SP-050830 Nortel Nortel Nortel Telcordia - 320027 11045 Stage 1 for ISB Enhancements of VGCS for public authority officials ISB-s1 EVGCS S1 S1.147 31065 31066 14017 31088 CAMEL Trunk Triggers Stage 1 for CAMEL Trunk Triggers CAMEL Trunk Originated Trigger Detection Points IMS Service Brokering enhancements TTCAMEL TTCAMEL CamelR7 ISB S1. Completi 12/06 =>03/07 - 3GPP .C 1. G2 13/03/2006 15/06/2007 SP-050830 - - Telcordia - 31061 11056 11062 14022 752076 11055 31070 32090 11057 Stage 1 Architecture and protocol aspects CT1 aspects of EVGCS CT4 aspects of EVGCS GERAN2 aspects Improvements of VGCS for parallel use of services Service Requirements for VGCS improvements Stage 2 modifications for VGCS improvements Protocol aspects EVGCS EVGCS EVGCS EVGCS EVGCS IVGCS IVGCS IVGCS IVGCS S1 C1.C 5 S1 C5 C5 C5 15/03/2007 08/06/2007 08/06/2005 01/12/2006 01/12/2006 08/06/2007 CP-070118 SP-050183 SP-050183 CP-060607 CP-070200 - T-Mobile AePONA AePONA AePONA AePONA AePONA Previous name (before CT32) w Architect and proto aspects - az: WID URL corrected - 7018 7019 7020 340001 340002 340003 340004 Parlay X Message Broadcast Web Service Parlay X Geocoding Web Service Parlay X Application driven QoS Web Service Parlay-X Device Capabilities and Configuration Parlay-X Multimedia Streaming Session Management Web Service Parlay-X Multimedia Multicast Control Web Service OSA API Conference Call Control SCF OSA7 OSA7 OSA7 OSA7 OSA7 OSA7 OSA7 C5 C5 C5 C5 C5 C5 C5 01/12/2006 01/12/2006 09/03/2007 08/06/2007 09/03/2007 09/03/2007 09/03/2007 - - ETRI ETRI BT Telenor Telenor ETRI Ericsson CP#34: W updated.

C 1 S2 C1 S2. "Acces Security Enhance nts".S5.UE Conformance Testing NSP-CR NSPCR_UECon Test C1 R5 15/06/2007 05/12/2008 CP-060357 RP-080135 RP-080819 Motorola Nokia - 32064 32065 11048 32074 Access Class Barring and Overload Protection TR on Stage 2 Stage 3 CN aspects of ACBOP System enhancements for fixed broadband access to IMS TISPAN Rel 1 related aspects Stage 2 of FBI for TISPAN R1 Protocol impact of FBI for TISPAN R1 CT1 aspects of FBI for TISPAN R1 ACBOP ACBOP ACBOP FBI S2.Sultan - 32094 FS on SMSIP SMSIP S2 13/06/2005 SP-060658 - Huawei 03/2006 SP#31 W approved SP#33 updated WID (removed MMS) SP#33 updated WID 3GPP . SP040865) deleted b A. C1.9.S 5.S 2.C1 14/03/2007 15/12/2006 14/03/2007 07/12/2006 14/06/2007 SP-060145 SP-060145 SP-060145 SP-060658 - CableLabs CableLabs CableLabs Huawei CT4#32: set of CR on FBI fo cable lab Duplicate entry ("ACCSE ".C4 S2 S2 C1 C1 08/09/2006 31/03/2005 31/01/2006 14/03/2007 SP-040338 SP-040338 - - Vodafone NTT DoCoMo - RP#42 complete SR in RP 080819.2 of FBI for PacketCable Protocol impact of FBI for PacketCable SA5 Charging aspects of FBI for PacketCable Support of SMS over generic 3GPP IP access FBI-PCBL FBI-PCBL FBI-PCBL FBI-PCBLCH SMSIP S2.10 (2010-06) 15/06/2007 08/12/2006 15/06/2007 15/06/2007 SP-050182 SP-050182 CP-070121 SP-060220 Motorola Motorola Ericsson O2 Moved fr FS sectio Feb 06 Moved fr FS sectio Feb 06 - 320012 NSP-TS S1 06/12/2006 SP-060220 - O2 - 320013 25048 Procedural aspects of NSP Network Selection enhancements (NSP) .148 31053 32088 7036 7041 Selective Disabling of UE Capabilities Stage 1 of SDoUE Stage 3 of SDoUE Network selection enhancements (NSP) Stage 1 of NSP SDoUE SDoUE-CR SDoUE NSP-CR S1.C1 S2 C1 S5 S2.C 3.C1 S1 C1 S1 Overview of 3GPP Release 7 V0. Linked to UID_704 (NSP-CR - NEW inserted 2/9/2004 - 7001 32075 11050 11060 FBI-TIS1 FBI-TIS1 FBI-TIS1 FBI-TIS1 09/03/2007 08/03/2006 09/03/2007 30/11/2006 NP-040618 NP-040618 - Siemens Siemens - 13025 14020 CT3 aspects of FBI for TISPAN R1 CT4 aspects of FBI for TISPAN R1 FBI-TIS1 FBI-TIS1st3-c4 FBI-ISE C3 C4 08/12/2006 09/03/2007 NP-040618 NP-040618 - Siemens Siemens end date updated CT1chairman after CP# - 33027 Security Enhancements for FBI S3 08/12/2005 SP-050395 - Ericsson 7002 7003 7004 7032 32081 PacketCable Related aspects Stage 1.S 3.C 4.

S 5. I-WLAN) PCC-Rx-Gxc1 VCC C1 S2. Revised CP#31.S5. 23.9. will be discontin from Rel SP-29 approved WID.C 4 15/06/2007 15/06/2007 CP-060435 SP-060292 - Ericsson AlcatelLucent - 32104 31085 32105 TR for VCC Stage 1 for VCC Stage 2 for VCC VCC VCC VCC S2 S1 S2 08/12/2005 28/09/2005 08/09/2006 SP-060292 SP-060292 SP-060292 - AlcatelLucent AlcatelLucent AlcatelLucent WID approved SP#27. SP updated WID.149 32095 310001 310002 310003 32082 Stage 2 for SMSIP Stage 3 for SMSIP CT1 aspects for SMSIP CT4 aspects for SMSIP Evolution of Policy Control and Charging SMSIP SMSIP-St3 SMSIP SMSIP-St3c4 PCC S2 C4. 23. SP updated WID.S 1. SP updated WID add SA5 charging 23. updated SP#28. C1 Overview of 3GPP Release 7 V0. will be discontin from Rel SP-31 updated WID with SA5 charging - 13030 PCC-Rx C3.10 (2010-06) 15/09/2006 14/06/2007 14/06/2007 01/06/2007 30/11/2007 SP-060658 CP-060697 CP-060697 CP-060697 SP-060217 Huawei Nokia Nokia Nokia Nokia 32103 Stage 2 for PCC PCC S2 15/09/2006 SP-060217 - Nokia 32109 Evolution of policy control and flow based bearer level charging PCC S2 29/12/2006 SP-060217 - Nokia 7033 SA5 Charging aspects of PCC PCC-CH S5 15/06/2007 SP-060217 - Orange 13029 Gx reference point for Policy and Charging Control Rx reference point for PCC CT3 aspects PCC-Gx C3 30/11/2007 CP-060434 - Siemens SP#33 updated WID CP#34 updated WID CP#34 updated WID CP#34 updated WID SP-29 approved WID.C 1 C1 C4 S2. Revised CP#33 - 7008 32091 PCC-Rx CT1 aspects Voice call continuity between CS and IMS (incl.C3. C1. updated SP#32 - 3GPP .125 w be discontin from Rel SP-29 approved WID.C 1 30/11/2007 CP-060435 - Ericsson 310006 PCC-Rx CT3 aspects PCC-Rx-c3 C3 30/11/2007 CP-060435 - Ericsson WID approved CP#30.

10 (2010-06) 14/06/2007 15/06/2007 15/06/2007 09/03/2007 31/10/2007 31/10/2007 15/12/2006 15/06/2007 SP-060292 CP-070186 CP-070186 CP-070186 SP-060819 SP-060819 SP-060819 SP-060437 Orange AlcatelLucent AlcatelLucent AlcatelLucent Nokia Huawei Nokia Samsung 03/2006 SP#31 W approved - 340014 340015 Stage 2 of CStermS Stage 3 of CStermS CSItermS CSItermS S2 C1 02/03/2007 15/06/2007 SP-060437 CP-070239 - Samsung Samsung S2#52 CREATE Triggered the abandon Study UID_321 - 33022 33023 33024 Liberty Alliance and 3GPP Security Interworking Trust Requirements for Open Platforms in 3GPP Development of UEA2 and UIA2 LibSec TrustOP AlgUEA2 S3 S3 S3 30/11/2006 30/11/2006 09/12/2005 SP-050145 SP-040863 SP-040864 - Nokia Nokia TeliaSoner a 33026 33028 330008 732030 732031 732032 732033 32034 310004 310005 711052 Lawful Interception in the 3GPP Rel-7 architecture Key establishment between a UICC and a terminal NDS Authentication Framework Extension for Transport Layer Security Security enhancements HTTPS connection between a UICC and a NAF 2G GBA: 2G SIM usage in 3GPP GAA framework Generic Authentication Architecture usage extensions and optimizations SS7 TCAP security Gateway SA3 aspects of SEC7-NDS-TCAPsec TCAPsec Gateway IMS Stage 3 IETF Protocol alignment LI-7A KeyEstUTer m NDSAFTLS SEC7 SEC7-HSUN SEC72GGBA SEC7-GAA2 SEC7-NDSTCAPsec SEC7-NDSTCAPsecSA3 SEC7-TCAP IMSProtoc S3 S3 S3 S3. WID approved SP#26.C4 S3.C 1 S3 S3 S3. CP updated WID WID approved SP#27.9.C 4 09/03/2007 CP-060102 - Siemens TR 24.C 1 Overview of 3GPP Release 7 V0.C 4 S3 C4 C1 08/12/2005 28/09/2006 06/12/2006 30/11/2006 12/09/2005 05/12/2005 30/11/2006 14/08/2006 10/03/2006 14/08/2006 14/03/2007 SP-050237 SP-050780 SP-060507 SP-050573 SP-050576 SP-060429 SP-050579 SP-050579 CP-060170 CP-060101 - BMWI Gemalto Nokia Gemalto Nokia Nokia Siemens Siemens Siemens - CP-34 approved WID.150 35079 11058 11066 14027 7046 340013 320003 320029 SA5 Charging aspects of VCC Stage 3 for VCC CT1 aspects of VCC CT4 aspects of VCC One Tunnel solution for optimization of Packet Data Traffic One Tunnel Deployment Guideline Stage 2 specification for One Tunnel solution CSI Terminating Session handling VCC-CH VCC VCC VCC-St3-c4 OPTUNEL OPTUNELGuide OPTUNELStage2 CSItermS S5 C1.223 g to R8 - 7043 Interoperability between VGCS/VBS and A/Gb flexibility VGCSFlex C1. Dependa on Fundi Availabili - TLS prof is moved Rel-8 - 33.C 4 C1 C4 S2 S2 S2 S2.93 Signallin flows for session setup in IM CN subsyste based on Session Initiation Protocol (SIP) Voice Gr Call Serv 3GPP .C 1. WID approved SP#26.

MRFP) interface CT1 aspects of Mp Procedures description Stage 3 Routeing of MT-SMS via the HPLMN Mobile Termination whilst the MS is moving to another MSC ISIM API for Java Card Rel-7 (U)SIM API Testing (TS 31.9.817 SP-050302 SP-050304 SP-050305 - Siemens Streamezz o Vodafone Ericsson China Mobile Ericsson Huawei Motorola Motorola China Mobile CP#47 complete Update o Rel-6 (U)SIM A for Java Card Tes UID_430 under Re UICC/US enhance nts and interwork UID_180 Following ETSI publicatio of TS 10 600.151 7044 7045 13023 13022 13033 CT1 aspects of VGCSFlex CT4 aspects of VGCSFlex DIAMETER on the GGSN Gi interface DIAMETER on the PDG Wi interface Interworking between the 3GPP CS domain with BICC or ISUP as signalling protocol and external SIP-I networks PDU multiplexing at Nb Interface with IP transport Mp (MRFC . expected be complete CT6 mee 45 - 3GPP .10 (2010-06) 30/10/2006 09/03/2007 08/12/2006 08/12/2006 22/07/2008 CP-060102 CP-060102 CP-060431 CP-060432 CP-070101 Siemens Siemens Vodafone Vodafone Siemens - 340047 14012 11061 320009 14021 340016 350003 743009 440042 NbIPMux Mp Mp Mp-PROCc4 Mp-St3c4 SMSviaH MTmovMS APIJAVA USIM_API_t est C3 C4.C 1 C4 C6 C6 22/07/2008 08/06/2007 13/02/2006 09/03/2007 08/06/2007 09/03/2007 31/05/2007 27/07/2007 19/03/2010 CP-070105 CP-070246 CP-070246 CP-070246 CP-070246 CP-070032 CP-070334 CP-050145 CP-090450 - AlcatelLucent Ericsson Ericsson Huawei Ericsson Vodafone AlcatelLucent Sun Sagem Orga - WID approved CP#34 - 330001 High speed interface between the UICC and the ME HSI C6 30/11/2007 CP-070259 - Gemalto 34030 34032 34034 34035 34036 34039 35041 35042 35044 35046 35047 Video Codec Performance Requirements Dynamic and Interactive Multimedia Scenes 3G-324M Video Telephony Call Setup Times Improvements Optimizations for Multimedia Telephony over IMS End-to-End Multimedia Services Performance Metrics Packet Switched Streaming Enhancements OAM&P Rel-7 Network Infrastructure Management Enhance NRM to accommodate NGN (IMS as basis of the Next Generation Network) Co-operative Element Management interface (CO-OP) (Study + Implementation) Network Management (NM) Itf-N performance criteria VICPer DIMS VTCSTI OMTIMS E2EMSPM PSSe OAM7 OAM7-NIM OAM7-NIM OAM7-NIM OAM7-NIM S4 S4 S4 S4 S4 S4 S5 S5 S5 S5 S5 07/06/2007 07/06/2007 27/09/2006 28/09/2005 15/03/2007 07/06/2007 26/06/2007 14/06/2007 14/06/2007 15/03/2007 14/06/2007 SP-040836 SP-050195 SP-050404 SP-060226 SP-050433 SP-060361 TR 30.C 1 C1 C4 C4 C4.213) VGCSFlex VGCSFlexc4 DIAMGi DIAMWi ExtSIPI C1 C4 C3 C3 C3 Overview of 3GPP Release 7 V0.

152 35048 35049 35050 Delta synchronization between IRP Manager and IRP Agent (Study + Implementation) Subscription Management (SuM) IRP Solution Sets Integration Reference Point (IRP) Security Management OAM7-NIM OAM7-NIM OAM7-NIM S5 S5 S5 Overview of 3GPP Release 7 V0. CT1/3/4 - 21006 MIMO . RP-070531 Nokia Nokia Orange Lucent Siemens AlcatelLucent 07/2005: OMA (St 1). Stage SA5.9.0 Multiple-Input Multiple-Output (MIMO) antennas OAM7-Trace OAM7-Trace CH7 CH7-IMSACP CH7-PoC MIMO S5 S5 S5 S5 S5 R1 07/12/2006 14/06/2007 14/06/2007 14/06/2007 14/06/2007 17/09/2007 SP-050628 SP-050629 SP-060442 SP-060546 RP-030192 RP-070037.Physical layer MIMO-Phys R1 15/03/2007 RP-030192 RP-070037 AlcatelLucent AlcatelLucent AlcatelLucent 22003 MIMO .10 (2010-06) 14/06/2007 07/12/2006 15/03/2007 SP-050306 SP-060739 SP-050308 Siemens Ericsson Huawei - 35052 35064 35071 35072 340009 Partial suspension of Itf-N during maintenance/testing (Study + Implementation) Backward and Forward Compatibility of IRP systems Repeater Network Resource Model (NRM) definition UTRAN radio channel power monitoring Notification XML Schema OAM7-NIM OAM7-NIM OAM7-NIM OAM7-NIM OAM7-NIM S5 S5 S5 S5 S5 14/06/2007 14/06/2007 07/12/2006 15/03/2007 15/03/2007 SP-050310 SP-050630 SP-050731 SP-050733 SP-060754 - Siemens Ericsson China Mobile China Mobile Huawei - 12/2006 SP#34 W approved - 35043 35057 35058 35059 35060 35069 35073 35039 35040 Performance Management Performance measurements definition for CN CS Enhancement UTRAN performance measurements definition Add TDD specific counters in Performance measurement ATM bearer network Performance measurements Performance measurements definition for IMS HSDPA performance measurements Trace Management End-to-end Service Level tracing for IMS OAM7-PM OAM7-PM OAM7-PM OAM7-PM OAM7-PM OAM7-PM OAM7-PM OAM7-Trace OAM7-Trace S5 S5 S5 S5 S5 S5 S5 S5 S5 14/06/2007 15/03/2007 14/06/2007 07/12/2006 15/03/2007 14/06/2007 14/06/2007 26/06/2007 15/03/2007 SP-050315 SP-050316 SP-050317 SP-050318 SP-050631 SP-060379 SP-050628 SP-050627 - China Mobile China Mobile CATT ZTE China Mobile China Mobile Vodafone Vodafone 35062 35063 320007 320008 330004 2468 Trace record content for UTRAN TDD IRP for Subscriber and Equipment Trace Management Charging Management small Enhancements Rel-7 Alternate Charged Party (ACP) for IMS Align 3GPP Charging with OMA PoC Enabler Release 2.3 aspects MIMO-L23 R2 15/03/2007 RP-030192 RP-070037 23008 MIMO .Layer 2.Iub/Iur Protocol Aspects MIMO-IurIub R3 15/03/2007 RP-030192 RP-070037 09/2006 SP#33 W approved Complete Sep 2007 SR in RP 070037a RP-0705 Complete Sep 2007 SR in RP 070037 Complete Sep 2007 SR in RP 070037 Complete Sep 2007 SR in RP 070037 3GPP .

9.6 GHz 7.68 Mcps TDD RInImpUMTS26VH CRTDD RInImpUMTS2600 R4 15/09/2006 RP-060349 RP-060451 IPWireless 20021 UMTS 2.10 (2010-06) 17/09/2007 RP-030192 RP-070531 AlcatelLucent Ericsson 20028 20060 RInImp RInImpUMTS1721E xt RP R4 04/06/2007 15/12/2006 RP-060180 RP-060681 20067 UMTS 2. Introduct of Band X (Extende UMTS 1.6 GHz TDD RInImpUMTS2600T DD R4 14/12/2005 RP-040553 RP-050661 IPWireless Complete Sep 2007 SR in RP 070531 Generic feature SR in RP 060681. Introduct of UMTS 900 (Ban VIII) in 25.RF Radio Transmission/Reception.307 Complete Sep 2006 SR in RP 060451 SR in RP 050184.6 GHz R4 14/06/2005 RP-040397 RP-050184 Nokia 20025 UMTS 2.307 SR in RP 050824 20024 UE Antenna Performance Evaluation Method and Requirements Improved Performance Requirements for HSDPA UE based on Rx Diversity (type 1) & LMMSE equalizer (type 2) Additional minimum UE performance requirement for nonHSDPA channels based on type 1 enhanced receiver (Rx Diversity) Additional minimum UE performance requirement for DL physical channels in support of DCH/HS-DSCH operation based on type 1 enhanced receiver (RX-Diversity) Additional minimum UE performance requirement for downlink physical channels in support of MTCH and MCCH operation based on type 1 enhanced receiver (Rx-Diversity) Additional minimum UE performance requirement for downlink physical channels in support of E-DCH operation based on type 1 enhanced receiver (Rx-Diversity) RInImpUEAnt R4 04/06/2007 RP-050122 RP-070281 TeliaSoner a 20045 RInImpHSPerfType3 RInImpRxDiv RInImpRxDiv-DCH R4 15/03/2005 RP-050362 RP-060015 Cingular 20062 R4 15/12/2006 - - Qualcomm RP#36 (M 2007) complete SR in RP 070281 Complete Mar 2006 SR in RP 060015 - 20048 R4 14/06/2006 RP-060185 RP-060235 Cingular Complete Jun 2006 SR in RP 060235 7028 RInImpRxDivMBMS RInImpRxDiv-EDCH R4 15/12/2006 RP-060183 RP-060678 Qualcomm Complete Dec 2006 SR in RP 060678 7029 R4 15/12/2006 RP-060184 RP-060679 Qualcomm Complete Dec 2006 SR in RP 060679 3GPP .7/2. Ba VII in 25.7/2.1 G in 25. Introduct of UMTS26 internal band. System Performance Requirements and Conformance Testing Rel-7 Improvements of the Radio Interface Extended UMTS 1. SR in RP 050661 20027 UMTS 900 MHz RInImpUMTS900 R4 14/12/2005 RP-040541 RP-050662 Nortel 20043 UMTS 1700 MHz RInImpUMTS1700 R4 14/12/2005 RP-050385 RP-050824 NTT DoCoMo SR in RP 050662.153 24008 MIMO .1 GHz MIMO-RF R4 Overview of 3GPP Release 7 V0.

RP#41 complete (GERAN aspects might ne to be included later) - R5 07/12/2007 RP-070414 - Motorola - 25040 RInImpUEConTest_ RxDivMBMS R5 07/03/2008 RP-070381 RP-080056 Ericsson SR in RP 080056 20029 20026 RANimp RANimpRABSECodOptLCR TDD RANimpDelayOpt RANimpIMSRealTim e MBMS-RANRF-TDD RANimpCPC RP R1 15/06/2007 15/12/2006 RP-040552 RP-060682 UTStarco m Nokia 20031 R2 15/09/2006 RP-050386 RP-060453 20132 20033 R2 R4 14/12/2005 15/06/2006 RP-050160 RP-050156 RP-050667 RP-060477 Cingular IPwireless 20046 R1 15/03/2007 RP-050870 RP-070033 Siemens Generic feature Complete Dec 2006 SR in RP 060682 Complete Sep 2006 SR in RP 060453 Closed D 2005. SR RP-0506 Complete Sep 2006 SR in RP 060477 Complete at Mar 20 SR in RP 070033 7030 Extended WCDMA Cell Range RANimpExtCell R3 15/12/2006 RP-060212 RP-060685 Ericsson Complete Dec 2006 SR in RP 060685 3GPP .7/2.9.28 Mcps TDD Delay optimization for procedures applicable to CS and PS Connections Improved support of IMS Realtime Services using HSDPA/HSUPA UE Performance Requirements for MBMS (TDD) Continuous connectivity for packet data users 25039 RInImpInterBand_T est RInImpUEConTest_ UMTS1721E xt RInImpUEConTest_ RxDivEDCH R5 R5 01/12/2006 01/06/2007 RAN5_Work _Items RP-060676 - NEC. Motorola Motorola SR in RP 080535.1 GHz Conformance Test Aspects – Minimum UE performance requirement for downlink physical channels in support of E-DCH operation based on type 1 enhanced receiver (Rx-Diversity) Conformance Test Aspects – Minimum UE performance requirement for downlink physical channels in support of MTCGH and MCCH operation based on type 1 enhanced receiver (Rx-Diversity) Rel-7 RAN improvements Optimization of channelisation code utilisation for 1.UE Conformance Testing RInImpUEConTest R5 Overview of 3GPP Release 7 V0.154 25025 Rel-7 Improvements of the Radio Interface .10 (2010-06) 12/09/2008 not applicable - 25007 25008 25013 25020 UE Conformance Test for UMTS 2600 MHz UE Conformance Test for UMTS 900 MHz (band VIII) Conformance Test Aspects – Improved Performance of HSDPA Receiver type 3 UE antenna Over The Air (OTA) conformance testing RInImpUMTS2600_ Test RInImpUMTS900_T est RInImpHSPerfType3_Test RInImpUEAnt_Test R5 R5 R5 R5 02/06/2006 02/06/2006 01/12/2006 12/09/2008 RAN5_Work _Items RAN5_Work _Items RAN5_Work _Items RP-060486 RP-080535 Nokia Qualcomm Motorola Nokia 05/08: Linked to Feature UID_200 (RInImp) - 25015 25028 UE conformance testing for FDD Inter-Band Operation Conformance Test Aspects – Extended UMTS 1.

68 Mcps TDD Enhanced Uplink Conformance Test Aspects – 64QAM for HSDPA (FDD) RANimpUEConTest_ EDCHTDH RANimpUEConTest_ 64QamDow nlink RANimpUEConTest_ 16QamUplin k RANimpUEConTest_ L2DataRate s RANimpUEConTest_ CPC RANimpUEConTest_ EnhancedCe llFACHState R5 12/09/2008 RP-060484 RP-080536 IPWireless 25031 R5 03/03/2008 RP-071319 RP-080059 Ericsson Complete Mar 2007 SR in RP 070140 SP#36 J 2007 complete 05/08: Linked to Feature UID_200 (RANimp SR in RP 080536.68 Mcps TDD Enhanced Uplink RANimpVHCRTDDEDCH R1 Overview of 3GPP Release 7 V0.155 7031 7.UE Conformance Testing RANImpTMA RANImpTMA-OAM RANimpUEConTest R3 15/06/2007 RP-060418 RP-070140 Vodafone 340045 25026 S5 R5 15/06/2007 18/09/2009 not applicable - Vodafone - 25021 Conformance Test Aspects . RP#39 complete 25032 Conformance Test Aspects – 16QAM for HSUPA (FDD) R5 30/05/2008 RP-070022 RP-080281 Motorola SR in RP 080281.3.9.10 (2010-06) 15/12/2006 RP-060119 RP-060684 IPwireless Complete Dec 2006 SR in RP 060684 330009 Enhanced CELL_FACH State in FDD RANimpEnhState R2 04/06/2007 RP-070245 RP-070286 Nokia Complete May 200 SR in RP 070286 340038 64QAM for HSDPA (FDD) RANimp64QamDow nlink R1 04/06/2007 RP-070223 RP-070287 Ericsson Complete May 200 SR in RP 070287 340039 Improved L2 support for high data rates RANimpL2DataRate s R2 04/06/2007 RP-070242 RP-070289 Ericsson Complete May 200 SR in RP 070289 340040 Introduction of 16QAM in HSUPA (FDD) RANimp16QamUplin k R1 04/06/2007 RP-060844 RP-070288 Nokia Complete May 200 SR in RP 070288 20066 Interface to control Tower Mounted Amplifiers (TMAs) OAM aspects to Interface to control TMAs Rel-7 RAN improvements . RP#40 complete 25033 Conformance Test Aspects – Improved L2 support for high data rates Conformance Test Aspects – Continuous connectivity for packet data users Conformance Test Aspects – Enhanced CELL_FACH state in FDD R5 30/05/2008 RP-070020 RP-080256 Ericsson 25034 R5 30/05/2008 RP-070023 RP-080282 Nokia SR in RP 080256. RP#41 complete SR in RP 080059. RP#40 complete SR in RP 080282. RP#40 complete 25035 R5 18/09/2009 RP-080730 RP-090711 Nokia RP#45 complete 3GPP .84 Mcps and 7.

System Performance Requirements and Conformance Testing VHCRTDDRF R4 15/06/2006 RAN_Work_ Items_Histor y - IPwireless 20035 3.28 Mcps TDD Enhanced Uplink: Physical Layer LCRTDDEDCH-Phys R1 15/03/2007 RAN_Work_ Items - CATT Complete May 200 SR in RP 070038 a RP-0702 - 3GPP .10 (2010-06) 15/06/2006 RP-060119 RP-060684 IPwireless 20015 VHCRTDD: Stage 2 VHCRTDDStage2 R1 15/03/2006 RAN_Work_ Items_Histor y - IPwireless 20016 VHCRTDD: Physical Layer VHCRTDDPhys R1 15/03/2006 RAN_Work_ Items_Histor y - IPwireless 20017 VHCRTDD: Layer 2 and layer 3 protocol aspects VHCRTDDL23 R2 15/03/2006 RAN_Work_ Items_Histor y - IPwireless 20018 VHCRTDD: UTRAN Iub/Iur Protocol Aspects VHCRTDDIurIub R3 15/03/2006 RAN_Work_ Items_Histor y - IPwireless 20019 VHCRTDD: RF Radio Transmission/ Reception.156 20014 7.9. System Performance Requirements and Conformance Testing 1.28 Mcps TDD Enhanced Uplink R2 R3 15/09/2006 15/09/2006 - IPwireless Interdigital - 20040 R4 15/09/2006 - IPwireless - 20055 RP 15/06/2007 RP-070296 CATT 20056 1.84 Mcps TDD Enhanced Uplink EDCHTDD RP 15/09/2006 RP-050100 RP-060684 IPwireless 20036 20037 EDCHTDD: Stage 2 EDCHTDD: Physical Layer EDCHTDDStage2 EDCHTDDPhys EDCHTDDL23 EDCHTDDIurIub EDCHTDDRF LCRTDDEDCH R2 R1 15/06/2006 15/09/2006 RAN_Work_ Items_Histor y RAN_Work_ Items_Histor y RAN_Work_ Items_Histor y RAN_Work_ Items_Histor y RAN_Work_ Items_Histor y RP-060202 - IPwireless IPwireless Complete Dec 2006 SR in RP 060684 Feature complete and close at RP#33 with the presenta of the tes WI Feature complete and close at RP#33 with the presenta of the tes WI Feature complete and close at RP#33 with the presenta of the tes WI Feature complete and close at RP#33 with the presenta of the tes WI Feature complete and close at RP#33 with the presenta of the tes WI Complete Dec 2006 SR in RP 060684 - 20038 20039 EDCHTDD: Layer 2 and 3 Protocol Aspects EDCHTDD: UTRAN Iub/Iur Protocol Aspects EDCHTDD: RF Radio Transmission/ Reception.68 Mcps TDD option VHCRTDD RP Overview of 3GPP Release 7 V0.

28 Mcps TDD Enhanced Uplink: UTRAN Iub/Iur Protocol Aspects 1. RP#41 complete GP#36 complete for R7 - 51138 53084 55094 50564 GSM710core GSM-710test GSM-710test SCSAGB G1 G1 G3n ew GP 30/06/2005 30/06/2006 30/06/2006 31/08/2007 GP-061501 - Ericsson Complete - 52143 51137 52144 SCSAGBMTD SCSAGBRRM SCSAGBRLCNP GP G1 G2 31/08/2007 31/08/2007 17/11/2006 GP-061501 GP-061502 GP-061503 - Ericsson Ericsson Ericsson Originally started N 2003 as 030443 - 50565 TGSM810 GP 31/08/2007 GP-050945 - Huawei - 50566 Changes to core specification TGSM810Core GP 02/09/2005 GP-050946 - Huawei - 55092 53082 50567 Changes to MS testing specification Changes to BTS testing specification Handover of dedicated and shared resources while in Dual Transfer Mode Handover of dedicated and shared resources while in Dual Transfer Mode Mobile Station Receive Diversity (DARP Phase II) TGSM810MStest TGSM810BTStest HODSRDTM G3n ew G1 GP 31/08/2007 11/11/2005 17/11/2006 GP-050947 GP-050948 GP-050979 - Huawei Huawei Nokia - 55093 50569 HODSRDTM -G2 MSRD2 G2 GP 30/06/2006 16/11/2007 GP-050979 GP-061491 - Nokia Nokia GP#30 complete Started a GP#24 GP#30 complete GP#36 complete 3GPP . System Performance Requirements and Conformance Testing 1.28 Mcps TDD Enhanced Uplink: Layer 2 and 3 Protocol Aspects 1.28 Mcps TDD Enhanced Uplink: RF Radio Transmission/ Reception.10 (2010-06) 15/03/2007 15/03/2007 RAN_Work_ Items RAN_Work_ Items RAN_Work_ Items RP-070724 CATT CATT - 20059 R4 15/06/2007 - CATT - 350146 R5 12/09/2008 RP-080539 CATT 50118 50119 MS Antenna Performance Evaluation Method and Requirements Lower 700 MHz Inclusion in the GERAN Specifications Inclusion of the 698 – 746 MHz band into GERAN core specifications G1 aspects of GSM710 G3 aspects of GSM710 Support of Conversational Services in A/Gb mode via the PS domain Minimise the transfer delay between the SGSN and the MS Definition of radio resource management functionality Support of Conversational Services in A/Gb mode via the PS domain – RLC Non-Persistent mode Addition of new frequency band to GSM (T-GSM810) APEMR GSM710 GP GP 16/11/2007 30/06/2006 GP-050284 GP-050543 - TeliaSoner a UTC UID_350 ->350146 05/08: Linked to Feature UID_200 (LCRTDD EDCH).157 20057 20058 1.28 Mcps TDD Enhanced Uplink UE Conformance Testing LCRTDDEDCH-L23 LCRTDDEDCH-IubIur LCRTDDEDCH-RF LCRTDDEDCHUEConTest R2 R3 Overview of 3GPP Release 7 V0. S in RP080539.9.

DARP Phase II Test Scenarios for Mobile Station Receive Diversity. Ericsson Nokia Siemens Networks. Ericsson GP#39 complete SP#42 s core from testing specifica work. Ericsson Nokia Siemens Networks. Ericsson Nokia Siemens Networks. Ericsson Nokia Siemens Networks.158 50571 50572 50573 50570 50579 51139 52142 Performance Requirements for Mobile Station Receive Diversity. Ericsson 51140 Stage 2 of HUGE HUGEStage2 HUGELayer1 HUGELayer23 HUGEPerfreq HUGE G1 07/09/2007 GP-061902 - 51141 Layer 1 Support of HUGE G1 22/02/2008 GP-061903 - 52149 Layer 2/3 Support of HUGE G2 31/08/2007 GP-061904 - 51142 Performance requirements G1 29/08/2008 GP-061905 - 59584 HUGE Conformance Testing G1. DARP Phase II Capability signalling of Mobile Station Receive Diversity.10 (2010-06) 16/02/2007 16/02/2007 16/02/2007 16/11/2007 31/08/2007 30/06/2006 31/08/2007 GP-060115 GP-060116 GP-060117 GP-060114 GP-061331 GP-060484 GP-060485 Nokia Nokia Nokia Nokia Nokia Siemens Networks Nokia Siemens Networks Nokia Siemens Networks Nokia Siemens Networks Nokia Siemens Networks Ericsson Ericsson GP#33 complete GP#33 complete GP#33 complete GP#36 complete GP#35 complete GP#30 complete GP#35 complete 59579 53086 50580 50582 Downlink Dual Carrier – MS Conformance Test Downlink Dual Carrier – MS Conformance Test Support of SIGTRAN in GERAN Latency Reductions G3n ew G3n ew G3n ew GP 04/09/2009 04/09/2009 30/06/2006 31/08/2007 GP-060486 GP-060486 GP-060450 GP-061519 - GP#43 complete GP#43 complete GP#30 complete GP#35 complete 52145 Improved Ack/Nack reporting LATREDACKNAR G2 31/08/2007 GP-061520 - Ericsson GP#35 complete 52146 Reduced TTI LATREDREDTTI G2 31/08/2007 GP-061521 - Ericsson GP#35 complete 52147 PS Handover between GERAN/UTRAN mode and GAN Mode Higher Uplink performance for GERAN Evolution GUGAN G2 16/02/2007 GP-061349 - Ericsson GP#33 complete 50584 HUGE GP 29/08/2008 GP-071083 - Nokia Siemens Networks. DARP Phase II MS conformance test of DARP Phase II (MSRD) Downlink Dual Carrier Downlink Dual Carrier Stage 2 Downlink Dual Carrier Stage 3 MSRD2PerfReq MSRD2CapSig MSRD2TestSc MSRD2Msconf GDCDL GDCDLStage2 GDCDLStage2 GDCDLStage3 GDCDLStage3 GDCDLMStest LATRED GP GP GP GP GP G1 G1 Overview of 3GPP Release 7 V0. GP#35 complete GP#37 complete GP#35 complete GP#39 complete SP#42 s core from testing specifica work 3GPP .9.G 3new 04/03/2011 not applicable - Nokia Siemens Networks.

(Small) Technical Enhancements and Improvements for Rel-7 TEI7 TEI7_Test All R5 26/03/2007 04/06/2010 not applicable not applicable - Ericsson. Nokia Siemens Networks.MS Conformance Tests REDHOTMstest G3n ew 12/11/2010 GP-062491 - 51146 BTS Conformance Tests REDHOTBTStest G1 15/05/2009 GP-062492 - 60110 480001 (Small) Technical Enhancements and Improvements for Rel-7 Test . Higher Order modulation and Turbo coding (RED HOT) for downlink GP 16/05/2008 GP-071080 - Nokia Siemens Networks. Nokia Siemens Networks. Marvell Ericsson.9.10 (2010-06) 04/03/2011 GP-061906 Nokia Siemens Networks. Nokia Siemens Networks. Marvell Ericsson. GP#35 complete 51145 Stage 3 for REDHOT REDHOTStage3 G1 16/05/2008 GP-062490 - GP#38 complete 59121 REDHOT Conformance Testing REDHOT G1.G 3new 12/11/2010 not applicable - 53088 REDHOT .159 53087 HUGE .MS Conformance Test HUGEMstest G3n ew Overview of 3GPP Release 7 V0. Nokia Siemens Networks. Nokia Siemens Networks. Ericsson Ericsson. Marvell Ericsson. Ericsson 51143 HUGE .BTS Conformance Test HUGEBTStest REDHOT G1 04/09/2009 GP-061907 - 50121 REduced symbol Duration. Marvell RP#48 created for submitted CRs SP#42 s core from testing specifica work GP#46 completio 09/10=>1 0 (was 02/10=>0 0=>09/10 GP#42 complete - Uniqu e_ID 0 31082 31050 31055 31059 Name Release 7 Studies Study on Multimedia Telephony Capabilities for IMS Study on Behaviour of Multi system UEs Study on Combining CS calls and IMS sessions Study on All-IP Network Acronym MITE BMSU IRTSDCS_IMS FS_AIPN Resou rce Finish Hyperlink Status _Repo rt - rapport eur Ericsson Qualco mm NTT DoCoMo Notes - S1 S1 S1 S1 31/07/2006 15/12/2005 17/03/2005 16/03/2005 SP-050387 SP-050502 SP-040467 SP-040303 Spin-o UID_70 (MTSI) - 07/08 M Rel-7 a out of s Rel-8 F 3GPP . Marvell Ericsson GP#46 completio 09/10=>0 1 (was 02/10=>0 0=>09/10 No intere in HUGE TCs developm among th participa compani GP#43 complete 51144 Stage 2 for REDHOT REDHOTStage2 G1 31/08/2007 GP-062489 - GP#38 complete SP#42 s core from testing specifica work.

9.160 Overview of 3GPP Release 7 V0.(G)MSC-S Nc Interface based on the SIP-I protocol CT4 aspects of NcSIP CT3 aspects of NcSIP Study on SOAP/HTTP IRP Solution Sets Study on Itf-N Implementation Conformance Statement (ICS) template Study on IRP Information Model Study on Evolved UTRA and UTRAN FS-M2PA NcSIP NcSIP NcSIP OAM7-NIMXML OAM7-NIMICS OAM7-NIMIM RANFS-Evo C4 C4 C4 C3 S5 S5 S5 RP 08/06/2007 14/09/2007 01/06/2007 14/09/2007 07/12/2006 15/03/2007 15/03/2007 15/09/2006 CP-060698 CP-070034 CP-070034 CP-070034 SP-050610 SP-050609 SP-050611 RP-040461 RP06047 2 RP06041 2 RP06003 5 RP05042 7 RP06069 2 RP06026 3 RP07049 9 RP07053 China Mobile Vodafon e Vodafon e Ericsson Nortel China Mobile Motorola NTT DoCoMo Vodafon e Ericsson Moved CT32 ( with sli Previou known of a SM for MT TR 29. conten to TS 2 under implem WI UID TCAPs Gatew - 20034 Study on Performance Evaluation of the UE behaviour in high speed trains with speeds up to 350 kmph Study on UTRA Tower Mounted Amplifier (FDD) Study on Continuous connectivity for packet data users Study on Improvement of the Multimedia Broadcast Multicast Service (MBMS) in UTRAN Study on Performance Improvements in Small Cells using HSDPA/EDCH Study on Further Improved Performance Requirements for UMTS/HSDPA UE (FDD) Study on Scope of future FDD HSPA Evolution RANFSHSTrains RANFSTMA RANFScont-packet RANFSMBMSImp SMALLCEL LS RANFS-IC R4 15/06/2006 RP-050146 20041 R4 14/03/2006 RAN_Study _Items_Hist ory RP-050391 20044 R1 14/09/2005 Siemens 20051 R2 15/12/2006 RP-050746 LG Electroni cs Cingular 20052 R4 15/06/2006 RP-050782 20053 R4 04/06/2007 RP-050880 Cingular 20065 RANFSHSPAEvo RP 17/09/2007 RP-060217 Cingular SP#34 comple SP#35 comple SP#35 comple RP#33 2006) comple in RP-0 RP#32 2006) comple in RP-0 RP#31 2006) comple in RP-0 RP#29 2006) comple in RP-0 RP#34 2006) comple in RP-0 RP#32 2006) c progre RP-060 RP#36 2007) comple in RP-0 RP#37 2007) 3GPP .10 (2010-06) 31075 31073 Study on Videotelephony teleservice Study on Network Selection Principles VidTel NetSel S1 S1 17/01/2006 08/12/2005 SP-050506 SP-050227 - T-Mobile O2 UID_31 IP Netw (AIPN) - 31041 31083 32073 7034 14019 Study on Multimedia Priority Service Study on Transferring of emergency Call data Study on Enhancement of E2E QoS Study on Bandwidth Saving at Nb Interface with IP transport Study on Routeing of MT-SMS via the HPLMN PRIOR-MM eCALL QoS7 BSNbIP SMS7 S1 S1 S2 C3 C4 30/06/2006 31/03/2006 15/09/2005 09/03/2007 01/12/2006 SP-060329 SP-050388 SP-040326 CP-060438 CP-060701 - Telcordi a Motorola Huawei Siemens Vodafon e Siemens Spin-o Networ selectio enhanc (NSP-C UID_70 Spin-o PRIOR UID_34 - 7025 Study on the TCAPsec Gateway concept SEC7-TCAP C4 10/03/2006 CP-050687 - 7050 32001 8 33000 2 33000 3 35066 35067 35068 20023 Study on using M2PA in 3GPP network Study on Support of (G)MSC-S .

161

Overview of 3GPP Release 7 V0.9.10 (2010-06)
3

33001 3 50568 50120

Study on Dynamically reconfiguring a FDD UE receiver to reduce power consumption when desired Quality of Service is met Study on Future GERAN Evolution Study on GAN Enhancements

FSUEPow

R4

22/06/2007

RP-060641

RP07053 4 -

Nokia

FGE EGAN

GP GP

16/02/2007 31/08/2007

GP-051052 GP-062298

Nokia T-Mobile

comple in RP-0 RP#37 2007) comple in RP-0 GP#33 comple GP#35 comple

3GPP

162

Overview of 3GPP Release 7 V0.9.10 (2010-06)

19
Uniqu e_ID 0 7009 7023 Name

Rel-7 Stopped Items
Acronym Resource Finish Hyperlink Release 7 Features Deleted - TR on GRUU Deleted - duplicates UID7039 - IMS Multimedia Telephony Service Deleted - Stage 2 Specification Phase - GPRS-level Deleted - CT3 IMS aspects to support IMS Emergency sessions Deleted - CT3 PS domain aspects to support IMS Emergency sessions Deleted - CT4 aspets for WLAN-PNA GRUU MMTEL S2 S1 14/09/200 6 15/06/200 7 02/03/200 7 15/09/200 6 SP-050633 SP-050387 Status_ Report rapporteu r RIM Ericsson Notes Abandoned TSs_an d_TRs 22.173

32101 13028

EMC1 EMC1

S2 C3

SP-050604 CP-050529

-

Siemens Ericsson

Cancelled for Rel-7 and there is now correspondi ng Rel-8 WI Cancelled for Rel-7 and there is now correspondi ng Rel-8 WI CT4#31; no impacts identified, therefore completed. CP-32 stopped SP-32 stopped Updated WID at SP#32 to change "stage 2" to "study" , duplicated UID 320017 deleted. SP#33 TR for Information. Last mention SP-35 Mar 2007 (abandoned ?) -

29.163

13031

EMC1

C3

15/09/200 6

CP-050529

-

Ericsson

29.061

14024

WLANPNAst3

C4

26/09/200 6

CP-060256

-

NEC

29.234

7015 32108

Deleted - TR on support of QoS on WLAN Deleted - Study of work on an LCS architecture for IWLAN.

WLANQOS LCS3-IWLANFSs2

S2 S2

31/01/200 6 02/03/200 7

SP-050682 SP-060291

-

Samsung LG Electronic s

23.836 23.837

20030 20054

Deleted - UE positioning Rel-7 Deleted - RAN2 aspects for LBS

LCS3-UEpos LCS3-UEPosLBS

RP R2

17/12/200 7 15/06/200 5

-

-

SiRF

25.305, 25.331, 25.410, 25.413, 25.453 29.002

50551 14023

Deleted - Towards AGNSS Concept Deleted - CT4 aspects of IVGCS Deleted - TR on different possible architectures

GNSS IVGCS-St3-c4

S1 C4

16/02/200 7 09/03/200 7 16/12/200 5

GP-042677 NP-050141

-

Alcatel T-mobile

CT4#33 stage 2 solution is still open. ... Moved from FS section Feb 06. Abandoned at SP-30

32089

SDoUE-FS

S2

SP-050182

-

Vodafone

23.805 abandon ned at SP-30; descend ant C1 24.305

3GPP

163
Uniqu e_ID 20010 Name Deleted - Potential impact on Iu interface Overload functionality Deleted - Extra ACBOP information in RAN Deleted - Extra ACBOP information in GERAN Deleted - TR for PCC Acronym ACBOP Resource RP Finish 15/03/200 4 15/03/200 4 08/09/200 6 29/12/200 5

Overview of 3GPP Release 7 V0.9.10 (2010-06)
Hyperlink Status_ Report rapporteu r Notes TSs_an d_TRs 25.413

20009 50117 32102

ACBOP ACBOP PCC

RP GP S2

SP-060217

-

Nokia

SP-30: S2 has no intention for TR completion S2#52 CREATED. TR for Info SP-33. SP34: S2 Report intention to discontinue TR CP-34 approved WID CP#34: CT3 not involved in Mp interface definition SP-35 stopped

25.331 44.018 23.803

13032 32000 2

Deleted - CT3 aspects of VCC Deleted - Study on Stage 2 for One Tunnel solution

VCC OPTUNELStudy

C3 S2

02/11/200 6 15/09/200 6

CP-070186 SP-060819

-

AlcatelLucent Nokia

29.163 23.809

34001 1

13026

Deleted - duplicated with UID 340015 -Stage 3 CSI Terminating Session handling Deleted - CT3 aspects of Mp

CSItermS

C1

09/03/200 7

CP-060647

-

Samsung

24.229, 24.179, 24.279 29.162

Mp

C3

22/09/200 6

-

-

Ericsson

34037

35054

Deleted Characterisation of Adaptive Jitter Management Performance for VoIP Services Deleted Management of Legacy Equipment Deleted - Rules for Vendor Specific Extensions Deleted - SIP enhancements for trace Deleted - duplicated with UID 35063 - IRP for Subscriber and Equipment Trace Management Deleted Improved support of gaming over HSDPA/EDCH Deleted (not approved at PCG) UMTS 2.6 GHz FDD DL External

OMTIMSCAJMP

S4

28/09/200 5

SP-050432

-

Lucent

-

OAM7-NIM

S5

15/12/200 6 15/03/200 7 26/06/200 7 15/12/200 6

SP-050312

-

Siemens

35055

OAM7-NIM

S5

SP-050313

-

Siemens

11046 35070

OAM7-Trace OAM7-Trace

C1 S5

SP-050629

-

Nokia

Request to TSG#35 to STOP the WI Request to TSG#35 to STOP the WI combined with UID 11067 -

new 32.xxx 32.62n; For n = 1 to 5 32.421,3 2.422,32 .423. 3 new 32.4x1,2 ,3 -

20049

RInImpGaming

R2

15/12/200 6

RAN_Work _Items

RP060680

Cingular

20047

RInImpUMTS2600Ext

R4

15/09/200 5

-

-

T-mobile

RP#34 (Dec 2006) stopped. SR in RP060680 This item was conditionnal y approved pending decision of PCG 16 who decided not to approve it

25.101, 25.104, 25.133, 25.141, 25.331, 25.942, 25.306, 25.307, 34.121

3GPP

002.MBMS Enhancements Deleted . no work done.Transferring of emergency Call data Deleted .807 32005 32019 Deleted .Not yet required in SA2 as it exists in previous releases - - 32098 Deleted .060. 23.Personal Network (PN) and Personal Area Network (PAN) Deleted .002. 23.IMS Local services Deleted .PS domain and IMS support for IMS Emergency sessions Deleted . 23.060.abc.271 23.Multimedia Telephony Capabilities for IMS Deleted . 23.Covered by SI . 23.Covered by SI . 23. 23.VoIMS bearer related enhancements IMS-EMER S2 21/09/200 6 SP-050604 - Nokia 32114 IMS-EMER S2 21/09/200 6 SP-050604 - Nokia Approved at SP#29 32115 IMS-EMER S2 21/09/200 6 SP-050604 - Nokia Approved at SP#29 31077 PNPAN S1 20/12/200 5 SP-050386 - Vodafone - 23.PS domain aspects to support IMS Emergency sessions Deleted . 12/2008 Marked as stopped ("deleted") Approved at SP#29 TSs_an d_TRs 51-010 53083 Deleted .002.Covered by SI . 23.IMS aspects to support IMS Emergency sessions Deleted . 12/2008 Marked as stopped ("deleted") Stopped.abc. no work done.867.Stage 2 IMSLocal IMSLocal S2 S2 06/01/200 6 06/01/200 6 - - - 23.228 - 11035 Deleted . 23.867.FS on enhancement of radio performance for VoIMS VoIMS S2 21/07/200 6 SP-050351 - Nortel 23.Covered by SI .271 23.9. after consultation of chairs WID approved SP#28: SA2#52: CLOSED To be removed from the work plan DAB . 23. 23.10 (2010-06) Hyperlink GP-051166 GP-051165 GP-050979 Status_ Report rapporteu r Ericsson Ericsson Nokia Notes Stopped.Radio Channel Support DeletedModifications to FLO Deleted .271 - 31078 MITE S1 20/12/200 5 08/12/200 5 08/12/200 5 21/07/200 6 SP-050387 - Ericsson - - 31079 31080 32099 eCALL MBMSE VoIMS S1 S1 S2 SP-050388 SP-050389 - - Motorola China Mobile - Created by MCC to group all VoIMS related items. 23.867.abc.BTS conformance testing HODSRDTMBTStest G1 17/11/200 6 GP-050979 - Nokia 51.Stage 3 for IMS Local services IMSLocal C1 06/01/200 6 - - Lucent - 3GPP .MS Conformance Testing Acronym SCSAGBRCHS SCSAGB-FLO HODSRDTMMstest Resource G2 G2 G3new Finish 17/07/200 6 17/07/200 6 17/11/200 6 Overview of 3GPP Release 7 V0.060.026 32113 Deleted .164 Uniqu e_ID 52138 52139 55095 Name Deleted.

This have to be moved to Rel-7. It was deleted from WID TSs_an d_TRs - - C4 - - - 42003 Deleted .Stage 3 Common objects - C4 30/06/200 6 TP-020275 - - 24.Study of work on an LCS architecture for I-WLAN Deleted: Study on applicability of GALILEO for LCS Deleted .241 Unique_ID 0 7022 Name Release 7 Studies Deleted covered by UID_31082 Study of (MITe) .165 Uniqu e_ID 32078 70121 6 14018 Name Deleted . No progress in CN4#26.10 (2010-06) Hyperlink RAN_Work _Items Status_ Report rapporteu r Notes Stage 2 description of Interim conclusion Created at TSG#27 by A.973 S1 31/07/200 6 SP050387 732028 IMS-SE S3 08/12/200 5 SP050395 Ericsson - - 320017 IMS-SE S2 08/12/200 6 - LG Electronics S2#52: Entry created - 32029 Galileo S2 30/06/200 5 30/06/200 5 30/06/200 5 30/06/200 6 SP020541 SP050607 - - - 32058 50095 31087 Galileo Galileo CAT S2 GP S1 - Awaiting MCC SA3 input - 50552 VIDGER GP 30/06/200 6 GP042221 Ericsson FS CLOSED at G#28 (no input) - 3GPP .IMS Phase 3 Deleted Improvements of Radio Interface Deleted: Generic User Profile Phase 2 Acronym RInImp Resource S2 RP Finish 06/01/200 6 15/09/200 4 30/06/200 6 Overview of 3GPP Release 7 V0.Study on enhanced support of Acronym MITE Resource Finish Hyperlink rapporteu r Ericsson Notes Duplicate entry with 31082 TSs_and_TRs 22.IMS Multimedia Telephony Communication Enabler and supplementary services Deleted covered by UID33027 .TR on Stage 2 Deleted GERAN review of the TR Deleted was duplicatedStudy of Customised Alerting Tone (CAT) Requirements Deleted .9. Sultan because of the move to Rel-7 of "Common Objects".IMS security extensions Deleted covered by 32108 .

8xy 3GPP .166 Video Telephony Deleted (moved to Rel8) . Deleted .9.Study on Stage 2 (IMS services using CS bearers) Deleted .Study of Personal Network and Personal Area Network Deleted .Study on Transferring of emergency call data – inband modem solution Deleted covered by UID 20053 .Study on IMS enhancements and optimizations for real time communication.818 CSIterm S2 29/12/200 6 SP050811 Samsung 35045 Deleted .Study on Terminating Session handling PNPAN S1 20/10/200 6 - - Deleted.Study on IMS with real time services deployment Deleted .819 32. Same as FS on Further Improved Performance Requirements for UMTS/HSDPA UE (FDD) Moved from FS section Feb 06 - - IRTSD S1 12/09/200 5 12/09/200 5 01/06/200 7 SP040465 SP040479 SP050492 - - - IRTSDIMSCS IMS-RT S2 Nortel SP-30: S2 has no intention for TR completion abandoned at 65% 23.967 360009 RANFSInterfCanc R4 28/03/200 7 - - 7011 31054 32076 32112 32117 Deleted .899 S2 Ericsson 23.10 (2010-06) 34040 eCALLIBMS S4 22/06/200 7 SP060935 Airbiquity SP-38 stopped 26.Study on IRP usage scenarios OAM-Study S5 07/12/200 6 SP050303 Lucent SP#32 Jun 2006 Study abandoned => spin-off Implementatio n work UID_320029 - 23.Study on Interference Cancellation for UTRA FDD UE Overview of 3GPP Release 7 V0.

7 6 0. 0. AZ wrote S2/3.5 4 0.8 7 0.9. 0.MS Conformance Tests (G3 new) Old New 0.9.0 1 0.7.10 (2010-06) Annex A: Change history Change history Date Subject/Comment 2008-04 MCC coordination handover from Alain Sultan to Adrian Zoicas 2008-05 Inclusion of leftover material 2008-06 Skeleton despatched to MCC for input by 14 July 2008 2008-07 No feedback received from MCC except GERAN.1 0.167 Overview of 3GPP Release 7 V0. Removed Features moved to Rel-8 or stopped in the meantime. Despatched to MCC for LAST check by 22 Aug 2008 2008-09 Submitted to TSGs#41 for Information 2008-10 GERAN updates (HUGE.9 8 0.6 5 0.9.2 1 0.9.9.10 9 Ongoing Release 7 Testing Unique_ID Name HUGE .0 0 0.9.UE Conformance Testing. Ericsson Notes GP#46 completion 09/10=>03/11 (was 02/10=>03/10=>09/10).9.9.6.1 0 0.MS Conformance Test (G3 new) UID_53088 REDHOT .9. 0.213) 2010-06 Post-TSG#48 updates (added attachment Rel-7_Work_Plan_20100621) Ongoing: UID_53087 HUGE .8. S4.MS Conformance Test Resourc e G3new Finish 04/03/201 1 Compl 10% Hyperlin k GP061906 rapporteur Nokia Siemens Networks. 0.1 0 0.9. C3/6.8. 0.9.MS Conformance Test (G3 new) UID_53088 REDHOT .9. Updated clauses 18 Rel-7 Completed Features and Studies 19 Rel-7 Deleted Features and Studies Still open: Testing issues for RAN.9.9. GERAN Despatched to MCC for LAST check by 22 Nov 2008 2008-11 draft despatched to TSG#42 for input / comment 2009-01 Post-TSG#42 updates (testing exclusively) 2009-04 Post-TSG#43 updates Completed UID_350147 MTSI .9. 0.0.UE Conformance Testing from Rel-8 to Rel-7 to match the Core specs release 2009-06 Post-TSG#44 updates Added UID_440042 Rel-7 (U)SIM API Testing (CT6) 2009-09 Post-TSG#45 updates Completed: UID_59579 Downlink Dual Carrier – MS Conformance Test (GDCDL-Stage3) G3new UID_51143 HUGE . 0. 0.4 3 0. 0. 0.9.9.3 2 0.9. R5 parts. No interest in HUGE TCs development TSs_and_TRs 51.9. Moved UID_400058 MBMS .010 53087 3GPP . 0.MS Conformance Tests (G3 new) 2010-04 Post-TSG#47 updates Completed: UID_440042 Rel-7 (U)SIM API Testing (TS 31.8.BTS Conformance Test (G1) UID_400059 Conformance Test Aspects – MBMS LCR TDD Physical Layer Enhancement (R5) UID_25035 Conformance Test Aspects – Enhanced CELL_FACH state in FDD (R5) 2009-12 Post-TSG#46 updates Completed: UID_400060 Conformance Test Aspects – MBSFN for FDD (R5) Ongoing: UID_440042 Rel-7 (U)SIM API Testing (CT6) UID_53087 HUGE .9. 0. REDHOT) RAN (R5) testing updates.9. 0.9.

10 (2010-06) among the participating companies 53088 REDHOT MS Conformance Tests G3new 12/11/201 0 55% GP062491 Ericsson GP#46 completion 09/10=>11/10 (was 02/10=>03/10=>09/10) 51.168 Overview of 3GPP Release 7 V0.010 3GPP .9.