Summary of all Release 4 Features

Overview of 3GPP Release 4

Summary of all Release 4 Features

V. TSG #26

 

 

ETSI Mobile Competence Centre

У Copyright ETSI 2004

 

 

 

Credits

 

This document has been produced by the ETSI MCC department, headed by Adrian Scrase and then by John Meredith, namely Adrian Zoicas, Alain Sultan, Andrijana Jurisic, Cesar Gutierrez, Claude Arzelier, David Boswarthick, Friedhelm Rodermund, Jьrgen Caldenhoven, Kimmo Kymalainen, Michael Clayton, Paolo Usai, Per Johan Jorgensen and Maurice Pope. The work was coordinated by Alain Sultan, who wishes to acknowledge all contributors for the quality of their inputs.

 

Table of Content

 

1 Introduction.. 5

1.1 Scope. 5

1.2 References. 5

1.2.1 Specifications. 5

1.3 Tdocs. 5

1.3.1 Work Plan, Work Items and Study Items. 6

1.3.2 Change Request database. 6

2 New Features applicable to UMTS and GSM... 6

2.1 Bearer Independent CS architecture (also called “Bearer Independent Core Network”) 6

2.1.1 Introduction. 7

2.1.2 Architecture. 7

2.1.2.1 (G)MSC Server 8

2.1.2.2 Circuit Switched - Media Gateway (CS-MGW) 8

2.1.3 Interfaces and protocols. 8

2.1.3.1 Mc Reference Point: (G)MSC server to CS-MGW... 8

2.1.3.2 Nc Reference Point: MSC Server to (G)MSC Server 8

2.1.3.3 Nb Reference Point: CS-MGW to CS-MGW... 9

2.2 Features related to Speech encoding and decoding. 9

2.2.1 General speech coding concepts. 9

2.2.2 Relationship between TFO, TrFO and OoBTC.. 10

2.2.3 Tandem Free Operation (TFO) or In-band TFO.. 10

2.2.4 Transcoder-Free Operation/ Out-of-Band Transcoder Control 11

2.3 Transparent End-to-End PS mobile streaming application. 12

3 UMTS-only new Features. 14

3.1 Low Chip Rate TDD option. 14

3.1.1 Introduction. 15

3.1.2 Physical layer. 16

3.1.3 Layer 2 and Layer 3. 17

3.1.4 UE radio access Capability. 18

3.1.5 Iub/Iur protocol aspects. 18

3.1.6 Measurement and testing of radio propagation. 18

3.1.7 Interworking with GERAN.. 18

3.2 UTRA FDD Repeater Specification. 19

4 GSM-only new Features. 20

4.1 700 MHz spectrum support. 20

5 Improvements of UMTS and GSM pre-Release 4 features. 21

5.1 Multimedia Messaging Service. 21

5.2 MExE enhancements Rel-4. 23

5.3 Advanced Speech Call Items enhancements_REL-4. 24

5.4 Rel-4 Evolutions of the transport in the CN.. 25

5.5 Rel-4 Emergency call enhancements. 26

5.6 Rel-4 Terminal interfaces. 26

5.6.1 AT-commands enhancements. 26

5.6.2 Wide Area Data Synchronisation. 27

5.6.3 Terminal Local Model 28

5.7 Rel-4 Location Services enhancements. 28

5.7.1 General aspects. 28

5.7.2 Iub/Iur interfaces for UE positioning methods supported on the radio interface Release 99 (applicable only to UMTS) 29

5.8 Rel-4 UICC/(U)SIM enhancements and interworking. 29

5.8.1 Addition of CPHS features. 30

5.8.2 Other aspects. 30

5.9 Rel-4 (U)SIM toolkit enhancements. 30

5.10 Rel-4 Open Service Access (OSA) improvements. 31

6 Improvements of UMTS-only pre-Release 4 features. 32

6.1 QoS Architecture for PS Domain. 32

6.1.1 RAB Quality of Service (re)Negotiation. 33

6.1.1.1 RAB Quality of Service Negotiation over Iu. 33

6.1.1.2 RAB Quality of Service Renegotiation over Iu. 33

6.1.1.3 RAB Quality of Service Negotiation over Iu during Relocation. 33

6.1.2 PS-Domain handover for real-time services. 33

6.2 Rel-4 Evolutions of the transport in the UTRAN.. 34

6.2.1 QoS optimization for AAL type 2 connections over Iub and Iur interfaces. 34

6.2.2 Transport bearer modification procedure on Iub, Iur, and Iu. 35

6.3 Rel-4 Improvements of Radio Interface. 35

6.3.1 DSCH power control improvement in soft handover. 35

6.4 Rel-4 RAN improvements. 36

6.4.1 Node B synchronisation for TDD.. 36

6.4.2 Radio Access Bearer Support Enhancements for Rel-4. 37

7 Improvements of GSM-only pre-Release 4 features. 38

7.1 Gb over IP (GERAN improvements 1) 38

7.2 Network Assisted Cell Change - NACC (GERAN improvements 2) 39

7.3 Delayed TBF (GERAN improvements 4) 40

8 Other aspects. 41

8.1 Rel-4 Charging and OAM&P. 41

8.2 Miscelleneous UE Conformance Testing Activities. 42

8.3 Small Technical Enhancements and Improvements for Rel4. 43

8.4 Facsimile group 3, non transparent. 43

8.5 “Hollow” features. 44

8.5.1 Operator Determined Barring for Packet Oriented Services. 44

8.5.2 Rel-4 Security enhancements. 44

8.5.3 Global Text Telephony. 44

 

Introduction

Scope

This document contains a high-level description of the 3GPP Release 4 Features.

A Feature is defined as new or substantially enhanced functionality which represents added value to the existing system. A feature should normally embody an improved service to the customer and / or increased revenue generation potential to the supplier.

Features are as independent as possible from each other, and relationships between features (if any) are clarified here.

 

In some cases, a feature does not correspond to a single functionality but consists in a grouping of different independent items impacting the same parts of the system (e.g. "Release 4 RAN improvements"). These groupings are performed to artificially limit the total number of features for each Release. For these “basket” features, a summary of each item is provided.

For each feature (or independent item), 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 are provided in the beginning of the section describing the feature. Only the list of impacted specifications is provided here. The exact impact on a given specification due to a given feature is described in the Change Request (CR) list, which can be found at the end of the specification, or in the CR database, which provides the full list of CRs for all 3GPP specifications.

The second part of this introduction contains global references, and provides links towards the 3GPP Specifications, the temporary documents (tdocs), the Work Plan, the Work Item Descriptions (WIDs) and the CR database.

The main body of this document is structured according to the 3GPP Release 4 Features: each chapter corresponds to one Release 4 Feature.

References

Specifications

Global information on the Specifications (also called “specs”) can be found at:

http://www.3gpp.org/specs/specs.htm

 

The latest versions of all 3GPP specifications, containing the most recent corrections and additions, are available at:

http://www.3gpp.org/ftp/Specs/latest/

 

For specific purposes, older versions might be needed. These versions are available at:

http://www.3gpp.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), for all Releases.

Tdocs

The Temporary Documents (tdocs) are mainly the original papers written by the 3GPP Members, and are the inputs for elaborating the specs. They are available (sorted by 3GPP technical groups (Technical Specification Groups (TSGs) and Working Groups (WGs)) at:

 

http://www.3gpp.org/ftp/

 

starting with 'tsg....'.

 

Work Plan, 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. Potential subsequent versions narrow the target and foreseen completion date according the actual progress. They are stored in:

 

http://www.3gpp.org/ftp/Information/WI_sheets/

 

The 3GPP Work Plan is a living document, updated roughly each month, which contains the full list of Work Items and Study Items, as well as summary information for each WI, as: the WG in charge of it, its starting date and (foreseen or actual) completion date, the actual progress, etc. The Work Plan is available at:

 

http://www.3gpp.org/ftp/Information/WORK_PLAN/

 

Change Request database

A specification is originally drafted and maintained by a rapporteur, who compiles the contents from discussions in the WGs and TSGs. When it is considered to be 80% complete, it is brought under a so-called "change control" process. After this, 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, and then formally approved by the relevant Technical Specification Group[1].

 

The Change Request database contains all available information on Change Requests, including a Work Item code, a Change Request number that is unique within the specification (different versions are possible, but only one can ever be approved), the status of each Change Request and references to relevant temporary document numbers and meetings. This database is available in:

 

http://www.3gpp.org/ftp/Information/Databases/Change_Request/

 

Further information on CR is available at:

http://www.3gpp.org/specs/CR.htm

 

Introduction

The objective of this feature is to dissociate the transport and the control in the Circuit Switched (CS) domain. The aim is to offer a better transport resource efficiency and a convergence with the Packet Switched (PS) domain transport. Also, this enables to use one single set of layer 3 protocols (e.g. DTAP in TS 24.008 or MAP in TS 29.002) on top of different transport resources, as ATM, IP, STM, or even new ones.

 

The users shall not notice whether they are connected to a “bearer independent CS network” or to a classical CS domain. This implies that both types of network offer the same bearer and teleservices, and have same external behaviour for the handling of the call control, related supplementary services, application services and mobility support. Also, none of the protocols used on the radio interface is modified by this feature. This means for example there is no need for the terminals to support IP even if IP is the transport protocol used in the network.

Architecture

The basic principle is that the MSC is split into an MSC server and a (Circuit-Switched) Media Gateway (CS-MGW), the external interfaces remaining the same as much as possible as for a monolithic MSC. The MSC server provides the call control and mobility management functions, and the CS-MGW provides the stream manipulating functions, i.e. bearer control and transmission resource functions.

The same applies to the GMSC, split into a GMSC server and a CS-MGW.

 

BICC Network Architecture

G)MSC Server

The MSC Server comprises all the call control and mobility control parts of an MSC. As such, it is responsible for the control of mobile originated and mobile terminated CS domain calls. It terminates the user to network signalling (see in particular TS 24.008) and translates it into the relevant network to network signalling (see in particular TS 29.002). It also contains the VLR.

The MSC Server controls the parts of the call state that pertain to connection control for media channels in a CS-MGW.

A GMSC Server is to a GMSC as an MSC Server is to an MSC.

2.1.2.2 Circuit Switched - Media Gateway (CS-MGW [2])

The CS-MGW interfaces the transport part of the UTRAN/BSC with the one of the core network, over Iu or the A interface. It interacts with the (G)MSC server for resource control.

A CS-MGW may also terminate bearer channels from a circuit switched network and media streams from a packet network (e.g., RTP streams in an IP network). As the entity interfacing the access and the core network, the CS-MGW operates the requested media conversion (it contains e.g. the TRAU), the bearer control and the payload processing (e.g. codec, echo canceller, conference bridge). It supports the different Iu options for CS services (AAL2/ATM based as well as RTP/UDP/IP based).

The CS-MGW bearer control and payload processing capabilities also need to support mobile specific functions such as SRNS relocation/handover and anchoring. Current H.248 standard mechanisms are applied to enable this. Further tailoring (i.e packages) of the H.248 may be required to support additional codecs and framing protocols, etc.

Note that no confusion should be made between the CS-MGW defined here and the IMS Media Gateway, the IM-MGW, defined in Release 5.

Interfaces and protocols

UMTS-only new Features

Low Chip Rate TDD option

This section was elaborated in co-operation between MCC and the following Datang Mobile experts: Liyan Yin, Ke Wang, Darun Wang, Na Wu, Guiliang Yang, Qingguo Feng, Yusong He. Many thanks to all of them.

 

Acronym: LCRTDD

UID: 1222

Main responsibility: RAN WG1

 

Structure of the feature:

UID	Task name	WG	Acronym
	Physical layer	R1	LCRTDD-Phys
	Layer 2 and layer 3 protocol aspects	R2	LCRTDD-L23
	"RF radio transmission/reception, system performance requirements and conformance testing"	R4	LCRTDD-RF
	UE radio access capability	R2	LCRTDD-UErac
	Iub/Iur protocol aspects	R3	LCRTDD-IubIur
	Low chiprate TDD interworking with GERAN	GERAN

 

The Work Item Description Sheets can be found in the file RAN_Work_Items_History in:

ftp://ftp.3gpp.org/tsg_ran/TSG_RAN/Work_Item_sheets/

References for WI "Low Chip Rate TDD option"

 

Impacted Specifications / Reports
25.102	UE Radio Transmossion and Reception (TDD)
25.104	BTS Radio Transmission and Reception (FDD)
25.105	BTS Radio Transmission and Reception (TDD)
25.123	Requirements for support of Radio Resource Management (TDD)
25.142	Base station conformance testing(TDD)
25.113	Base station EMC
25.133	Requirements for support of Radio Resource Management (FDD)
25.201	Physical layer – General description
25.221	Physical channels and mapping of transport channels onto physical channels (TDD)
25.222	Multiplexing and channel coding (TDD)
25.223	Spreading and modulation (TDD)
25.224	TDD; physical layer procedures
25.225	Physical layer; measurements
25.302	Services Provided by the physical layer
25.303	UE functions and Inter-layer procedures in connected mode
25.304	UE procedures in idle mode and procedures for cell reselection in connected mode
25.305	User Equipment (UE) positioning in Universal Terrestrial Radio Access Network (UTRAN); Stage 2
25.306	UE Radio Access capabilities definition
25.321	Medium access control (MAC) protocol specification
25.331	Radio resource control (RRC) protocol specification
25.401	UTRAN Overall Description
25.402	Synchronisation in UTRAN Stage 2
25.423	UTRAN Iur Interface RNSAP Signalling
25.425	UTRAN Iur Interface User Plane Protocols for Common Transport Channel data streams
25.427	UTRAN Iub/Iur Interface User Plane Protocols for DCH data streams
25.430	UTRAN Iub Interface: General Aspects and Principles
25.433	UTRAN Iub Interface NBAP Signalling
25.435	UTRAN Iub Interface User Plane Protocols for Common Transport Channel data streams
25.922	Radio Resource Management Strategies
25.944	Channel coding and multiplexing examples
44.018	Radio Resource Control Protocol
44.060	Radio Link Control / Medium Access Control Protocol
45.002	Multiplexing and multiple access on the radio path
45.008	Radio subsystem link control
48.008	MSC-BSS interface Layer 3 specification
48.058	BSC-BTS interface Layer 3 specification
24.008	Mobile radio interface Layer 3 specification; Core network protocols; Stage 3
34.108	Common test environments for User Equipment (UE) conformance testing
34.122	Terminal conformance specification, Radio transmission and reception (TDD)
34.123-1	User Equipment (UE) conformance specification; Part 1: Protocol conformance specification
34.123-2	User Equipment (UE) conformance specification; Part 2: Implementation conformance statement (ICS) specification
34.124	Electromagnetic compatibility (EMC) requirements for Mobile terminals and ancillary equipment

 

New Dedicated Technical Reports
25.834	UTRA TDD low chip rate option; Radio protocol aspects
25.843	1.28 Mcps TDD UE Radio Access Capabilities
25.928	Low Chip Rate TDD Physical Layer
25.937	Low chip rate TDD Iub/Iur protocol aspects
25.945	RF requirements for 1.28 Mcps UTRA TDD option

 

Introduction

3GPP Release 99 UTRA (Universal Terrestrial Radio Access) included two basic modes of operation: Frequency Division Duplex (FDD) and Time Division Duplex (TDD). TDD can be introduced without needs for paired spectrum and is well-suited to asymmetric traffic.

In addition to Release 99 TDD, using a chip rate of 3.84 Mcps, Release 4 introduces an option that uses a chip rate of 1.28 Mcps. This mode is known as “1.28 Mcps TDD” through 3GPP specifications, and usually referred to as "Low Chip Rate TDD" (LCR TDD). In line with this formulation, R99 TDD is often called High Chip Rate TDD.

 

LCR TDD is also supported by ITU-R (where it is called “TD-SCDMA”) and Operators Harmonisation Group (OHG). LCR TDD operation mode is TDD mode. It takes advantage of varies available Multiple Access techniques: TDMA, CDMA, FDMA, SDMA. As one of IMT-2000 compliant system, LCR TDD can support all the bearer services and diversified radio propagation environments corresponding to ITU requirement.

 

The chip rate of LCR TDD is 1.28Mcp. The benefit of LCR TDD is that it can be supported on unpaired frequency bands of 1.6MHz hence it is more flexible than FDD and 3.84Mcps TDD that request a minimum bandwidth of 5 MHz. It can be deployed not only for high spot or high density area to provide high speed data service or to provide enhanced coverage, but also to be used alone as macro cell to provide the service coverage. LCR TDD allows deployment together with existing GSM system, with FDD system, with 3.84Mcps TDD system and should support the handover between UTRA modes (e.g., LCR TDD to 3.84Mcps TDD, LCR TDD to FDD) and between systems (e.g., LCR TDD to GSM).

Comparison between minimum bandwidth needed for FDD, HCR TDD and LCR TDD

 

The goal of LCR TDD is to enable the full integration of TD-SCDMA and its specific properties into the Release 4 specifications of 3GPP. In other words, the integration work of all aspects of LCR TDD is designed to maximize the commonality with the 3.84Mcps TDD. As a result of this requirement, LCR TDD shares most of the aspects of the high layer and network elements as the other modes. But LCR TDD has its unique physical layer structure and key features. Correspondingly, some elements or parameters in high layer and interface for LCR TDD are added, modified or extended to adapt physical layer features. Also the differences on RF, system performance and conformance testing requirements of LCR TDD reflect the characteristic of an LCR TDD system.

 

The different system impacts of LCR TDD are described hereafter.

Physical layer

The main differences between LCR TDD and UTRA R99 TDD are on physical layer, e.g. the differences on the frame structure and synchronisation scheme.

 

Frame structure

In LCR TDD, a radio frame has a duration of 10 ms and is subdivided into 2 sub-frames of 5 ms each, each sub-frame is then subdivided into 7 traffic time slots (“Ts”) of 675 ms duration each and 3 special time slots: DwPTS (downlink pilot timeslot), GP (guard period) and UpPTS (uplink pilot timeslot). This is different to 3.84 Mcps TDD, where there is no sub-frame. The LCR sub-frame of 5 ms allows for a faster update of power control and is well suited for smart antenna beamforming.

For high chip rate option, each 10 ms frame consists of 15 time slots, each allocated to either the uplink or the downlink. So it has both single and multiple-switching point configuration. While in the low chip rate option, the big Guard Period GP, the DwPTS and UpPTS physical channels are always between Ts0 and Ts1 whatever the level of asymmetry is, and there are always only 2 Switching Points per sub-frame.

 

The frame structure of LCR allows for a better control of the trade-off between quality and interference than with HCR. Indeed, given the switch of downlink to uplink, there is a risk of interference due to propagation delay. This risk of interference determines the size of cells. For the high chip rate option, there is no “DwPTS – guard – UpPTS” structure: the UL time slots are following the DL time slots immediately. This problem is avoided thanks to the guard period of LCR TDD.

 

Basic behaviour

In cell search procedure, unlike 3.84 Mcps TDD, the UE will search for the DwPCH at the first and then identify the scrambling code and basic midamble code.

Then, upon starting a transmission, the UE first accesses the cell through the UpPCH (uplink synchronisation burst, “power ramping”). The timing used for UpPCH is coarse and based on the DwPCH and P-CCPCH. The Node B will listen to the UpPCH burst, evaluate the timing and required power for the UE and send the information with the FPACH described below. The UE knows the correct timing and power level for the use of the PRACH, allowing for a more efficient use of resources (e.g. as the shorter initial sequence sent minimises interferences). This is similar to FDD mode “two step access”.

 

Physical Channels

Compared to R99 TDD, LCR TDD introduces new channels and removes others.

The following channels are introduced:

• Two dedicated physical synchronisation channels: DwPCH and UpPCH, equal to DwPTS and UpPTS above.
• A physical channel for random access, the Fast Physical Access CHannel (FPACH). FPACH is used by the Node B to carry, in a single burst, the acknowledgement of a detected signature with timing and power level adjustment indication to a UE.
• A 5ms TTI (Transmission Time Interval) is also introduced

On the other hand, two physical channels of 3.84 Mcps TDD, SCH and PNBSCH, are not needed in LCR option.

The transport and logical channels do not change.

 

Only one burst type is used. Transmit method of TFCI, TPC, SS, different basic midamble sequences and different timeslot formats differ compared to R99 TDD.

 

Modulation and spreading

While 3.84 Mcps TDD uses QPSK, LCR TDD can support 8PSK and QPSK, together with different combination scheme of downlink and uplink physical channel from UTRA TDD. 64 chips of a SYNC-DL sequence have been used for DwPTS and 128chips of a SYNC-UL sequence have been used for UpPTS, and there is a fixed relationship between the SYNC-DL sequence and the SYNC-UL sequence.

 

Physical layer procedures

Uplink Synchronisation is realised in completely different ways in the two TDD modes. In LCR TDD, the UL synchronisation replaces the timing advance function performed by higher layer interaction in HCR TDD. In LCR, it can be considered as part of the random access procedure, as shown in the “Basic behaviour” section.

 

To minimise interferences, a closed loop Power control (as for the FDD mode) is introduced, with cycles from 0 to 200 cycles/sec.

 

Physical Layer Measurements

Two new parameters are introduced: Timing Advance (T_ADV) and Received SYNC-UL Timing Deviation. The other parameters measured are similar to those of UTRA TDD.

 

Layer 2 and Layer 3

The changes on the Physical Channels imply new parameters and information elements (IEs) in the radio related protocols.

In RRC messages, the IEs referring to common physical channels had to be updated to cover both TDD chip rate options. New IEs are needed for FPACH, DwPCH and 5ms TTI. 3.84Mchips TDD and FDD and LCR TDD conduct similarly with respect to the following aspects: UE procedures in idle mode, Interlayer procedures in connected mode, Control plane protocol aspects, User plane protocol aspects, mobility aspects.

Timing handling function is now performed at Layer 1 with the UL synchronization procedure, providing higher accuracy. Thus timing advance as a Radio Resource Control Protocol (Layer 3) is not needed.

 

The different aspects of LCR TDD layer 2 and layer 3 protocol aspects are as follows:

 

The MAC layer controls the RACH transmission by a two step procedure. More precisely, it:

1) Selects an ASC from the available set of ASCs

2) Initiates PRACH transmission procedure (L1 starts with SYNC_UL/FPACH power ramping sequence)

3) Waits for access information from L1

4) Requests data transmission when receiving the indication “ready for RACH data transmission” from physical layer

5) Indicates successful completion of the MAC procedure to high layer

 

Concerning the RRC layer, LCR TDD uses the same messages as HCR TDD. Some IEs referring to special physical channel are introduced. The close power control, function offered by RRC, implies DPCH and PDSCH in 1.28Mchips TDD.

UE radio access Capability

The main difference between LCR and HCR TDD concerning UE radio access capabilities relates to the physical channel parameters, as shown in the tables below. The description of other aspects, e.g. PDCP parameters, RLC parameters, Transport channel parameters, Multi-mode related parameters, Multi-RAT related parameters, security parameters, UE positioning related parameters, are the same in both options. Compressed mode is not to be used in 1.28Mchips TDD.

LCR TDD physical channel parameters in downlink

Maximum number of timeslots per subframe	Defines the maximum number of timeslots per subframe that the UE can receive.
Maximum number of physical channels per subframe	This parameter defines how many physical channels can be received during one subframe. The distribution of the received physical channels on the received timeslots can be arbitrary.
Minimum SF	Defines the minimum spreading factor supported by the UE.
Support of PDSCH	Defines whether PDSCH is supported or not.
Maximum number of physical channels per timeslot	This parameter defines how many physical channels can be received within one timeslot.
Support of 8PSK	Defines whether 8PSK modulation is supported or not.

LCR TDD physical channel parameters in uplink

Maximum Number of timeslots per subframe	Defines the maximum number of timeslots per subframe that the UE can transmit.
Maximum number of physical channels per timeslot	Defines the maximum number of physical channels transmitted in parallel during one timeslot.
Minimum SF	Defines the minimum SF supported by the UE.
Support of PUSCH	Defines whether PUSCH is supported or not.
Support of 8PSK	Defines whether 8PSK modulation is supported or not.

 

Iub/Iur protocol aspects

To support the physical channel parameters as modified by LCR, some adaptations have been made on the Information Elements in radio link related signalling for Iub and Iur interfaces. This implies new parameters and IEs in the radio related protocols.

In NBAP and RNSAP messages, the IEs referring to time slot information, burst types, and common physical channels were updated to cover both TDD chip rate options.

 

Interworking with GERAN

Although the handover and the Cell Selection / Reselection to the low chip rate TDD are very similar to their 3.84 Mcps equivalents, there are some differences, e.g. modification of the system broadcast and measurement report, which are described and clarified. Basically, most of them were originated from the differences of physical layer between low chip rate TDD and 3.84 Mcps TDD.

 

GSM-only new Features

MHz spectrum support

 

Acronym: 700SS

UID: 2403

Main responsibility: GP

 

References for WI " 700 MHz spectrum support "

Document	Title/Contents
GP-000449	WI Description
Impacted Specifications
TS 51.010   TS 51.021   TS 43.022   TS 43.030 TS 44.018 TS 24.008 TS 45.001 TS 45.005 TS 45.008	Mobile Station (MS) conformance specification; Part 1: Conformance specification Base Station System (BSS) equipment specification; Radio aspects Functions related to Mobile Station (MS) in idle mode and group receive mode Radio network planning aspects Radio Resource Control (RRC) protocol Core network protocols; Stage 3 Physical layer on the radio path; General description Radio transmission and reception Radio subsystem link control
New Dedicated Specifications
	None

 

Contains:

	GERAN support for the 700 MHz band	GP-000450
	GERAN MS Conformance test for 700 MHz band	GP-000451
	GERAN BTS Conformance test for 700 MHz band	GP-000452

 

This feature provides GERAN system support for 700 MHz frequency band.

The commercial use of the 746-764 MHz and 776-794 MHz bands may be launched by US operators who have shown interest to provide GSM services on those new bands. In order to be one candidate technology to be used as a cellular service for those bands, the GSM specifications are now including the support of the so-called 700 MHz spectrum.

This was widely facilitated by the band independent format of GSM specifications: almost all aspects, as Service, MMI, Charging or Security aspects, are the same as in other bands (400, 850, 900, 1800 and 1900 MHz bands).

When considering GSM for the 700 MHz band, potential extension on further frequency bands like 430-450 MHz, 698-746 MHz, 1710-1885 MHz, 2500-2690 MHz was considered, e.g. in the channel numbering.

MExE enhancements Rel-4

 

Acronym: MExE

UID: 1445

Main responsibility: T2

 

References for WI " MExE enhancements Rel-4 "

Document	Title/Contents
TP-030052	WI Description
Impacted Specifications
TS 22.057 TS 23.057	Mobile Execution Environment stage 1 Mobile Execution Environment stage 2
New Dedicated Specifications
	None

 

The work item MExE enhancements Rel-4 consists of two aspects:

· MExE Rel-4 Improvements and Investigations: several enhancements are introduced in Release 4 of which the most significant ones are mentioned in the MExE description below

• MExE Security Analysis Activity: this task was suggested to carry out an analysis of the MExE security framework and evaluate if it is sufficient to eliminate the risks posed by downloading content and applications. This analysis was performed by SA3 (Security) in co-operation with T2-MExE group.

 

MExE is a feature introduced in GSM Release 98, enhanced in GSM Release 99 to cover SIM MExE certificate management, security clarifications and QoS aspects. Release 4 introduces further enhancements of which the most significant is the introduction of a new small footprint Java classmark (Classmark 3).

 

MExE provides a standardised execution environment in an MS, and an ability to negotiate its supported capabilities with a MExE service provider, allowing applications to be developed independently of any MS platform. The MS can then be targeted at a range of implementations for MExE from small devices with low bandwidth, limited displays, low processor speeds, limited memory and MMI to sophisticated devices with a complete MExE execution environment.

 

A standardised means of negotiating the MSs’ and network’s capabilities is supported. This negotiation permits the mutual exchange of capabilities between the MS and the MExE server, and possibly includes the service profile of the user and capabilities of the network.

 

A network can be a transport bearer for the negotiation, interaction and transferring of applications, applets and content with the MS. It does not have to be the provider of the MExE services with which the MS’s execution environment is interacting with. The network may also be the intermediary between two MSs which are engaged in a MExE service with each other, with the network effectively supplying the “pipe” and not playing a MExE role in the connection. Network nodes, nodes external to the network, or even MSs are the entities which can interact with the MSs’ execution environment.

 

Central elements of the MExE specification are the classmark concept, content negotiation and the security architecture which are explained below.

 

The MExE classmark provides the device’s capabilities. The following classmarks are defined in Release 4 (in Rel-4 MExE classmark 3 was added):

 

· MExE classmark 1 - based on Wireless Application Protocol (WAP) - requires limited input and output facilities (e.g. as simple as a 3 lines by 15 characters display and a numeric keypad) on the client side, and is designed to provide quick and cheap information access even over narrow and slow data connections.

· MExE classmark 2 - based on Personal-Java - provides and utilises a run-time system requiring more processing, storage, display and network resources, but supports more powerful applications and more flexible MMIs. MExE Classmark 2 also includes support for MExE classmark 1 applications (via the WML browser.)

• MExE classmark 3 – based on J2ME CLDC and MIDP environment – supports Java applications running on resource-constrained devices. Classmark 3 MExE devices are based on the Connected Limited Device Configuration (CLDC) with the Mobile Information Device Profile (MIDP). Java 2 Micro Edition (J2ME) is a version of the Java 2 platform targeted at consumer electronics and embedded devices. CLDC consists of a virtual machine and a set of APIs suitable for providing tailored runtime environments. The J2ME CLDC is targeted at resource constrained connected devices (e.g. memory size, processor speed etc.)

 

Content negotiation allows for flexible choice of formats available from a server or adaptation of a service to the actual classmark of a specific client device. Bi-directional capability negotiation between the MExE Service Environment and MExE device (including MExE classmark), supports the transfer of capabilities between the client and the server.

 

In order to manage the MExE and prevent attack from unfriendly sources or transferred applications unintentionally damaging the MExE device a security architecture is specified. The basis of MExE security is:

· a framework of permissions which defines the permissions transferred MExE executables have within the MExE MS;

· the secure storage of these permissions and permission types;

· conditions within the execution environment that ensure that MExE executables can only perform actions for which they have permission.

 

The MExE permissions framework is as follows (there is no implied hierarchy):

· MExE Security Operator Domain (MExE executables authorised by the HPLMN operator);

· MExE Security Manufacturer Domain (MExE executables authorised by the terminal manufacturer);

· MExE Security Third Party Domain (trusted MExE executables authorised by trusted third parties);

· Support for the three domains is mandatory;

Untrusted MExE executables are not in a specific domain, and have very reduced privileges.

 

In Release 4 several enhancements to the security framework have been introduced in particular enhancements related to the new MExE classmark 3 based on J2ME CLDC and MIDP.

 

Another enhancement in Release 4 is the optional support of core software download. Core software download enables the UE radio, characteristics and properties to be updated by changing the software in the UE. E.g. a new codec may be loaded into a device, a new air interface, etc. Guidelines are introduced into the specification but the functionality is not specified in detail.

5.3 Advanced Speech Call Items enhancements_REL-4

 

Acronym: ASCI

UID: 2230

Main responsibility: CN1

 

References for WI " Advanced Speech Call Items enhancements_REL-4 "

Document	Title/Contents
NP-000730	WI Description on ASCI Release 4 enhancements
Impacted Specifications
TS 43.068 TS 43.069 TS 44.068 TS 44.069 TS 24.008	Voice Group Call Service (VGCS); Stage 2 Voice Broadcast Service (VBS); Stage 2 Group Call Control (GCC) protocol Broadcast Call Control (BCC) protocol Mobile radio interface Layer 3 specification; Core network protocols; Stage 3
New Dedicated Specifications
	None

 

This work item was introduced manly for maintenance of the ASCI feature. ASCI refers to the use of GSM for Railways (GSM-R).

The Release 4 enhancements cover ASCI’s High Speed Train Interoperability, as requested by the TSI (Technical Standards for Interoperability).

The enhancements are the possibility to add operator-to-dispatcher information, the definition of ASCI related event records, and the introduction of ciphering for Voice Group Call Service (VGCS)/Voice Broadcast Service (VBS).

Rel-4 Terminal interfaces

 

The Feature Rel-4 Terminal Interfaces consists of the following three independent functionalities which are described in the following sections:

• AT commands enhancements

· Wide Area Data Synchronization

• Terminal local model

AT-commands enhancements

 

Acronym: TI-ATC

UID: 1827

Main responsibility: T2

 

References for WI " AT commands enhancements "

Document	Title/Contents
	No WID
Impacted Specifications
TS 27.007	AT command set for User Equipment (UE)
New Dedicated Specifications
	None

 

This work item is about AT[6] commands for control of 3GPP Mobile Equipments (MEs) via an external Terminal Equipment (TE), fully compatible with GSM AT commands.

 

TS 27.007 specifies a profile of AT commands and recommends that this profile be used for controlling ME functions and GSM network services from a TE through Terminal Adaptor (TA). The command prefix +C is reserved for Digital Cellular in ITU-T Recommendation V.25ter. This TS has also the syntax details used to construct these extended GSM commands. Commands from ITU-T Recommendation V.25ter and existing digital cellular standards (TIA IS-99 and TIA IS-135) are used whenever applicable. Some of the new commands are defined such way that they can be easily applied to ME of networks other than GSM.

 

The new AT commands added in Release 4 relate all to ASCI[7] services:

 

• Introduction of a new AT command +CUUS1 to manage User-to-User Information element
• Indication of priority and/or sub-address in the unsolicited result code CCWA
• eMLPP SIM Commands

· VBS, VGCS SIM Commands

• Extension of dial command for VBS and VGCS
• Introduction of a new AT command +COTDI to manage Originator-to-dispatcher information element

Terminal Local Model

 

Acronym: TLM

UID: 1832

Main responsibility: T2

 

References for WI "Terminal Local Model"

Document	Title/Contents
TP-000080	WI Description
Impacted Specifications
TS 23.227	Application and User interaction in the UE - Principles and specific requirements
New Dedicated Specifications
	None

 

The rapid development of a diversity of new applications and application environments for mobile usage creates a complexity of previously unseen proportions that the Mobile Equipment has to handle. Since third party software can run in various parts of the UE, there was a need to develop a general framework to ensure that the APIs created for the different UE-based toolkits work in harmony with each other.

 

The work item introduces such a generic model approach for the UE environment; the purpose is not to categorise the applications peripherals, but to try to structure the events that are internal and external to, and has to be handled by, the MT Core Functions. This means that the structure or grouping of the events is done from a MT centric perspective. Some applications run on the UE side have counterparts in the network. The functions in the network are not addressed in this work.

 

Under this work item the principles were defined for scheduling resources between applications in different application execution environment (e.g. MExE, USAT etc.) and internal and external peripherals (e.g. infra-red, Bluetooth, USIM, radio interface, MMI, memory etc.).

General aspects

 

Acronym: LCS1

UID: 401536

Main responsibility: S2

 

References for WI " Rel-4 Location Services enhancements "

Document	Title/Contents
SP-010518	WI Description
Impacted Specifications
TS 25.305	LCS Stage 2 (UTRAN part)
New Dedicated Specifications
TS 23.271 TS 43.059	LCS Stage 2 (CN part) LCS Stage 2 (GERAN part)

 

Between Rel99 LCS and Releases 4 LCS, the main difference concerns the documentation: the Stage 2 documents are restructured, as shown in the figure below.

 

Restructuring of LCS Stage 2 between Release 99 and Release 4

 

From a functionality point of view, Release 99 and Release 4 LCS are practically identical. The main difference is that the support of OTDOA method in LCR TDD mode is introduced in Release 4, as LCR TDD itself is introduced in this Release (see corresponding description in this document).

Also in Rel 4, the "Deferred Location Request" is introduced: in response to this request, the location is provided to the LCS client as soon as the target mobile becomes reachable again. Deferred answers triggered by other types of events are also considered, but are not standardised in this Release (not even in Release 5).

Lastly, new OSA APIs (Application Programming Interface for Open Access Service) are defined for the LCS.

Addition of CPHS features

This item refers to the incorporation in the Release 4 Standard of some terminal and USIM functions which were previously defined in a stand-alone addendum to the 3GPP standard known as the “CPHS features”, “CPHS” meaning “Common PCN (Personal Communication Network) Handset Specification”. These functions were already available in some pre-Rel 4 equipments and have proven to be useful.

They consist of additions in the USIM of:

· A file called “EF_PNN” (PLMN Network Name) (corresponding to the CPHS file EF_OpName (PLMN Operator Name)). This file enables to display the operator name instead of a network code.

· A file called “EF_OPL” (Operator PLMN List) to indicate for which Location Area Identities a required network name is to be displayed

· Mailbox numbers and “Message waiting” indicators. Several mailbox Numbers can be stored, one per type of message: Voicemail, Fax, Electronic Mail and Other messages. A short message may be used to indicate the status, types and number of waiting messages. The ME shall present this indication as an icon on the screen, or other MMI indication, and store the indication status on the SIM/USIM to allow the status to be retained through power off/on, SIM/USIM movement between UEs etc. The ME shall be able to accept and acknowledge these message waiting status short messages irrespective of the memory available in the SIM/USIM.

Other aspects

WID on "Report on SIM/USIM interoperation" was approved for Release 4 and TR 31.900 was created, but withdrawn in TP#16 plenary meeting. TR 31.900 remains valid only in Rel-5.

Rel-4 Open Service Access (OSA) improvements

 

Acronym: OSA1

UID: 401142

Main responsibility: CN5

 

References for WI "OSA improvements"

Document	Title/Contents
WIDs
SP-000216 (S1-000447)	WI on Scope of Open Interface for Service Provision in Release 2000 (SA1)
SP-000302	OSA security (SA3)
Impacted Specifications
22.121	Service aspects; The Virtual Home Environment; Stage 1
23.127	Virtual Home Environment (VHE) / Open Service Access (OSA); Stage 2
29.198	Open Services Architecture API part 1 (R99 was split in Rel-4 in a multi-part TS, see below)
29.998	Open Services Architecture API part 2 (R99 was split in Rel-4 in a multi-part TS, see below)
33.102	Security Architecture
New Dedicated Specifications
22.127	Service Requirement for the Open Services Access (OSA); Stage 1
33.200	MAP Application Layer Security
	OSA API
29.198-01	Part 1: Overview
29.198-02	Part 2: Common data
29.198-03	Part 3: Framework
29.198-04	Part 4: Call control
29.198-05	Part 5: Generic user interaction
29.198-06	Part 6: Mobility
29.198-07	Part 7: Terminal capabilities
29.198-08	Part 8: Data session control
29.198-11	Part 11: Account management
29.198-12	Part 12: Charging
	OSA API Mapping for OSA
29.998-01	Part 1: General Issues on API Mapping
29.998-04-1	Part 4: Call Control Service Mapping; Subpart 1: API to CAP Mapping
29.998-05-1	Part 5: User Interaction Service Mapping; Subpart 1: API to CAP Mapping
29.998-05-4	Part 5: User Interaction Service Mapping; Subpart 4: API to SMS Mapping
29.998-06	Part 6: User Location and User Status Service Mapping to MAP
29.998-08	Part 8: Data Session Control Service Mapping to CAP

Open Service Access (OSA) allows service development by operators and third parties: it enables application developers to make use of network functionality through open, standardised, secure, extensible and scalable interfaces. Applications see the network functionality offered to them as a set of Service Capability Features (SCFs) in the OSA APIs. These SCFs provide access to the network capabilities on which the application developers can rely when designing their applications. The OSA APIs are independent of where or which network capabilities are implemented in the network, and of vendor-specific solutions and programming languages.

 

This work (stage 1, 2 and 3 specifications) was done jointly with other fora (3GPP2, ETSI SPAN and Parlay), so that there is a single set of standard OSA APIs for the whole development community.

 

The objective of OSA in Release 4 is to enhance the OSA interface for the communication between Applications and Service Capability Features (SCF). The SCFs are described in the OSA set of specifications.

 

Release 4 brings enhancements to the OSA interface based on the evolved network capabilities within the Core Networks. Examples of these are:

• Call Control (IP)

This addresses the Call Control capabilities based on SIP and/or H.323. In 3GPP, SIP is introduced only in Release 5 with the IMS (IP Multimedia Subsystem). However, it is justified to have the corresponding OSA capability as early as Release 4 because SIP and H323 exist in fixed networks for some time and the 3GPP OSA has a requirement to have the same API for Fixed and Mobile networks (and, more generally, to be network-agnostic).

• E-Commerce

This takes into account the capabilities provided by the network to use the capabilities provided by the post processing of the charging capabilities (e.g. E-Pay). It also involves the enhancements of the security to be provided by the network and by the application.

 

The enhancements compared to OSA Release 99 are as follows:

• User Location: Further integration of the Location Services within the provisioning of geographical positioning information, taking into account the evolution of the 3G networks associated with this capability.
• Terminal Capabilities: In Release 99, the mechanism to retrieve the terminal capabilities is only applicable to WAP phones. Rel-4 adds a mechanism that is applicable to all types of phones. Security mechanisms for the display of terminal capabilities information have been added.
• Enhanced User Profile Management: The integration of the Personal Service Environment Management (PSEM) within the Network and Framework SCFs.
• Enhanced Session Control: This provides the enhancements of the bearer manipulation and creation of bearers/sessions sessions (in particular negotiation of the QoS).

 

The OSA API offer many capabilities related to charging (they supervise of user activities for online charging features; allow applications to access the online account; allow applications to add charging information to network based charging records; and inform applications on network based charging event).

Rel-4 RAN improvements

 

Acronym: RANimp

UID: 400009

Main responsibility: RAN

 

This feature contains two independent items described in the next two sections.

Other aspects

8.1 Rel-4 Charging and OAM&P

 

Acronym: OAM

UID: 401142

Main responsibility: SA5

 

References for WI "Rel-4 Charging and OAM&P"

Document	Title/Contents
SP-000524	SA5 proposed Work-Plan & Work Items for Release 4. It contains the following WIDs:
S5-000569	WID for Feature: UTRAN Operations and Maintenance procedures (UOAM)
S5-000570	WID for Feature: Charging and OAM&P (OAM)
S5-000571	WID for BB: Principles, high level Requirements and Architecture (OAM-AR)
S5-000572	WID for BB: Configuration Management (OAM-CM)
S5-000573	WID for BB: Fault Management (OAM-FM)
S5-000574	WID for BB: Performance Management (OAM-PM)
S5-000575	WID for BB: Charging Management (OAM-CH)
Impacted Specifications
32.101	Telecommunication management; Principles and high level requirements
32.102	Telecommunication management; Architecture
	On Telecommunication management; Fault Management:
32.111-1	Part 1: 3G fault management requirements
32.111-2	Part 2: Alarm Integration Reference Point (IRP): Information Service
32.111-3	Part 3: Alarm IRP: CORBA Solution Set
32.111-4	Part 4: Alarm IRP: CMIP Solution Set
New Dedicated Specifications
On Telecommunication management; Charging management
32.200	Charging principles
32.205	Charging data description for the Circuit Switched (CS) domain
32.215	Charging data description for the Packet Switched (PS) domain
32.235	Charging data description for application services
	On Telecommunication management; Configuration Management (CM);
32.300	Name convention for Managed Objects
	Notification IRP series:
32.301	Requirements
32.302	Information Service
32.303	CORBA Solution Set
32.304	CMIP Solution Set
	Generic IRP management series:
32.311	Requirements
32.312	Information Service
	On Telecommunication management; Performance Management (PM);
32.401	Concept and requirements
52.402	Performance measurements - GSM
32.403	Performance measurements - UMTS and combined UMTS/GSM
	On Telecommunication management; Configuration Management (CM):
32.600	Concept and high-level requirements
	Basic CM IRP series:
32.601	Requirements
32.602	Information Service
32.603	CORBA Solution Set
32.604	CMIP Solution Set
	Bulk CM IRP series:
32.611	Requirements
32.612	Information Service
32.613	CORBA Solution Set
32.614	CMIP Solution Set
32.615	XML file format definition
	Generic network resources IRP series:
32.621	Requirements
32.622	Information Service
32.623	CORBA Solution Set
32.624	CMIP Solution Set
	Core network resources IRP series:
32.631	Requirements
32.632	Network Resource Model (NRM)
32.633	CORBA Solution Set
32.634	CMIP Solution Set
	UTRAN network resources IRP series:
32.641	Requirements
32.642	Network Resource Model (NRM)
32.643	CORBA Solution Set
32.644	CMIP Solution Set
	GERAN network resources IRP series:
32.651	Requirements
32.652	Network Resource Model (NRM)
32.653	CORBA Solution Set
32.654	CMIP Solution Set
	Others
32.800	Management level procedures and interaction with UTRAN

 

 

The objective of Release 4 Charging and OAM&P (Operation, Administration, Maintenance and Provisioning, also called OAM) is to continue progressing the framework to be followed by all 3GPP TSGs and WGs dealing with 3G Systems' Telecom Management (e.g. SA5, RAN O&M, GERAN O&M, etc.).