Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации
Практические работы по географии для 6 класса
Организация работы процедурного кабинета
Обработка изделий медицинского назначения многократного применения
Изменения в неживой природе осенью
Уборка процедурного кабинета
Сольфеджио. Все правила по сольфеджио
Балочные системы. Определение реакций опор и моментов защемления
Summary of all Release 4 Features
Стр 1 из 8Следующая ⇒
Overview of 3GPP Release 4
Summary of all Release 4 Features
V. TSG #26
ETSI Mobile Competence Centre
У Copyright ETSI 2004
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
184.108.40.206 (G)MSC Server 8
220.127.116.11 Circuit Switched - Media Gateway (CS-MGW) 8
2.1.3 Interfaces and protocols. 8
18.104.22.168 Mc Reference Point: (G)MSC server to CS-MGW... 8
22.214.171.124 Nc Reference Point: MSC Server to (G)MSC Server 8
126.96.36.199 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
188.8.131.52 RAB Quality of Service Negotiation over Iu. 33
184.108.40.206 RAB Quality of Service Renegotiation over Iu. 33
220.127.116.11 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
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.
Global information on the Specifications (also called “specs”) can be found at:
The latest versions of all 3GPP specifications, containing the most recent corrections and additions, are available at:
For specific purposes, older versions might be needed. These versions are available at:
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.
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:
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:
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:
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.
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:
Further information on CR is available at:
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.
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
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.
18.104.22.168 Circuit Switched - Media Gateway (CS-MGW)
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.
Main responsibility:RAN WG1
Structure of the feature:
The Work Item Description Sheets can be found in the file RAN_Work_Items_History in:
References for WI "Low Chip Rate TDD option"
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.
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.
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.
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”.
Compared to R99 TDD, LCR TDD introduces new channels and removes others.
The following channels are 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 (TADV) 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
LCR TDD physical channel parameters in uplink
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
References for WI " 700 MHz spectrum support "
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
References for WI " MExE enhancements Rel-4 "
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 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.)
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
References for WI " Advanced Speech Call Items enhancements_REL-4 "
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:
· Wide Area Data Synchronization
References for WI " AT commands enhancements "
This work item is about AT 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 services:
· VBS, VGCS SIM Commands
Terminal Local Model
References for WI "Terminal Local Model"
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.).
References for WI " Rel-4 Location Services enhancements "
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 “EFPNN” (PLMN Network Name) (corresponding to the CPHS file EFOpName (PLMN Operator Name)). This file enables to display the operator name instead of a network code.
· A file called “EFOPL” (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.
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
References for WI "OSA improvements"
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:
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).
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:
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
This feature contains two independent items described in the next two sections.
8.1 Rel-4 Charging and OAM&P
References for WI "Rel-4 Charging and OAM&P"
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.).
Последнее изменение этой страницы: 2016-04-19; Нарушение авторского права страницы
infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 22.214.171.124 (0.088 с.)