nRF9160 LTE Cat. M1 periodic search behavior

According to the AT command reference v1.7, the nRF9160 SIP modem firmware v1.3.1 added the %PERIODICSEARCHCONF command.

It does though not mention anything about the behavior of modem firmware v1.3.0 and earlier.

From my (limited) observations with modem firmware v1.2.0 hardware SICA B0A there is a 10sec search interval and after some timeout a 12min sleep.

Do you have detailed information about the search behavior? I'm especially interested in modem firmware v1.2.0 and v1.3.0.

Reason for my question: I'm using a multi-profile SIM card which rotates its profile to a new IMSI every 3min (while registration fails). This needs to be synchronized with the sleep pattern, because currently with modem firmware v1.2.0 the modem enters those 12min sleep intervals while the rotation of the SIM profile continues. Those SIM profiles active during the modem sleep are not used for attaching attempts.

Parents
  • Hi Matthias

    Håkon is currently out of office, so I have included the response from the LTE team below: 

    It is important to distinguish between search periods and Attach re-attempts. The search periods are used for periodically searching for suitable cells, and is used only when there is no suitable cell available. When a suitable cell has been found but Attach fails for some reason, the modem will do Attach re-attempts, and this functionality has been specified by 3GPP. 

    The "10, 10, 10, 10, 720" sequence is the one specified by 3GPP for Attach re-attempts, and there is no difference between releases for this matter. 

    There may be exceptions if the modem changes cell at some point in which case the next attempt may be done earlier. 

    Anyway, using %PERIODICSEARCHCONF (or anything else for that matter) does not have any effect on this because it is something the modem must obey. 

    Reason for my question: I'm using a multi-profile SIM card which rotates its profile to a new IMSI every 3min (while registration fails). This needs to be synchronized with the sleep pattern, because currently with modem firmware v1.2.0 the modem enters those 12min sleep intervals while the rotation of the SIM profile continues. Those SIM profiles active during the modem sleep are not used for attaching attempts.

    If IMSI changes during SIM refresh, the new Attach attempt should be possible immediately assuming that a suitable cell is found. So the problem described by the customer should not be possible. IF they think this really happens, we would need a modem log to confirm. 

    The same goes for the periodic searches: If the IMSI changes a new search is triggered immediately. So the described problem should not exist. 

    Best regards
    Torbjørn

Reply
  • Hi Matthias

    Håkon is currently out of office, so I have included the response from the LTE team below: 

    It is important to distinguish between search periods and Attach re-attempts. The search periods are used for periodically searching for suitable cells, and is used only when there is no suitable cell available. When a suitable cell has been found but Attach fails for some reason, the modem will do Attach re-attempts, and this functionality has been specified by 3GPP. 

    The "10, 10, 10, 10, 720" sequence is the one specified by 3GPP for Attach re-attempts, and there is no difference between releases for this matter. 

    There may be exceptions if the modem changes cell at some point in which case the next attempt may be done earlier. 

    Anyway, using %PERIODICSEARCHCONF (or anything else for that matter) does not have any effect on this because it is something the modem must obey. 

    Reason for my question: I'm using a multi-profile SIM card which rotates its profile to a new IMSI every 3min (while registration fails). This needs to be synchronized with the sleep pattern, because currently with modem firmware v1.2.0 the modem enters those 12min sleep intervals while the rotation of the SIM profile continues. Those SIM profiles active during the modem sleep are not used for attaching attempts.

    If IMSI changes during SIM refresh, the new Attach attempt should be possible immediately assuming that a suitable cell is found. So the problem described by the customer should not be possible. IF they think this really happens, we would need a modem log to confirm. 

    The same goes for the periodic searches: If the IMSI changes a new search is triggered immediately. So the described problem should not exist. 

    Best regards
    Torbjørn

Children
  • Hi Torbjørn

    Ok thanks. This means I'll need to check with our SIM card provider if he can check with you why a SIM refresh does not trigger a new Attach attempt.

    Regarding your reference to 3GPP, I assume this is about NAS configuration?
    In TS 24.301 V16.8.0 I found in section 5.5.1 Attach Procedure

    An attach attempt counter is used to limit the number of subsequently rejected attach attempts. The attach attempt counter shall be incremented as specified in subclause 5.5.1.2.6. Depending on the value of the attach attempt counter, specific actions shall be performed. The attach attempt counter shall be reset when:

    -     the UE is powered on;

    -     a USIM is inserted;

    -     an attach or combined attach procedure is successfully completed;

    In TS 24.368 V14.2.0 I found in section 5.10c <X>/SM_RetryWaitTime

    The SM_RetryWaitTime leaf indicates a configured UE retry wait time value applicable when in HPLMN or EHPLMN
    (see 3GPP TS 23.122 [3]) for controlling the UE session management retry behaviour when prior session management
    request was rejected by the network with cause value #8, #27, #32, #33 as specified in 3GPP TS 24.008 [4] and
    3GPP TS 24.301 [5].
    - Occurrence: ZeroOrOne
    - Format: int
    - Access Types: Get, Replace
    - Values: 0-255
    The default value of 12 minutes applies if this leaf is not provisioned.

    I'll confirm here as soon as I got details from the SIM card provider.

  • Hi Matthias,

    A completed SIM refresh should always trigger a new PLMN selection and Attach attempt. If record a modem trace we could confirm the actual behavior and see is there anything wrong.

Related