SGSN Administration Guide, StarOS Release 21.25

Feature Description

A Public Land Mobile Network (PLMN) is uniquely identified by the combination of a mobile country code and a mobile network code (the PLMN-Id). Sharing of radio resource and network nodes requires a PLMN network to support more than one than one PLMN-Id.

GPP defines two different configurations for supporting network sharing based on the resources being shared.

Gate Core Network (GWCN) Configuration

In this configuration, the radio access network and some core network services are shared among different operators. Each operator has its own network node for GGSN, HLR etc, while sharing SGSN and MSC with the rest of the radio network. The figure below depicts a GWCN configuration.

Figure 1. GWCN Configuration for Network Sharing

Multi Operator Core Network (MOCN) Configuration

In this configuration, the radio network is shared among different operators, while each operator maintains its separate core network. The figure below depicts a MOCN configuration.

Relationships to Other Features

SGSN supports both MOCN and GWCN in 3G. GPRS. The MOCN feature can work with 3G network sharing. Inter-RAT from 3G to 2G in shared to non-shared area, and non-shared area to shared are supported.

To enable GPRS MOCN, the BSC also needs to support the GPRS MOCN. For "Supporting-MS", the MS shall have the capability to select the network from the PLMN details shared by the BSC. Currently, the SGSN supports only "non-supporting MS", thus the MS always selects the common PLMN.

How It Works

Automatic PLMN Selection in Idle Mode

This section briefly describes the normal PLMN selection procedure performed by MS along with modifications for network sharing.

Whenever MS is switched on or has just returned to network coverage after being out of coverage, it tries to select a network to register itself and receive network services. Traditionally, each network broadcasts its own PLMN-Id on common broadcast channels that are visible to all MSs in that area.

The MS starts by scanning for all the available radio networks in that area and creating an Available PLMN list. It then refers to the Equivalent PLMN list and Forbidden PLMN list (stored on its SIM) to prioritize the Available PLMN list. Once this prioritized PLMN list is available, the MS attempts registration with a PLMN based on priority.

With network sharing a single radio network is shared by more than one network operator. Information about the availability of multiple operators must be propagated to the MS so that it can correctly select a home or equivalent network from all available networks.

To advertise availability of multiple core network operators on a single radio network, broadcast information has been modified to contain a list of PLMN-Ids representing core network operators sharing the particular radio network. The traditional PLMN-Id broadcast by a radio network before network sharing support was available is known as a "common PLMN Id".

An MS that does not support network sharing (a non-supporting MS) sees only the "common PLMN Id", while an MS supporting network sharing (a supporting MS) is able to see the list of PLMN-Ids along with "common PLMN Id".

A supporting MS is responsible for selecting an appropriate core network, while the RNC and SGSN will help select an appropriate core network for a non-supporting MS.

MOCN Configuration with Non-supporting MS

In this scenario, only the radio network is shared by different network operators while each operator manages its own SGSN and the rest of the core network. The MS does not support network sharing it is unable to understand the modified broadcast information and would always choose the PLMN based on the advertised "common PLMN-Id".

The SGSN performs the following steps:

Extract the subscriber's IMSI.
- If it is available, use IMSI in a BSSGP UL-UNITDATA message.
- For inter-SGSN RAU and a P-TMSI Attach Request, retrieve the IMSI from the old SGSN or the MS by doing an Identity Procedure.
Based on the MCC-MNC from the IMSI, apply roaming control.
If the subscriber can be admitted in the SGSN, send a response message (Attach-Accept or RAU-Accept) with an Redirection-Completed IE via BSSGP UL-UNITDATA.
If the subscriber cannot be admitted in the SGSN, send a BSSGP DL-UNITDATA message to the BSC with a redirection indication flag set containing the reject cause, the attach reject message, and the original attach request message received from the UE. The IMSI is also included in the message.

Architecture

Redirection in GERAN with MOCN Configuration

The figure below illustrates the information flow for this configuration.

Figure 3. Information Flow for Redirection in GERAN (PS Domain)


1	Establish the TBF (Temporary Block Flow).
2	The BSC receives the LLC frame with foreign [or random] TLLI =X. The BSC works in a Shared RAN MOCN, and, therefore, forwards the message in a BSSGP ULUNITDATA message with an additional redirect attempt flag set. The flag indicates that the SGSN shall respond to the attach request with a BSSGP DL-UNITDATA message providing when relevant a redirection indication flag set to inform the BSC that a redirection to another CN must to be performed. The selection of a CN node is based on NRI (valid or invalid) or random selection. The mechanism defined for Gb-Flex in TS 23.236 [8] is used.
3	The SGSN receives the BSSGP UL-UNITDATA message with the redirect attempt flag set. It then knows it may have to provide the BSC with a redirection indication flag set or a redirection completed flag set.
4	The SGSN needs the IMSI of the UE retrieves it either from the old SGSN or from the UE as in this example. By comparing the IMSI with the roaming agreements of the CN operator, SGSN A discovers that roaming is not allowed or that roaming is allowed but CS/PS coordination is required. The Attach procedure is aborted.
5	5a) A BSSGP DL-UNITDATA message is sent back to the BSC with a redirection indication flag set containing the reject cause, the attach reject message, and the original attach request message received from the UE. The V(U) shall also be included in the message. The IMSI is also included in the message. The BSC selects a SGSN B in the next step. The already tried SGSN A is stored in the BSC during the redirect procedure so that the same node is not selected twice. 5b) The BSC makes a short-lived binding between the TLLI =X and SGSN ID so that it points to SGSN B.
6	The BSC sends a new BSSGP UL-UNITDATA to the next selected SGSN B with the original attach request message (for CS/PS coordination the BSSGP UL-UNITDATA may also be sent back to the first SGSN depending on the outcome of the coordination). Redirect attempt flag is set and IMSI is included to avoid a second IMSI retrieval from the UE or old SGSN and to indicate that PS/CS domain coordination has been done in BSC (if enabled in BSC). The V(U) shall also be included in the message. The SGSN B receiving the message starts its attach procedure.
7	SGSN B does support roaming for the HPLMN of the IMSI authentication is done and RAN ciphering is established. The value of V(U) in SGSN-B is set according to the received value from BSC. Uplink LLC frames are routed to SGSN B despite the NRI of the TLLI=X pointing to SGSN A.
8	SGSN B updates the HLR and receives subscriber data from HLR Subscriber data allows roaming, and the SGSN B completes the attach procedure.This includes the assignment of a new P-TMSI with an NRI that can be used by BSC to route subsequent signalling between UE and the correct SGSN (Gb-Flex functionality).
9	A BSSGP DL-UNITDATA Attach accept message is sent to BSC with the Redirection Completed flag set. The BSC knows that the redirect is finished and can forward the Attach Accept message to the UE and clean up any stored redirect data. SGSN B is allowed to reset the XID parameter only after the Attach Request is accepted.
10	The Attach Accept is forwarded to the UE. The UE stores the P-TMSI with the Gb-Flex NRI to be used for future signalling, even after power off.
11	UE responds with an Attach Complete message (P-TMSI [re-]allocation if not already made in Attach Accept). The Attach Complete uses the new TLLI. After this, the BSS releases the binding between TLLI=X and SGSN B.

If the BSC finds no SGSNs to redirect to after receiving a BSSGP DL-UNITDATA message with the Redirection Indication flag set, it compares the cause code with cause codes from other BSSGP DL-UNITDATA messages it has previously received for this UE. A cause code ranking is done and the "softest" cause code is chosen. The corresponding saved Attach Reject message is returned to the UE.

Each CN node that receives a BSSGP UL-UNITDATA, runs its own authentication procedure. This may in some rare situations cause the UE to be authenticated more than once. However, the trust-model used is that one CN operator shall not trust an authentication done by another CN operator. This is not an optimal usage of radio resources, but given the rare occurrence of this scenario, the increased signalling is insignificant.

During the redirect procedure the BSC keeps a timer, which corresponds to the UE timer for releasing the RR connection (20 seconds). If the BSC when receiving a BSSGP DL-UNITDATA message with the Redirection Indication flag set finds that there is insufficient time for another redirect, further redirect attempts are stopped (for this Attach Request message). The UE will repeat its Attach Request four times (each time waiting 15 seconds before it re-establishes the RR connection for another try).

Standards Compliance

Support for 2G MOCN functionality on the SGSN complies with the following standards:

3GPP TS 23.251 Network Sharing: Architecture and functional description
3GPP TS 40.018 version 10.7.0 Release 10 BSSGP layer specification
3GPP TS 44.064 Mobile Station - Serving GPRS Support Node (MS-SGSN) Logical Link Control (LLC) Layer Specification
3GPP TS 24.008 Mobile radio interface Layer 3 specification Core network protocols

Configuring 2G MOCN

For details about the commands listed below, refer to the Command Line Interface Reference for the appropriate release.

GPRS MOCN Configuration

gprs-mocn

The SGSN mode gprs-mocn command enables or disables 2G MOCN support.

config 
   sgsn-global 
      gprs-mocn 
      end

Verifying gprs-mocn Configuration

From the Exec mode, run the show sgsn-mode command and look for the line:

Multi Operator Core NW (MOCN)   : Enabled

Common PLMN-Id and List of PLMN Ids Configuration

plmn id

The following command sequence configures the common PLMN-Id and an optional list of dedicated PLMN-Ids in the GPRS service.

config 
   context  ctxt_name 
      gprs-service  gprs_srvc_name 
         plmn id mcc mcc_id mnc mnc_id  [ network-sharing common-plmn mcc mcc_id mnc mnc_id [ plmn-list mcc mcc_id mnc mnc_id [ mcc mcc_id mnc mnc_id ] + ] ]  
         end

Notes:

+ in the syntax above indicates that the mcc/mnc combination can be repeated as often as needed to define all PLMN-Ids needed in the list.

Verifying plmn id Configuration

From the Exec mode, run the show gprs-service command, including the name keyword to identify the specific GPRS service you configured above, and check the output for the following lines:

Network Sharing              : <Enabled/Disabled> 
Common Plmn-id               : MCC: <mcc_id>, MNC:  <mnc_id> 
Local PLMNS: 
PLMN                         : MCC: <mcc_id>, MNC:  <mnc_id>

Network Sharing Configuration

network-sharing cs-ps-coordination

Next, the operator should configure cs-ps-coordination checking explicitly for homer or roamer subscribers and for the failure-code to be sent when the SGSN asks the BSC to perform CS-PS coordination.

The network-sharing command enables or disables the cs-ps coordination check for homer or roamer . It is also used to set the failure code that will be sent while the SGSN is requesting the BSC to provide CS-PS coordination.

config 
   context <ctxt_name> 
      gprs-service <gprs_srvc_name> 
         network-sharing cs-ps-coordination [ roamer | homer | failure-code gmm-cause ] 
         end

Notes: Variations of the network sharing command can be used to adjust the CS-PS configuration.

[ no ] network-sharing cs-ps-coordination roamer enables/disables the cs-ps-coordination check for a roamer.
[ no ] network-sharing cs-ps-coordination homer enables/disables the cs-ps-coordination check for a homer.
network-sharing cs-ps-coordination failure-code gmm-cause sets the gmm cause value to be sent while cs-ps-coordination is required. This setting applies to both homer and roamer .
default network-sharing cs-ps-coordination sets the cs-ps-coordination parameters to default. By default, checking for cs-ps-coordination is enabled for homer and roamer. The default failure code is 0xE.

Verifying network-sharing Configuration

From the Exec mode, run the show gprs-service command, including the name keyword, and check the output for the following lines:

CS/PS Co-ordination homer    : <Enabled/Disabled> 
CS/PS Co-ordination roamer   : <Enabled/Disabled> 
CS/PS Co-ordination failcode : <valid gmm cause>

network-sharing failure-code

The following command sequence sets the failure code that is used by GPRS MOCN if no failure cause is available when the SGSN sends an Attach/RAU Reject message

config 
   context ctxt_name 
      gprs-service gprs_srvc_name 
         network-sharing failure-code gmm-cause 
         end

Default network sharing failure-code is 7.

Verifying Failure Code Configuration

From the Exec mode, run the show gprs-service name command and look for the following line:

Network-sharing Failure-code : <gmm-cause>

Monitoring and Troubleshooting 2G SGSN MOCN Support

The output generated by the following show commands will assist you in monitoring and troubleshooting 2G SGSN MOCN support.

show sgsn-mode

From the Exec mode, run the show sgsn-mode command and look for the following line:

Multi Operator Core NW (MOCN)   : <Enabled/Disabled>

This line indicates whether or not MOCN has been enabled.

show gprs-service name

From the Exec mode, run show gprs-service name gprs-service-name and check the output for the following lines:

CS/PS Co-ordination homer    : <Enabled/Disabled> 
CS/PS Co-ordination roamer   : <Enabled/Disabled> 
CS/PS Co-ordination failcode : <valid gmm cause>

The above lines display details regarding cs/ps coordination for homer and roamer, as well as the GMM cause to be sent in the Reject message when cs/ps coordination is required.

Network-sharing Failure-code : <gmm-cause>

The above line displays the GMM cause to be sent as a Reject cause only when no valid cause code was derived while sending the Reject message. This gmm-cause is used for non-cs/ps coordination Rejects.

Network Sharing              : <Enabled/Disabled> 
Common Plmn-id               : MCC: <mcc_id>, MNC:  <mnc_id> 
Local PLMNS: 
PLMN                         : MCC: <mcc_id>, MNC:  <mnc_id>

The above lines display details about the GPRS service with MOCN enabled, including the configured common PLMN-id and the list of local PLMN Ids.

show gmm-sm statistics verbose

From the Exec mode, run show gmm-sm statistics verbose and look for the following lines:

GPRS MOCN Attach Statistics 
 Total Redirection Attempts Rcvd: 
       Redirection attempts rcvd with bsgp imsi:         <value>  
       Redirection attempts rcvd without bssgp imsi:     <value>  
 Total Redirection Completes Sent:                       <value>  
       Successful Redirection completes sent:            <value>  
       Failure Redirection completes sent:               <value>  
 Total Redirection Indications Sent:                     <value>  
       Illegal PLMN:                                     <value>  
       Illegal LA:                                       <value>  
       No roaming:                                       <value>  
       No gprs PLMN:                                     <value>  
       No cell in LA:                                    <value>  
       CS/PS Coord Rqrd:                                 <value>  
       Others:                                           <value>  
   
GPRS MOCN RAU Statistics 
 Total Redirection Attempts Rcvd:                        <value>  
       Redirection attempts rcvd with bssgp imsi:        <value>  
       Redirection attempts rcvd without bssgp imsi:     <value>  
 Total Redirection Completes Sent:                       <value>  
       Successful Redirection completes sent:            <value>  
       Failure Redirection completes sent:               <value>  
 Total Redirection Indications Sent:                     <value>  
       Illegal PLMN:                                     <value>  
       Illegal LA:                                       <value>  
       No roaming:                                       <value>  
       No gprs PLMN:                                     <value>  
       No cell in LA:                                    <value>  
       CS/PS Coord Rqrd:                                 <value>  
       Others:                                           <value>

Bias-Free Language

Book Title

SGSN Administration Guide, StarOS Release 21.25

Chapter Title

MOCN for 2G SGSN

Results

Chapter: MOCN for 2G SGSN