Report of the Workshop on Handover and Cell Selection
9th and 10th of June 1999
Sophia Antipolis, France
Chairman: Niels Andersen, Motorola
MCC Support: Alain Sultan, MCC
Table of Contents
1. Opening of the meeting
*2. Approval of the Agenda
*3. Clarifications on the terminology used in this report
*4. Handover
*4.1. Presentation of the Tdocs and related discussions
*4.2. Conclusions on the handover session
*4.2.1. Classification of the inter-system HO cases
*4.2.2. Distinguish roaming from HO
*4.2.3. Items identified as requiring urgent further studies
*4.2.4. Indications for improvements on 22.129
*5. PLMN Selection, Mode Selection and Cell Selection
*5.1. Presentation of the Tdocs and related discussions
*5.2. Conclusions on cell selection
*5.2.1. Establishing priorities between PLMN selection, mode selection and cell selection
*5.2.2. Documentation on idle mode
*6. Any other business
*7. Closing
*Annex 1: answer to the questions raised by RAN2 in Tdoc WHO-99017
*General
*PLMN Selection and Reselection
*Radio Access System Selection and Reselection
*Radio Access Mode Selection and Reselection
*Annex 2: Tdoc list
*Annex 3: Participant list
*
Mr. Niels Andersen from Motorola, acting as chairman, welcomed the delegates at the Workshop on Handover and Cell Selection. 74 participants were present, coming from SMG2, SMG3, SA1, SA2, SA3, RAN2, CN1 or CN2. The meeting was hosted by ETSI at Sophia Antipolis, on the French Riviera, at Hôtel Médiathel on the first day and at ETSI premises on the second day.
The agenda was distributed as WHO-99001. It was approved as such, even if it was not strictly followed during the meeting.
The terms used in this report are defined as follow:
A Mode is the type of protocol suite used for the communications between the entities of a telecommunication system. This report deals with only two modes: GSM or UMTS. This definition does not apply when the word ‘mode’ is used in the strings ‘idle mode’ and ‘connected mode’. The term System is used as synonymous of Mode.
A PLMN has the same meaning as in GSM, i.e. a mobile network owned by a single operator defined by one single value of the MCC+MNC codes. One PLMN can be single mode or multi-mode (if the same value of MCC+MNC codes is used for the two different modes).
This terminology is used for this report only, and might contradict the one used elsewhere. It does not claim to be totally rigorous but should anyway improve the readability of this report.
WHO-99032, source R3: LS to S2 answered in WHO-004 on Node Identification over Iu
See WHO-99004.
WHO-99004, source S2: LS from TSG SA WG2 to RAN3 on Manifestations of Handover and SRNS Relocation and answer on the liaison on Node identification over the Iu
This TDoc is a LS from S2 to R3 (copy to the workshop), asking RAN3 whether simultaneous mode is to be supported for all detailed cases of handover and SRNS relocation. It also clarifies that BSS GSM in one type of radio access technique and stresses that handover between UTRAN and BSS is definitely required for UMTS release 99.
The following documents were distributed for background information:
WHO-99034, source S2 and R3: exchanges of LSs between R3 and S2 on CN architectures to be supported in UMTS Release 99
WHO-99019, source SA WG1: 22.100 version 3.2.0 "UMTS phase 1"
WHO-99020, source SA WG1: 22.101 version 3.5.0 "UMTS Service principles"
WHO-99022, source RAN WG3: 25.832 version 2.1.1 "Manifestations of handover and SRNS relocation"
WHO-99015, source Editor of 22.129: Definition of Handover
This paper presents the definition for Handover in 22.129 and proposes some modification on it: The process of changing the network radio resources that are used to provide the bearer services for active connection mode teleservice, while maintaining a defined bearer quality.
The definition of inter/intra network HO is also presented, as well as inter-systems HO.
Discussion: The terms ‘radio network’, used in the inter/intra network HO definitions, were said to be imprecise as they can refer either to the UTRAN or to a PLMN. The following definition was proposed: one PLMN with one RAN technology.
The term "network", used in the HO definition, was said to be by itself too fuzzy for the definition to be understandable. It should be preferred more precise terms such as "inter-RNC HO",…
The HO definition provided in WHO-99015 was said to be improvable (streamlining is e.g excluded by the definition of 15).It was commented that there are other procedures that change the radio resources while maintaining the defined bearer quality as e.g. channel reconfigurations and power control.
It was stressed that another HO definition is used in TSG R2, stating that a HO occurs when a MS get radio resource from another cell. It was then said that intra-cell HO (in the GSM sense) is excluded from this definition. It was stressed that the key point is that HO can occur only once a RRC connection has been established.
It was also discussed, without reaching any real consensus, whether HO can allow or not a degradation of the QoS.
Conclusion: noted. It triggered some discussions, carried on during the presentation of other tdocs, which conclusions are reported in the ‘conclusions’ section of this report.
WHO-99021, source SA WG1: 22.129 version 3.0.0 "Handover Requirements between UMTS and GSM or other"
A presentation of this document is offered in WHO-99025.
WHO-99025, source Rapporteur: Service requirements for Handover (UMTS 22.129)
This document is a power point presentation of 22.129 (distributed as WH0 99-021). The key chapters of 22.129 are the service requirements on HO: for UMTS-UMTS (chapter 5), UMTS-GSM (chapter 6), GSM-UMTS (chapter 7). The General Principles are presented in chapter 4. UMTS to other systems HOs will be studied later.
Discussion: This document was discussed section by section:
Chapter 4 (on general principles): one key principle is that "if it is possible to hand over a bearer intra-operator, then it also is possible inter-operator". It was commented that "operator" is a commercial concept. It should be preferred to use more technical concepts, like a "PLMN" defined by a single value of the MCC + MNC fields, like in GSM. The inter/intra-PLMN HO will then replace the inter/intra-operator HOs classification.
Whether all the requirements (security, …) are the same in the cases the two PLMNs are handled by the same operator or not should be clarified. The conclusions on inter-PLMN HOs are reported in the conclusion section.
In the case of UMTS islands belonging to one operator offering spotted coverage "in a sea" of GSM coverage provided by another operator, it was questioned whether the GSM network has to act so that the UMTS customer (roamed on the GSM network) has to be handovered back to the UMTS network as soon as he returns back under UMTS coverage. The UK regulator explained that his requirement is that there should be the same behaviour of the networks irrespective of whether the UMTS and the GSM networks are operated by the same or by different operators. This does not necessarily mean for the GSM network to immediately return the user to the UMTS network.
Whether Network Preference relies into the HLR (decided at subscription) or whether it is established on a per-call basis was questioned. There were some guesses that both cases should be available.
Conclusion on chapter 4: The different HO cases mentioned during the discussion, reported in the conclusion, have to be clearly reflected. S1 should clarify the chapter 4 in the light of what was said during this meeting.
Chapter 5: no comments.
Chapter 6: concerning the statement "no requirement on Fax", it was clarified that this does not mean that Fax should not be handed over. The rapporteur explained that the sections on fax were introduced at the time fax was not identified as a teleservice for UMTS, so the corresponding requirement may need to be revisited (now that fax has been re-introduced as teleservice). It was stressed that in GSM, no service identification is performed on the TCH for HO, so it may not make any sense to distinguish among the different teleservices as long as they are supported by the same bearer service type.
"no requirement on SMS": it was clarified that SMS is handed over within GSM, in the sense a SMS is not loosed when GSM MS moves from one cell to another. It was stressed that the statement might reflect a problem of terminology: there is no bearer continuity for SMS so the term ‘handover’ may be inappropriate. This should be clarified in 22.129.
On operational requirements: "quality of UMTS<->GSM handover is the existing GSM performance", it was clarified that this does not refer to inter-PLMN GSM HO as this feature is not defined for GSM (even if it can work with some tricks). This requirement does not mean that it is prohibited to offer a best HO than in GSM.
It was commented that for GSM to GSM HO, the performance can be degraded because the UMTS channels might be monitored in addition of the GSM ones, e.g. some degradations in term of the number of GSM supervised channels might occur. The implementation indications should be studied by SMG2.
WHO-99003, source S2: LS on Area concept
This LS introduces the idea of using registration areas common to GSM and UMTS (at least for CS services) as to avoid location updates when the MS hand-off from one system to the other. Some issues on specific topics (security, network/terminal capabilities, paging channels,..) are raised with respect to this idea.
Discussion: It was remembered that there is a trade-off on the size of the location/routing area, resulting from the frequency of location update procedures (pushing for large areas) and the broadcast of paging messages (pushing for small areas).
As GSM+GPRS use two types of registration area (namely LA and RA), the proposal was explained for UMTS to re-use both RA and LA. It was explained that no modification is expected on GSM other than introducing the support of combined GSM LA/UMTS LA update: this combined procedure is expected to be performed just like the combined LA/RA update is performed for GSM/GPRS. The same applies for combined GPRS RA/UMTS RA update.
Some more explicit terms than ‘network service capability’ were requested (this refers to e.g. bit rates,…).
Conclusion: noted.
WHO-99018, source Siemens: GSM to UMTS Hand-over - Radio Interface Requirements
This Tdoc lists a set of requirements on the radio interface for GSM to UMTS HOs, like: It must be possible to hand-over to both FDD and TDD UTRA cells; The hand-over signalling must not affect existing mobiles;…
Discussion: In the last bullet, "Service dependent cell choice in connected mode", it was explained that only connected mode is mentioned (and not idle mode) because in idle mode, the service the user wants is not known by the network. This point is developed in the cell selection session. Also concerning this last bullet, it was finally commonly agreed that the cell selection choice should be based on the bearer service, and not on the teleservice, otherwise the AN/CN split might be impacted.
WHO-99029, source Motorola: Handover for real time service from GPRS to UMTS
This contribution proposes that the capability to carry real time services on GPRS and the network-controlled GPRS handover mechanisms should be taken into account when designing the Release 99 UMTS / GPRS inter-system handover routines.
Discussion: The time plan was questioned, as well as the status of the WI which is referred to in the contribution. It was proposed to have it for a further release of UMTS.
WHO-99026, source Vodafone: Some topics for HO and Idle mode specs for R99
A list of topics to be studied related to UMTS and GSM HOs is proposed here.
Discussion: About ciphering, it was remarked that the termination point might change after having performed an inter-system HO. This should be studied too.
On point 2, it is explained that UMTS to GSM Call Reestablishment can be seen as a fallback procedure in case of the UMTS to GSM handover does not work properly.
On point 6, more work is requested. After the sentence "however, the case of GSM X to UMTS Y when it […] complex", it was proposed to add "Inclusion of this feature for R99 will depend on the contributions presented to solve this issue."
Conclusion: This list is widely re-used in the conclusion of this session, where the items for further discussions are stressed out.
WHO-99005, source Ericsson: Inter System Handover Issues
This paper also proposes a list of issues to be studied for inter-system handovers, like Cell identification and RNC addressing, Definition of GSM/GPRS cells within UTRAN (for UMTS to GSM HO) or Definition of UTRAN RNC and cells within GSM (for GSM to UMTS HO).
Discussion: Section 2.1, "Cell identification and RNC addressing", stresses that there is a need to uniquely identify the cell in UMTS.
On section 2.2, "Service dependent handover evaluation", it is again clarified that it should be "radio bearer" instead of "service".
Concerning 2.3 Transfer of system specific UE capabilities between systems, the WA taken by N1 on use of the classmark was remembered (the classmark will be split in two: one part for RAN and one for CN).
It was stressed that some new requirements are introduced to SMG2 to perform the GSM to UMTS HO, and that this mechanism should work for TDD and FDD.
Conclusion: The new requirements to SMG2 should be stressed to this group.
WHO-99011, source Siemens: Prerequisites for performing intersystem HO of CS services
This paper concludes that GSM equipment has to be upgraded for inter-system handover purposes. At least, Um interface (RR part) has to be enhanced with UMTS specific transparent fields parameters, implying modifications within MS and BSS. It proposes to add requirement lists into 25.931.
Discussion: It was stressed that the fact to use one single MSC for GSM and UMTS is not precluded, even if not shown.
It was commented that UMTS has to emulate GSM for inter-system HO. In particular, in GSM, for inter-MSC HO, some 08.08 related information is sent on the E interface, so the target MSC also has to receive this information for inter-system HO.
Conclusion: noted.
WHO-99009, source Siemens: Relaying of Iu interface information via E interface
In case of inter-3G-MSC Relocation procedures, the Iu interface information has to be relayed via the E interface. MAP handover service definitions have to be analysed and maybe enhanced.
Discussion: It was stressed that the key information for routing the messages at HO should be the RNC Id and not the Cell Id, to cope with the problem of soft handover, where several cells are 'active' simultaneously, and the concept of a "master" cell does not exist.
It was explained that ideally, the concept of cell id should not appear at the Iu interface (some 'geographical indication' should be used instead), but it was recognised that it may not be such, and the cell id may still appear.
It was proposed to have SRNC as anchor point. In such case, there will be no Routing Update, because Routing Update takes place at SRNC relocation (some inconsistencies with this respect were mentioned within 23.20).
Some opinions were expressed in favour of the "container approach" compared to the IWU approach, which was said not to be flexible. The ‘container’ idea is that when performing an inter-system HO, e.g. from GSM to UMTS, the UMTS message should be encapsulated in a GSM one, and reciprocally.
Conclusion: noted.
WHO-99012, source Nokia: Handover and cell re-selection measurement quantity for UMTS
This paper proposes a new idea, which is that Ec/Io is an appropriate measurement and reporting value for all intra-frequency HO and cell re-selection procedures. The decoding of the BCCH should not be required for making the decision to transmit a measurement report or for making a cell update decision at the MS. After the (measurement report transmission or cell update) decision has been made by the UE, it is acceptable to require the decoding of the BCCH of the new cell.
Discussion: It was suggested that it should be possible to decode the information before to perform the Location Update, as to avoid ping-pong effect.
Some key questions have to be solved before to be able to take any decision on the idea, like what are the requirements for the process?, How to handle border cases? (how to be sure not to be listening to the next country's PLMNs?) It was answered that the BSIC can be decoded, but then the interest of the solution was questioned.
Conclusion: RAN WG1 and 4 can study more in depth the proposal.
WHO-99028, source Motorola: An enhancement to the cell monitoring and measuremernt reporting procedures
This paper presents a method to improve the cell monitoring and measurement reporting procedures of UE's in RRC Connected mode. This is achieved by forcing the UE to only monitor neighbour cells which would be able to support the UE's currently active services ie. dependending on the current QoS class resource availability. It is proposed that the "Cell capability" be used in the procedures for determining which cells the UE should monitor and that "Cell capability" and "Currently Available QoS Classes" parameters be used in the procedures both for determining the list of cells on which the UE should report measurements and for the purposes of connected mode cell reselection.
Discussion: It was explained that the proposal should apply not for a specific radio technique. Some concerns were raised on using it with FDD on the same frequency. Some other concerns were raised on expliciting the kind of bearer services supported by each cell (how to provide in a simple way the accurate QoS supported by a given cell?). Some doubts were raised that the concept itself can work.
Conclusion: noted
WHO-99010, source Siemens: Coordination of Relocation- and NAS procedures
This contribution proposes to Reject NAS procedure requests during ongoing Relocation due to processing complexity within UMSC.
Discussion: It was commented that such feature exists in GSM, at least for the circuit switched part. The problem was said to be on the SGSN side. So more studies are requested to identify from where the problem comes.
Conclusion: RAN 2, RAN3 and CN groups have to study this issue more in depth.
WHO-99008, source Siemens: Target Id within Relocation Required Message
This paper states that two possibilities exist for identifying the target radio environment in case of Relocation: apply a ‘target cell_id (list)’, like in GSM, or apply an identifier, representing the target RNC address (the target cell information is then passed within a transparent field from SRNC to target RNC).
Discussion: their should not be a ‘target_id(list)’: either one ‘targ_id’ or the ‘RNC_id’ is provided, but not a list.
The 2G to 3G HO should be decoupled from the 3G to 2G HO.
Conclusion: noted.
WHO-99024, source Telecom Modus: Network Selectivity for UMTS-GSM Handover
This paper proposes some pieces of solution enabling a dual-mode terminal to handover from a UMTS network to a GSM network in the case different GSM networks are available. The solution is based on keeping track of a preferred candidate for the handover.
Discussion: A part of the discussion on this paper contributed to the conclusions reported hereafter. Concerning the network selection procedure, it was explained that some very similar concerns had to be solve for SoLSA: SIM centric or network centric solution. It was concluded that the network centric solution was much more flexible, e.g. the instantaneous network load can be taken into account easily. It was remembered that one of the main problems with SoLSA was legacy, i.e. support of pre-SoLSA terminals.
Conclusion: These comments and the conclusions can be used to provide a revised version.
WHO-99023, source RAN WG2: Extract from 25.303 (UE Functions and Interlayer Procedures in Connected Mode): Description of UE RRC States and State Transitions
The purpose of this document is to describe UE states and inter layer procedures. Only the first part is presented in this extract. Section 5.6 concerns inter-system handover (with simultaneous IP and PSTN/ISDN domain services) UTRAN to BSS and reciprocally.
Discussion: it should be clarified in which MS states identified in the document the mobile is actually transmitting data.
It is explained that the 'complicated route' for GPRS cell reselection in figure 2 reflects the actual GPRS cell reselection mechanisms, even if it does not seam to be an efficient solution. This figure was lengthly explained.
Conclusion: The delegates are encouraged to study more in depth the document and send their comments to RAN2.
WHO-99030, source RAN WG2: TR 25.922 "RRM strategies"
This document describes the General Description of Radio Resource Management, the Idle Mode Tasks, the RRC Connection Mobility, …
Discussion: In section 6.1.1.6, on slotted mode, it was requested for the document to provide some additional indications on the available time to scan for GSM channels.
Conclusion: noted, further comments are invited.
WHO-99031, source editor (RAN WG4): TS 25.103 "RF parameters in support of RRM"
This TS is in version 0.1.0. It will describe for each mode (FDD and TDD) the tasks performed in idle mode, the ‘admission control’ process, the ‘radio access bearer control’ process, and other procedures of the Access Stratum.
Conclusion: noted (this document is presented for information).
In this section, the following assumptions are made:
With these clarifications, the different scenario cases were classified as follow:
For all these cases and sub-cases, it was stressed that the one-to-one relationship was much easier to handle than the one-to-multiple cases. The following problems are avoided: there is no need to define some mechanisms to exchange information between networks and the number of channels the MS has to monitor might be much lower, so the technical complexity of the MS could be reduced.
It was then suggested (but not firmly concluded) to limit to the one-to-one relationship for UMTS phase 1.
However, this does not mean that all the customers moving e.g. from one country to another have to be handovered on the same network, as illustrated by the following example. Let’s have A and B operating in country 1 and C operating in a border country 2, and let’s assume that A and C have an agreement so that all the C customers preferably use A and not B when they are in country 1. The B customers who were previously roaming on C and coming back to country 1 still need to be redirected to their HPLMN and not to A. This might imply that the RAN needs to have some level of knowledge of the subscriber (like for SoLSA, but this might imply important changes on "classical" GSM, where the BSS has no knowledge of the subscriber identity).
It was discussed whether it should be allowed to HO towards a network where no roaming agreement is established.
The decoupling of roaming agreement from HO was illustrated by the following example: let's have a user N from operator A roaming on a PLMN B (A has roaming agreement with B). If B has some agreements with C for HO (e.g. because B and C have complementary coverage in a given country, so all the B users are transferred to C at the limit between B and C coverages and reciprocally), N can be on C's network after a HO, even if there is no roaming agreement between A and C.
Here again, it was proposed, but not firmly concluded, that such a case should be possible. It was argued in favour of such feature that the fact that N uses the services provided by C results from an internal agreement between B and C and is totally hidden to A.
The following topics (derived from document WHO-99026, where more information can be found) have been identified as requiring some urgent work:
The document 22.129, specifying the requirements for handover, needs some further improvements to be made according to the discussions and conclusions of this workshop. Among them, the group particularly stressed that the intra or inter PLMN HOs provide different constraints. The requirements applying on these different types of HOs should be clearly de-coupled.
5. PLMN Selection, Mode Selection and Cell Selection
Presentation of the Tdocs and related discussionsWHO-99013, source Nokia: Mixing of cell selection procedures for GSM-UMTS dual system MS
A comparison of different cell selection methods is performed, and the paper concludes in favor of a "no mixing" approach: with this approach, the cell selection procedure defined for each single system is kept as independent as possible to the other system procedure.
Discussion: The "BA range" functionality should be considered when deciding on the approach.
It was stressed that 22.01 states that a downloadable mechanism should be defined to select the radio access. It was commented that, as for HO procedures, the download of data and applications to the SIM is a nice mechanism as long as the MS is in the HPLMN, but may cause troubles when roaming.
The proposal seems to prioritise cell selection compared to PLMN selection, which was said to be unacceptable: the PLMN selection should always take place first, but solutions for speeding up this search are welcomed. Some solutions were proposed to this aim: for a dual mode network GSM/UMTS, on the GSM BA list, state that such network also provides UMTS services, specifying the bands, and reciprocally (UMTS saying that GSM is also supported). Another solution (not incompatible with the first one) is to dynamically update the preferred list of PLMNs according to the MCC (e.g. the MS stops searching for France Telecom's network if the MCC indicates China). This last solution met support at the meeting.
The problem with present GSM preferred list was stressed out: if a user is roming in a country where network B and C are available, and if only B is in the preferred PLMN list, then as soon as there is a lack of coverage of B, the user goes to C and never go back to B as long as there is a coverage by C. To introduce a periodic search for B was proposed, as a periodic search for the HPLMN is defined in GSM, but no firm decision was taken.
It was stressed that it should not be possible to change the registered PLMN during the call (at least for CS service), which does not preclude to HO on a different PLMN, as stated during the HO session.
The information to broadcast was also discussed: it was first clarified that a solution where all the information related to all type of network (GSM, UMTS, satellite,..) are broadcast on a single common channel is no more studied. It was said that having a BCCH common to all the operators is no more judged as realistic.
Conclusion: No conclusion was taken on mixing/non mixing procedures. All the approaches should be studied. The document 16 is the TS on idle mode, and some inputs to it can be derived from the proposal, in particular on how to decrease the search time. This document triggered a lot of discussions and helped in the process of reaching some conclusions, in particular on PLMN/cell selection and on documentation issues.
WHO-99006, source Ericsson: Idle mode issues
This paper lists some issues related to idle mode, and proposes some assumptions on some of these issues. The issues/assumtpions are:
The non-access stratum part of UMTS idle mode is specified outside TSG-RAN, e.g. by TSG-CN. As a starting point, the corresponding processes defined for GSM can be taken, and the idle mode of GSM is not included in the UMTS specifications.
The cell selection and reselection process includes the choice of radio access system (like UMTS and GSM/GPRS), radio access mode (like FDD/TDD) and cell.
It is assumed that 3GPP specifications will describe how other radio access systems shall be treated by a UE supporting multiple radio access systems. However, the transition back to UTRA is specified in the standard of the particular radio access system.
Discussion: Splitting the specification of idle mode (CN/AN) into two TSGs will introduce lot of avoidable interactions. The example of problems like SoLSA in GSM was mentioned, making more complex such a separation.
It was explained that two types of solutions are possible, not conflicting with each other: a same PLMN code (MCC+MNC) can apply to different modes (i.e. GSM and UMTS), or different (MCC+MNC) codes can be used: this does not prohibit the networks to be owned by the same operator.
It was proposed that a multimode network has to indicate such a capability in each of its mode, so, if a network in a given mode does not indicate that it is multimode, it means that it offers one single mode. A new document for multimode should be developed in this line. Its impacts on 22.01 (service requirements) should be pointed out.
Conclusion: noted. The discussions raised by this paper helped in reaching the conclusions in 5.2.2.
WHO-99014, source Nokia: Need of different radio access network selection modes (RANSM)
The contribution asks the following questions related to RAN Selection Mode: is the user allowed or prohibited to affect to RAN selection procedures?; is the operator allowed to affect to RAN selection procedure of the terminal? If so, then should it be controlled by the home PLMN operator, by the visited PLMN operator or by both of them?, and, based on the answers to questions 1 and 2, should different radio access network selection modes (RANSMs) be defined as discussed in this contribution?
Discussion: 22.101 section 18 provides the answers, without however mentioning multimode issues: the home network, the serving network and the user (including the application) may be involved in the procedure. It was however mentioned during this meeting that the user should not be involved in the process of selecting the RAN: it was stressed that there is some clear interest for the user to select the PLMN, but his interest in selecting the actual cell was unclear. It was stressed that the user can select its preferred mode, but it should be up to the serving network to actually decides to direct the user to the appropriate cell.
Conclusion: noted, see the conclusions.
WHO-99016, source RAN WG2: TS 25.304 v1.2 "UE Procedures in Idle Mode"
This specification provides the procedures performed by the UE in idle mode. Its key parts are Functional division between AS and NAS in Idle mode, PLMN and cell selection, location registration, broadcasted information,… The Figure 1 shows the Overall Idle Mode process.
Discussion: In section 4.1, anonymous access or cell broadcast are examples of services which do not need registration.
The role of PLMN selection, of cell selection (i.e. best suitable for initial access, not to provide the actual service) should be clarified.
The impacts of the load of the network should be clarified.
In UMTS, a mechanism should avoid that cell failure immediately triggers PLMN reselection, as it is the case in GSM.
Conclusion: noted.
WHO-99017, source RAN WG2: Questions on PLMN, radio access system and radio access mode selection and reselection
This document asks a series of questions to the workshop on capabilities of the MS in idle mode and other procedures related to PLMN and cell selection. It proposes the definition of Radio Access System (value: GSM or UMTS) and of Radio Access Mode (value: FDD or TDD). The individual questions are answered in the annex.
Conclusion: see the corresponding annex of these minutes.
WHO-99035, source Lucent: Cover sheet for WHO-99027
see WHO-99027.
WHO-99027, source Lucent: A flexible method for defining RF channels for UMTS
A new method is proposed to speed up the PLMN search procedure: a "default" list of frequencies to be used by a mobile for searching for a network, and for handover messages, is programmed into the terminal on manufacture. This list can be further modified: the corresponding data could be either stored in the SIM, or downloaded over the radio interface from the home network, or both. A temporary list, e.g. broadcast by a network, would take precedence over the other lists until the terminal attaches to a different network.
It is explained that the proposal can be extended to include handover to other systems, including (but not restricted to) GSM.
Discussion: The extra complexity introduced by the proposal might delay the standardisation process. The balance compared to its advantages was challenged.
There was a previous version presented at another meeting. Compared to the previous version, FDD/TDD is now supported, but the comment that the solution shall allow to take into account future extensions of frequencies has still to be considered.
It was remembered, for potential further improvements of the proposal, that the 1900-band is incompatible with the ARFCN numbering.
Conclusion: The proposal should be discussed within RAN2. The mechanism should be extendable to new frequencies. It may be possible to download data to the SIM card, but not to use only the SIM card data as first initiated.
WHO-99033, source Nokia/S2: UMTS node addressing and identification over Iu-interface
This contribution discusses the methods to identify UMTS nodes, especially from Iu interface point of view. The identification for Relocation procedure and the usage of cell-ID in CN is discussed. It is proposed to broadcast the following information: Cell-ID (Unique within RNC); RNC-ID (Unique within PLMN); LAC (Location Area Code of the cell, unique in PLMN), RAC (Routing Area Identifier Code of the cell, unique in PLMN); MNC (Mobile Network Code); MCC (Mobile Country Code).
Discussion: It was commented that the only constraint to have a unique cell id within the network is to have a long enough field. It was answered that splitting the information the way proposed in the paper might provide better ability to evolve.
Conclusion: Noted. To be discussed within the RAN and the CN groups.
There was a common agreement that the PLMN selection should be performed prior to the mode selection and the cell selection, i.e. the PLMN is chosen first and, once the PLMN is selected, the choice of the mode has to be decided among the ones offered by the chosen PLMN. This second step is under the control of the selected operator.
The meeting agreed that PLMN selection can be decided by the user/application, but once the PLMN selected, the user only provides wishes of the requested services and has no capability to actually choose the serving cell nor the RAN.
No specific conclusion for UMTS was reached: it was mentioned that the same mechanisms as for GSM can apply (automatic or manual selection).
Some improvements compared to GSM were proposed, like deducing the potentially available PLMNs from the MCC, or introducing a periodic search for a PLMN in the ‘preferred PLMN list’. Some mechanisms for updating the ‘preferred PLMN list’ were discussed. GSM 02.11 is still providing the basic procedure for PLMN selection, but other methods should be allowed by downloading procedures to the MS.
There was a common agreement that the serving operator might decide the mode (UMTS, GSM,…) supporting a multi-mode MS in idle mode.
For dual mode terminals, the cell selection is proposed to be made in two steps: the mode selection (UMTS or GSM), and the actual cell selection (which cell in a given mode), which can be made just like for a single mode terminal once the mode selection has been performed.
For mode selection, an approach based on a threshold was proposed: if the signal level received from the other system is above this threshold (eventually during a certain time), then the MS should commute to the corresponding mode.
It was particularly stressed that the cell selection procedure applies to select the most suitable cell for initial access, not to provide the actual service: if, once the initial access is performed, the user indicates he wants to use a service not supported by the mode used during idle mode, then the actual call establishment can be made with the other mode or an inter-system HO can occur. A possible exception might be for SoLSA.
A set of tools should be developed by TSG RAN to help the operator in deciding on which mode (GSM or UMTS) and cell the MS has to camp, so as to minimise the occurrences for a MS to change of mode once the initial access is performed. One basic principle should be that a network shall indicate all the modes it can support in each of its individual mode.
It was stressed that the comparison between GSM and UMTS cells is the only new task not fitting within the classical approach, but GSM cell selection specification has to be used as unchanged as possible when in GSM mode. Some further discussions should take place within SMG2 and RAN groups and between them.
Now two documents exist on idle mode: CN groups have reused 03.22 for UMTS, and RAN groups (RAN2 in particular) have produced TS25.304 "UE Procedures in Idle Mode".
The resulting potential inconsistencies have to be solved as a priority task. It was stressed that 03.22 is mixing radio related with non radio related matters and has to be "cleaned up" for UMTS (the same on 03.09), and could be processed as 04.08, i.e. split it into RR/non RR parts.
Single mode UMTS, single mode GSM and bi-mode have to be studied and documented. This last specification can be a new stand-alone document, under joint responsibility of SMG2/RAN. It should be written as to become easily a multi-mode document, i.e. expandable to modes other than GSM and UMTS. The TS 25.304 in document WHO-99016 can deal with single mode UMTS and refer to this new document for multi-mode.
The Tdoc WHO-99007 was withdrawn.
The chairman thanked the host, the secretary, and the delegates for their positive attitude and willingness to progress efficiently and quickly.
Annex 1: answer to the questions raised by RAN2 in Tdoc WHO-99017
[The plain text is the incoming LS, the answers are presented in italic.]
The TSG-RAN WG2 has studied idle mode processes and identified open issues in the PLMN, radio access system and radio access mode selection and reselection. TSG-RAN WG2 has gathered the following lists of questions to have clarification and guidance for resolving the open issues.
Radio Access System: Indicates the type of interface to the radio access network, UMTS or GSM/GPRS
Radio Access Mode: If the radio access system is UMTS, whether a given cell supports FDD or TDD mode of layer 1 operation
It is left to R2 and S1 to decide on terminology (in this group, ‘mode’ has been sometimes used to refer to ‘system’ and reciprocally). However, it should be noted that:
For GSM, the workshop recommends to have one single RAM (it should be avoided to introduce a ‘GPRS RAM’).
The MS shall only listen to and camp on one cell at a time.
A single broadcast resource shall be used per system and mode. Multiplexing information coming from different systems and modes is judged too complex.
No general answer can be provided to this question: ME manufacturers have to predict as much as possible the future standardised improvements so that their specific improvements do not compromise future releases.
N1.
PLMN Selection and Reselection
No, PLMN selection is always performed prior to any type of other selection.
PLMN selection is based upon Network/USIM information (although some relationships on signal strength are unavoidable).
Yes, with some cautions on the power consumption (e.g. some tricks with the MCC are possible: the MS scan only the PLMNs which are known to be available in the current country, even though if some problems can appear at the borders).
Radio Access System Selection and Reselection
No firm answer can be provided without further studies. The PLMN selection always has priority and subsequent selection is up to the operator’s decision: some tools might be developed to help his choice, based on the capabilities of the mobile: the decision on the cell selection can be based on RAS, RAM and frequency bands supported by the MS.
This is not a part of the cell selection mechanism. The cell selection mechanism only provides the cell to camp on in idle mode, potentially different from the cell providing the actual service: before the call is initiated, the network does not know which service the MS is willing to use.
This choice is up to operator’s decision (see 1).
Radio Access Mode Selection and Reselection
For radio access mode selection and reselection, there are similar issues as for the radio access system selection and reselection.
See the answers in previous sections.
TDoc # |
Source |
Title |
WHO-99001 |
Chairman |
Agenda |
WHO-99002 |
MCC |
TDoc list |
WHO-99003 |
SA WG2 |
LS on Area concept |
WHO-99004 |
SA WG2 |
LS from TSG SA WG2 to RAN3 on Manifestations of Handover and SRNS Relocation and answer on the liaison on Node identification over the Iu |
WHO-99005 |
Ericsson |
Inter System Handover Issues |
WHO-99006 |
Ericsson |
Idle mode issues |
WHO-99007 |
Siemens |
Relocation Detect Message: OPTIONAL vs. MANDATORY |
WHO-99008 |
Siemens |
Target Id within Relocation Required Message |
WHO-99009 |
Siemens |
Relaying of IU interface information via E interface |
WHO-99010 |
Siemens |
Coordination of Relocation- and NAS procedures |
WHO-99011 |
Siemens |
Prerequisites for performing intersystem HO of cs services |
WHO-99012 |
Nokia |
Handover and cell re-selection measurement quantity for UMTS |
WHO-99013 |
Nokia |
Mixing of cell selection procedures for GSM-UMTS dualsystem MS |
WHO-99014 |
Nokia |
Need of different radio access network selection modes (RANSM) |
WHO-99015 |
Editor of 22.129 |
Definition of Handover |
WHO-99016 |
RAN WG2 |
TS25.304 v1.2., "UE Procedures in Idle Mode" |
WHO-99017 |
RAN WG2 |
Questions on PLMN, radio access system and radio access mode selection and reselection |
WHO-99018 |
Siemens |
GSM to UMTS Hand-over - Radio Interface Requirements |
WHO-99019 |
SA WG1 |
22.100 version 3.2.0 "UMTS phase 1" |
WHO-99020 |
SA WG1 |
22.101 version 3.5.0 "UMTS Service principles" |
WHO-99021 |
SA WG1 |
22.129 version 3.0.0 "Handover Requirements between UMTS and GSM or other" |
WHO-99022 |
RAN WG3 |
25.832 version 2.1.1 "Manifestations of handover and SRNS relocation" |
WHO-99023 |
RAN WG2 |
Extract from 25.303 (UE Functions and Interlayer Procedures in Connected Mode): Description of UE RRC States and State Transitions |
WHO-99024 |
Telecom Modus |
Network Selectivity for UMTS-GSM Handover |
WHO-99025 |
Rapporteur |
Service requirements for Handover (UMTS 22.129) |
WHO-99026 |
Vodafone |
Some topics for HO and Idle mode specs for R99 |
WHO-99027 |
Lucent |
A flexible method for defining RF channels for UMTS |
WHO-99028 |
Motorola |
An enhancement to the cell monitoring and measuremernt reporting procedures |
WHO-99029 |
Motorola |
Handover for real time service from GPRS to UMTS |
WHO-99030 |
RAN WG2 |
TR 25.922, RRM strategies |
WHO-99031 |
Editor |
TS 25.103, (RAN WG4) RF parameters in support of RRM |
WHO-99032 |
RAN WG3 |
LS to S2 answered in WHO-004 on Node Identification over Iu |
WHO-99033 |
Nokia/SA WG2 |
UMTS NODE ADDRESSING AND IDENTIFICATION OVER Iu-INTERFACE |
WHO-99034 |
SA WG2 and RAN WG3 |
exchanges of LSs between R3 and S2 on CN architectures to be supported in UMTS Release 99 |
WHO-99035 |
Lucent |
Cover sheet for WHO-99027 |
Name |
Company |
|
Mr. Kalle Ahmavaara |
Nokia Japan |
kalle.ahmavaara@nokia.com |
Mr. Niels Peter Skov Andersen |
MOTOROLA A/S |
npa001@email.mot.com |
Mr. Sergio Barberis |
CSELT |
sergio.barberis@cselt.it |
Mr. David Barnes |
DTI |
dbarnes3@compuserve.com |
Mr. Stephen Barrett |
MOTOROLA Ltd |
sbarret1@ecid.cig.mot.com |
Mr. Nigel. H Berry |
Lucent Technologies N. S. UK |
nhberry@lucent.com |
Mr. Stig Brink |
BOSCH TELECOM DANMARK A/S |
stig.brink@dk.bosch.com |
Mr. Pablo Brito Cabello |
BOUYGUES Telecom |
pbrito@bouyguestelecom.fr |
Mr. Doru Calin |
MOTOROLA S.A. |
doru.calin@crm.mot.com |
Mr. David Cooper |
NEC Technologies (UK) LTD |
david.cooper@t-modus.co.uk |
Mr. Graham Crisp |
MARCONI COMMUNICATIONS |
CRISP_G@A1.BEA1.marconicomms.com |
Mr. Jean-Jacques Davidian |
DoCoMo Europe S.A. |
davidian@docomo.fr |
Mr. Remi De Montgolfier |
ALCATEL France |
remi.de-montgolfier@alcatel.fr |
Mr. Harald Dettner |
SIEMENS AG |
harald.dettner@icn.siemens.de |
Mr. Guillaume du Roscoat |
France Telecom |
guillaume.duroscoat@cnet.francetelecom.fr |
Mr. Jean Dumazy |
PHILIPS E.G.P. |
jean.dumazy@dev-lme.pcc.philips.com |
Mr. Peter Edlund |
ERICSSON L.M. |
peter.edlund@era.ericsson.se |
Mr. Lars Ekeroth |
ERICSSON L.M. |
lars.ekeroth@erv.ericsson.se |
Mr. Denis Fauconnier |
NORTEL NETWORKS (EUROPE) |
dfauconn@nortelnetworks.com |
Mr. Daniele Franceschini |
CSELT |
daniele.franceschini@cselt.it |
Mr. Gordon Gay |
NEC Technologies (UK) LTD |
gordong@icpdd.neca.nec.com.au |
Mr. Volkmar Hammer |
France Telecom |
volkmar.hammer@francetelecom.fr |
Mr. Martin Hans |
ROBERT BOSCH GmbH |
Martin.Hans@fr.bosch.de |
Mr. Jon Harris |
BT |
jon.w.harris@bt.com |
Mr. Thomas HOWARD |
MOTOROLA |
Howard_thomas@ecid.cig.mot.com |
Mr. Benn Howard |
MOTOROLA Ltd |
bennh@ecid.cig.mot.com |
Mr. Andrew Howell |
MOTOROLA Ltd |
andrew.howell@motorola.com |
Mr. Tony Hulkkonen |
NOKIA Corporation |
tony.hulkkonen@nokia.com |
Mr. Peter Hupperich |
ALCATEL SEL AG |
P.Hupperich@alcatel.de |
Mr. Kaisu Iisakkila |
NOKIA Corporation |
kaisu.iisakkila@ntc.nokia.com |
Mr. Ken Isaacs |
SIEMENS AG |
kenneth.isaacs@roke.co.uk |
Mr. Teuvo Jarvela |
NOKIA UK Ltd |
teuvo.jarvela@nmp.nokia.com |
Mr. Bent Jepsen |
BOSCH TELECOM DANMARK A/S |
bent.jepsen@dk.bosch.com |
Mr. Stefan Kornprobst |
SONY INTERNATIONAL (EUROPE) |
kornprobst@fb.sony.de |
Mr. Marko Koskela |
NOKIA Corporation |
marko.koskela@nmp.nokia.com |
Mr. Matthias Krampf |
Lucent Technologies BCS & ME |
mkrampf@lucent.com |
Mr. Joern Krause |
SIEMENS AG |
joern.krause@icn.siemens.de |
Mr. Peter Krischan |
MANNESMANN Mobilfunk GmbH |
peter.krischan@d2privat.de |
Mr. Hyunseok Lee |
Samsung Electronics Co., Ltd |
leehs@telecom.samsung.co.kr |
Mr. Tommi Leivonen |
NOKIA Corporation |
Tommi.Leivonen@nmp.nokia.com |
Mr. Michael Luddy |
SONY INTERNATIONAL (EUROPE) |
luddy@sony.de |
Mr. Edgar Lycksell |
TELIA AB |
edgar.A.lycksell@telia.se |
Mr. David Lynes |
NEC Technologies (UK) LTD |
davidl@icpdd.neca.nec.com.au |
Mr. Marco Mastroforti |
CSELT |
marco.mastroforti@cselt.it |
Mr. Behzad Mohebbi |
FUJITSU Europe Telecom R & D C |
b.mohebbi@fujitsu.co.uk |
Mr. Walter Müller |
ERICSSON L.M. |
walter.muller@era.ericsson.se |
Mr. Temi Ogunbambi |
DOLPHIN TELECOMMUNICATIONS LTD |
temiogunbambi@dolphin-telecom.co.uk |
Mr. Johnson Oyama |
Nippon Ericsson |
johnson.oyama@nrj.ericsson.se |
Mr. Sudeep Palat |
Lucent Technologies |
|
Mr. Holger Pampel |
Lucent Technologies |
hpampel@lucent.com |
Mr. Gilles Pasteau |
ALCATEL France |
gilles.pasteau@alcatel.fr |
Mr. Bengt Persson |
Ericsson Radio System AB |
bengt.y.persson@era.ericsson.se |
Mr. Chris Pudney |
VODAFONE Group Plc |
chris.pudney@vf.vodafone.co.uk |
Mr. Michael Roberts |
Lucent Technologies N. S. UK |
mr85@lucent.com |
Mr. Adel Rouz |
FUJITSU Europe Telecom R & D C |
a.rouz@fujitsu.co.uk |
Mr. Dan Rylander |
ERICSSON L.M. |
dan.rylander@ecs.ericsson.se |
Mr. Oscar Salonaho |
NOKIA Corporation |
oscar.salonaho@nokia.com |
Mr. Ari-Pekka Salovaara |
SONERA Limited |
ari-pekka.salovaara@sonera.fi |
Mr. Raj Sanmugan |
ERICSSON L.M. |
raj.sanmugam@era.ericsson.se |
Mrs. Liisa Silvennoinen |
TELIA AB |
liisa.a.silvennoinen@telis.se |
Mr. Alain Sultan |
SOURCE COM |
alain.sultan@etsi.fr |
Mr. Motohiro Tanno |
NTT DoCoMo |
tanno@wsp.yrp.nttdocomo.co.jp |
Mr. Stephen Terry |
INTERDIGITAL COMMUNICATIONS |
steve.terry@interdigital.com |
Mr. Laurent Thiebaut |
ALCATEL CIT |
laurent.thiebaut@alcatel.fr |
Mr. David Thomas |
SIEMENS AG |
david.thomas@roke.co.uk |
Mr. Juha Timonen |
NOKIA Corporation |
juha.t.timonen@nokia.com |
Mr. Pierre Truong |
Ericsson Inc. |
pierre.truong@ericsson.com |
Mr. Jonas Twingler |
NorthStream AB |
jonas.twingler@northstream.se |
Mr. Han van Bussel |
Deutsche Telekom MobilNet |
han.van.bussel@t-mobil.de |
Mr. Alexander Vesely |
SIEMENS AG |
alexander.vesely@siemens.at |
Mr. Pontus Wallentin |
ERICSSON L.M. |
pontus.wallentin@ericsson.com |
Ms. Emmanuelle Wurffel |
ETSI Secretariat |
emmanuelle.wurffel@etsi.fr |
Mr. Masahiko Yahagi |
NEC Corporation |
yamasa@mvc.biglobe.ne.jp |
Mr. Gordon Young |
Lucent Technologies N. S. UK |
gyoung1@lucent.com |