Content for TS 23.251 Word version: 17.0.0

4.1 Overview 4.2 Core Network Operator and Network Selection 4.3 Network Name Display for Supporting UEs 4.4 HPLMN Support 4.5 Support of Cell Broadcast Services and Warning System 4.6 Support of Extended Access Barring 4.7 Support of service identification for improved radio utilization for GERAN
...

4 General Description p. 8

4.1 Overview p. 8

A network sharing architecture shall allow different core network operators to connect to a shared radio access network. The operators do not only share the radio network elements, but may also share the radio resources themselves. In addition to this shared radio access network the operators may or may not have additional dedicated radio access networks, like for example, 2G radio access networks. There are two identified architectures to be supported by network sharing. They are shown in the figures below.

In both architectures, the radio access network is shared. Figure 1 below shows reference architecture for network sharing in which also MSCs and SGSNs are shared. This configuration will be referred to as a Gateway Core Network (GWCN) configuration.

Copy of original 3GPP image for 3GPP TS 23.251, Fig. 1: A Gateway Core Network (GWCN) configuration for network sharing. Besides shared radio access network nodes, the core network operators also share core network nodes

Figure 1: A Gateway Core Network (GWCN) configuration for network sharing. Besides shared radio access network nodes, the core network operators also share core network nodes
(⇒ copy of original 3GPP image)

Figure 2 below shows the reference architecture for network sharing in which only the radio access network is shared, the Multi-Operator Core Network (MOCN) configuration.

Copy of original 3GPP image for 3GPP TS 23.251, Fig. 2: A Multi-Operator Core Network (MOCN) in which multiple CN nodes are connected to the same RNC and the CN nodes are operated by different operators

Figure 2: A Multi-Operator Core Network (MOCN) in which multiple CN nodes are connected to the same RNC and the CN nodes are operated by different operators
(⇒ copy of original 3GPP image)

The UE behaviour in both of these configurations shall be the same. No information concerning the configuration of a shared network shall be indicated to the UE.

For the Evolved Packet System, only the PS domain of the above figures is relevant. For E-UTRAN access Figures 1 and 2 both apply but with the MME replacing the SGSN, the eNodeB replacing the RNC, and the S1 reference point replacing the Iu interface.

For GERAN access, both GWCN and MOCN are applicable but with the BSC replacing the RNC and the A/Gb-Interfaces replacing the Iu interface.

4.2 Core Network Operator and Network Selection p. 9

Network sharing is an agreement between operators and shall be transparent to the user. This implies that a supporting UE needs to be able to discriminate between core network operators available in a shared radio access network and that these operators can be handled in the same way as operators in non-shared networks.

4.2.1 Core network operator identity p. 9

A core network operator is identified by a PLMN-id (MCC+MNC).

4.2.2 Broadcast system information for network sharing p. 10

If a shared RAN is configured to indicate available core network operators for selection by UEs, each cell in shared radio access network shall in the broadcast system information include information concerning available core network operators in the shared network.

The available core network operators shall be the same for all cells of a Location Area in a shared UTRAN or GERAN network.

For E-UTRAN, the Broadcast System Information broadcasts a basic set of PLMN IDs and optionally one or more additional set of PLMN IDs. All E-UTRAN UEs support reception of the basic set, only Release 14 and later E-UTRAN UEs are required to receive the additional set (see TS 36.331).

The available core network operators shall be the same for all cells of a Tracking Area in a shared E-UTRAN network. The basic and the additional sets allow different (sets of) PLMNs to have different cell ID and TAC.

A supporting UE decodes the broadcast system information and takes the information concerning available core network operators into account in network and cell (re-)selection procedures. Broadcast system information is specified in TS 44.018 for GERAN, TS 25.331 for UTRAN and TS 36.331 for E-UTRAN.

4.2.3 Network selection in a shared network p. 10

4.2.3.1 Behaviour of supporting UEs (GERAN, UTRAN and E-UTRAN) p. 10

In some sharing scenarios, the sharing operators require the UTRAN/GERAN to broadcast, to non-supporting UEs, a PLMN ID that does not identify any of the sharing core network operators. In this case, it is necessary that a supporting UE does not select this "common PLMN ID".

In other sharing scenarios, the sharing operators may want the PLMN broadcast to non-supporting UEs to be selectable by supporting UEs.

A supporting UE decodes the broadcast system information to determine available core network operators in the shared network. The UE regards both the core network operators indicated in the broadcast system information and conventional networks as individual networks. The core network operators together with all conventional networks are candidate PLMNs for the PLMN selection procedure that shall be performed by the UE as specified in TS 23.122.

In GERAN and UTRAN, non-supporting UEs use the broadcast "common PLMN-id" in their PLMN (re)selection processes.

In UTRAN, supporting UEs shall use the PLMN-ids that are broadcast in the Multiple PLMN ID List information element in their PLMN (re)selection processes. UTRAN AS signalling permits the Multiple PLMN ID List to indicate to supporting UEs whether to include or exclude the MCC+MNC of the "common PLMN-id" in their network (re)selection processes.

For supporting UEs, GERAN provides equivalent functionality to UTRAN.

For E-UTRAN, the UE uses all of the received broadcast PLMN-ids in its PLMN (re)selection processes.

4.2.3.2 Behaviour of non-supporting UEs (GERAN, UTRAN) p. 10

Non-supporting UEs ignore the broadcast system information that is relevant for network sharing. The common PLMN together with all conventional networks are candidate PLMNs for the PLMN selection procedure that shall be performed by the UE as specified in TS 23.122.

It is recommended for the network and the UE to support the Network Identity part of the Network Identity and Time Zone (NITZ) feature (see TS 22.042) for providing the UE with the name of the serving PLMN operator.

4.2.4 Assignment of core network operator and core network node p. 10

When a UE performs an initial access to a shared network, one of available CN operators shall be selected to serve the UE. For non-supporting UEs, the shared network selects an operator from the available CN operators. For supporting UEs, the selection of core network operator by the UE shall be respected by the network. Supporting UEs inform the BSC/RNC/eNodeB of the network identity of the chosen core network operator.

In a UTRAN GWCN configuration, the RNC relays the chosen network identity to the shared core network node (in UTRAN MOCN, the RNC indicates that the UE is a "supporting UE" by relaying the chosen network identity to the core network node). To permit GWCN operation, in E-UTRAN, the eNodeB always relays the chosen network identity to the shared MME. In a GERAN GWCN configuration, the BSC relays the chosen network identity to the core network node (in GERAN MOCN, the BSC indicates that the UE is a "supporting UE" by relaying the chosen network identity to the core network node).

In a MOCN configuration, the RAN routes the UE's initial access to the shared network to one of the available CN nodes. Supporting UEs shall inform the RAN of the chosen core network operator so that the RAN can route correctly. For non-supporting UEs the shared network selects an operator from the available CN operators. A redirection to another CN operator may be required for non-supporting UEs until an operator is found that can serve the UE. Redirection is described in clause 7.1.4.

After initial access to the shared network the UE does not change to another available CN operator as long as the selected CN operator is available to serve the UE's location. Only the network selection procedures specified in TS 23.122 may cause a reselection of another available CN operator. Also the network does not move the UE to another available CN operator, e.g. by handover, as long as the selected CN operator is available to serve the UE's location. Furthermore the UE does not change to another CN node as long as the selected CN node is available to serve the UE's location.

In GERAN and UTRAN, when the network signals location/routing area identities to supporting UEs, e.g. in location updating accept messages, these identities shall contain the chosen core network operator identity. For non-supporting UEs, they shall contain the common PLMN. The UE stores the received LAI/RAI on the SIM/USIM, as already specified in TS 24.008.

In E-UTRAN, the chosen core network operator identity is included in the GUTI in e.g. the Attach Accept message. The UE shall store the received GUTI on the USIM according to the rules specified in TS 24.301.

4.2.5 PS and CS domain registration coordination in UTRAN and GERAN p. 11

In conventional networks, the same CN operator always serves the UE in CS and PS domains. In a shared network, supporting UEs shall behave as UEs in conventional networks with respect to registration with CS and PS domains and always register with the same operator for the CS and PS domains. CS/PS coordination should be performed at registration when a redirect attempt flag is included in A/Gb/Iu messages carrying the NAS registration message (see TS 48.008, TS 48.018, and TS 25.413). The term registration includes attach, and LA and RA updates.

When multiple PLMNs are available and SRVCC from UTRAN/GERAN CS domain to E-UTRAN/HSPA PS is deployed, the source BSC/RNC determines a core network operator to be used in the target network based on current PLMN in use, Anchor PLMN provided by PS core network, or other information present in the BSC/RNC. The source BSC/RNC shall at handover indicate the selected core network operator to the source core network node in the handover required message. The anchor MSC Server shall forward the selected core network operator chosen by the source BSC/RNC to the target MME/SGSN.

4.2.5a PS and CS domain registration coordination in E-UTRAN |R8| p. 11

When multiple core network operators share the E-UTRAN using a GWCN configuration, separate MSCs may still be used for the CS Fall Back functionality. In this case the MME uses the 'selected network' information received from the E-UTRAN to select an MSC from the already selected operator.

When multiple PLMNs are available for CS domain, the MME selects the MSC for CS Fallback functionality based on the 'selected network' information received from the E-UTRAN, current TAI, old LAI provided by the UE and operator selection policies as specified in TS 23.272. In this case, the selected PLMN-id for CS domain may be different to the PLMN-id for EPS domain. If the selected MSC is shared network configured, the MME selects the CS domain operator as specified in TS 23.272. If the UE is a GERAN network-sharing non-supporting UE and the preferred RAT of the selected CS network is GERAN with GWCN configuration, or the preferred RAT of the selected CS network is shared network in GWCN configuration not offering the broadcast of available Core Network operators for selection by the UE, the MME sends the 'selected CS domain operator' in addition to the Common PLMN-id included in the LAI to the VLR. If the MSC is GWCN configured, the MSC applies local policy (e.g. uses a fixed split of IMSI ranges or IMSI hash) to determines the CN operator when the PLMN-id included in the LAI contains Common PLMN-id (i.e. does not identify any CS domain operator) and the 'selected CS domain operator' is absent. Otherwise, the MSC accepts the CS domain operator selected by the MME.

When multiple PLMNs are available for CS domain and SRVCC from E-UTRAN PS to UTRAN/GERAN CS domain is deployed, the MME sends the Handover Restriction List (see TS 23.401) to eNB including the currently serving PLMN and equivalent PLMNs together with information about which PLMNs are preferred for SRVCC. The eNB selects target PLMN for SRVCC from the list based on HRL and local policy and constructs the Neighbour Cell list (NCL) based on this knowledge of the target PLMN. The selected target core network PLMN should, if possible, be the same as the one in use.

4.2.5.1 Void

4.2.5.2 Void

4.2.5.3 CS/PS domain coordination and operator selection in GERAN and UTRAN |R13| p. 12

At combined or non-combined registration by a non-supporting UE the BSC/RNC routes the request to one of the available CN nodes. In all Attach Request/Routeing Area Update Request/Location Area Update Request messages from the BSC/RNC to CN a redirect attempt flag shall be included to indicate that the CN should either return a Reroute Command or a Reroute Complete message. If the BSC/RNC can determine that the UE is already served by a CN operator in the opposite domain, then a CN node from this operator shall be selected and the serving CN operator shall be indicated to the CN node together with an indication that the selected CN operator is already serving the UE in the opposite domain. If the BSC/RNC cannot determine a CN operator this way, the selection of CN node by the BSC/RNC is based on the NRI if provided by the UE. The RAN stores the NRI received from the UE.

If the UE is already served by the CN node that receives the registration request and this CN node can continue to serve the UE (for example if there are no regional roaming restrictions for the target area), or if the UE is a non-roaming subscriber, or if the BSC/RNC indicated a BSC/RNC selected CN operator and that the selected CN operator is serving the UE in the opposite domain then the CN node accepts the registration attempt and completes the registration procedure. Otherwise the CN node returns IMSI and a Reroute Command message to the BSC/RNC with an indication that it is for coordination purposes. The old LAI (for the CS domain) or old RAI (for the PS domain), or an indication whether the UE is attaching shall also be included.

Based on information received from CN node (old LAI or old RAI), UE (CS-NRI or PS-NRI, as stored in the RAN) and BSC/RNC internal configuration the BSC/RNC concludes whether:

The UE is 'under operator coordination' i.e. if the UEs (CS-NRI, old LAI) tuple for the CS domain or (PS-NRI, old RAI) tuple for the PS domain can be used to uniquely identify one of the operators in the shared network. The old RAI/PS-NRI can be "native" (i.e. no RAT change) or "mapped" (i.e. RAT change).
The UE is not 'under operator coordination' i.e. the UEs (CS-NRI, old LAI) tuple for the CS domain or (PS-NRI, old RAI) tuple for the PS domain cannot uniquely identify any operator in the shared network. The old RAI/PS-NRI can be "native" (i.e. no RAT change) or "mapped" (i.e. RAT change).
The UE is attaching.

For case (i) the BSC/RNC selects serving CN operator based on the identified operator and routes the request to the selected operator. The IMSI and the BSC/RNC selected CN operator shall be indicated to the CN.

For case (ii) and (iii) the BSC/RNC shall for a (combined or non-combined) registration attempt in the PS domain query its connected MSCs, whether the UE is registered with any of the sharing operators in the CS domain. Similarly for a registration attempt in the CS domain the BSC/RNC shall query its connected SGSNs, whether the UE is registered at any of the sharing operators in the PS domain. For a registration attempt in the CS domain this means that the SGSNs on behalf of the BSC/RNC may be needed to query all MMEs that may hold the UEs context of the sharing operators whether the UE is registered at any of the MMEs of the sharing operators. Registration in MME but not in the CS domain can e.g. occur at cell reselection from LTE for a UE that is not SGs registered. If MMEs are not updated to support registration queries, it may not be possible to guarantee CS/PS coordination in certain scenarios.

For case (ii) and (iii) and if the UE is found to be registered with one of the sharing operators then that operator shall be selected by the BSC/RNC and the registration message shall be forwarded to a CN node of this operator. The BSC/RNC selected CN operator shall be indicated to the CN and the BSC/RNC shall indicate that BSC/RNC selected CN operator is serving the UE in the opposite domain.

For cases (ii) and (iii) and the UE is not found to be registered at one of the sharing operators then the BSC/RNC routes the request to one of the available CN operators. Selection of CN operator is done in the BSC/RNC by IMSI analysis, e.g. using a fixed split of IMSI ranges or IMSI hash table between operators, etc. The CN node / CN operator selection may result in that the registration is sent back to the same CN node or CN operator again. At non-combined registration CS/PS coordination is done in the BSC/RNC (without memorising IMSI information for IDLE mode UEs) by applying the same IMSI analysis for both CS and PS domains. The BSC/RNC selected CN operator shall be indicated to the CN and IMSI shall be included to the CN node.

If a registration attempt is ongoing in the PS domain when a registration attempt starts in the CS domain then the BSC/RNC selects operator as specified below and the IMSI and the BSC/RNC selected CN operator shall be sent to the CN node:

If for the CS domain case (i) applies then that operator shall be selected for both domains.
If for the CS domain case (ii) or (iii) applies then depending on:
- If for the PS domain case (i) applies then that operator shall be selected for both domains
- If for the PS domain case (ii) or (iii) applies then the BCS/RNC selects operator for both domains based on IMSI analysis

Similar handling applies if a registration attempt is ongoing in the CS domain when a registration attempt starts in the PS domain.

At combined registration the SGSN may indicate over Gs interface the selected CN operator that serves the subscriber.

4.2.6 Attach/detach handling p. 13

To attach to the same core network operator from which it detached, a UE uses information stored in the UE (e.g. on the SIM/USIM) when the UE was detached. For a supporting UE in a shared network, the stored information indicates the core network operator it detached from (as specified in clause 4.2.4). This information enables a supporting UE to attach to the same core network operator from which it detached. For non-supporting UEs in a shared network, the stored information indicates the common PLMN.

4.3 Network Name Display for Supporting UEs p. 13

A supporting UE shows the name of the PLMN-id it has registered with. In case of a shared network, it is the PLMN-id of the chosen core network operator. The name stored in the UE for the PLMN-id is displayed except when the network indicates to the UE a name to be displayed, as already specified for non-supporting UEs.

4.4 HPLMN Support p. 13

The use of a shared VLR/SGSN/MME shall not result in service restrictions, e.g. roaming restrictions. Since the HSS and gsmSCF derives whether the subscriber roams in H- or V-PLMN from the VLR/SGSN/MME identifier, a shared VLR/SGSN/MME in a GWCN shall be allocated a separate identifier from each operator sharing that CN node, i.e. a shared VLR/SGSN/MME has multiple identifiers. The VLR/SGSN/MME identifier of the user's serving CN operator (either the one selected by a supporting UE, or, the one allocated by the network for a non-supporting UE) shall be used in signalling with the HSS and the gsmSCF.

In the roaming scenario, the VPLMN shall ensure that any PLMN ID that is communicated to the HPLMN via any interface is that of the selected Core Network Operator for supporting UEs, or that of the allocated Core Network Operator for non-supporting UEs. An exception to this is that the HPLMN operator may specify in the inter-operator roaming/sharing agreement that for non-supporting UEs any PLMN ID that is communicated to the HPLMN is the Common PLMN ID.

When the MME/SGSN and PGW/GGSN pertain to the same PLMN, i.e. in non-roaming scenario and in roaming local breakout scenario, the PLMN ID (as described in TS 36.300 constructed to define the ECGI) shall be communicated via ECGI to the PGW, and the Common PLMN ID shall be communicated in SAI/CGI to the PGW/GGSN for both supporting and non-supporting UEs.

4.5 Support of Cell Broadcast Services and Warning System |R10| p. 14

In shared networks Cell Broadcast and Warning System services are provided via a single common CBC, which connects to GERAN/UTRAN as described in TS 23.041 and connects to E-UTRAN as described in TS 23.401. The deployment and configuration of the common CBC is per agreement between the sharing operators. The sharing operators need to coordinate the broadcast services between each other, e.g. how to provide Warning System services.

4.6 Support of Extended Access Barring |R11| p. 14

In shared networks, BSC/RNC/eNodeB shall provide independent support for the barring of MSs configured for Extended Access Barring (as defined in TS 22.011) for each sharing operator. The BSC/RNC/eNodeB may initiate Extended Access Barring for a specific sharing operator when all the SGSNs/MMEs belonging to that sharing operator connected to this BSC/RNC/eNodeB request to restrict the load for UEs configured for low access priority, or if requested by O&M. Broadcast Extended Access Barring information is specified in TS 44.018 for GERAN, TS 25.331 for UTRAN and TS 36.331 for E-UTRAN.

4.7 Support of service identification for improved radio utilization for GERAN |R11| p. 14

Service Class Indicator (SCI) for improved radio utilization for GERAN (see TS 23.060) is supported in shared network for A/Gb mode GERAN PS domain. The A/Gb mode GERAN identifies the service class associated with downlink user plane packets according to TS 23.060. When deciding whether to use or discard the SCI information, the A/Gb mode GERAN may need to take the identity of the MS's Core Network operator into account.