This Technical Report has been produced by the 3rd Generation Partnership Project (3GPP).
The present document shall analyse the current network selection mechanism and will highlight its limitations based on known operational problems. It will also consider issues brought about by the advent of new access systems.
Potential changes shall be described to the selection mechanism to provide a better user and network operator experience.
The present document is applicable to both GERAN and UTRAN.
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
: "Non-Access-Stratum (NAS) functions related to Mobile Station"
: "Requirements on 3GPP system to Wireless Local Area Network (WLAN) interworking"
: "3GPP System to Wireless Local Area Network (WLAN) interworking; User Equipment (UE) to network protocols"
The Stage 1 Requirements for Network Selection are found in TS 22.011
. This describes the behaviour that is expected from a UE in order to select a PLMN from which to gain service.
Two modes of operation are supported: Automatic and Manual. At power on, and the UE is required to revert to the last mode used at power off. At any time, the user may request the UE to initiate reselection and registration onto an alternative available PLMN.
As defined in Release 6 the Automatic Mode will attempt to connect the UE to a PLMN using the following order; the RPLMN (or its EPLMNs) followed by the HPLMN followed by PLMNs indicated on the User and then the Operator controlled Preferred Lists, followed by those PLMNs with sufficient signal quality in random order, and finally those in descending order of signal strength.
The Manual Mode presents the user with a list of the networks that are available and the user then selects which network the UE should connect to in order to gain service.
In the case of the Automatic mode periodic network selection attempts may be enabled by the HPLMN to search for and connect to higher priority PLMNs if they have become available. In Release 7 the Equivalent HPLMN feature has been introduced which allows multiple PLMNs to be treated as the HPLMN and hence share the highest priority during network selection attempts.
The detailed Network Selection Procedure is contained in TS 23.122
The Stage 1 Requirements for Network Selection when access is available through I-WLAN are detailed in TS 22.234
. This is provides for both an automatic and a manual mode similar to that specified in TS 22.011
. This introduces a number of additional priority lists, which enable Network Operators to give different preferences to PLMNs that are available via I-WLAN and also to indicate preferred WLAN ID's in the case that it is possible to connect to the same PLMN via more than one WLAN AP.
The detailed Network Selection Procedure for I-WLAN is contained in TS 24.234
. The Network Selection Procedures defined for I-WLANs are decoupled from the network selection procedures for cellular protocols specified in TS 23.122
, though they share some similarities.
This clause describes the principles that are applicable in network selection up to Rel-6 and that are not expected to be challenged by the enhancements introduced to the network selection procedures. Furthermore the expectations of the three main stakeholders in the network selection procedures (customer, home operator, visited network operator) are also described.
The following is a set of principles that should be preserved when devising a new procedure to perform the registration to the serving mobile network. The assumption made in this paragraph is that the term "network"
has to be interpreted as the core network of the mobile operator with whom the subscriber has direct relation (i.e. the home PLMN) or indirect via the home PLMN (e.g. a Visited PLMN).
Principle 1: the subscriber selects and registers with a public land mobile network regardless of the radio access technology employed to attain connectivity. This is then regarded as the registered PLMN (RPLMN).
Principle 2: the home PLMN operator and the user can prioritise by means of lists the available PLMNs/Access technologies combinations for roaming. If only networks for which no priority is defined are available, then those networks with sufficient radio quality are chosen at random, then the rest are chosen in order of decreasing signal strength. Furthermore the home PLMN operator has control over the periodicity the UE attempt to register on a PLMN with higher priority than the current registered one.
Principle 3: the HPLMN and any other PLMN declared as equivalent to the HPLMN (EHPLMN) of the subscriber has by default the highest priority, however the UE shall first attempt to attain service from the last PLMN it successfully registered on (last registered PLMN or the equivalent PLMNs).
Principle 4: the PLMN has priority over the particular radio access technology that the UE may prefer to use. When the PLMN supports multiple access technologies, the UE shall use in priority preferred RAT on the USIM preferred list to attain connectivity on that PLMN.
Enhancements to the network selection principles will not negatively affect the functionality of existing devices.
Enhancements to the Network Selection procedure in the core network shall be done such that backwards compatibility with existing UEs is maintained.
The network selection principles should allow for at least the following combination of entities:
HPLMN and USIM are Rel-7: HPLMN/EHPLMN (Rel-7) - VPLMN (pre-Rel-7) - ME (pre-Rel-7) - USIM (Rel-7)
HPLMN and ME are Rel-7: HPLMN/EHPLMN (Rel-7) - VPLMN (pre-Rel-7) - ME(Rel-7) - (U)SIM (pre-Rel-7)
VPLMN is Pre-Rel-7: HPLMN/EHPLMN (Rel-7) - VPLMN (pre-Rel-7) - ME (Rel-7) - USIM (Rel-7)
All the entities are Rel-7: HPLMN/EHPLMN (Rel-7) - VPLMN (Rel-7) - ME(Rel-7) - USIM (Rel-7)
Following switch-on where there is no last registered PLMN, the user should be registered on non-forbidden PLMN as fast as possible (typically within 20 seconds). This period includes the execution of any 3GPP defined functionality (e.g. after any PIN verification) that is performed by the mobile device but excludes any additional functionality (e.g. operating system device initialisation).
Following switch-on if the last registered PLMN is available, and no higher priority PLMN is available (e.g. HPLMN) the user should be registered on that PLMN (typically within 5 seconds). This period includes the execution of any 3GPP defined functionality as described above.
Following switch-on if the last registered PLMN is available, and a higher priority PLMN is available (e.g. HPLMN) the user should be registered on the Highest priority PLMN available (typically within 20 seconds). This period includes the execution of any 3GPP defined functionality as described above.
If not limited by subscriptions and other commercial framework and technical feasible, roaming users should always be able to access all their services and their services shall always work correctly as if they were on the home network.
Users shall be able to choose the PLMN they wish to receive service from.
The home operator's users' devices should select the home operator's preferred network and access type while roaming.
The home operator should be able to set which preferred networks are in the customer's device. The home operator should be able to set the mix of networks and access types that can be used by each roaming user for each visited network (i.e. apply per user per country). This should include which networks are preferred in selected countries in priority order.
User preferences or manual PLMN selection may override operator preferences.
The HPLMN can direct the user to a VPLMN that is capable of providing the best possible service to match the "at home experience"
. However, the VPLMN needs to have over-riding control over the use of its own capabilities.
It should be possible for the visited operator to direct traffic from roamers onto the appropriate access technology to manage network capacity and loading (e.g. to use 2G for voice and 3G for high speed data services). The ability to change the access in real-time for roamers according to their usage should be possible. The visited operator should be able to choose the most appropriate access technology in order to meet the service requirements of the user subject to network conditions and availability. This should cover data rates also, for example, the visited network should be able to allocate 128kbps even though the user may usually use 384kbps. The visited operator should be able to allocate access technology and data rates on the basis of the IMSI of the inbound roamer.
In terms of Network Selection Procedures, the USIM contains several sets of data that are used either for automatic or manual selection:
User controlled PLMN selector with Access Technology
Operator controlled PLMN selector with Access Technology
Higher Priority PLMN search period
HPLMN selector with Access Technology
And for I-WLAN:
User controlled PLMN selector for WLAN Access
Operator controlled PLMN selector for WLAN Access
User controlled WLAN Specific Identifier List
Operator controlled WLAN Specific Identifier List
No dynamic mechanism exists for the HPLMN to request that a UE selects a different VPLMN whilst roaming. Currently this happens through the use of the background scan when the UE is on a non-preferred network. This mechanism is not considered dynamic since updating the preference lists in the UE and taking the new lists into use is not efficient enough at the moment.
Means should be provided that allow the HPLMN to dynamically direct the UE to select a different VPLMN whenever it is already registered on a VPLMN. National roaming situations must be taken into account in this case.
The timing of when the new network is selected should happen at a point where the user is not inconvenienced.
The HPLMN request to select a different VPLMN should not over-ride a manual network selection made by the user, or a selection that is done according to user preferences.
Currently the only standardised automatic network selection mechanism by which the HPLMN can control which VPLMN is selected is through the Operator preferred list. The intended behaviour is that one network in the visited country takes precedence over all the others, and in the case where a UE has selected an alternate network, the background scan should cause the UE to re-select to the preferred network.
As a consequence the HPLMN has a choice to direct "all"
of its roaming users to one VPLMN, or alternatively to distribute the users randomly between all of the VPLMNs in the visited country (by not stating a preferred network for that country).
It is currently not possible to distribute traffic between, say, 2 or 3 of the networks in the visited country.
Manual selection is a useful tool in cases where the selected PLMN is not providing adequate quality. However, in other circumstances it prevents the mobile operator from providing the user with the best possible service.
One key limitation of manual network selection is that the user is presented only with the network name and is not given any other information on which to base an informed decision on which network to select. As an example, the user could be informed of the PLMNs that are recommended by its HPLMN to give an "at home"
experience .(e.g. availability of CAMEL, GPRS, 3G etc).
Further examples of such information could include; the ability for the HPLMN to indicate which services (e.g. voice and/or data) a user will be able to gain from each network and the ability for the HPLMN to indicate if 3G Roaming is available. Any such mechanism should be extensible so as new features and commercial arrangements are introduced the HPLMN will be able to inform the user of their availability.
Such information on the network capabilities available for presentation to the user needs to be defined. How it is presented to the user would be in accordance with vendor implementations. The gathering of such information shall not adversely impact the time the user has to wait before the list is presented.
Other limitations are:
The network name presented to the user cannot show PLMN name changes on legacy devices unless NITZ is implemented in the VPLMN and device. For the HPLMN, operators can program their current network name in the USIM card which will then be displayed on the device.
The HPLMN has no method of restricting the networks visible in manual selection e.g. to cater for a proposition that gives users a choice of certain networks only.
When the customer manually selects a network, some devices use manual selection from that point onwards. The problem this gives is that if the manually selected network runs out of coverage another network is not automatically selected. This can be a problem either in the foreign country or with some devices when returning to the home network.
In manual mode, a UE returning to an area served by the HPLMN (e.g. when the user returns from holiday) will look only for the RPLMN, potentially leaving the user without service. Ideally it should be possible for example for the user to set a preference for either manual or automatic network selection on power-up. At power on, if the RPLMN is not found, but the HPLMN is available then the UE should automatically register with it. -
In the case of Equivalent HPLMNs where 2 or more PLMNs can equate to a single PLMN the user is only presented with the highest priority EHPLMN name allowing them no way to choose the other network if network selection fails.
If a PLMN is inserted into the forbidden PLMN list the only way to remove that PLMN is via manual network selection and successful registration on that PLMN.
When multiple bands and multiple technologies are available the time to select a PLMN may be too long. The new procedure should address this area
This refers specifically to the case of the initial PLMN selection. Subsequent to that, the serving PLMN may change the RAT used by the UE .The visited operator should be able to allocate access technology and data rates on the basis of the identity (e.g. MCC-MNC) of the home operator of the inbound roamer.
specifies that preferred PLMNs can be prioritised with their preferred RAT on the USIM preferred list. Therefore, when 2 different PLMNs are detected by the UE and they are both in the preferred list, the UE should select the highest priority one. If two RATs of the same PLMN are detected by the UE but the preferred list specifies only one RAT for this PLMN, the UE should select the RAT that is in the preferred list.
Where a PLMN entry on the preferred list has multiple RATs specified or if there is no RAT specified, then the end user experience is not known because how the UE uses this information is not standardised and so it is not predictable which RAT will be used.
What currently happens is that when roaming in a country where none of the available PLMN/RATs are prioritised relative to each other, the UE will select randomly a PLMN+RAT out of the high quality PLMNs available. Therefore when a PLMN selection is made and no priority is given on the USIM for the available PLMN+RATs the UE should choose the highest capability RAT, consistent with its own capabilities, provided it is above a usable signal level.
This section highlights that the time from loss of coverage to registration on a new PLMN is already quite long and with future developments will possibly be even longer.
and TS 25.304
mandate that the UE shall search for its last RPLMN in every supported RAT and bands at power on or recovery from lack of coverage before attempting to register on another PLMN.
The reason for selecting the RPLMN instead of the HPLMN was due to the experience found during GSM Phase 1 where the mobile was required to search for its HPLMN first. This meant that in the roaming case the mobile would search for a non-existent PLMN before moving on to select a VPLMN. By making the mobile search for the RPLMN the whole process is speeded up. When in the HPLMN the RPLMN=HPLMN so no delay in selecting HPLMN and when roaming the mobile will have been on the preferred PLMN so again using RPLMN gives the most efficient behaviour.
The issue for operators is that when a UE loses coverage from the RPLMN, it is obliged to perform a full scan of all supported bands (UMTS2100, EGSM900, GSM1800 and possibly even GSM850 and GSM1900 depending on the implementation) before possibly reselecting a different PLMN, such as a National Roaming Partner. Today, such a scan takes a long time in dense or complex radio environment, which means the UE can spend over a minute searching/synchronising/decoding cells where only FPLMNs are to be found. In the future, as more frequency bands are introduced or refarmed for 3G (UMTS1900, UMTS800, 2.5GHz, TDD, FDD in GSM bands, etc.) and more technologies are integrated to 3GPP (WiFi, WiMax, etc.) the UE may require an even longer time to complete a scan of all supported technologies.
It should be possible for the UE to register immediately with its HPLMN when found during the scan.
In order to allow fast network selection, the specifications should not require exhaustive band scans to be performed at moments when they cause unnecessary delays in network selection.
Currently different handsets support different list sizes of the various PLMN lists on the (U)SIM (as specified in 31.102) and this leads to problems for operators when trying to guide the behaviour of the handset in selecting a PLMN. It may be beneficial to standardise a minimum size of list to be supported by the ME. The agreed minimum lengths of the lists should support the normal operational requirements of operators, i.e. not necessarily the longest possible list sizes but a reasonable portion of them.
The lists concerned include: Operator PLMN, User PLMN, and Forbidden PLMN.
Currently means are provided to prevent the handset from constantly attempting to obtain service from PLMNs that it is unable to use (e.g. due to roaming restrictions). One means of achieving this is through the use of the PLMN Forbidden List.
It is possible for PLMN entries to be removed from the Forbidden List due to limitations on its size or on successful PLMN registration by manual selection As the Forbidden List can also be controlled by the operator via OTA, this could create a position where the operator can not effectively control the user's Forbidden List for the following purposes:
Use of the Forbidden List to change or improve user experience
Any form of guaranteed experience through OTA updates (as the OTA update can quickly be over written by the handset)
It would be useful to introduce a means for the home operator to have greater control over the PLMN selection procedure while maintaining the use of the current Forbidden List which is dynamically updated by the UE. Specifically, it should be possible for the HPLMN to prevent user access to specified PLMNs or PLMN + RAT combinations that the user cannot over-ride. It should be possible to hide barred PLMNs or PLMN + RAT from user selection or indicate in some way to the user that these selections are not possible. Any restriction shall not preclude access to networks for emergency calls.
There are two situations of device use which makes it difficult how they select networks
Devices that are always on - The problem here is that in some cases, any USIM OTA updates take effect only when the device is power cycled. If the device is not power cycled the customer will not receive the benefit of the new list of preferred networks. Note the re-reading of the USIM files by the device, could possibly be improved with more uniform support of the "refresh" command by device manufacturers. Ideally the HPLMN should be able to request that UE performs a refresh when it sends an OTA update and this refresh should be invisible to the user.
Devices that are often off - The problem here being that to update this type of device operators may need complex configurations that send out updates as soon as the device is powered on. Any type of "bulk" USIM OTA updates will fail on these device types as the device is normally off.
The handling of OTA updates should be improved and the refreshing of data used by the UE should be as quick as possible so long as this does not adversely impact the user (e.g. data should not be refreshed if doing so would lead to a dropped call). Means should be provided to allow the subscriber's operator to update information, used by the UE, in the most optimum manner possible.
Note: This might be addressed by OMA Device Management
Currently the mechanisms standardised do not seem to adequately cater for the national roaming scenario nor formulti RAT (3G, WLAN, 2G etc.) environments. This, when associated with fluctuating signal condition, can lead to UE ping-ponging between 2G and 3G , causing significant signalling load on the network as well as severely affecting user experience.
The currently specified behaviour is as follows:
If less than 12 seconds, the UE will be momentarily out of coverage but will not declare out of service (OOS), and then it will come back to the serving cell.
If slightly more than 12 seconds, the UE will declare Out-of-service(OOS) and start scanning, but then will most likely come back to the same 3G cell.
If longer (~30 sec) the UE may go to a national roaming partner, but after 6 minutes it is likely to come back to the same weak 3G cell upon the first background HPLMN search.
This will create instability that will affect user experience as this is a source of missed calls, failed call setups and possible denial of certain services.
Means should be reviewed to improve the effect of ping ponging between registration areas. It should be possible for allow the network to be configured by the operator so as to enable the definition of different quality criteria for leaving and coming back to a cell/PLMN.
mandates that the UE shall always select in priority its last RPLMN or an ePLMN when recovering from out of coverage or at power-on.
The main reason for this RPLMN requirement was due to the fact that in all roaming cases at that time the mobile will not find its HPLMN and this introduced an unnecessary (and unacceptable) delay to getting into service. In the case the mobile was in its home country it will, in the majority of cases, be on its HPLMN (i.e. the RPLMN is the HPLMN) so there is no problem with looking for the RPLMN first.
requires the UE to wait for at least 2 minutes following power-on before attempting to access the HPLMN or an EHPLMN or higher priority PLMN, thus enabling the UE to receive any messages from the network
At recovery from lack of coverage (e.g. tube or tunnel) and if the UE lost coverage whilst registered on the National Roaming Partner, the UE will go directly to the National roaming partner even if the HPLMN is present. Then the UE will have to wait for the HPLMN timer to expire before it can attempt to register on the HPLMN.
At power on scenario and if the UE was last registered on the National Roaming Partner, then no HPLMN search is permitted for the first 2 minutes after registration (again according to TS 23.122
Consideration should be given to reducing this time to 1 minute, if feasible.
Ideally the UE should be allowed to reselect any available higher priority PLMN (e.g. the HPLMN) possible and not be forced to return to the RPLMN if a higher priority PLMN is available.
A problem exists for mobile users when commuting across national borders. Whilst manual network selection may be used to ensure that the user can select the HPLMN / EHPLMN, many users use Automatic Selection mode; and the ME is only permitted to select PLMNs of a higher priority within the same country in automatic mode. This leads to the situation that, having crossed back into its home country and within HPLMN coverage, an ME might remain camped on the VPLMN in the adjacent territory.
As a consequence, the user will be charged international roaming rates for all calls made or received until such time as he either
moves out of VPLMN coverage or
manually selects the HPLMN.
Currently the TS 23.122
allows an operator to define a list of EHPLMNs which may have different priority. Thus under automatic network selection it is possible to for one of the constituent networks to be given priority over another. Manual network selection only allows the highest EHPLMN to be displayed to the subscriber even when there are other EHPLMNs. The subscriber is not allowed to select any other EHPLMN. If the highest priority EHPLMN is not available while the user has selected it in the manual network selection, UE will select the highest available EHPLMN without interaction with the user.
Another choice is to make the user aware, during a manual network selection attempt that more than one EHPLMN has been found and allow the user to select one over the other. However, the impact on user experience should be evaluated carefully.
Since each choice is expected by different operators, there should be a mechanism to fulfil both requirements.
This section looks at how technology changes can impact the current Network Selection mechanism. When a new technology has been introduced typically one of two options are taken:
Replication of the network selection principles.
Replicating the user experience provides the same over all "look and feel" to the user, however from an operators perspective it is possible to use a different set of variables to assist the UE in choosing the most appropriate network. There is also the opportunity to provide some additional control, however the experience to the user should be technology independent. Current examples include the ability to define a different set of preferred PLMNS for I-WLAN
Do nothing to the network selection principles.
Some technology changes do not allow replication of the user experience. Core network technologies such as CAMEL, IMS, etc fall into this category. In these instances the UE is not aware of the capabilities of the core network when it performs a scan of the radio broadcast information.
As technology changes are introduced there is the possibility that the "ideal"
network for a given user may not correspond to the preferred network as indicated by the HPLMN currently on the (U)SIM. In order to ensure the best user experience operators may need to regularly update their preferred lists, and also verify that all users receive those updates. The "ideal"
network may also change from user to user depending on the services that she decides to use.
This becomes a more complex model as more technology changes are introduced into the 3GPP system. For example an operator may have roaming services based upon CAMEL with one operator in the visited country but only have GPRS roaming with one of the other operators. The UE should be directed to the best network at the time for the user at that time taking into consideration variables such as service(s) availability, cost etc.
The network selection procedures in TS 22.011
focuses on PLMN selection defined in clause 22.214.171.124
as "an UE based procedure, whereby candidate PLMNs are chosen, one at a time, for attempted registration"
Upcoming usage scenarios may require taking into consideration for network selection where there are different ownerships of the Radio Access Network (RAN), the Core Network (CN) and Service Network (SN). For example, taking the I-WLAN case, at a particular location several WLAN access networks could provide access to the HPLMN services. Figure 1 depicts the generic situation where there are multiple RANs, CNs and Service Networks that all have different business relationships:
Each of the RANs and CNs has different capabilities e.g. HSPDA, EDGE, CAMEL. Thus if a UE is turned on and performs an initial scan or does a background scan there is need to choose a RAN / CN that provides the services that the UE wants to use.
Also given that there could be multitude of RANs in different technologies the coverage area of each RAN technology would be different. It could be advantageous that the UE is aware of the RANs / CN combinations that are available to it at any given time. Possible solution approaches could be, for example, the definition of specific background scan timers for different RATs. The UE could also determine the capabilities of the RATs and corresponding connecting CNs.
Given that multiple technologies may be available in a given location, it would be useful to provide a single mechanism for identifying preferences.
For example, the HPLMN may wish to give the highest priority to Operator A being accessed via the I-WLAN Access System over Operator B via 2G. If Operator A cannot be accessed via that I-WLAN, then the second priority, Operator B (possibly with a preferred RAT) will be attempted.
Furthermore, in certain situations it could be advantageous for a PLMN to be able to instruct a terminal to gain access over a particular RAT and/or intermediate core network. To this avail, appropriate system reselection mechanisms could be of interest.
This Technical Report has reviewed current practice with regard to Network Selection Principles and considered the impact of some future developments within 3GPP on the existing mechanisms. It is concluded that it would be beneficial to consider enhancements to the current specifications in a number of areas.
A number of concerns over the time the network selection process takes have been raised, especially in the cases where UE's support multiple bands and multiple modes.
Ideal performance targets have been identified as: less than 20 seconds to select a PLMN in the case where the RPLMN is not available and less than 5 seconds in the case where the RPLMN is available.
Methods to improve the time taken for a UE to regain service and hence avoid time consuming searches of all the bands in which a UE can operate should be considered.
There is a requirement to provide the tools to a network operator to allow them to offer their customers the best possible experience when roaming into other networks. This includes the ability of the home operator to control their user's selection of visited network from the perspective of service provisioning, access technology, terminal capability, and so on. Such tools include
The ability for the HPLMN to dynamically direct a UE to select a different VPLMN.
The ability to prevent users from selecting specific PLMNs.
Enhancements to Manual Network Selection to provide the user with additional information to assist their choice.
To allow Network Operators to dynamically distribute their roaming customers across multiple VPLMNs in a given country.
Practical experience from the implementation of National Roaming has highlighted a number of areas where enhancements to the 3GPP specifications could be considered.
In the case where a UE is registered to a national roaming partner and loses coverage, the UE will attempt to select the RPLMN (the national roaming partner). In some cases, but not all, it is desirable to register to the HPLMN if it has become available.
In the case where a UE may oscillate between two PLMNs.
The performance of PLMN selection in border areas should be improved, as it has been noted that network operators are advising their customers to manually select the HPLMN to avoid accidental roaming.
In the course of the development of the TR some additional areas for enhancements to the 3GPP specifications have been identified. These are:
It may be beneficial to standardise a minimum size of list to be supported by the ME and any conclusion should support the normal operational requirements of operators
The use of the Refresh command should be reviewed to allow the subscriber's operator to update information, used by the UE, in the most optimum manner possible.
At power on, in manual mode, if the RPLMN is not found, but the HPLMN is available then the UE should automatically register with it.
It should be possible for the user to set a preference for either manual or automatic network selection on power-up
In any future developments of the 3GPP specifications backwards compatibility is essential and the utilisation of entities from different 3GPP releases should also be considered as detailed in clause 5.3