TSG-SA Working Group 1 (Services) meeting #4 Bernried, Starnberger, German !

"t# Sept $ 1st %ct 1&&&

TSG S1 (99)868
Agenda 'tem : 6.3.6

()A*G+ ,+-.+ST *o / Technical Specification / Report UMTS Submitte to TS!"S# TS!$S#%& 22.129 0

Please see embedded help file at the bottom of this page for instructions on how to fill in this form correctly

Version:

3.0.0

for appro'al for information

(ithout presentation )*non$strate+ic*, (ith presentation )*strate+ic*,

list TSG plenary meeting no here

PT S!G "# co$er form is a$ailable from% http%&&docbo' etsi org&tech(org&smg&)ocument&smg&tools&"#*form&crf+8*1 ,ip

1roposed c#ange a22ects/

(at least one should be mar-ed with an .)

US-M

T.

/et(or0

Work item/ Source/ Sub4ect/

!SM UMTS 1an o'er S1 3ate/ 22.10.99

3erformance re4uirements for real time ser'ices an re4uirements for han o'er bet(een UMTS an !3RS 5 # 7 6 : 6orrection 6orrespon s to a correction in an earlier release # ition of feature 5unctional mo ification of feature . itorial mo ification ,e5ease/ 0 3hase 2 Release 9& Release 98 Release 99 UMTS 99

(ategor /
(one category and one release /nly shall be !ar-ed with an .)

,eason 2or c#ange/

Addressing performance requirements for UMTS to UMTS handover of real time services. The temporal discontinuity experienced by real time services should be shorter than the same event in GSM.

Addressing requirements for handover between UMTS and G !S. "andover to G !S !#$ core networ% shall be implemented. "andover of real time S services to G !S !## is out of the scope of UMTS !## phase & and shall be considered in subsequent phases. 'G !S can(t handle )oS requirements other than best effort* ; < ;.3 )ne(, < ;.3.1 )ne(, < &.2.; >ist of >ist of >ist of >ist of >ist of 6Rs: 6Rs: 6Rs: 6Rs: 6Rs:

(5auses a22ected/ %t#er specs A22ected/

=ther releases of same spec =ther core specifications MS test specifications / T7Rs 7SS test specifications =?M specifications

%t#er comments/

help. oc

@$$$$$$$$$ ouble$clic0 here for help an instructions on ho( to create a 6R.

GSM aa.bb ,ersion x.y.- '..../MM*

!eneral 3rinciples +o'ernin+ han o'er re4uirements

This section describes the general principles governing the operation of UMTS when preparing for and executing handover both within UMTS and to another radio system such as GSM. 0t also describes the additional concepts required to be included in GSM to allow preparation for and handover to UMTS. As a principle1 the requirements on handover characteristics should be according to the networ% to which the handover is made. The handover matrix
#andover possib5e6 5rom 5rom 5rom 5rom UMTS !SM$cs !SM$!3RS -MT2000 UMTS to .7TS 1 1 1 A to GS7-cs 1 =os =os =os to GS7-G1,S 1 oos oos oos to '7T!888 .7TS A =os =os =os

oos 2 out of scope of UMTS specifications &2 supporting standards required for UMTS release ##. x2 supporting standards required1 not necessarily for release ##. GSM/G !S in the table refers to !#$1 !#3 and !## G !S. 4or UMTS release ## means shall be defined which5 &* enable handover to a GSM networ% from a UMTS networ%6 +* enable handover to a UMTS networ% from a GSM networ%. 0n both the cases above the GSM networ% may be operated by either the same networ% operator as the UMTS networ% or a different networ% operator. "andover of real time S services between UMTS and G !S !## is out of the scope of UMTS !## phase & and shall be considered in subsequent phases. Service continuity of best effort pac%et services between UMTS and G !S is required.

;.1 Re4uirements for Ser'ice 6apabilities

UMTS standardises service capabilities1 not services. As part of the service capabilities it is envisaged that applications may wish to respond to events related to handover that either has occurred1 is about to occur or could potentially occur. The service capabilities described in this section should be available at least to U7 hosted applications. The following list is of uses is exemplary and is not intended to be exhaustive5 / / / an application may wish to accept or re8ect offered )oS6 an application may wish to cope to the effect that handover has on a service1 for example facsimile retransmission6 an application may with to preferentially choose radio resources1 for purposes such as So9SA.

0t is therefore required that the service capability set available to an application be able to provide an indication that handover has occurred or could occur with information about the type of handover and radio resources involved. The service capabilities should support )oS negotiation.

;.1.1 Support of localise ser'ice area )So>S#,

The UMTS service capability set shall support the 9ocalised Service Area '9SA* concept. 0t shall facilitate the creation of applications that implement user/dependent radio resource selection based on 9SA 'e.g. when user is located at his office1 radio coverage provided with indoor radio solutions should be preferred*. This may cause

GSM aa.bb ,ersion x.y.- '..../MM*

handover to be ta%e place within UMTS or into other radio systems. ;orresponding GSM feature has been specified in GSM <+.=:.

;.2 !eneral =perational 6onsi erations

;.2.1 6o'era+e en'ironment
Mechanisms defined to support handover between UMTS and other radio systems 'such as other UMTS modes1 other 0MT +<<< family members1 or GSM* should effectively cope with a number of coverage scenarios5 / / / limited UMTS coverage in a >sea> of coverage provided by another radio system 1 or vice/versa6 selective operation at a geographical boundary1 with extensive UMTS coverage on one side and extensive coverage from another radio system on the other side6 geographically co/located areas of UMTS coverage and another radio system.

"owever the standards should impose no restrictions or assumptions on how an operator might deploy or operate the networ% in both GSM and UMTS.

;.2.2 -nter =perator 1an o'er -ssues

"andovers between GSM and UMTS networ%s operated by different operators should remain an optional feature to implement. 0t is envisaged that handover would ta%e place due to changing radio conditions caused eg by movement of the terminal causing it toleave the coverage area of a networ%. The following networ%s may be involved with an inter/networ% handover procedure. These concepts are illustrated in Annex A5 / / the user(s home network, i.e. the operator where the user(s subscription may be found6 the user(s visited network where the subscriber user is currently registered1 i.e. the networ% where the subscriber user has performed the last successful update location procedure. As long as the subscriber user is roaming roams within the home networ%1 home and visited networ% are identical. the user>s serving network covering the cell that serves the subscriber. After successful completion of the update location update procedure1 the serving networ% is identical with the visited networ%. After an inter/ networ% handover1 the visited networ% is different from the serving networ% until a location update procedure has been successfully completed 'excepted the case that the subscriber returns into the visited networ%*. the target network covering candidate target cell's* for inter/networ% handover. The target networ% has overlapping radio coverage with the serving networ% but not necessarily with the visited networ%.

The minimum requirements for inter networ% "? are5 / / continuity of an active call across the handover procedure1 where this would be possible for intra/operator handover6 charging1 billing and accounting for inter/networ% handover should be according to the principles defined in UMTS ++.&@. 4or !>## the mechanisms currently used in GSM should be provided as a minimum 'charging for handover leg is based on vistited networ% tariff1 etc.1 settlement between operators is based on bul% metering1 etc.*6 the ability to chec% with the home networ% whether the user is permitted to handover from the visited networ% to a target networ%6 the decision whether the handover request is accepted must be ta%en by the target networ%6 invocation of the handover procedure only occurs if the target networ% provides the radio channel type required for the respective call6 the avoidance of Anetwor% hoppingA1 i.e. successive handover procedures between neighbouring networ%s for the same call6 the possibility of user notification of inter networ% "? 'eg possible tariff change* when it occurs.

/ / / / /

GSM aa.bb ,ersion x.y.- '..../MM*

;.2.3 6har+in+ an /et(or0 Mana+ement

Means shall be standardised which allow charging records to record the time of handover in the case of inter networ% operator handover. ;harging records must be able to reflect the level of service 1 operation mode 'eg. 4BB or TBB* and networ% type afterhandover. A capability to provide networ% management information relating to frequency of occurrence and type of handover should be defined.

;.2.; 6ost an efficiencB

The UT!AC standards shall facilitate the cost effective implementation both on the networ% and on the terminal side1 of multi mode operation between GSM and UMTS. 0mpacts on the GSM networ% shall be minimised. Such handover shall not require user intervention.

;.2.2 SecuritB
Security requirements relating to handover shall be elaborated in a separate document 'UMTS ::.+&1 security requirements*1 but should embody the principle that handover shall not compromise the security of5 the networ% providing the new radio resources6 the 'possibly different* networ% providing the original radio resources6 and the terminalU7. The security mechanisms should also cater for appropriate authentication processes and meet the requirements of national administrations in terms of lawful interception.

;.3 3erformance Re4uirements

;.3.1 TemporarB e+ra ation of ser'ice cause bB han o'er
Any degradation of service during intra UMTS handover or in the case of handover from UMTS to GSM1 shall be no worse than during intra GSM handover. The duration of the discontinuity experienced by S and ;S real time services should be shorter than that in the handover of GSM ;S speech calls.

Re4uirements for 1an o'er from UMTS to UMTS

2.1 1an o'er ue to U. Mo'ement

0t should be possible to provide a technical implementation of handover such that there is no measurable impact on the quality of any service when handover due to U7 movement occurs. This does not imply that all UMTS handovers will achieve this ideal. "owever1 the standards shall define at least one UT!A mode in which this is possible given the following5 / / U7 speed stays within limits for given service6 U7 stays constantly within UMTS coverage of a single UT!AC.

2.2 1an o'er 7et(een UMTS Mo es

The standards shall permit a technical implementation in which service is continued1 although there may be a temporary degradation which may affect teleservices at the time of handover.

2.3 1an o'er 7et(een .n'ironments

UMTS is expected to provide coverage in a number of environments including fixed and mobile. The standard shall enable handover between these environments as described in the table below. The following are indicative of long term requirements and do not necessarily apply to !##. "owever1 technical standardisation should not preclude the possiblity of implementing these requirements.

@
To 9rom Terrestria5 (e55u5ar 9i:ed;(ord5ess Sate55ite Terrestria5 (e55u5ar Ces Ces Ces

GSM aa.bb ,ersion x.y.- '..../MM*

9i:ed;(ord5ess Ces Ces Ces Sate55ite Ces Ces /o

2.; UMTS cell capacitB

;onsideration must be given services such as multimedia which may involve use of multiple bearers. Bue for example to cell loading1 it may happen that a target cell cannot support the combination of bearer services provided by the current serving cell. Means shall be provided for the application's* to indicate minimum acceptable )oS for services continuation after handover. Although all UMTS bearer services may not be handed over1 the handover to another UMTS cell should not be precluded.

&

Re4uirements for 1an o'er from UMTS to !SM

&.1 =perational Re4uirements

&.1.2 !SM ban s
The standard shall support handover to any combination of GSM bands supported by the GSM standards.

&.2 3erformance Re4uirements

The following service principles apply to performance requirements5 / when the U7 performs handover to GSM then the service requirements of GSM that relate to handover between different cells in different location areas is ta%en as the benchmar%. 0t is not the intention to setmore stringent service requirements for UMTS to GSM handover than are already commonly accepted for handover within GSM.

&.2.1 :etection Time of 3otential !SM 1an o'er 6an i ates

Means shall be defined which allow the U7 to achieve as good detection time performance as the GSM benchmar%5 ie to behave in such a way as to detect potential GSM handover candidates as quic%ly as a GSM mobile performing an intra GSM handover is required to do so.

&.2.2 /umber of !SM han o'er can i ates to etect

Means shall be available which allow U7 to detect an equal number of GSM handover candidates relative to the GSM benchmar%1 ie to behave in such a way as to detect as many potential GSM handover candidates as a GSM mobile performing an intra GSM handover is required to do so.

&.2.3 3robabilitB of 6onnection >oss

The service requirement is that it should be possible to hand over to GSM from UMTS with a probability of connection loss that fulfils the corresponding service requirement for intra GSM handover.

&.2.; TemporarB e+ra ation of ser'ice cause bB han o'er

The service requirement is that means should be defined so that it is possible to construct networ%s comprising GSM and UT!A radio resources in such a way that the duration and extent of any degradation of service during handover from UMTS to GSM is no worse than during intra GSM handover.