8.6.3 UE information elements

25.3313GPPProtocol specificationRadio Resource Control (RRC)Release 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

8.6.3.1 Activation time

If the UE receives a message in which presence is needed for the IE "Activation time", and the value is other than the default value "Now", or if the variable DETERMINED_ACTIVATION_TIME is set, the UE shall:

1> let the "reference CCTrCH" be defined as the CCTrCh that includes any transport channel or is associated with any physical channel which is being added, re-configured or removed, or, in the case of HS-DSCH, the CCTrCh including the associated DCH;

1> if the frame boundary immediately before the frame with the CFN (Connection Frame Number) value indicated by the IE "Activation Time" or the variable DETERMINED_ACTIVATION_TIME is at the TTI boundary common to all the transport channels that are multiplexed onto the reference CCTrCh:

2> select that frame boundary as the activation time T.

1> else:

2> select the next TTI boundary, which is common to all the transport channels that are multiplexed onto the reference CCTrCh, after the frame with the CFN (Connection Frame Number) value indicated by the IE "Activation Time" or by the variable DETERMINED_ACTIVATION_TIME, as the activation time T.

1> if the IE "Delay restriction flag" is received and activation time T is more than 128 frames from the CFN at which the message was received:

2> choose an activation time T as soon as possible after reception of the message, respecting the performance requirements in subclause 13.5, which is common to all the transport channels that are multiplexed onto the reference CCTrCh.

NOTE: If the UE receives a message containing the IE "Delay restriction flag" and that message causes a transport channel or physical channel reconfiguration of the reference CCTrCH then the UE behaviour is not specified.

1> at the activation time T:

2> for a physical channel reconfiguration other than an HS-DSCH related reconfiguration, caused by the received message:

3> release the physical channel configuration, which was present before T;

3> initiate the establishment of the physical channel configuration as specified for the physical channel information elements in the received message as specified elsewhere.

2> for an HS-DSCH related reconfiguration in FDD or 1.28 Mcps TDD caused by the received message:

3> select the HS-SCCH subframe boundary immediately before the first HS-SCCH subframe, which entirely falls within the 10 ms frame following T;

3> start using, at that HS-SCCH subframe boundary, the new HS-DSCH configuration in the received message, replacing any old HS-DSCH configuration.

2> for an HS-DSCH related reconfiguration in 3.84 Mcps TDD or 7.68 Mcps TDD caused by the received message:

3> start using, at activation time T, the new HS-DSCH configuration in the received message, replacing any old HS-DSCH configuration.

2> for actions, other than a physical channel reconfiguration, caused by the received message:

3> perform the actions for the information elements in the received message as specified elsewhere.

2> clear the variable DETERMINED_ACTIVATION_TIME.

NOTE: In FDD an "HS-DSCH related reconfiguration" includes, in particular, reconfigurations that need to be time-aligned with the 2ms subframe of the HS-SCCH, HS-PDSCH and/or HS-DPCCH. For example, start and stop of HS-SCCH reception and serving HS-DSCH cell change.

If the UE receives a message in which presence is needed for the IE "Activation time", and the value is the default value "Now", the UE shall:

1> if the IE "Dynamic activation time" is received:

2> choose the value of the variable DETERMINED_ACTIVATION_TIME as the activation time T and acts as if the IE "Activation Time" had never been received.

1> else:

2> choose an activation time T as soon as possible after the reception of the message, respecting the performance requirements in subclause 13.5;

1> at the activation time T:

2> perform the actions for the information elements in the received message as specified elsewhere.

2> clear the variable DETERMINED_ACTIVATION_TIME.

NOTE: In FDD, if the UE was in idle mode or CELL_FACH or CELL_PCH state upon reception of the message, regardless of the state the UE enters after reception of the message, and the value of the IE "Activation time" in the received message is different from "Now", the UE behaviour is unspecified. In TDD, if the UE was in idle mode or CELL_FACH state upon reception of the message, the value of the IE "Activation time" in the received message is relative to the CFN associated with the cell from which the message was received.

8.6.3.1a CN domain specific DRX cycle length coefficient

The UE updates CN domain specific DRX cycle length coefficient as specified in [4]. The UE shall use it to calculate the CN domain specific DRX cycle length, according to the following:

1> set k to the value of the IE "CN domain specific DRX cycle length coefficient".

1> store the result of MAX(2k, PBP), where PBP is the Paging Block Periodicity, as the CN domain specific DRX cycle length for the CN domain indicated by the IE "CN domain identity". For FDD PBP=1.

The UE shall determine its idle mode paging occasions and PICH monitoring occasions for that CN domain, according to [4], based on the stored CN domain specific DRX cycle length, when using DRX in idle mode.

8.6.3.1b H-RNTI

If an IE "New H-RNTI" is included and the UE will be in CELL_DCH state after completion of this procedure, the UE shall:

1> if the IE "New H-RNTI" is received in a UTRAN MOBILITY INFORMATION message

2> the UE behaviour is unspecified.

1> store the value in the variable H_RNTI;

1> determine the value for the HS_DSCH_RECEPTION variable and take the corresponding actions as described in subclause 8.5.25;

1> determine the value for the SECONDARY_CELL_HS_DSCH_RECEPTION variable and take the corresponding actions as described in subclause 8.5.51.

If the message that triggers the HS_DSCH_RECEPTION variable to change value from FALSE to TRUE does not contain the IE "New H-RNTI"; and

if, before receiving that message, the UE is not in CELL_FACH or CELL_PCH state or the variable H_RNTI is not set:

1> the UE behaviour is not defined.

When the variable HS_DSCH_RECEPTION is set to TRUE the UE shall:

1> use the value of the variable H_RNTI as UE identity in the HS-SCCH reception procedure in the physical layer.

In FDD and 1.28 Mcps TDD, if the IE "New H-RNTI" is included and the UE will be in CELL_FACH state after completion of this procedure, the UE shall:

1> store the value in the variable H_RNTI;

1> determine the value for the HS_DSCH_RECEPTION_CELL_FACH_STATE variable and take the corresponding actions as described in subclause 8.5.36.

1> for 1.28 Mcps TDD, If the IE "Treset Usage Indicator" has been stored:

2> stop using all configured Treset timer [15].

When the variable HS_DSCH_RECEPTION_CELL_FACH_STATE is set to TRUE the UE shall:

1> use the value of the variable H_RNTI as UE identity in the HS-SCCH reception procedure in the physical layer.

When an entry in the variable SECONDARY_CELL_HS_DSCH_RECEPTION is set to TRUE the UE shall:

1> use the value of the variable H_RNTI associated with the corresponding secondary serving HS-DSCH cell as UE identity in the HS-SCCH reception procedure in the physical layer on that cell.

In FDD and 1.28 Mcps TDD, if the IE "New H-RNTI" is included and the UE will be in CELL_PCH or URA_PCH state after completion of this procedure, the UE shall:

1> store the value in the variable H_RNTI.

1> for 1.28 Mcps TDD, If the IE "Treset Usage Indicator" has been stored:

2> stop using all configured Treset timer [15].

8.6.3.2 UTRAN DRX Cycle length coefficient

If the IE "UTRAN DRX cycle length coefficient" is present, the UE shall use it to calculate the UTRAN DRX cycle length, according to the following:

1> start timer T319 using the IE "Time for DRX cycle 2" value;

1> store IE "DRX cycle length coefficient";

1> set k to the value of the IE "DRX cycle length coefficient 2";

1> store the result of MAX(2^k,PBP), where PBP is the Paging Block Periodicity, as the DRX cycle length.

The UE shall determine its connected mode paging occasions and PICH monitoring occasions in the same way as for idle mode, according to [4].

The DRX cycle length to use in connected mode is defined in [4].

8.6.3.3 Generic state transition rules depending on received information elements

The IE "RRC State Indicator" indicates the state the UE shall enter. The UE shall enter the state indicated by the IE "RRC State Indicator" even if the received message includes other IEs relevant only for states other than indicated by the IE "RRC State Indicator". E.g. if the RRC state indicator is set to CELL_FACH while other IEs provide information about a configuration including dedicated channels, the UE shall enter CELL_FACH state. If however the UE has no information about the configuration corresponding to the state indicated by the IE "RRC State Indicator", it shall consider the requested configuration as invalid.

The UE shall, if the IE "RRC State Indicator" in the received message has the value:

1> "CELL_FACH":

2> enter CELL_FACH state as dictated by the procedure governing the message received.

1> "CELL_DCH":

2> if neither DPCH is assigned in the message nor is the UE in CELL_DCH:

3> set the variable INVALID_CONFIGURATION to TRUE.

2> else:

3> enter CELL_DCH state as dictated by the procedure governing the message received.

1> "CELL_PCH":

2> if the received message is RRC CONNECTION SETUP and IE "RRC State Indicator" is set to CELL_PCH:

3> set the variable INVALID_CONFIGURATION to TRUE.

2> else:

3> enter CELL_PCH state as dictated by the procedure governing the message received.

1> "URA_PCH":

2> if the received message is RRC CONNECTION SETUP and IE "RRC State Indicator" is set to URA_PCH:

3> set the variable INVALID_CONFIGURATION to TRUE.

2> else:

3> enter URA_PCH state as dictated by the procedure governing the message received.

8.6.3.4 Ciphering mode info

The IE "Ciphering mode info" defines the new ciphering configuration. At any given time, the UE needs to store at most two different ciphering configurations (keyset and algorithm) per CN domain at any given time in total for all radio bearers and three configurations in total for all signalling radio bearers.

If the IE "Ciphering mode info" is present and if the IE "Reconfiguration" in the variable CIPHERING_STATUS is set to TRUE, the UE shall:

1> ignore this second attempt to change the ciphering configuration; and

1> set the variable INCOMPATIBLE_SECURITY_RECONFIGURATION to TRUE.

If the IE "Ciphering mode info" is present and if the IE "Reconfiguration" in the variable CIPHERING_STATUS is set to FALSE, the UE shall:

1> if none of the IE "Status" in the variable CIPHERING STATUS has the value "Started", and this IE "Ciphering mode info" was included in a message that is not the message SECURITY MODE COMMAND or this IE "Ciphering mode info" was included in a message that doesn’t include the IE "SR-VCC Info"; or

1> if the IE "Ciphering Mode Info" was received in the message SECURITY MODE COMMAND and there does not exist exactly one ciphering activation time in the IE "Radio bearer downlink ciphering activation time info" for each established RLC-AM and RLC-UM radio bearers included in the IE "RB information" in the IE "ESTABLISHED_RABS" for the CN domain as indicated in the variable LATEST_CONFIGURED_CN_DOMAIN; or

1> if the IE "Ciphering Mode Info" was received in the message SECURITY MODE COMMAND and the IE "Ciphering activation time for DPCH" is not included in the message, and there exist radio bearers using RLC-TM according to the IE "RB information" in the IE "ESTABLISHED_RABS" for the CN domain as indicated in the variable LATEST_CONFIGURED_CN_DOMAIN; or

1> if the IE "Ciphering Mode Info" was received in the message SECURITY MODE COMMAND and there does not exist exactly one ciphering activation time in the IE "Radio bearer downlink ciphering activation time info" for each established signalling radio bearer included in the IE "Signalling radio bearer information" in the IE "ESTABLISHED_RABS":

2> ignore this attempt to change the ciphering configuration;

2> set the variable INVALID_CONFIGURATION to TRUE;

2> perform the actions as specified in subclause 8.1.12.4c.

1> set the IE "Reconfiguration" in the variable CIPHERING_STATUS to TRUE;

1> set the IE "Status" in the variable CIPHERING_STATUS of the CN domains for which the IE "Status" of the variable SECURITY_MODIFICATION is set to "Affected" to "Started";

1> apply the new ciphering configuration in the lower layers for all RBs that belong to a CN domain for which the IE "Status" of the variable SECURITY_MODIFICATION is set to "Affected" and all signalling radio bearers:

2> using the ciphering algorithm (UEA [40]) indicated by the IE "Ciphering algorithm" as part of the new ciphering configuration;

2> for each radio bearer that belongs to a CN domain for which the IE "Status" of the variable SECURITY_MODIFICATION is set to "Affected" and all signalling radio bearers:

3> using the value of the IE "RB identity" in the variable ESTABLISHED_RABS minus one as the value of BEARER [40] in the ciphering algorithm.

1> for the downlink and the uplink, apply the new ciphering configuration as follows:

2> if the ciphering configuration for a AM or UM radio bearer or signalling radio bearer from a previously received SECURITY MODE COMMAND has not yet been applied because of the corresponding activation times not having been reached and the current received message includes the IE "DL Counter Synch Info" or the current received message is a RADIO BEARER RECONFIGURATION message and includes the IE "New U-RNTI":

3> if the previous SECURITY MODE COMMAND was received due to new keys being received:

4> consider the new ciphering configuration to include the received new keys.

3> else if the previous SECURITY MODE COMMAND caused a change in LATEST_CONFIGURED_CN_DOMAIN:

4> consider the new ciphering configuration to include the keys associated with the LATEST_CONFIGURED_CN_DOMAIN.

3> apply the new ciphering configuration in uplink and downlink immediately following RLC re-establishment.

2> if the IE "Ciphering activation time for DPCH" is present in the IE "Ciphering mode info" and the UE was in CELL_DCH state prior to this procedure:

3> for radio bearers using RLC-TM:

4> apply the old ciphering configuration for CFN less than the number indicated in the IE "Ciphering activation time for DPCH";

4> apply the new ciphering configuration for CFN greater than or equal to the number indicated in IE "Ciphering activation time for DPCH".

2> if the IE "Radio bearer downlink ciphering activation time info" is present:

3> apply the following procedure for each radio bearer and signalling radio bearers using RLC-AM or RLC-UM indicated by the IE "RB identity":

4> suspend uplink transmission on the radio bearer or the signalling radio bearer (except for the SRB where the response message is transmitted) according to the following:

5> do not transmit RLC PDUs with sequence number greater than or equal to the uplink activation time, where the uplink activation time is selected according to the rules below.

4> select an "RLC sequence number" at which (activation) time the new ciphering configuration shall be applied in uplink for that radio bearer according to the following:

5> consider a ciphering activation time in uplink to be pending until the RLC sequence number of the next RLC PDU to be transmitted for the first time is equal to or larger than the selected activation time;

5> for each radio bearer and signalling radio bearer that has no pending ciphering activation time in uplink as set by a previous procedure changing the security configuration:

6> set a suitable value that would ensure a minimised delay in the change to the latest ciphering configuration.

5> for each radio bearer and signalling radio bearer that has a pending ciphering activation time in uplink as set by a previous procedure changing the security configuration:

6> for radio bearers and signalling radio bearers except SRB2:

7> set the same value as the pending ciphering activation time.

6> for signalling radio bearer SRB2:

7> set a suitable value that would ensure a minimised delay in the change to the latest ciphering configuration.

4> store the selected "RLC sequence number" for that radio bearer in the entry for the radio bearer in the variable RB_UPLINK_CIPHERING_ACTIVATION_TIME_INFO;

4> switch to the new ciphering configuration according to the following:

5> use the old ciphering configuration for the transmitted and received RLC PDUs with RLC sequence numbers smaller than the corresponding RLC sequence numbers indicated in the IE "Radio bearer uplink ciphering activation time info" sent to UTRAN and in the received IE "Radio bearer downlink ciphering activation time info" received from UTRAN, respectively;

5> use the new ciphering configuration for the transmitted and received RLC PDUs with RLC sequence numbers greater than or equal to the corresponding RLC sequence numbers indicated in the IE "Radio bearer uplink ciphering activation time info" sent to UTRAN and in the received IE "Radio bearer downlink ciphering activation time info" received from UTRAN, respectively;

5> for a radio bearer using RLC-AM, when the RLC sequence number indicated in the IE "Radio bearer downlink ciphering activation time info" falls below the RLC receiving window and the RLC sequence number indicated in the IE "Radio bearer uplink ciphering activation time info" falls below the RLC transmission window, the UE may release the old ciphering configuration for that radio bearer;

5> if an RLC reset or re-establishment of the transmitting side of an RLC entity occurs before the activation time for the new ciphering configuration has been reached in uplink, ignore the activation time and apply the new ciphering configuration in uplink immediately after the RLC reset or RLC re-establishment;

5> if an RLC reset or re-establishment of the receiving side of an RLC entity occurs before the activation time for the new ciphering configuration has been reached in downlink, ignore the activation time and apply the new ciphering configuration in downlink immediately after the RLC reset or RLC re-establishment.

2> if the current received message includes the IE "Downlink counter synchronisation info" or the current received message is a RADIO BEARER RECONFIGURATION message and includes the IE "New U-RNTI"; or

2> if the current received message includes the IE "SR-VCC Info":

3> apply the new ciphering configuration in uplink and downlink immediately following RLC re-establishment.

If the IE "Radio bearer downlink ciphering activation time info" was received in another message than SECURITY MODE COMMAND:

1> the UE behaviour is unspecified.

If the IE "Ciphering mode info" is not present, the UE shall:

1> for the downlink and the uplink, apply the ciphering configuration as follows:

2> if the ciphering configuration for a AM or UM radio bearer or signalling radio bearer from a previously received SECURITY MODE COMMAND has not yet been applied because of the corresponding activation times not having been reached and the current received message includes the IE "Downlink counter synchronisation info" or the current received message is a RADIO BEARER RECONFIGURATION message and includes the IE "New U-RNTI" or the current received message triggering SR-VCC:

3> if the previous SECURITY MODE COMMAND was received due to new keys being received:

4> consider the ciphering configuration to include the received new keys.

3> else if the previous SECURITY MODE COMMAND caused a change in LATEST_CONFIGURED_CN_DOMAIN:

4> consider the ciphering configuration to include the keys associated with the LATEST_CONFIGURED_CN_DOMAIN.

3> apply the ciphering configuration in uplink and downlink immediately following RLC re-establishment.

2> else:

3> not change the ciphering configuration.

8.6.3.5 Integrity protection mode info

The IE "Integrity protection mode info" defines the new integrity protection configuration. At any given time, the UE needs to store at most three different integrity protection configurations (keysets) in total for all signalling radio bearers for all CN domains.

If the IE "Integrity protection mode info" is present and if the IE "Reconfiguration" in the variable INTEGRITY_PROTECTION_INFO is set to TRUE, the UE shall:

1> ignore this second attempt to change the integrity protection configuration; and

1> set the variable INCOMPATIBLE_SECURITY_RECONFIGURATION to TRUE.

If the IE "Integrity protection mode command" has the value "Start", the IE "Status" in the variable INTEGRITY_PROTECTION_INFO has the value "Not started" and the IE "Integrity protection mode info" was not included in the message SECURITY MODE COMMAND and the IE "Integrity protection mode info" was not included in the message triggering SR-VCC and including the IE "NONCE"; or

If the IE "Integrity protection mode command" has the value "Start", the IE "Status" in the variable INTEGRITY_PROTECTION_INFO has the value "Not started", the IE "Integrity protection mode info" was included in the message SECURITY MODE COMMAND and the IE "Integrity protection algorithm" is not included or the IE "Integrity protection mode info" was included in the message triggering SR-VCC; or

If the IE "Integrity protection mode command" has the value "Modify" and the IE "Status" in the variable INTEGRITY_PROTECTION_INFO has the value "Not Started"; or

If the IE "Integrity protection mode command" has the value "Start", the IE "Status" in the variable INTEGRITY_PROTECTION_INFO has the value "Started" and the IE "Integrity protection mode command info" was included in the message SECURITY MODE COMMAND; or

If the IE "Integrity protection mode command" has the value "Modify" and there does not exist exactly one integrity protection activation time in the IE "Downlink integrity protection activation info" for each established signalling radio bearer included in the IE "Signalling radio bearer information" in the IE "ESTABLISHED_RABS"; or

If the IE "Integrity protection mode command" has the value "Modify", the IE "Status" in the variable INTEGRITY_PROTECTION_INFO has the value "Started" and the IE "Integrity protection mode info" was not included in the message SECURITY MODE COMMAND and the IE "Integrity protection mode info" was not included in the message triggering SR-VCC:

the UE shall:

1> ignore this attempt to change the integrity protection configuration; and

1> set the variable INVALID_CONFIGURATION to TRUE.

If the IE "Integrity protection mode info" is not present, the UE shall:

1> not change the integrity protection configuration.

If the IE "Integrity protection mode info" is present and if the IE "Reconfiguration" in the variable INTEGRITY_PROTECTION_INFO is set to FALSE, the UE shall:

1> set the IE "Reconfiguration" in the variable INTEGRITY_PROTECTION_INFO to TRUE;

1> perform the actions in accordance with subclauses 8.6.3.5.1, 8.6.3.5.2 and 8.6.3.5.3.

8.6.3.5.1 Initialisation of Integrity Protection

The UE shall:

1> if the IE "Integrity protection mode command" has the value "start" and the IE "Status" in the variable INTEGRITY_PROTECTION_INFO has the value "Not started", and this IE was included in the message SECURITY MODE COMMAND or this IE was included in the message triggering SR-VCC and including the IE "NONCE":

2> initialise the information for all signalling radio bearers in the variable INTEGRITY_PROTECTION_INFO according to the following:

3> set the IE "Uplink RRC Message sequence number" in the variable INTEGRITY_PROTECTION_INFO to zero;

3> do not set the IE "Downlink RRC Message sequence number" in the variable INTEGRITY_PROTECTION_INFO;

3> set the variable INTEGRITY_PROTECTION_ACTIVATION_INFO to zero for each signalling radio bearer in the IE "ESTABLISHED_RABS".

NOTE: The IEs "Integrity protection activation info" and "RRC Message sequence number"included in the IE "Integrity Check Info" in the transmitted message do not have identical values, but integrity protection is applied from the first transmitted message.

2> set the IE "Status" in the variable INTEGRITY_PROTECTION_INFO to the value "Started";

2> perform integrity protection on the received message, applying the new integrity protection configuration, as described in subclause 8.5.10.1 by:

3> using the algorithm (UIA [40]) indicated by the IE "Integrity protection algorithm" contained in the IE "Integrity protection mode info";

3> using the IE "Integrity protection initialisation number", contained in the IE "Integrity protection mode info" as the value of FRESH [40].

2> start applying the new integrity protection configuration in the downlink for each signalling radio bearer in the IE "ESTABLISHED_RABS" except RB2 at the next received RRC message;

2> start applying the new integrity protection configuration in the downlink for signalling radio bearer RB2 from and including the received SECURITY MODE COMMAND message or the message triggering SR-VCC;

2> start applying the new integrity protection configuration in the uplink for signalling radio bearer RB2 from and including the transmitted SECURITY MODE COMPLETE message or the transmitted response message for the message triggering SR-VCC;

2> start applying the new integrity protection configuration in the uplink for signalling radio bearers other than RB2 at the uplink activation time included in the IE "Uplink integrity protection activation info".

NOTE: After Inter-RAT handover to UTRAN, and ciphering was activated in the other RAT, then during the first security mode control procedure following the handover, UE activates integrity protection using the integrity key of the same key set as used in the other RAT (see.subclause 8.3.6.3).

8.6.3.5.2 Integrity Protection Re-configuration for SRNS Relocation, intra-RAT SR-VCC and handover from GERAN Iu mode

The UE shall:

1> if IE "Integrity protection mode command" has the value "start" and the IE "Status" in the variable INTEGRITY_PROTECTION_INFO has the value "Started" and this IE was not included SECURITY MODE COMMAND:

NOTE: This case is used in SRNS relocation, in SR-VCC and in handover from GERAN Iu mode.

2> perform integrity protection on the received message, applying the new integrity protection configuration, as described in subclause 8.5.10.1 by:

3> using the algorithm (UIA [40]) indicated by the IE "Integrity protection algorithm" contained in the IE "Integrity protection mode info";

NOTE: If the algorithm indicated by the IE "Integrity protection algorithm" is different from the one currently used by the UE, then this leads to a change of the integrity protection algorithm.

3> using the IE "Integrity protection initialisation number", contained in the IE "Integrity protection mode info" as the value of FRESH [40].

2> let RBm be the signalling radio bearer where the reconfiguration message was received and let RBn be the signalling radio bearer where the response message is transmitted;

2> prohibit transmission of RRC messages on all signalling radio bearers in the IE "ESTABLISHED_RABS" except on RB0 and the radio bearer where the response message is transmitted;

2> for the downlink, for each signalling radio bearer, if for the signalling radio bearer, a security configuration triggered by a previous SECURITY MODE COMMAND or a previous message triggering SR-VCC has not yet been applied, due to the activation time for the signalling radio bearer not having been reached:

3> set "Down link RRC Message sequence number" for this signalling radio bearer in the variable INTEGRITY_PROTECTION_INFO to (activation time -1), where the activation time is the corresponding activation time for this signalling radio bearer;

3> if the previous SECURITY MODE COMMAND was received due to new keys being received:

4> consider the new integrity protection configuration to include the received new keys.

3> else if the previous SECURITY MODE COMMAND or the previous message triggering SR-VCC caused a change in LATEST_CONFIGURED_CN_DOMAIN:

4> consider the new Integrity Protection configuration to include the keys associated with the LATEST_CONFIGURED_CN_DOMAIN associated with the previously received SECURITY MODE COMMAND.

2> start applying the new integrity protection configuration in the downlink for each signalling radio bearer in the IE "ESTABLISHED_RABS" except RBm at the next received RRC message for the corresponding signalling radio bearer;

2> start applying the new integrity protection configuration in the downlink for signalling radio bearer RBm from and including the received configuration message;

2> start applying the new integrity protection configuration in the uplink for signalling radio bearer RBn from and including the transmitted response message;

2> start applying the new integrity protection configuration in the uplink for signalling radio bearers other than RBn from the first message onwards.

8.6.3.5.3 Integrity Protection modification in case of new keys or initialisation of signalling connection

The UE shall:

1> if the IE "Integrity protection mode command" has the value "modify" and the IE "Status" in the variable INTEGRITY_PROTECTION_INFO has the value "Started" and this IE was included in SECURITY MODE COMMAND or this IE was included in a message triggering SR-VCC:

2> store the (oldest currently used) integrity protection configuration until activation times have elapsed for the new integrity protection configuration to be applied on all signalling radio bearers;

2> start applying the new integrity protection configuration in the downlink for each signalling radio bearer n, at the first received message with RRC Sequence number greater than or equal to the RRC sequence number indicated by the entry for signalling radio bearer n in the "RRC message sequence number list" in the IE "Downlink integrity protection activation info", included in the IE "Integrity protection mode info";

2> perform integrity protection on the received message, applying the new integrity protection configuration, as described in subclause 8.5.10.1;

3> if present, use the algorithm indicated by the IE "Integrity protection algorithm" (UIA [40]);

2> set the content of the variable INTEGRITY_PROTECTION_ACTIVATION_INFO according to the following:

3> for each established signalling radio bearer, stored in the variable ESTABLISHED_RABS:

4> select a value of the RRC sequence number at which (activation) time the new integrity protection configuration shall be applied in uplink for that signalling radio bearer according to the following:

5> for each signalling radio bearer except RB0:

6> set the activation time for the new integrity protection configuration to the next RRC SN.

4> for signalling radio bearer RB0:

5> set the value of the included RRC sequence number to greater than or equal to the current value of the RRC sequence number for signalling radio bearer RB0 in the variable INTEGRITY_PROTECTION_INFO, plus the value of the constant N302 plus two.

4> prohibit the transmission of RRC messages on all signalling radio bearers, except for RB2, with RRC SN greater than or equal to the value in the "RRC message sequence number list" for the signalling radio bearer in the IE "Uplink integrity protection activation info" of the variable INTEGRITY_PROTECTION_ACTIVATION_INFO.

2> start applying the new integrity protection configuration in the uplink at the RRC sequence number, for each RBn, except for signalling radio bearer RB2, indicated by the entry for signalling radio bearer n in the "RRC message sequence number list" in the IE "Uplink integrity protection activation info", included in the variable INTEGRITY_PROTECTION_ACTIVATION_INFO;

2> start applying the new integrity protection configuration in the uplink at the RRC sequence number for signalling radio bearer RB2, as specified for the procedure initiating the integrity protection reconfiguration;

2> start applying the new integrity protection configuration in the downlink at the RRC sequence number, for each RBn, except for signalling radio bearer RB2, indicated by the entry for signalling radio bearer n in the "RRC message sequence number list" in the IE "Downlink integrity protection activation info";

NOTE: For signalling radio bearers that have a pending activation time as set for integrity protection by a previous procedure changing the integrity protection configuration, UTRAN should set this value in IE "Downlink integrity protection activation info".

2> start applying the new integrity protection configuration in the downlink at the RRC sequence number for signalling radio bearer RB2, as specified for the procedure initiating the integrity protection reconfiguration.

8.6.3.6 Void

8.6.3.7 Void

8.6.3.8 Integrity check info

If the IE "Integrity check info" is present the UE shall:

1> act as described in subclause 8.5.10.1.

8.6.3.9 New C-RNTI

If the IE "New C-RNTI" is included, the UE shall:

1> store the value in the variable C_RNTI, replacing any old stored value;

1> use that C-RNTI when using common transport channels of type RACH and FACH in the current cell;

1> for FDD and 1.28 Mcps TDD:

2> if the UE is in CELL_FACH and CELL_PCH:

3> use that C-RNTI when using the transport channel of type HS-DSCH.

8.6.3.9a New DSCH-RNTI

In TDD if the IE "New DSCH-RNTI" is included, the UE shall:

1> if the UE will be in CELL_DCH or CELL_FACH at the end of the procedure where the received message included this IE:

2> if the UE supports DSCH or USCH as indicated in the IE "Physical Channel Capability" included in the IE "UE Radio Access Capability":

3> store the value in the variable DSCH_RNTI, replacing any old stored value;

3> use that DSCH-RNTI when using SHCCH signalling in the current cell.

8.6.3.10 New U-RNTI

If the IE "New U-RNTI" is included in a received message, the UE shall:

1> store the value in the variable U_RNTI, replacing any old stored value.

8.6.3.11 RRC transaction identifier

The IE "RRC transaction identifier" may be used, together with the message type, for identification of an invocation of a downlink procedure (transaction). The UE behaviour for accepting or rejecting transactions based on the message type and the IE "RRC transaction identifier" is specified below.

If the IE "RRC transaction identifier" is included in a received message or if a Target cell HS-SCCH order is received, the UE shall perform the actions below. When a Target cell HS-SCCH order is received, the UE shall consider this as a received message with IE "RRC transaction identifier" and "Message Type" equivalent to the fields "Serving Cell Change Transaction Id" and "Serving Cell Change Message Type" stored in the variable TARGET_CELL_PRECONFIGURATION. The UE shall:

If the received message is any of the messages:

– RADIO BEARER SETUP; or

– RADIO BEARER RECONFIGURATION; or

– RADIO BEARER RELEASE; or

– TRANSPORT CHANNEL RECONFIGURATION; or

– PHYSICAL CHANNEL RECONFIGURATION; or

– a Target cell HS-SCCH order:

the UE shall:

1> if the variable ORDERED_RECONFIGURATION is set to FALSE; and

1> if the variable CELL_UPDATE_STARTED is set to FALSE; and

1> if the received message does not contain a protocol error according to clause 9 and the variable PROTOCOL_ERROR_REJECT is set to FALSE; and

1> if the table "Accepted transactions" in the variable TRANSACTIONS does not contain an entry with an IE "Message Type" set to ACTIVE SET UPDATE; and

1> if the UE has received:

2> a Target cell HS-SCCH order; or

2> an RRC message and the table "Processed transactions" in the variable TRANSACTIONS does not contain an entry with the same "Message Type" and "Transaction identifier" as the received message, the UE shall:

3> accept the transaction; and

3> store the IE "Message type" and the IE "RRC transaction identifier" of the received message in the table "Accepted transactions" in the variable TRANSACTIONS. In case of the reception of a Target cell HS-SCCH order, the UE shall use the values received in the IEs "Serving Cell Change Message Type" and "Serving Cell Change Transaction Id" which were received in the Active Set Update; and

3> if the received message is not a Target cell HS-SCCH order:

4> clear all entries in the table "Processed transactions" in the variable TRANSACTIONS.

1> else:

2> if the variable ORDERED_RECONFIGURATION is set to TRUE; or

2> if the variable CELL_UPDATE_STARTED is set to TRUE; or

2> if the table "Accepted transactions" in the variable TRANSACTIONS contains an entry with an IE "Message Type" set to ACTIVE SET UPDATE; or

2> if the received message contains a protocol error according to clause 9 causing the variable PROTOCOL_ERROR_REJECT to be set to TRUE; or

2> if the UE received an RRC message and the table "Processed transactions" in the variable TRANSACTIONS contains an entry with the same "Message Type" and "Transaction identifier" as the received message:

3> if the UE received an RRC message and the table "Processed transactions" in the variable TRANSACTIONS contains an entry with the same "Message Type" and "Transaction identifier" as the received message:

4> ignore the transaction; and

4> continue with any ongoing processes and procedures as if the message was not received; and

4> clear one entry which is identified by IE "Message Type" and "RRC transaction identifier" of the received message in "Processed transactions" in the variable TRANSACTIONS; and

4> end the procedure.

3> else if the IE "RRC transaction identifier" of the received message is identical to the "RRC transaction identifier" stored for the same "Message Type" as the received message in the table "Accepted transactions" in the variable TRANSACTIONS:

4> ignore the transaction; and

4> continue with any ongoing processes and procedures as if the message was not received; and

4> end the procedure.

3> else:

4> reject the transaction; and

4> if the IE "Message Type" of the received message is not present in the table "Rejected transactions" in the variable TRANSACTIONS:

5> store the IE "Message type" and the IE "RRC transaction identifier" of the received message in the table "Rejected transactions" in the variable TRANSACTIONS.

Else:

If the received message is any of the messages:

– RRC CONNECTION SETUP; or

– CELL UPDATE CONFIRM; or

– URA UPDATE CONFIRM; or

– UE CAPABILITY ENQUIRY:

the UE shall:

1> if the IE "Message Type" of the received message is not present in the table "Accepted transactions" in the variable TRANSACTIONS:

2> if the received message does not contain a protocol error according to clause 9 and the variable PROTOCOL_ERROR_REJECT is set to FALSE:

3> accept the transaction; and

3> store the IE "Message type" and the IE "RRC transaction identifier" of the received message in the table "Accepted transactions" in the variable TRANSACTIONS.

2> else:

3> if the received message contains a protocol error according to clause 9 causing the variable PROTOCOL_ERROR_REJECT to be set to TRUE:

4> reject the transaction; and

4> if the IE "Message Type" of the received message is not present in the table "Rejected transactions" in the variable TRANSACTIONS:

5> store the IE "Message type" and the IE "RRC transaction identifier" of the received message in the table "Rejected transactions" in the variable TRANSACTIONS.

1> else:

2> if the IE "Message Type" of the received message is present in the table "Accepted transactions" in the variable TRANSACTIONS:

3> if the IE "RRC transaction identifier" of the received message is identical to the "RRC transaction identifier" stored for the "Message Type" in the table "Accepted transactions" in the variable TRANSACTIONS:

4> ignore the transaction; and

4> continue with any ongoing processes and procedures as the message was not received; and

4> end the procedure.

3> else:

4> if the IE "RRC transaction identifier" of the received message is different from the "RRC transaction identifier" stored for the "Message Type" in the table "Accepted transactions" in the variable TRANSACTIONS:

5> if the received message does not contain a protocol error according to clause 9 and the variable PROTOCOL_ERROR_REJECT is set to FALSE:

6> ignore the once accepted transaction and instead accept the new transaction; and

6> store the IE "Message type" and the IE "RRC transaction identifier" of the received message in the table "Accepted transactions" in the variable TRANSACTIONS, replacing the previous entry.

NOTE 1: The UE is expected to process the first RRC CONNECTION SETUP/CELL UPDATE CONFIRM/URA UPDATE COMFIRM message that it receives after transmitting an RRC CONNECTION REQUEST/CELL_UPDATE/URA_UPDATE message. If the UE receives further RRC CONNECTION SETUP/CELL UPDATE CONFIRM/URA UPDATE COMFIRM messages without having transmitted another RRC CONNECTION REQUEST/CELL_UPDATE/URA_UPDATE message, the UE is not required to process these messages.

NOTE 2: If the previously accepted transaction was a CELL UPDATE CONFIRM/URA UPDATE CONFIRM that included the IE "Dowlink counter synchronisation info", rather than ignore the first accepted transaction the UE may continue with the first transaction in the case where a cell re-selection interrupted the on-going procedure causing a cell update procedure to be triggered. In this case the response message acts as an explicit acknowledgement of both the CELL UPDATE CONFIRM/URA UPDATE CONFIRM message signalling an SRNS relocation and the subsequent CELL UPDATE CONFIRM/URA UPDATE CONFIRM.

5> else:

6> if the received message contains a protocol error according to clause 9 causing the variable PROTOCOL_ERROR_REJECT to be set to TRUE:

7> reject the transaction; and

7> if the IE "Message Type" of the received message is not present in the table "Rejected transactions" in the variable TRANSACTIONS:

8> store the IE "Message type" and the IE "RRC transaction identifier" of the received message in the table "Rejected transactions" in the variable TRANSACTIONS.

Else:

If the received message is any of the messages:

– HANDOVER FROM UTRAN COMMAND; or

– CELL CHANGE ORDER FROM UTRAN:

the UE shall:

1> if the variable ORDERED_RECONFIGURATION is set to TRUE;

2> reject the transaction; and

2> if the IE "Message Type" of the received message is not present in the table "Rejected transactions" in the variable TRANSACTIONS:

3> store the IE "Message type" and the IE "RRC transaction identifier" of the received message in the table "Rejected transactions" in the variable TRANSACTIONS.

Else:

If the received message is:

– MEASUREMENT CONTROL:

the UE shall:

1> if the IE "Message Type" of the received message is not present in the table "Accepted transactions" in the variable TRANSACTIONS:

2> if the received message does not contain a protocol error according to clause 9 and the variable PROTOCOL_ERROR_REJECT is set to FALSE:

3> accept the transaction; and

3> store the IE "Message type", the IE "RRC transaction identifier", and the IE "Measurement identity" of the received message in the table "Accepted transactions" in the variable TRANSACTIONS.

2> else:

3> if the received message contains a protocol error according to clause 9 causing the variable PROTOCOL_ERROR_REJECT to be set to TRUE:

4> reject the transaction; and

4> store the IE "Message type", the IE "RRC transaction identifier", and the IE "Measurement identity" of the received message in the table "Rejected transactions" in the variable TRANSACTIONS.

1> else:

2> if the IE "Message Type" of the received message is present in the table "Accepted transactions" in the variable TRANSACTIONS:

3> if the IE "RRC transaction identifier" of the received message is identical to the "RRC transaction identifier" stored in any entry for the "Message Type" in the table "Accepted transactions" in the variable TRANSACTIONS:

4> ignore the transaction; and

4> continue with any ongoing processes and procedures as the message was not received; and

4> end the procedure.

3> else:

4> if the IE "RRC transaction identifier" of the received message is different from the "RRC transaction identifier" stored in all entries for the "Message Type" in the table "Accepted transactions" in the variable TRANSACTIONS:

5> if the received message does not contain a protocol error according to clause 9 and the variable PROTOCOL_ERROR_REJECT is set to FALSE:

6> accept the additional transaction; and

6> store the IE "Message type", the IE "RRC transaction identifier", and the IE "Measurement identity" of the received message in the table "Accepted transactions" in the variable TRANSACTIONS, in addition to the already existing entries.

5> else:

6> if the received message contains a protocol error according to clause 9 causing the variable PROTOCOL_ERROR_REJECT to be set to TRUE:

7> reject the transaction; and

7> store the IE "Message type", IE "RRC transaction identifier", and the IE "Measurement identity" of the received message in the table "Rejected transactions" in the variable TRANSACTIONS.

If the received message is any other message, the UE shall:

1> if the IE "Message Type" of the received message is not present in the table "Accepted transactions" in the variable TRANSACTIONS:

2> if the received message does not contain a protocol error according to clause 9 and the variable PROTOCOL_ERROR_REJECT is set to FALSE:

3> accept the transaction; and

3> store the IE "Message type" and the IE "RRC transaction identifier" of the received message in the table "Accepted transactions" in the variable TRANSACTIONS.

2> else:

3> if the received message contains a protocol error according to clause 9 causing the variable PROTOCOL_ERROR_REJECT to be set to TRUE:

4> reject the transaction; and

4> store the IE "Message type" and the IE "RRC transaction identifier" of the received message in the table "Rejected transactions" in the variable TRANSACTIONS.

1> else:

2> if the IE "Message Type" of the received message is present in the table "Accepted transactions" in the variable TRANSACTIONS:

4> ignore the transaction; and

4> continue with any ongoing processes and procedures as the message was not received; and

4> end the procedure.

3> else:

5> if the received message does not contain a protocol error according to clause 9 and the variable PROTOCOL_ERROR_REJECT is set to FALSE:

6> accept the additional transaction; and

6> store the IE "Message type" and the IE "RRC transaction identifier" of the received message in the table "Accepted transactions" in the variable TRANSACTIONS, in addition to the already existing entries.

5> else:

6> if the received message contains a protocol error according to clause 9 causing the variable PROTOCOL_ERROR_REJECT to be set to TRUE:

7> reject the transaction; and

7> store the IE "Message type" and the IE "RRC transaction identifier" of the received message in the table "Rejected transactions" in the variable TRANSACTIONS.

8.6.3.12 Capability Update Requirement

If the IE "Capability Update Requirement" is included the UE shall:

1> if the IE "UE radio access FDD capability update requirement" has the value TRUE:

2> if the UE supports FDD mode:

3> store its UTRA FDD capabilities and its UTRA capabilities common to FDD and TDD in the IE "UE radio access capability" and the IE "UE radio access capability extension" in variable UE_CAPABILITY_REQUESTED as specified below:

4> if the UE supports any radio access capability included in IE "UE radio access capability extension" that is not included in IE "UE radio access capability":

NOTE: This is valid e.g. for UE that supports multiple UTRA FDD Bands, UE that supports a single UTRA FDD Band different from Band I [21] or UE that supports E-UTRA.

5> store the IE "UE radio access capability", excluding IEs "RF capability FDD" and "Measurement capability";

5> store the IE "UE radio access capability extension", including the IEs "RF capability FDD extension", the "Measurement capability extension", the "Additional Secondary Cells" and the "Non-contiguous multi-cell" associated with each supported UTRA FDD frequency band indicated in the IE "Frequency band".

4> else:

5> store the IE "UE radio access capability", including the IEs "RF capability FDD" and "Measurement capability" associated with the Band I [21].

1> if the IE "UE radio access 3.84 Mcps TDD capability update requirement" has the value TRUE:

2> if the UE supports 3.84 Mcps TDD mode:

3> store its UTRAN-specific 3.84 Mcps TDD capabilities and its UTRAN–specific capabilities common to FDD and TDD in the variable UE_CAPABILITY_REQUESTED.

1> if the IE "UE radio access 7.68 Mcps TDD capability update requirement" has the value TRUE:

2> if the UE supports 7.68 Mcps TDD mode:

3> store its UTRAN-specific 7.68 Mcps TDD capabilities and its UTRAN–specific capabilities common to FDD and TDD in the variable UE_CAPABILITY_REQUESTED.

1> if the IE "UE radio access 1.28 Mcps TDD capability update requirement" has the value TRUE:

2> if the UE supports 1.28 Mcps TDD mode:

3> store its UTRAN-specific 1.28 Mcps TDD capabilities and its UTRAN–specific capabilities common to FDD and TDD in the variable UE_CAPABILITY_REQUESTED;

3> if the UE supports E-UTRA:

4> store the IE "UE radio access capability", including "Measurement capability TDD" associated with each supported E-UTRA band.

1> if the IE "System specific capability update requirement list" is present:

2> for each of the RAT requested in the IE "UE system specific capability":

3> if the UE supports the listed RAT:

4> include its inter-RAT radio access capabilities for the listed RAT in the IE "UE system specific capability" from the variable UE_CAPABILITY_REQUESTED;

4> if the listed RAT is GSM and PS Handover to GPRS is supported:

5> include the IE ”MS Radio Access Capability” in the variable UE_CAPABILITY_REQUESTED.

4> if the listed RAT is E-UTRA:

5> if the IE "Requested E-UTRA Frequency Band list" is present and supported by the UE:

6> include in IE "UE system specific capability" in the variable UE_CAPABILITY_REQUESTED all supported E-UTRA bands according to sub-clause 5.6.3.3 in [67];

6> include in IE "UE system specific capability" in the variable UE_CAPABILITY_REQUESTED all supported non-CA bands according to sub-clause 5.6.3.3 in [67];

6> include in IE "UE system specific capability" in the variable UE_CAPABILITY_REQUESTED CA band combinations according to sub-clause 5.6.3.3 in [67] as if the UE supports only those E-UTRA frequency bands signaled in IE "Requested E-UTRA Frequency Band list";

6> include in IE "UE system specific capability" in the variable UE_CAPABILITY_REQUESTED other E-UTRA capabilities.

If the IE "Capability update requirement" is not present, the UE shall:

1> assume the default values as specified in subclause 10.3.3.2 and act in accordance with the above.

8.6.3.13 Group release information

The UE shall apply the following procedure to compare the IE "U-RNTI group" with the U-RNTI allocated to the UE stored in the variable U_RNTI.

If the IE "group discriminator" is equal to "All":

1> consider this as a group identity match.

If the IE "group discriminator" is equal to "U-RNTI mask":

1> let N be the value of the IE "U-RNTI bit mask index";

1> if N is equal to b20, b21, … or b31:

2> compare pairs of bits, starting from bit b31 downto, and including, bit N of the "SRNC identity" of the IE "U-RNTI" with the corresponding bits stored in the variable U_RNTI;

2> if all pairs of bits are equal:

3> consider this as a group identity match.

1> if N is equal to b1, b2, … or b19:

2> compare pairs of bits, starting from bit b31 downto, and including, bit b20 of the "SRNC identity" in the IE "U-RNTI" with the corresponding bits of the "SRNC identity" stored in the variable U_RNTI;

2> if all pairs of bits are equal:

3> then compare pairs of bits, starting from bit b19 downto, and including, bit N of the "S-RNTI" in the IE "U-RNTI" with the corresponding bits of the "S-RNTI" stored in the variable U_RNTI;

3> if all pairs of bits are equal:

4> consider this as a group identity match.

NOTE 1: The most significant bits of the U-RNTI, which indicate the "SRNC identity" must be unique among all RNC’s, which support all the UEs in the group to be released, in order to obtain correct behaviour of group release.

8.6.3.14 New E-RNTI

If the IE "New Primary E-RNTI" and/or the IE "New Secondary E-RNTI" (FDD only) are/is included and the UE will be in CELL_DCH state after completion of this procedure, the UE shall:

1> if the IE "New Primary E-RNTI" is received in a UTRAN MOBILITY INFORMATION message:

2> the UE behaviour is unspecified;

1> store the new value(s) in the variable E_RNTI;

1> determine the value for the E_DCH_TRANSMISSION variable and take the corresponding actions as described in subclause 8.5.28.

If, after state transition the UE enters CELL_PCH or URA_PCH state and the UE was in CELL_DCH state upon reception of the reconfiguration message the UE shall:

1> if the UE supports E-DCH transmission in CELL_FACH state and Idle mode and the IE "Common E-DCH system info" is included in system information block type 5 or 5bis:

2> clear the variable E_RNTI.

For FDD and 1.28 Mcps TDD, if the IE "New Primary E-RNTI" is included and the UE will be in CELL_FACH or CELL_PCH state after completion of this procedure, the UE shall:

1> store the new value in the variable E_RNTI;

1> determine the value for the READY_FOR_COMMON_EDCH variable and perform the corresponding actions as described in subclause 8.5.47.

1> for FDD, determine the value for the READY_FOR_COMMON_ERGCH variable and perform the corresponding actions as described in subclause 8.5.75.

For FDD, if the IE "New Primary E-RNTI" is included and the UE will be in URA_PCH state after completion of this procedure, the UE shall:

1> store the new value in the variable E_RNTI;

1> for FDD, determine the value for the HSPA_RNTI_STORED_PCH variable and perform the corresponding actions as described in subclause 8.5.56.

If, after the completion of this procedure, the variable E_DCH_TRANSMISSION is set to FALSE, the UE in CELL_DCH state shall:

1> clear the variable E_RNTI.

If, after the completion of this procedure, the variable READY_FOR_COMMON_EDCH is set to FALSE and the variable HSPA_RNTI_STORED_PCH is also set to FALSE, the UE shall:

1> if not in CELL_DCH, or not in URA_PCH state and E_RNTI is set:

2> clear the variable E_RNTI.

When the variable E_DCH_TRANSMISSION is set to TRUE the UE shall:

1> for FDD:

2> use the value of the Primary E-RNTI and/or Secondary E-RNTI stored in the variable E_RNTI as UE identities in the E-AGCH reception procedure in the physical layer.

1> for TDD:

2> use the value of New Primary E-RNTI stored in the variable E_RNTI as the UE identity in the E-AGCH reception procedure and the E-RUCCH transmission procedure in the physical layer.

When the variable SECONDARY_CELL_E_DCH_TRANSMISSION is set to TRUE and the secondary uplink frequency is an activated uplink frequency, the UE shall:

1> use the primary E-RNTI and/or secondary E-RNTI stored in the IE "Secondary serving E-DCH cell info" as UE identities in the E-AGCH reception procedure in the physical layer on the downlink frequency associated with the secondary uplink frequency.

8.6.3.15 SR-VCC Info

The presence of the IE "NONCE" in the IE "SR-VCC Info" triggers the relevant actions for mapping keys from the PS domain to the CS domain. The IE "NONCE" is not included if ciphering is not active for PS domain prior to the reception of the IE "SR-VCC Info".

If the IE "SR-VCC Info" is included and the IE "NONCE" is present in the IE "SR-VCC Info", the UE shall:

1> set the "Status" in the variable CIPHERING_STATUS of the CS domain to "Started";

1> calculate the CK and IK for the CS domain as specified in [40];

1> if the IE "SR-VCC Info" is included in a message other than HANDOVER FROM UTRAN COMMAND:

2> set the variable LATEST_CONFIGURED_CN_DOMAIN to "CS domain";

2> use the ciphering algorithm in use for the PS domain as part of the new ciphering configuration for the CS domain unless otherwise specified by the message triggering SR-VCC.

If the IE "SR-VCC Info" is included, the UE shall:

1> add the signalling connection with the identity "CS domain" in the variable ESTABLISHED_SIGNALLING_CONNECTIONS.

8.6.3.16 rSR-VCC Info

If the IE "rSR-VCC Info" is received and contains the IE "IMS information", the UE shall:

1> indicate the "IMS information" IE to the upper layers as part of rSR-VCC procedure.

If the IE "rSR-VCC Info" is received and contains the IE "NONCE", the UE shall:

1> forward the IE "NONCE" to upper layers as specified in [79];

8.6.3.17 Access Group identity

If the IE "Access Group identity" is included, the UE shall:

1> store the value in the variable CONNECTED_MODE_ACCESS_CONTROL, replacing any stored value of the IE "Access Group identity";

1> if in CELL_FACH state:

2> if System Information Block type 24 is scheduled on the broadcast channel:

3> if the n-th Bit in the IE "DTCH transmission blocked" in the variable CONNECTED_MODE_ACCESS_CONTROL is set to 1, where n is the value stored in the IE "Access Group identity" in the variable CONNECTED_MODE_ACCESS_CONTROL:

4> configure RLC entities mapped onto the logical channel DTCH to not submit any data PDUs to lower layers.

3> else:

4> configure RLC entities mapped onto the logical channel DTCH to allow submitting data PDUs to lower layers.

1> if in CELL_PCH state or URA_PCH state:

2> if System Information Block type 24 is scheduled on the broadcast channel:

4> not trigger a measurement report procedure or not initiate the cell update procedure with cell update cause "uplink data transmission".

NOTE: Measurement report and cell update procedures that are triggered by uplink RLC control PDU are permitted.

8.6.3.18 RNTI handling at cell re-selection

If the IE "RNTI handling at cell re-selection" is included, the UE shall:

1> set the variable RNTI_HANDLING_AT_CELL_RE-SELECTION to TRUE.

else:

1> set the variable RNTI_HANDLING_AT_CELL_RE-SELECTION to FALSE.

8.6.3.19 Actions related to dynamic activation time determination (FDD only)

If the IE "Dynamic activation time" is included, the UE shall:

1> trigger lower layers to start operation of improved synchronized RRC procedures.

If the UE receives a lower layer ACK to an UL MAC Control Information for a Ready to Switch [15], the UE shall:

1> calculate the determined activation time, by adding the value of the IE "Activation offset" included in the message to the CFN [29] of the latest ACK received;

1> set the value of the determined activation time to the smaller of the determined activation time calculated above and the value of the IE "Activation Time" included in the message, taking possible CFN wrap-around into account;

1> store the value of the determined activation time in the variable DETERMINED_ACTIVATION_TIME;

1> perform the actions as specified in chapter 8.6.3.1 considering the determined activation time when selecting the activation time T.

NOTE 1: If the UE has not received a lower layer ACK to an UL MAC Control Information for a Ready to Switch [15] before the activation time specified in the IE "Activation Time" if the value is not the default value "Now", the UE shall perform the actions as specified in chapter 8.6.3.1 considering the IE "Activation Time".