Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 23.236  Word version:  16.0.0

Top   Top   Up   Prev   Next
0…   4…   5…   6…   A…

 

5  Functional Description

5.1  MS Functions

In Iu mode the MS provides the IDNNS to the RNC in the access stratum part of the RRC_initial_DT message as described in TS 25.331.
If the MS is E UTRAN capable, then TS 23.401, TS 23.060 and TS 23.003 define rules as to how the MS shall select and encode the identity to place in the P TMSI/TLLI parameters used in the Routing Area Update procedure. For the PS domain, the E UTRAN capable MS shall use this P TMSI parameter to derive the UTRAN IDNNS parameter. For the CS domain, the E UTRAN temporary identities shall not be used to derive the IDNNS: instead the MS shall use its (MSC supplied) TMSI, if that TMSI is valid, to derive the IDNNS.
When the MS in Iu mode replies to IMSI paging, it shall derive IDNNS from (P)TMSI if a valid one is available. If (P)TMSI is not available, the MS shall derive IDNNS from IMSI.
No further changes are expected in the MS for Gb or A interface mode.
Up

5.2  RNC FunctionsWord‑p. 16
The RNC provides the NAS Node Selection Function. It masks the significant number of bits out of the IDNNS provided by the MS together with the initial NAS signalling message. The significant number of bits is configured in the RNC. The NAS Node Selection Function derives from the NRI the address of the specific CN node for the relevant domain (CS or PS). The association between NRI values and CN node addresses is configured in the RNC (O&M).
The RNC routes the initial NAS signalling messages according to the NRI and the "domain indicator" (CS or PS) to the relevant CN node if a CN node address is configured in the RNC for the specific NRI and the requested domain (CS or PS).
When IDNNS is derived from the IMSI, the IDNNS has a value (V) from the range 0 to 999 as defined in TS 25.331. The RAN node shall be configured to use the value (V) to select a CN node. Each value (V) corresponds a single CN node. Typically many values of (V) may point to the same CN node. In some networks, the RAN node may be configured to select the MSC/VLR or SGSN for "UEs configured for low access priority" with a different load balance to that used for MSC/VLR or SGSN selection for other UEs. In this case the RAN node maintains a second, separate mapping table between value (V) and CN node for "UEs configured for low access priority".
If the selected CN node is not available or if no CN node address is configured in the RNC for the requested NRI or if the provided identity contains no NRI then the RNC routes the initial NAS signalling message to a CN node selected from the available CN nodes which serve the related domain (CS or PS). The selection mechanism is implementation dependent and should enable load balancing between the available CN nodes. In some networks, the RNC may be configured to select the MSC/VLR or SGSN for "UEs configured for low access priority" with a different load balance to that used for MSC/VLR or SGSN selection for other UEs.
In case a MSC sends a paging with IMSI (i.e. the paging message does not contain a TMSI), the RNC may, for purposes to increase the paging success rate, upon reception temporarily store the Global-CN-ID of the node that issued the paging message. If the MSC/VLR initiates the paging procedure via Gs-interface the SGSN has to add the Global-CN-ID to the paging message.
Up

5.2.1  Load Re-Distribution function in RNC |R6|

When the RNC receives a message with a 'null-NRI' it uses the NAS Node Selection Function for selecting a CN node where to forward the message. CN node(s) with re-distribution in progress should be excluded from the NAS Node Selection algorithm in the RNC. This is done by O&M configuration in the RNC.
In network configurations using MOCN network sharing, the RNC is preconfigured with a null-NRI for each CN Operator in the MOCN. The RNC selects a CN node belonging to a CN Operator based on what 'null-NRI' is received.
Up

5.3  BSC Functions

5.3.1  A interface mode

The BSC provides the NAS Node Selection Function. It is aware whenever a new RR connection is established. In particular, the BSC always examines the content of the Initial Layer 3 message sent by the MS in order to determine the position of the MS Classmark and to extract its contents. The examination of the Initial Layer 3 message content allows the BSC to observe the TMSI+LAI or IMSI or IMEI.
The BSC derives from Initial Layer 3 messages the NRI from the TMSI. It is configured in the BSC (O&M) which bits of the TMSI are significant for the NRI. The BSC routes the Initial Layer 3 message according to the NRI to the relevant MSC if an MSC address is configured in the BSC for the specific NRI. The association between NRI values and MSC addresses is configured in the BSC (O&M).
If no MSC address is configured in the BSC for the requested NRI, or if no TMSI is sent by the MS (e.g. an IMSI or IMEI), then the BSC routes the initial NAS signalling message to an MSC selected from the available MSCs. In addition, the BSC may route the initial NAS signalling message to an MSC selected from the available MSCs if this message is a Location Update Request messages and the PLMN ID in the LAI is not one of the PLMN IDs served by the BSC (FFS). The selection mechanism is implementation dependent and should enable load balancing between the available MSCs. In some networks, the BSC may be configured to select the MSC/VLR for "MSs configured for low access priority" with a different load balance to that used for MSC/VLR selection for other MSs.
In case a MSC sends a paging-request with IMSI, the NAS node selection function in the BSC shall upon reception temporarily store the MSC/VLR-identity of the node that issued the paging-request message.
Up

5.3.2  Gb modeWord‑p. 17
The BSC provides the NAS Node Selection Function. The MS sends the TLLI to the BSC. The NRI is part of the P-TMSI and therefore also contained in the 'local TLLI' or in the 'foreign TLLI'. The number of bits out of the TLLI which are significant for the NRI is configured in the BSC (O&M).
A 'local TLLI' indicates to the BSC that the TLLI is derived from a P-TMSI which was assigned for the current RA, i.e. the 'local TLLI' contains an NRI which is valid for routing to an SGSN. A 'foreign TLLI' indicates to the BSC that the TLLI is derived from a P-TMSI which was assigned for another RA than the current RA. The BSC does not know whether the other RA and therefore the related P-TMSI belongs to the same pool-area or not unless this is configured in the BSC (which is not intended). Consequently, the BSC assumes, that the 'foreign TLLI' contains a NRI which is valid for routing to an SGSN.
For 'local TLLIs' and for 'foreign TLLIs' the BSC masks the NRI out of the TLLI. The BSC routes the uplink LLC frame to the relevant SGSN if an SGSN address is configured in the BSC for the specific NRI. The association between NRI values and SGSN addresses is configured in the BSC (O&M).
If no SGSN address is configured in the BSC for the requested NRI, which may happen for NRIs masked out of a 'foreign TLLI', or if the BSC received a 'random TLLI' which contains no NRI at all then the RNC routes the uplink LLC frame to an SGSN selected from the available SGSNs. The selection mechanism is implementation dependent and should enable load balancing between the available SGSNs. In some networks, the BSC may be configured to select the SGSN for "MSs configured for low access priority" with a different load balance to that used for SGSN selection for other MSs. In this case, until TLLI re-allocation occurs, the BSC shall remember which TLLIs are from "MSs configured for low access priority" and which are not.
As more than one SGSN may send downlink data at the same time for a cell or a BVCI, the BSC has to share the total possible downlink traffic between the SGSNs that can access a cell. The BSC should use the existing flow control procedure on cell level to control each of the SGSNs in a way not to violate the total possible traffic for the cell. How the BSC decides to share the downlink traffic between each of the SGSNs is an implementation specific issue; e.g. the possible downlink traffic can be equally shared between the SGSNs, or the share of each SGSN can be proportional to the capacity of the SGSN. In case a MSC sends a paging-request with IMSI via Gs-interface the SGSN has to add the MSC/VLR-identity to the paging-request message. The NAS node selection function in the BSC/RNC shall upon reception temporarily store the MSC/VLR-identity.
Up

5.3.3  Iu modeWord‑p. 18
To support MSs in Iu mode the BSC provides the same functionality as described under "RNC Functions".

5.3.4  Load Re-Distribution function in BSC |R6|

When the BSC receives a message with a 'null-NRI' it uses the NAS Node Selection Function for selecting a CN node where to forward the message. This is also done for all messages with 'random TLLIs' (Gb-mode). CN node(s) with re-distribution in progress should be excluded from the NAS Node Selection algorithm in the BSC. This is done by O&M configuration in the BSC.

5.4  MSC Functions

5.4.1  TMSI Allocation

Every MSC is configured with its one or more specific NRI (O&M). One of these specific NRIs is part of every temporary identity (TMSI) which the MSC assigns to an MS. The TMSI allocation mechanism in the MSC generates TMSIs which contain one of the specific NRIs in the relevant bit positions. An NRI has a flexible length between 10 and 0 bits (0 bits means the NRI is not used and the feature is not applied). The use of the bits not used to encode the NRI is implementation dependent (e.g. to extent the TMSI space). An MSC applying "Intra Domain Connection of RAN nodes to multiple CN nodes" shall allocate TMSIs to the served MSs.
Up

5.4.2  Mobility Management and Handover/Relocation

For MAP signalling between two MSCs which both support the Intra Domain Connection of RAN Nodes to Multiple CN Nodes the new MSC derives the address of the old MSC from the old LAI and the NRI contained in the old TMSI. The MSC addresses for each LAI and NRI combination are configured in the MSC (O&M). If the network contains MSCs that cannot derive the old MSC from LAI and NRI the default MSC per LAI as described below shall be used (e.g. to reduce the configuration effort). Some redundancy may be required as the default MSC is a single point of failure.
The load balancing between multiple target MSCs at handover/relocation into a pool area is described in "4.5 Load Balancing". The handover/relocation from an MSC that supports the Intra Domain Connection of RAN Nodes to Multiple CN Nodes to an MSC not supporting the feature needs no new functionality, as there is only one MSC that serves the handover/relocation target.
Up

5.4.3  Backward Compatibility and Default MSC

If a default MSC that is serving a pool-area receives MAP signalling (e.g. to fetch the IMSI or to get unused cipher parameters) it has to resolve the ambiguity of the multiple MSCs per LAI by deriving the NRI from the TMSI. The MSC relays the MAP signalling to the old MSC identified by the NRI in the old TMSI unless the default MSC itself is the old MSC. For every NRI value that is used in the pool-area an MSC address is configured in the default MSC (O&M).
Up

5.4.4  Support of Combined Procedures

If the SGSN does not support the Intra Domain Connection of RAN Nodes to Multiple CN Nodes then only one default out of the MSCs serving the related LA can be used for the combined procedures. A relaying or diverting from the default MSC to another is FFS. Distributing the associations of the combined procedures according to the LAs would result in MSC changes when the MS is still in the old MSC service area.

5.4.5  Load Re-Distribution function in MSC |R6|

The MSC needs to ensure that the RR-connection is released immediately after the Location Update response message is returned to the UE, i.e. the follow-on proceed flag shall be cleared.
For the special case when an MSC in a pool also serves a BSC or RNC that is not part of the pool (e.g. a BSC or RNC that does not support pool functionality), an MSC should not try to re-distribute UEs connected to that BSC or RNC.

5.5  SGSN FunctionsWord‑p. 19

5.5.1  P-TMSI Allocation

Every SGSN is configured with its specific one or more NRI (O&M). One of these specific NRIs is part of every temporary identity (P-TMSI) which the SGSN assigns to an MS. The P-TMSI allocation mechanism in the SGSN generates P-TMSIs which contain one of the specific NRIs in the relevant bit positions. An NRI has a flexible length between 10 and 0 bits (0 bits means the NRI is not used and the feature is not applied). The use of the bits not used to encode the NRI is implementation dependent (e.g. to extent the TMSI space). An SGSN applying "Intra Domain Connection of RAN nodes to multiple CN nodes" shall allocate P-TMSIs to the served MSs.
Up

5.5.2  Mobility Management and Handover/Relocation

For the GTP signalling between two SGSNs supporting the Intra Domain Connection of RAN Nodes to Multiple CN Nodes the new SGSN derives the address of the old SGSN from the old RAI and the NRI contained in the old P-TMSI/TLLI. The SGSN addresses are configured in the SGSN (O&M) or in DNS for each RAI and NRI combination. If the network contains SGSNs that cannot derive the old SGSN from RAI and NRI the default SGSN per RAI as described below shall be used (e.g. to reduce the configuration effort).
The load balancing between multiple target SGSNs at handover/relocation into a pool area is described in "4.5: Load Balancing". The handover/relocation from an SGSN that supports the Intra Domain Connection of RAN Nodes to Multiple CN Nodes to an SGSN not supporting the feature needs no new functionality, as there is only one SGSN that serves the handover/relocation target.
Up

5.5.3  Backward Compatibility and Default SGSN

If a default SGSN that is serving a pool-area receives GTP signalling (e.g. to fetch the IMSI or to get unused cipher parameters) it has to resolve the ambiguity of the multiple SGSNs per RAI by deriving the NRI from the P-TMSI. The SGSN relays the GTP signalling to the old SGSN identified by the NRI in the old P-TMSI unless the default SGSN itself is the old SGSN. For every NRI value that is used in the pool-area an SGSN address is configured in the relaying SGSN (O&M) or in DNS.
Up

5.5.4  Support of Combined Procedures

The SGSN has to select an MSC at the Gs interface for the combined procedures if multiple MSCs are configured for the relevant LAI. The MSC out of the available MSCs is selected based on the TMSI based NRI as provided by the UE or on the IMSI, and optionally, whether the "MS is configured for low access priority". Use of the TMSI based NRI as provided by the UE prevents an MSC change for UEs when UEs register first via normal procedures, and later by combined procedures. Use of the TMSI based NRI as provided by the UE or IMSI hash prevents an MSC change for many MSs if an SGSN fails and the re-attaching MSs would get assigned another MSC by the new SGSN. Two HLR updates instead of one would be the result.
From the LAI and the TMSI based NRI as provided by the UE, the SGSN can select a VLR from the available VLRs. The NRI length and the selected VLR per NRI value shall be the same as for the CN Node selection for the CS Domain in the RNC and BSC nodes.
From the IMSI the SGSN derives a value (V) using algorithm [(IMSI div 10) modulo 1000]. Every value (V) from the range 0 to 999 corresponds to a single MSC node. Typically many values of (V) may point to the same MSC node. The configuration of the MSC node should be the same in the same RNC area.
In some networks, the SGSN may be configured to select the MSC/VLR for "MSs configured for low access priority" with a different load balance to that used for MSC/VLR selection for other UEs. In this case the SGSN maintains a second set of tables of NRI to MSC mappings, and of value (V) to MSC mappings.
Up

5.5.5  CS PagingWord‑p. 20
If a CS paging is received via the Gs interface from MSC with mobile identity type IMSI then the SGSN should include the MSC/VLR-id in the paging / paging-request message to RNC/BSC.

5.5.6  Load Re-Distribution function in SGSN |R6|

On the Iu-ps interface the SGSN needs to ensure that the Iu-connection is released immediately after the Routing Area Update response message is returned to the UE, i.e. the follow-on flag shall be cleared.
On the Gb interface the SGSN needs to force the UE to standby after the Routing Area Update response message is returned to the UE, i.e. the force to standby indication shall be set. This ensures the Periodic Routing Area Update timer to start as quickly as possible.
For the special case when an SGSN in a pool also serves a BSC or RNC that is not part of the pool (e.g. a BSC or RNC that does not support pool functionality), an SGSN should not try to re-distribute UEs connected to that BSC or RNC.
Up


Up   Top   ToC