A phone can hold two subscriptions while sharing some of the hardware needed to use them. If both networks require attention at the same time, UE may miss paging, interrupt a connection or need fewer radio resources on one subscription. Multi-USIM support helps UE communicate those conflicts to the network.

This note covers the Rel-17 baseline and Rel-18 enhancements. The related Paging note explains paging frames and occasions. Here the focus is how multiple subscriptions compete for device resources, how UE reports its preferences, and what the network can configure in response.

• Executive Summary
• Two subscriptions do not imply two independent radios
  • SIM, USIM, DSDS and DSDA
  • Network A and Network B
• Rel-17: Paging conflicts and paging controls
  • Paging timing collision control
  • Voice indication, rejection and restriction are different
• Rel-17: Leave the connection or request a gap ?
  • Connection release assistance
  • Scheduled gaps while remaining connected
• Rel-18: Temporary capability restriction
  • What can UE ask the network to change ?
  • Early indication and network coordination
• Rel-18: Gap priority and collision handling
  • Periodic gap priority and the keep preference
  • How to verify a conflict in a trace
• RRC parameters and selected ASN.1
  • Rel-17 assistance and gap configuration
  • Rel-18 assistance and capability restriction
• Reference

Executive Summary

Multi-USIM (MUSIM) procedures coordinate availability and capability. They do not combine subscription identities or guarantee that every device can transmit and receive on both subscriptions simultaneously.

Two subscriptions do not imply two independent radios

Each active subscription has its own network relationship and protocol state. The physical device may still share antennas, RF chains, processing resources or power limits. A subscription state and a hardware resource allocation are therefore different things.

SIM, USIM, DSDS and DSDA

Multi-SIM is the familiar device term, while the specifications use Multi-USIM for the subscription-related procedures discussed here. A removable card versus an embedded profile does not, by itself, determine whether the device has simultaneous radio capability.

Dual SIM Dual Standby (DSDS) commonly describes a device that keeps both subscriptions reachable in standby while sharing resources for active use. Dual SIM Dual Active (DSDA) describes simultaneous active operation. Actual transmit/receive combinations vary by implementation and band combination, so these labels are not substitutes for the supported radio capabilities.

Network A and Network B

The examples use Network A for the network receiving MUSIM assistance and Network B for the other subscription. The two networks need not be different operators. The resource conflict can exist even when both subscriptions use the same PLMN.

UE usually has the information needed to recognize its internal conflict. Network A does not automatically know Network B's paging schedule or the full device allocation. The MUSIM procedures let UE request an appropriate change without turning the two subscriptions into carrier aggregation or dual connectivity.

For example, A can be RRC_CONNECTED while B is RRC_IDLE and needs to monitor a paging occasion. Later both can be connected, but the MIMO or carrier resources available to A may decrease. These are different situations: the first may need a gap; the second may need a temporary capability restriction.

• Separate subscription state, simultaneous Tx/Rx support and available radio capability when interpreting a Multi-SIM device claim.

Rel-17: Paging conflicts and paging controls

A shared receiver may be unable to monitor two paging occasions that overlap. A separate issue arises when UE receives a page but cannot accept the service immediately. Rel-17 provides different mechanisms for timing conflicts, service awareness and paging response.

Paging timing collision control

UE can detect a potential paging collision when both subscriptions are idle or inactive. For a non-emergency registration, the 5GS approach allows a Mobility Registration Update to obtain a new 5G-GUTI. The changed identity can change the derived paging timing.

This uses a normal Registration procedure without a special collision indication and does not require the feature capability exchange used for the other NAS MUSIM features. UE still needs to evaluate the resulting paging timing. A newly allocated identity should not be described as a guarantee of a collision-free schedule forever.

Figure 1 illustrates the objective, not a particular paging formula or configured DRX cycle. Real paging timing depends on identity and cell configuration. See Paging for the PF/PO calculation; repeatedly requesting new identities also creates signalling load.

Figure 1. Paging collision control aims to separate monitoring opportunities for a resource-constrained device.

Voice indication, rejection and restriction are different

A voice-service indication helps UE recognize IMS voice paging when the feature is supported end to end. It is not a universal classification of every application. UE needs the appropriate RAN and core support before interpreting the indication or its absence.

UE and AMF exchange support for the relevant NAS features during registration. Operator policy can affect the accepted result. Paging Restriction acceptance must be checked in the response, and its removal rules matter when UE becomes available again. An RRC_INACTIVE UE can choose not to resume in the specified paging case; do not substitute the CM-IDLE rejection sequence for every inactive-state event.

• Distinguish a missed paging occasion, a received voice indication, an explicit rejection and an accepted paging restriction in a trace.

Rel-17: Leave the connection or request a gap ?

When Network B needs radio resources, UE can need either a short interruption or a longer absence from Network A. The network-facing procedures reflect that difference. A request to leave RRC_CONNECTED and a scheduling-gap preference are not equivalent messages.

Connection release assistance

When configured, UE can send an RRC preference to leave RRC_CONNECTED, including its preferred state. The network can respond with RRCRelease. A configured leave-without-response timer permits the specified local transition to RRC_IDLE if the response does not arrive in time.

The preferred state can be idle, inactive or simply outOfConnected. It is a preference rather than proof of the final state. A trace must show the network response or the applicable timer outcome. The RRC INACTIVE note explains the context retention difference between idle and inactive.

A NAS alternative uses the supported Connection Release feature with a Release Request Indication in Service Request or Registration Request. This path can carry Paging Restriction Information under the specified conditions. The RRC release-assistance path does not itself carry that NAS restriction. Emergency registration has separate restrictions and must not be treated as an ordinary MUSIM release case.

Scheduled gaps while remaining connected

For a temporary visit to Network B, UE can request MUSIM gaps while staying RRC_CONNECTED in A. The requested timing is assistance information. UE must distinguish that request from the actual gap configuration received from Network A.

The baseline supports up to three periodic gaps and one aperiodic gap. The network can provide requested patterns or no gaps; the described procedure does not support substituting an arbitrary alternative pattern for the requested one. Periodic gaps suit recurring activities, while the aperiodic gap provides a particular temporary opportunity.

Figure 2 illustrates a short visit. Remaining connected means that the RRC connection is retained; it does not mean that UE remains continuously available for ordinary communication with A during the configured gap. Transition and measurement requirements must fit the actual configured window.

Figure 2. A scheduling gap changes radio availability while preserving the connection to Network A.

• Choose the interpretation from the configured procedure: release changes connection state; a MUSIM gap temporarily changes availability.

Rel-18: Temporary capability restriction

Two active subscriptions can use separate transmit/receive paths while still sharing part of the hardware. Network A may therefore need to reduce the resources it configures when B becomes active. Rel-18 provides a way to report that temporary constraint and later remove it.

What can UE ask the network to change ?

After the network allows reporting, UE can send temporary capability-restriction assistance. It can identify already configured cells that need changes or describe affected and avoided bands or band combinations. This is a dynamic constraint, not a permanent rewrite of the device capability identity.

The UEAssistanceInformation report describes the constraint or preference. It is not itself an RRCReconfiguration from the network. For the applicable reactive procedure, a wait timer bounds the wait for a matching reconfiguration before the specified local capability change. Prohibit timers control report frequency; they serve a different purpose from that wait timer.

Early indication and network coordination

A device may already have reduced resources when it establishes or resumes the connection for the other subscription. If allowed in SIB1, UE can give an early restriction indication in the applicable RRC completion message, before detailed assistance is available.

Rel-18 stage-2 text includes RRCSetupComplete, RRCResumeComplete and RRCReestablishmentComplete for this indication. It tells the network that unrestricted capabilities may not currently be usable. It does not carry the complete affected-cell or band list; the detailed configured assistance procedure supplies that information.

Network A can be NR while B is NR or E-UTRA. When both are NR, UE implementation determines which network receives the temporary-restriction request. For the described NR/E-UTRA combination, the restriction request is made on the NR network. Master/secondary-node coordination is also relevant when the affected connection uses dual connectivity.

• Rel-18 restriction reporting lets a dual-active device describe its current resource limits; dual-active operation does not imply unrestricted capability on both subscriptions.

Rel-18: Gap priority and collision handling

A MUSIM gap can overlap a measurement gap or another MUSIM gap. Merely configuring every requested pattern does not explain what UE should do during the overlap. Rel-18 adds preference and configuration tools for those conflicts.

Periodic gap priority and the keep preference

When allowed, UE can indicate priorities for its periodic MUSIM gaps and a preference to keep colliding MUSIM gaps. The network configures the resulting behavior. A keep preference sent by UE is not equivalent to a keep indication granted by the network.

Without the applicable keep configuration, periodic MUSIM gap collisions use the defined priority handling, which can drop a lower-priority gap. Aperiodic MUSIM gap handling follows its own rules. The exact interaction with measurement gaps belongs to the RRM requirements; it should not be replaced by a blanket assumption that the newest gap always wins.

How to verify a conflict in a trace

Start with the state of each subscription and the exact time interval where the conflict occurs. Then collect the requested gap patterns, the configured patterns and their reference timing. A single subscription trace cannot always reveal the activity that caused the conflict.

For a paging issue, compare both PF/PO schedules and any identity change. For a connected-mode issue, check UEAssistanceInformation, RRC configuration, report-control timers and the gap-collision outcome. For reduced throughput, check whether temporary layer, bandwidth or carrier restrictions were actually applied before concluding that radio coverage degraded.

Capability support and network enablement are separate checks. NAS feature negotiation does not automatically enable all RRC MUSIM assistance, and an RRC gap configuration does not establish NAS paging restrictions. Use the UE Capability note, UE Assistance Information note and Paging note together when tracing the complete behavior.

• Compare requested behavior with accepted configuration, then apply the collision and timer rules for the specific procedure.

RRC parameters and selected ASN.1

The selected definitions below were checked against TS 38.331 v19.4.0. They retain the Rel-17 baseline and the Rel-18 extensions in the current syntax. Referenced types and message containers are not all expanded, so these listings are not complete RRC messages.

Rel-17 assistance and gap configuration

UE sends preferences through MUSIM assistance, while the network supplies gap configuration separately. The direction of signalling matters: a list in the assistance report describes what UE wants, and the configured list describes what the network has provided.

Following is based on 38.331 v19.4.0 (Release 19): MUSIM-Assistance-r17

MUSIM-Assistance-r17 ::=              SEQUENCE {
    musim-PreferredRRC-State-r17          ENUMERATED {idle, inactive, outOfConnected}     OPTIONAL,
    musim-GapPreferenceList-r17           MUSIM-GapPreferenceList-r17                     OPTIONAL
}

Following is based on 38.331 v19.4.0 (Release 19): MUSIM-GapConfig-r17

MUSIM-GapConfig-r17 ::=                  SEQUENCE {
    musim-GapToReleaseList-r17               SEQUENCE (SIZE (1..3)) OF MUSIM-GapId-r17               OPTIONAL, -- Need N
    musim-GapToAddModList-r17                SEQUENCE (SIZE (1..3)) OF MUSIM-Gap-r17                 OPTIONAL, -- Need N
    musim-AperiodicGap-r17                   MUSIM-GapInfo-r17                                       OPTIONAL, -- Need N
   ...,
    [[
    musim-GapToAddModListExt-v1820           SEQUENCE (SIZE (1..3)) OF MUSIM-GapExt-v1820            OPTIONAL, -- Need N
    musim-GapKeep-r18                        ENUMERATED {true}                                       OPTIONAL  -- Need N
    ]]
}

Following is based on 38.331 v19.4.0 (Release 19): MUSIM-LeaveAssistanceConfig-r17

MUSIM-LeaveAssistanceConfig-r17 ::=     SEQUENCE {
    musim-LeaveWithoutResponseTimer-r17     ENUMERATED {ms10, ms20, ms40, ms60, ms80, ms100, spare2, spare1}
}

The preferred RRC state is optional and does not force a matching RRCRelease. The leave-without-response timer has a specific role in the configured RRC procedure. Do not use it as a general timeout for NAS release, paging rejection or every temporary visit to Network B.

Rel-18 assistance and capability restriction

The Rel-18 assistance adds gap priorities, the keep preference and capability-related information. The capability-restriction configuration supplies reporting controls. Its wait timer and prohibit timer must be interpreted with the procedure rather than as interchangeable delays.

Following is based on 38.331 v19.4.0 (Release 19): MUSIM-Assistance-v1800

MUSIM-Assistance-v1800 ::=              SEQUENCE {
    musim-GapPriorityPreferenceList-r18     MUSIM-GapPriorityPreferenceList-r18           OPTIONAL,
    musim-GapKeepPreference-r18             ENUMERATED {true}                             OPTIONAL,
    musim-CapRestriction-r18                MUSIM-CapRestriction-r18                      OPTIONAL,
    musim-NeedForGapsInfoNR-r18             NeedForGapsInfoNR-r16                         OPTIONAL,
    ...
}

Following is based on 38.331 v19.4.0 (Release 19): MUSIM-CapRestriction-r18

MUSIM-CapRestriction-r18 ::=            SEQUENCE {
    musim-Cell-SCG-ToRelease-r18            MUSIM-Cell-SCG-ToRelease-r18                  OPTIONAL,
    musim-CellToAffectList-r18              MUSIM-CellToAffectList-r18                    OPTIONAL,
    musim-AffectedBandsList-r18             MUSIM-AffectedBandsList-r18                   OPTIONAL,
    musim-AvoidedBandsList-r18              MUSIM-AvoidedBandsList-r18                    OPTIONAL,
    musim-MaxCC-r18                         MUSIM-MaxCC-r18                               OPTIONAL
}

Following is based on 38.331 v19.4.0 (Release 19): MUSIM-CapabilityRestrictionConfig-r18

MUSIM-CapabilityRestrictionConfig-r18 ::= SEQUENCE {
    musim-CandidateBandList-r18               MUSIM-CandidateBandList-r18                                           OPTIONAL, -- Need R
    musim-WaitTimer-r18                       ENUMERATED {ms10, ms20, ms40, ms60, ms80, ms100, spare2, spare1},
    musim-ProhibitTimer-r18                   ENUMERATED {s0, s0dot1, s0dot2, s0dot3, s0dot4, s0dot5, s1, s2, s3, s4, s5, s6, s7, s8,
                                                          s9, s10}
}

The current MUSIM-GapConfig-r17 listing also contains the v1820 extension for gap priorities and the r18 keep field. The type name retains its r17 suffix because that type was introduced in Rel-17; it does not make every extension a Rel-17 feature. The preference lists in UE assistance and the network configuration must be checked separately.

NAS Release Request, Reject Paging and Paging Restriction information belong to NAS procedures rather than these RRC ASN.1 types. Their stage-2 behavior is covered in TS 23.501 section 5.38. No synthetic captured signalling is shown here, and the illustrative diagrams are not actual device logs.

• Separate baseline fields, release extensions, reporting controls and actual network configuration when decoding MUSIM signalling.

Reference

The Multi-USIM architecture and procedure clauses and selected RRC definitions were reviewed. The references support the specific Rel-17/18 discussion; this is not a claim that every clause of each specification was read.

• TS 23.501 v17.9.0: Section 5.38: feature negotiation, connection release, voice paging, rejection, restrictions and collision control.
• TS 38.300 v17.10.0: Section 20: Rel-17 Multi-USIM support and network-switching assistance.
• TS 38.300 v18.6.0: Section 20: gap preferences and temporary capability restriction.
• TS 38.331 v19.4.0: MUSIM assistance, gap configuration and reporting-control definitions.
• TR 21.918 v18.0.0: Section 23.1.7, Dual Transmission Reception Multi-SIM for NR.