This document describes the problem and solutions related to random Temporary Logical Link Identifier (TLLI) collision issues on the Serving General Packet Radio Service (GPRS) Supporting Node (SGSN) in Cisco ASR 5000 Series Routers.
At the Logical Link Control (LLC) layer, SGSN aborts a processing attach request if it receives a subsequent attach request with the same fixed random TLLI that interprets the device to be the same for both requests. In SGSN reloads, when many devices try to attach simultaneously, only one of them (the last) successfully attaches to the network and the attach procedure is aborted by the SGSN for all previous devices. This results in a poor successful attach rate. The failed devices continue to attempt and eventually succeed after an unpredictable time delay. The devices present in the wireless network have software issues where all the devices from the same manufacturer attempt the Packet Switch (PS) attach with a fixed random TLLI.
As 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 23.003 explains, a random TLLI is built by a Mobile Station (MS) as follows:
bit 31 is set to 0
bits 30 down to 27 are set to 1
bits 0 to 26 are chosen randomly
Additionally, 3GPP TS 24.008 V 7.0 explains that if no valid Packet-Temporary Mobile Subscriber Identifier (P-TMSI) is available and when the MS has not stored a valid P-TMSI, the MS uses a randomly-selected random TLLI for transmission of the ATTACH REQUEST message of any combined/non-combined GPRS attach procedure.
The same randomly-selected random TLLI value is used for all message retransmission attempts and for the cell updates within one attach attempt. Upon receipt of an ATTACH REQUEST message, the network assigns a P-TMSI to the MS. The network derives a local TLLI from the assigned P-TMSI, and transmits the assigned P-TMSI to the MS.
Upon receipt of the assigned P-TMSI, the MS derives the local TLLI from this P-TMSI and uses it for addressing at lower layers.
Note: Although the MS derives a local TLLI for addressing at lower layers, the network should not assume that receive only LLC frames use a local TLLI. Immediately after the successful GPRS attach, the network must be prepared to continue to accept LLC frames from the MS that still uses the random TLLI.
Smartphones usually use P-TMSI allocated by SGSN in order to avoid any collisions. Random TLLI is released by SGSN only after the successful GPRS attach. Since modems, or nonstandards that do not work as per standards, attach with the same random TLLI, this results in the delay in successful attach whenever the other devices attempt to attach at the same time. A system reload has many more attach requests that come in from these modems/devices within a short window of time, but with a limited pool of fixed random TLLIs. Therefore, the chances of a collision are high.
These solutions are provided in order to address this issue:
Allow only one subscriber to attach with a fixed random TLLI at a time. While an attach procedure with a fixed random TLLI is continuous, (until a new P-TMSI is accepted by the MS), all other subsequent attaches that come with the same random TLLI with different International Mobile Subscriber Identifier (IMSI) are dropped at linkmgr. This drops the attach requests from a different MS with the same random TLLI irrespective of whether or not the TLLI is configured. This provides some solution of this issue but the attach success rate is very low because only one attach request among all attach requests with the same random TLLI can be processed by SGSN.
Additional checks of the Network Service Entity Identifier (NSEI) are also provided in order to process the attach requests. If different attach requests with the same random TLLI come from different NSEIs then all of these requests are processed at the same time. This increases the success rate of attach requests with the same random TLLI because now attach requests with the same random TLLI are processed simultaneously if they come from different NSEIs.
Allow a TLLI timer to receive the attach-complete with the old random TLLI. This timer stops once an uplink packet, such as an activation request, is received from the attached subscriber with the TLLI allocated by the SGSN. In case no uplink packet is received by the subscriber with the TLLI allocated by SGSN within the time (wait-time), the random TLLI that maps with that IMSI is freed and any other attach request with the same fixed random TLLI is accepted. No attach requests from the configured fixed-random TLLI are accepted until the timer is either stopped/expired. This timer (wait-time) is given as configurable with a range of 1 second to 125 seconds and a default value of 5 seconds. Also, in order to limit this wait-time functionality to only the fixed-random TLLI subscribers, configure the TLLI list with who needs to be catered with this functionality.
The impact of the fix is limited to only the subscribers with fixed random TLLI if the affected TLLI is configured in the TLLI list.
If the attached subscriber does not send any uplink packet within the wait-time and sends an uplink packet with the SGSN-allocated TLLI after the wait-time expiration, there is no impact.
If the subscriber does not send an uplink packet with TLLI allocated by the SGSN, then no other attach requests from the configured TLLI are honored for the configured time. This can cause a delay in overall attaches of all the devices that use fixed random TLLI. Normally, an activation request follows attach-complete for the Machine-to-Machine (M2M) devices. However, the situation is better than present where a single attach is delayed due to interference by other devices than the fixed-random TLLI.
If the attached subscriber comes back with an uplink packet with the fixed random TLLI after the expiration of the configured wait-time, this can lead to collision scenarios. This configuration in gprs-service increases the probability of the attached subscriber to use the TLLI provided by the SGSN immediately (within the wait-time).
"gmm information-in-messages access-type gprs"
New configuration commands are added under sgsn-global configuration mode in order to enable/disable the random TLLI.
This first configuration allows the SGSN to drop/discard the attach request received with the random TLLI which is already in use.
Enable/Disable the Attach Drops for an Existing TLLI
By default, the attach requests received are allowed to process with the TLLI which is already in use.
This configuration allows the SGSN to discard/drop the ATTACH-REQUEST message received with the random TLLI already in use. This configuration ensures at any point of time only one ATTACH is processed by the SGSN with the same random TLLI. When you enable this configuration, it drops the ATTACH-REQUEST message from the different MS with the use of the TLLI which already exists in the SGSN and used by another MS in order to attach. If the second attach comes from the same MS and same random TLLI which was used earlier to attach, it is allowed to process by SGSN with the addition of another check that uses NSEI.
[local]sim-lte#config [local]sim-lte(config)#sgsn-global [local]sim-lte(config-sgsn-global)#gmm-message attach-with-tlli-in-use - Specifies the action to be taken for the reception of ATTACH request with TLLI already in use. By default, SGSN process the ATTACH request [local]sim-lte(config-sgsn-global)#gmm-message attach-with-tlli-in-use discard-message - Enables the SGSN to discard the received GMM message [local]sim-lte(config-sgsn-global)#gmm-message attach-with-tlli-in-use discard-message only-on-same-nsei - Enables the SGSN to discard the received GMM message if same NSEI <cr> - newline [local]sim-lte(config-sgsn-global)#gmm-message attach-with-tlli-in-use discard-message [local]sim-lte(config-sgsn-global)#
The second part of this configuration allows the user to configure the list of random TLLI to be invalidated/removed from the GPRS mobility management (GMM) after the invalidated old TLLI timer (timer introduced as part of this fix) expires. The timer is also configurable in the range of 1 to 125 seconds.
Enable/Disable the Attach Drops for Existing TLLI with NSEI Check
This configuration allows you to have an additional check of the NSEI whenever any new attach request with the random TLLI value which is already in use arrives on the SGSN. This allows the SGSN to process multiple attach requests with the same random TLLI if they come from different NSEIs.
[local]sim-lte#config [local]sim-lte(config)#sgsn-global [local]sim-lte(config-sgsn-global)#gmm-message attach-with-tlli-in-use - Specifies the action to be taken for the reception of ATTACH request with TLLI already in use. By default, SGSN process the ATTACH request [local]sim-lte(config-sgsn-global)#gmm-message attach-with-tlli-in-use discard-message - Enables the SGSN to discard the received GMM message [local]sim-lte(config-sgsn-global)#gmm-message attach-with-tlli-in-use discard-message only-on-same-nsei - Enables the SGSN to discard the received GMM message if same NSEI <cr> - newline [local]sim-lte(config-sgsn-global)#gmm-message attach-with-tlli-in-use discard-message only-on-same-nsei <cr> - newline [local]sim-lte(config-sgsn-global)#gmm-message attach-with-tlli-in-use discard-message only-on-same-nsei [local]sim-lte(config-sgsn-global)#
The second part of this configuration allows the user to configure the list of random TLLI to be invalidated/removed from the GMM after the invalidated old TLLI timer (timer introduced as part of this fix) expires. The timer is also configurable in the range of 1 to 125 seconds.
Enable the TLLI Hold Timer
This output provides an example configuration:
#config #sgsn-global #gmm-message attach-with-tlli-in-use [discard-message] #old-tlli invalidate tlli 0x7C43128F ( Please identify more such TLLIs used by this modems) #old-tlli hold-time 2 (You can optimize the timer value based on the frequency of the attach from the same TLLI) #exit #end
Check for Drops
This CLI helps you identify whether the attach is getting dropped due to the random TLLI only if this configuration is enabled.
The first configuration works irrespective of the list of TLLIs configured to be invalidated with the gprs invalidate-old-tlli tlli [<value>] command.
If the highlighted counter in this CLI is more, then there is a random TLLI collision in the network. Try the CLI in normal mode if you are not able to see this. Then try in hidden mode which requires special user privileges.
IMSI Key : 14302 P-TMSI Key : 13205 attach with tlli in use: 7191
Add P-TMSI Key : 0
Mobile Id Len Error : 2 Unsupported Mobile Id : 0
IE Missing : 0 Other Decode Failure : 9344
ASR5000 Mechanism for an IMSI Attach with a Random TLLI
Generally, whenever the SGSN receives the IMSI attach request with a random TLLI, it processes the received attach request and creates an entry for that TLLI along with the IMSI and assigned session manager (SESSMGR) instance. The SESSMGR is assigned by the SGSN in order to serve this MS. After the successful creation of the entry, all further messages received from this MS (TLLI) are directly forwarded to that SESSMGR in order to process the same. At the entry level, SGSN is not able to identify the TLLI uniquely based on the Location Area Code (LAC)/Routing Area Code (RAC) as this was not assigned by the SGSN.
The SGSN processes the attach request for MS-1 and creates an entry for that TLLI along with the IMSI and assigned SESSMGR instance. If the SGSN receives another attach request from MS-2 using the same random TLLI (from different MS) the existing entry for that TLLI is overwritten with the IMSI of MS-2 along with the newly assigned SESSMGR instance for MS-2. This instance can be the same or a different SESSMGR instance. If the assigned SESSMGR instance is different for both MS-1 and MS-2, then additional messages received for MS-1 do not reach the correct SESSMGR.
Improvements and Suggestions
Devices present in the wireless network that have software issues with the TLLI or are hardcoded with the fixed TLLI and are from the same manufacturer attempt the PS attach with a fixed random TLLI. Fix this issue at the modem end in order to avoid attach collisions. Also create a list random TLLI frequently used by these modems and apply this fix in order to avoid the same scenario whenever the SGSN reboots.