A UE with a data connection but no data to send still holds radio resources and spends battery. Who decides when that UE may leave the connected state? In UMTS the answer used to be only the network, and Fast Dormancy is the way the UE asks for it.

If you have any experience on UMTS protocol, you may have noticed two properties as listed below.

• Property 1 : RRC Connection Request (RRC Session) is always initiated by UE
• Property 2 : RRC Release (or RRC State Change) is always initiated by Network.

Of course, this property would impose a lot of restriction for normal operations. So they introduced some additional mechanism to compensate this property.

The compensation mechanism for Property 1 is Paging. With Paging, Network can trigger UE to initiate RRC Connection Request. This compensation mechanism has been provided since day 1 of UMTS deployment. However, it has not been long since we got the compensation mechanism for Property 2. What is the compensation mechanism for property 2 ? It is SCRI (Signaling Connection Release Indicator) message. SCRI is a mechanism for UE to tell Network to initiate RRC Release. and this SCRI is the key component of 'Fast Dormancy'.

In 25.331 the message is SIGNALLING CONNECTION RELEASE INDICATION, and the industry shortens it to SCRI. This page explains why a UE wants to end its RRC connection early, and then compares the conventional flow with the Release 8 flow. The last section shows the ASN.1 that tells the two flows apart.

• What is Fast Dormancy and why is it needed ?
• Conventional Fast Dormancy
• Release 8 Fast Dormancy
• SCRI and T323 in the current 25.331
• Reference

What is Fast Dormancy and why is it needed ?

Before looking at the message flows, let's be clear about what Fast Dormancy keeps and what it releases. It releases the radio resources, but it keeps the PDP context. The questions below build that answer step by step.

Then what is 'Fast Dormancy' ?

Simply put, it is a mechanism for UE to let Network initiate RRC Release without tearing down existing PDP Context.

What is the motivation for this ?

Major motivation is to reduce the signaling time to recover the data connection which has been established before.

How this kind of Fast Dormancy can reduce the signaling time for recover the data connection ?

Normally it would take much longer time to go through NAS layer signaling and IP related bearer setup comparing to RRC layer signaling. So if you have to tear down everything (RRC + NAS) when you release and reestablish everything (RRC + NAS) when you recover the connection, it would take long time. But if you just tear down RRC  layer with keeping NAS layer (PDP) as it is, you can recover PDP connection much faster when you need.

Then why do they want to reduce the signaling traffic time ? What is the motivation for this ?

There can be different motivation for Network and UE side.

The Network side motivation may be

i) reduce network overhead for exchanging signaling message with UE

ii) tearing down unused 'RRC Session' mean it can recall unused Channelisation code (OVSF code) and allocate it for another UE.

UE side motivation may be

i) it can reduce energy consumption by getting into idle or dormant mode when there is no data transaction.

It has been several years since this Fast Dormancy started being used (meaning it is not brand new. It has been used since R99 period), but lately (in Release 8) this mechanism has been improved even further.

The second motivation of the UE is the most important one in practice. A smartphone sends small, frequent packets, such as keep-alive messages. Without Fast Dormancy, each packet keeps the UE in CELL_DCH or CELL_FACH until a network inactivity timer expires, and those timers are often several seconds long. The UE spends that time transmitting and receiving nothing, but its radio is still on. So a UE with Fast Dormancy sends SCRI as soon as its applications have nothing more to send.

• Fast Dormancy releases RRC, not NAS : the PDP context stays, so the next data session starts faster.
• Network benefit : radio resources and codes are freed for other UEs.
• UE benefit : the UE reaches a battery efficient state without waiting for the network timers.

Conventional Fast Dormancy

Following is the general signal flow for Fast Dormancy that has been used since R99. (According to GSMA Fast Dormancy Best Practice document, this method is called "Autonomous Signaling Connection Release", but as far as I recall we called this Fast Dormancy in the industry from the beginning)

The key point is step 4. The UE sends SCRI without the cause IE, which means that the UE asks the network to release the PS signalling connection. 25.331 clause 8.1.14.3 says the UTRAN then requests the release of the signalling connection from upper layers. The UE also removes the signalling connection from its list of established connections. So the only choice left to the network is RRC Connection Release, and the UE ends up in idle mode.

This flow saves battery, but it has a cost on the network side. The next data packet needs a new RRC Connection Request, a new security setup and new radio bearers. When many UEs do this every few seconds, the RNC and the core network see a large increase in signalling. That problem is what Release 8 set out to fix.

• SCRI without a cause : the network can only release the RRC connection.
• UE goes to idle mode : the PDP context stays, but the RRC connection is gone.
• Signalling load : every new packet needs a full RRC connection setup.

Release 8 Fast Dormancy

Following is the general signal flow for Fast Dormancy that has been improved in Release 8. (Even though the concept is officially introduced in Release 8, the term 'Fast Dormany' is not a official 3GPP term. It is the term used by the organization (Research In Motion Limited, AT&T, Huawei, Vodafone, NTT DOCOMO) who suggested the concept in RAN2. But again this terminology is more widely used in industry and GSMA is using this term in some of documents linked below).

According to GSMA Fast Dormancy Best Practice Document,

If timer T323 is broadcase in System Information Block type1, it means that the network supports this Rel-8 mechanism. This timer can take values : (0,5,10,20,30,60,90,120) seconds. The use of 0 secs indicates no need to apply the inhibit timer. Inhibit timer is started after a FD(Fast Dormancy) Request is sent, and until the timer is elapsed, UE can't send any further FD Request. If T323 = 120, the UE can't send any FD request before 2 minutes after a transmission ends or the transmission of a previous FD request.

The SIB1 below comes from a live cell. T323 sits in the v860 extension of SIB1, inside ue-ConnTimersAndConstants, and it is set to s30.

SIB1 carrying T323 = 30 s. The cell supports the Release 8 mechanism, and a UE waits 30 seconds between two requests with the new cause.

• ue-IdleTimersAndConstants : t-300 ms100, n-300 0, t-312 0 and n-312 s1, from the original SIB1.
• v3a0NonCriticalExtensions : the Release 99 extension with n-312 and n-315.
• v860NonCriticalExtentions : sysInfoType1-v860ext with t-323 = s30, highlighted. The field name keeps the spelling of the ASN.1.

The new element is the cause value. With cause UE Requested PS Data session end, the UE no longer asks for a release. It only tells the network that it has no more PS data for a prolonged period. 25.331 clause 8.1.14.3 then lets the UTRAN choose a battery efficient RRC state: IDLE, CELL_PCH, URA_PCH or CELL_FACH. Option 2 in the table above is the common choice, because a move to CELL_PCH or URA_PCH keeps the RRC connection and avoids a new connection setup.

The UE may use this cause only when the network has broadcast T323, and only when no CS domain connection exists. The UE also must not release the PS signalling connection locally after it sends the request. While T323 runs, the UE is inhibited from sending another SCRI with this cause. That is why step 6 in the table waits for T323 to expire.

One more limit was added later. If the UE is already in CELL_PCH or URA_PCH with a long DRX cycle, a further request saves little battery. So 25.331 uses the counter V316 to limit such requests, and the UE resets it when PS data is sent or received.

• Cause UE Requested PS Data session end : the network chooses the target state, and it can keep the RRC connection.
• T323 in SIB1 : the network announces that it supports the Release 8 mechanism.
• T323 is an inhibit timer : no second request with this cause until it expires.
• No CS call : the Release 8 request applies only when there is no CS domain connection.

SCRI and T323 in the current 25.331

How does the network tell the two flows apart on the air interface? It reads one optional extension of the same message. The tile below shows the message, the v860 extension with the cause, and the SIB1 structures that carry T323.

Following is based on 25.331 v19.0.1 (Release 19)

SignallingConnectionReleaseIndication ::= SEQUENCE {
    -- Core network IEs
        cn-DomainIdentity               CN-DomainIdentity,
        laterNonCriticalExtensions      SEQUENCE {
            -- Container for additional R99 extensions
            signallingConnectionReleaseIndication-r3-add-ext        BIT STRING      OPTIONAL,
            v860nonCriticalExtentions       SEQUENCE {
                signallingConnectionReleaseIndication-v860ext
                                                SignallingConnectionReleaseIndication-v860ext,
                nonCriticalExtensions           SEQUENCE {}     OPTIONAL
            }   OPTIONAL
        }   OPTIONAL
}

SignallingConnectionReleaseIndication-v860ext ::= SEQUENCE {
        signallingConnectionReleaseIndicationCause
                                        ENUMERATED { uERequestedPSDataSessionEnd, anyOtherCause }
}

SysInfoType1 ::=                    SEQUENCE {
    -- Core network IEs
        cn-CommonGSM-MAP-NAS-SysInfo    NAS-SystemInformationGSM-MAP,
        cn-DomainSysInfoList            CN-DomainSysInfoList,
    -- User equipment IEs
        ue-ConnTimersAndConstants       UE-ConnTimersAndConstants           OPTIONAL,
        ue-IdleTimersAndConstants       UE-IdleTimersAndConstants           OPTIONAL,
    -- Extension mechanism for non- release99 information
        v3a0NonCriticalExtensions       SEQUENCE {
            sysInfoType1-v3a0ext            SysInfoType1-v3a0ext-IEs,
            v860NonCriticalExtentions       SEQUENCE {
                sysInfoType1-v860ext            SysInfoType1-v860ext-IEs,
                nonCriticalExtensions           SEQUENCE {} OPTIONAL
            }                           OPTIONAL
        }                           OPTIONAL
}

SysInfoType1-v860ext-IEs ::=    SEQUENCE {
    ue-ConnTimersAndConstants               UE-ConnTimersAndConstants-v860ext
}

UE-ConnTimersAndConstants-v860ext ::=   SEQUENCE {
    t-323                                       T-323                       OPTIONAL
}

T-323 ::=                           ENUMERATED { s0, s5, s10, s20, s30, s60, s90, s120 }

The cause sits in the v860 non-critical extension, so a Release 7 UE simply does not include it. The network then treats the message as the conventional request. The value anyOtherCause behaves the same way as an absent cause. T323 is ENUMERATED from s0 to s120, the eight values quoted from the GSMA document above. Later releases copy t-323 into UE-ConnTimersAndConstants-r11, which is why it also appears in the Release 11 structure.

• Absent cause or anyOtherCause : the conventional flow, which ends in RRC Connection Release.
• uERequestedPSDataSessionEnd : the Release 8 flow, where the network chooses the state.
• SysInfoType1-v860ext-IEs : carries T323, and its presence enables the Release 8 flow.

Reference

http://www.slideshare.net/zahidtg/gsma-fast-dormancy-best-practices

[1] 3GPP TS 25.331 v19.0.1 - clause 8.1.14 Signalling connection release indication procedure, and the ASN.1 of SignallingConnectionReleaseIndication, SysInfoType1-v860ext-IEs and T-323